初始同步生成 mof 时出现 Azure DSC 错误
Azure DSC error on initial sync generating mof
我有一个基于 class 的自定义 DSC 模块。在初始同步过程中,目标计算机尝试在 C:\Windows\System32\dsc 中生成 MOF,这会导致错误 - 这会导致初始同步报告失败,即使所有单独的配置资源任务都显示为成功。那些基于未生成MOF的资源的报告成功,但实际上根本没有执行。
这是错误:
{
"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"
}
}]
}
我试过手动生成 MOF 并将其包含在模块中,但这没有帮助(或者我做错了)。尽管这是基于 class 的资源,但我在 \DSCResources\ className
\ classname
中添加了名称为 class 的 MOF。schema.mof 文件。我注意到在 C:\windows\system32\dsc 文件夹中生成的那个包含版本号,而我的没有。也许这就是问题所在。
初始同步失败后,后续的一致性检查确实通过了,并且在错误消息中提到的位置创建了 MOF。
class 本身包含一个调用 Import-Module Azure.Storage
的函数,该函数由不同的 DSC 资源安装在机器上,并且已在一致性检查点安装,但是(显然)不是在初始同步开始的时候。安装模块的资源在配置中被标记为 class-资源的依赖项,但我认为 MOF 生成必须发生在模块部署时,逻辑上在初始同步 运行.
至少我是这么认为的。
如果有人能指导我在这种情况下可以做什么,以及我的假设(以上)是否正确,将不胜感激?我似乎无法从 MOF 编译过程本身获得任何其他错误或遥测来查看为什么 MOF 编译失败。
@Mods 我真的不清楚在什么基础上这会被否决 - 我不认为问一个没人能回答的问题是 "punishment".[=27 的真正理由=]
发布一个答案,因为没有人真的可以在这里做出任何贡献,而我似乎
我自己解决了。我认为这个问题是时间问题。 DSC 依赖模块从拉取服务器交付,并在 执行它们中的任何一个之前编译。我的 class 模块对 Azure.Storage
的依赖意味着无法编译 .psm1
文件(因为该模块在机器上还不存在——它将通过 DSC 进行开发稍后资源)。
也许有某种机制可以解决基于 PS 的模块中的这些依赖关系,或者应用了一些宽大处理,但基于 class 的资源并非如此。还是不清楚。
经过一些实验后,我开始创建和传送 MOF 文件以及 psm1
和 psd1
文件,而不是在我的问题中概述的 DSCResources...
子文件夹中,并且这似乎已经解决了问题。
希望这对某人有所帮助,不会吸引更多反对票。
我有一个基于 class 的自定义 DSC 模块。在初始同步过程中,目标计算机尝试在 C:\Windows\System32\dsc 中生成 MOF,这会导致错误 - 这会导致初始同步报告失败,即使所有单独的配置资源任务都显示为成功。那些基于未生成MOF的资源的报告成功,但实际上根本没有执行。
这是错误:
{
"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"
}
}]
}
我试过手动生成 MOF 并将其包含在模块中,但这没有帮助(或者我做错了)。尽管这是基于 class 的资源,但我在 \DSCResources\ className
\ classname
中添加了名称为 class 的 MOF。schema.mof 文件。我注意到在 C:\windows\system32\dsc 文件夹中生成的那个包含版本号,而我的没有。也许这就是问题所在。
初始同步失败后,后续的一致性检查确实通过了,并且在错误消息中提到的位置创建了 MOF。
class 本身包含一个调用 Import-Module Azure.Storage
的函数,该函数由不同的 DSC 资源安装在机器上,并且已在一致性检查点安装,但是(显然)不是在初始同步开始的时候。安装模块的资源在配置中被标记为 class-资源的依赖项,但我认为 MOF 生成必须发生在模块部署时,逻辑上在初始同步 运行.
至少我是这么认为的。
如果有人能指导我在这种情况下可以做什么,以及我的假设(以上)是否正确,将不胜感激?我似乎无法从 MOF 编译过程本身获得任何其他错误或遥测来查看为什么 MOF 编译失败。
@Mods 我真的不清楚在什么基础上这会被否决 - 我不认为问一个没人能回答的问题是 "punishment".[=27 的真正理由=]
发布一个答案,因为没有人真的可以在这里做出任何贡献,而我似乎
我自己解决了。我认为这个问题是时间问题。 DSC 依赖模块从拉取服务器交付,并在 执行它们中的任何一个之前编译。我的 class 模块对 Azure.Storage
的依赖意味着无法编译 .psm1
文件(因为该模块在机器上还不存在——它将通过 DSC 进行开发稍后资源)。
也许有某种机制可以解决基于 PS 的模块中的这些依赖关系,或者应用了一些宽大处理,但基于 class 的资源并非如此。还是不清楚。
经过一些实验后,我开始创建和传送 MOF 文件以及 psm1
和 psd1
文件,而不是在我的问题中概述的 DSCResources...
子文件夹中,并且这似乎已经解决了问题。
希望这对某人有所帮助,不会吸引更多反对票。