Azure DSC error on initial sync generating mof

Question

I have a custom DSC module which is class based. During the initial sync process the target machine tried to generate a MOF in C:\Windows\System32\dsc which results in an error - this causes the initial sync to report as failed, even though all the individual configuration resource tasks show as succeeded. The ones that are based on the resource who's MOF was not generated report as succeeded, but in fact have not executed at all.

This is the error:

{
    "JobId": "4deeaf52-aa56-11e6-a940-000d3ad04eaa",
    "OperationType": "Initial",
    "ReportFormatVersion": "2.0",
    "ConfigurationVersion": "2.0.0",
    "StartTime": "2016-11-14T21:37:14.2770000+11:00",
    "Errors": [{
        "ErrorSource": "DSCPowershellResource",
        "Locale": "en-US",
        "Errors": {
            "Exception": {
                "Message": "Could not find the generate schema file dsc\tBlobSync.1.4.tAzureStorageFileSync.schema.mof.",
                "Data": {

                },
                "InnerException": null,
                "TargetSite": null,
                "StackTrace": null,
                "HelpLink": null,
                "Source": null,
                "HResult": -2146233079
            },
            "TargetObject": null,
            "CategoryInfo": {
                "Category": 6,
                "Activity": "",
                "Reason": "InvalidOperationException",
                "TargetName": "",
                "TargetType": ""
            },
            "FullyQualifiedErrorId": "ProviderSchemaNotFound",
            "ErrorDetails": null,
            "InvocationInfo": null,
            "ScriptStackTrace": null,
            "PipelineIterationInfo": []
        },
        "ErrorCode": "6",
        "ErrorMessage": "Could not find the generate schema file dsc\tBlobSync.1.4.tAzureStorageFileSync.schema.mof.",
        "ResourceId": "[tAzureStorageFileSync]CDrive"
    }],
    "StatusData": [],
    "AdditionalData": [{
        "Key": "OSVersion",
        "Value": {
            "VersionString": "MicrosoftWindowsNT10.0.14393.0",
            "ServicePack": "",
            "Platform": "Win32NT"
        }
    },
    {
        "Key": "PSVersion",
        "Value": {
            "CLRVersion": "4.0.30319.42000",
            "PSVersion": "5.1.14393.206",
            "BuildVersion": "10.0.14393.206"
        }
    }]
}

I have tried manually generating the MOF and including it in the module, but that didn't help (or perhaps I did it wrong). Even though this is a class-based resource I added the MOF with the name of the class in a \DSCResources\ className \ classname .schema.mof file. I note that the one generated in the C:\windows\system32\dsc folder includes the version number, which mine does not. Perhaps that's the problem.

After the failed initial sync, the subsequent consistency check does pass, and the MOF is created at the location mentioned in the error message.

The class itself contains a function that calls Import-Module Azure.Storage which is installed on the machine by a different DSC resource, and has been installed at the point of the consistency check, but (obviously) not at the point the initial sync starts. The resource that installs the module is marked as a dependency of the class-resource in the configuration, but I think MOF generation must happen at the point the modules are deployed which is logically before the initial sync has run.

At least that's what I think is happening.

Would be grateful if anyone could instruct me on what can be done in this instance, and whether my assumptions (above) are correct? I can't seem to get any additional errors or telemetry from the MOF compilation process itself to see why the MOF compilation is failing.

Answer 1

@Mods I'm really not clear on what basis this would be downvoted - I don't think asking a question nobody can answer is really grounds for "punishment".

Posting an answer as nobody really had anything to contribute here and I appear to have solved it on my own. I believe the issue is a matter of timing. The DSC dependent modules are delivered from the pull server and compiled before any of them are executed. The dependency of my class module on Azure.Storage meant that the .psm1 file couldn't be compiled (since the module didn't exist on the machine yet - it would be devlivered via a DSC resource at a later time).

Perhaps there is some mechanism that accounts for these dependencies in PS-based modules, or there is some leniency applied that isn't the case for class-based resources. That's still not clear.

After some experimentation I have begun creating and shipping the MOF files alongside the psm1 and psd1 file, rather than in the DSCResources... child folder as outlined in my question, and this appears to have resolved the issue.

Hopefully this helps someone and doesn't attract more downvotes.