We had an issue with MOSS 2007 and Kerberos during the implementation of a new application some weeks ago. Our application load several web parts on a MOSS2007 web-part page and each one of these web parts call to a different web service requesting data from an enterprise data storage. The page is a dashboard that display sales information to our executive team.
At the beginning we loaded the web parts in a synchronous way but after see the time taken by the page to load all the web parts (some web services returned a big number of rows) we decided to use asynchronous multithreads using ASP.NET.
But an strange error appeared then, two of the web parts were not loaded correctly the first time a user call to the page. They reported an error, when he refreshes the page one of them was loaded correctly and the other one not, and then if we refreshed the page again both of them were loaded correctly. The error didn’t appear again until any user call the page for 5 minutes, then the error appeared again for the first user to load it.
Event Viewer logs shown a Kerberos impersonation problem, when the error appeared the credential received by the destination server was Network Services one, instead of the User ID, so the impersonation was not working correctly.
After work with Microsoft for several days on the issue and didn’t find any logical explanation, we started to think the problem could be generated by the asynchronous call (I don’t know how to explain why… we were desperate I suppose so…).
Finally, the solution is to change some settings on ASPNet.config file (located in the Microsoft.Net folder) to the following values:
legacyImpresonationPolicy enabled
alwaysFlowImpresonationPolicy enabled
On the following links you can find the description of both entries but as a summary this is the values that they can have and the meaning of each one:
<legacyImpersonationPolicy enabled="true|false"/> http://msdn.microsoft.com/en-us/library/ms229296.aspx
| Value | Description |
| false | WindowsIdentity flows across asynchronous points depending upon the ExecutionContext flow settings for the current thread. |
| true | WindowsIdentity does not flow across asynchronous points, regardless of the ExecutionContext flow settings on the current thread. |
<alwaysFlowImpersonationPolicy enabled="true|false"/> http://msdn.microsoft.com/en-us/library/ms229553.aspx
| Value | Description |
| false | The Windows identity does not flow across asynchronous points, unless the impersonation is performed through managed methods such as Impersonate. |
| true | The Windows identity always flows across asynchronous points, regardless of how impersonation was performed. |
So to impersonate on a multithreading asynchronous scenario we have to apply the following values to these two entries:
<legacyImpresonationPolicy enabled=”false”/>
<alwaysFlowImpresonationPolicy enabled=”true”/>
One of the improvements included on the Service Pack 2 for MOSS 2007 to make our life more easy is the way to eliminate orphan items in our Content database.
Now, we have to follow these steps to clean up our database:
Run the following stsadm command
Stsadm –o enumallwebs –databasename <Content db name> -databaseserver <db server name>
It should show a result similar to that:
<Sites Count="1">
<Site Id="14f9385d-f543" OwnerLogin="domain\angelp" InSiteMap="False">
<Webs Count="10">
<Web Id="f5355528-6b02" Url="/" LanguageId="1033" TemplateName="STS#0" TemplateId="1" />
<Web Id="86d9b8e3-2287" Url="/Test" LanguageId="1033" TemplateName="STS#1" TemplateId="1" />
<Web Id="0d855bfe-b0ea" Url="/ClientD" LanguageId="1033" TemplateName="STS#1" TemplateId="1" />
<Web Id="1cb190f0-c8d1" Url="/Financials" LanguageId="1033" TemplateName="STS#1" TemplateId="1" />
<Web Id="c127df5a-865e" Url="/Toolkit" LanguageId="1033" TemplateName="STS#1" TemplateId="1" />
<Web Id="90281063-6224" Url="/Management" LanguageId="1033" TemplateName="STS#1" TemplateId="1" />
<Web Id="e84bcd49-1b5d" Url="/Client" LanguageId="1033" TemplateName="STS#1" TemplateId="1" />
<Web Id="12d77124-a53f" Url="/Reporting" LanguageId="1033" TemplateName="STS#1" TemplateId="1" />
<Web Id="d764935a-7d90" Url="/Container" LanguageId="1033" TemplateName="STS#1" TemplateId="1" />
<Web Id="cbd1e30d-69ef" Url="/Testing" LanguageId="1033" TemplateName="STS#1" TemplateId="1" />
</Webs>
</Site>
</Sites>
And then you have to run the deletesite command for all webs where InSiteMap is equal to False:
Stsadm –o deletesite –force –siteid < site id> -databaseserver <db server name> -databasename <Content db name>
On the above example:
Stsadm –o deletesite –force –siteid 14f9385d-f543 –databaseserver myServer –databasename myDB_Content
And anymore steps are needed. However, It seems that enumallwebs command output only locates Content db orphans, not Config db orphans. Which is OK, because Content db orphans are more common and much more difficult to delete. In order to eliminate the Config db orphans, you still need to detach/attach the content db as I explained on “MOSS 2007 and Orphan objects – Part II” post.
Today, a user has reported a problem executing a search in a MOSS environment, it seems that the documents uploaded during the last days were not displayed on the search results. Checking the Manage Content Sources on MOSS SSP site we could checked that an incremental crawl was running for more than 1000 hours. Evidently the crawl was hand on.
The solution was very simple: to stop the crawl (index is deleted by default), to reset all crawled content and then to run a Full Crawl (we don’t have many documents and the site content can be crawled in less than 30 minutes). But when we tried to stop the crawl (we have tried both methods from the Manage Content Sources page and running net stop osearch command), it has not been stopped and when we tried to access to some “crawling” pages like “Content Sources”, “Crawl Rules”, or “Reset all Crawled Content” we receive the same error page:
We have found many “tips” on internet about how to solve this issue but all of them looked like a little radical (delete some Registry entries, stop the Search service on Admin console uninstalling the service on the environment, etc…) so we have decided to try to fix it with a more simple solution:
We have stopped IIS service, open Task Manager console, go to Process tab and delete the two mssearch.exe process running on the server:
Then we have tried to access to all “crawling” pages on SSP site and we could do it without problem. We have reset all crawled content and ran a Full Crawl from Content Sources page and 20 minutes after, the crawl was completed and all documents were displayed on search results.
Sometimes the simplest option is the best one…
Some developers have reported to us this error when they try to publish a new InfoPath template to some of our MOSS 2007 farms. After research on it and try several ways to solve it I think that we have fixed the problem.
If you googling on the net for this error you will find many blogs talking about several ways to solve it making some changes on the server: stop the System Event Notification service, delete SSP and create a new one, if you are using SPS 2003, uninstall .NET 2.0,… etc. Some of them (like the one related to SSP or the .NET 2.0 solution) I can’t understand how they can solve the issue, but in any case if you apply them it is possible that they started a lot of others errors and issues.
A good point to start is to check if your farm has a site in the root. If in your farm all the sites are created under a virtual path such as “/sites/”, InfoPath can’t publish. The best way to do it is trying to access to the root site typing in your Internet Explorer a URL similar to that: https:\\myMossFarm.accenture.com\
If the root site exists, a team site will be displayed (after you enter your credentials and if you are an administrator or have rights to view it). If the site doesn’t appears, you have to request to your administrator to create a root site on the farm following these steps:
If some developers still receiving the same error, you can try to execute these steps on the developer machine:
I would like to finish these series about Orphan objects in MOSS 2007 talking about two considerations that could be very important that you keep in mind when you are “fighting” with orphan objects and your farm is in one of the cases described below.
Considerations if you are working with a mySite farm
If you are working with a mySite farm or any other farm with a big number of top level sites where you can find hundred of orphan objects, it is better that you execute the following steps to clean it:
Considerations if the Infrastructure Update is not installed on your farm
If your farm has not been upgraded to the Infrastructure Update you have to take into account to execute the following command before to detach the Content DB:
Stsadm –o preparetomove –contentdb <myContentDB> -site <mysiteURL>
This is very important because if you didn’t run this command the Content db would be assigned a new GUI when reattached.
To check if the IU is installed on your farm, from Central Administration site go to Operations > Servers in Farm. In this page you will see the Database Schema Version in the top of the screen and a list of servers with the version numbers listed in the relevant column against each server in the farm.
You can also see the database schema version in Site Settings, Modify All Site Settings in the Site Information section. Or you can look the MOSS configuration database (SQL Server) of your site collection and open the Versions table, there will be entries in this table with the versions that have been applied to in your farm and the date when the Service Pack, hot fix or Rollup was applied.
The version corresponding for the IU upgrade is 12.0.0.6318, if your farm is in this version or above you don’t need to execute the Preparetomove command and you can forget about this consideration section.
If the commands described on the first part of this post could not clean the orphan objects on your farm, means that your farm has “deep” orphan objects and you need to execute other series of steps before to execute the upgrade.
The best way to detect the deep orphan objects is to run the following SQL script on the SQL server that host the databases of your farm. The script is not mine and you can find it on the SharePoint Tips & Tricks blog of Microsoft TechNet site, as its author said you will execute the script at your own risk. I have executed it in several production environments where we have orphan objects and I have never had any problem.
You just need to copy and paste the following code on a Query window with read access to all databases and change the database name (in green) with the one of your Config database.
Use MSDB
Drop table orphanlist
CREATE TABLE [dbo].[orphanlist](
[farm] [varchar](250) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
[databasename] [varchar](250) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
[SiteID] [uniqueidentifier] NULL,
[sitepath] [varchar](250) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
[type] [varchar](250) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
)
drop table orphan_hopper
declare
@dbname as varchar(250),
@cmdstr as varchar(2000),
@dbid as varchar(250),
@configdb as varchar(250)
/** only change the following line and nothing else, change spskills_config_db to your config db name **/
select @configdb = 'MyConfigDB_MOSS'
/** Change nothing below this line **/
select @cmdstr =
'select distinct b.name as ''databasename'', b.id as ''dbid'' into orphan_hopper
from
[' + @configdb + '].dbo.sitemap as a inner join
[' + @configdb + '].dbo.objects as b on a.databaseid=b.id inner join
[' + @configdb + '].dbo.objects as c on c.id=a.applicationid inner join
[' + @configdb + '].dbo.objects as d on b.parentid=d.id inner join
[' + @configdb + '].dbo.objects as e on d.parentid=e.id '
exec (@cmdstr)
DECLARE DBCursor CURSOR For
Select databasename, dbid
From orphan_hopper
OPEN DBCursor
FETCH NEXT FROM DBCursor into @DBName, @dbid
WHILE @@FETCH_STATUS =0
BEGIN
INSERT INTO orphanlist([Type], farm, databasename,[sitepath], SiteID)
EXEC
('
select ''Potential ConfigDB orphan:'' + '''+@dbname+''' as [Type], '''+@configdb+''' as [farm], '''+@dbname+''' as [databasename],path as [sitepath], id as [SiteID] from ['+@configdb+'].dbo.sitemap where id not in (select id from ['+@dbname+'].dbo.sites) and databaseid = '''+@dbid+'''
union
select ''Potential ConfigDB orphan:'' + '''+@dbname+''' as [Type], '''+@configdb+''' as [farm], '''+@dbname+''' as [databasename],path as [sitepath], id as [SiteID] from ['+@configdb+'].dbo.sitemap where id not in (select siteid from ['+@dbname+'].dbo.webs where parentwebid is null) and databaseid = '''+@dbid+'''
union
select ''Potential ContentDB orphans:'' + '''+@dbname+''' as [Type], '''+@configdb+''' as [farm], '''+@dbname+''' as [databasename],fullurl as [sitepath], siteid as [SiteID] from ['+@dbname+'].dbo.webs where parentwebid is null and siteid not in (select id from ['+@configdb+'].dbo.sitemap where databaseid = '''+@dbid+''')
union
select ''Potential ContentDB orphan:'' + '''+@dbname+''' as [Type], '''+@configdb+''' as [farm], '''+@dbname+''' as [databasename],fullurl as [sitepath], siteid as [SiteID] from ['+@dbname+'].dbo.webs where parentwebid is null and siteid not in (select id from ['+@dbname+'].dbo.sites)
')
FETCH NEXT FROM DBCursor into @DBName, @dbid
END
CLOSE DBCursor
DEALLOCATE DBCursor
select * from orphanlist
This script will report a list of orphan objects found. On the screenshot /sites/myMOSS is the orphan found by SQL script:
The best way to clean this orphan site would be detach and attach the Content database to our farm, but this could eliminate our orphan site and in this case we suppose that we need to conserve it. I mean, myMOSS site is a site that we are using at this moment and we want to use it in the future, and for any reason that we don’t know it appears as orphan (the info related to this site on our Content and Config databases not concur).
In this case the best way is to make a backup of the site and restore it when we finish the detach/attach process, so the steps to execute would be the following:
Backup orphan object
Stsadm –o backup –url <mysiteURL> -filename <path/filename.dat>
Delete orphan object
Stsadm –o deletesite –url <mysiteURL>
Detach/Attach Content DB
You can detach/attach the Content DB following two different ways: from SharePoint Central Administration site or from command line using the stsadm command.
Central Administration site
Open the Administrator site and go to Central Administration > Application Management > Content Databases > Manage Content Databases. Ensure the correct site is selected in Web Application and click on Database Name to open the properties page. At the bottom of the page select Remove Content Database option and click OK.
Now the database is not associated with the farm but it has not been deleted from the database server.
To attach it again, go to Central Administration > Application Management > Content Databases > Manage Content Databases, click on Add a content database button, fill the form with the correct information (database server, database name, etc.) and click Ok.
Using STSADM command
To detach the Content database execute the following command:
Stsadm –o deletecontentdb –url <mysiteURL> -databasename <myContentDB>
To attach it again execute this one:
Stsadm –o addcontentdb –url <mysiteURL> -databasename <myContentDB>
Restore the site
Stsadm –o restore –url <mysiteURL> -filename <path/filename.dat>
Now your farm is free of orphan objects (surface and deep ones) and you can proceed with the farm upgrade.
Please, review the third part (and last one) of this post to take into account some considerations related to Orphan objects in MOSS.
Orphans are the objects in a SharePoint schema that live without a parent or child relationship in the database. This database inconsistencies can be created due to many different reasons, for example, if you are creating a new site and click back, or close the window in mid creation, or when you are deleting a site and stop the process in the middle, etc., etc., etc. In any case these orphan objects could be a real problem when you need to upgrade your farm installing a hotfix or a service pack. The majority of issues produced during an upgrade process are due to one or more orphan objects in the database, so it is a good practice to check and clean all orphan objects in your farm before to implement the upgrade.
As a Best Practice you should clean the old sync information in your MOSS databases periodically executing the following commands:
Stsadm –o sync –listolddatabases 2
Where 2 is the number of days old the sync info is. If it is more than a few days old it is probably orphaned. If you receive any result means that you have old sync info in your databases so you have to run this other command to delete it:
Stsadm –o sync –deleteolddatabases 2
Before to execute an update on your farm (a hotfix or service pack installation) you have to run the following commands to detect if any orphan object exist:
Stsadm –o databaserepair –url <mysiteURL> -databasename <myContentDB>
If any object is listed by this command, your farm is right and you don’t have any orphan object, you can proceed with your upgrade. If the command lists any object it means that this object is an orphan one, so you should execute the following one to delete all of these objects on the farm:
Stsadm –o databaserepair –url <mysiteURL> -databasename <myContentDB> –deletecorruption
The best way to ensure that the last command has ran fine and deleted all the orphans is to execute the first one again and ensure that any object is listed now. If any object is listed your farm is clean and you can proceed with the upgrade, in other case it means that the orphan objects are deeper and you have to jump to the second part of this post to learn how to detect and clean the deep orphan objects.
Today, Microsoft has announced that SharePoint Designer 2007 is available as a free download. On this way they want to put the tool in the hands of more people and promote the SharePoint 2007 customization.
From this link you can see a letter to Designer customers and the link to download the software for free.
Enjoy it!!!
Sometimes when we are working in a new environment and we have to talk with application teams to define the requirements and explain them the components that we have to implement, it is difficult to explain what Shared Services Provider (SSP) is and why it is very important for a MOSS environment. Some customers confuse this site with the Administration one that is generated by MOSS installation process on the first node, and don’t understand why this site exist in both web front end servers (if you are implementing a Load Balancer environment with SSP running on them).
The idea of SSP is to group certain services that really make sense to centrally manage and share between all web applications running on your farm. A good example is the profiles. With a SSP you can download them from AD once and then serve this information to your web applications; if I have two applications on my farm, https:\\Facilities and https:\\Finance, it doesn’t make sense that each application connect with AD independently and download the profiles…, they should share.
Some of the services shared on the SSP are:
As a general rule you need just one SSP on your farm (including just one on your company), but MOSS enables you the ability to create more than one if you want. Why could you need more than one SSP? The most common scenario is the Intranet/Extranet one. Maybe your MOSS farm hosts two primary web applications, one for your employees and other one for your customers. You probably want separate search and profiles because you don’t want to share this kind of information between both audiences. This could be a good reason to use more than one SSP: You want not share information between your applications.
Other advantage of SSP is that you can separate administration roles. For example, it is very common to have one group administrating physical server farm and other to manage and maintain the search, or to work with the audiences. As SSP run in a separate site than Administration site you can grant access to some people to the SSP site but not to the admin one. Once inside the SSP you can limit their access too; you can determine if they can:
Do you need more reasons to justify the use of SSP?
