Migrate from SharePoint 2010 to SharePoint 2013 - Step by Step

So you are excited by SharePoint 2013's new features and tend to migrate from SharePoint 2010 to SharePoint 2013? Well, this article walks through moving from SharePoint 2010 to SharePoint 2013 step by step, assuming all necessary migration preparations and planning strategies are done, lets move to the core migration process.

Before you start:

• Make sure your SharePoint 2010 farm is up-to date: Its highly recommended that you have latest service packs/patches installed on your SharePoint 2010 farm before proceeding with migration. Download Patches/Service packs from: http://technet.microsoft.com/en-us/sharepoint/ff800847.aspx
• Document your existing SharePoint 2010 environment -Assess current environment and take an inventory of all customizations. Document farm configuration settings in SharePoint Server 2010 
• Refer this check list: 25 Things to Document before You Start SharePoint Migration.
• http://technet.microsoft.com/en-us/library/ff645391%28v=office.14%29.aspx  .  
• You can also use codeplex tool: http://spdocgen.codeplex.com/, http://spsfarmreport.codeplex.com/  
• Use Upgrade Work Sheets: Use upgrade worksheets from Microsoft to document your source environment. Download upgrade worksheets at: http://www.microsoft.com/en-us/download/details.aspx?id=30370

• Change the Authentication to Claims: Claims authentication is the default authentication in SharePoint 2013. Many dependent services (like Office Web Apps) require Claims authentication in SharePoint 2013. So before migration convert your SharePoint 2010 web applications from Classic mode (which is default in SharePoint 2010) to Claims. Technet Reference:http://technet.microsoft.com/library/gg251985 Also, If you have "Forms" authentication, make sure its configured in your target farm before migration. 
• Cleanup Before Migration - Clean up an environment before an upgrade to SharePoint 2013 - This includes deleting unused sites/site collections, Removing unused features and solutions, Delete orphaned users and sites, Cleanup old document versions, Removing features which are not supported by SharePoint 2013 (such as Web Analytics). Technet Reference: http://technet.microsoft.com/en-us/library/ff382641.aspx

Its recommended that you run database consistency check before taking database backup from SharePoint 2010 farm.

