Troubleshoot custom DSC resource runnin in LCM

I have written two custom DSC resources that use the IIS WebAdministration module. One resource uses the Get-WebConfigurationProperty command (FMGlobal_WebConfigurationProperty), and the other uses Get-WebConfiguration command (FMGlobal_WebConfigurationMetadata). I uses these resources as part of the configuration to configure IIS which results in updates to the applicationHost.config file. The custom resource that uses Get-WebConfigurationProperty works fine when invoked by the LCM, but the one that wraps Get-WebConfiguration results in the following error getting logged to the DSC operational log:

Log Name: Microsoft-Windows-DSC/Operational
Source: Microsoft-Windows-DSC
Date: 5/22/2014 11:52:19 AM
Event ID: 4103
Task Category: None
Level: Error
Computer: (hidden)
Job {A68F50C6-FE06-48D0-A5C4-F9BD7C9252E3} :
This event indicates that a non-terminating error was thrown when DSCEngine was executing Test-TargetResource on FMGlobal_WebConfigurationMetadata provider. FullyQualifiedErrorId is System.IO.FileNotFoundException,Microsoft.IIs.PowerShell.Provider.GetConfigurationCommand. ErrorMessage is Could not load file or assembly ‘Microsoft.WSMan.Management’ or one of its dependencies. The system cannot find the file specified…

If I log onto the server I can successfully execute the Get-TargetResource, Test-TargetResource, and Set-TargetResource functions from the PowerShell command line.

How can I troubleshoot this as the problem only exists when the resource is executed by the LCM?

It may be tough to troubleshoot it directly. It likely has something to do with the user context (SYSTEM) that the LCM runs under; it may not be spinning up enough of a profile, for example, to know where to find the assembly.

Tricky. Let me ask around.

The custom resource works fine when the LCM on my windows 7 machine runs the configuration, which runs as SYSTEM. The problem is consistent on two different ws2008R2 servers. I can also successfully execute the Get-, Set-, and Test- functions on both servers from the PS command line. Rrrr…

It may well be something version specific then. Or a bug.

Does seem like a bug, I tried running the following on a Server 2012 R2 machine and got your error:

Add-Type -Assembly Microsoft.WSMan.Management -verbose

However, the above worked find on my Windows 8.1 laptop. I then tried the following on a Server 2012 R2 machine:

Add-Type -Assembly Microsoft.WSMan.Management -verbose

…and it worked fine. That tells me it has to do with the .NET framework binding to the appropriate version of the WSMAN assembly.

If you enable fusion logs

    DWORD  ForceLog set value to 1
    DWORD  LogFailures set value to 1
    DWORD  LogResourceBinds set value to 1
    String LogPath set value to folder for logs (e.g. C:\FusionLog\)

You’ll notice, during failures, the server tries to load “Version=” instead of “version=” and failing. I think the fusion log should give you some clues on what’s happening.

…Or possibly just use a “Test-WSMan” before you run the “Get-WebConfiguration” cmdlet :slight_smile:


For some unknown reason, this just started working. This is good, but doesn’t explain why it was failing earlier.

I’ll have to keep an eye on it…