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
Keywords:
User: SYSTEM
Computer: (hidden)
Description:
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.
Update…
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…
…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
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion
Add:
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=1.0.0.0” instead of “version=3.0.0.0” 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
