SharePoint 2013 Upgrade

SharePoint 2013 Upgrade Best‐Practices
Artur Santos Rumos [email protected]

SharePoint 2013 – Upgrade Best‐ Practices ‐ Agenda
• • • • • Learn Prepare Test Implement Validade

Learn

• Upgrade Cycle • Upgrade Requirements • Upgrade Methods • Upgrade Improvements • Deferred Site Collection Upgrade • Database/Service Changes

UPGRADE CYCLE
Learn
•Upgrade methods •New capabilities •Downtime mitigation

Validate
•Troubleshooting •Upgrade event failures •UI/UX issues •Data issues

Prepare
•Document environment •Manage customizations •Plan upgrade strategy •Make items upgradable

Implement
•Build/upgrade farms •Deploy customizations •Minimize downtime •Monitor progress

Test
•Build test farms •Use real data •Evaluate techniques •Find issues early

UPGRADE REQUIREMENTS • Server Prerequisites
– Install ONLY SharePoint 2013 – To use existing 2010 SharePoint Farm hardware:
• Backup your farm using SharePoint backup tool – Ensure your backup of farm and databases • Ensure SharePoint 2010 or earlier is not installed – Either uninstall old products This includes dependent products like Project Server and language packs

• Client Prerequisites
– Office 2010 or Office 15
• • • • For full offline and integrated experience SharePoint Designer 2010 only works for 14 mode sites SharePoint Designer 15 works for both 14 and 15 mode sites SharePoint Workspace 2010 and 15 work for both 14 and 15 mode sites

– Web Browser
• Internet Explorer 7 or higher

UPGRADE METHODS • Database Attach Upgrade
– Only available method for version to version (V2V) upgrades – Works for both version to version (V2V) and build to build (B2B) upgrades – Works for content and services databases

• In‐Place Farm Upgrade
– Only available for build to build (B2B) upgrades

DATABASES SUPPORTING DATABASE ATTACH UPGRADE • Content databases • Project databases
– Note: Four 2010 merged to one during upgrade

• • • • •

Search admin database Profile database Social database Managed Metadata database Secure Store database
– Note: Passphrase required to retain passwords in store

• Access databases
– Note: Supported for B2B upgrades only

DATABASES NOT SUPPORTING DATABASE ATTACH UPGRADE • Configuration database
– Unsupported for both V2V and B2B upgrades – Has never been supported in prior versions

• Search index databases
– Unsupported for V2V upgrades only

• Sync database
– Unsupported for V2V upgrades only

AUTHENTICATION MODE SUPPORT & UPGRADE • Windows Classic Support (Legacy)
– SP2013 supports this with some issues

• Windows Claims Support
– 2010 supports this with a few exceptions
• Outlined in claims migration document

– Migration before upgrade recommended

• Forms Auth Support
– No changes from 2010 – Ensure provider installed with same name before database attachment

• Database to Web Application authentication mode mismatches
– Database attach in SP2013 detects mismatched auth support – Test‐SPContentDatabase in SP2013 also detects this – Fix before attaching is best advice

• Ensure all external data source/web services work as expected  after claims migration

UPGRADE IMPROVEMENTS OVERVIEW • • • • • • Deferred Site Collection Upgrade Site Collection Health Checks Upgrade Evaluation Site Collections System Event Notifications System Logging Changes Site Collection Upgrade Throttling

DEFERRED SITE COLLECTION UPGRADE • Allows existing 2010 site collections to work unchanged in SP2013
– No SharePoint 2010 installation required – SP2013 has all required SharePoint 2010 files included

• Replaces Visual Upgrade
– Spiritual successor – Safer process

• Requires deep backwards compatibility
– All 14 features side by side with 15 ones – Existing customizations should just work

• Default state for all site collections in upgraded databases
– Cannot be forced automatically on database upgrade

SITE COLLECTION HEALTH CHECKS • Rule based health checks • Looks for common known issues:
– Blocking upgrade issues • Missing SP2013 templates and orphans – Post upgrade issues • Un‐ghosted files

