Tips to resolve issue that site owners are able to delete site templates or sandbox solutions before 2011 Dec. CU

If you are using sandbox solution you might be aware of that on SharePoint RTM version, site owners are able to delete site templates or sandbox solutions from solution gallery without deactivating them on load balanced multiple tier environment through edit item as we described before.

This issue supposed to be resolved in 2011 Dec. CU. After we applied 2012 Feb. CU, this issue indeed has been resolved on any new created site collections. Even though the delete option is still available in the ribbon, when site owners try to delete site templates or sandbox solutions from solution gallery without deactivating it, there will be an error message. 

However, this issue is still on the existing site collections created previous the CU. We finally identified the root cause and the way to fix it.

The root cause is the existing the sites created before Feb CU are missing two event receivers on Site Collection “Solution Gallery” list. The two missing event receivers are ItemUpdating and ItemDeleting. You could use the following powershell command to list the event receivers on the Site Collection “Solution Gallery” list for the site collection.

$web = get-spweb http://AffectedSiteName

$sg = $web.lists[“Solution Gallery”]

$sg.eventReceivers | out-file c:\ev.txt

The result for the site collection created after Feb CU has listed below. Please note the two highlighted receivers in RED that are missing on site collection created before the CU.

Id                              : c655b849-6f3f-4d95-a476-ef805a43f13c
Name                        :
SiteId                        : 59682d29-9241-468c-8d73-93b6e74c7a45
WebId                       : 8e1c6b34-9434-4c4d-9ca7-b057f0fd5983
HostId                       : 40187fd3-0178-46f7-b89e-233b7e83a739
HostType                  : List
ParentHostId            : 00000000-0000-0000-0000-000000000000
ParentHostType        : Site
Synchronization        : Synchronous
Type                          : ItemAdding
SequenceNumber      : 10000
Assembly                   : Microsoft.Office.Access.Server.Application, Version=14.0.0.0, Culture=neutral, PublicKeyT          oken=71e9bce111e9429c
Class                          : Microsoft.Office.Access.Server.Template.SolutionGalleryEventReceiver
Data                           :
Filter                          :
Credential                  : 0
ContextItemId           : 0
ContextItemUrl         :
ContextType              : 00000000-0000-0000-0000-000000000000
ContextEventType     : 00000000-0000-0000-0000-000000000000
ContextId                   : 00000000-0000-0000-0000-000000000000
ContextObjectId        : 00000000-0000-0000-0000-000000000000
ContextCollectionId  : 00000000-0000-0000-0000-000000000000
UpgradedPersistedProperties :

Id                               : 6d505269-a988-46b5-aea1-62f15927714f
Name                         :
SiteId                         : 59682d29-9241-468c-8d73-93b6e74c7a45
WebId                        : 8e1c6b34-9434-4c4d-9ca7-b057f0fd5983
HostId                       : 40187fd3-0178-46f7-b89e-233b7e83a739
HostType                  : List
ParentHostId             : 00000000-0000-0000-0000-000000000000
ParentHostType        : Site
Synchronization       : Synchronous
Type                         : ItemUpdating
SequenceNumber     : 10000
Assembly                 : Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c
Class                       : Microsoft.SharePoint.SolutionGalleryEventReceiver
Data                        :
Filter                      :
Credential                  : 0
ContextItemId               : 0
ContextItemUrl              :
ContextType                 : 00000000-0000-0000-0000-000000000000
ContextEventType            : 00000000-0000-0000-0000-000000000000
ContextId                   : 00000000-0000-0000-0000-000000000000
ContextObjectId             : 00000000-0000-0000-0000-000000000000
ContextCollectionId         : 00000000-0000-0000-0000-000000000000
UpgradedPersistedProperties :

Id                          : 099a4e0c-1e76-46ce-8c3c-549968535658
Name                        :
SiteId                      : 59682d29-9241-468c-8d73-93b6e74c7a45
WebId                       : 8e1c6b34-9434-4c4d-9ca7-b057f0fd5983
HostId                      : 40187fd3-0178-46f7-b89e-233b7e83a739
HostType                    : List
ParentHostId                : 00000000-0000-0000-0000-000000000000
ParentHostType              : Site
Synchronization             : Synchronous
Type                        : ItemDeleting
SequenceNumber              : 10000
Assembly                    : Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c
Class                       : Microsoft.SharePoint.SolutionGalleryEventReceiver
Data                        :
Filter                      :
Credential                  : 0
ContextItemId               : 0
ContextItemUrl              :
ContextType                 : 00000000-0000-0000-0000-000000000000
ContextEventType            : 00000000-0000-0000-0000-000000000000
ContextId                   : 00000000-0000-0000-0000-000000000000
ContextObjectId             : 00000000-0000-0000-0000-000000000000
ContextCollectionId         : 00000000-0000-0000-0000-000000000000
UpgradedPersistedProperties :

