Installing 64 bit MOSS with a 32 bit SQL Server (Using SQL Alias)

I have come across a issue which took me a while to figure out the reason.

Problem: I was installing 64 Bit Version of MOSS and configuring the databases on a 32 Bit SQL server. Now on the MOSS server I had 32 bit SQL client tools to setup the SQL server alias. So my connection string when configuring MOSS was "SharePointSQLServer" for the SQL server 10.x.x.x on instance ABC01 port 1435 (10.x.x.x\ABC01, 1435). Now I was setting up the alias on MOSS server using SQL client tools. For some reason confuguration wizard was not detecting the correct SQL alias and was throwing me error of cannot connect to DB server.

Solution and Attempts:

• I tried different sets of aliases but no help. For example tried using machine name instead of IP, tried using FQDN of machine name, tried without instance name. No help!
• Then I thought it might be 32 bit client tools. So I tried removing 32 bit version and installed 64 bit version of SQL client tools. Still No help!
• Worked Solution: Then I went through the registry entries at:

(32 Bit Location)
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSSQLServer\Client\ConnectTo

The SQL client tools add the regisrty entry to this location for 32 bit applications running on 64 bit operating System. But MOSS 64 Bit configuration wizard was not reading from this location and instead trying to use the Alias name directly from some other location.

So I went and checked in registry entries at this location:
(64 Bit Location)HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Client

And there was no ConnectTo key. So even after installing 64 Bit version of SQL client tools the conenction string was not getting set at above location and was going into Wow6432Node key which is used for 32 bit applications. So I created a ConnectTo key by exporting from 32 Bit Location (Wow6432Node) and importing into 64 Bit Location so that my registry key on MOSS server looks like this:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\Client\ConnectTo

And checked that the value of connection string is: "DBMSSOCN,SharePointSQLServer,PortNumber"

And guess what? Yes it worked!

So on 64 Bit Windows 2003 machines if you get any issues related to entries in regisrty keys then you know where and what to look for :-)

Let me know if you have any questions on this.

Cheers,
Kunal

Error Event ID 5555, Event ID 7888 after changing Web App Association with new SSP

I had come across a strange issue which exposes some of the inabilities of MOSS. I had to recreate SSP in a SharePoint Farm. I then went and changed the association of web applications to point to new SSP so that I can get rid of old faulty SSP. (It was faluty because the search was stuck on "Crawling Full (Computing Ranking)" status and when tried to remove the SSP it was then stuck on "Unprovisioning" status). So to remove the old SSP:
- I created a new SSP.
-Associated web applications from old SSP to new SSP through Central Administration.
-Change the default SSP to new one.
-Deleted the old SSP including all associated databases.
-Deleted old SSP web application.

After this next day I saw in event logs there were errors thrown related synchronization of MySite and Portal web application with content databases. The errors were as below:

Event Type: ErrorEvent Source: Office SharePoint ServerEvent Category: User Profiles Event ID: 5555Date: 8/10/2008Time: 1:01:00 PMUser: N/AComputer: AUYXUAP310WBC32Description:Failure trying to synch web application ab1d413c-4e4b-40af-b9f2-61fedadb385d, ContentDB 4876d341-5349-4396-b0a9-3cb6f5110b1c Exception message was Cannot open database "WSS_SharedServices2_DB" requested by the login. The login failed.Login failed for user 'ESDEVAU\SRV-SHRPT07'.
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Event Type: ErrorEvent Source: Office SharePoint ServerEvent Category: Office Server General Event ID: 7888Date: 8/10/2008Time: 1:01:00 PMUser: N/AComputer: AUYXUAP310WBC32Description:A runtime exception was detected. Details follow. Message: Cannot open database "WSS_SharedServices2_DB" requested by the login. The login failed.Login failed for user 'ESDEVAU\SRV-SHRPT07'.
Techinal Details:System.Data.SqlClient.SqlException: Cannot open database "WSS_SharedServices2_DB" requested by the login. The login failed.Login failed for user 'ESDEVAU\SRV-SHRPT07'. at System.Data.ProviderBase.DbConnectionPool.GetConnection(DbConnection owningObject) at System.Data.ProviderBase.DbConnectionFactory.GetConnection(DbConnection owningConnection) at System.Data.ProviderBase.DbConnectionClosed.OpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory) at System.Data.SqlClient.SqlConnection.Open() at Microsoft.Office.Server.Data.SqlSession.OpenConnection() at Microsoft.Office.Server.Data.SqlSession.ExecuteReader(SqlCommand command, CommandBehavior behavior) at Microsoft.Office.Server.Administration.SharedObjectStore.GetObject[T]() at Microsoft.Office.Server.Administration.SharedResourceProvider.Microsoft.Office.Server.Administration.ISharedObjectStore.GetObject[T]() at Microsoft.Office.Server.Administration.SharedApplicationCollection`1.GetValue(SharedResourceProvider sharedResourceProvider) at Microsoft.Office.Server.Administration.SharedApplicationCollection`1.get_Item(SharedResourceProvider sharedResourceProvider) at Microsoft.Office.Server.ServerContext.GetApplication[S,T](String name) at Microsoft.Office.Server.Search.Administration.SearchContext..ctor(ServerContext serverContext, Boolean cached) at Microsoft.Office.Server.Search.Administration.SearchContext.GetContext(SharedResourceProvider sharedResourceProvider) at Microsoft.Office.Server.UserProfiles.SRPSite.SynchronizeManagedPropertyMappings() at Microsoft.Office.Server.UserProfiles.SRPSite._Init(ServerContext serverContext) at Microsoft.Office.Server.UserProfiles.SRPSite..ctor(ServerContext serverContext) at Microsoft.Office.Server.UserProfiles.UserProfileConfigManager..ctor(ServerContext serverContext) at Microsoft.Office.Server.UserProfiles.ContentDBSynchronizer.SynchContentDB() at Microsoft.Office.Server.Diagnostics.FirstChanceHandler.ExceptionFilter(Boolean fRethrowException, TryBlock tryBlock, FilterBlock filter, CatchBlock catchBlock, FinallyBlock finallyBlock)
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

