Thursday, September 8, 2011

SharePoint 2010 SP1 and June CU Upgrade issue #2 - Content type not found (Id: '0x0101000F1C8B9E0EB4BE489F09807B2C53288F0054AD6EF48B9F7B45A142F8173F171BD1')


If you upgrade SharePoint 2010 RTM to SP1 and June CU or any other CU, you might encounter error Feature upgrade incomplete for Feature - Content type not found (Id: '0x0101000F1C8B9E0EB4BE489F09807B2C53288F0054AD6EF48B9F7B45A142F8173F171BD1'). 

If you check the logs, there will be many errors indicating features related to publishing features such as PublishingLayouts and PublishingResources.

After debugging this, we have identified this is related to only sites migrated from 2007 with publishing features enabled. We had this issue during 2007 migration to 2010 as described in previous blog. Here are the tips and tricks to work around the issue.

1.       Issue summary - Content type not found during 2010 SP1 and June CU upgrade for sites migrated from 2007 with publishing features enabled

2.       Error in psconfig logs are listed below all point to 'PublishingResources' feature and publishing master page. Please check the ones highlighted in RED.
  
[PSCONFIG] [SPSiteWssSequence2] [INFO] [8/5/2011 11:32:51 AM]: SPSite Url=http://sandbox/sites/testsite
 [PSCONFIG] [SPSiteWssSequence2] [ERROR] [8/5/2011 11:32:51 AM]: Feature upgrade incomplete for Feature

'PublishingResources' (Id: 'aebc918d-b20f-4a11-a1db-9ed84d79c87e') in Site 'http://sandbox/sites/testsite'.

Exception: Content type not found (Id: '0x01004D5A79BAFA4A4576B79C56FF3D0D662D').
[PSCONFIG] [SPSiteWssSequence2] [INFO] [8/5/2011 11:32:51 AM]: SPSite Url= http://sandbox/sites/testsite
[PSCONFIG] [SPSiteWssSequence2] [ERROR] [8/5/2011 11:32:51 AM]: Feature upgrade incomplete for Feature

'PublishingResources' (Id: 'aebc918d-b20f-4a11-a1db-9ed84d79c87e') in Site 'http://sandbox/sites/testsite'.

Exception: Content type not found (Id: '0x01002CF74A4DAE39480396EEA7A4BA2BE5FB').
[PSCONFIG] [SPSiteWssSequence2] [INFO] [8/5/2011 11:32:51 AM]: SPSite Url=http://sbx04/sites/itlegal
[PSCONFIG] [SPSiteWssSequence2] [ERROR] [8/5/2011 11:32:51 AM]: Feature upgrade incomplete for Feature

'PublishingResources' (Id: 'aebc918d-b20f-4a11-a1db-9ed84d79c87e') in Site 'http://sandbox/sites/testsite'.

Exception: Specified argument was out of the range of valid values.
Parameter name: Content type not found (Id: '0x0101000F1C8B9E0EB4BE489F09807B2C53288F0054AD6EF48B9F7B45A142F8173F171BD1').
[PSCONFIG] [SPContentDatabaseSequence] [INFO] [8/5/2011 11:32:53 AM]: SPContentDatabase

Name= WSS_Content_test_sb
[PSCONFIG] [SPContentDatabaseSequence] [ERROR] [8/5/2011 11:32:53 AM]: Found a missing feature Id = [aeb3b47f-5d09-4c99-b563-02c746cc1aae]
[PSCONFIG] [SPContentDatabaseSequence] [INFO] [8/5/2011 11:32:53 AM]: SPContentDatabase

Name=WSS_Content_test_sb

[PSCONFIG] [SPSiteWssSequence2] [ERROR] [8/5/2011 11:39:36 AM]: Feature upgrade incomplete for Feature 


3.      Root cause for this issue.

 Please note the Content type with Id: '0x01004D5A79BAFA4A4576B79C56FF3D0D662D' is Publishing Master Page that is related to PublishingResources feature. We are not sure why this is causing the migration issue and it has been confirmed from Microsoft that some other people have similar issues on this. Since we had this issue before during 2007 to 2010 upgrade, we believe this is still related to deprecated or removed site templates in SharePoint 2010. The following site templates have been either deprecated or removed from 2010.

  • Wiki Site
  • Site Directory
  • Report Center
  • Search Center with Tabs
  • Search Center 
  • Collaboration Portal 
  • News Site 