Id                          : 7cd2ee61-7a30-4956-9f6c-3ea10c6c4be9
Name                        :
SiteId                      : 59682d29-9241-468c-8d73-93b6e74c7a45
WebId                       : 8e1c6b34-9434-4c4d-9ca7-b057f0fd5983
HostId                      : 40187fd3-0178-46f7-b89e-233b7e83a739
HostType                    : List
ParentHostId                : 00000000-0000-0000-0000-000000000000
ParentHostType              : Site
Synchronization             : Synchronous
Type                        : ItemAdded
SequenceNumber              : 10000
Assembly                    : Microsoft.Office.Access.Server.Application, Version=14.0.0.0, Culture=neutral, PublicKeyT
                              oken=71e9bce111e9429c
Class                       : Microsoft.Office.Access.Server.Template.SolutionGalleryEventReceiver
Data                        :
Filter                      :
Credential                  : 0
ContextItemId               : 0
ContextItemUrl              :
ContextType                 : 00000000-0000-0000-0000-000000000000
ContextEventType            : 00000000-0000-0000-0000-000000000000
ContextId                   : 00000000-0000-0000-0000-000000000000
ContextObjectId             : 00000000-0000-0000-0000-000000000000
ContextCollectionId         : 00000000-0000-0000-0000-000000000000
UpgradedPersistedProperties :

Well, you might have the idea to fix this issue on any site collections that are having this issue. The solution is to add back the two missing event receivers are ItemUpdating and ItemDeleting to on the Site Collection “Solution Gallery” list. Here is the powershell command you could use.

$web = get-spweb http://siteCollectionName

$sg = $web.lists[“solution gallery”]

$sg.EventReceivers.Add("ItemDeleting", "Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c", "Microsoft.SharePoint.SolutionGalleryEventReceiver")

$sg.EventReceivers.Add("ItemUpdating", "Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c", "Microsoft.SharePoint.SolutionGalleryEventReceiver")

$web.update()

Now, site owners are NOT able to delete site templates or sandbox solutions from solution gallery without deactivating them on load balanced multiple tier environment through edit item!

How to remove the duplicated Document ID after 2012 Feb CU upgrade?

2012 Feb CU release note indicted to fix the duplicated IDs issue.  This is the fix for any new document IDs.
The question to us is how we could the existing duplicated document IDs on the existing sites?

We have tried to the following procedures but none of them seem to work. See previous blog for details.

1. Deactivate/reactive “Document ID Service” site collection feature
2. “Reset all Document IDs in this Site Collection to begin with these characters” from Set Actions->Site Settings->Site Collection Adminstration->Document ID settings
3. Run two timer jobs named “Document ID enable/disable job” and “Document ID assignment job” for the webapp

If there is out of box procedure we could remove the entire document ID on the site and then regenerate for them again, it should get rid of the duplicates. At this time, we are generate the report to list all the duplicate document IDs and we may have to try to reset those IDs using APIs.

If anyone have any better way to remove the duplicated Document ID after 2012 Feb CU upgrade, please let me know.

How to debug and resolve CanUpgrade [SPConfigurationDatabase] failed issue

We have run into the following error several times and it’s a good time to record the solution.

In one of DEV SharePoint development box today, when we deploy solution and the solution was stay in deploying status. We also received timer job error and we are not able to deploy any solution. The log shows the following error.

04/18/2012 12:50:05.63 OWSTIMER.EXE (0x0494)                              0x27BC SharePoint Foundation                 Upgrade                                       fbv7       Unexpected       [OWSTIMER] [SPUpgradeSession] [ERROR] 

[4/18/2012 12:50:05 PM]: CanUpgrade [SPConfigurationDatabase] failed.          

04/18/2012 12:50:05.63 OWSTIMER.EXE (0x0494)                              0x27BC SharePoint Foundation                 Upgrade                                       fbv7       Unexpected       [OWSTIMER] [SPUpgradeSession] [ERROR] 

