Beware of Restore-SPSite Requirements

 

Overview

You have SharePoint 2010/2013 Farm deployed. In the same SharePoint Farm, you are trying to back up a site collection and restore on to either a different site URL or managed path or different web application. You are doing this using following PowerShell commands:

• Backup-SPSite
• Restore-SPSite

Meanwhile in the process, your Backup-SPSite will work successfully, but while executing the Restore-SPSite you might get following errors:

1. Restore—SPSite : The operation that you are attempting to perform cannot be completed successfully. No content databases in the web application were available to store your site collection. The existing content databases may have reached the maximum number of site collections, or be set to read—only, or be offline, or may already contain a copy of this site collection. Create another content database for the web application and then try the operation
2. Restore-SPSite : Access is denied. (Exception from HBESULT: 0x80070005 ( E_ACCESSDENIED))

Cause

Condition for Site Restore

• When you back up a site collection and restore within the same Web Application, you will need a separate Content Database to restore to. Refer this MSDN Article. Same site collection (will have same SiteID GUID)

If a site collection is backed up and restored to a different URL location within the same Web application, an additional content database must be available to hold the restored copy of the site collection.

Condition for Site Delete

• Now if you are backing and restoring to be served from different URL, then you are looking at deleting the site collection before you are restoring the site collection. Starting in SharePoint 2010, the Site Collection deletion process has been changed. Refer to Bill Baer's blog here.

Condition for Site Restore

• When you are set with above conditions and trying to restore site collection now you are greeted with the Access Denied warning.
• This happens when the user login you are using to login to the SharePoint Server (RDP), this is usually the Farm Admin, is not one of the restoring site collection primary or secondary administrator.

Resolution

1. You are going to be performing this operation on the SharePoint Server, using the Farm Administrator account.
2. Your current site collection owner is not the farm admin.
   1. In this case, set your farm admin as Primary/Secondary administrator (This will be temporary until your restore operation is complete)
   2. If you did not do this and went ahead and already deleted the site collection and you have no back up, still no worries, follow further steps.
   3. But at least know who is the Primary or Secondary site collection administrator.
3. Backup your site collection using the Backup-SPSite.
4. If you need to delete the site collection because you are trying to move the site collection, then you will need to delete the backed up site collection from SharePoint.
   1. So before you go ahead and delete, ensure you have backed up the Content Database that contains this site collection.
   2. If you delete site collection using Remove-SPSite, the site collection will be deleted permanently.
   3. If you delete site collection from the Central Administration or using Remove-SPSite with -GradualDelete option the site collection will be marked for deletion, and will be deleted based on the timer job "Gradual Site Delete".
      1. You could list the sites marked for deletion by running Get-SPDeletedSite and follow with Remove-SPSite
      2. You could force the timer job Run Now to delete pending the site collection that are marked for deletion.
   4. At this stage you site is removed successfully.
5. Now you are trying to restore your site collection.
   1. Use Restore-SPSite PowerShell command to restore.
   2. If you are coming across the Access Denied error, that means your Site Collection Primary or Secondary owner is not one of the Farm Admin.
   3. In that case, ( If you did not rest the site collection Primary or secondary admin to the Farm admin before the backup), follow below option:
      1. Find out who was the primary/secondary site collection administrator is
      2. Temporarily, make the above site collection administrator a farm admin, provide rights (I gave full rights until Restore was successful) to the restoring Content Database.
      3. Have the site collection administrator Login to the SharePoint Server farm (This is the only way, because you did not reset the site collection owner to farm admin before the backup)
      4. Then run the Restore-SPSite.
      5. Now remove the user from farm admin and remove the SQL Full rights on the content database.
      6. If you had the Site collection administrator reset to Farm admin prior to back up, then set the appropriate business users to the site collection administrators.

MySite Delete Warning Resolution

Overview

You have SharePoint 2010 or 2013 environment. You have also deployed My Sites and your users have been consuming the My Site Feature.

You had an old Users OU in your AD and now you decided to create a new OU for whatever reason. Then gradually you have been moving the users from old OU to the new OU.

While this moving users has been occurring for period of time, now few end users are receiving a warning email message that one of their reporting employee my site will be deleted.

This issue is around the below described specific scenario and the suggested resolution could be reviewed in your specific scenario based

Issue Diagnosis

Let's say you have following below OUs for in your AD.

• OldUsers is the old OU
• New.Users is the new OU

In the last one month your IT has been gradually moving users from OldUsers to New.Users OU. In the SharePoint, the User Profile Synchronization is pointed only to the OldUsers OU. As the users were moved to the new OU New.users, following is been happening:

• The moved User Profile was deleted from SharePoint.
• If that user had a mysite and if the user had an assigned Manager in AD,
  • Then the MySite secondary administrator was changed to the Manager
  • The My Site was queued for Deletion in 14 Days.
  • An email was sent to the Manager (This is first warning)
  • After 12 days a second email was sent with notification that after 3 days the site will be deleted.
