2017-04-05 13 views
1

Get-WmiObject Win32_Serviceを使用して実行中のサービスと現在の状態を列挙するPowershellスクリプトがあります。最初のバージョンはthis oneに基づいており、Azure用に変更されています。私がPowershellでスクリプトを実行すると(私の場所のマシン上のぼんやりした自動化部分なしで)、それはうまく動作し、関心のあるすべてのマシンに接続することができます。しかし、runbookに移植すると、次のエラーが出ます: "Get-WmiObject :RPCサーバーは利用できません。Azureランブックを使用したAzure VMの監視サービス

Q:オートメーションアカウントのアクセス許可に問題がありますか?その場合は、問題を解決するためにローカルマシンにどのアカウントを追加する必要がありますか?

Q:Get-WmiObjectは接続を開始する有効な方法ではありませんか?そうでない場合は、代わりに何を試すべきですか?

私が使用しているコードは以下の通りです:

[CmdletBinding(SupportsShouldProcess = $true)] 
param(

    # Servers to check 
    [Parameter(Mandatory=$true)][string[]]$ServerList, 

    # Services to check for 
    [Parameter(Mandatory=$true)][string[]]$includeService 
    ) 

# Following modifies the Write-Verbose behavior to turn the messages on globally for this session 
$VerbosePreference = "Continue" 

$connectionName = "AzureRunAsConnection" 

# retry 
$retry = 6 
$syncOk = $false 

$servicePrincipalConnection = Get-AutomationConnection -Name $connectionName 
do 
{ 
    try 
    { 
     Add-AzureRmAccount -ServicePrincipal -TenantId $servicePrincipalConnection.TenantId -ApplicationId $servicePrincipalConnection.ApplicationId -CertificateThumbprint $servicePrincipalConnection.CertificateThumbprint 
     $syncOk = $true 
    } 
    catch 
    { 
     $ErrorMessage = $_.Exception.Message 
     $StackTrace = $_.Exception.StackTrace 
     Write-Warning "Error during sync: $ErrorMessage, stack: $StackTrace. Retry attempts left: $retry" 
     $retry = $retry - 1  
     Start-Sleep -s 60   
    } 
} while (-not $syncOk -and $retry -ge 0) 

Select-AzureRMSubscription -SubscriptionId $SubscriptionId -TenantId $servicePrincipalConnection.TenantId 
$currentSubscription = Get-AzureRMSubscription -SubscriptionId $SubscriptionId -TenantId $servicePrincipalConnection.TenantId 
Set-AzureRmContext -SubscriptionId $SubscriptionId; 

[email protected]() 

[System.Collections.ArrayList]$unreachableServers = @() 

Foreach($ServerName in ($ServerList)) 
{ 
    try 
    { 
     $service = Get-WmiObject Win32_Service -ComputerName $servername 
    } 
    catch 
    {} 

    if ($Service -ne $NULL) 
    { 
     foreach ($item in $service) 
     { 
      #$item.DisplayName 
      Foreach($include in $includeService) 
      {       
        #write-host $include          
       if(($item.name).Contains($include) -eq $TRUE) 
       { 
        $props += [pscustomobject]@{ 
        servername = $ServerName 
        name = $item.name 
        Status = $item.Status 
        startmode = $item.startmode 
        state = $item.state 
        serviceaccount=$item.startname 
        DisplayName =$item.displayname} 
       } 
      } 
     } 
    } 
    else 
    { 
     Write-host "Failed to contact server: "$ServerName 
     $unreachableServers.Add($ServerName) 
    } 
} 

$props | Format-Table Servername,Name,startmode,state,serviceaccount,displayname -AutoSize 

答えて

0

私はあなたがAzure Automation Hybrid Worker機能を使用していると仮定しています。デフォルトでは、システムアカウントで実行されます。しかし、別のアカウントを使ってランブックを実行することができます。これはここに文書化されています:Azure Automation Hybrid Worker; RunAsアカウントのセクションを見てください。それを直接試すときに動作する同じアカウントを使用してください。

+0

はい、これは私が最終的に行った解決策です。要約:1)カスタムハイブリッドワーカーグループを作成しました。2)そのグループにAD資格を関連付けて、問題のマシンに対する権限を持っていました。 3) "RunAs"パラメータを持つハイブリッドワーカーグループの下でランブックを走らせた – user2766185

0

あなたはOMSを使用して検討していますか?これはより良いことのように聞こえる。

とにかく、私はおそらくローカルユーザーを作成し、そのユーザーが接続するためのPS構成エンドポイントを作成し、そのユーザーをオートメーションアカウントから偽装するように接続しますが、このルートでは、むしろOMSを使用したいと思います。

+0

Windowsサービスは、停止またはクラッシュすると常にイベントログに書き込みますか? – user2766185

+0

は、サービスに依存していることは明らかです。 – 4c74356b41

+0

OMSは、サービスのステータスを確認するためにサービスに直接問い合わせを行いますか?それがなければ、サービスがすべての状態変化をログに記録しないと、OMSはサービスクラッシュを逃してしまう可能性がありますが、より直接的なアプローチはより信頼性高く機能するようです。 – user2766185

関連する問題