次の方法で共有

入力パラメーターの検証中によく発生するエラーを解決する

  • [アーティクル]

この記事では、入力パラメーターの検証中に発生する可能性があるエラーとその解決方法について説明します。

オンプレミスのパラメーターの作成中に問題が発生した場合は、このスクリプトを使用して支援を受けてください。

このスクリプトは、オンプレミスのパラメーター作成に関連する問題のトラブルシューティングと解決に役立つよう設計されています。 スクリプトにアクセスし、その機能を利用して、オンプレミスパラメーターの作成時に発生する可能性のある問題に対処します。

スクリプトを実行するには、次の手順に従います。

  1. スクリプトをダウンロードし、-Help オプションを使用して実行してパラメーターを取得します。
  2. ドメインに参加しているマシンにドメイン資格情報を使用してサインインします。 マシンは、SCOM マネージド インスタンスに使用されるドメイン内にある必要があります。 サインインした後、指定したパラメーターを使用してスクリプトを実行します。
  3. 検証が失敗した場合は、スクリプトで提案されている修正アクションを実行し、すべての検証に合格するまでスクリプトを再実行します。
  4. すべての検証が成功したら、スクリプトで使用されているのと同じパラメーターを使用してインスタンスを作成します。

検証チェックと詳細

検証 説明
Azure 入力検証チェック
テスト マシンでの前提条件の設定 1.AD PowerShell モジュールをインストールします。
2. グループ ポリシー PowerShell モジュールをインストールします。
インターネット接続 テスト サーバーで送信インターネット接続が使用できるかどうかを確認します。
SQL MI 接続 指定された SQL MI に、テスト サーバーが作成されているネットワークから到達可能かどうかを確認します。
DNS サーバーの接続 指定された DNS サーバーの IP に到達可能で、有効な DNS サーバーに解決されているかどうかを確認します。
ドメイン接続 指定されたドメイン名に到達可能で、有効なドメインに解決されているかどうかを確認します。
ドメイン参加の検証 指定された OU パスとドメイン資格情報を使用して、ドメイン参加が成功するかどうかを確認します。
静的 IP と LB FQDN の関連付け 指定された静的 IP の DNS レコードが、指定された DNS 名に対して作成されているかどうかを確認します。
コンピューター グループの検証 指定されたコンピューター グループが指定されたドメイン ユーザーによって管理されており、マネージャーがグループ メンバーシップを更新できるかどうかを確認します。
gMSA アカウントの検証 指定された gMSA が以下を満たしているかどうかを確認します:
- 有効である。
- DNS ホスト名が指定された LB の DNS 名に設定されている。
- SAM アカウント名の長さが 15 文字以下である。
- 適切な SPN が設定されている。
パスワードは、指定されたコンピューター グループのメンバーが取得できます。
グループ ポリシーの検証 ドメイン (または管理サーバーをホストする OU パス) が、ローカルの Administrators グループを変更する任意のグループ ポリシーの影響を受けるかどうかを確認します。
検証後のクリーンアップ ドメインからの参加を解除します。

検証スクリプトを実行するための一般的なガイドライン

オンボード プロセス中は、検証ステージ/タブで検証が実行されます。すべての検証が成功した場合は、SCOM マネージド インスタンスの作成の最終段階に進むことができます。 ただし、いずれかの検証に失敗した場合は、作成を続行できません。

複数の検証が失敗した場合は、テスト マシンで検証スクリプトを手動で実行して、すべての問題に一度に対処することをお勧めします。

重要

最初に、SCOM マネージド インスタンスの作成用に選択した同じサブネットに、新しいテスト Windows Server (2022/2019) の仮想マシン (VM) を作成します。 その後、AD 管理者とネットワーク管理者の両方がこの VM を個別に利用して、それぞれの変更の有効性を確認できます。 この方法により、AD 管理者とネットワーク管理者の間のやり取りに費やす時間が大幅に節約されます。

検証スクリプトを実行するには、次の手順に従います。

  1. SCOM マネージド インスタンスの作成用に選択したサブネット内に、Windows Server 2022 または 2019 で実行されている新しい仮想マシン (VM) を生成します。 VM にサインインし、SCOM マネージド インスタンスの作成時に使用されたのと同じ DNS IP を使用するように DNS サーバーを構成します。 たとえば、以下を参照してください。

    プロパティのスクリーンショット。

  2. 検証スクリプトをテスト VM にダウンロードし、抽出します。 次の 5 つのファイルで構成されています。

    • ScomValidation.ps1
    • RunValidationAsSCOMAdmin.ps1
    • RunValidationAsActiveDirectoryAdmin.ps1
    • RunValidationAsNetworkAdmin.ps1
    • Readme.txt

  3. Readme.txt ファイルに記載されている手順に従って、RunValidationAsSCOMAdmin.ps1 を実行します。 実行する前に、RunValidationAsSCOMAdmin.ps1 の設定値に該当する値を入力してください。

    # $settings = @{