[4/18/2012 12:50:05 PM]: Inner Exception: The type initializer for 'System.Data.SqlClient.SqlConnectionFactory' threw an exception.    

04/18/2012 12:50:05.63 OWSTIMER.EXE (0x0494)                              0x27BC SharePoint Foundation                 Upgrade                                       fbv7       Unexpected       [OWSTIMER] [SPUpgradeSession] [ERROR] 

[4/18/2012 12:50:05 PM]:    at System.Data.SqlClient.SqlConnection..cctor()    

04/18/2012 12:50:05.63 OWSTIMER.EXE (0x0494)                              0x27BC SharePoint Foundation                 Upgrade                                       fbv7       Unexpected       [OWSTIMER] [SPUpgradeSession] [ERROR] 

[4/18/2012 12:50:05 PM]: Exception: The type initializer for 'System.Data.SqlClient.SqlConnection' threw an exception.              

… <Some error skipped here>

04/18/2012 12:50:05.63 OWSTIMER.EXE (0x0494)                              0x27BC SharePoint Foundation                 Timer                                         7v43       Medium               An error occured while initializing the timer.       

04/18/2012 12:50:05.63 OWSTIMER.EXE (0x0494)                              0x27BC SharePoint Foundation                 Timer                                         5utx       Unexpected       The timer service could not initialize its configuration, please check the configuration database.  Will retry later.

The error seems to indicate the upgrade and is very misleading. After debugging on the issue again, we realized this was the same issue we had before. The real error is in the application event log the DB is FULL. Here are two errors from SharePoint application event logs.

Now, it’s very clear that database is exceeding the limit. You could go to the location (our case is E:\SQL\Data) to review which DB is causing this issue. It’s as always the user profile sync application as in the following screen shot.

The solution is to shrink the DB and you will resolve the issue.

“Reset all Document IDs in this Site Collection to begin with these characters” does not seem to work on 2010 SP1 + June CU

SharePoint 2010 has introduced an excellent out-of-the-box feature that allows you to automatically assign a unique document ID to all of your documents that are uploaded to your SharePoint site. This site-collection scoped feature is designed the document IDs are guaranteed to be unique across the site collection that the feature has been activated for. The major use case to use this feature is all document ID on one site collection can have a common prefix and we could have a short URL to access the documents. One example to access the document is http://sbx01/sites/harry/_layouts/DocIdRedir.aspx?ID=ZHMD6RZVPS52-3-2.

This seems like an excellent feature if the uniqueness is true. However, the issue is there are several bugs on 2010 SP1 + June CU and the IDs are not guaranteed to be unique. You could reproduce the duplicated document ID issues through save template or content organizer. We are upgrading to 2012 Feb CU that supposed to fix the duplicated IDs issue. There is no surprise that it does not fix the existing duplicated document IDs. The major reason is “Reset all Document IDs in this Site Collection to begin with these characters” failed on several environment after Feb CU upgrade. We have several people reported similar issues.

Here is the procedure to reproduce the issue.

1. Active “Document ID Service” site collection feature
2. Add column “Document ID” to the list library
3. Add item and you will see Document IDs 

4. “Reset all Document IDs in this Site Collection to begin with these characters” from Set Actions->Site Settings->Site Collection Adminstration->Document ID settings

5. Run two timer jobs named “DocumentID enable/disable job” and “Document ID assignment job” for the webapp
6. De-active/Active “Document ID Service” site collection feature
7. Column “Document ID” values on the list libraries not updated
8. New list may not have “Document ID” assigned

Our original thought is to remove and reset the document ID on the site with duplicated IDs, then regenerate the IDs for all the document on 2012 Feb CU. This way it should have all unique IDs. Since this is not working as we expected, we are not able to fix the existing duplicated document IDs. If anyone find any workaround or solution, please let us know.

Thanks.

Workaround to remove orphan components when site owners delete site templates or sandbox solutions from solution gallery without deactivating them

If you are using sandbox solution or saved site template on SharePoint 2010, you will noticed those solutions will be uploaded into solution gallery. If you have not upgraded to 2011 December CU and you are on load balanced multiple tier environment (example is two WFS and one application server), site owners are able to delete site templates or sandbox solutions from solution gallery without deactivating them through edit page. Those site templates or sandbox solutions will become orphan and users will still be able to see them in site creation template. Of cause, users will get error if they want to create ant site from these orphan templates. You could refer my previous blog for details.