The sites created from  Collaboration Portal that has publishing features enabled had some issues during 2007 to 2010 upgrade as we discovered. Other sites created from different 2007 template may have similar issue and we are not be able to identify the exact way to distinguish them.
 
4.       Workaround to resolve the issue after working with several co-workers my group.
a.       Deactivate the 'PublishingResources' feature
b.      Detach the content db
c.       Attach the content db
d.      Upgrade
e.      Activate the 'PublishingResources' feature


Now you have the workaround to resolve this issue during the upgrade. The question will be how we could identify the sites that will fail in upgrade?

Well, you could list all sites created from 2007 by creation date with 'PublishingResources' feature enabled. This may give you all potential sites that might fail in the upgrade. We are still working with Microsoft to see whether we could have easy way to identify those sites or final solution to fix this issue.

If you have better way to resolve this, please share with us.

Wednesday, September 7, 2011

SharePoint 2010 SP1 and June CU Upgrade issue #1 - WebPart class [baf5274e-a800-8dc3-96d0-0003d9405663] is referenced [16] times in the database


If you plan your SharePoint 2010 SP1 and June CU Upgrade, you may encounter some upgrade errors from  Test-SPContentDatabase script. One of the popular error in the Test-SPContentDatabase you may find after you setup new test environment is as follows.


Category                              : MissingWebPart
Error                                      : True
UpgradeBlocking              : False
Message                              : WebPart class [baf5274e-a800-8dc3-96d0-0003d9405663] is referenced [20] times in the database [WSS_Content_it_ems_dev], but is not installed on the current farm. Please install any feature/solution which contains this web part.

Remedy                               : One or more web parts are referenced in the database [WSS_Content_it_ems_dev], but are not installed on the current farm.  …


Category                              : MissingWebPart
Error                                      : True
UpgradeBlocking              : False
Message                              : WebPart class [07f48b68-2e69-c86a-ebe4-16359e03ebc2] (class [Microsoft.Office.Server.Search.WebControls.AdvancedSearchBox] from assembly Microsoft.Office.Server.Search, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c]) is referenced [1] times in the database [WSS_Content_it_ems_dev], but is not installed on the current farm. Please install any feature/solution which contains this web part.

Remedy                               : One or more web parts are referenced in the database [WSS_Content_it_ems_dev], but are not installed on the current farm. …


 Here are some ways to resolve these and deep dive on the issue.

1. The “simple” procedures to resolve most of these errors is described here.

a.     Open the following search center pages

b.    Open the search administration page by following this procedure if you get error to access searchfarmdashboard.aspx page.

c.    May need to iisreset/noforce and restart SharePoint 2010 Timer


2.  There are some other similar errors you need to be aware of. You could identify from the class name they are all from search package. Here is the list you could found from logs. Here is the list of the class you might have error.

Microsoft.SharePoint.Portal.WebControls.SearchBoxEx
Microsoft.Office.Server.Search.WebControls.SearchSummaryWebPart
Microsoft.Office.Server.Search.WebControls.RefinementWebPart
Microsoft.Office.Server.Search.WebControls.SearchStatsWebPart
Microsoft.Office.Server.Search.WebControls.CoreResultsWebPart
Microsoft.Office.Server.Search.WebControls.SearchPagingWebPart
Microsoft.Office.Server.Search.WebControls.QuerySuggestionsWebPart
Microsoft.Office.Server.Search.WebControls.FederatedResultsWebPart
Microsoft.Office.Server.Search.WebControls.HighConfidenceWebPart
Microsoft.Office.Server.Search.WebControls.TopFederatedResultsWebPart
Microsoft.SharePoint.Portal.WebControls.PeopleSearchBoxEx
Microsoft.Office.Server.Search.WebControls.PeopleRefinementWebPart
Microsoft.Office.Server.Search.WebControls.PeopleCoreResultsWebPart
Microsoft.Office.Server.Search.WebControls.AdvancedSearchBox

