Sunday, January 30, 2011

Getting access to database installed by SharePoint 2010 single server install

After performing single server installation of SharePoint 2010 you have new SQL Server instance called SHAREPOINT running on your server. You can access it using Management Studio but you cannot do practically nothing with this instance if you are logged in as domain user to this machine. You have to add your domain account to server admin role so you can manage this SQL Server.

Chris Randall has very good step-by-step guide that helps you add your account to SQL Server server admin role: SQL Server 2008: Forgot to add an administrator account? 

Some notes. You should call sp_addsrvrolemember with additional argument for role name. Otherwise you will get error: '(null)' is not a fixed server role. So, correct call that works is something like this:

sp_addsrvrolemember @loginame='user', @rolename='sysadmin'

This situation is not usual and usually you don’t face this problem.

SharePoint installation error: dbwrap.exe failed with error code: -2068643839. Type: 8::CommandFailed

Got the following error when installing SharePoint Server 2010 to machine where SQL Server 2008 R2 was previously installed: dbwrap.exe failed with error code: -2068643839. Type: 8::CommandFailed. Here’s my painful guide how I solved the problem.

Messages in setup error log

  • Successfully installed package: oserver path:G:\Global\oserver.MSI
  • Executing command path: 'C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\BIN\stsadm.exe', args: 'updateproductinfo'
  • Start C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\BIN\stsadm.exe updateproductinfo
    Command 'C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\BIN\stsadm.exe' returned: 0
  • Executing command path: 'C:\Program Files\Common Files\Microsoft Shared\SERVER14\Server Setup Controller\dbwrap.exe', args: 'timeout=2950'
  • Start C:\Program Files\Common Files\Microsoft Shared\SERVER14\Server Setup Controller\dbwrap.exe timeout=2950
  • Error: Command: 'C:\Program Files\Common Files\Microsoft Shared\SERVER14\Server Setup Controller\dbwrap.exe' failed with error code: -2068643839. Type: 8::CommandFailed.

1. Uninstall SQL Server 2008

I found some suggestions to uninstall SQL Server 2008 (R2) because there can be problems if standalone installation finds some existing database. Well, there are two instances in my server:

  • SHAREPOINT
  • Default instance

To make sure that there is nothing left from previous installations or experiments I uninstalled SQL Server 2008 completely.

2. Make sure you don’t have pending file operations

I found also some interesting suggestion from comments of MSDN library page Setting Up the Development Environment for SharePoint 2010 on Windows Vista, Windows 7, and Windows Server 2008. Quote:

“If I go to regedit and then to HKEY_LOCAL_MACHINE>SYSTEM>CurrentControlSet>Control>Session Manager I see a "PendingFileRenameOperations" registry.  This was leftover by the Logitech install (sloppy codewriting no doubt).  If I delete this and re-run the Repair then it works.  The file refreshes itself on Restart though so I'll need to figure out how to deal with this permanently.”

I had no data under this key but maybe this knowledge may help somebody.

3. Install SharePoint 2010 as single instance again

I ran setup again and let it repair last installation. After that I ran SharePoint configuration wizard and my SharePoint 2010 got nicely up again.

SharePoint 2010 installation and configuration logs

Short posting that helps me to find SharePoint 2010 setup and configuration logs easily. Taken from TechNet page Verify upgrade and review upgraded sites (SharePoint Foundation 2010).

The Setup.exe log file for SharePoint Foundation 2010

The Setup log file is stored in the temp directory for the user account that is running Setup (%USERTEMP% or %WINDIR%\Users\user account\AppData\Local\Temp). It is named SharePoint Foundation Setup(YYYYMMDD-HHMMSS-SSS).log, where YYYYMMDD is the date and HHMMSS-SSS is the time (hours in 24-hour clock format, minutes, seconds, and milliseconds).

The SharePoint Products Configuration Wizard (Psconfig.exe) log file

The Psconfig.exe log files are located at %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\14\LOGS. The logs are named in the following format: PSCDiagnostics_MM_DD_YYYY_HH_MM_SS_SSS_randomnumber.log, where MM_DD_YY is the date and HH_MM_SS_SSS is the time (hours in 24-hour clock format, minutes, seconds, and milliseconds), and the random number is used to differentiate between possible simultaneous attempts to run the Psconfig.exe program.

The upgrade log file and the upgrade error log file

The upgrade log file and the upgrade error log file are located at %COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\14\LOGS. The logs are named in the following format: Upgrade-YYYYMMDD-HHMMSS-SSS.log, where YYYYMMDD is the date and HHMMSS-SSS is the time (hours in 24-hour clock format, minutes, seconds, and milliseconds). The upgrade error log file combines all errors and warnings into a shorter file and is named Upgrade-YYYYMMDD-HHMMSS-SSS-error.log.

Saturday, January 29, 2011

CAML: Use “text“ as type when querying text fields

As I don’t write CAML queries very often due to some good libs I have worked out over time I sometimes forget little nuances about CAML. One of my favorites is using “string” instead of “text” as type when querying text fields.

Wrong:

<Where><Eq><Value Type="string">Green, Graham</Value></Eq></Where>

Right:

<Where><Eq><Value Type="text">Green, Graham</Value></Eq></Where>

Hope it helps.