SharePoint 2013 upgrade preparation - redirect only migrated site collection

As we discussed before, there are many options to redirect old site collection URLs to new URLs to avoid URL changes or downtime SharePoint 2013 during upgrade. 

We have a situation that users from one department need to upgrade their SharePoint 2010 sites across several webapps to 2013 while other users will stay on 2010 version for some time. The best option is to use AAM redirect. In this blog, I'll explain how to implement this and how to maintenance this. There are some issues associated with the approach will be listed here.

SharePoint 2010 http://sbx18/sites/R1/ has been upgraded and migrated to http://sbx28:13247/sites/R1/ and no of the other sites http://sbx18/**  have been upgraded. Th goal is to redirect only upgraded site like R1 to new SharePoint farm. Here are the procedures.

 1. Use powershell to verify existing AAM -  stsadm -o enumalternatedomains -url http://sbx18
 You should see the following result with no AAM mapped:

            <AlternateDomains Count="1" Name="SharePoint - sbx2080">
                   <AlternateDomain>
                        <IncomingUrl>http://sbx18</IncomingUrl>
                        <UrlZone>Default</UrlZone>
                        <MappedUrl>http://sbx18</MappedUrl>
                        <RedirectUrl />
                    </AlternateDomain>
               </AlternateDomains>
 
2.  USe powershell to add redirect URL - stsadm -o addzoneurl -url http://sbx18 -urlzone Default -zonemappedurl http://sbx18 -redirectionurl http://sbx28:13247
You should see the following result with new URL mapped:

            <AlternateDomains Count="1" Name="SharePoint - sbx2080">
                   <AlternateDomain>
                        <IncomingUrl>http://sbx18</IncomingUrl>
                        <UrlZone>Default</UrlZone>
                        <MappedUrl>http://sbx18</MappedUrl>
                        <RedirectUrl>http://sbx28:13247</RedirectUrl>
                   </AlternateDomain>
               </AlternateDomains>
  
3. Any site on the webapp http://sbx18 will be redirected to new webapp http://sbx28:13247 if not found on the original webapp. If the site URL exists on old server, it will display directly on old server.

This looks like perfect and it could be used if you move site from one webapp to another with same SharePoint version. However, there are some limitations described below you need to be aware of to maintain the system.

The first limitation is although some functions like OoB web services http://sbx18:13247/sites/R1/_vti_bin/Lists.asmx will be also redirect, several accesses will not be redirected. These accesses include access from WevDev, Outlook, and SharePoint designer. You might need to communicate with users if they access SharePoint through other channels besides UI.

The error you got from designer is as below.

The second limitation is you could add only one URL to redirect all sites inside one webapp. You could not redirect some sites to one URL and other sites to a different URL. The last URL mapping set through powershell will overwrite existing one.

The third limitation is there is not documentation to remove the mapped URLs after set up. You will get error or run into loop if you try to do the following powershell commands.

stsadm -o deletezoneurl -url http://sbx18 -urlzone Default

stsadm -o addzoneurl -url http://sbx18 -urlzone Default -zonemappedurl http://sbx18 -redirectionurl http://sbx18

The way to remove the AM mapping is to use the following command. Do not include the -redirectionurl parameter, otherwise you’re redirecting to the original address, in a loop. Remember to verify use enumalternatedomains powershell command to verify the result.

stsadm -o addzoneurl -url http://sbx18 -urlzone Default -zonemappedurl http://sbx18

As we discussed here, it's a good option to redirect only some site collections inside one webapp. After you upgrade and migrated the whole farm, you should use other options or not even use redirect as discussed before.

   

SharePoint 2013 upgrade preparation - redirect site collection options and tips

To avoid URL changes or downtime SharePoint 2013 during upgrade, you might need to redirect old site collection URLs to new URLs. There are several techniques you could choice depends on different situation. Here is the summary of these options and the situation you might use.

1. The best option is do not redirect. You could use the same VIP and point to the new SharePoint 2013 servers that will only require infrastructure changes like load balance configuration change. Example is the http://sharepoint used in SharePoint 2010 will point to new 2013 servers.  

This option can be used if you migrate SharePoint farm all site collections at one time and you have VIP set up originally.

2. The second option is DNS redirect. You could update DNS entries to point the oldserver to new server. This will only need DNS entry change and no other configuration needed.  

This option can be used if you migrate SharePoint farm all site collections at one time and you do not have VIP in place.

3. The third option is to use IIS redirect. You could set IIS redirect rules to redirect specific URL patterns to new servers. You could refer the instruction to configure URL redirect rules. This option you have to have old IIS that are used for previous SharePoint version running in order to support redirect.The IIS redirect rule syntax is little tricky to set up exactly want you want. 

This option can be used if you migrated partial site collections and could like to redirect only those site collections.

4. The forth option is to utilize AAM redirect. You could use powershell set up for specific webapp to redirect any site not found on existing webapp to new webapp. The new webapp could be on same server farm or different new SharePoint farm. You could need to setup once and it will work for all site collections inside the same webapp.