#   Configuration = @{
#         DomainName="test.com"                 
#         OuPath= "DC=test,DC=com"           
#         DNSServerIP = "190.36.1.55"           
#         UserName="test\testuser"              
#         Password = "password"                 
#         SqlDatabaseInstance= "test-sqlmi-instance.023a29518976.database.windows.net" 
#         ManagementServerGroupName= "ComputerMSG"      
#         GmsaAccount= "test\testgMSA$"
#         DnsName= "lbdsnname.test.com"
#         LoadBalancerIP = "10.88.78.200"
#     }
# }
# Note : Before running this script, please make sure you have provided all the parameters in the settings
$settings = @{
Configuration = @{
DomainName="<domain name>"
OuPath= "<OU path>"
DNSServerIP = "<DNS server IP>"
UserName="<domain user name>"
Password = "<domain user password>"
SqlDatabaseInstance= "<SQL MI Host name>"
ManagementServerGroupName= "<Computer Management server group name>"
GmsaAccount= "<GMSA account>"
DnsName= "<DNS name associated with the load balancer IP address>"
LoadBalancerIP = "<Load balancer IP address>"
}
}

  4. 一般に、RunValidationAsSCOMAdmin.ps1 ではすべての検証が実行されます。 特定のチェックを実行する場合は、ScomValidation.ps1 を開き、ファイルの末尾にある他のすべてのチェックにコメントを付けます。 特定のチェックにブレークポイントを追加して、チェックをデバッグし、問題をよりよく理解することもできます。

        # Default mode is - SCOMAdmin, by default if mode is not passed then it will run all the validations  

    # adding all the checks to result set 

    try { 

        # Connectivity checks 

        $validationResults += Invoke-ValidateStorageConnectivity $settings 

        $results = ConvertTo-Json $validationResults -Compress 

         

        $validationResults += Invoke-ValidateSQLConnectivity $settings 

        $results = ConvertTo-Json $validationResults -Compress 

 

        $validationResults += Invoke-ValidateDnsIpAddress $settings 

        $results = ConvertTo-Json $validationResults -Compress 

 

        $validationResults += Invoke-ValidateDomainControllerConnectivity $settings 

        $results = ConvertTo-Json $validationResults -Compress 

 

        # Parameter validations 

        $validationResults += Invoke-ValidateDomainJoin $settings 

        $results = ConvertTo-Json $validationResults -Compress 

 

        $validationResults += Invoke-ValidateStaticIPAddressAndDnsname $settings 

        $results = ConvertTo-Json $validationResults -Compress 

 

        $validationResults += Invoke-ValidateComputerGroup $settings 

        $results = ConvertTo-Json $validationResults -Compress 

 

        $validationResults += Invoke-ValidategMSAAccount $settings 

        $results = ConvertTo-Json $validationResults -Compress 

             

        $validationResults += Invoke-ValidateLocalAdminOverideByGPO $settings 

        $results = ConvertTo-Json $validationResults -Compress 

    } 

    catch { 

        Write-Verbose -Verbose  $_ 

    }

  1. 検証スクリプトには、すべての検証チェックとそれぞれのエラーが表示され、検証の問題の解決に役立ちます。 迅速な解決を実現するために、ブレークポイントを使用して PowerShell ISE でスクリプトを実行すると、デバッグ プロセスが高速化されます。

    すべてのチェックが正常に完了した場合は、オンボード ページに戻り、オンボード プロセスをもう一度再起動します。

インターネット接続

問題: 送信インターネット接続がテスト サーバーに存在しません

原因: DNS サーバーの IP が正しくないか、ネットワーク構成が正しくないために発生します。

解決策:

  1. DNS サーバーの IP を確認し、DNS サーバーが稼働していることを確認します。
  2. SCOM マネージド インスタンスの作成に使用されている VNet に、DNS サーバーに対する通信経路があることを確認します。

問題: SCOM マネージド インスタンスの製品ビットをダウンロードするためにストレージ アカウントに接続できません

原因: インターネット接続の問題が原因で発生します。

解決策: SCOM マネージド インスタンスと同じサブネット上にテスト仮想マシンを作成し、テスト仮想マシンからの送信接続をテストすることで、SCOM マネージド インスタンスの作成に使用されている VNet に送信インターネット アクセスがあることを確認します。

問題: インターネット接続テストに失敗しました。 必要なエンドポイントが VNet から到達できない

原因: DNS サーバーの IP が正しくないか、ネットワーク構成が正しくないために発生します。

解決策:

  • DNS サーバーの IP を確認し、DNS サーバーが稼働していることを確認します。

  • SCOM マネージド インスタンスの作成に使用されている VNet に、DNS サーバーに対する通信経路があることを確認します。

  • SCOM マネージド インスタンスに送信インターネット アクセスがあり、ファイアウォール要件で説明されているように、NSG/ファイアウォールが必要なエンドポイントへのアクセスを許可するように適切に構成されていることを確認します。

インターネット接続の一般的なトラブルシューティング手順

  1. SCOM マネージド インスタンスの作成用に選択したサブネット内に、Windows Server 2022 または 2019 で実行されている新しい仮想マシン (VM) を生成します。 VM にサインインし、SCOM マネージド インスタンスの作成時に使用されたのと同じ DNS IP を使用するように DNS サーバーを構成します。

  2. 以下の手順に従うか、PowerShell に慣れている場合は、ScomValidation.ps1 スクリプトの Invoke-ValidateStorageConnectivity という特定のチェックを実行します。 テスト マシンで検証スクリプトを個別に実行する方法の詳細については、検証スクリプトの実行に関する一般的なガイドラインを参照してください。

  3. 管理者モードで PowerShell ISE を開き、Set-ExecutionPolicy を [無制限] に設定します。

  4. インターネット接続を確認するには、次のコマンドを実行します。

    Test-NetConnection www.microsoft.com -Port 80

    このコマンドは、ポート 80 で www.microsoft.com への接続を確認します。 このコマンドが失敗した場合は、送信インターネット接続に問題があることを示します。

  5. DNS 設定を確認するには、次のコマンドを実行します。

    Get-DnsClientServerAddress

    このコマンドは、マシンで構成されている DNS サーバーの IP アドレスを取得します。 DNS 設定が正しくアクセス可能であることを確認します。

  6. ネットワーク構成を確認するには、次のコマンドを実行します。

    Get-NetIPConfiguration

    このコマンドは、ネットワーク構成の詳細を表示します。 ネットワーク設定が正確で、ネットワーク環境と一致していることを確認します。