In this blog, I will use save site template as example to explain how we could workaround and clean up those orphan sandbox solutions. Before we explain the clean up procedure, let us identify what will be added into content database after we activate the sandbox solution and what would be cleaned up automatically if we deactivate and then delete the solution. I’m using two saved templates ITDebug.wsp that saved form out of box team site for the testing.

First, we will identify what happened inside content database if we upload, activate, deactivate, and delete the solution ITDebug.wsp in single SharePoint server farm.

• Upload the ITDebug.wsp, there is no entry in dbo.Feature or dbc.Solutions tables.
• Activate the ITDebug.wsp, you will see ONE additional feature entry in dbo.Feature and ONE additional entry in dbc.Solutions table
• Deactivate ITDebug.wsp, there is no entry in dbo.Feature or dbc.Solutions tables for this saved template. Both are cleaned up
• Remove ITDebug.wsp, the file is removed from the solution gallery

 

Here is the solution gallery screen shot after ITDebug.wsp solution activated.

Here is the one entry inside table dbc.Solutions with name ITDebug.wsp.

Here is the screen shot for entry inside table dbo.Feature for ITDebug.wsp solution.

Here is the SQL script to get the entry. Please note the content database for testing site http://sbx08:3797/sites/Orphan is WSS_Content_TEST_ORPHAN. You could identify the database name from central admin when you view the site or from ‘stsadm -o enumsites’ command.

SELECT [WSS_Content_TEST_ORPHAN].[dbo].[Features].[SiteId]

      ,[WSS_Content_TEST_ORPHAN].[dbo].[Features].[FeatureId]

      ,[WSS_Content_TEST_ORPHAN].[dbo].[Features].[SolutionId]

      ,[WSS_Content_TEST_ORPHAN].[dbo].[Solutions].[Name]

  FROM [WSS_Content_TEST_ORPHAN].[dbo].[Features] INNER JOIN [WSS_Content_TEST_ORPHAN].[dbo].[Solutions]

  ON [WSS_Content_TEST_ORPHAN].[dbo].[Features].[SolutionId] = [WSS_Content_TEST_ORPHAN].[dbo].[Solutions].[SolutionId]

 

Second, we will identify what happened inside content database if we upload, activate, delete without deactivating the solution ITDebug.wsp in multiple SharePoint server farm.

• Upload the ITDebug.wsp, there is no entry in dbo.Feature or dbc.Solutions tables. This is same as before.
• Activate the ITDebug.wsp, you will see ONE additional feature entry in dbo.Feature and ONE additional entry in dbc.Solutions table. This is same as before.
• Delete ITDebug.wsp without deactivating it,  both entries inside dbo.Feature and dbc.Solutions table are still there!!!  These are orphan entries.

You could use the following SQL script to identify the orphan solutions. Please replace the content database name with yours.

SELECT [Content_DBNAME].[dbo].[Solutions].[Name]

  FROM [Content_DBNAME].[dbo].[Solutions] INNER JOIN [Content_DBNAME].[dbo].[Features]

  ON [Content_DBNAME].[dbo].[Features].[SolutionId] != [Content_DBNAME].[dbo].[Solutions].[SolutionId]

Now it's time to describe the workaround to cleanup those orphan components. As you see we need to clean up two entries, one inside feature table and another inside Solutions table. Here is the procedures.

1. Use powershell or stsadm command to disable to feature for the sanbox solution. You need to pass the feature ID you get from previous queries.

  

     Disable-SPFeature –Identity DA9016BA-93F2-44AD-99B0-1F80B968E7E7 –url http://projectsdev/sites/Harry/ –Confirm:$false -Force:$true

      2. Use database delete to remove the orphan entry inside Solution table for the solution. STOP! This is not supported by Microsoft. If you update the SharePoint tables, your farm will not be supported by Microsoft any more!

Well, I have decided to leave the solution entry at this time and will work with Microsoft to see anyway we could clean it up using Powershell or OM API. I have tried the following commands but there are not able to remove the solution.

 

    Uninstall-SPUserSolution –Identity emsdev.wsp  -Site http://yoursharepoint/sites/Harry/ -Confirm:$false –Force:$true

    Remove-SPUserSolution –Identity emsdev.wsp  -Site http://yoursharepoint/sites/Harry/ -Confirm:$false –Force:$true

If you have a better way to clean up the solution table without deleting the entry from the database table, please let me know. We are also in the process to automate process to identify orphan solutions and deactivate the feature.