This option can be used if you migrated partial site collections and could like to redirect only those site collections.This redirect is different from option 3 since SharePoint will try to find the site collection under correct webapp, it will redirect to different webapp if the site collection not exist. This is very useful and I'll explain in details in next blog.

 

5. The fifth option is to modify the default page Default.aspx to redirect to different site collection or site as described by Harmeet Walia from Microsoft. 

This option can be used if you migrated partial site collections and could like to redirect only those site collections. It will work for any sub-sites also that is advantage.

The option you choice will depend on your migration situation. You might use option 4 first during migration and use option 1 after migration completed.

 

SharePoint 2013 upgrade preparation - to be or not to be claim-based?

After SharePoint 2012 conference and SharePoint Ignite IT Pro training, I got much inside information to prepare the SharePoint 2013 migration. One of the critical preparation before the 2013 upgrade is the claim-based authentication migration. We were not fan of the claim-based authentication two years ago since we found several major out of box functions were not working when we implemented ADFS at that time. In this blog, I will list the pros and cons to enable claim-based authentication on SharePoint 2013 for your reference.

In SharePoint 2013, claims-based authentication is the default and preferred method of user authentication and is required to take advantage of server-to-server authentication and app authentication. There are several options to upgrade SharePoint classic sites to SharePoint 2013 claims-based authentication. The preferred reproach is to convert them to claims-based web applications within SharePoint 2010 Products, and then migrate them to SharePoint 2013.

Here is the list of the pros to enable claim-based authentication on SharePoint 2013. The majority is the support capability of server-to-server authentication run SharePoint 2013.

1. Utilize Office Web Apps (OWA) to work correctly with the web application – In SP 2013 the authentication provider must be displayed as Claims Based Authentication for Office Web Apps to work correctly with the web application. You can find more information in SharePoint authentication requirements for Office Web Apps.

2. Apps in the SharePoint Store or App Catalog - SharePoint 2013 introduces support for server-to-server authentication and app authentication by utilizing and extending the Open Authorization 2.0 (OAuth 2.0) web authorization protocol. 

3. Azure Workflow Service - SharePoint 2013support this new workflow that is running on separately from SharePoint farm. The server-to-server between SharePoint farm and Azure Workflow Service  makes the use of claims-based authentication.

4. Exchange Server 2013 integration - SharePoint 2013 social functions like Mysite need to communicate with exchange 2013 to auto display users social pages and sites.

5. Lync Server 2013 integration - SharePoint 2013 functions related to display Lync functions will depend on server-to-server claims-based authentication.

6.  eDiscovery functions - SharePoint 2013 eDiscovery will not be able to search other repositories such as exchange or Lync w/o claims-based authentication.

7. Hibernate SharePoint 2013 farms - You could not integrate SharePoint 2013 on-Prem with SharePoint cloud w/o claims-based authentication.

8. SharePoint On-Prem to cloud migration -  SharePoint 2013 cloud only support ADFS claims-based authentication and you will not be able to migrate your sites if not claim-based already.

9. Could not create sites in classic mode easily using UI - You have to use powershell to create them.

It is very clear that you will loss many SharePoint 2013 features with deprecated classic model. My suggestion is you might need to serious consider to convert to claims-based authentication so you could be ready for the 2013 upgrade.

There are some cons you would need to keep in mind and need to be verified and tested. We have not review this with 2013 and the current conclusion is based on previous ADFS conversion.

1. Microsoft project server resource conversion and sync issues - MPS is resource to assign permissions. The resource users need to be converted to claim-based and it's not straight forward. After converted to claim, how the resource sync will work needs to be investigated.

2. People picker usability - Users will see claim user format when move mouse to user. The claim format will cause confusion when select or search users. The group might display as SID so you will not be able to identify from UI after added to the site from people picker.

3. SharePoint server API and client API need to be modified to communicated with SharePoint - You will need to pass token when communicate with SharePoint on claim-based.We will publish the detailed in future blog.

4. Several services need additional configuration and more difficult to set up - this is obvious.

5. External Workflow like Nintex workflow could not be continued and has to be rebuild or republished. All out of box workflow or designer workflows might continue working that need to be verified.

6. Some third party software or integrations might not work on claim-based authentication - Vordel SSO integration for SharePoint with other siteminder protected systems. NextLabs SharePoint entitlement tool is not supporting at this time. You might need to discuss with vendors on the claim-based authentication support of any SharePoint add on components.

7. Files checked out to local location will not be able to checking after conversion. The workaround is to generate a report indicate who has any file checked out and ask them to check in.

8. All the existing external connections including UNC, outlook connections, workspace need to be tested and might cause issues.

9. BCS and security stores need to be verified. C2WT service need to be started and associated with claim-based webapp to streamline the integrations (double hub issues).

10. Custom reports to display user and group names might need to adjust the code.

There might be more issues and risks on  claim-based SharePoint. Please share any issues or concerns if you have such experience.