690 likes | 1.03k Views
Implement Upgrade. Name Title Company. Upgrade Cycle. Build SP15 Farm For Database Attach Upgrade. Implement Upgrade. Scripted Environment Setup. Using PowerShell scripts is recommended way to set up environment Allows repeatability and ensures consistency
E N D
Implement Upgrade Name Title Company
Build SP15 Farm For Database Attach Upgrade Implement Upgrade
Scripted Environment Setup • Using PowerShell scripts is recommended way to set up environment • Allows repeatability and ensures consistency • Between test and production environments • Benefits in disaster recovery situations • Works as documentation • Change management is easier if the script always gets updated
Account Requirements For Upgrades • Database Upgrades • Active SQL Server login on the computer that runs SQL Server • Login must be member of the DB_Owner database security role on the database being upgraded • Login must be member of the WSS_Admin_WPG database security role on the farm configuration database • Member of Farm Admin group • Service Upgrades • All requirements above for database upgrade for each database that is part of service being upgraded • Some services may require additional access such as local Administrator • Site Collection Upgrades • Member of Site Collection Administrator group • Both primary and secondary Site Collection owners have this automatically • Can also be member of full control web application policy instead • Farm Upgrades • Member of the Administrators local group on each server on which upgrade is run
Implementing Services Upgrade • Gather applicable services settings on source farm • Backup all applicable services databases from source farm • Ensure service application pools are created first • Make sure the managed account is the correct one for your security needs • Create each service application and proxy • If applicable, upgrade service database during service application creation • Pay special attention to differences in some services • Most service upgrade processes are the same, some are different though • Start service instances only after service is created with upgraded databases
Configuring Web Applications • Before attaching content databases • Ensure web applications are setup correctly • Using correct managed account for application pool • Correct managed paths exist • Same AAM zones and URLs are configured • Solutions and other customizations are installed • Ensure service instances are connected to web application • Some content database upgrades attempt to use service instances • Service unavailability should not block upgrade • Service issues during upgrade may require additional work afterwards • To finish the specific service interaction missed during upgrade • Check log to look for issues
Handling Managed Paths • Should pre-create managed paths before attaching content databases • Use the same as was used in prior version if possible • Otherwise SharePoint will guess based on your content • SharePoint may create managed paths that don’t work correctly for you • E.g. Creating managed paths that make explicit inclusions into wildcards if two explicit exclusions are at same depth under same root • SharePoint may create different managed paths depending on which database is attached first • E.g. First content database has sites at depth which makes paths that conflict with sites lower in depth in second content database
Handling Alternate Access Mappings • Must pre-create alternate access mappings before attaching content databases • Otherwise SharePoint will only render for default URL • Use the same as was used in prior version if possible • Using differing URLs from prior version can cause dirtying of all links • Will cause link fix-up in background on first hit to each document • Can cause unnecessary performance hit if URLs shouldn’t change • Remember to ensure IIS has correct bindings • If IIS cannot send request to SharePoint, AAM won’t matter • Should not just modify IIS bindings settings though • Best practice is to choose correct URL per web application instance • Configure extended web application instances when required for more zones
Installing Customizations • Install 2010 customizations • Use 2010 solutions when possible (hopefully you have these) • Use XCopy when not solution based • Install SP15 customizations • Recommend using solutions only • In some cases, 2010 customization may be used • May defer this if using DSCU • Make Web.config changes • Trusted code entries • Authentication providers Categories: • Custom authentication providers • Existing custom 2010 site definitions into 14 Site Templates directory • New SP15 site definitions when available, 2010 if not • New upgrade definition files into 15 Upgrade Configdirectory • Existing custom 2010 Features into 14 Features directory • New custom SP15 Features into 15 Features directory • Existing custom 2010 Controls into 14 CustomControlsdirectory • New custom SP15 Controls into 15 CustomControls directory • Existing custom 2010 Themes, JS, CSS and images into 14 directories • New custom SP15 Themes, JS, CSS and images into 15 directories • Existing/new custom resource files into 15 directory • Existing/replacement custom Web services into 15 directories • Existing/new custom Web part or other assemblies into GAC • New custom assembly redirects into 15 directory
Core Upgrade Commands Implement Upgrade
Upgrade Related PowerShell Commands • Content Database • Mount-SPContentDatabase • Test-SPContentDatabase • Upgrade-SPContentDatabase • Site • Test-SPSite • Repair-SPSite • Upgrade-SPSite • Request-SPUpgradeEvaluationSiteCollection • Farm • Upgrade-SPFarm • Queue Management • Get-SPSiteUpgradeSession • Remove-SPSiteUpgradeSession • Services • New-SPBusinessDataCatalogServiceApplication • Restore-SPEnterpriseSearchServiceApplicationUpgrade-SPEnterpriseSearchServiceApplication • Upgrade-SPEnterpriseSearchServiceApplicationSiteSettings • New-SPMetadataServiceApplication • New-SPPerformancePointServiceApplication • New-SPProfileServiceApplication • New-SPProjectServiceApplication • New-New-SPSecureStoreApplication • New-SPSubscriptionSettingsServiceApplication
Mount-SPContentDatabase • Initiates Content Database upgrade • Runs internal consistency/orphans check • Runs web application compatibility checks • Customization references • Web parts • Features • Site Definitions • Event handlers • Authentication/security migration references • Installed to reference auth provider mismatch
Test-SPContentDatabase • Finds issues with content databases when compared to a specific web application • Can test a database not connected to the farm • Can test a database already connected to the farm • List out issues including orphans • Missing referenced server side customizations: • Missing Features • Missing Templates/Site Definitions • Missing Web Parts • Site collections in content database but not in the configuration database site map and vice versa • Use –ShowRowCounts option to find database row sizing metrics
Upgrade-SPContentDatabase • Used to upgrade a Content Database • Mainly after applying patches to initiate build to build upgrade • Can also be used to resume failed version upgrade after mounting database • Can be used in parallel with other Content Database upgrades • Defaults to doing build to build upgrade on all child site collections • Does not have option to do version upgrade of all site collections • Can be set to not include child site collections (-NoB2BSiteUpgrade) • Improve B2B database upgrade speed • Allows upgrading site collections later • Has option to use SQL snapshot if available (-UseSnapShot) • Provides read only copy of content via snapshot while upgrading writable copy of database behind the scenes
Test-SPSite • Runs the specified or all site collection health checks in test mode • Does not do any changes to content when running • Works for both 14 and 15 mode sites • Results for test run are used to determine whether site collection can be upgraded to not • Errors will prevent upgrade • All others are to help with troubleshooting after upgrade • Option to force rerunning recently performed check (-RunAlways) • Used to bypass result caching if check recently passed • This command is correlated with Repair-SPSitecmdlet • Use Repair-SPSite to try to fix some issues found with Test-SPSite
Repair-SPSite • Runs the specified or all site collection health checks in repair mode • Does potentially make changes to content when running • Works for both 14 and 15 mode sites • When run, this will create a site level log of the repair operation • Stored in maintenance library on site • Maintenance library will be created if it doesn’t exist • Option to force rerunning recently performed check (-RunAlways) • Used to bypass result caching if check recently passed • This command is correlated with Test-SPSite cmdlet
Upgrade-SPSite • Used for both build to build and version to version upgrades • Can initiate an upgrade or resume a failed upgrade • Defaults to only performing build to build upgrade • To prevent causing mode switch by accident • Use -VersionUpgrade option to change from 14 to 15 mode • Can be used in parallel with other site collection upgrades • Need to use different PowerShell sessions though • Has option to add site collection to queue instead of upgrading within PowerShell process (-QueueOnly) • Used if you want to add larger numbers of sites to queue and let timer job handle upgrades • Will initiate upgrade of site collection already in queue • Only if site is not currently in progress for upgrading
Request-SPUpgradeEvaluationSiteCollection • Adds request to create upgrade evaluation copy of specified site collection • Request is added to per database queue • Timer job will process site: • Snapshot database (Optional) • Copy site data with new URL and Site ID • Perform upgrade (Optional) • Send email (Optional) • Works even for site collections over self-service request limits • Has option to not try to immediately upgrade after creating upgrade evaluation site collection • Used if trying to make edits to copy before upgrade • Can send email to site collection admins when creation is finished
Upgrade-SPFarm • Used to initiate full farm upgrade on a server • Intended for initiating build to build upgrades • Can also be used to resume failed upgrades at farm or for all children • Replaces using PSConfig based B2B upgrade command • PSConfig command still works for this, but may be removed in future versions • Initiates upgrade at root of upgrade hierarchy • Will upgrade any child objects that are not yet upgraded • Can take a long time • Depending on number of non upgraded objects in heirarchy • Must be run on each server
Services Upgrade Commands Implement Upgrade
Service Upgrade Processes • Common pattern used for most cases: • Restore copy of old version service database(s) to SQL • Can be done using command line or SQL Management Studio • Following examples use names such as "ManagedMetadata_Upgrade_DB" • Create the service application using the new service application cmdlet applicable for that service type • Pass in the old database(s) as parameter(s) to the cmdlet • Will cause upgrade of old version database while creating new service application • Create the service application proxy using the new service application cmdlet applicable for that service type • Start the applicable service(s) instance • Special operations needed for Project, Search, and Secure Store • Called out accordingly in following slides
New-SPBusinessDataCatalogServiceApplication • Creates a new Business Data Connectivity service application in the farm • Use to provision new Business Data Connectivityservice instance while passing in an existing database • Causes upgrade of Business Data Connectivity database as part of creation • Process works for: • Version to version database attach upgrade • Side by side build to build database attach upgrade • Remember to restore prior version database first
Example Business Data Catalog Service B2B/V2V Provisioning $applicationPool= Get-SPServiceApplicationPool -Identity "SharePoint Service Application" # Create Business Data Catalog service and proxy $sa= New-SPBusinessDataCatalogServiceApplication -Name "Business Data Catalog Service Application" -ApplicationPool $applicationPool-DatabaseName “BDC_Upgrade_DB" if ($sa) { New-SPBusinessDataCatalogServiceApplicationProxy -ServiceApplication$sa-Name "Business Data Catalog Service Application Proxy" -DefaultProxyGroup #Start Business Data Catalog service Get-SPServiceInstance| Where-Object {$_.TypeName -Eq "Business Data Connectivity Service"} | Start-SPServiceInstance }
Restore-SPEnterpriseSearchServiceApplication • Creates a new Enterprise Search Admin instance in the farm using restored information • Also known as 3rd party restore process • Can be used to: • V2V upgrade an existing Search Admin database • Side by side B2B upgrade an existing topology including search databases, usage files and index • Admin database only • Only intended for use with V2V upgrades • Topology must be recreated after restore • Do no pass in topology file as it will throw and error and prevent restore • Topology • Works for B2B upgrades only
Example Enterprise Search Service V2V Provisioning $applicationPool= Get-SPServiceApplicationPool -Identity "SharePoint Service Application" # Restore Enterprise service and create proxy $searchInstance = Get-SPEnterpriseSearchServiceInstance -local $sa= Restore-SPEnterpriseSearchServiceApplication -Name "Search Service Application" -ApplicationPool $applicationPool -AdminSearchServiceInstance$searchInstance-DatabaseName“SearchAdmin_Upgrade_DB" if ($sa) { New-SPEnterpriseSearchServiceApplicationProxy-ServiceApplication$sa-Name “Search Service Application Proxy“ -Uri $sa.Uri.AbsoluteURI #Start Enterprise Search service Get-SPServiceInstance| Where-Object {$_.TypeName -Eq"Search Server Service"} | Start-SPServiceInstance }
Export-SPEnterpriseSearchTopology • Exports the existing topology to an XML file • File contains information on service names, locations, and databases • Topology file can be used to restore service instance across same version farms • Must be accompanied by other referenced files and databases though • 2010 topology file cannot be used with 15 • 2010 and 15 topology XML files use different XML Name Spaces • Only Search Admin 2010 database can be upgraded across versions so using the same file is of little value
Example Enterprise Search Service B2B Provisioning # On prior farm, get search topology $ssa = Get-SPEnterpriseSearchServiceApplication Export-SPEnterpriseSearchTopology-SearchApplication $ssa -Filename "Topology_File.xml" # On new farm, provision Enterprise Search using topology file $applicationPool = Get-SPServiceApplicationPool -Identity "SharePoint Service Application" # Restore Enterprise Search service and create proxy $sa= Restore-SPEnterpriseSearchServiceApplication-Name "Search Service Application" -ApplicationPool $applicationPool -Topology "Topology_File.xml" if ($sa) { New-SPEnterpriseSearchServiceApplicationProxy-ServiceApplication$sa-Name "Search Service Application Proxy" -Uri $sa.Uri.AbsoluteURI #Start Enterprise Search service Get-SPServiceInstance| Where-Object {$_.TypeName -Eq"SharePoint Server Search"} | Start-SPServiceInstance }
Upgrade-SPEnterpriseSearchServiceApplication • Upgrades an existing search service application • Used specifically for build to build upgrades • Use if only search has backwards compatibility breaking change • Most likely after any service pack level change • Could occur at any CU or QFE, check release notes and/or test first to confirm need • Mainly used to avoid doing full farm upgrade immediately after patching • If only search needs upgrade, then this will be much faster
Upgrade-SPEnterpriseSearchServiceApplicationSiteSettings • Upgrades the search related settings on a given site collection • Used specifically for build to build upgrades
New-SPMetadataServiceApplication • Creates a new Managed Metadata service application in the farm • Use to provision new Managed Metadata service instance while passing in an existing database • Causes upgrade of Managed Metadata database as part of creation • Process works for: • Version to version database attach upgrade • Side by side build to build database attach upgrade • Remember to restore prior version database first
Example Of Managed Metadata Service Provisioning $applicationPool= Get-SPServiceApplicationPool -Identity "SharePoint Service Application" # Create Managed Metadata service and proxy $sa = New-SPMetadataServiceApplication -Name "Managed Metadata Service Application" -ApplicationPool $applicationPool -DatabaseName "ManagedMetadata_Upgrade_DB" if ($sa) { New-SPMetadataServiceApplicationProxy-ServiceApplication$sa-Name "Managed Metadata Service Application Proxy" -DefaultProxyGroup #Start Managed Metadataservice Get-SPServiceInstance| Where-Object {$_.TypeName -Eq "Managed Metadata Web Service"} | Start-SPServiceInstance }
New-SPPerformancePointServiceApplication • Creates a PerformancePoint service application in the farm • Use to provision new PerformancePoint service instance while passing in an existing database • Causes upgrade of PerformancePoint database as part of creation • Process works for: • Version to version database attach upgrade • Side by side build to build database attach upgrade • Remember to restore prior version database first
Example Of PerformancePoint Service Provisioning $applicationPool= Get-SPServiceApplicationPool -Identity "SharePoint Service Application" # Create PerformancePoint service and proxy $sa= New-SPPerformancePointServiceApplication-Name "PerformancePoint Service Application" -ApplicationPool $applicationPool -DatabaseName "PerformancePoint_Upgrade_DB" if ($sa) { New-SPPerformancePointServiceApplicationProxy -ServiceApplication$sa-Name "PerformancePoint Service Application Proxy" -DefaultProxyGroup #Start PerformancePoint service Get-SPServiceInstance| Where-Object {$_.TypeName -Eq "PerformancePoint Service"} | Start-SPServiceInstance }
New-SPProfileServiceApplication • Adds a User Profile Service application to a farm • Use to provision new User Profile service instance while passing in existing databases • Causes upgrade of both Profile and Social databases as part of creation • Process works for: • Version to version database attach upgrade • Side by side build to build database attach upgrade • Remember to restore both prior version databases first
Example Profile Service B2B/V2V Provisioning $applicationPool= Get-SPServiceApplicationPool -Identity "SharePoint Service Application" # Create User Profile service and proxy $sa= New-SPProfileServiceApplication -Name "User Profile Service Application" -ApplicationPool $applicationPool -ProfileDBName"UPA_Profile_Upgrade_DB" -SocialDBName"UPA_Social_Upgrade_DB" if ($sa) { New-SPProfileServiceApplicationProxy-ServiceApplication$sa-Name "User Profile Service Application Proxy" -DefaultProxyGroup #Start User Profile service Get-SPServiceInstance| Where-Object {$_.TypeName -Eq "User Profile Service"} | Start-SPServiceInstance }
Mount-SPProjectDatabase • Use to mount single merged Project database or to merge all four prior version Project databases into one and mount it to farm • Calls ConvertTo-SPProjectDatabase only if four other databases are passed in • Causes upgrade of merged Project database • Process works for: • Version to version database attach upgrade • Merged database is attached to Project service instance • Side by side build to build database attach upgrade • Performs upgrade as part of attachment process • Remember to restore prior version databases first
ConvertTo-SPProjectDatabase • Use to merge all four prior version Project databases into one • Merged Project Database = 2010 Draft Database + 2010 Published Database + 2010 Archived Database + 2010 Reporting Database • Only used for version to version upgrade case • Recommended to use Mount-SPProjectDatabase instead of this command • This will get called behind the scenes to merge the databases • Merged database is attached to Project service instance • Database is upgraded as part of attachment process
Example Project Service V2V Provisioning $applicationPool= Get-SPServiceApplicationPool -Identity "SharePoint Service Application“ # Create Project service and proxy $sa = New-SPProjectServiceApplication -Name "Project Service Application" -ApplicationPool $applicationPool –Proxy $true if ($sa) { # Merge, mount and upgrade existing project databases Mount-SPProjectDatabase -ServiceApplication$sa-ProjectServiceDbname "Merged_Project_DB" -DraftDBName "Project_Draft_DB" -PublishedDBName "Project_Published_DB" -ArchiveDBName "Project_Archived_DB" -ReportingDBName "Project_Reporting_DB" #Start Project service Get-SPServiceInstance | Where-Object {$_.TypeName -Eq "Project Server Application Service"} | Start-SPServiceInstance }
Upgrade-SPProjectWebInstance • Upgrades an existing Project Service application in the farm • Used specifically for build to build upgrades • Use if only the project service has backwards compatibility breaking change • Most likely after any service pack level change • Could occur at any CU or QFE, check release notes and/or test first to confirm need • Mainly used to avoid doing full farm upgrade immediately after patching • If only project needs upgrade, then this will be much faster
Upgrade-SPProjectDatabase • Upgrades an existing Project database in the farm • Used specifically for build to build upgrades • Use if only project database has backwards compatibility breaking change • Most likely after any service pack level change • Could occur at any CU or QFE, check release notes and/or test first to confirm need • Mainly used to avoid doing full farm upgrade immediately after patching • If only a project database needs upgrade, then this will be much faster
New-SPSecureStoreApplication • Creates a new Secure Store Service application in the farm • Use to provision new Secure Store service instance while passing in an existing database • Causes upgrade of Secure Store database as part of creation • Process works for: • Version to version database attach upgrade • Side by side build to build database attach upgrade • Remember to restore prior version database first • Need to set the service passphrase to same as pre-upgrade • Otherwise service will work but application passwords will be lost
Example Secure Store Service B2B/V2V Provisioning $applicationPool= Get-SPServiceApplicationPool -Identity "SharePoint Service Application" # Create Secure Store service and proxy $sa= New-SPSecureStoreServiceApplication -Name "SecureStoreService Application" -ApplicationPool $applicationPool-DatabaseName "SecureStore_Upgrade_DB" –AuditingEnabled if ($sa) { $proxy = New-SPSecureStoreServiceApplicationProxy-ServiceApplication$sa-Name "SecureStoreService Application Proxy" –DefaultProxygroup} # Update Secure Store service passphrase to allow use of existing stored passwords if ($proxy) {Update-SPSecureStoreApplicationServerKey-ServiceApplicationProxy $proxy -Passphrase "P@ssphrase"} #Start Secure Store service Get-SPServiceInstance | Where-Object {$_.TypeName -Eq "Secure Store Service"} | Start-SPServiceInstance }
New-SPSubscriptionSettingsServiceApplication • Creates a new Subscription Settingsservice applicationin the farm • Use to provision new Subscription Settings service instance while passing in anexisting database • Causes upgrade of Subscription Settings database as part of creation • Process works for: • Version to version database attach upgrade • Side by side build to build database attach upgrade
Example Subscription Settings Service B2B/V2V Provisioning $applicationPool= Get-SPServiceApplicationPool -Identity "SharePoint Service Application" # Create Secure Store service and proxy $sa= New-SPSubscriptionSettingsServiceApplication -Name "Subscription Settings Service Application" -ApplicationPool $applicationPool-DatabaseName "SubscriptionsSettings_Upgrade_DB" –AuditingEnabled if ($sa) { $proxy = New-SPSubscriptionSettingsServiceApplicationProxy-ServiceApplication$sa-Name “Subscription Settings Service Application Proxy" –DefaultProxygroup} #Start Secure Store service Get-SPServiceInstance | Where-Object {$_.TypeName -Eq "Subscription Settings Service"} | Start-SPServiceInstance }
Managing Upgrade Internals Implement Upgrade
Manage Upgrade Queues • All Site Collection upgrades get listed in the queue • Each site collection upgrade, whether queued or not, is listed as an SPSiteUpgradeSession • Add a site to the queue using UI or PowerShell • Upgrade-SPSite $Site -VersionUpgrade -QueueOnly • List the queue contents via PowerShell • Get-SPUpgradeQueue -ContentDatabase $ContentDatabase • Remove a site from the queue using PowerShell • Remove-SPSiteUpgradeSession $Site • Upgrade a site in the queue using UI, PowerShell, or timer job • Upgrade-SPSite$Site -VersionUpgrade • If in queue, will upgrade using PowerShell session instead • Upgrade site collections job (job-upgrade-sites) • Upgrades site collections in a content databases upgrade queue • Runs every 1 minute • Manage Content Database and Web Application level upgrade throttle settings • Remember, upgrade queue is stored per Content Database
Get-SPSiteUpgradeSession • Lists upgrade sessions within a content database or the current state of a specific site collection upgrade • Defaults to show waiting/queued upgrades • Defaults to not show in process or completed/failed upgrades • Can be used to examine upgrade queue for specific content database • If the queue gets stuck on a site collection or backed up due to lots of items • You’re monitoring upgrade sessions • You’re just curious about upgrade states