• If that user had a mysite and if the user had no Manager in AD,
  • No email sent to any body
  • No change in user administrator
  • The site is queued for deletion in 14 days

The entire process is managed by a timer job called “MySite Cleanup job”. This timer job runs every day from 1AM-6AM (Default setting).

Resolution

First and foremost disabled this timer job “MySite Cleanup job” to avoid any accidental My Site Deletion. The resolution is to gracefully recover from this issue and not directly edit the database table content which is not supported by Microsoft. So proceed with your own caution.

You will first need to determine the current state of User Profiles in the SharePoint Profile Database. Run the following simple Select query against your SharePoint Profile database

SELECT [DisplayName]

,[Email]

,[NotificationStatus]

,[Created]

FROM [PROD_Profile].[dbo].[MySiteDeletionStatus]

(I have removed the Display Name and emails from the below screen shot.)



1. For each user, against the Created Date, calculate the 14 days date.
1. In the SharePoint farm, under UPS revise the Connection to ensure to include the New.User and OldUsers are also included
1. Run full profile synchronization
2. Ensure that now you can find all the users (or whatever the latest number from the above SQL query run) under the User Profiles
3. Under the Monitoring, ensure the MySite Cleanup job is now active and is scheduled to run daily (Default)
4. Ensure that the daily database backups are done
5. Next step is to watch out for each of the marked user site collections to be deleted (The Site Collection does not get permanently deleted, with SP 2010 SP1 changes, the site collection now stays in the Site Collection Recycle bin at the Farm level) by the MySite Cleanup job, on the dates that you calculated by adding the 14 days.
6. After a site is deleted by the MySite Cleanup job, next day, re-run the SQL Query to ensure that the user name is not listed in the SQL Query.
7. Now run the following PowerShell command to check and restore the deleted site collection from the internal site collection recycle bin.
8. On any server in the farm, run the Powershell, and run Get-SPDeletedSite, example below, Jane Smith site was deleted.



1. Now run the Restore-SPDeletedSite as below"



1. At this stage the user site is back as is and there is no entry for this site in the database table MySiteDeletionStatus
2. If a manager was assigned as secondary site contact, then from the Central Administration, remove the manager as the Secondary Site Contact.
3. This should get the User Site Collection re-instated as is.

Future of Implementing Content Types and Site Columns

Overview

You are using SharePoint 2007, 2010, 2013 as On Prem. You are implementing Site Columns and Content Types to support your desired Taxonomy and document object models within your organization.

Either in a near feature or you are in the process of moving to the cloud with O365, completely or partially for collaboration workloads.

Beware of your implementation choices for Site Columns and Content Types and what is upcoming!

Background

Currently you have following options to implement the Site Columns and Content Type structures within the SharePoint platform and what it means to you.

Options for implementing Site Columns and Content Types and the impact:

• Deploying over the browser from Site Settings>Galleries>Site Columns or Content Types
  • SharePoint determines the GUID assigned for ID
  • Site Columns and Content Types are coded in to the content database
• Deploying Declaratively:
  • By XML Site Column and Content Type Definitions in the form of Elements.xml
  • Baking the above XML definitions in to the Feature Solution
  • You determine the GUID assigned for the ID
  • Eventually deploying the solution to run as Full Trust Code (FTC)
  • Site Columns and Content Types are coded in to the content database

Impact of GUIDs

Impact of the Site Columns and Content Type IDs which are in the form of GUIDs

• When you upgrade this site collection to next available version, the GUIDs are maintained.
• When you are migrating to O365, you will need a tool to migrate the content.
• You will need a commercial migration tool or custom code written tool by yourself.
• You should ensure to retain the GUIDs of your Site Columns.
• You want to retain the GUIDs so that the Site Column referencing libraries and lists data are intact.

Issue

• Like we all know there is no support for Farm Solutions with O365, we have no option to deploy our Site Columns and Content Types with our desired GUIDs.

Content Type Hub

• If you have deployed a Content Type Hub configuration to consolidate your enterprise Site Columns and Content Types, with migration to O365, you are still stuck with the above issue. (Also please read below how the migration products behave)

Migration products behavior with the GUIDs

The major migration product vendors I had spoken to, comment that they cannot retain the Site Column and Content Type GUIDs while their tools copy over for obvious reason. However, post the copy process the tools will reset such GUIDs to be all in synch.

Alternative Coding/Scripting Options

For those who have to opt for custom development option, beware of below aspects:

• You can implement Site Column with a specific GUID via the AddasXMLSchema method on the SPWeb.Fields object.
• However ContentType does not have similar AddAsXMLSchema support API.
• However you can implement Content Type with your specific GUID via new SPContentType object and assign the GUID to the myContentType.ID field

Update with SP1

• With the recent release of SP 2013 SP1, CSOM APIs has been now revised to support the assignment of specific ID for the content type creation.
• From KB2817429 Developers are unable to specify a Content Type ID when creating Content Types in the client object model.
• For example see http://blogs.msdn.com/b/vesku/archive/2014/02/28/ftc-to-cam-create-content-types-with-specific-ids-using-csom.aspx