I had a server running with the 32 version of Server 2008 that I needed to migrate over to the 64 bit version of Windows Server. The server hosted both our Active Directory Rights Management Server (AD RMS) along with our Microsoft Certificate Server (CA). I had tried porting it years ago but was unable to get the certificate services to start. As part of the process I had already ported the RMS DB to SQL. I decided to give it another try and have some tips in no particular order:
- First I needed to get certificate services running. I started by turning off the old server, installing a new Windows Server 2008 64 bit version with the same name. I then installed certificate services role using the instructions here. However when I tried to follow the instructions for migrating the database I was getting errors like ‘jet_errmissinglogfile’ or sector size mismatch. The fix was to copy over a ‘clean’ version of the database from the old server (a copy taken while Certificate Services is stopped), deleting all the files but the database (edb) and starting the service. (I had also previously imported the original ‘config’ registry entries per the earlier referenced instructions).
- AD RMS proved a bit more tricky. First I installed 64 bit version of SQL Express which matched the instance name of the old server. HOWEVER, the better move would have been to uninstall AD RMS from the old server first. In this case I had to use ASDI edit to remove the ‘SCP’ section from AD (under Configruation->Services->RightsManagementServices). I was then able to install and restore my settings (DB and registry). Be sure to check the functionality of documents secured with RMS and the admin console though. Of special note is that after upgrading to Server 2012 I needed to run the ‘Update-ADRMS’ utility; it will NOT work right without doing this!
Migrating from SharePoint 2010 Foundation to SharePoint 2013 Foundation/Services/etc.
I followed the well illustrated instructions here, but several key points were missing. Perhaps a lot of the grief was caused by the fact that I didn’t want the SharePoint application pool to be run by Local System/Network Service/Administrator.
- First the security in 2013 uses ‘Claims Based’ security (the exact details of which I am not completely clear on, but anyway) while 2010 security is referred to as ‘Classic’. On this page (step 6) they detail how to setup a site with classic security within 2013, though my impression is that there is no benefit to ‘upgrading’ when doing this (you would just make the new site that you want and attach your content database that was brought over using the steps from the first article and it could be left there I suppose).
- In order to upgrade your restored content to the new security model I followed the proper steps in the same article that has the tip on how to make a ‘classic security’ site. After that the plot thickens. It will be necessary to modify the web.config files for the site, the admin site, and the security tokens “site”. I used this article as a reference (step #3), but it is missing pieces as well. Be sure to make backups of the originals as a mistake can render the entire installation inaccessible! An important note is that although I basically copied the tags from the source website over to the admin and security tokens site, it’s important not to put any switches in the ‘<roleManager>’ in either of those. Within that article are also steps on adding ‘SPN’s so that the application pool account can run authentications (otherwise watch out for KDC_ERR_S_PRINCIPAL_UNKNOWN/0xc0000035 errors); as well, this article points out the delegation steps required in setting up the SPNs.
- I believe at this point the site was working enough that I was getting the “Sorry, this site hasn’t been shared with you.” error when accessing the site (though from somewhere it noted that you should be able to pull up the local settings under “domain.com/_layouts/15/settings.aspx”. Just a few final things needed to be done. First forms authentication had to be disabled within the central administrator and IIS. As well I needed to follow the steps here in order to make sure that the application uses the …SPN, or something. Lastly I was getting an error where my application pool account did not have ‘local activation’ rights over an app (the CLSID is for the IIS WAMREG admin Service). In order to remedy this I had to follow the instructions here so that I could change the permissions for IIS WAMREG admin Service.
- Extra credit: I used this page to mock up a forms authentication, but further study is needed.