SQL MI 接続

問題: 送信インターネット接続がテスト サーバーに存在しません

原因: DNS サーバーの IP が正しくないか、ネットワーク構成が正しくないために発生します。

解決策:

  1. DNS サーバーの IP を確認し、DNS サーバーが稼働していることを確認します。
  2. SCOM マネージド インスタンスの作成に使用されている VNet に、DNS サーバーに対する通信経路があることを確認します。

問題: SQL Managed Instance で MSI の DB ログインを構成できませんでした

原因: SQL Managed Instance にアクセスするように MSI が正しく構成されていない場合に発生します。

解決策: MSI が SQL Managed Instance で Microsoft Entra Admin として構成されているかどうかを確認します。 MSI 認証を機能させるために必要な Microsoft Entra ID アクセス許可が SQL Managed Instance に提供されていることを確認します。

問題: このインスタンスから SQL MI に接続できませんでした

原因: SQL MI VNet が委任されていないか、SCOM マネージド インスタンス VNet と適切にピアリングされていないために発生します。

解決策:

  1. SQL MI が正しく構成されていることを確認します。
  2. SCOM マネージド インスタンスの作成に使用されている VNet に、SQL MI に対する通信経路があることを確認します (同じ VNet 内にあるかまたは VNet ピアリングによって)。

SQL MI 接続の一般的なトラブルシューティング手順

  1. SCOM マネージド インスタンスの作成用に選択したサブネット内に、Windows Server 2022 または 2019 で実行されている新しい仮想マシン (VM) を生成します。 VM にサインインし、SCOM マネージド インスタンスの作成時に使用されたのと同じ DNS IP を使用するように DNS サーバーを構成します。

  2. 以下の手順に従うか、PowerShell に慣れている場合は、ScomValidation.ps1 スクリプトの Invoke-ValidateSQLConnectivity という特定のチェックを実行します。 テスト マシンで検証スクリプトを個別に実行する方法の詳細については、検証スクリプトの実行に関する一般的なガイドラインを参照してください。

  3. 管理者モードで PowerShell ISE を開き、Set-ExecutionPolicy を [無制限] に設定します。

  4. 送信インターネット接続を確認するには、次のコマンドを実行します。

    Test-NetConnection -ComputerName "www.microsoft.com" -Port 80

    このコマンドは、ポート 80 で www.microsoft.com への接続を確立しようとすることによって、送信インターネット接続を検証します。 接続に失敗した場合は、インターネット接続に潜在的な問題があることを示します。

  5. DNS 設定とネットワーク構成を確認するには、DNS サーバーの IP アドレスが正しく構成されていることを確認し、検証が実行されているマシンでネットワーク構成設定を検証します。

  6. SQL MI 接続をテストするには、次のコマンドを実行します。

    Test-NetConnection -ComputerName $sqlMiName -Port 1433

    $sqlMiName を SQL MI ホスト名に置き換えます。

    このコマンドは、SQL MI インスタンスへの接続をテストします。 接続が成功した場合は、SQL MI に到達可能であることを示します。

DNS サーバーの接続

問題: 指定されている DNS IP (<DNS IP>) が正しくないか、または DNS サーバーに到達できません

解決策: DNS サーバーの IP を確認し、DNS サーバーが稼働していることを確認します。

DNS サーバー接続の一般的なトラブルシューティング

  1. SCOM マネージド インスタンスの作成用に選択したサブネット内に、Windows Server 2022 または 2019 で実行されている新しい仮想マシン (VM) を生成します。 VM にサインインし、SCOM マネージド インスタンスの作成時に使用されたのと同じ DNS IP を使用するように DNS サーバーを構成します。

  2. 以下の手順に従うか、PowerShell に慣れている場合は、ScomValidation.ps1 スクリプトの Invoke-ValidateDnsIpAddress という特定のチェックを実行します。 テスト マシンで検証スクリプトを個別に実行する方法の詳細については、検証スクリプトの実行に関する一般的なガイドラインを参照してください。

  3. 管理者モードで PowerShell ISE を開き、Set-ExecutionPolicy を [無制限] に設定します。

  4. 指定した IP アドレスの DNS 解決を確認するには、次のコマンドを実行します。

    Resolve-DnsName -Name $ipAddress -IssueAction SilentlyContinue

    $ipAddress を検証する IP アドレスに置き換えます。

    このコマンドは、指定された IP アドレスの DNS 解決を確認します。 コマンドが結果を返さない場合、またはエラーをスローした場合は、DNS 解決に潜在的な問題があることを示します。

  5. IP アドレスへのネットワーク接続を確認するには、次のコマンドを実行します。

    Test-NetConnection -ComputerName $ipAddress -Port 80

    $ipAddress をテストする IP アドレスに置き換えます。

    このコマンドは、ポート 80 で指定された IP アドレスへのネットワーク接続を確認します。 接続に失敗した場合は、ネットワーク接続に問題があることを示します。

ドメイン接続

問題: ドメイン <ドメイン名> のドメイン コントローラーにこのネットワークから到達できないか、または少なくとも 1 つのドメイン コントローラーでポートが開いていません

原因: 指定された DNS サーバーの IP またはネットワーク構成に問題があるために発生します。

