別のコンピューターにソフトウェアをリモートでインストールする方法

avatar Oct 22, 2026
Remotely installing software on another computer

別のコンピューターにソフトウェアをリモートでインストールするには、リモート デスクトップで接続してローカルで操作するのと同じようにインストーラーを実行するか、PowerShell の Invoke-Command や PsExec と msiexec /qn を使ってコマンド ラインからサイレント インストールをプッシュします。コマンド ラインでは、正しい管理者パスワードを使っていても多くの人が Access is denied に遭遇します。これは、Windows がネットワーク ログオン経由で通常のローカル管理者アカウントにフィルター処理されたトークンを渡すためです。リモート デスクトップは対話型ログオンであるためこのフィルターを回避でき、対象側のドメインに属するドメイン アカウントは、どちらの方法でも完全なトークンを取得します。

一般的なローカル管理者アカウントの場合、最速の対処法は対象側のレジストリ値を 1 つ設定することです: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System の下で LocalAccountTokenFilterPolicy を 1 に設定し、その後インストーラーをサイレントで実行して終了コードを取得します。このガイドでは、検証済みのコマンド、複数台向けスクリプト、PSEXESVC の失敗から winget の 0x8a15000f まで、一般的なあらゆるエラーの修正方法を含めて、それぞれの方法を解説します。

トークンのパズルを完全にスキップしたい場合は、HelpWire は先方のマシンに接続できるリモートサポート用ソフトウェアで、セッション中に管理者権限を要求できます。実際のインタラクティブなデスクトップ環境内でインストーラーを実行するため、昇格プロンプトも実機のキーボードで操作しているときと同様に動作します。

目次

管理者アカウントでもリモートソフトウェアのインストールが失敗する理由

原因は UAC のリモート制限、いわゆるトークン フィルタリングです。Administrators グループに属するローカル アカウントがネットワーク経由でサインインすると、ローカル セキュリティ機関 が中程度の整合性レベルのフィルター処理されたトークンを渡すため、Administrators グループは拒否のみ (deny-only) 状態となり、特権操作はブロックされます。ネットワーク ログオン、つまり WinRM、PsExec、WMI、または C$ へのコピーでは、ローカル管理者に対してフィルター処理されたトークンが生成されます。

影響を受けるかどうかは 2 つの要素で決まります。対象自身のドメインに属するドメイン アカウントで、ローカルの Administrators グループに含まれているものは適用除外となりフル トークンを受け取ります。これが、ドメイン環境でこの現象がほとんど見られない理由です。組み込みの RID 500 の Administrator も特例で、FilterAdministratorToken が有効でない限りフィルター処理されません。その他、つまり通常のローカル管理者アカウントや別ドメインのアカウントは、対象がワークグループであってもドメイン参加済みであっても、フィルター処理されたトークンになります。この 1 点だけで、PsExec、net use、C$ へのコピーで Access is denied となる理由に加え、Invoke-Command 経由で管理者ではないフィルター済みトークンになってしまう理由が説明できます。

もう 1 つの根本原因は非対話型セッションです。リモート コマンドは誰もクリックできない場所で実行されるため、ウィンドウを前提とするインストーラーはボタン待ちでハングするか、即座に失敗します。

ソフトウェアをリモートでインストールする方法：利用可能な方法の比較

リモートでソフトウェアをインストールする最速の方法は、環境に合った方法を選ぶことです。各方法は管理者トークン、ワークグループ、Windows Home での挙動がそれぞれ異なるためです。この表は、コマンドを1つも実行する前にその選択を確定させます。 グループ ポリシー はドメイン専用であり、早い段階で採用するか除外するかを判断する価値があるため、ここに含めています。

方法 管理者トークンの動作 ワークグループで動作 Windows Home ホスト ユーザーの作業を中断 インターネット経由
RDP フル トークン、対話型 はい No host はい、ユーザーの接続を切断 VPN 経由
PowerShell リモート ローカル管理者向けにフィルター済み TrustedHosts を使用 はい いいえ まれに
cmd + PsExec フィルター済み。 -h を使用。 レジストリ修正で可能 はい いいえ いいえ
winget WinRM では動作しない ローカル実行のみ はい いいえ いいえ
グループ ポリシー SYSTEM、コンピューター割り当て No、ドメインのみ ドメインのみ いいえ いいえ
HelpWire フル、対話型の昇格 はい はい いいえ はい

