Wednesday, September 12, 2012

How to Correctly Backup and Restore Term Store DB, Content Type Hub and Content Database

I have run across this scenario a few times so I thought I would write a guide for others to follow. The need for this comes up when companies have multiple environments such as Prod, Staging, Test, Dev etc. Almost invariably, I have seen that the Prod environments are the most up to date, not only in terms of content but also in terms of configuration of the SharePoint farm.

So lets assume that your organization is using the Content Type Hub to syndicate and push content types to the different subscribing site collections. This involves the use of the Managed Metadata Service which directs the publishing of the content types and also allows for the term sets to be used in the various SharePoint web sites. Lets also assume that your sites use Managed Metadata columns that are mapped to the term sets in the term store. Every once in a while, you want to pull data back to your other environments for periodic refreshes and testing. I have been asked how to do this by a few clients so I will lay it out here.

To do this correctly, you will need to back up at least 3 databases from your production farm, depends on how many databases your hub and content sites are using. I am assuming 1 per web application here. So, backup the Hub database, the content database or databases which you want to bring back, and the managed metadata database that contains all the term sets and terms. What is the managed metadata database, you ask. To find that out, you have to go to Service Applications, highlight the Managed Metadata Service application and then click properties. You will see the name of the database on this screen.

Bring those backed up databases to the target environment SQL Server, ready to be restored. As a best practice first I make backups of all three or more databases in the target environment that I am about to replace. Then I turn of the SP Timer service to make sure the timer jobs don't try to push stuff while I am restoring term sets and the Hub. Then I override the MMS destination database with the MMS database I just backup from Prod. This brings back all the term sets and terms. I also disconnect the Hub and the target web application content databases using CA or stsadm or powershell.

Note: To view this go back to the properties screen we were just on for the Managed Metadata Service Application. This brings back the connection to the content type hub in production, which is what we don't want. We want this URL to point to our target environment (Staging, Test etc). It is not possible to change this URL from the UI, we have to change it using powershell.

The Powershell command is as follows:

Set-SPMetadataServiceApplication -Identity "<ServiceApplication>" -HubURI "<HubURI>"

Once the managed metadata service looks good and all the term sets and terms have come through, then we can move on to the hub and content databases. Restore the hub and content databases as different names on the target farm so they dont override. Make sure that the permissions match on the newly restored database and the old database that we just disconnected. This is just a practice I follow. Then attach the hub web application to the newly restored hub database from prod. You might have to redo permissions on the newly restored site collections through CA so you can access them.

Finally, restore and attach all the content databases that you need to. After all this is done, do an IISReset and start the timer service. This will start the two timer jobs that push and subscribe to the content types from the new hub.

There you go, all done! Verify to make sure that your MMS columns work correctly in your web applications and that your content types are being pushed down correctly from your local hub.

Wednesday, January 11, 2012

Remember password with ISA Server

Here was a scenario I ran into recently.  A client had an ISA server 2006 deployment and used forms authentication against AD for logging in their customers. A long time request had been that users did not want to enter their username and password every time, they wanted the browser to remember their credentials.

After talking the customer through the fact that this was not a good idea from a security standpoint and not succeeding in dissuading them, I started to look for the solution. We took a look at the ISA settings on the server, but couldn't find anything in this regard. I was chatting to a colleague about this who had been making modifications to the ISA server login page to customize the HTML the end user would see, and he pointed out that there is a form option on the login page that turns auto complete on or off. Here is the piece of HTML that causes this:

form autocomplete="off" id="logonForm" method="post" action="/CookieAuth.dll?Logon"

Setting autocomplete="on" then allows the browser to save the username and password credentials.