• Site collection level scoped tool
– UI exists for Site Collection Admins – PowerShell cmdlet for Farm Admins

• Runs automatically before Site Collection version to version  upgrade
– Prevents upgrade if blocking issues detected – Does not run before any build to build upgrades

UPGRADE EVALUATION SITE COLLECTIONS • Allows upgraded preview of existing site in 15 mode • Makes side by side copy of existing site collection
– Takes advantage of SQL Snapshot capability if present
• Causes no read‐only outage as source is snapshot • Available in SQL Enterprise and SQL Developer editions

– Otherwise uses site collection backup process
• Causes read‐only outage during copy

– Occurs in scheduled Timer Job process – Considered an expensive operation

• Sends email notification when copy and upgrade is completed
– Requester and all site collection administrators – Email is optional if request occurs via PowerShell

SYSTEM EVENT NOTIFICATIONS SYSTEM • Template Based Email
– Sent to Site Collection  admins – Web Application level  feature based customizable  template – Notifies on:
• V2V upgrade completed  successfully • V2V upgrade completed  with errors • Upgrade Evaluation Site  Requested • Upgrade Evaluation Site  Created but not Upgraded • Upgrade Evaluation Site  Created and Upgraded

• System Status Bar
― Site Collection wide system events  shown prominently ― Non customizable, built‐in messages  only — Notifies users on:

• Site Collection read‐only
• Site Collection upgrading

— Notifies admins on:

• Upgrade available to Site Collection
• Site Collection requires upgrade

UPGRADE LOGGING • Per SPSite logs available to Site Collection Admins
– – – – Uses separate logging level control than rest of upgrade Shows reduced set of information by default Created for both B2B and V2V upgrades Stored as content within Site Collection
• Maintenance Logs library created as Gallery • Maintenance Logs secured to Site Collection Admins only • Hidden feature activates during first upgrade

SITE COLLECTION UPGRADE THROTTLING • Prevents overload from self‐service site collection upgrade
– Throttles are used to allow/limit upgrade

• Built‐in throttles work together:
– Application pool level throttle
• Limits number of simultaneous upgrades per application pool instance – Default is 5 concurrent site collection upgrades allowed per web app • Effectively becomes a per server level throttle for most environments • Web Application instance property controls this throttle

– Content Database level throttle
• Limits number of simultaneous upgrades per content database instance – Default is 10 concurrent site collection upgrades allowed per content database • Content Database instance property controls this throttle

– Content throttle
• Prevents self service upgrade within application pool process for oversize sites – Default is site collection < 10MB and has <10 subwebs • Web Application instance property controls this throttle

• If an upgrade is not possible due to throttling it is queued
– Queued upgrades are processed by the timer service by upgrade timer job

VERSIONED SITE STORAGE AND FEATURE/TEMPLATES

SP2013 Content Database

Feature Feature Feature Feature Feature Feature

SPWeb

SPSite

SPSite

Feature Feature

SPWeb

Feature Feature

Site Definition
Template STS#1 Feature Definition Feature Definition Feature Definition Feature Definition

Site Definition
Template STS#1

Feature Definition Feature Definition Feature Definition Feature Definition Feature Definition Feature Definition

Template STS#2

Template STS#2

WSE\14\Templates

WSE\15\Templates

FEATURE FALLBACK BEHAVIOR
15 Mode Features List
15 Mode  Lookups

SP2013 feature  replacing SP14  feature

New SP2013 only  feature

“Sunset” feature  Visible=false

14 Mode Features List

14 Mode  Lookups

SP14 feature  replaced by  SP2013 feature

Non‐replaced O14  only feature (e.g.  3rd party)

SP14 feature  removed in  SP2013

UNSUPPORTED IN 14 MODE • All new SP2013 specific features
– Upgrade SPSite to 15 mode first