以下のすべてのコマンドライン手法を左右するのは、接続に使用するアカウントです。対象側ドメインのAdministrators グループに属するドメイン アカウントであればフルトークンを取得し、そのまま動作します。通常のローカル管理者アカウントはフィルター済みトークンしか得られないため、C$ へのコピーや PsExec の呼び出しは Access is denied を返し、PowerShell のリモート実行もセッションを拒否するか管理者権限なしで実行されます。これは対象で LocalAccountTokenFilterPolicy を 1 に設定するまでの挙動で、修正セクションで説明しています。RDP は例外で、ネットワーク ログオンではなく対話型ログオンだからです。

リモート デスクトップを使用して別のコンピューターにソフトウェアをリモートでインストールする方法

リモート デスクトップは、UAC プロンプトを承認すると完全な管理者トークンで実行される対話型セッションであるため、別のコンピューターにソフトウェアをリモートでインストールする最も確実な方法です。接続して、そのマシンの前に座っているかのようにインストールします。

  1. 対象のPCで、Win + R を押し、SystemPropertiesRemote と入力して、このコンピューターへのリモート接続を許可する を有効にします。

  2. お使いのコンピューターで、リモート デスクトップ接続（mstsc.exe）を開き、接続先の名前または IP アドレスを入力し、そこでローカル管理者権限を持つアカウントでサインインします。

  3. インストーラーをセッション経由でコピーするか、ローカル リソースでローカル ドライブをマップしてアクセスできるようにします。

  4. インストーラーを実行してください。UAC プロンプトが表示されたら、RDPウィンドウ内で承認し、その後ウィザードを完了してください。

それに依存する前に、制限事項を知っておく価値があります。Windows Home エディションは RDP セッションを一切ホストできません。クライアントしか実行できません。クライアント版の Windows では単一コンソール扱いのため、接続するとそのマシンにログインしているユーザーは切断されます。また、リモート側で管理者資格情報を持たない標準ユーザーはそのプロンプトを承認できないため、以下のコマンドラインの方法に進むことになります。

PowerShell を使用してリモートでソフトウェアをインストールする方法

PowerShell を使ってリモートでソフトウェアをインストールするには、Invoke-Command に頼ることになりますが、ほとんどの人が引っかかる落とし穴が2つあります。リモート セッションは非対話型のため、インストーラーは完全にサイレントで実行される必要があり、さらに、すぐに終了を返すインストーラーが完了する前にセッションが閉じてしまい、インストールが取り消されることがあります。Kevin Marquette による リモート インストールに関する有名な解説記事 は両方を説明しており、2つ目の解決策は Start-Process -Wait です。

Invoke-Command を使用して 1 台のコンピューターにインストールする

  1. 対象で、PowerShell リモートを一度有効にします。管理者権限の PowerShell ウィンドウから、Enable-PSRemoting -Force を実行します。

  2. セッションがネットワーク パスにアクセスする必要がないよう、インストーラーをターゲットにコピーします:
    Copy-Item -Path "C:\Installers\app.msi" -Destination "\\PC01\c$\Windows\Temp\app.msi"

  3. サイレントで実行し、完了するまで待ちます:
    Invoke-Command -ComputerName PC01 -ScriptBlock {

      Start-Process msiexec.exe -ArgumentList "/i
    C:\Windows\Temp\app.msi /qn /norestart" -Wait

    }

    -Wait を省略すると、インストーラーがまだファイルをコピーしている最中にスクリプトブロックが終了してしまう可能性があり、セッションを閉じると書き込み途中のインストールが中断されます。インストーラーがウィンドウを表示する場合は、非対話型セッションではそれをクリックできるものが何もないため、ハングします。

複数のコンピューターにリモートでソフトウェアをインストールするための PowerShell スクリプト

PowerShell スクリプトはコンピューターのリストを順に処理し、各マシンごとのセッション経由でインストーラーをコピーして実行し、終了コードを記録することで、各マシンに何が展開されたかを把握できます。これは、セッション内から共有にアクセスするのではなく事前にコピーすることで、ダブルホップ問題に対処します。

$computers = Get-Content "C:\Installers\computers.txt"
$source = "C:\Installers\app.msi"
$results = @()