No more In-place upgrade from SharePoint 2010 to SharePoint 2013! In other words - No direct upgrade is possible from SharePoint 2010 to SharePoint 2013. You can't install SharePoint 2013 on top of SharePoint 2010 (as we can install SharePoint 2010 on top of SharePoint 2007) . So only migration is allowed in SharePoint 2013. You can't re-use your existing Hardware for SharePoint 2013 (Also you can't install both SharePoint 2010 and SharePoint 2013 on same machine).

Migration Steps Summary:

1. Create new SharePoint 2013 Farm, Setup necessary configurations.
2. Backup - Restore SharePoint 2010 Content Databases to SharePoint 2013's SQL Sever (or perform a detach-attach process)
3. Verify content databases by running: Test-SPContentDatabase from SharePoint 2013 farm.
4. Attach Content Databases to SharePoint 2013 web application by running: Mount-SPContentDatabase
5. Upgrade Site Collections to move them into SharePoint 2013.

Step 1. Create New SharePoint 2013 Farm:
Install and configure new SharePoint 2013 farm. All farm configurations should be setup as in source SharePoint 2010 Farm, including: All necessary configurations like AAM, Email settings, Managed pats, etc. Install any 3rd party software, language packs, custom features and solutions you had in your SharePoint 2010 farm into your new SharePoint 2013 Farm. Create web application(s) to SharePoint 2013 environment as in your existing SharePoint 2010 farm.

As we are going to use the existing content database from SharePoint 2010, Delete the default content database associated with your new web application. If you failed to delete the web application's root site database, you will get "Orphaned Sites" issue on running Test-SPContentDatabase cmdlet as part of migration process. This is because the root site collection exists in both content databases and leads to conflict!

Alright, This article assumes new SharePoint 2013 Farm is already installed and configured.

Step 2. Backup - Restore SharePoint 2010 Content Databases to SharePoint 2013 SQL Sever: 
Backup SharePoint 2010 content databases, Restore them into SharePoint 2013's SQL Server instance.

Identify and take a list of your source content databases either from Central Administration (Central Administration >> Application Management >> Manage Content Databases )

Or use this PowerShell cmdlet to retrieve all content databases of a particular web application:

Get-SPContentDatabase -WebApplication "<Web App URL>" | Select Name

Optionally, you can Setting SharePoint Content databases to read-only before taking backup. But why? because you may want users to continue using SharePoint 2010, same time preventing any data in-consistency on content migrated to SharePoint 2013. To do so: Go to SQL Management Studio >> database properties >> Options >> Set Database Read-only to "True".

Backup Databases from SharePoint 2010 SQL Server:

1. Log-in to SQL Server box of your SharePoint 2010 Farm
2. Open SQL Server Management Studio, Expand Databases node
3. Right Click your content database, Choose Tasks >> Backup
4. Set the backup type to "FULL", specify the backup destination and click on "OK" to start backup process
5. Wait for the backup to complete.

Repeat this procedure for All content databases of desired SharePoint 2010 web applications.

Restore Database on SharePoint 2013's SQL box:
Next step is to Restore all databases taken from SharePoint 2010 to SharePoint 2013 SQL Server.

1. Copy all required databases backup files to your target SharePoint 2013's SQL Server. 
2. Open SQL Server Management Studio Right click databases node >>Click Restore Database
3. Specify the source as "Device" and Click on the "..." button to add backup files. Click on "Add" button to locate backup files.
4. Once done, Click on "OK" to return to the restore window.
5. In Destination section , you can type new database name in Database field if you wish to rename your database.
6. Click on "OK" button to start restore process. Wait for the restore successful message.
7. Once restored, Go to Database properties, Click on Options Tab, Set Database Read-only to False. (If you made it read-only before taking backup!)

Step 3. Verify content databases with Test-SPContentDatabase: 
No more STSADM -o PreUpgradeCheck and its replaced with the PowerShell cmdlet: Test-SPContentDatabase. So we got to execute Test-SPContentDatabase cmdlet which scans content databases of the provided web application and addresses any issues found.

Syntax:

Test-SPContentDatabase -Name <Database name> -WebApplication  <Web-App-URL>

E.g.

Test-SPContentDatabase -Name "SP2013_Operations_Content" -WebApplication "http://SharePoint13.Crescent.com"

This would report potential issues such as: Missing Features & Solution dependencies, Orphaned Sites, wide Lists, etc. Resolve Migration issues reported by Test-SPContentDatabase.


Test All Content Databases and produce Report
Lets execute Test-SPContentDatabase for all Content Databases:

Add-PSSnapin Microsoft.SharePoint.PowerShell -EA SilentlyContinue

#Array to hold Content Databases to Test
$ContentDBS= ("SP2010_IntranetRoot_Content", "SP2010_Sales_content", "SP2010_Operations_Content")

#Web Application to Host
$WebAppURL = "http://SharePoint13.Crescent.com"

#Loop through each web web application
Foreach ($DB in $ContentDBS)
 {
     "Checking Content Database - " + $DB | Write-Host -ForegroundColor Green

      "Report to Content Database: $($db)" |  Out-File -Encoding default -FilePath $("D:\DBCheck.csv") -Append 
      #Test Content Database and output report to a CSV file
      Test-SPContentDatabase -Name $DB -WebApplication $WebAppURL | ConvertTo-Csv -NoTypeInformation | Out-File -Encoding default -FilePath $("D:\DBCheck.csv") -Append 

  }
  

This script gives nice report in CSV format for easier analysis. To troubleshoot upgrade issues reported, use http://technet.microsoft.com/en-us/library/cc262967.aspx

Check the upgrade log and deploy any missing components and re-run Test-SPContentDatabase cmdlet to verify again. Make sure UpgradeBlocking is false to move further!

Step 4. Attach Content Databases to SharePoint 2013 by running: Mount-SPContentDatabase
After fixing all issues reported by Test-SPContentDatabase, we can start attaching content databases to SharePoint 2013 web application. Remember: Always mount the root site collection's database first! Also, if you migrating My sites, Migrate My Site Host First!

Mount-SPContentDatabase -name "SP2013_Operations_Content" -DatabaseServer "G1-SP2013-DB01.Crescent.com" -WebApplication "http://sp13.crescent.com" -confirm:$false

Once mounted the content database to web application successfully, The site collection is accessible in SharePoint 2010 Mode!

Step 5. Upgrade Site Collections to move them into SharePoint 2013.
One more step to complete our migration: Upgrading site collections.
By default, after migrating from SharePoint 2010 to SharePoint 2013, All migrated site collections will be on SharePoint 2010 format, retaining its old look and feel and other functionalities. We've to explicitly migrate all site collections to SharePoint 2013.

This can be done by Site collection administrators by clicking links from upgrade reminder banner.

At Site Collection Level, you can make use of Site Collection Health Checkup:
New in SharePoint 2013, Site collection Administrators can perform health checkup at site collection level before upgrading site collections from SharePoint 2010 mode to SharePoint 2013! Navigate to

• Site Settings >> Site Collection Administration 
• Click on Site collection health checks (Or use PowerShell Test-SPSite -identity <URL>)

Site collection health checkup report gives customized files, missing galleries, missing Content Types, content type conflicts, missing site templates, unsupported language packs, etc. You can repair some of the issues by running: Repair-SPSite -identity <URL>


Deferred site collection upgrade - Its a replacement for Visual Upgrade feature (Once site collection is upgraded, can't be rolled back). SharePoint 2013 shipped with files to Support SharePoint 2010. Not just user interface but actual SharePoint functionality itself. E.g. You can find 14 folder on SharePoint 2013 installation. So all files will still be maintained. E.g. Features, Event Receivers, Solutions can be deployed on 14 hive, etc. So, almost all of your existing SharePoint 2010 customizations should just work fine.

You will see a banner on top of Site collections now!

To upgrade the site collections: Click on "Start now" link on the banner (You can get there by going to Site Settings >> Site Collection Upgrade as well.)
Confirm the site collection Upgrade

We can monitor the upgrade progress with SiteUpgrade.aspx page, which provides a link to an upgrade log for troubleshooting purposes. From here, you can either start the actual upgrade or create a preview site.

SharePoint Farm Administrators can do it through bulk through PowerShell script:

Upgrade-SPSite -identity "http://sharepointsite" -VersionUpgrade

We can upgrade all site collections under the specific web application with PowerShell cmdlet:

#To upgrade all site collections in a Content Database
Get-SPSite -contentdatabase <content database name> -limit All | Upgrade-SPSite -versionUpgrade 

Once upgrade completed successfully, Verify Your site collection is with all new SharePoint 2013 features.


Get Upgrade Status:
Upgrade can be time consuming where there is a large number of site collections exists on the given content database. Get the Status of  upgrade from "Upgrade Status" page in central administration page (Central Admin >> Upgrade and Migration >> Check upgrade status )!

Or use the PowerShell script: 

Get-SPSiteUpgradeSessionInfo -contentdatabase "<Content DB Name>" -showInProgress -showCompleted -ShowFailed 

Sites will be in locked state until upgrade completed.

That's all, We are completed now! As a best practice, Review event logs and ULS logs after migration completed successfully!!

Here is our SharePoint 2010 site:

Here is the SharePoint 2010 site migrated with SharePoint 2013:

The Final site after site collection upgrade:

Additional Things to Consider:

You can try the Demo Upgrade with Evaluation Site Collection:
Demo upgrade allows to get the SharePoint 2013 preview of existing site collection by making a copy. You can try it by clicking "Try a Demo Upgrade" link either from "Upgrade Reminder banner " or by going to

• Site Settings >> Site Collection Admin 
• Site collection upgrade, click on Try a demo upgrade
• Site collection admin receives an email when timer job “Create upgrade Evaluation Site Collections” creates a site collection

Farm administrators can request an Evaluation Site Collection using PowerShell:

Request-SPUpgradeEvaluationSite -identity <Site Collection URL>

This Provisions a temporary site collection with SharePoint 2013's look and feel to validate your site collection to get the preview of your site collection on SharePoint 2013. Remember, the evaluation site collection expires after 30 days, and gets auto deleted!

Remember, while upgrading: you can't downgrade! Meaning, you can't upgrade from SharePoint Server to SharePoint Foundation or You can't upgrade from SharePoint Server Enterprise to Standard version!

Disable Self Service Upgrade
In some cases, you may want to disable self service upgrade on specific site collections, for e.g. You may want to disable upgrade on heavily customized site collections. We can disable upgrade which hides the "upgrade Reminder" bar at the top of the site collection eventually.

#Get the site collection
$Site = Get-spsite "http://Intranet2013.crescent.com/sites/operations"
#Disable Upgrade options from UI
$Site.AllowSelfServiceUpgrade = $false

This disables upgrade options from site the collection by removing the upgrade banner and the "Upgrade Site Collection" button from Site collection upgrade page of site settings. So now, the only option to upgrade is: using PowerShell cmdlet: Upgrade-SPSite

What about Migrating Service Applications?
Just because you can migrate service applications, doesn't mean you must! Consider upgrading service applications from SharePoint 2010 to SharePoint 2013 when you have some critical data in it and it involves lot of time to re-do!! I'm keeping it aside for now, will cover this in an another article.

Upgrade from SharePoint 2007 to SharePoint 2013
Want to migrate from MOSS 2007 to SharePoint 2013? Sure, But there is no way to migrate from SharePoint 2007 to SharePoint 2013 directly! We've to Migrate from MOSS 2007 to SharePoint 2010 first (can use Staging environment for this!) and then perform SharePoint 2010 to SharePoint 2013 migration again (Or you can use 3rd party migration tools to upgrade from SharePoint 2007 to SharePoint 2013 directly) Read my related posts:

• SharePoint Migration Products comparison
• Migrate from SharePoint 2007 to SharePoint 2010

References:
I would strongly recommend to go through these excellent technet resources:

• Overview of the upgrade process to SharePoint 2013 http://technet.microsoft.com/en-us/library/cc262483.aspx 
• Upgrade content databases to SharePoint 2013 http://technet.microsoft.com/en-us/library/cc263299.aspx
• Upgrade resources for SharePoint 2013: http://technet.microsoft.com/en-us/library/cc303420.aspx

Read more: http://www.sharepointdiary.com/2013/09/migrate-from-sharepoint-2010-to-2013-step-by-step.html#ixzz3gfr1TUex

Move content databases in SharePoint 2013

SharePoint 2013

Other Versions

• Office 2007

  Applies to: SharePoint Server 2013, SharePoint Foundation 2013
Topic Last Modified: 2014-09-24
Summary: Learn how to move content databases in SharePoint 2013.
This article describes how to move content databases between servers that are running SQL Server, between instances of SQL Server, or from one SharePoint 2013 web application to another.

Important:
This article only describes how to move content databases. For information about how to move other kinds of databases that are associated with SharePoint 2013, see Rename service application databases in SharePoint 2013 and Move all databases in SharePoint 2013.

You can move content databases by using the SharePoint Central Administration website or Windows PowerShell, and SQL Server tools. Which tool that you use depends on what kind of environment you have deployed, what your schedule requires, and what service level agreements that you have made with your organization.
In this article:

• Before you begin
• Moving content databases by using Central Administration
• Moving content databases by using Windows PowerShell

Before you begin

---

Before you begin this operation, moving a content database, review the following tasks. Each task is a procedure that must be done in the order in which it is listed. Note that when you move content databases, you must use both SharePoint 2013 tools and SQL Server tools. You can use either Central Administration or Windows PowerShell 3.0 for this operation.

1. Record the content database name and the web application it is associated with.
2. Pause any service applications and services that might run against the content database, including timer jobs and search crawls.
3. Remove the SharePoint 2013 content database from the web application.
4. Detach the content database from the current SQL Server instance.
   

   Important:

   To move the content database file within the same instance SQL Server we recommend that you use the FILENAME clause of the ALTER DATABASE statement. For more information, see Move User Databases. To move a content database to another instance of SQL Server or to another server, we recommend that you use procedures found in Database Detach and Attach (SQL Server) or Back Up and Restore of SQL Server Databases.

5. Copy or move the content database .mdf, .ndf, and .ldf files from the source location to the destination location using Windows Explorer.
6. Attach the content database to the new SQL Server instance.
7. Add the content database to the destination web application in SharePoint 2013.
   

   Important:
   Use the identical name when you add the content database or SharePoint 2013 creates a new content database.

8. Restart all service applications and services that you paused in step 2.

Note:

Because SharePoint 2013 runs as websites in Internet Information Services (IIS), administrators and users depend on the accessibility features that browsers provide. SharePoint 2013 supports the accessibility features of supported browsers. For more information, see the following resources: Plan browser support Accessibility for SharePoint 2013 Accessibility features in SharePoint 2013 Products Keyboard shortcuts Touch

Moving content databases by using Central Administration

---

Use the following procedure to move the content databases in your SharePoint 2013 farm by using Central Administration.

Note:

The procedures in this section use Central Administration to move content databases. However when you perform the following procedures, you must use the correct tool: 1. To record which content databases are associated with each web application ─ Windows PowerShell 4. To detach the content databases from SQL Server ─ SQL Server tools 5. To move the content databases to a new location ─ Windows Explorer 6. To attach the content databases to the new instance of SQL Server ─ SQL Server tools

Note:
The procedures in this section use Central Administration to move content databases. However, the first procedure, must be performed by using Windows PowerShell.

Note:

If you are moving a content database to a different farm, you must make the server farm account a member of the Administrators group on the database server during the restore process. This enables the account to replicate the security setting for the databases. This access level can be removed after the content database is moved. For more information, see Account permissions and security settings in SharePoint 2013. The destination farm must be running the same version or a later version of SharePoint 2013 than the source farm is running.

1. To record which content databases are associated with each web application

1. Verify that you have the following memberships:
   
   • securityadmin fixed server role on the SQL Server instance.
   • db_owner fixed database role on all databases that are to be updated.
   • Administrators group on the server on which you are running the Windows PowerShell cmdlets.
   • The dbcreator and securityadmin fixed server roles on the destination server, in order to attach the database and configure SQL Server logins.
   An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.
   

   Note:
   If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

2. Start the SharePoint 2013 Management Shell.
   
   • For Windows Server 2008 R2:
     
     • On the Start menu, click All Programs, click Microsoft SharePoint 2013 Products, and then click SharePoint 2013 Management Shell.
   • For Windows Server 2012:
     
     1. On the Start screen, click SharePoint 2013 Management Shell.
        If SharePoint 2013 Management Shell is not on the Start screen:
     2. Right-click Computer, click All apps, and then click SharePoint 2013 Management Shell.
   For more information about how to interact with Windows Server 2012, see Common Management Tasks and Navigation in Windows Server 2012.
3. At the Windows PowerShell command prompt, type the following command:
   
   Copy

   Get-SPContentDatabase -WebApplication <http://SiteName>
   

   
   Where:
   
   • <http://SiteName> is the URL of the web application.

   Note:
   We recommend that you use Windows PowerShell when performing command-line administrative tasks. The Stsadm command-line tool has been deprecated, but is included to support compatibility with previous product versions.

2. To pause timer jobs by using Central Administration

1. Verify that the user account that is performing this procedure is a member of the Farm Administrators SharePoint group.
2. In Central Administration, in the Monitoring section, click Check Job Status.
3. For each scheduled job that runs against the content database that you are moving, click the job to open the Edit Timer Job page, click Disable, and then click OK.

3. To detach the content databases from a web application by using Central Administration

1. Verify that the user account that is performing this procedure is a member of the Farm Administrators SharePoint group.
2. In Central Administration, in the Application Management section, click Manage Content databases.
3. On the Manage Content Databases page, click the content database that you want to move.
   The Manage Content Database Settings page opens.
   

   Note:
   If the content database does not appear in the list, it might be associated with another web application. To select another web application, on the Web Application menu, click Change Web Application.

4. On the Manage Content Database Settings page, in the Remove Content Database section, select the Remove content database check box, and then click OK.
   

   Note:
   Removing the content database does not delete the database. It only removes the association of the database with the web application.

5. Repeat steps 3 and 4 for each content database that you want to move.

4. To detach the content databases from SQL Server

1. Verify that the user account that is performing this procedure is a member of the db_owner fixed database role on the database server where each database is stored.
2. In SQL Server Management Studio, open the source SQL Server instance, and then expand the Databases node.
3. Right-click the content database, point to Tasks, and then click Detach. Repeat this step for each content database that you want to move.
   

   Note:
   Use this procedure to move only content databases. Do not detach any other kinds of databases.

5. To move the content databases to a new location

1. Verify that the user account that is performing this procedure has Write access to both the source and destination folders.
2. Using Windows Explorer, locate the .mdf, .ldf, and .ndf files for the content databases.
3. Select the .mdf, .ldf, and .ndf files for the database that you want to move and either copy or move them to the destination directory.

6. To attach the content databases to the new instance of SQL Server

1. Verify that the user account that is performing this procedure is a member of the dbcreator fixed server role on the database server where each database is stored.
2. In Management Studio, open the destination SQL Server instance.
3. Right-click the Databases node, point to Tasks, and then click Attach.
4. In the Attach Database dialog box, browse to where you transferred the .mdf, .ldf, and .ndf files, select the .mdf file for the database that you want to attach, and then click OK.
5. Repeat for each content database that you are moving.

7. To attach the content databases to the web application by using Central Administration

1. Verify that the user account that is performing this procedure is a member of the Farm Administrators group.
2. In Central Administration, in the Application Management section, click Manage Content databases.
3. On the Manage Content Databases page, click Add a content database.
4. On the Add Content Database page, verify that the Web Application menu displays the correct web application.
5. In the Server box, specify the database server that hosts the database.
6. In the Database Name box, type the exact name of the transferred content database.
   

   Note:
   Verify that the name is correct. If it is not, a new database will be created.

7. Specify the authentication method for the database, and then click OK.
8. Repeat these steps for each database that you are adding. Be sure that you select the correct web application from the Web Application menu for each database.

8. To restart timer jobs by using Central Administration

1. Verify that the user account that is performing this procedure is a member of the Farm Administrators group.
2. In Central Administration, in the Monitoring section, click Check Job Status.
3. For each scheduled job that you disabled previously, click the job to open the Edit Timer Job page, click Enable, and then click OK.

Moving content databases by using Windows PowerShell

---

Use the following procedure to move the content databases in your SharePoint 2013 farm by using Windows PowerShell.

Note:
The procedures in this section use Windows PowerShell to move content databases. However when you perform the following procedures, you must use the correct tool: 4. To detach the content databases from SQL Server ─ SQL Server tools 5. To move the content databases to a new location ─ Windows Explorer 6. To attach the content databases to the new instance of SQL Server ─ SQL Server tools

Note:

If you are moving a content database to a different farm, you must make the server farm account a member of the Administrators group on the database server during the restore process. This enables the account to replicate the security setting for the databases. This access level can be removed after the content database is moved. The destination farm must be running the same version or a later version of SharePoint 2013 than the source farm is running.

1. To record which content databases are associated with each web application

1. Verify that you have the following memberships:
   
   • securityadmin fixed server role on the SQL Server instance.
   • db_owner fixed database role on all databases that are to be updated.
   • Administrators group on the server on which you are running the Windows PowerShell cmdlets.
   • The dbcreator and securityadmin fixed server roles on the destination server, in order to attach the database and configure SQL Server logins.
   An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.
   

   Note:
   If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

2. On the Start menu, click All Programs.
3. Click Microsoft SharePoint 2013 Products.
4. Click SharePoint 2013 Management Shell.
5. At the Windows PowerShell command prompt, type the following command:
   
   Copy

   Get-SPContentDatabase -WebApplication <http://SiteName>
   

   
   Where:
   
   • <http://SiteName> is the URL of the web application.

For more information, see Get-SPContentDatabase

Note:
We recommend that you use Windows PowerShell when performing command-line administrative tasks. The Stsadm command-line tool has been deprecated, but is included to support compatibility with previous product versions.

2. To pause timer jobs by using Windows PowerShell

1. Verify that you have the following memberships:
   
   • securityadmin fixed server role on the SQL Server instance.
   • db_owner fixed database role on all databases that are to be updated.
   • Administrators group on the server on which you are running the Windows PowerShell cmdlets.
   • The dbcreator and securityadmin fixed server roles on the destination server, in order to attach the database and configure SQL Server logins.
   An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.
   

   Note:
   If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

2. On the Start menu, click All Programs.
3. Click Microsoft SharePoint 2013 Products.
4. Click SharePoint 2013 Management Shell.
5. At the Windows PowerShell command prompt, type the following command:
   
   Copy

   Get-SPTimerJob -webapplication <http://WebApplicationURL> | select name | Out-File <c:\timerjobfile.txt> -Append -Encoding ascii
   
   ForEach($tmrjob in (Get-Content <c:\timerjobfile.txt>)) { Get-SPTimerJob -Identity $tmrjob | Disable-SPTimerjob }
   
   

   
   Where:
   
   • <http://WebApplicationURL> is the Web application associated with the content database that you are moving.
   • <c:\timerjobfile.txt> is the location of the file that you are creating that lists all timer jobs associated with the Web application.

For more information, see Get-SPTimerJob, Out-File, ForEach-Object, Get-Content, and Disable-SPTimerJob.

Note:
We recommend that you use Windows PowerShell when performing command-line administrative tasks. The Stsadm command-line tool has been deprecated, but is included to support compatibility with previous product versions.

3. To detach content databases from a web application by using Windows PowerShell

1. Verify that you have the following memberships:
   
   • securityadmin fixed server role on the SQL Server instance.
   • db_owner fixed database role on all databases that are to be updated.
   • Administrators group on the server on which you are running the Windows PowerShell cmdlets.
   • The dbcreator and securityadmin fixed server roles on the destination server, in order to attach the database and configure SQL Server logins.
   An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.
   

   Note:
   If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

2. On the Start menu, click All Programs.
3. Click Microsoft SharePoint 2013 Products.
4. Click SharePoint 2013 Management Shell.
5. At the Windows PowerShell command prompt, type the following command:
   
   Copy

   Dismount-SPContentDatabase "<ContentDB>"
   

   
   Where:
   
   • <ContentDB> is the name of the content database.

   Note:
   If you have multiple content databases that have the same name, you must use the content database GUID in this command instead of using the content database name. To retrieve the GUID of the content database, run the Get-SPContentDatabase cmdlet without arguments.

   For more information, see Dismount-SPContentDatabase and Get-SPContentDatabase.
   

   Note:
   We recommend that you use Windows PowerShell when performing command-line administrative tasks. The Stsadm command-line tool has been deprecated, but is included to support compatibility with previous product versions.

4. To detach the content databases from SQL Server

1. Verify that the user account that is performing this procedure is a member of the db_owner fixed database role on the database server where each database is stored.
2. In SQL Server Management Studio, open the source SQL Server instance, and then expand the Databases node.
3. Right-click the content database, point to Tasks, and then click Detach. Repeat this step for each content database that you want to move.
   

   Note:
   Use this procedure to move only content databases. Do not detach any other kinds of databases.

5. To move the content databases to a new location

1. Verify that the user account that is performing this procedure has Write access to both the source and destination folders.
2. Using Windows Explorer, locate the .mdf, .ldf, and .ndf files for the content databases.
3. Select the .mdf, .ldf, and .ndf files for the database that you want to move and either copy or move them to the destination directory.

6. To attach the content databases to the new instance of SQL Server

1. Verify that the user account that is performing this procedure is a member of the dbcreator fixed server role on the database server where each database is stored.
2. In Management Studio, open the destination SQL Server instance.
3. Right-click the Databases node, point to Tasks, and then click Attach.
4. In the Attach Database dialog box, browse to where you transferred the .mdf, .ldf, and .ndf files, select the .mdf file for the database that you want to attach, and then click OK.
5. Repeat for each content database that you are moving.

7. To attach content databases from a web application by using Windows PowerShell

1. Verify that you have the following memberships:
   
   • securityadmin fixed server role on the SQL Server instance.
   • db_owner fixed database role on all databases that are to be updated.
   • Administrators group on the server on which you are running the Windows PowerShell cmdlets.
   • The dbcreator and securityadmin fixed server roles on the destination server, in order to attach the database and configure SQL Server logins.
   An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.
   

   Note:
   If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

2. On the Start menu, click All Programs.
3. Click Microsoft SharePoint 2013 Products.
4. Click SharePoint 2013 Management Shell.
5. At the Windows PowerShell command prompt, type the following command:
   
   Copy

   Mount-SPContentDatabase "<ContentDB>" -DatabaseServer "<DBServer>" -WebApplication <http://SiteName>
   
   

   
   Where:
   
   • <ContentDB> is the name of the content database to be attached.
   • <DBServer> is the name of the database server.
   • <http://SiteName> is the URL of the Web application to which the content database is being attached.
   For more information, see Dismount-SPContentDatabase.
   

   Note:
   We recommend that you use Windows PowerShell when performing command-line administrative tasks. The Stsadm command-line tool has been deprecated, but is included to support compatibility with previous product versions.

8. To restart timer jobs by using Windows PowerShell

1. Verify that you have the following memberships:
   
   • securityadmin fixed server role on the SQL Server instance.
   • db_owner fixed database role on all databases that are to be updated.
   • Administrators group on the server on which you are running the Windows PowerShell cmdlets.
   • The dbcreator and securityadmin fixed server roles on the destination server, in order to attach the database and configure SQL Server logins.
   An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.
   

   Note:
   If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Add-SPShellAdmin.

2. On the Start menu, click All Programs.
3. Click Microsoft SharePoint 2013 Products.
4. Click SharePoint 2013 Management Shell.
5. At the Windows PowerShell command prompt, type the following command:
   
   Copy

   ForEach($tmrjob in (Get-Content <c:\timerjobfile.txt>)) {Get-SPTimerJob -Identity $tmrjob | Enable-SPTimerjob}
   
   

   
   Where:
   
   • <c:\timerjobfile.txt> is the location of the file that you created that lists all of the timer jobs associated with the Web application.
   For more information, see Get-SPTimerJob, ForEach-Object, Get-Content, and Enable-SPTimerJob.
   

   Note:
   We recommend that you use Windows PowerShell when performing command-line administrative tasks. The Stsadm command-line tool has been deprecated, but is included to support compatibility with previous product versions.

How to Increase the Maximum Upload Size in SharePoint 2013

There are so many configuration settings documented elsewhere online to increase the maximum file upload size in order to store large files in SharePoint. Often times, you keep on trying different settings (you may even forget what you have tried and still can't get it to work!!) In this post I will walk you through two simple steps to accomplish this task :)

• Change the maximum upload size on the web application level

Central Admin>Application Management>Manage Web Applications> Select the desired web app and click General Settings on the ribbon

• Modify the web.config file for the appropriate web application, this is located by default at C:\inetpub\wwwroot\wss\VirtualDirectories\web application name or port

• Make a backup copy of the web.config, then open it
• Do a Ctrl+f to find this element 

<httpRuntime maxRequestLength="51200" requestValidationMode="2.0" />

• Modify the above element to match the following

<httpRuntime executionTimeout="999999" maxRequestLength="2048000" requestValidationMode="2.0" /> 

• In the above step we added executionTimeout="999999" and we set the maxRequestLength to what we set the maximum upload size on the web application general settings, which is 2048000 (2000mb * 1024 = 2048000)

And that should be all that you have to do :)

If you run into trouble, you can keep on reading on how you can use the ULS logs to find out more information about the issue.

1. If you upload a large file to an out of the box web application with default settings, you should expect to get an error. Copy the correlation id of the error and open the ULS logs and you should see the following exception about the Maximum request length exceeded, hence we change the maximum request length in the web.config to the desired amount, in this case it was 2048000.
2. 
3. Now change the maximum request length in the web.config and save the file and try to upload a large file size, you should get another error, copy the correlation id and lets check the uls logs one more time. You should see another exception this time is about the request timed out, hence we added executionTimeout="999999"
4. 

I am not a big fan of changing the upload file size to a very large amount due to other implications, for instance large files uploaded to IIS can have a high impact on server memory, also transferring large files over TCP can run into network issues where you may have to re-upload the file again from scratch!! A better option is to use some custom upload manager to stream the upload. My recommendation is to set the file size somewhere between 250-400 mb, unless your business case requires otherwise.

how to find out when a user last visited? using the C#

in your case it would be through c# to get to active directory and query last Log on:

public DateTime Get(string attr, string UserName)
    {

        DomainConfiguration domainConfig = new DomainConfiguration();
        using (new SPMonitoredScope("AD Properties"))
        {
            using (DirectoryEntry domain = new DirectoryEntry("LDAP://" + domainConfig.DomainName, domainConfig.UserName, domainConfig.Password))
            {
                //DirectorySearcher searcher = new DirectorySearcher(domain, "(|(objectClass=organizationalUnit)(objectClass=container)(objectClass=builtinDomain)(objectClass=domainDNS))");
                DirectorySearcher searcher = new DirectorySearcher(domain);
                searcher.PageSize = 1000;
                searcher.Filter = "(SAMAccountName='" + UserName + "')";
                //searcher.Filter = "(|(objectCategory=group)(objectCategory=person))";
                searcher.Filter = "(&(objectClass=user) (cn=" + UserName + "))";
                var user = searcher.FindOne();
                DateTime LastLogon = DateTime.FromFileTime((Int64)user.Properties["lastLogon"].Value);
                return LastLogon;
            }
        }

    }

Get Users Last Logon Time and Date using PowerShell

A question we sometimes need, but can't get from SharePoint is users last logon time. Usually you have an environment where a user signs in to the network and is authorized to access the company intranet without further password requirements in a single sign on environment. But the information isn't stored in SharePoint, so we can't get it from there.

However, the information is stored in Active Directory, and by importing it, you can get the information when all of your users where last active (logon) on your domain.

# Load the SharePoint cmdlets
$snapin = Get-PSSnapin | Where-Object {$_.Name -eq 'Microsoft.SharePoint.Powershell'} 
if ($snapin -eq $null) 
{    
    Write-Host "Loading SharePoint Powershell Snapin"    
    Add-PSSnapin "Microsoft.SharePoint.Powershell"  -EASilentlyContinue
}

# Import ActiveDirectory cmdlets
Import-Module ActiveDirectory

# Here's the function that will return the last logon date and time
function Get-ADUserLastLogon([string]$userName)
{
  $dcs = Get-ADDomainController -Filter {Name -like "*"}
  $time = 0
  foreach($dc in $dcs)
  { 
    $hostname = $dc.HostName
    $user = Get-ADUser $userName | Get-ADObject -Properties lastLogon 
    if($user.LastLogon -gt $time) 
    {
      $time = $user.LastLogon
    }
  }
  $dt = [DateTime]::FromFileTime($time)
  Write-Host $username "last logged on at:" $dt 
}

# Get the user profiles
$site = Get-SPSite "https://intranet.company.com/"
$context = Get-SPServiceContext $site
$profileManager = New-ObjectMicrosoft.Office.Server.UserProfiles.UserProfileManager($context) 
$profiles = $profileManager.GetEnumerator()

# Iterate all profiles and grab the users last logon date time and write to console
foreach($user in $profiles)
{
     Get-ADUserLastLogon -UserName $user["UserName"]
}