As an administrator, you will be faced with troubleshooting a broken site. Often, changes and customizations by developers or administrators lead to problems that may not be evident immediately. Often, issues are not addressed until a breaking change is found during an upgrade. The first of the tools at our disposal to help us in troubleshooting is the Test-SPOSite command.
The command allows you to check several rules against your site collection, producing a report that will help you to take action. By default, the command will return a result with an array of all the rules tested and individual results:
Test-SPOSite -Identity $siteUrl
SiteUrl : https://mytest321.sharepoint.com/sites/testA1
Results : {
SPSiteHealthResult Status=Passed RuleName="Conflicting Content Types"
RuleId=befe203b-a8c0-48c2-b5f0-27c10f9e1622,
SPSiteHealthResult Status=FailedWarning RuleName="Customized Files"
RuleId=cd839b0d-9707-4950-8fac-f306cb920f6c,
SPSiteHealthResult Status=Passed RuleName="Missing Galleries"
RuleId=ee967197-ccbe-4c00-88e4-e6fab81145e1,
SPSiteHealthResult Status=Passed RuleName="Missing Parent Content Types"
RuleId=a9a6769f-7289-4b9f-ae7f-5db4b997d284...}
PassedCount : 6
FailedWarningCount : 1
FailedErrorCount : 0
The response shows us that one of the rules has a warning; let's produce a list of all the rules tested first, and we will dig further on the rule with the issue.
In the following code, we iterate over the results and select the rule's name and ID:
$testResult = Test-SPOSite -Identity $siteUrl
$testResult.Results | Select @{N='Name'; E= {$_.Rule.Name}}, @{N='Id'; E= `
{$_.Rule.Id}}
Name Id
---- --
Conflicting Content Types befe203b-a8c0-48c2-b5f0-27c10f9e1622
Customized Files cd839b0d-9707-4950-8fac-f306cb920f6c
Missing Galleries ee967197-ccbe-4c00-88e4-e6fab81145e1
Missing Parent Content Types a9a6769f-7289-4b9f-ae7f-5db4b997d284
Missing Site Templates 5258ccf5-e7d6-4df7-b8ae-12fcc0513ebd
Unsupported Language Pack References 99c946f7-5751-417c-89d3-b9c8bb2d1f66
Unsupported MUI References 6da06aab-c539-4e0d-b111-b1da4408859a
Now let's identify the rule that failed and print its description:
ForEach ($rule in $testResult.Results | Where { $_.Status -ne 'Passed' }) {
Write-Host $rule.Message
}
The following files have been customized from their default and may present some unexpected visuals or behavior after upgrade:
- https://mytest321.sharepoint.com/sites/testA1/default.aspx - <a href="...">Reset page to default</a>
Reset specific pages to default to make the page lose customizations and any embedded data. Normally, you should do this only if you are having difficulty using the page after upgrade.
Customized or unghosted pages are one of the most common issues that affect an upgrade. The preceding message shows the URL of the customized page and the suggested action.
Often, addressing individual pages or items individually is impossible due to availability resources, or the number of occurrences. Alternatively, the Request-SPOUpgradeEvaluationSite command will create a copy of the site collection so you can attempt the upgrade without affecting the original site collection. This approach is often helpful in identifying false positives (customized pages may work depending on many factors) and often shows issues that a simple test was not able to identify:
Request-SPOUpgradeEvaluationSite [-Identity] <SpoSitePipeBind> ^
[-Confirm [<SwitchParameter>]] [-NoEmail <SwitchParameter>] ^
[-NoUpgrade <SwitchParameter>] [-WhatIf [<SwitchParameter>]]
The command will send an email to the administrator unless the NoEmail parameter is used. The NoUpgrade command allows you to make changes before scheduling the upgrade. To perform an upgrade, we will use the Upgrade-SPOSite command:
Upgrade-SPOSite [-Identity] <SPOSitePipeBind> [-VersionUpgrade] `
[-NoEmail] [-WhatIf] [-Confirm]
This is another command that requires the scripting account to be a site collection administrator. At the time of writing, we cannot test this method since only one version is allowed. Since SharePoint Online changes have been pushed at a much faster pace, it is conceivable that we will not see a major version in the foreseeable future. The relevance of the upgrade methods will most likely diminish as Microsoft switches to small but steady functionality deployments.
We will finish this section with the methods related to deleting site collections. On-premise site collection deletions used to be unrecoverable unless you had backups. In Office 365, the Recycle Bin concept has been implemented for site collections. Deleting a site moves it to the Recycle Bin, making the site unavailable. You have 30 days to restore the site; after this, the site collection will be deleted permanently.
The following script shows how to delete a site, confirm that it is in the Recycle Bin, and then restore it and delete it permanently:
$siteUrl = 'https://mytest321.sharepoint.com/sites/testA1'
Remove-SPOSite $siteUrl -Confirm:$false
Get-SPODeletedSite
Url Storage Quota Resource Quota Deletion Time Days Remaining
--- ------------- -------------- ------------- --------------
https://mytest321..../sites/testA1 26214400 0 2/21/2017 4:58:48 AM 30
Restore-SPODeletedSite $siteUrl
Remove-SPOSite $siteUrl -Confirm:$false
Remove-SPODeletedSite $siteUrl -Confirm:$false