Azure Automation中Hashtable未被识别为哈希表的问题

我之前也踩过完全一样的坑——Azure Automation的PowerShell运行环境和本地ISE差异很大，核心问题出在对象序列化/反序列化上。当你在Automation作业中获取$vm.Tags时，它看起来是哈希表，但实际可能已经被转换成了PSCustomObject（或者其他非哈希表类型），哪怕你强制类型转换也没法直接恢复，因为序列化过程已经丢失了哈希表的类型元数据。

下面是几个经过验证的解决方案，按优先级排序：

1. 手动重建哈希表（最可靠） #

不要直接使用$vm.Tags，而是遍历它的键值对重新创建一个真正的哈希表：

# 初始化空哈希表
$tags = @{}

# 遍历原Tags的键值对，逐个添加到新哈希表
if ($vm.Tags) {
    foreach ($key in $vm.Tags.PSObject.Properties.Name) {
        $tags[$key] = $vm.Tags.$key
    }
}

# 现在再执行Set-AzureRmResource
Set-AzureRmResource -ResourceId $_.Id -Tag $tags -Force -Verbose

这种方式能确保$tags是标准的System.Collections.Hashtable类型，Automation的cmdlet能正确识别。

2. 验证并显式转换类型 #

如果想保留原逻辑，可以先检查$vm.Tags的实际类型，再针对性转换：

# 检查当前Tags的类型
Write-Verbose "Original Tags type: $($vm.Tags.GetType().FullName)"

# 如果不是哈希表，就重建
if ($vm.Tags -isnot [System.Collections.Hashtable]) {
    $tags = [System.Collections.Hashtable]::new()
    foreach ($kvp in $vm.Tags.PSObject.Properties) {
        $tags[$kvp.Name] = $kvp.Value
    }
} else {
    $tags = $vm.Tags
}

# 执行更新
Set-AzureRmResource -ResourceId $_.Id -Tag $tags -Force -Verbose

这里用PSObject.Properties来遍历，能兼容序列化后的PSCustomObject结构。

3. 升级Azure模块（长期解决方案） #

你当前使用的AzureRm模块已经被官方弃用，建议切换到Az模块（Azure Automation里可以直接导入最新的Az模块）。新模块在对象类型处理上更严谨，能减少这类序列化问题。切换后对应的cmdlet是Set-AzResource，用法类似。

为什么直接强制转换没用？ #

当Azure Automation在沙盒中运行作业时，所有从Azure服务获取的对象都会被序列化，这个过程会把哈希表转换成PSCustomObject——表面上看键值对都在，但类型已经变了。直接用[system.collections.hashtable]$vm.Tags无法正确转换，因为PSCustomObject没有哈希表的内部结构，必须逐个键值对重新构建。

内容的提问来源于stack exchange，提问作者Norrin Rad