• 2010 Web Analytics
– Existing features must be removed – New web analytics features supported only in 15 mode

• 2010 Office Web Applications (WAC)
– Replaced with SP2013 WAC for both 14 and 15 mode – PowerPoint Broadcast sites must be removed
• No replacement available, use Lync instead 

• Project Web Access Sites (PWA Template)
– Must upgrade to 15 mode to use – Project Sites (PWS) supported in both 14 and 15 mode

DATABASE CHANGES • Security improvements
– New application roles on all databases
• Replaces requiring DB_Owner role for normal use – DB_Owner or equivalent rights still required to perform database upgrades • Running accounts no longer have schema modification rights • Note: Roles exist in beta 1 but the upgrade to change this does not exist in Beta 1

• Runtime content database optimizations
– Sparse column support allows wider lists
• This results in a longer running database upgrade action depending on source data

– Shredded store to support file edits
• This results in a longer running database upgrade action depending on source data

• Upgrade depth improvements
– Upgrade of content database schema is separated from site collection upgrade
• Allows faster database upgrade performance

UPGRADING SERVICES • 15 WAC now on separate farm
– Consumable only by SP2013 farms
• New WOPI protocol support only exists starting with SP2013

– Works in both 14 and 15 mode for Site Collections
• New WAC functionality for editing documents shows up in 14 mode

• User Defined Functions no longer work in Excel Services
– This is due to changes around how WAC is designed

Prepare

• Upgrade Cycle • Document Existing Environment • Manage Customizations • Environment Cleanup

UPGRADE CYCLE
Learn
•Upgrade methods •New capabilities •Downtime mitigation

Validate
•Troubleshooting •Upgrade event failures •UI/UX issues •Data issues

Prepare
•Document environment •Manage customizations •Plan upgrade strategy •Make items upgradable

Implement
•Build/upgrade farms •Deploy customizations •Minimize downtime •Monitor progress

Test
•Build test farms •Use real data •Evaluate techniques •Find issues early

DOCUMENTATION PROCESS • Examine existing farm for  useful information • Gathered information informs  new version • Keep all information for future  use
• Content databases:
‐ ‐ ‐ ‐ ‐ ‐ ‐ Names Issues Referenced customizations Cross farm topology Database names Service Settings Installed customizations Alternate Access Mappings (AAM) Authentication Methods/Providers Managed paths Installed/registered features Installed customizations Web.config modifications

• Services:

• Farm/Web Application:
‐
‐ ‐ ‐ ‐ ‐

INFORMATION GATHERING COMMANDS • Test‐SPContentDatabase
– Both 2010 and SP2013 versions

• WinDiff • STSADM ‐o PreUpgradeCheck no longer exists
– STSADM deprecated

SETTINGS GATHERING • Some settings are farm specific • Most are needed for the new version farm
– At least as a basis for the new farms settings

• Simple PowerShell scripts can gather settings data Gathering Farm Settings with PowerShell

CUSTOMIZATIONS GATHERING • Solutions
– Should always have a build‐out directory for FT solutions
• Otherwise have to find way to extract FT solutions

– Don’t forget admin deployed InfoPath Forms
• Special process required to extract them

– Sandbox solutions are fine
• They come with the content database for free

• Other stuff
– MSI deployed components
• Contact vendor for updates for O15 support • Highest chance of needing a change due to file/directory placement

– XCopy or manually deployed features/files/changes
• Should look to packaging in WSP solutions package • Can just deploy to equivalent directory in O15

• Use directory comparisons to be sure you have it all

PERFORMANCE ASSESSMENT • Determine performance in advance of upgrade • Different components have different key metrics
– SQL Server(s):
• IOPs • Memory • CPU

– Network:
• Bandwidth • Latency

– SharePoint Server(s):
• Memory • CPU

TEST‐SPCONTENTDATABASE • Tests content databases against Web Application
– Connected content databases – Disconnected/remote farm content databases