3.  Way to identify mis-match webparts using db query.
First, you could identify the features from 14 hive on all search related features and classes. 
Second, you could query the content database what webparts are installed. Here is the simple query.

SELECT *
FROM AllWebParts
WHERE tp_Class is NOT NULL


You could filtyer out the webparts based on class names.

I have tried the procedure and it indeed cleaned up almost all errors except one with WebPart class [baf5274e-a800-8dc3-96d0-0003d9405663].  
I'm not sure why other people were able to clean up even this one.

We will continue working this and keep you posted. Here are some reference I could find for your reference.


Thursday, August 25, 2011

Workaround to auto refresh RSS feed web part for SharePoint 2010 lists

If you have seen previous blog, you might know SharePoint 2010 RSS feed web part does not support AJAX asynchronous load as it should be. As a result,  you will not be able to setup to auto refresh the web part with the latest SharePoint list  feeds using AJAX options without IIS reset. 

This result has been acknowledged by Microsoft that it can be confusing to users if they try to use this option when  it does not perform this function one would expect. However, the RSS feed web part was not designed to provide this functionality so presently the issue in regards to a fix, is that the option is there in the first place. 

This is a workaround we tested it you could auto refresh the web part. The workaround is to setup the web part refresh (This is inherited from Date View web part) instead of AJAX asynchronous load. The result will be refresh through webpart refresh that is causing page refresh. You should see these options on the properties of the web part itself:



Now, you could adjust the refresh time to get the latest SharePoint list RSS feeds. The potential issue is the performance impact. This is NOT AJAX asynchronous load but a whole page refresh. If you have multiple BCS webparts,  multiple PSS feed webparts, you may run into performance issue. User experience might be impacted too.

Regrading the future enhancement or fix, here is the feedback from Microsoft. If the first then we can explore the best approach for dealing with the confusion in the option being present when it shouldn’t be. If the request is for the functionality to be added then this would be a design change request, as we are requesting new functionality. For this the product group would need a strong business reason as to why this functionality should be added in the context of a cumulative update. I can’t guarantee this can be done, it depends on a lot of factors, but if it’s something you feel strongly about pursuing we can certainly push forward the request.

Tuesday, August 23, 2011

SharePoint 2010 incoming e-mail does not start workflow on "create item" after upgraded from 2007


After SharePoint 2007 to 2010 for almost a year and some users reported an issue that incoming e-mail does not start workflow on "create item". After digging into the issue, we have identified that this is the same issue is happening on 2010 version.  

Since our upgraded was done using DB detach and attached approach, we have the new 2010 farm with all default settings. We were under impression that the previous issue reported that the email processing is running in the context of "System Account", SharePoint declarative workflow cannot be triggered by the system account should be resolved.

It turns out this issue still exists on 2010 RTM version for any declarative workflow. An example is any workflow created using SharePoint Designer.You still need to follow the following solution published here to enable SharePoint workflow for email enabled list.

Run “stsadm -o setproperty -pn declarativeworkflowautostartonemailenabled -pv true” on SharePoint 2010 even you have run on 2007. You could run the command "stsadm -o getproperty -pn declarativeworkflowautostartonemailenabled" first to verify the property value.

This is just one command we have missed during the SharePoint 2010 upgrade. Hope you remember this.


Tuesday, July 26, 2011

Options to block or exclude a security group to access some selected Sharepoint site collections - Part I

Our security department has identified some SharePoint 2010 site collections need to restrict to users of some security groups. The requirement is to restrict the users belong to some security groups to access selected site collections with sensitive information even these users have been granted the permission through individual account, any AD groups, or email list groups.

After extensive research and testing, we have found that there is no out of box solution on SharePoint 2010 we could exclude a security group to access some selected Sharepoint site collections. Here are some possible options I would recommend to try to resolve this issue.


1. Siteminder policy configuration to exclude any users belongs to selected groups to access the SharePoint site URL identified.

If you have already integrated the siteminder with SharePoint, you could modify the policy to restrict the groups to access site URLs. As long as you have the groups needed to be restricted and the site URLS, it should be a quick configuration changes.

