SPDiag Error Creating a Snapshot

  • Article

SPDiag Error Creating a Snapshot

Many people see error messages when attempting to create an SPDiag snapshot. In my experience the root cause is either the PowerShell remoting configuration or the credential delegating group policy. Sometimes this is not obvious if you only see a vague, generic error.

First, consider what happens during a snapshot. There are several steps, as implied by the TechNet description (http://technet.microsoft.com/en-us/library/hh144782.aspx)

You can take snapshots of your farm that aggregate

  • report images
  • farm topology information
  • Unified Logging Service (ULS) logs
  • usage database data.

This makes it easy to consolidate key troubleshooting information about a SharePoint farm and share it with other users or preserve it for comparison and trend analysis.

Errors can arise at any of these steps. As far as I know, you cannot select which steps you want executed other than selecting Light or Full in the Snapshot diaglog.

Report images seem a safe operation. SPDiag is merely turning the report into a picture and storing it in the Export Directory.

The farm topology step is where I see the most errors. To gather the farm topology, SPDiag establishes a remote PowerShell session to each server in the farm, including the database server. If either the PowerShell remoting configuration or the credential delegating group policy is not configured correctly, the snapshot will abort at the first error. You can still find what was collected up to that point in time in the export directory, but no further information is collected. In this scenario you will see the following dialog.

The first question is, where is the error.log file? It is in the export directory. Sometimes you will find a very explicit error description like the following:

05/19/2012 10:39:20 Connecting to remote server failed
with the following error message : The WinRM client cannot process the request.
A computer policy does not allow the delegation of the user credentials to the
target computer. Use gpedit.msc and look at the following policy: Computer
Configuration -> Administrative Templates -> System -> Credentials
Delegation -> Allow Delegating Fresh Credentials. Verify that it is
enabled and configured with an SPN appropriate for the target computer. For
example, for a target computer name "myserver.domain.com", the SPN
can be one of the following: WSMAN/myserver.domain.com or WSMAN/*.domain.com.
For more information, see the about_Remote_Troubleshooting Help topic.

The first step is to verify the PowerShell configuration on the SharePoint farm servers. Open up this page, SharePoint Diagnostic Studio 2010 (SPDiag 3.0). It has the installation requirements and instructions.

We are interested in target server configuration. On each server in the farm, including the database server, Open a PowerShell window as administrator, and run the commands listed in the TechNet article, repeated here:

  • Enable-PSRemoting -force
  • Enable-WSManCredSSP -role Server -force
  • Set-Item WSMan:\localhost\Shell\MaxMemoryPerShellMB 1000
  • Set-ExecutionPolicy RemoteSigned

Now we need to set the PowerShell configuration on the client server. While the TechNet article doesn't mention this, I have found by experience the client server is where you are running SPDiag, even if it is one of the SharePoint farm servers. In my case, SPDiag is installed on the Central Administration server, so I have to execute these PowerShell commands as administrator.

  • Enable-PSRemoting -force
  • Enable-WSManCredSSP -role Client -DelegateComputer “<target_computer>” -force

The question is, What is the correct target_computer value? For a true remote client, it is one or more of the SharePoint servers, like the Central Administration server; but what if you are running SPDiag on farm server? I used the farm server name where SPDiag is installed. In my case, I had to use the Central Administration server FQDN name, even though logically it is not remote from the farm (however, it is remote from the other servers in the farm). 

Please see Enable-WSManCredSSP for details of the command syntax and how to specify multiple target servers. Notice the command expects the FQDN server name(s).

Now that PowerShell is configured for remote execution; that is, SPDiag can now execute PowerShell scripts remotely on the other farm servers from the Central Administration server, we need to address the error message above which refers to credential delegation. What is this all about?

When PowerShell executes a script remotely, it has to execute on the remote machine within a user security context. SPDiag uses the security credentials you enter in the Credential Request prompt to establish the security context on the remote server.

If you enter the Farm Administrator credentials, then the Farm Administrator account has be explicitly configured for remote delegation to be able to execute the remote PowerShell scripts on the other farm servers. This is what the above sample error message is about. It is telling us PowerShell cannot run remote scripts because it has not been authorized to delegate the credentials to the target server(s). The fix is simple. Just follow the step in the error message.

Run the gpedit.msc management console by entering gpedit.msc in the Run box of the Start Menu.

When the console opens, navigate the tree structure to Computer Configuration -> Administrative Templates -> System -> Credentials Delegation -> Allow Delegating Fresh Credentials.

Select the Enable option, and then click the Show button to see the list of servers that can be delegated to.

When the Show Contents window opens, use the Add button to add SharePoint farm servers and the database server. Use the format shown; that is, wsman/ prefixed to the server's NetBIOS name.

Note: It appears SPDiag expects the database server to be a single machine; or the currently active mirror. SPDiag (in my experience) is unable to resolve the logical name of clustered servers. In other words, SPDiag expects the name entered to be an individual server machine, not a cluster name. Hopefully future versions of SPDiag will be able to gracefully handle SQL clusters.

That's it. You should now be able to generate snapshots.