解決策:

  1. DNS サーバーの IP を確認し、DNS サーバーが稼働していることを確認します。
  2. ドメイン名解決が、Azure または SCOM マネージド インスタンス用に構成された指定されたドメイン コントローラー (DC) に正しく転送されていることを確認します。 解決済み DC の一番上にこの DC が表示されていることを確認します。 解決が異なる DC サーバーに送信される場合は、AD ドメインの解決に問題があることを示します。
  3. ドメイン名を確認し、Azure と SCOM マネージド インスタンス用に構成されたドメイン コントローラーが稼働していることを確認します。

    Note

    ポート 9389、389/636、88、3268/3269、135、445 は、Azure または SCOM マネージド インスタンス用に構成された DC で開いている必要があり、DC 上のすべてのサービスが実行されている必要があります。

ドメイン接続の一般的なトラブルシューティング手順

  1. SCOM マネージド インスタンスの作成用に選択したサブネット内に、Windows Server 2022 または 2019 で実行されている新しい仮想マシン (VM) を生成します。 VM にサインインし、SCOM マネージド インスタンスの作成時に使用されたのと同じ DNS IP を使用するように DNS サーバーを構成します。

  2. 以下の手順に従うか、PowerShell に慣れている場合は、ScomValidation.ps1 スクリプトの Invoke-ValidateDomainControllerConnectivity という特定のチェックを実行します。 テスト マシンで検証スクリプトを個別に実行する方法の詳細については、検証スクリプトの実行に関する一般的なガイドラインを参照してください。

  3. 管理者モードで PowerShell ISE を開き、Set-ExecutionPolicy を [無制限] に設定します。

  4. ドメイン コントローラーの到達可能性を確認するには、次のコマンドを実行します。

    Resolve-DnsName -Name $domainName

    $domainName をテストするドメインの名前に置き換えます。

    ドメイン名解決が、Azure または SCOM マネージド インスタンス用に構成された指定されたドメイン コントローラー (DC) に正しく転送されていることを確認します。 解決済み DC の一番上にこの DC が表示されていることを確認します。 解決が異なる DC サーバーに送信される場合は、AD ドメインの解決に問題があることを示します。

  5. DNS サーバーの設定を確認するには:

    • 検証を実行しているマシンの DNS サーバー設定が正しく構成されていることを確認します。
    • DNS サーバーの IP アドレスが正確でアクセス可能かどうかを確認します。

  6. ネットワーク構成の検証を検証するには:

    • 検証が実行されているマシンでネットワーク構成の設定を確認します。
    • マシンが正しいネットワークに接続されており、ドメイン コントローラーと通信するために必要なネットワーク設定があることを確認します。

  7. ドメイン コントローラーで必要なポートをテストするには、次のコマンドを実行します。

    Test-NetConnection -ComputerName $domainName -Port $portToCheck

    $domainName をテストするドメインの名前に置き換え、$portToCheck を次のリスト番号の各ポートに置き換えます。

    • 389/636
    • 88
    • 3268/3269
    • 135
    • 445

    上記のすべてのポートに対して指定されたコマンドを実行します。

    このコマンドは、Azure または SCOM マネージド インスタンスの作成用に構成されている指定されたドメイン コントローラーで、指定されたポートが開いているかどうかを確認します。 コマンドが正常な接続を示している場合は、必要なポートが開かれていることを示します。

ドメイン参加の検証

問題: テスト管理サーバーがドメインに参加できませんでした

原因: OU パスが正しくないか、資格情報が正しくないか、ネットワーク接続の問題が原因で発生します。

解決策:

  1. Key Vault に作成された資格情報を確認します。 ユーザー名とパスワードのシークレットには、ユーザー名の値の正しいユーザー名と形式が反映されている必要があり、マシンをドメインに参加させるアクセス許可を持っているドメイン\ユーザー名とパスワードである必要があります。 既定では、ユーザー アカウントは最大 10 台のコンピューターをドメインに追加できます。 構成するには、「ユーザーがドメインに参加できるワークステーションの数に対する既定の制限」を参照してください。
  2. OU パスが正しく、新しいコンピューターがドメインに参加するのをブロックしていないことを確認します。

ドメイン参加の検証に関する一般的なトラブルシューティング手順

  1. SCOM マネージド インスタンスの作成用に選択したサブネット内に、Windows Server 2022 または 2019 で実行されている新しい仮想マシン (VM) を生成します。 VM にサインインし、SCOM マネージド インスタンスの作成時に使用されたのと同じ DNS IP を使用するように DNS サーバーを構成します。

  2. 以下の手順に従うか、PowerShell に慣れている場合は、ScomValidation.ps1 スクリプトの Invoke-ValidateDomainJoin という特定のチェックを実行します。 テスト マシンで検証スクリプトを個別に実行する方法の詳細については、検証スクリプトの実行に関する一般的なガイドラインを参照してください。

  3. 管理者モードで PowerShell ISE を開き、Set-ExecutionPolicy を [無制限] に設定します。

  4. SCOM マネージド インスタンスの作成で使用されるドメイン アカウントを使用して、VM をドメインに参加させます。 資格情報を使用してドメインをマシンに参加させる場合は、次のコマンドを実行します。

    
$domainName = "<domainname>"


$domainJoinCredentials = New-Object pscredential -ArgumentList ("<username>", (ConvertTo-SecureString "password" -AsPlainText -Force))



$ouPath = "<OU path>"
if (![String]::IsNullOrWhiteSpace($ouPath)) {
$domainJoinResult = Add-Computer -DomainName $domainName -Credential $domainJoinCredentials -OUPath $ouPath -Force -WarningAction SilentlyContinue -ErrorAction SilentlyContinue
}
else {
$domainJoinResult = Add-Computer -DomainName $domainName -Credential $domainJoinCredentials -Force -WarningAction SilentlyContinue -ErrorAction SilentlyContinue
}

    ユーザー名、パスワード、$domainName、$ouPath を適切な値に置き換えます。

    上記のコマンドを実行した後、次のコマンドを実行して、マシンがドメインに正常に参加したかどうかを確認します。

    Get-WmiObject -Class Win32_ComputerSystem | Select-Object -ExpandProperty PartOfDomain