Since you could provide the root URL and all sub sites will be blocked, the pros of this approach is clean and simple. The sites need to be controlled or protected can be in any webapp. Even users have been added to the SharePoint site, they will not be able to access the site. However, current version siteminder SSO does not support multiple domain AD SharePoint. We have more than FIVE AD domains in our company and it was NOT a solution at this time for us.


2. Configure ADFS Identity provider or other gateway such as Vordel to deny certain group of users to access selected URLs.

If you have implemented ADFS identity provider or other gateway tool such as Vordel to work with with SharePoint, you might work with the team to configure on ADFS or Vordel side to deny group of users to access certain selected sites. The pros and cons are same as described using siteminder.

Since we have identified many issues for SharePoint with ADFS, we have on hiod the SharePoint ADFS implementation early February 2011. ADFS approach is NOT a solution at this time for us. At same time, we are evaluate the Vordel approach and may move to this solution whenever it's available.


3. Configure IIS URLscan tool to block user agents for SharePoint sites

Microsoft strongly recommends that all users upgrade to Microsoft Internet Information Services (IIS) version 7.0 running on Microsoft Windows Server 2008. IIS 7.0 significantly increases Web infrastructure security.The URLScan tool can be used to protect your Web server from attacks and exploits. When a client requests a page from a Web server, it typically sends over some HTTP headers that contain additional information about the request. You mighht use the [DenyHeaders] section to restrict some user groups to access to certain SharePoint sites. You may refer to the discussion for more details.

Based on our observation, this approach may be useful but we may have difficult time to identify the method to filter the certain users. This may not the solution at this time for us.


4. Configure Microsoft Internet Security and Acceleration (ISA) to restrict access

In this session we will use ISA to accomplish this task to restrict the users belong to some security groups to access selected site collections. Here are the steps.

    * Create a security group and add users to that group
    * Create a new Firewall Policy and a Domain Name Set
    * Verify your Firewall rule and fine tune settings.

Please refer to Microsoft TechCenter on ISA for details.

Since this approach requires the additional ISA installation and lots of testing, it may not the solution at this time for us.

5. Configure user policy at web application level to deny them access to SharePoint sites inside the webapp.

If you do not have siteminder integrated with SharePoint, you may consider to group or migrate all sites need to be controlled or protected to a separate webapp. Then creating a user policy at web application level which denies them access to SharePoint. Here are the steps.

  •  Click Manage Web Applications
  •  Click the Web Application you wish to set a deny policy on
  •  Click User Policy in the Ribbon bar to display the Policy for Web Application dialog
  •  Click the Add Users link
  •  Leave the Zones prompt as (All Zones) and click Next to display the Add Users dialog
  •  Enter the AD group into the Users prompt
  •  Click the Deny All check box
  •  Click Finish
This is also very clean process and same as the previous approach the users will not be able to access the site even they have been added to the SharePoint site. This approach is extensible to add aaitional groups need to be blocked to the webapp. However,there are two major issues need to be planned for this approach.
  • You may need to migrate sites identified to be protected to the new webapp. This will break the URLs or bookmarks published to other applications. You may implement redirect or  alternate access mappings to minimize the impact.
  • You may change your site provisioning process so future sites need to be controlled will be provisioned inside controlled webapp.
This may be a good long term solution for us and we may plan to implement this approach.

6. Customize SharePoint access

You might intercept the out of box SharePoint authentication or authorization package to exclude the groups of users to access selected SahrePoint sites.  One suggestion provided by Allen Wang is to apply custom master page for this site collection and insert a custom user control near the top of the master page to perform security trimming, or check in the user control. If the user is in one of these group, then redirect it to another page or something....

You will see this might work for the users to access the site directly. However, it may not block users to access the files directly. This is not safe since the users could modify the master page or remove the code from the page.

7. Customize SharePoint Policy Feature

Since we could manage Information Management Policy in SharePoint Server 2010, I'm thinking whether we could implement a policy and apply the policy feature on the SharePoint site to exclude certain users. If anyone think this is feasible, please let me know.


As a result, none of the above options are perfect as we could see at this point. We are exploring other options in Part II and if you have any good suggestions, please let me know.

Thanks for your input.