• Makes no modifications to database/content • Used to detect/report:
– – – – Configuration gaps Orphaned sites Missing/unregistered customizations Row sizing for predicting comparative upgrade speeds

• Exists in both 2010 and SP2013
– 2010 version has subset of SP2013 abilities

WINDIFF OR OTHER DIRECTORY COMPARISON TOOLS • Used to compare directories and files • Compare between environments:
– Existing environment – Pristine installation at same build level as existing
• Ensure no customizations are installed

• Compare target locations:
– Web Server Extensions
• All installed customizations

– IIS Web Site directory
• Web.config file differences

– GAC
• All installed and referenced global assemblies 

• Recommended to save entire directories for future use
– May later need files or settings that are missing from new install

EVOLUTION OF CUSTOMIZATIONS • Product release cycles are a form of evolution • Customizations dependent on a product are affected
– Some live on relatively unchanged – Some change dramatically but continue on – Many die off
• Due to circumstance – e.g. developer left and no source, vendor out of business • If non‐adaptable – e.g. designed into a corner

• Takeaway is that you need to plan for evolution and even cleanup  of customizations
– All customizations have a lifecycle, plan for it right from the beginning

CUSTOMIZATION CATEGORIES AND TYPES
• • • • • • • • • • • • Master Pages Themes Web Pages Web Parts Content Types List Types Web Templates Site Definitions Web Services Windows Services HTTP Handler HTTP Module

Visually  impacting Data structure  impacting Non‐visually  impacting

VISUAL IMPACTING CUSTOMIZATIONS • Most likely to not work well with 15 mode user experience
– – – – – .CSS dependencies .JS dependencies Theme dependencies UI control dependencies UI behavior dependencies

• Usually should still work in 14 mode
– Shouldn’t block farm upgrade – Needs to be addressed before Site Collection upgrade

• Test carefully in both 14 and 15 modes

DATA STRUCTURE IMPACTING CUSTOMIZATIONS • Highest likelihood to cause blocking issues during upgrade if  missing
– E.g. Missing feature with list schema means list won’t render

• Can be modified during upgrades, but are usually expensive  changes
– Iterate over every instance to update

• Instantiation and updating needs to handle conflicting  customizations
– E.g. Conflicting path or column names

NON‐VISUALLY IMPACTING CUSTOMIZATIONS • Highest likelihood to be incompatible with SP2013
– – – – Dependencies on existing services structure or topology Deeper API and security dependencies Deep dependency on page rendering pipeline Higher chance of impacting performance

• Test carefully, these are sometimes only found by deep testing
– E.g. finding exceptions when exercising all code paths

• Can sometime express issues by impacting other behaviors
– E.g. HTTP handlers interfering with rendering pipeline

• Be prepared to replace or remove if necessary
– Check to see if the system works correctly without the customization

3RD PARTY CUSTOMIZATIONS • Customers usually don’t have  • MSI installed 2010  the ability to fix issues in  customizations may be  product without help incompatible with SP2013
– Source code rarely available – Need to work closely with 3rd party  to get updates to work with SP2013 – May require additional special  upgrade instructions – Check with 3rd party for updated  SP2013 compatible MSIs

• 3rd party applications can  include following which have  higher possibility of issues:
– – – – Windows services Windows applications Web applications HTTP modules

• In some cases consider re‐ evaluating the value of the  component with the new  version farm
– Out of box features may be viable  alternative

• Some 3rd party products  modify the SharePoint content  databases
– Absolutely not supported, ever!

SPRING CLEANING FOR A HEALTHY FARM • Cleanup existing 2010 farm before upgrade • Delete stale SPSites and SPWebs
– stsadm ‐o DeleteSite [‐force] [‐gradualdelete] – stsadm ‐o DeleteWeb [‐force] 

• Remove extraneous document versions
– Primarily user driven, OM operations or tools help

• Cleanup templates, features, & web parts
– Primarily user driven, OM operations or tools help

