SharePoint 2010: Migrating a Sub-Site to a Different (existing) Site Collection

I decided to write this blog post because I screwed up today.  Yes, even good guys have bad days and nobody is perfect, even though to our customers and clients we appear to be.  So, slightly embarrassed for my mistake, I'm putting this out there so others can hopefully learn form this incident and avoid creating more problems and work for yourself.

I was asked by a customer to move some sub-sites from one site collection to another.  The reasoning was because he was running out of space in his storage quota and wanted to move these sites to a different content database.  This is not a big effort usually.  It's actually quite simple using powershell.

First step is you export the original site per this technet article (http://technet.microsoft.com/en-us/library/ff607895(v=office.15).aspx):

Export-SPWeb <URL> -Path c:\site_export.cmp -NoFileCompression

Once the file is created, you simply import the site to the new location (http://technet.microsoft.com/en-us/library/ff607613(v=office.15).aspx):

Import-SPWeb -Identity <URL> -Path c:\location_of_export.cmp -NoFileCompression

When you've confirmed everything looks good in the new location, you can delete the site from the original location and you're done.

BUT... HERE IS WHAT THEY DON'T TELL YOU....

You can also use Import-SPWeb to import a SharePoint list too.  The difference is, when you use this cmdlet to copy a SharePoint list, you simply specify the root site URL and it will create the new list or library in that location.  If you use this cmdlet for a site however, you MUST FIRST create a placeholder site in the destination web application.  If you only specify the root URL, it WILL OVERWRITE that site, instead of creating a new sub-site.

What made this issue even worse for me was, the original root site was created using a 'blank site' template (STS#1) and when I overwrote it, the site was changed to a 'team site' template (STS#0).  Not a big deal, right?  Wrong.  When I tried to restore the site back using an export/import from an unattached backup copy of the content database, it wouldnt overwrite the site back from team site template to blank site template.  Fortunately the site was more or less a placeholder, so I was able to fix it manually, but it could have been much, much worse.

So take it from me, always double check your cmdlets and never assume that Microsoft will be consistent in their processes.  You have been warned.

What to do when a User Profile is out of sync with Active Directory

Frequently I will get a report from a user that a user profile is out of sync or doesnt display correct information.

The first thing I do is query AD to make sure that it contains the correct information.  If AD is correct but the SharePoint User Profile is incorrect, you can try to force a full synchronization.  But if this is not successful, here are a couple other things you can try:

1) Use PowerShell Cmdlet to force a sync with AD
Set-SPUser –Identity <domain>\<username> –SyncFromAD –Web http://<webapp>

2) Manually delete and immediately re-add the profile in Central Administration.  This will force the profile service to query AD and populate with the correct information. There are no worries to delete the profile in UPS, because it wont delete the user from any site collections or lose any metadata.  It will simply re-build their profile.

3) If all else fails, you will need to remove the user from SharePoint Site Collection and re-add them.  Please keep in mind that this will remove them from any security groups they may have been added to.  All original permissions will be lost and you will need to re-add them to each of these groups and sites manually.  Use this step with EXTREME caution.

For this, navigate to the User Information List by adding "_layouts/people.aspx?MembershipGroupId=0" to the end of your site collection URL.  Select the user you wish to remove, and click Delete User from Site Collection.

Create web applications that use classic mode authentication in SharePoint 2013

In SharePoint 2013 Central Administration, you can only configure claims-based authentication when you manage web applications.  If you are migrating from a SharePoint 2010 environment where classic-mode authentication is being used, you will need to first create a classic-mode web application in SharePoint 2013, migrate all content, and then upgrade to Claims-Based, to take advantage of server-to-server authentication and app authentication as well as Office Web Apps.

Using SharePoint 2013 Management Shell with an account that has proper permissions to SQL and the farm, use this cmdlet:

New-SPWebApplication -Name "NewWebApp" -ApplicationPool "NewWebApp1.AP" -AuthenticationMethod "NTLM" -ApplicationPoolAccount (Get-SPManagedAccount "webappserviceacct") -Port 443 -Url "https://url.domain.com" -SecureSocketsLayer -DatabaseName "WSS_Content_WebApp_Root"

For more information, visit: http://technet.microsoft.com/en-us/library/gg276326.aspx