SharePoint 2013 Upgrade Best Practices Artur Santos Rumos artur.santos@rumos.pt
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 ATTACHUPGRADE 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
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 DATABASES NOT SUPPORTING DATABASE ATTACH UPGRADE
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
UPGRADEEVALUATION 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 EVENTNOTIFICATIONS 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 UPGRADETHROTTLING 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 ANDFEATURE/TEMPLATES SP2013 Content Database SPSite SPWeb Feature Feature Feature Feature SPSite SPWeb Feature Feature Feature Feature Feature Feature Site Definition Site Definition Feature Definition Feature Definition Template STS#1 Feature Definition Feature Definition Template STS#1 Feature Definition Feature Definition Template STS#2 Feature Definition Feature Definition Template STS#2 Feature Definition Feature Definition 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. 3 rd 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 Services: Cross farm topology Database names Service Settings Installed customizations Farm/Web Application: Alternate Access Mappings (AAM) Authentication Methods/Providers Managed paths Installed/registered features Installed customizations Web.config modifications
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 GAC Web.config file differences 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 Visually impacting Data structure impacting Non visually impacting Master Pages Themes Web Pages Web Parts Content Types List Types Web Templates Site Definitions Web Services Windows Services HTTP Handler HTTP Module
VISUAL IMPACTINGCUSTOMIZATIONS 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 IMPACTINGCUSTOMIZATIONS 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 the ability to fix issues in product without help Source code rarely available Need to work closely with 3rd party to get updates to work with SP2013 May require additional special upgrade instructions 3rd party applications can include following which have higher possibility of issues: Windows services Windows applications Web applications HTTP modules MSI installed 2010 customizations may be incompatible with SP2013 Check with 3rd party for updated SP2013 compatible MSIs In some cases consider reevaluating 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
UPGRADETESTING CYCLE Learn Validate Troubleshooting Upgrade event failures UI/UX issues Data issues 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 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 Consider that default deployment will result in being only in 14 directories Deploy solutions to 15 directories if required using AddToLatest option If not using solutions ensure deployment of: Custom Master pages Custom JavaScript Custom CSS (including those for themes) Custom workflow actions must be included in actions file To ensure rendering for larger lists, confirm large list query throttling settings
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. Restore copy of old version service database(s) to SQL Can be done using command line or SQL Management Studio 2. 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. Create the service application proxy using the new service application cmdlet applicable for that service type 4. Start the applicable service(s) instance Special operations needed for Search, and Secure Store
SPECIAL PROCEDURES FOR SERVICE UPGRADE Search 1. Migrate Admin Database Restore SPEnterpriseSearchServiceApplication 2. 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. Create the service application proxy using the new service application cmdlet applicable for that service type 4. 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
UPGRADELOG 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
1. Determine cause of failure Follow exceptions from source to ULS using correlation Id and timestamp Exceptions shown on UI Exceptions in event logs 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 Try to repro issue If necessary reach out to who was using system, especially for UI issues POST UPGRADE TROUBLESHOOTING STEPS 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 3. Confirm the fix If a repro of the issue was possible before, see if the issue still occurs You are done once the issue no longer occurs 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 Site Collections / Webs 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 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 CREATE NEW VALIDATION TARGETS 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 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
VERIFY SERVICES FUNCTIONALITY Search Crawls content farm sources Crawls external sources Ensure scopes and best bets work Profile and social features Profile sync occurs My Site Host works Check in 14 or 15 mode Managed Metadata Taxonomy data exists Business Connectivity Service Existing connections work Secure Store (SSS) Application definitions exist Passwords retained Access Services Excel Services Excel Web Access Web parts render Visio Services Rendering Visio files Office Web Accessible Clients PowerPoint, Excel, Word Rendering correctly Open and save documents
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
Validate services connections InfoPath connections BCS connections Excel Services connections Search crawl external targets Confirm connections work for all applicable users Check for other common users not just administrators Connection strings may need to be edited Can be defined connection files, or embedded within files (Excel, InfoPath) Authentication method may need to be changed EXTERNAL DATA SOURCES 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 Claims issues may impact use Services may be incorrectly set up Machine/network filtering may be clocking 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 PARTISSUES 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 3 rd 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 upgrade of site collections Site Collection administrator rights Read/write access to content database Read/write access to configuration database UI Upgrade of site collections Site Collection administrator rights PowerShell service upgrades DBO access to all services databases that are being upgraded Read/write access on configuration database Local box admin access 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