• Finish Visual Upgrades to 14 • Repair data issues
– stsadm ‐o DatabaseRepair [‐deletecorruption] – stsadm ‐o ForceDeleteList – stsadm ‐o VariationsFixupTool

COMPLETING VISUAL UPGRADE • Run VisualUpgrade method on all remaining sites
– PowerShell can do this easily
• Get‐SPSite | ForEach‐Object {$_.VisualUpgradeWebs()}

• Will occur during content database upgrade on 15 farm
– Content Database level upgrade action

• Better to do this on 14 farm prior to upgrade:
– – – – – To address issues while v3 components still exist To get end users involved early if necessary To allow rollback temporarily if needed To not stack faults during content database upgrade To not cause UX changes during content database upgrade

SITE COLLECTION END OF LIFE • PowerPoint Broadcast Sites
– – – – – Site Definition based template was included in WAC WAC moved off of farm, template ceased support Existing sites not supported on 15 even in 14 mode Only option is to find and remove instances Can find sites by PowerShell
• Get‐SPSite | Where‐Object {$_.RootWeb.Template ‐eq “PowerPoint Broadcast #0”}

– Can remove site using PowerShell
• Get‐SPSite | Where‐Object {$_.RootWeb.Template ‐eq “PowerPoint Broadcast #0”} |  Remove‐SPSite

FEATURE END OF LIFE • Best time to remove a feature is during site collection upgrade
– Causes least impact on users

• Simple feature can be removed with template upgrade
– DeprecateSimpleFeature – Only for Simple Features though, don’t use for complex ones

• Complex feature can be removed using feature upgrade
– Use feature upgrade code callout – Allows clean up of artifacts – Can self‐remove instance

Test

• Upgrade Cycle • Building Test Farms • Upgrade Testing cycle • Testing Processes • Service Applications Testing • Testing Customizations

UPGRADE CYCLE
Learn
•Upgrade methods •New capabilities •Downtime mitigation

Validate
•Troubleshooting •Upgrade event failures •UI/UX issues •Data issues

Prepare
•Document environment •Manage customizations •Plan upgrade strategy •Make items upgradable

Implement
•Build/upgrade farms •Deploy customizations •Minimize downtime •Monitor progress

Test
•Build test farms •Use real data •Evaluate techniques •Find issues early

TEST ENVIRONMENT CONSIDERATIONS

• Be careful of impacting live environments from test ones
– External data connections modifying live data in bad way
• E.g. deleting an item thinking it is only a test environment causing production impact

– Running database impacting commands against live databases
• E.g. Test‐SPContentDatabase

– Test environment hurting performance of shared SQL servers
• Best to run using different SQL servers (not just instances) for production and test

• Try to prevent/minimize URL changes
– These can cause issues you only experience in test environment – Can do this by using same URLs and testing only from machines with host file  changes – Actual machine names should be different though to prevent AD issues – Database names should stay the same if you want to validate scripts • Per above, you shouldn’t be using the same SQL servers for production and test

TEST FARM METHODOLOGIES

• Use real data and copies of entire databases
– To identify trouble areas – To determine upgrade performance

• Test a copy of everything, not just a sample
– You only really know what you have tested – The unexpected lurks in the databases you didn’t test

• Use production processes in test environment
– To prevent flaws occurring only in production

• Use similar hardware if possible
– Will give best equivalent performance data – If a parallel farm will be used for upgrade try using it for testing first
• E.g. use new farms as test before doing actual production upgrade • Gives excellent indication of actual upgrade performance and issues • Make sure to pave test environment before doing actual upgrade

UPGRADE TESTING CYCLE
Learn
•Upgrade methods •New capabilities •Downtime mitigation

Prepare
•Document environment •Manage customizations •Plan upgrade strategy •Make items upgradable

Implement •Build/upgrade farms •Deploy customizations •Minimize downtime •Monitor progress

Validate
•Troubleshooting •Upgrade event failures •UI/UX issues •Data issues

Implement
•Build/upgrade farms •Deploy customizations •Minimize downtime •Monitor progress

Test
•Build test farms •Use real data •Evaluate techniques •Find issues early

Learn
•Upgrade methods •Downtime mitigation •Performance •Understand issues

Validat
•Troubleshootin •Upgrade event •UI/UX issues •Data issues

TESTING PROCESSES • Confirm the upgrade plan you’ve chosen will work
– Does it do what you expect – Does your upgrade plan provide the right outage mitigation – Are there any gaps in the process?
• How would you roll back if you need to?

– You did take a backup, right?

• Validate any scripts and commands used
– Scripted processes are more repeatable – Make sure a script you may have used in 2010 or earlier is still valid
• Parameters change, and sometimes how they work changes

SERVICE APPLICATIONS TESTING • Consider various states you may be in, not just initial or final state
– 2010 farm connected to 15 services – 15 farm connected to 15 services – Different version farms for different services

• Verify in all possible states you will use in advance of production  use
– Helps to find security, configuration, compatibility, and even performance issues

• Service upgrade can be complex due to number of services
– Script the service upgrade process whenever possible

DEPLOYING CUSTOMIZATIONS

• Ensure solutions are  deployed
–

• To ensure rendering for  larger lists, confirm large list  • If not using solutions ensure  query throttling settings deployment of:
– Custom Master pages – Custom JavaScript – Custom CSS (including those for  themes)

result in being only in 14 directories – Deploy solutions to 15 directories if  required using AddToLatest option

• Custom workflow actions  must be included in actions  Consider that default deployment will  file

TESTING CUSTOMIZATIONS • Pay special attention to visual and behavioral issues • Test in both 14 and 15 mode • Look for language/resource loading issues
– Manually deployed customizations resources may be in 14 global directory
• Won’t get loaded since only new version global directory is used

– One versions resources may prevent others form working
• E.g. 15 version resource file same name but doesn’t include 14 version resources • Fixes to this require rework of customizations

• Validate upgrade impact on customizations
– Confirm that customizations do appropriate upgrade tasks if required – Ensure that they don’t block site collection upgrade

Implement

•

Service Upgrades

UPGRADE CYCLE
Learn
•Upgrade methods •New capabilities •Downtime mitigation

Validate
•Troubleshooting •Upgrade event failures •UI/UX issues •Data issues

Prepare
•Document environment •Manage customizations •Plan upgrade strategy •Make items upgradable

Implement
•Build/upgrade farms •Deploy customizations •Minimize downtime •Monitor progress

Test
•Build test farms •Use real data •Evaluate techniques •Find issues early

STANDARD PROCEDURE FOR SERVICE UPGRADE

• Common pattern used for most cases:
1. 2. Restore copy of old version service database(s) to SQL • Can be done using command line or SQL Management Studio 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

3. 4.

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  Search, and Secure  Store

SPECIAL PROCEDURES FOR SERVICE UPGRADE

• Search
1. 2. Migrate Admin Database • Restore‐SPEnterpriseSearchServiceApplication 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

3. 4.

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

Validate

• Upgrade Cycle • Review Logs • Troubleshooting • Basic Functionality • External Data Sources • Security • Find & Fix Issues

UPGRADE CYCLE
Learn
•Upgrade methods •New capabilities •Downtime mitigation

Validate
•Troubleshooting •Upgrade event failures •UI/UX issues •Data issues

Prepare
•Document environment •Manage customizations •Plan upgrade strategy •Make items upgradable

Implement
•Build/upgrade farms •Deploy customizations •Minimize downtime •Monitor progress

Test
•Build test farms •Use real data •Evaluate techniques •Find issues early

UPGRADE LOG FAILURES • Should always review logs after any upgrade
– Look for Errors and Warnings

• Start at top of log and work downwards
– Issues reported earlier likely to cause issues reported later – Look around the timeframe of the issue to find related or causal information

• Order of operations in reviewing logs
– Start with upgrade error log – Move to full upgrade log and then ULS if necessary • Correlate of timestamp of event

• Order of operations is solving issues
– Solve authentication issues first – Solve missing files/customizations next – Then worry about content issues

APPLICATION EVENT LOG FAILURES • Services not able to start
– May be out of backwards compatibility
• Most likely after patching if B2B upgrade not yet run • Can be incompatible between servers – Don’t partially patch farm unless following official documentation

– Service accounts may have login failures
• Local machine • Remote databases

– May have service provisioning errors
• DLL pushdown • Missing config file updates

– Possible fix is:
• Check logs for blocking issues and fix if necessary • Run farm upgrade

POST‐UPGRADE TROUBLESHOOTING STEPS 1. Determine cause of failure
– Follow exceptions from source to ULS  using correlation Id and timestamp
• Exceptions shown on UI • Exceptions in event logs

2. Fix failure
– Once an understanding is gained for  what has failed and why – Make necessary  configuration/settings changes – Adjust security as necessary for  login/access issues – Install components or dependencies  that are missing – If a repro of the issue was possible  before, see if the issue still occurs – You are done once the issue no longer  occurs

– Look at start of correlation Id entries  to see if earlier issue could cause later  one – Pay special attention to login, access,  and process/assembly load failures
• These usually point to configuration  or installation gaps

3. Confirm the fix

– Try to repro issue
• If necessary reach out to who was  using system, especially for UI issues

4. Document the fix
– Better to learn once than repeatedly

VALIDATE PREDETERMINED SITES • Pick certain sites in advance and ensure they work as expected  before upgrade • As a best practice include at least one of every site definition and  feature in use • Take care to review high impact/high profile sites
– – – – Better to cover bases than get complaints Should know sites look and feel before upgrade Work with key stakeholders to validate post upgrade More important after 14 to 15 mode switch

CREATE NEW VALIDATION TARGETS • Create new Site Collections /  Webs • Create new libraries/lists
– Ensure custom libraries and lists can  be created in both 14 and 15 mode – Verify if specific libraries/lists or  columns get conflicts – Add content types against libraries to  ensure they work correctly
• Good idea to verify they upgrade  correctly as well from 14 to 15 mode

– Ensure custom templates work as  expected for creation and initial use in  14 mode – Also verify new 15 mode custom  templates as net new sites

• Activate features
– Confirm that features activate as  • expected in both 14 and 15 mode – Validate that features perform correct  upgrade

Recommend best practice is to  create 2x for each template in  14 mode
– After validating 14 mode for both,  upgrade one each template – Ensures upgrade of Site per template  with 14 mode to validate beside 15  mode

• Create new pages
– Validate that pages create correctly

• Add web parts
– Confirm web parts are added and  render correctly in both 14 and 15  modes

VERIFY SERVICES FUNCTIONALITY • Search
– Crawls content farm sources – Crawls external sources – Ensure scopes and best bets work

• Access Services • Excel Services
– Excel Web Access Web parts render

• Profile and social features
– Profile sync occurs – My Site Host works 
• Check in 14 or 15 mode

• Visio Services
– Rendering Visio files

• Office Web Accessible Clients
– PowerPoint, Excel, Word – Rendering correctly – Open and save documents

• Managed Metadata
– Taxonomy data exists

• Business Connectivity Service
– Existing connections work

• Secure Store (SSS)
– Application definitions exist – Passwords retained

MY SITE HOST UPGRADES

• My Site Host works in both 14 and 15 mode
– When upgraded to 15 mode new social experience is available

• Once My Site Host is upgraded to 15 mode
– All new personal sites will be created in 15 mode – As users visit My Site Host, their sites are added to upgrade queue
• Upgrade is not immediate, it occurs via timer job • Site remains in 14 mode until upgrade occurs

– If upgrade of personal site fails, it will be reattempted after a delay
• Can manually force upgrade attempt of personal site from the UI of the actual personal  site if site collection admin or from PowerShell if farm admin

EXTERNAL DATA SOURCES • Validate services connections
– – – – InfoPath connections BCS connections Excel Services connections Search crawl external targets

• Connection accounts may have  issues
– Secure Store based application  definitions may be broken
• Passwords were not retained during  upgrade – Possible if database restored but  old passphrase not configured • Passwords changed externally but not  updated in Secure Store • Accounts need to be updated

• Confirm connections work for  all applicable users
– Check for other common users not  just administrators

• Connection strings may need to  – Claims issues may impact use be edited • Services may be incorrectly set  – Can be defined connection files, or  up embedded within files (Excel,  InfoPath) • Machine/network filtering may  – Authentication method may need to  be clocking
be changed

– Could be blocking access from new  servers when it worked on old servers

AUTHENTICATION PROVIDERS

• Ensure all authentication providers are allowing login
– Also check that admin functions work deeply into site collections such as  using _Layouts/Settings.aspx as site collection admin

• Also confirm user lookup works
– Within content Web Application – Within Central Administration Web Application

• If not working:
– Verify web.config files have correct provider information
• Content Web Application • Central Administration Web Application • Secure Token Service

– Confirm provider name is exactly the same as used in 2010 environment

PROCESS ACCOUNTS • Farm services account
– Member of SPDataAccess role on config database

• Web Application accounts
– Member of SPDataAccess role on Web Applications own content database

• All services accounts
– Member of SPDataAccess role on services own databases

• UPA service
– Member of SPDataAccess role on all connected Web Applications content databases

VISUAL CUSTOMIZATIONS ISSUES • Deferred Site Collection Upgrade intended to prevent seeing these  all at once
– Allows you to tackle this separately from farm upgrade – To also handle them site collection by site collection

• Should consider working with site collection owner to identify and  fix issue
– If fix requires change or deletion they need to be involved – The owner and users usually know what to look for

• Common areas for visual issues are:
– MasterPages – JS and CSS references – Web Parts

XHTML/XSLT/MASTERPAGES • Existing 2010 visuals should work without changes in 14 mode • Issues can occur when upgrading site collections to 15 mode Common causes are:
– References to 2010 or earlier version of files
• Has explicit references to _Layouts • Uses 2010 JavaScript and/or CSS while in 15 mode

– Pages that have been modified using 2010 or earlier visuals
• Un‐ghosted files (SetupPath associated but customized file loads) • Copies of 2010 or earlier version files (no SetupPath associated)

WEB PART ISSUES • Biggest issue is not being able to run
– Class reference missing from SafeControls list – Assembly or referenced items not installed

• Second biggest issue is not running correctly
– Rendering issues due to expecting earlier version artifacts
• JavaScript and CSS are most common issues here

– Exceptions due to missing artifacts or broken API calls

MISSING CUSTOMIZATIONS • Many missing customizations show up in upgrade log • Some do not, but can still impact your upgrade • Best to have these in advance of database upgrade • Important to install customizations or clean up  references/dependent artifacts as soon as possible once detected • For WSP solutions ensure you have installed them to correct target
– ‐AddToLatestVersion

required for 2010 Site Definitions to “work” in 15 mode

• For 3rd party components/services
– Ensure you have 15 compatible components installed – May also need to install 2010 components to make 14 mode work • Check with vendor for details

SECURITY ISSUES • PowerShell content/service  database upgrades
– DBO access to content or services  databases – Read/write access to configuration  database

• PowerShell service upgrades
– DBO access to all services databases  that are being upgraded – Read/write access on configuration  database – Local box admin access

• PowerShell upgrade of site  collections
– Site Collection administrator rights – Read/write access to content  database – Read/write access to configuration  database

• PowerShell/PSConfig farm  upgrades
– DBO access on all content and  services databases that are being  upgraded – Read/write access on configuration  database – Local box admin access

• UI Upgrade of site collections
– Site Collection administrator rights