Utilize the Managed Metadata Service application tip #8 - How to resolve error "This operation cannot be completed. The term store may be unavailable."

If you add a managed metadata column to a site, you may get the following error "This operation cannot be completed. The term store may be unavailable.". The end user will have the screen like this in the screen shot.

 

After looking at this issue and I’m able to reproduce this consistently on RTM version. Here is the steps to reproduce this issue.

After looking at this issue and I’m able to reproduce this consistently on RTM version. Here is the steps to reproduce this issue.

1.       Create a site collection with URL http://<server>:<port>/sites/MMD2

2.       Add a local term on one of the lists on the site. See screen shot. This will create a local term store.

3.       Delete the site collection

4.       Recreate a site collection with SAME URL http://<server>:<port>/sites/MMD2

5.       Try to add one managed metadata column with local term store

You will get the same error. SharePoint logs is listed below.

10/24/2011 13:39:45.45 w3wp.exe (0x2738)                       0x26E4  SharePoint Foundation                 Topology                                      e5mc     Medium               WcfSendRequest: RemoteAddress: 'http://sbx01:32843/cbcfc9eb8878494b84958f40d075e575/MetadataWebService.svc' Channel: 'Microsoft.SharePoint.Taxonomy.IMetadataWebServiceApplication' Action: 'http://schemas.microsoft.com/sharepoint/taxonomy/soap/IDataAccessReadOnly/GetChanges' MessageId: 'urn:uuid:dcaf0d35-ada7-437d-90dc-83dfa6ad5869'     

   

10/24/2011 13:39:45.46 w3wp.exe (0x09E4)                       0x209C  SharePoint Foundation                 Topology                                      e5mb    Medium               WcfReceiveRequest: LocalAddress: 'http://sbx01.na.qualcomm.com:32843/cbcfc9eb8878494b84958f40d075e575/MetadataWebService.svc' Channel: 'System.ServiceModel.Channels.ServiceChannel' Action: 'http://schemas.microsoft.com/sharepoint/taxonomy/soap/IDataAccessReadOnly/GetChanges' MessageId: 'urn:uuid:dcaf0d35-ada7-437d-90dc-83dfa6ad5869'          8d6fb8d3-f669-4791-abf0-4d63bfe9a9ea

 

Please note the URL has the GUID that may be poiting to the previous site colletion. This is only happens on RTM version  and it seems to be resolved on Sp1 + June CU. Here is the defference for RTM version and SPA + JUne CU if you add managed metadata columns on the recreated site colelction with same URL.

On RTM version server sbx01, you will not be able to create new managed metadata group and the old managed metadata table EMCGroup still have the old group. It seems like RTM prevent new group created with same name.

On SP1 + June CU version sbx04, we are able to create new managed metadata group and add terms. When we check the managed metadata service table EMCGroup, you will see new group created with additional "-1" appended to previous group name as in the screen shot.

So the real problem for deleting site collection is  none of the managed metadata associated with the site collelction will be deleted. The managed metadata associated with deleted site will become orphan data. If you create another site collection with same URL on RTM version, it will fail to overwrite existing data. 

Although SP1 + June CU seems to "resolve" the issue, you will see the orphan  managed metadata still in the table after site deleted. As a result, in order to resolve the issue, you would need to delete the managed metadata columns, delete the local managed term store before deleting the site collection. This way, you have clean managed metadata table.

If you have any better solution, please share. You could refer other blog on managed metadata service.

Utilize the Managed Metadata Service application tip #1 - How to resolve "The required feature is not enabled for this column type" error 

Utilize the Managed Metadata Service application tip #2 - Metadata column not visible for users other than site collection administrators

Utilize the Managed Metadata Service application tip #3 – Impact of message “Earlier versions of client programs might not support this type of column” on Document Library

Utilize the Managed Metadata Service application tip #4 – How to workaround "Deletion of this user as a contributor failed" for local term store 

Utilize the Managed Metadata Service application tip #5 – Be aware of "Deletion of this user as a contributor failed" error on AD groups for local term store

Utilize the Managed Metadata Service application tip #6 – How to fix "The default termstore for this site cannot be identified " error

Utilize the Managed Metadata Service application tip #7 – How to read managed metadata column relationship 

Utilize the Managed Metadata Service application tip #8 - How to resolve error "This operation cannot be completed. The term store may be unavailable."