Test Upgrade Name Title Company 9/18/2018 Microsoft SharePoint © 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

Upgrade Cycle Learn Prepare Test Implement Validate Upgrade methods New capabilities Downtime mitigation Prepare Document environment Manage customizations Plan upgrade strategy Make items upgradable Test Build test farms Use real data Evaluate techniques Find issues early Implement Build/upgrade farms Deploy customizations Minimize downtime Monitor progress Validate Troubleshooting Upgrade event failures UI/UX issues Data issues

Test Upgrade Building Test Farms

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 prevent flaws occurring only in production Use similar hardware if possible To identify trouble areas To determine upgrade performance Test a copy of everything, not just a sample 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 You only really know what you have tested The unexpected lurks in the databases you didn’t test Gives excellent indication of actual upgrade performance and issues Use production processes in test environment Make sure to pave test environment before doing actual upgrade

Test Upgrade Evaluation Techniques

Upgrade Testing Cycle Test Environment Learn Prepare Test Implement Upgrade methods New capabilities Downtime mitigation Prepare Document environment Manage customizations Plan upgrade strategy Make items upgradable Test Build test farms Use real data Evaluate techniques Find issues early Implement Build/upgrade farms Deploy customizations Minimize downtime Monitor progress Validate Troubleshooting Upgrade event failures UI/UX issues Data issues Test Environment Implement Build/upgrade farms Deploy customizations Minimize downtime Monitor progress Validate Troubleshooting Upgrade event failures UI/UX issues Data issues Learn Upgrade methods Downtime mitigation Performance Understand issues

Expectations From Testing Understand upgrade methods and processes Know what works Know what the outcome will be Understand performance and downtime mitigation Should have a good guess on downtime Should know per database how long upgrade will take Gain experience and confidence in troubleshooting and validation Know your enemy Where it lurks What it looks like Know how to make it right again

Test Upgrade Testing Processes

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

Test Upgrade Performance Testing

Upgrade Performance Testing Actual hardware + actual databases = reliable results Measure sequences and actions Parse individual upgrade logs for performance data Use multiple upgrade runs per database for more accuracy Collate multiple runs results to get likely performance per sequence/action/database Determining upgrade performance per sequence/action Parse upgrade logs Collate time spent per action instance per log Collate time spent in each sequence per log Separate out database upgrade times from site collection upgrade times Mainly look for min, max, and average

Post-Upgrade Performance Testing Confirm against pre-upgrade performance goals Ensure your new farm is not going to give less than you expect Look for SQL responsiveness at load Disk queue length CPU and memory usage Look for SharePoint servers responsiveness at load Requests Per Second (RPS) Page Load Time Initial clean request, loading scripts for first time (PLT1) Secondary requests with scripts cached at client (PLT2)

Test Upgrade Testing Service Applications

Service Applications Testing Consider various states you may be in, not just initial or final state 2010 farm connected to 2013 services 2013 farm connected to 2013 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

Test Upgrade Testing Customizations

Deploying Customizations Ensure solutions are deployed Consider that legacy solution deployment with default will result in being only in 14 directories Deploy legacy solutions to 15 directories if required using CompatibilityLevel option on Install-SPSolution command 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

Microsoft SharePoint Server 2013 Test Upgrade Conclusion Building Test Farms Evaluation Techniques Testing Processes Performance Testing Testing Service Applications Testing Customizations © 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

Q&A

9/18/2018 1:20 PM © 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION. © 2010 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.