SharePoint 2013 – Sorry, something went wrong

Following some work on SharePoint, users were encountering the error “Sorry, something went wrong.  The context has expired and can no longer be used. (Exception from HRESULT: 0x80090317)”

SP-Content-Expired-0

Searching the web uncovered suggestions to change the claims token timeout value, reducing it from its default value of 24 hours, to something much lower, like 1 hour.  You can check the current value, shown in minutes, using the command below.

stsadm.exe -o getproperty -propertyname token-timeout

In my case the value had already been reduced to 1 hour, so I decided to set it back to the default of 24 hours using the command below.  This resolved the error.

stsadm.exe -o setproperty -propertyname token-timeout -propertyvalue 1440

Advertisements

Windows cannot install required files error 0x80070570

I recently encountered an issue where a server wouldn’t install any Windows Updates, whether directly from Microsoft, or if downloaded from the Windows Update Catalog.  The error message received was “Windows cannot install required files error 0x80070570” and this is how I resolved the error.

From an administrative command prompt I ran the System File Checker using sfc /scannow.  This stopped with an error at 36%.  The log for sfc is in the %windir%\Logs\CBS folder.

Next, I used the Deployment Image Servicing and Management (DISM) tool to perform a health scan of the Windows system files.  Again, I ran this from an administrative command prompt, Dism /Online /Cleanup-Image /ScanHealth, but it showed no errors.

WUError-1

Despite the fact no corruption was detected, I ran the following command to fix corruption, Dism /Online /Cleanup-Image /RestoreHealth.  In my case, rather than using Windows Update to retrieve fresh files, I used the /Source switch to point to a copy of the SXS folder from a Windows installation ISO.

WUError-2

Having fixed the corruption Windows Updates now installed.

SQL Server backup performance on Azure Premium Storage

In this post I’ll show the results of some basics tests I carried out to identify the optimum number of SQL Server backup files to use when backing up to an Azure Premium Storage P30 disk with two different VM sizes.

The tests were carried out using SQL Server 2016 Standard SP2 on Windows Server 2016.  All drives were formatted with a 64K allocation size and backup compression was enabled.   The database was 123GB with 9GB free space.

The virtual machine configuration was:

  • DS14-8 v2 8 cores and 112GB RAM
  • 1x P30 with read caching enabled for database data files
  • 1x P30 with caching disabled for database log files
  • 1x P30 with caching disabled for backup files

The DS14-8 v2 supports 51,200 IOPs and 768MBps throughput, so has capacity to support the 15,000 IOPs and 600MBps that the 3x P30 disks can generate.  The results show that only two backup files are required for close to peak performance.

1 backup file: 152.648 MB/sec

2 backup files: 192.484 MB/sec

4 backup files: 198.223 MB/sec

8 backup files: 194.735 MB/sec

I then resized the VM to a DS13 v2, to see if the reduced VM storage capability would impact the backup performance.  The DS13 v2 has 8 cores, 56GB RAM and supports 25,600 uncached IOPs and 384MBps throughput.  The IOPs capability is sufficient to support all three P30 disks, but the throughput could be limiting.  However, the results show very little difference.

1 backup file: 150.416 MB/sec

2 backup files: 192.969 MB/sec

4 backup files: 194.692 MB/sec

8 backup files: 194.561 MB/sec

Monitor Azure events with Logic Apps – follow up

Following on from my earlier post “Monitor Azure events with Logic Apps” I’ll now show how to add additional control within the Logic App to only alert on events related to virtual machine changes and how to surface additional event information in the email.

Firstly edit the Logic App in the designer and click the + between the event and email steps and choose Add an action.

EG0

From the Choose an action screen select Control.

EG1

Select Condition.

EG2

Click into the “Choose a value” box, select Expression and enter triggerBody()?[‘data’][‘operationName’] and click ok.

EG3