foreach ($pc in $computers) {
try {
$s = New-PSSession -ComputerName $pc -ErrorAction Stop
Copy-Item -Path $source -ToSession $s -Destination
"C:\Windows\Temp\app.msi"
$code = Invoke-Command -Session $s -ScriptBlock {
$p = Start-Process msiexec.exe -ArgumentList "/i
C:\Windows\Temp\app.msi /qn /norestart" -Wait -PassThru
$p.ExitCode
}
$ok = @(0, 3010, 1641) -contains $code
$results += [pscustomobject]@{ Computer = $pc; ExitCode = $code; Success = $ok }
Remove-PSSession $s
}
catch {
$results += [pscustomobject]@{ Computer = $pc; ExitCode = "N/A"; Success = $false }
}
}
$results | Export-Csv "C:\Installers\install-report.csv"
-NoTypeInformation

3010 と 1641 は失敗ではなく成功として扱ってください。どちらもインストールが成功したことを意味します。3010 は完了するには再起動が必要であること、1641 はインストーラーがすでに再起動を開始したことを示します。多くの単純なスクリプトはこれらを誤って失敗としてフラグ付けします。なお、Copy-Item -ToSession は一度に 1 つのセッションで実行されるため、Invoke-Command はファンアウトできても、コピー処理はマシンごとになります。

二重ホップのための近道として提案されがちな CredSSP は避けてください。コミュニティでは、攻撃者に抜き取られるおそれのある管理者資格情報をリモートホストにキャッシュしてしまうため、これを避ける流れになっています。上記のように事前コピーすることで、この問題全体を回避できます。

確認すべき一般的な msiexec の終了コード:

終了コード 意味
0 成功
1603 インストール中の致命的なエラー
1618 別のインストールが既に進行中
1619 インストーラーパッケージを開くことができませんでした
1638 製品の別のバージョンが既にインストールされています
1641 成功、再起動を開始しました
3010 成功、再起動が必要です

cmd を使用してリモートでソフトウェアをインストールする方法

cmd を使ってソフトウェアをリモートでインストールするには、3つの方法があります: PsExec、winget、そして古い WMIC コマンドですが、現在の Windows で信頼できるのは最初の2つだけです。どれも管理者トークンとのやり取りが異なるため、ツールそのものよりもフラグの指定のほうが重要です。

PsExec と msiexec

  1. Microsoft Sysinternals の PsExec をダウンロードして展開します。PsExec は実行のたびにサービス (PSEXESVC) をインストールし、そのため管理者権限が必要になるので、cmd を 管理者として 開いてください。

  2. MSI を対象の管理共有にコピーします:
    copy "C:\Installers\app.msi" \\PC01\C$\Windows\Temp\

  3. 昇格トークンでサイレントインストールを実行します。重要なのは -h フラグです。これによりアカウントの昇格トークンでプロセスが実行されます:
    psexec \\PC01 -h -accepteula msiexec.exe /i "C:\Windows\Temp\app.msi" /qn /norestart

古いガイドでコピペされている -i フラグは省略してください。これはデスクトップとの対話を強制し、サイレントインストールと相反し、まさに回避しようとしているハングを引き起こす可能性があります。-h の動作とスイッチの完全な一覧は、PsExec リファレンスにそのまま記載されています。Couldn't install PSEXESVC service: Access Denied が表示される場合、一般的な原因は昇格されていないローカルのプロンプトですが、ADMIN$ 共有がブロックされている場合や対象側でトークンがフィルタリングされている場合も同様に発生します。ワークグループ マシンに対して Couldn't access <PC>: Access is denied が表示される場合は、修正セクションで取り上げているトークン フィルタリングが原因です。

コマンド ラインからの winget

winget は cmd から 1 行でローカルにアプリをインストールでき、レガシー ツールの現代的な代替手段です:

winget install --id Google.Chrome --silent --accept-package-agreements --accept-source-agreements

ただし、リモート実行では問題が生じがちです。WinRM セッション経由では、winget は対話的なログオンを想定したパッケージ化アプリとして実行されるため、しばしば A specified logon session does not exist を出したり、winget が認識されないと報告したりします。長年にわたる winget-cli の問題がこれを追跡しており、関連レポートでは、管理者がそのマシンで一度ローカルに任意の winget コマンドを実行するまで、最初のリモート呼び出しが 0x8a15000f で失敗することが示されています。新規マシンでは、--accept-source-agreements を指定しない限り、入力プロンプト エラーである 0x8a150042 にも遭遇します。winget は SYSTEM アカウントも公式にはサポートしておらず、Windows Server では Server Core を除き 2025 以降でのみサポートされ、2019 と 2022 は未サポートで実験的です。

なぜWMICの方法が機能しなくなったのか

