Purani Dilli, or Old Dilli as we know it, is the place to hit in Delhi when it comes to trying something Chatpata, theekha or meetha. From the curious, to food lovers, to food historians to the connoisseurs, this place enchants one and all! The bylanes of Old Dilli and the variety of food available can really intimidate you. From the world famous Paranthe Wali Gali to Natraj Bhalla Corner till you reach Karim’s for some Mughlai delicacies, this gastronomical trip is going to make you come back here again and again. So hop in a rickshaw and start your food trip though the experience might leave you with a few extra pounds.
Wednesday, November 13, 2013
Thursday, November 7, 2013
Migrating any Microsoft server product to a newer version is always a frightening proposition. In this blog post we'll cover the high-level overview of the SharePoint 2010 to 2013 migration process using Microsoft and industry best practices.
If you’re interested in migrating your existing SharePoint farm to SharePoint 2013, then the first things you need to know are as follows:
The only supported upgrade path is from SharePoint 2010. Thus, if your farm runs Microsoft Office SharePoint Server (MOSS) 2007 or earlier, then you’ll first need to upgrade to SharePoint 2010, and then re-upgrade to SharePoint 2013.
SharePoint 2013 has no direct upgrade path in any event. Sadly, even those with SharePoint 2010 farms must use a new install and database migration method (explained later in this blog post) in order to transition their environment to SharePoint 2013. Consequently, the term “upgrade” is itself a misnomer when it is applied to SharePoint 2013.
For instance, if you try to install SharePoint 2013 on top of an existing SharePoint 2010 server, you’ll see the dialog box that I’ve shown in Figure 1.
Setup has detected previous versions of this product on your computer.
A full discussion of the SharePoint 2010-to-SharePoint 2013 migration process would take farm more space than we have available here. Thus, I’ll provide you with the high-level steps as adapted from Microsoft’s own literature. For additional learning I suggest you study the resources I provide at the conclusion of this post.
In the meantime, “upgrade” to SharePoint 2013 consists of the following workflow:
- Prepare Your SharePoint 2010 Farm
- Prepare Your SharePoint 2013 Farm
- Copy and Upgrade Your Databases and Service Applications
- Upgrade Your Site Collections
Let’s take a closer look at each of these migration phases in more detail.
Prepare your SharePoint 2010 farm
We understand that we’ll decommission the SharePoint 2010 farm after our migration to SharePoint 2013 is complete. Before we do that, though, we have several punchlist tasks to undertake:
- Gather all configuration (topology, settings, etc.) of the farm
- Check all databases for errors and fix them
- Turn off the Web Analytics service application (SharePoint 2013 moves this service to the Search service application)
- Remove PowerPoint Broadcast sites (Removed in SharePoint 2013)
- Consider setting your SharePoint 2010 databases to read-only to “freeze” content
The suggestion to test all elements in this upgrade process applies universally. If you can afford to perform trial migration(s), then by all means do so.
This is my SharePoint 2010 Web app running on a Windows Server 2008 R2 SP1 server.
Also, I cannot stress enough how crucial it is that your SharePoint 2010 farm (or any SharePoint farm for that matter) be documented down to the most minute level. You don’t have to rely upon your memory and Excel to do this–there are plenty of third-party SharePoint documentation tools, including free ones. For instance, check out the Sezai SharePoint Auto Documenter for SharePoint 2010 from CodePlex.
Prepare your SharePoint 2013 farm
In the database-attach migration scenario, we must create a separate SharePoint 2013 farm, building it from scratch, and then gradually introduce the SharePoint 2010 content into the new farm. As you would reasonably and accurately expect, you’re going to lose some of your branding customizations, so be prepared to adjust accordingly.
Here are some major TODO tasks for this phase of the migration:
- Don’t use the SharePoint 2013 Farm Configuration Wizard. Instead, deploy all of your service applications manually and be sure to name their associated databases intelligently
- Complete all the normal post-installation farm configuration in your new farm: incoming/outgoing e-mail settings, farm security; Web application policy; logging, and so forth.
- Install any necessary language packs
- Recreate your customizations
Recall that your database back-end must be running either SQL Server 2008 R2 or SQL Server 2012 to support SharePoint 2013.
Do not create any Web applications at this point besides Central Administration; we’ll take care of that detail in just a moment.
Copy and migrate your databases
In this migration phase we need to concern ourselves with moving and upgrading our SharePoint 2010 farm’s databases:
- Content database(s): At least one for every Web application (except for Central Administration, we don’t need that)
- Service Application databases: Each service application installs at least one (and oftentimes many more than one) SQL Server database
Only certain SharePoint 2010 service applications can be migrated to SharePoint 2013; these are:
- Business Data Connectivity
- Managed Metadata
- PerformancePoint Services
- Secure Store
- User Profile
We’ll need to use SQL Server (using the GUI or Windows PowerShell, it does not matter) to back up the appropriate SharePoint 2010 databases and restore them to the SQL Server instance that hosts our new SharePoint 2013 environment.
Here we use T-SQL to restore a backed-up SharePoint 2010 content database to our SharePoint 2013 SQL Server database instance.
Once your service application and Web application content databases are successfully restored into your SharePoint 2013 database server, it’s time to create SharePoint 2013 Web applications, one for every Web application we had in our SharePoint 2010 environment. Be sure to use the same URLs and TCP port numbers.
Copy or re-create any Web application-level customizations as appropriate:
- CSS stylesheets
- Web parts
- Web.config tweaks
- Features/farm solutions
- Site definitions and templates
- .NET assemblies
Upgrading the service application databases can be tricky, so I’ll refer you to TechNet for the detailed step-by-step. Here is the general procedure:
- Start the service instances on your SharePoint 2013 server. The service is instance is the “engine” that powers SharePoint service applications. Think of starting your car.
- Create your service applications and restore your SharePoint 2010 service application databases. You’ll need to use Windows PowerShell for this procedure
- Define proxies for the service application; the proxy is the intermediary component that connects your service applications to the Web applications that consume their services
- Verify and customize the default proxy group membership
Now on to our content databases and user-facing Web applications. At this point we created the “empty” Web apps and re-applied customizations as necessary. We can use the Test-SPContentDatabase to verify the integrity of the SharePoint 2010 database, and then use Mount-SPContentDatabase to attach the database to its associated Web application. Again, for maximum control and flexibility, we should be using Windows PowerShell as much as possible.
Here we see our newly attached content database being migrated in our SharePoint 2013 environment.
Upgrade your site collections
The final step of the SharePoint migration process is to upgrade your SharePoint 2010 site collections. SharePoint 2013 includes most of the SharePoint 2010 templates, so your migrated site(s) should look pretty much exactly how they looked prior to the migration.
The site collection migration can be initiated either by a farm administrator or a site collection administrator. Microsoft recommends that you run a health check on each site collection by clicking the Site collection health checks link on the Site Settings page.
Here we decide whether we want to proceed with a site collection upgrade or instead try a demo upgrade.
To perform the site collection upgrade, navigate back to Site Settings and click Site collection upgrade in the Site Collection Administration section. As you can see in the figure, you can either preview the upgraded site, or initiate the actual upgrade.
Here is our fully-migrated SharePoint 2010 Web application running on a Windows Server 2012 box running SharePoint 2013.
For further Rrading:
In the last part of this three part series, we performed a completely fresh install of SharePoint 2013 on a new server and made sure it was up and running. In this part, we’re going to grab our content databases, bring them over to the SQL Server our SharePoint 2013 installation is using, and mount them to be used in our installation.
Update: Also read SharePoint 2010 to 2013 migration overview
Step 1 – Finding and moving the content databases
The easiest way to locate the content databases that are currently being utilized by our 2010 SharePoint installation is to open up the SharePoint Central Administration site. This is the administrative site used for the SharePoint backend and can be found in the Start menu.
Once you have opened the SharePoint Central Administration, click on the Manage content databases link.
When the new page loads, we are presented with all the content databases. In the case of our test server, we only have one content database named WSS_Content. We also see the current number of site collections we currently have.
There are many ways of backing up the content databases. Microsoft has several articles and tutorials dedicated to this subject. You can of course use any method you prefer and are comfortable with. For this article, I chose to use the Copy Database Wizard.
We’ll start out by opening the SQL Server Management Studio and connecting to the instance where the content databases are located. I’m directly on the SQL server so in this case it will be localhost.
Once connected, expand the Databases folder. Here we will find the WSS_Content database where our site collections are stored.
Right click on the database and hover over the Tasks option. A new fly out menu will pop up. We want to select the Copy Database… to start the wizard.
The first dialogue box of the Copy Database Wizard asks what source server the database we want to copy is located on. Note that you can use either Windows authentication or SQL server authentication. Select the appropriate one in accordance with your environment. Again, I am on the SQL server where our content database is, so I will just enter localhost and click Next >.
The next box asks where we want a copy of the database to be moved to. Here we have the same authentication options also. Enter the new SharePoint 2013 database server name and instance if any. The specific format is
\ . Click Next >.
The transfer method depends on whether you can have downtime on your SharePoint 2010 site. There are two options: the detach and attach method and the SQL Management Object method. The former is much quicker and protects against changes during the copy. The downside is that it requires the database to go offline during the process. The latter method will leave the database online but will take significantly more time to move. When you’ve decided on the best method for your individual scenario, click Next >.
The next screen will ask what databases you want to move. The WSS_Content database should already be selected. If not, select it here. For this article, we will only be covering the content database. Click Next >.
The destination database name doesn’t necessarily matter. However, for the sake of simplicity, I leave the database the same name. You can append 2013, new, etc. if you wish. Leave the rest of the options as default and click Next >.
Click Next > again on the next dialogue box. We only need to move the logins and the rest are out of the scope of this article.
Leave the next box at the defaults also unless you have a specific reason to save the logs. Click Next >.
We want to run this copy immediately for the purpose of this article. Depending on when downtime is allowed or what copy method you chose, you may wish to schedule the copy at a later date and time. ClickNext >.
The final window in the wizard gives us a rundown of what process will occur. After verifying the steps, click Finish.
When the wizard has completed copying the database, open the SQL Server Management Studio and connect to the server and instance you copied the database to. Verify that the database exists.
Step 2 – Creating the default application
In order to attach our newly copied database to the SharePoint 2013 installation, we need to create a default application. In order to do so, open Central Administration from the Start menu.
When the administrative page opens, select Application Management on the left.
Then click on Manage web applications in the right side of the page under the Web Applications heading.
From here we can add, delete, and manage the web applications on the SharePoint server. You’ll notice there is currently only one web application listed; the Central Administration site we are currently using. In the top left on the ribbon, click the New button.
A Create New Web Application modal box pops up. We don’t necessarily care about the options in this box for this particular tutorial. If you wish, give the options a look over to ensure compliance with your company. Don’t worry about the database. We will be deleting it shortly.
Another popup lets us know that the web application creation is currently in progress. Depending on the robustness of the server, this process can take quite a while.
When it has finally completed, the Application Created box is shown. We don’t wish to create any site collections at this point, so click Close.
Step 3 – Testing and mounting the content database
Although there are other ways to test and mount the content databases, by far the easiest and most efficient way is to use the management shell. Open it from the Windows Start menu now.
Testing the content database is extremely important and will tell us if we’re missing any installations on the new server. This can help us immensely by giving us troubleshooting information and letting us know whether these issues will not allow the upgrade process to complete. The command to test the database is as follows:
In our case it will look as follows:
Next, after all issues have been resolved, we will mount the new content database. This process will also upgrade the database in order to allow SharePoint 2013 to use it. The command is very similar to the test command:
Depending on the size of the content database, you may have to wait several minutes for the upgrade to complete.
Upon completion, we are given some information about the process. If there were any issues or errors, they will be shown here.
Step 4 – Clean up and initialize
After the test and mount has gone smoothly, we will need to remove the content database SharePointautomatically created earlier. Open the Central Administration site from the Start menu.
Click on Application Management in the left when the site has loaded.
On the right under the Databases header, select Manage content databases.
This should be familiar as we did the same thing to find what content databases 2010 was using. Here you’ll see the database WSS_Content that we just tested and mounted. You’ll also see the automatically created content database WSS_Content_
. Click on the automatically created database.
About halfway down on the modal box that pops up, there is a tick box to remove the content database. Check the box and click OK.
We have successfully removed the unused content database. Now we must initialize the site to use the content database we copied over and upgraded. Go back to the Web Application Management page by clicking Application Management in the left.
Under the Web Applications header on the right, click Manage web applications.
Select SharePoint – 80 under the table header Name.
In the ribbon at the top of the site, click the Managed Paths button.
We’re going to add the “/” base path to the web application. This basically just reinitializes the web application so that it will use the content database we want to use. If you do not complete this step, your newSharePoint installation will just error out when you go to the site. Type “/” in the Path: textbox and click OK.
Our web application is now up and running! You’ll notice that it looks exactly the same as the 2010 installation. This is one of the great features in 2013 that has built upon the Visual Upgrade of 2010. The individual site collections can now be “visually upgraded” by their site collection administrators. This is extremely helpful if there are a lot of customizations to the site that will be broken during the visual upgrade process.
The content database is now upgraded and on our new SharePoint 2013 installation. We copied our content databases from the old SQL server to the new one and created a new web application to attach it to. We then tested and upgraded the content database and forced our new installation to use it.