In the next box select “is equal to” and in the value box enter Microsoft.Compute/virtualMachine.

EG4

Drag the “Send an email” action into the “If true” box.

EG5

These changes ensure the Logic App will only send an email for operations related to virtual machines.

If you would like to include additional event information in the email beyond those in the Dynamic content selection it’s easy to achieve.  From the Logic App page click on runs history.  Click on “When a resource event occurs” and you can see the JSON on the event. Click “Show raw outputs” to see the full JSON generated by the event.

EG56

You can include values from the JSON in the email using the expression box.  Go back to the “Send an email” action and click on the email body.  In the Expression box enter the path to the JSON value, e.g. triggerBody()?[‘data’][‘operationName’] to include the operation name or triggerBody()[‘data’][‘claims’][‘http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name’%5D to include the name of the user that carried out the action.

EG7

 

Office 365 ProPlus installation detection with System Center Configuration Manager (SCCM)

Microsoft have a good guide showing how to deploy Office 365 ProPlus with System Center Configuration Manager (SCCM), see here.  Within the guide there’s a section  showing the detection rule to use.  However, I’ve found the registry detection method doesn’t work and Office 365 ProPlus will install, but Software Centre will show the installation as failed.

The Microsoft guide has the following configuration, which I’ve found to not work.

O365PP0

This is the detection method I use.  If you update the detection method, run a machine policy retrieval & evaluation cycle on an affected machine to test the change.

O365PP1

Monitor Azure events with Logic Apps

In this post I’ll provide a starting point for monitoring Azure with Logic Apps whereby an email is sent when a successful change is made within an Azure subscription.

To start with, check the Event Grid resource provider is registered within your Azure subscription.  You can do this in the Azure portal under Subscriptions -> Resource providers.

EventGrid0

Next, create a Logic App from the Azure portal, entering a name, resource group and location.

EventGrid1

From the splash screen select the common trigger When a Event Grid event occurs.

EventGrid12

Click the sign in button to connect to your Azure subscription.

EventGrid13

Select your Azure subscription, resource type and resource name.  In this example I’ve selected the subscription, for event monitoring across the entire subscription, but you can choose resource group or something else to scope the alerts further.  I’ve also added an event type filter for WriteSuccess, but again you can adjust as per your requirements.

EventGrid14

 

In this example I’ve chosen to be notified by email, so click on new step, then select Office 365 Outlook, followed by send an email.

EventGrid15

Populate the email body with event information that interests you.

EventGrid16

 

Save the Logic App, then make a change, e.g. resize a VM or create a resource within the subscription to trigger the alert.

If you don’t receive an email check the runs history on the Logic App page.

EventGrid17

If nothing is listed check that the Logic app automatically created the Event Grid subscription.  Search for Event Grid subscriptions in the Azure portal.

EventGrid18

If nothing is listed re-register the EventGrid resource provider in your Subscription.  I did this using Azure Cloud Shell Register-Azure RmResource Provider -ProviderNamespace Microsoft.EventGrid.

EventGrid19

Once you have the basics working you can customise further, e.g. to only notify for changes related to virtual machines.  In a future post I’ll show how to do this.

Renaming Azure automation accounts

As of Aug 2018 it’s not possible to rename an Azure automation account, but this is the next best thing.  There are number of limitations to this approach, including the requirement to recreate schedules and a number of other automation account settings and configurations, but if you have a simple setup it’s worthwhile.

  • Bulk export the runbooks from the incorrectly named automation account using the Export-Azure RmAutomation Runbook PowerShell cmdlet.
  • Create a new automation account with the desired name.
  • Bulk import the exported runbooks into the new automation account using the Import-Azure RmAutomation Runbook PowerShell cmdlet.  Use the -Published switch to save time having to manually publish each runbook post import.
  • Recreate and link any schedules and other configurations.
  • Import any modules required by your runbooks.
  • Update the existing modules as they’re not the latest available when you create the account.