旧来の wmic product call install の手法は、Windows 11 24H2 以降では動作しなくなりました。Microsoft の WMIC 廃止通知によれば、このユーティリティは Windows 11 23H2 と 24H2 では既定で無効化され、25H2 へのアップグレード時に削除され、2026 年 8 月のプレビュー更新プログラムで 24H2 と 25H2 からも除去され、26H1 では最初から同梱されず、復元するための Feature on Demand も提供されません。これらのリリースでは、wmic.exe を呼び出すスクリプトは、'wmic' is not recognized を返します。Microsoft は削除対象を Windows 11 に限定しているため、現時点では Windows 10 と Windows Server には引き続き WMIC が同梱されていますが、移行先としては PowerShell の Get-CimInstance と Invoke-Command の利用が推奨されています。HelpWire の cmd インストールガイドでは、コマンドライン オプションについてさらに詳しく解説しています。

Windows のバージョン別のコマンドライン ツール対応状況:

機能 状態 備考
WMIC は次で削除 24H2, 25H2, 26H1 2026年8月以降は機能オンデマンドなし
winget Win 10 1809+, Win 11, Server 2025 (Core ではない) SYSTEM サポートなし; Server 2019/2022 は実験的
RDP ホスト Pro, Enterprise, Education Home エディションはクライアントのみを実行
 

多くの人がまず試すことと、なぜそれが失敗するのか

表面的な対処は、リモート側のフィルター済みトークンではなく症状だけを扱うため、何時間も無駄にします。ローカルのcmdを管理者として実行しても何も変わりません。フィルタリングはあなたのマシンではなく対象側で行われるからです。通常の管理者アカウントでrunasを使うと、管理者グループのメンバー資格はあるものの昇格されていないウィンドウが開くだけなので、インストールは依然として失敗します。

EnableLUAを0に設定してUACを完全に無効化すればインストールは通りますが、管理者権限が制御不能となり、ストア アプリが動作しなくなります。これが、Microsoft とコミュニティがそれをやめるよう警告している理由です。これらはいずれも実際の原因には触れておらず、その点は次のセクションで扱います。

“アクセスが拒否されました”や権限昇格エラーに対する実証済みの対処法

まずエラーメッセージから始め、次にその解決策へ移動してください。以下の各項目は、Microsoft のドキュメント、ベンダーのナレッジベース、コミュニティのスレッドで確認済みです。

エラー文字列 発生元 根本原因
アクセスが拒否されました PsExec, net use, C$ フィルター処理された管理者トークン
PSEXESVC サービスをインストールできませんでした PsExec ローカルのプロンプトが昇格されていない、または対象の ADMIN$/トークンがブロックされている
0x80090322 WinRM ワークグループまたは SPN の問題
アクセス拒否 Invoke-Command を共有に対して ダブルホップ
0x8a15000f winget 経由で WinRM ソース データが見つからない
1603 msiexec 致命的なインストール エラー

LocalAccountTokenFilterPolicy で“アクセスが拒否されました”を解決

対象にレジストリ値を1つ設定し、ローカル管理者アカウントにネットワーク経由で完全なトークンを付与します。これは、PDQ、Broadcom、そして数え切れないほどのPsExecスレッドで確認された修正です。

  1. 対象のコンピューターで、レジストリ エディター（regedit）を開き、次に移動します:
    HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System

  2. LocalAccountTokenFilterPolicy という名前の DWORD を作成し、値を 1 に設定します。または、管理者権限のコマンド プロンプトから次を実行します:
    reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f

  3. インストールを再試行してください。後で元に戻すには、値を0に戻せば、リモート UAC フィルタリングが再び有効になります。

対象自身のドメインのドメイン管理者アカウントで接続する場合は不要です。対象はすでに完全なトークンを受け取ります。Microsoft はループバック攻撃を防ぐためにこのフィルタリングを設計しているため、これを無効にすると 攻撃対象領域が広がります。必要なときだけ意図的に設定し、作業が終わったら元に戻してください。

“PSEXESVC サービスをインストールできませんでした”を修正

これはほとんど常にローカルの権限昇格の問題であり、Microsoft Q&Aで確認されています。

  1. プロンプトを閉じて、cmd または PowerShell を管理者として開き直してください。PsExec は実行のたびにサービスをインストールしますが、通常のプロンプトからはそれを行えません。

  2. それでも失敗する場合は、古い psexecsvc.exe がターゲット側に残ってしまっている可能性があります。リモート マシンの %windir% を確認し、残っているコピーがあれば削除してから、再試行してください。

  3. 対象の ADMIN$ 共有にアクセスでき、ファイルとプリンターの共有（TCP 445 上の SMB）がそのファイアウォールで許可されていることを確認してください。これは、PsExec がそこで実行するために PSEXESVC サービスをコピーするためです。

