Friday, October 17, 2008

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

Wednesday, October 8, 2008

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

Tuesday, October 7, 2008

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:

Tuesday, September 30, 2008

Event ID 6482,7076,6398,27745

For past few days I have noticed errors in my event logs on the MOSS server. The errors were related to event ids 6482,7076,6398,27745. The description was:

Event Type: ErrorEvent Source: Windows SharePoint Services 3Event Category: General Event ID: 27745Date: 30/09/2008Time: 3:23:52 AMUser: N/AComputer: AUYXUAP310WBC32Description:The description for Event ID ( 27745 ) in Source ( Windows SharePoint Services 3 ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: #50071: Unable to connect to the database SharePoint_Config on SharePointSQLServer_Dev. Check the database connection information and make sure that the database server is running..

Event Type: ErrorEvent Source: Windows SharePoint Services 3Event Category: Timer Event ID: 6398Date: 30/09/2008Time: 3:23:52 AMUser: N/AComputer: AUYXUAP310WBC32Description:The Execute method of job definition Microsoft.Office.Server.Administration.ApplicationServerAdministrationServiceJob (ID 4dbd717a-6f8a-4595-8d03-6e21a6551257) threw an exception. More information is included below.
Not enough storage is available to complete this operation.

And similar errors regarding insufficient memory. There are many other suggestions on web but the one that fixed the errors for me was:

-For errors related to Event IDs 6482,7076,6398, I have to install hotfix 923028 available here:http://support.microsoft.com/kb/923028

-For error related to Event ID 27745, I have to stop and start the Windows SharePoint Services Timer service with following command:

net stop “Windows SharePoint Services Timer”
net start “Windows SharePoint Services Timer”

Saturday, September 27, 2008

Error When starting Windows SharePoint Search service

Last week I got stuck with few errors when starting WSS Search Service. Below are few errors that were thrown:



Error1:
Event ID: 10036
A database error occurred.
Source: Microsoft OLE DB Provider for SQL Server
Code: 6 occurred 1 time(s)
Description: [DBNETLIB][ConnectionOpen (Connect()).]Specified SQL server not found.

Error2:
Error Description: Could not access the Search service configuration database.


Few tips to avoid this kind of error:


  • Make sure the search service account has got DBCreator role on DB server. You can remove this role once the service is started.

  • Offcourse your normal Farm Admin service account also needs DbCreator and SecurityAdmin role.

  • I have read someone saying to use Named Pipes for remote connection. But this is not true it should work with TCP/IP connection as well. So in your SQL server make sure that your remote connection is enabled for either TCP/IP or Named Pipes or for both.

  • Make sure the DB Server name in your connection string is consistent in your farm for all other webapps, admin content config database etc etc..

  • Finally the solution that worked for me was that I was using "DB server name\Instance, port" as the connection string and this format of connection string uses Named Pipes. Unfortunately Named Pipes was disabled so I have to use an Alias of the DB server to use the TCP/IP connection. Also once the alias is setup for you by the DBA's you have to set it up on the MOSS server under SQL Server Client Configuration settings. You can also use server name if you are using default instance for TCP/IP.

I hope that makes sense. If anybody has any more suggestions or corrections to my suggestions then please do leave a comment.

Cheers,

Kunal

SharePoint Capacity Planning Tool

Not sure if some of you have already come across this tool. So instead of reading the whole capacity-planning documentation, you can get a rough idea of your hardware needs and farm topology design. Just enter information such as the number of users, locations, bandwidth and network topology, preferred hardware, and usage profiles. After you provide the tool with basic information about your organization, the tool provides a first approximation of the topology your organization needs.

Good tool for infrastructre guys!

Download Here or follow the link:

http://www.microsoft.com/downloadS/details.aspx?familyid=DBEE0227-D4F7-48F8-85F0-E71493B2FD87&displaylang=en

Sunday, September 14, 2008

Create Databases before deploying MOSS

In many organizatons there are certain policies and procedures where only DBA's can create databases. Now when installing MOSS 2007, the install creates the databases automatically that means they need to give the service account permissions to create database on DB server. This kind of breaks the organizational policy. Do you agree guys? No? Yes? Anyways these are the policies set by organization and we have to abide by them. So what do we do in these situations? Luckily there is a procedure where we can deploy MOSS using DBA-created databases. TechNet provides us with steps where DBA's can create databases on DB servers and Farm Administrators can configure them separately. Have a look at this TechNet article:

http://technet.microsoft.com/en-us/library/cc262869.aspx
Dogpile
Powered By Blogger