静的 IP と LB FQDN の関連付け

問題: サーバーがドメインに参加できなかったため、テストを実行できませんでした

解決策: マシンがドメインに参加できることを確認します。 「ドメイン参加の検証」セクションのトラブルシューティング手順に従います。

問題: DNS 名 <DNS 名> を解決できませんでした

解決策: 指定された DNS 名が DNS レコードに存在しません。 DNS 名を確認し、指定された静的 IP に正しく関連付けられていることを確認します。

問題: 指定された静的 IP <静的 IP> とロード バランサーの DNS <DNS 名> が一致しません

解決策: DNS レコードを確認し、正しい DNS 名と静的 IP の組み合わせを指定します。 詳細については、「静的 IP を作成して DNS 名を構成する」を参照してください。

静的 IP と LB FQDN の関連付けの一般的なトラブルシューティング手順

  1. SCOM マネージド インスタンスの作成用に選択したサブネット内に、Windows Server 2022 または 2019 で実行されている新しい仮想マシン (VM) を生成します。 VM にサインインし、SCOM マネージド インスタンスの作成時に使用されたのと同じ DNS IP を使用するように DNS サーバーを構成します。

  2. 以下の手順に従うか、PowerShell に慣れている場合は、ScomValidation.ps1 スクリプトの Invoke-ValidateStaticIPAddressAndDnsname という特定のチェックを実行します。 テスト マシンで検証スクリプトを個別に実行する方法の詳細については、検証スクリプトの実行に関する一般的なガイドラインを参照してください。

  3. 管理者モードで PowerShell ISE を開き、Set-ExecutionPolicy を [無制限] に設定します。

  4. SCOM マネージド インスタンスの作成で使用されるドメイン アカウントを使用して、仮想マシンをドメインに参加させます。 仮想マシンをドメインに参加させる場合は、「ドメイン参加の検証」セクションに記載されている手順に従います。

  5. IP アドレスと関連付けられている DNS 名を取得し、次のコマンドを実行して一致するかどうかを確認します。 DNS 名を解決し、実際の IP アドレスをフェッチします。

    $DNSRecord = Resolve-DnsName -Name $DNSName
$ActualIP = $DNSRecord.IPAddress

    DNS 名を解決できない場合は、DNS 名が有効であり、実際の IP アドレスに関連付けられていることを確認してください。

コンピューター グループの検証

問題: サーバーがドメインに参加できなかったため、テストを実行できませんでした

解決策: マシンがドメインに参加できることを確認します。 「ドメイン参加の検証」セクションで指定されているトラブルシューティング手順に従います。

問題: 名前が <コンピューター グループ名> のコンピューター グループがドメインで見つかりませんでした

解決策: グループが存在することを確認し、指定された名前を確認するか、まだ作成されていない場合は新しく作成します。

問題: 入力コンピューター グループ <コンピューター グループ名> がユーザー <ドメイン ユーザー名> によって管理されていません

解決策: グループのプロパティに移動し、このユーザーをマネージャーとして設定します。 詳細については、「コンピューター グループを作成して構成する」を参照してください。

問題: 入力コンピューター グループ <コンピューター グループ名> のマネージャー <ドメイン ユーザー名> に、グループ メンバーシップを管理するために必要なアクセス許可がありません

解決策: グループのプロパティに移動し、[マネージャーがメンバーシップ リストを更新できる] チェックボックスをオンにします。 詳細については、「コンピューター グループを作成して構成する」を参照してください。

コンピューター グループの検証に関する一般的なトラブルシューティング手順

  1. SCOM マネージド インスタンスの作成用に選択したサブネット内に、Windows Server 2022 または 2019 で実行されている新しい仮想マシン (VM) を生成します。 VM にサインインし、SCOM マネージド インスタンスの作成時に使用されたのと同じ DNS IP を使用するように DNS サーバーを構成します。

  2. 以下の手順に従うか、PowerShell に慣れている場合は、ScomValidation.ps1 スクリプトの Invoke-ValidateComputerGroup という特定のチェックを実行します。 テスト マシンで検証スクリプトを個別に実行する方法の詳細については、検証スクリプトの実行に関する一般的なガイドラインを参照してください。

  3. SCOM マネージド インスタンスの作成で使用されるドメイン アカウントを使用して、VM をドメインに参加させます。 仮想マシンをドメインに参加させる場合は、「ドメイン参加の検証」セクションに記載されている手順に従います。

  4. 管理者モードで PowerShell ISE を開き、Set-ExecutionPolicy を [無制限] に設定します。

  5. 次のコマンドを実行してモジュールをインポートします。

    Add-WindowsFeature RSAT-AD-PowerShell -ErrorAction SilentlyContinue
Add-WindowsFeature GPMC -ErrorAction SilentlyContinue

  6. VM がドメインに参加しているかどうかを確認するには、次のコマンドを実行します。

    Get-WmiObject -Class Win32_ComputerSystem | Select-Object -ExpandProperty PartOfDomain

  7. ドメインが存在することを確認し、現在のマシンが既にドメインに参加しているかどうかを確認するには、次のコマンドを実行します。

    $domainJoinCredentials = New-Object pscredential -ArgumentList ("<username>", (ConvertTo-SecureString "password" -AsPlainText -Force)) 