ワークグループのマシンでの WinRM 0x80090322 の修正

ワークグループ環境での PowerShell リモート処理は、Kerberos がローカル アカウントを認証できないため失敗します。そのため、対象を TrustedHosts に追加し、NTLM を強制します。WinRM のエラー メッセージ自体に TrustedHosts のパスが明記されています。

  1. お使いのマシンで、管理者権限のPowerShellから、対象を追加します:
    Set-Item WSMan:\localhost\Client\TrustedHosts -Value "PC01" -Concatenate

  2. 明示的なローカル資格情報を使用して接続し、Negotiate が NTLM にフォールバックするようにします:
    $cred = Get-Credential

    Invoke-Command -ComputerName PC01 -Credential $cred -ScriptBlock { hostname }

  3. エラーがワークグループではなくドメインの FQDN で発生し続ける場合、それは SPN の問題です。 Microsoft KB 4549715 では、-IncludePortInSPN と spn_prefix の回避策が説明されています。

ダブルホップの“アクセス拒否”を修正

リモート セッションが UNC パスに到達すると、認証できず、ファイルを事前にコピーすることも、スクリプト ブロック内で再認証することもできません。

  1. 推奨: 複数コンピューター用スクリプトと同様に、まずインストーラーを対象先にコピーし、セッションがローカル パスにのみアクセスするようにします。

  2. または、セッション内で新しい資格情報を使ってネットワーク ドライブを割り当てます。New-PSDrive 呼び出しはファイル サーバーへの接続を認証し、下記の UNC パスからの直接起動はその接続を再利用するため、コマンドがマップ済みドライブを参照していなくても資格情報は引き継がれます:
    $cred = Get-Credential

    Invoke-Command -ComputerName PC01 -ScriptBlock {

      New-PSDrive -Name X -PSProvider FileSystem -Root "\\fileserver\share" -Credential $using:cred | Out-Null

      Start-Process "\\fileserver\share\app.exe" -ArgumentList "/silent" -Wait

    }

winget の 0x8a15000f および 0x8a150042 を修正

両方のエラーは、winget が対話型ログオンを想定しているのにそれがないために発生しています。回避策は winget-cli のトラッカー全体で文書化されています。

  1. 対象に管理者として一度サインインして、任意の winget コマンドを実行します。たとえば、winget list です。これによりソースが初期化され、後続のリモート呼び出しで 0x8a15000f がクリアされます。

  2. 初回実行時に 0x8a150042 の入力プロンプトが表示されないように、常に同意フラグを指定してください:
    winget install --id Google.Chrome --silent --accept-package-agreements --accept-source-agreements

  3. SYSTEM コンテキストで winget に依存しないでください。winget を提供する App Installer パッケージはユーザーごとに登録されており、その登録は通常 SYSTEM アカウントには存在しないため、C:\Program Files\WindowsApps 内のフルパスを呼び出しても、インストールに失敗することがよくあります。SYSTEM コンテキストでの展開には、代わりに msiexec を PsExec を介して使用するか、パッケージツールを使用してください。

msiexec エラー 1603 を修正

終了コード 1603 は汎用的な致命的エラーなので、推測するのではなく詳細ログを読むのが常に正しい対処です。 Microsoft による 1603 のトラブルシューティング も同じアプローチを示しています。

  1. ターゲット上の書き込み可能なパスに詳細ログを出力するようにして再実行してください:
    msiexec /i "C:\Windows\Temp\app.msi" /qn /l*v "C:\Windows\Temp\install.log"

  2. ログを開き、失敗したアクションの直後にある return value 3 を検索してください。よくある原因は、ディスク空き容量の不足、ユーザー単位とマシン単位のプロパティの不一致、またはロックされたファイルです。

  3. ログが不十分な場合は、RDP 経由で対象上で対話的にインストールを再現してください。SYSTEM コンテキストでの起動にはエラーを表示するデスクトップがないため、GUI インストーラーなら実際のエラーを表示できます。

HelpWire を使用して管理者権限でソフトウェアをリモートでインストールする方法

HelpWire は リモートアクセスソフトウェア で、お使いのデバイス上のアプリ（Operator）から、ライブのインタラクティブセッション内でリモート側のマシンにインストーラーを実行できます。リンク経由で接続し、リモート側に管理者権限を要求します。権限が付与されると、リモートユーザー（Client）のアプリが再起動し、インストーラーを直接実行できるようになります。