These errors are related to profile synchronization issues. As WSS and MOSS has got different storage of User Profile data the "SYNC" job runs every 1 hour by default to synchronize data between the content databases. And Web Application stores these profile data. But for some entry in content databases of web application it still thinks that it has to open old SSP database. So now we have to clean the entries in following manner:

-Firtly get the GUIDs of all the web applications and content databases as thrown in the error long.
-Use this GUID to find the web application name because of which sync is going crazy. You can either use SharePoint Inspector or SharePoint Manager to find these details. Both can be downloaded from http://www.codeplex.com/spm and http://www.codeplex.com/spi
-Since I didn't prepared the web application's content database before changing the SSP hence all the issue started. So probably (I haven't tried yet) if we do this step before changing the association then we might not run into this situation. So now we have to fix the synchronization of content databases using "preparetomove" STSADM command. When the preparetomove operation is not run prior to moving the content database, synchronization can fail on a particular content database that has been moved to a new Web application. Synchronization is fixed for that content database by using this command. We will run this command for every web application and corresponding content database as follows:

stsadm -o preparetomove -site %WEBAPP% -oldcontentdb %GUID Of Content DB from Error Log%

-Once this command is run successfully we need to detach and reattach all the faulty content databases with their web applications again. You will do this by using "deletecontentdb" and "addcontentdb" STSADM commands as shown below:

stsadm -o deletecontentdb -url %WEBAPP% -databaseserver %DBSERVER% -databasename %DBNAME%
stsadm -o addcontentdb -url %WEBAPP% -databasename %DBNAME% -databaseserver %DBSERVER%

After doing this you can wait for next synchronization which occurs every hour by default or change the sync timing default value temporarily by using following command:

stsadm -o sync -synctiming "m:5" (This will run synchronization in every 5 minutes)

Wait for 5 minutes and check your error log. You will not see any reported errors.

Reset the sync timing back to default value of 1 hour
stsadm -o sync -synctiming "h:1"

Hopefully this will help you in resolving similar errors or issues.

Kunal

Change Default Index File Location

In a farm environment it will be usually a requirement to have the index file location on a separate drive and folder as opposed to the default location which is:

"C:\Program Files\Microsoft Office Servers\12.0\Data\Office Server\Applications"

You can set this path for an SSP by using the UI through Central Administration. But to set the default path for Office SharePoint Server Search Service and for WSS Search Service you will have to set the location through STSADM command.

Office SharePoint Server Search Service is configured using OSEARCH command:

If its not clear then read here:
stsadm -o osearch -defaultindexlocation e:\Data\MOSS_Search_Index

(By default, the search index will be located at this path on this server. For index servers, you can specify a different path when you create an SSP.

Note:
Changing the index location will reset the index. To move an index with a reset, use the noreset parameter of the Spsearchsensitive or Osearchsensitive operation)

Windows SharePoint Services Search Service is configured using SPSEARCH command:

If its not clear then read here:
stsadm -o spsearch -indexlocation e:\Data\MOSS_Search_Index

(Configures the search server that has the location of where the index resides)

You can also set this path for already created SSP using EDITSSP command:

If its not clear then read here:

stsadm -o editssp -title Sharedservices1 -indexlocation e:\Data\MOSS_Search_Index

(Configures the search server that has the location of where the index resides. This parameter is used in conjunction with the osearch operation. )

References:

SPSEARCH: http://technet.microsoft.com/en-us/library/cc288507.aspx

OSEARCH: http://technet.microsoft.com/en-us/library/cc262920.aspx

EDITSSP: http://technet.microsoft.com/en-us/library/cc262727.aspx