$Domain = Get-ADDomain -Current LocalComputer -Credential $domainUserCredentials

    $username と password を該当する値に置き換えます。

  8. ドメインにユーザーが存在することを確認するには、次のコマンドを実行します。

    $DomainUser = Get-ADUser -Identity $username -Credential $domainUserCredentials

    $username と $domainUserCredentials を該当する値に置き換えます。

  9. ドメインにコンピューター グループが存在することを確認するには、次のコマンドを実行します。

    $ComputerGroup = Get-ADGroup -Identity $computerGroupName -Properties ManagedBy,DistinguishedName -Credential $domainUserCredentials

    $computerGroupName と $domainUserCredentials を該当する値に置き換えます。

  10. ユーザーとコンピューター グループが存在する場合は、そのユーザーがコンピューター グループのマネージャーであるかどうかを判断します。

    Import-Module ActiveDirectory
  	$DomainDN = $Domain.DistinguishedName
  $GroupDN = $ComputerGroup.DistinguishedName
 $RightsGuid = [GUID](Get-ItemProperty "AD:\CN=Self-Membership,CN=Extended-Rights,CN=Configuration,$DomainDN" -Name rightsGuid -Credential $domainUserCredentials | Select-Object -ExpandProperty rightsGuid)

  # Run Get ACL under the give credentials
  $job = Start-Job -ScriptBlock {
      param (
          [Parameter(Mandatory = $true)]
          [string] $GroupDN,
          [Parameter(Mandatory = $true)]
          [GUID] $RightsGuid
      )

  Import-Module ActiveDirectory
  $AclRule = (Get-Acl -Path "AD:\$GroupDN").GetAccessRules($true,$true,[System.Security.Principal.SecurityIdentifier]) |  Where-Object {($_.ObjectType -eq $RightsGuid) -and ($_.ActiveDirectoryRights -like '*WriteProperty*')}
      return $AclRule

  } -ArgumentList $GroupDN, $RightsGuid -Credential $domainUserCredentials

  $timeoutSeconds = 20
  $jobResult = Wait-Job $job -Timeout $timeoutSeconds

  # Job did not complete within the timeout
  if ($null -eq $jobResult) {
      Write-Host "Checking permissions, timeout after 10 seconds."
      Remove-Job $job -Force
  } else {
      # Job completed within the timeout
      $AclRule = Receive-Job $job
      Remove-Job $job -Force
  }

  $managerCanUpdateMembership = $false
  if (($null -ne $AclRule) -and ($AclRule.AccessControlType -eq 'Allow') -and ($AclRule.IdentityReference -eq $DomainUser.SID)) {
      $managerCanUpdateMembership = $true

    managerCanUpdateMembership が True の場合、ドメイン ユーザーにはコンピューター グループに対するメンバーシップ更新アクセス許可があります。 managerCanUpdateMembership が False の場合は、コンピューター グループにドメイン ユーザーへの管理アクセス許可を付与します。

gMSA アカウントの検証

問題: サーバーがドメインに参加できなかったため、テストが実行されません

解決策: マシンがドメインに参加できることを確認します。 「ドメイン参加の検証」セクションで指定されているトラブルシューティング手順に従います。

問題: 名前が <コンピューター グループ名> のコンピューター グループがドメインに見つかりません。 このグループのメンバーは、gMSA パスワードを取得できる必要があります

解決策: グループが存在することを確認し、指定された名前を確認します。

問題: 名前が <ドメイン gMSA> の gMSA がドメインで見つかりませんでした

解決策: gMSA アカウントが存在することを確認し、指定された名前を確認するか、まだ作成されていない場合は新しく作成します。

問題: gMSA <ドメイン gMSA> が有効になっていません

解決策: 次のコマンドを使用して有効にします。

Set-ADServiceAccount -Identity <domain gMSA> -Enabled $true

問題: gMSA <ドメイン gMSA> の DNS ホスト名を <DNS 名> に設定する必要があります

解決策: gMSA に DNSHostName プロパティが正しく設定されていません。 次のコマンドを使用して DNSHostName プロパティを設定します。

Set-ADServiceAccount -Identity <domain gMSA> -DNSHostName <DNS Name>

問題: gMSA <ドメイン gMSA> の Sam アカウント名が 15 文字の制限を超えています

解決策: 次のコマンドを使用して SamAccountName を設定します。

Set-ADServiceAccount -Identity <domain gMSA> -SamAccountName <shortname$>

問題: コンピューター グループ <コンピューター グループ名> を、gMSA <ドメイン gMSA> の PrincipalsAllowedToRetrieveManagedPassword として設定する必要があります

解決策: gMSA に PrincipalsAllowedToRetrieveManagedPassword が正しく設定されていません。 次のコマンドを使用して PrincipalsAllowedToRetrieveManagedPassword を設定します。

Set-ADServiceAccount -Identity <domain gMSA> - PrincipalsAllowedToRetrieveManagedPassword <computer group name>

問題: gMSA <ドメイン gMSA> に対して SPN が正しく設定されていません

解決策: gMSA に正しいサービス プリンシパル名が設定されていません。 次のコマンドを使用して、サービス プリンシパル名を設定します。

Set-ADServiceAccount -Identity <domain gMSA> -ServicePrincipalNames <set of SPNs>

gMSA アカウント検証の一般的なトラブルシューティング手順

  1. SCOM マネージド インスタンスの作成用に選択したサブネット内に、Windows Server 2022 または 2019 で実行されている新しい仮想マシン (VM) を生成します。 VM にサインインし、SCOM マネージド インスタンスの作成時に使用されたのと同じ DNS IP を使用するように DNS サーバーを構成します。

  2. 以下の手順に従うか、PowerShell に慣れている場合は、ScomValidation.ps1 スクリプトの Invoke-ValidategMSAAccount という特定のチェックを実行します。 テスト マシンで検証スクリプトを個別に実行する方法の詳細については、検証スクリプトの実行に関する一般的なガイドラインを参照してください。

  3. SCOM マネージド インスタンスの作成で使用されるドメイン アカウントを使用して、VM をドメインに参加させます。 仮想マシンをドメインに参加させる場合は、「ドメイン参加の検証」セクションに記載されている手順に従います。

  4. 管理者モードで PowerShell ISE を開き、Set-ExecutionPolicy を [無制限] に設定します。

  5. 次のコマンドを実行してモジュールをインポートします。

    Add-WindowsFeature RSAT-AD-PowerShell -ErrorAction SilentlyContinue
Add-WindowsFeature GPMC -ErrorAction SilentlyContinue

  6. サーバーがドメインに正常に参加したことを確認するには、次のコマンドを実行します。

    (Get-WmiObject -Class Win32_ComputerSystem).PartOfDomain

  7. コンピューター グループが存在することを確認するには、次のコマンドを実行します。

    $Credentials = New-Object pscredential -ArgumentList ("<username>", (ConvertTo-SecureString "password" -AsPlainText -Force))
$adGroup = Get-ADGroup -Identity $computerGroupName -Properties ManagedBy,DistinguishedName -Credential $Credentials

    ユーザー名、パスワード、computerGroupName を該当する値に置き換えます。

  8. gMSA アカウントが存在することを確認するには、次のコマンドを実行します。

    $adServiceAccount = Get-ADServiceAccount -Identity gMSAAccountName -Properties DNSHostName,Enabled,PrincipalsAllowedToRetrieveManagedPassword,SamAccountName,ServicePrincipalNames -Credential $Credentials

  9. gMSA アカウントのプロパティを検証するには、gMSA アカウントが有効になっているかどうかを確認します。

    (Get-ADServiceAccount -Identity <GmsaAccount>).Enabled

    コマンドが False を返す場合は、ドメイン内のアカウントを有効にします。

  10. gMSA アカウントの DNS ホスト名が指定された DNS 名 (LB DNS 名) と一致することを確認するには、次のコマンドを実行します。

    (Get-ADServiceAccount -Identity <GmsaAccount>).DNSHostName

    コマンドが予想される DNS 名を返さない場合は、gMsaAccount の DNS ホスト名を LB DNS 名に更新します。

  11. gMSA アカウントの Sam アカウント名が 15 文字の制限を超えていないことを確認します。

    (Get-ADServiceAccount -Identity <GmsaAccount>).SamAccountName.Length

  12. PrincipalsAllowedToRetrieveManagedPassword プロパティを検証するには、次のコマンドを実行します。

    指定されたコンピューター グループが gMSA アカウントの 'PrincipalsAllowedToRetrieveManagedPassword' として設定されているかどうかを確認します。

    (Get-ADServiceAccount -Identity <GmsaAccount>).PrincipalsAllowedToRetrieveManagedPassword -contains (Get-ADGroup -Identity <ComputerGroupName>).DistinguishedName

    gMSAAccount と ComputerGroupName を該当する値に置き換えます。

  13. gMSA アカウントのサービス プリンシパル名 (SPN) を検証するには、次のコマンドを実行します。

    $CorrectSPNs = @("MSOMSdkSvc/$dnsHostName", "MSOMSdkSvc/$dnsName", "MSOMHSvc/$dnsHostName", "MSOMHSvc/$dnsName")
(Get-ADServiceAccount -Identity <GmsaAccount>).ServicePrincipalNames

    結果に正しい SPN があるかどうかを確認します。 $dnsName を SCOM マネージド インスタンスの作成時に指定された LB DNS 名に置き換えます。 $dnsHostName を LB DNS の短い名前に置き換えます。 たとえば、MSOMHSvc/ContosoLB.domain.com、MSOMHSvc/ContosoLB、MSOMSdkSvc/ContosoLB.domain.com、MSOMSdkSvc/ContosoLB はサービス プリンシパル名です。

グループ ポリシーの検証

重要

GPO ポリシーを修正するには、Active Directory 管理者と共同作業を行い、次のポリシーから System Center Operations Manager を除外します。

  • ローカル管理者グループの構成を変更またはオーバーライドする GPO。
  • ネットワーク認証を非アクティブ化する GPO。
  • ローカル管理者のリモート サインインを妨げる GPO を評価します。

問題: サーバーがドメインに参加できなかったため、このテストを実行できませんでした

解決策: マシンがドメインに参加していることを確認します。 「ドメイン参加の検証」セクションのトラブルシューティング手順に従います。

問題: 名前が <ドメイン gMSA> の gMSA がドメインで見つかりませんでした。 このアカウントは、サーバーのローカル管理者である必要があります

解決策: アカウントが存在することを確認し、gMSA とドメイン ユーザーがローカル管理者グループの一部であることを確認します。

問題: アカウント <ドメインユーザー名> と <ドメイン gMSA> をテスト管理サーバーのローカルの Administrators グループに追加できなかったか、グループ ポリシーの更新後にグループに保持されませんでした

解決策: 指定されたドメイン ユーザー名と gMSA 入力が、完全な名前 (ドメイン\アカウント) を含めて正しいことを確認します。 また、OU レベルまたはドメイン レベルで作成されたポリシーにより、ローカルの Administrators グループをオーバーライドしているグループ ポリシーがテスト マシンに存在するかどうかを確認します。 gMSA とドメイン ユーザーは、SCOM マネージド インスタンスを機能させるためにローカル管理者グループの一部である必要があります。 SCOM マネージド インスタンスのマシンは、ローカル管理者グループをオーバーライドするポリシーから除外する必要があります (AD 管理者と連携する)。

問題: SCOM マネージド インスタンスが失敗しました

原因: ドメイン内のグループ ポリシー (名前: <グループ ポリシー名>) が、サーバーを含む OU 上またはドメインのルート上のいずれかで、テスト管理サーバーのローカルの Administrators グループをオーバーライドしています。

解決策: SCOM マネージド インスタンス管理サーバーの OU (<OU パス>) が、グループをオーバーライドするポリシーの影響を受けないことを確認します。

グループ ポリシー検証の一般的なトラブルシューティング手順

  1. SCOM マネージド インスタンスの作成用に選択したサブネット内に、Windows Server 2022 または 2019 で実行されている新しい仮想マシン (VM) を生成します。 VM にサインインし、SCOM マネージド インスタンスの作成時に使用されたのと同じ DNS IP を使用するように DNS サーバーを構成します。

  2. 以下の手順に従うか、PowerShell に慣れている場合は、ScomValidation.ps1 スクリプトの Invoke-ValidateLocalAdminOverideByGPO という特定のチェックを実行します。 テスト マシンで検証スクリプトを個別に実行する方法の詳細については、検証スクリプトの実行に関する一般的なガイドラインを参照してください。

  3. SCOM マネージド インスタンスの作成で使用されるドメイン アカウントを使用して、VM をドメインに参加させます。 仮想マシンをドメインに参加させる場合は、「ドメイン参加の検証」セクションに記載されている手順に従います。

  4. 管理者モードで PowerShell ISE を開き、Set-ExecutionPolicy を [無制限] に設定します。

  5. 次のコマンドを実行してモジュールをインポートします。

    Add-WindowsFeature RSAT-AD-PowerShell -ErrorAction SilentlyContinue
Add-WindowsFeature GPMC -ErrorAction SilentlyContinue

  6. サーバーがドメインに正常に参加したことを確認するには、次のコマンドを実行します。

    (Get-WmiObject -Class Win32_ComputerSystem).PartOfDomain

    このコマンドは True を返す必要があります。

  7. gMSA アカウントが存在することを確認するには、次のコマンドを実行します。

    Get-ADServiceAccount -Identity <GmsaAccount>

  8. ローカルの Administrators グループにユーザー アカウントが存在することを検証するには、次のコマンドを実行します。

    $domainJoinCredentials = New-Object pscredential -ArgumentList ("<username>", (ConvertTo-SecureString "password" -AsPlainText -Force)) 
$addToAdminResult = Add-LocalGroupMember -Group "Administrators" -Member $userName, $gMSAccount -ErrorAction SilentlyContinue 
$gpUpdateResult = gpupdate /force 
$LocalAdmins = Get-LocalGroupMember -Group 'Administrators' | Select-Object -ExpandProperty Name

    <UserName> および <GmsaAccount> を実際の値に置き換えます。

  9. ドメインと組織単位 (OU) の詳細を確認するには、次のコマンドを実行します。

    Get-ADOrganizationalUnit -Filter "DistinguishedName -like '$ouPathDN'" -Properties CanonicalName -Credential $domainUserCredentials

    <OuPathDN> を実際の OU パスに置き換えます。

  10. ドメインから GPO (グループ ポリシー オブジェクト) レポートを取得し、ローカルの Administrators グループでポリシーをオーバーライドしているか確認するには、次のコマンドを実行します。

     [xml]$gpoReport = Get-GPOReport -All -ReportType Xml -Domain <domain name>
 foreach ($GPO in $gpoReport.GPOS.GPO) {
     # Check if the GPO links to the entire domain, or the input OU if provided
     if (($GPO.LinksTo.SOMPath -eq $domainName) -or ($GPO.LinksTo.SOMPath -eq $ouPathCN)) {
         # Check if there is a policy overriding the Local Users and Groups
         if ($GPO.Computer.ExtensionData.Extension.LocalUsersAndGroups.Group) {
         $GroupPolicy = $GPO.Computer.ExtensionData.Extension.LocalUsersAndGroups.Group | Select-Object @{Name='RemoveUsers';Expression={$_.Properties.deleteAllUsers}},@{Name='RemoveGroups';Expression={$_.Properties.deleteAllGroups}},@{Name='GroupName';Expression={$_.Properties.groupName}}
         # Check if the policy is acting on the BUILTIN\Administrators group, and whether it is removing other users or groups
         if (($GroupPolicy.groupName -eq "Administrators (built-in)") -and (($GroupPolicy.RemoveUsers -eq 1) -or ($GroupPolicy.RemoveGroups -eq 1))) {
          $overridingPolicyFound = $true
          $overridingPolicyName = $GPO.Name
             }
         }
     }
 }
 if($overridingPolicyFound) {
  Write-Warning "Validation failed. A group policy in your domain (name: $overridingPolicyName) is overriding the local Administrators group on this machine. This will cause SCOM MI installation to fail. Please ensure that the OU for SCOM MI Management Servers is not affected by this policy"
 }
 else {
  Write-Output "Validation suceeded. No group policy found in your domain which overrides local Administrators. "
 }

スクリプトの実行で検証に失敗したという警告が表示される場合は、ローカル管理者グループをオーバーライドするポリシー (警告メッセージの名前) があります。 Active Directory 管理者に確認し、System Center Operations Manager 管理サーバーをポリシーから除外します。