セッション中に管理者権限をリクエストする

  1. セッションを開始し、リモートワークステーションに接続します。全体の流れについては、HelpWire の管理者権限ガイドを参照してください。

  2. Operator アプリのツールバーの 管理者アクセスをリクエスト をクリックします。

    Helpwire Operator アプリのツールバーにある管理者アクセスをリクエストするボタンをクリックする

  3. クライアントはアクセスを許可をクリックし、続いてデバイス変更のプロンプトではいを選択します。クライアント アプリは管理者権限で再起動され、接続が復元されます。

  4. ツールバーに管理者アクセスが付与されていますと表示されている状態で、リモートデスクトップ経由でインストーラーを完全な管理者権限で実行してください。

    HelpWire ツールバー上の通知 “管理者権限が付与されました”

ご自身で資格情報を保持している場合は、管理者アクセスをリクエストの横にあるドロップダウンを使用して資格情報で管理者を選択し、その後、管理者アカウントのユーザー名とパスワードを入力してください。リモートユーザーは、クライアントアプリの管理者として再起動で自身の側から昇格することもできます。

インストーラーを向こう側に移して、後で再接続してください

RDP のコピー＆ペーストの問題なしでインストーラーをセッションに直接渡すことができ、または Operator ウィンドウにドラッグできます。修正に後続作業が必要な場合は、無人アクセスにより、リモートユーザーが不在でも後で同じ電源が入ったマシンに再接続できます。

管理者権限への昇格は実際のインタラクティブなデスクトップ内で行われるため、インストーラーとその UAC プロンプトは、対象側のレジストリを編集することなく通常どおりに動作します。

リモートユーザーが制御を保持します。すべての管理者リクエストにはその承認が必要で、いつでもアクセスを取り消すことができます。

よくある質問

不足している権限が誰のものかによります。Program Files や HKLM に書き込むマシン単位のインストールには対象マシンでの管理者権限が必要なので、あなたがそれを開始する側であれば管理者資格情報を提供するか、ユーザーにプロンプトを出すツールで昇格させます。管理者があらかじめ展開メカニズムを構成している場合、対象のエンドユーザーに管理者権限は不要です: グループポリシーのコンピューター割り当てのソフトウェアは、起動時に SYSTEM コンテキストでマシン単位のアプリをインストールし、ユーザーからの昇格は不要です。Google Chrome のようなユーザー単位のアプリも、管理者権限なしでユーザープロファイルにインストールされます。

対象で LocalAccountTokenFilterPolicy を 1 に設定し、その後 PsExec を -h 付きで使用するか、PowerShell でそのマシンを TrustedHosts に追加して使用します。ワークグループ マシンには完全なトークンを配布するドメインがないため、レジストリ値と、明示的なローカル資格情報を用いた NTLM 認証の両方が必要です。

方法によります。RDP 接続はコンソールのユーザーを切断し、セッションをロックしますが、プログラムはそのまま実行し続けます。一方、PsExec、PowerShell リモーティング、そしてサイレントな /qn インストールは、ユーザーを邪魔することなくバックグラウンドで実行されます。アクティブなデスクトップを共有するリモートサポートツールもユーザーをそのままにしておき、勤務時間中に誰かのマシンへインストールする場合に重要になります。

コマンドが戻ったかどうかだけでなく、インストーラーの終了コードを確認してください。0 は成功、3010 と 1641 は再起動を伴う成功、そして 1603 は致命的なエラーを意味します。終了コードが信頼できる指標なので、PowerShell で -PassThru を使って取得してください。アンインストーラーを登録するほとんどの MSI および EXE アプリは、HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall のアンインストールキー、32 ビットアプリではその WOW6432Node ブランチ、ユーザー単位のインストールでは HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall にも表示されますが、すべてのアプリがそこにエントリを書き込むとは限りません。MSIX およびその他の AppX でパッケージ化されたアプリは、ソースに関係なく、代わりに Get-AppxPackage で表示されます。Get-CimInstance Win32_Product は使用を避けてください。Windows Installer 製品しか列挙せず、そのクエリが遅い MSI の整合性チェックを引き起こす可能性があるためです。

HelpWire
4.8

シームレスなITサポートのためのリモートアクセスソフトウェア。無料プランあり。

サイトを表示
リモートアクセス: オンデマンド/無人
対応システム: Windows, macOS, Linux
HelpWire