Um Software aus der Ferne auf einem anderen Computer zu installieren, verbinden Sie sich über Remotedesktop und führen Sie das Installationsprogramm so aus, wie Sie es an der Tastatur tun würden, oder stoßen Sie eine lautlose Installation über die Befehlszeile mit PowerShell Invoke-Command oder PsExec und msiexec /qn an. Die Befehlszeile ist der Ort, an dem die meisten auf Access is denied stoßen, selbst mit dem richtigen Administratorkennwort, weil Windows bei einer Netzwerkanmeldung gewöhnlichen lokalen Administratorkonten ein gefiltertes Token zuweist. Remotedesktop umgeht den Filter, da es sich um eine interaktive Anmeldung handelt, und ein Domänenkonto aus der eigenen Domäne des Ziels erhält in beiden Fällen ein vollständiges Token.
Für ein gewöhnliches lokales Administratorkonto ist die schnellste Abhilfe ein einzelner Registrierungswert auf dem Ziel: Setzen Sie LocalAccountTokenFilterPolicy auf 1 unter HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System, führen Sie dann das Installationsprogramm lautlos aus und erfassen Sie dessen Beendigungscode. Dieser Leitfaden behandelt jede Methode mit erprobten Befehlen, einem Skript für mehrere Computer und einer Lösung für jeden gängigen Fehler, von PSEXESVC-Fehlschlägen bis zu winget 0x8a15000f.
Wenn Sie das Token-Rätsel lieber ganz überspringen möchten, HelpWire ist eine Fernsupport-Software, die sich mit dem Rechner am anderen Ende verbindet, und Sie können während der Sitzung Administratorrechte anfordern. Sie führen das Installationsprogramm in einem echten interaktiven Desktop aus, sodass sich die UAC-Eingabeaufforderung genauso verhält wie direkt an der Tastatur.
Warum Remote-Softwareinstallationen selbst mit einem Administratorkonto fehlschlagen
Die Ursache sind UAC-Remoteeinschränkungen, auch Tokenfilterung genannt. Wenn sich ein lokales Konto, das zur Gruppe Administratoren gehört, über das Netzwerk anmeldet, stellt die Lokale Sicherheitsautorität ihm ein gefiltertes Token mit einer mittleren Integritätsstufe aus, sodass die Gruppe Administratoren sich in einem Nur-Verweigern-Zustand befindet und privilegierte Aktionen blockiert werden. Eine Netzwerkanmeldung, also WinRM, PsExec, WMI oder eine C$-Kopie, erzeugt für lokale Administratoren ein gefiltertes Token.
Zwei Details entscheiden, ob Sie betroffen sind. Ein Domänenkonto aus der eigenen Domäne des Ziels, in der lokalen Gruppe Administratoren, ist ausgenommen und erhält ein vollständiges Token, weshalb man das in Domänenumgebungen selten sieht. Der integrierte RID 500-Administrator ist ebenfalls ein Sonderfall und wird nicht gefiltert, es sei denn, FilterAdministratorToken ist aktiviert. Alle anderen, also gewöhnliche lokale Administratorkonten und Konten aus einer anderen Domäne, erhalten das gefilterte Token, unabhängig davon, ob das Ziel in einer Arbeitsgruppe ist oder einer Domäne beigetreten ist. Diese eine Tatsache erklärt, warum Access is denied bei PsExec, net use, einer C$-Kopie auftritt, sowie das gefilterte, Nicht-Admin-Token, mit dem Sie über Invoke-Command landen.
Die zweite Hauptursache ist die nicht interaktive Sitzung. Ein Remote-Befehl läuft dort, wo niemand klicken kann, sodass ein Installer, der ein Fenster erwartet, entweder hängen bleibt und auf eine Schaltfläche wartet oder sofort fehlschlägt.
So installieren Sie Software per Fernzugriff: Ihre Methodenoptionen im Vergleich
Der schnellste Weg, Software aus der Ferne zu installieren, besteht darin, die Methode an Ihre Umgebung anzupassen, da sich jede Methode in Bezug auf Admin-Token, Arbeitsgruppen und Windows Home anders verhält. Diese Tabelle erleichtert die Wahl, bevor Sie auch nur einen einzigen Befehl ausführen. Gruppenrichtlinie ist hier enthalten, weil sie nur in Domänen verfügbar ist und es sich lohnt, sie frühzeitig ein- oder auszuschließen.
| Methode | Verhalten des Admin-Tokens | Funktioniert in einer Arbeitsgruppe | Windows-Home-Host | Unterbricht den Benutzer | Über das Internet |
| RDP | Vollständiges Token, interaktiv | Ja | Kein Host |
Ja, trennt sie | Mit VPN |
| PowerShell-Remoting | Gefiltert für lokale Administratoren | Mit TrustedHosts |
Ja | Nein | Selten |
cmd + PsExec |
Gefiltert. Verwenden Sie -h. |
Mit Registry-Fix | Ja | Nein | Nein |
| winget | Funktioniert unter WinRM nicht |
Nur lokal ausführbar | Ja | Nein | Nein |
| Gruppenrichtlinie | SYSTEM, computerzugewiesen | Nein, nur Domäne |
Nur Domäne | Nein | Nein |
| HelpWire | Vollständige, interaktive Rechteerweiterung | Ja | Ja | Nein | Ja |
Eine Sache entscheidet über jede der unten aufgeführten Befehlszeilenmethoden: das Konto, mit dem Sie sich verbinden. Ein Domänenkonto aus der eigenen Domäne des Ziels, das Mitglied der Administrators-Gruppe ist, erhält ein vollständiges Token und funktioniert ohne Weiteres. Ein gewöhnliches lokales Administratorkonto erhält das gefilterte Token, sodass seine C$-Kopien und PsExec-Aufrufe Access is denied zurückgeben, und PowerShell-Remoting verweigert entweder die Sitzung oder führt sie ohne Administratorrechte aus, bis Sie auf dem Ziel LocalAccountTokenFilterPolicy auf 1 setzen, was im Abschnitt mit den Korrekturen behandelt wird. RDP ist die Ausnahme, weil es eine interaktive Anmeldung und keine Netzwerk-Anmeldung ist.
So installieren Sie mit Remotedesktop aus der Ferne Software auf einem anderen Computer
Remote Desktop ist die sauberste Methode, Software aus der Ferne auf einem anderen Computer zu installieren, da es sich um eine interaktive Sitzung handelt, die nach dem Bestätigen der UAC-Eingabeaufforderung mit einem vollständigen Administrator-Token ausgeführt wird. Verbinden Sie sich, und installieren Sie dann, als säßen Sie direkt am Gerät.
-
Auf dem Zielsystem drücken Sie Win + R, geben Sie
SystemPropertiesRemoteein und aktivieren Sie Remoteverbindungen mit diesem Computer zulassen. -
Öffnen Sie auf Ihrem Computer die Remotedesktopverbindung (
mstsc.exe), geben Sie den Zielnamen oder die IP-Adresse ein und melden Sie sich mit einem Konto an, das dort lokaler Administrator ist. -
Kopieren Sie das Installationsprogramm über die Sitzung, oder binden Sie unter Lokale Ressourcen ein lokales Laufwerk ein, damit Sie darauf zugreifen können.
-
Führen Sie das Installationsprogramm aus. Wenn die UAC-Eingabeaufforderung erscheint, bestätigen Sie sie im RDP-Fenster, dann schließen Sie den Assistenten ab.
Die Einschränkungen sollte man kennen, bevor man sich darauf verlässt. Windows-Home-Editionen können überhaupt keine RDP-Sitzung hosten. Sie führen nur den Client aus. Auf Client-Windows zählt eine einzelne Konsole, daher trennt eine Verbindung die am Rechner angemeldete Person. Und ein Standardbenutzer ohne Administratoranmeldedaten auf dem Remote-Rechner kann die Aufforderung dennoch nicht bestätigen, was Sie zu den unten beschriebenen Methoden über die Befehlszeile führt.
So installieren Sie Software per Fernzugriff mit PowerShell
Um Software remote mit PowerShell zu installieren, verwendet man Invoke-Command, doch zwei Fallstricke erwischen fast alle. Die Remotesitzung ist nicht interaktiv, daher muss das Installationsprogramm vollständig im Silent-Modus laufen, und die Sitzung kann sich schließen, bevor ein schnell zurückkehrendes Installationsprogramm fertig ist, was die Installation abbricht. Kevin Marquettes bekannter Artikel über Remote-Installationen beschreibt beides, und die Lösung für Letzteres ist Start-Process -Wait.
Auf einem einzelnen Computer mit Invoke-Command installieren
-
Aktivieren Sie auf dem Zielsystem Remoting einmalig. Führen Sie in einem erhöhten PowerShell-Fenster
Enable-PSRemoting -Forceaus. -
Kopieren Sie das Installationsprogramm auf das Ziel, damit die Sitzung nie auf einen Netzwerkpfad zugreifen muss:
Copy-Item -Path "C:\Installers\app.msi" -Destination "\\PC01\c$\Windows\Temp\app.msi" -
Führen Sie es lautlos aus und warten Sie, bis es abgeschlossen ist:
Invoke-Command -ComputerName PC01 -ScriptBlock {Start-Process msiexec.exe -ArgumentList "/i
C:\Windows\Temp\app.msi /qn /norestart" -Wait}Wenn Sie
-Waitweglassen, kann der Skriptblock beendet werden, während das Installationsprogramm noch Dateien kopiert, und das Schließen der Sitzung bricht die Installation mitten im Schreibvorgang ab. Wenn das Installationsprogramm irgendein Fenster anzeigt, bleibt es hängen, weil in einer nicht interaktiven Sitzung niemand darauf klicken kann.
PowerShell-Skript zur Remoteinstallation von Software auf mehreren Computern
Ein PowerShell-Skript durchläuft eine Computerliste, kopiert das Installationsprogramm über die jeweilige Sitzung auf jeden Computer, führt es aus und protokolliert den Exitcode, sodass Sie wissen, was auf jedem Computer gelandet ist. Dadurch wird das Double-Hop-Problem gelöst, indem vorab kopiert wird, anstatt innerhalb der Sitzung auf eine Freigabe zuzugreifen.
$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
Behandeln Sie 3010 und 1641 als Erfolg, nicht als Fehler. Beide bedeuten, dass die Installation funktioniert hat: 3010 bedeutet, dass ein Neustart zum Abschluss erforderlich ist, und 1641 bedeutet, dass das Installationsprogramm den Neustart bereits eingeleitet hat. Viele einfache Skripte kennzeichnen diese fälschlicherweise als Fehlschläge. Beachten Sie, dass Copy-Item -ToSession jeweils nur eine Sitzung bearbeitet, sodass der Kopierschritt pro Rechner erfolgt, auch wenn Invoke-Command auf mehrere Ziele verteilen kann.
Vermeiden Sie die CredSSP-Abkürzung, die für den Double-Hop oft vorgeschlagen wird. Die Community ist davon abgekommen, weil dabei Ihre Administratoranmeldeinformationen auf dem Remote-Host zwischengespeichert werden, wo ein Angreifer sie abgreifen kann. Vorabkopieren, wie oben, umgeht das gesamte Problem.
Häufige msiexec-Rückgabecodes, gegen die geprüft werden sollte:
| Exitcode | Bedeutung |
0 |
Erfolg |
1603 |
Schwerwiegender Fehler während der Installation |
1618 |
Eine andere Installation wird bereits ausgeführt |
1619 |
Installationspaket konnte nicht geöffnet werden |
1638 |
Eine andere Version des Produkts ist bereits installiert |
1641 |
Erfolg, Neustart eingeleitet |
3010 |
Erfolg, Neustart erforderlich |
So installieren Sie Software aus der Ferne mit cmd
Um Software remote mit cmd zu installieren, haben Sie drei Möglichkeiten: PsExec, winget und den älteren WMIC-Befehl, wobei jedoch nur die ersten beiden unter aktuellem Windows zuverlässig sind. Jede davon interagiert unterschiedlich mit dem Administrator-Token, daher sind die Optionen wichtiger als das Tool.
PsExec mit msiexec
-
Laden Sie PsExec von Microsoft Sysinternals herunter und entpacken Sie es. Öffnen Sie
cmdals Administrator, daPsExecbei jedem Ausführen einen Dienst (PSEXESVC) installiert, und dafür sind erhöhte Rechte erforderlich. -
Kopieren Sie die MSI-Datei in die Adminfreigabe des Zielrechners:
copy "C:\Installers\app.msi" \\PC01\C$\Windows\Temp\ -
Führen Sie die stille Installation mit einem erhöhten Token aus. Der
-h-Schalter ist der wichtigste. Er führt den Prozess mit dem erhöhten Token des Kontos aus:psexec \\PC01 -h -accepteula msiexec.exe /i "C:\Windows\Temp\app.msi" /qn /norestart
Lassen Sie den Schalter -i weg, den ältere Anleitungen häufig übernehmen. Er erzwingt eine Desktopinteraktion, die einer Silent-Installation zuwiderläuft und genau die Hänger verursachen kann, die Sie zu vermeiden versuchen. Das Verhalten von -h und die vollständige Schalterliste stammen direkt aus der PsExec-Referenz. Wenn Sie Couldn't install PSEXESVC service: Access Denied sehen, liegt die übliche Ursache in einer lokalen, nicht erhöhten Eingabeaufforderung; allerdings bewirken eine blockierte ADMIN$-Freigabe oder ein gefiltertes Token auf dem Ziel dasselbe. Wenn Sie bei einem Arbeitsgruppenrechner Couldn't access <PC>: Access is denied sehen, ist das die Tokenfilterung, die im Abschnitt mit den Lösungen behandelt wird.
winget von der Befehlszeile aus
winget installiert Apps lokal aus cmd mit einer einzigen Zeile und ist der moderne Ersatz für Legacy-Tools:
winget install --id Google.Chrome --silent --accept-package-agreements --accept-source-agreements
Die Remote-Ausführung ist hingegen problematisch. Über eine WinRM-Sitzung wirft winget häufig A specified logon session does not exist oder meldet, dass winget nicht erkannt wird, weil es als gepackte App läuft, die eine interaktive Anmeldung erwartet. Ein seit Langem bestehendes winget-cli-Problem verfolgt dies, und ein verwandter Bericht zeigt, dass ein erster Remoteaufruf mit 0x8a15000f fehlschlägt, bis ein Admin einmal irgendeinen winget-Befehl lokal auf dieser Maschine ausgeführt hat. Auf einer frischen Maschine stoßen Sie außerdem auf 0x8a150042, einen Eingabeaufforderungsfehler, sofern Sie nicht --accept-source-agreements übergeben. winget unterstützt außerdem das SYSTEM-Konto offiziell nicht, und auf Windows Server wird es nur ab 2025 unterstützt, Server Core ausgenommen, wobei 2019 und 2022 nicht unterstützt und experimentell sind.
Warum die WMIC-Methode nicht mehr funktioniert
Der alte Trick wmic product call install funktioniert unter Windows 11 24H2 und neuer nicht mehr. Laut Microsofts WMIC-Entfernungsmitteilung wurde das Dienstprogramm in Windows 11 23H2 und 24H2 standardmäßig deaktiviert, beim Upgrade auf 25H2 entfernt und durch das Vorschauupdate vom August 2026 aus 24H2 und 25H2 herausgenommen; 26H1 wird ohne es ausgeliefert, und es gibt kein Feature on Demand, um es wiederherzustellen. In diesen Versionen geben Skripte, die wmic.exe aufrufen, 'wmic' is not recognized zurück. Microsoft hat die Entfernung auf Windows 11 beschränkt, daher wird WMIC vorerst weiterhin mit Windows 10 und Windows Server ausgeliefert, aber die allgemeine Empfehlung ist, auf PowerShells Get-CimInstance und Invoke-Command umzusteigen. Der HelpWire-Leitfaden zur Installation per CMD erläutert die Befehlszeilenoptionen ausführlicher.
Unterstützung für Befehlszeilentools nach Windows-Version:
| Funktion | Status | Hinweise |
WMIC |
Entfernt in 24H2, 25H2, 26H1 |
Kein Feature on Demand ab August 2026 |
winget |
Win 10 1809+, Win 11, Server 2025 (nicht Core) |
Keine SYSTEM-Unterstützung; Server 2019/2022 experimentell |
| RDP-Host | Pro, Enterprise, Education | Home-Editionen führen nur den Client aus |
Was die meisten Menschen zuerst versuchen, und warum es fehlschlägt
Oberflächliche Fixes vergeuden Stunden, weil sie das Symptom behandeln, nicht das gefilterte Token auf der Remoteseite. Die lokale cmd als Administrator auszuführen, ändert nichts, da die Filterung auf dem Zielsystem erfolgt, nicht auf Ihrem Rechner. Die Verwendung von runas mit einem gewöhnlichen Administratorkonto liefert Ihnen zwar ein Fenster mit Administratorgruppenmitgliedschaft, aber ohne erhöhte Rechte, sodass Installationen weiterhin fehlschlagen.
Das vollständige Deaktivieren der UAC mit EnableLUA auf 0 lässt die Installation zwar zu, aber es lässt Administratorrechte unkontrolliert und lässt Store-Apps nicht mehr funktionieren, weshalb Microsoft und die Community davor warnen. Keines davon geht die eigentliche Ursache an; der nächste Abschnitt schon.
Die bewährten Lösungen für “Zugriff verweigert” und Elevationsfehler
Beginnen Sie mit der Fehlermeldung und springen Sie dann zur Lösung. Jeder der unten aufgeführten Punkte ist durch Microsoft-Dokumentation, Wissensdatenbanken der Anbieter und Community-Threads bestätigt.
| Fehlermeldung | Ausgelöst von | Grundursache |
Zugriff verweigert |
PsExec, net use, C$ |
Gefiltertes Administrator-Token |
Konnte den Dienst PSEXESVC nicht installieren |
PsExec |
Lokale Eingabeaufforderung nicht erhöht oder Ziel ADMIN$/Token blockiert |
0x80090322 |
WinRM |
Arbeitsgruppen- oder SPN-Problem |
Zugriff verweigert |
Invoke-Command auf eine Freigabe |
Double-Hop |
0x8a15000f |
winget über WinRM |
Quelldaten fehlen |
1603 |
msiexec |
Schwerwiegender Installationsfehler |
“Zugriff verweigert” mit LocalAccountTokenFilterPolicy beheben
Setzen Sie am Ziel einen Registrierungswert, um lokalen Administratorkonten über das Netzwerk ein vollständiges Token zu geben. Dies ist der Fix, der von PDQ, Broadcom und unzähligen PsExec-Threads bestätigt wurde.
-
Öffnen Sie auf dem Zielsystem den Registrierungs-Editor (
regedit) und navigieren Sie zu:HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System -
Erstellen Sie einen DWORD-Wert mit dem Namen
LocalAccountTokenFilterPolicyund setzen Sie ihn auf 1. Oder führen Sie Folgendes in einer erhöhten Eingabeaufforderung aus:reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f -
Wiederholen Sie die Installation. Um dies anschließend rückgängig zu machen, setzen Sie den Wert wieder auf
0, wodurch die Remote-UAC-Filterung wieder aktiviert wird.
Dies ist nicht erforderlich, wenn Sie sich mit einem Domänenadministratorkonto aus der eigenen Domäne des Ziels verbinden, das bereits ein vollständiges Token erhält. Microsoft hat die Filterung entwickelt, um Loopback-Angriffe zu blockieren, sodass das Deaktivieren die Angriffsfläche vergrößert. Setzen Sie es gezielt und stellen Sie es wieder zurück, wenn die Aufgabe erledigt ist.
Behebung “Konnte den PSEXESVC-Dienst nicht installieren”
Dies ist fast immer ein lokales Problem mit erhöhten Rechten, bestätigt auf Microsoft Q&A.
-
Schließen Sie Ihre Eingabeaufforderung und öffnen Sie
cmdoder PowerShell als Administrator erneut.PsExecinstalliert seinen Dienst bei jedem Aufruf und kann dies nicht über eine normale Eingabeaufforderung durchführen. -
Wenn es weiterhin fehlschlägt, kann eine verwaiste
psexecsvc.exeauf dem Ziel hängen bleiben. Überprüfen Sie%windir%auf dem Remotecomputer und entfernen Sie eine eventuell verbliebene Kopie, dann versuchen Sie es erneut. -
Bestätigen Sie, dass die
ADMIN$-Freigabe des Ziels erreichbar ist und die Datei- und Druckerfreigabe (SMB über TCP445) durch dessen Firewall zugelassen ist, daPsExecden DienstPSEXESVCdorthin kopiert, um ihn auszuführen.
WinRM 0x80090322 auf Arbeitsgruppencomputern beheben
PowerShell-Remoting in einer Arbeitsgruppe schlägt fehl, weil Kerberos ein lokales Konto nicht authentifizieren kann, daher fügen Sie das Ziel zu TrustedHosts hinzu und erzwingen NTLM. Der WinRM-Fehlertext selbst nennt den TrustedHosts-Pfad.
-
Auf Ihrem Computer, aus einer mit Administratorrechten gestarteten PowerShell, fügen Sie das Ziel hinzu:
Set-Item WSMan:\localhost\Client\TrustedHosts -Value "PC01" -Concatenate -
Verbinden Sie sich mit expliziten lokalen Anmeldeinformationen, damit Negotiate auf NTLM zurückfällt:
$cred = Get-CredentialInvoke-Command -ComputerName PC01 -Credential $cred -ScriptBlock { hostname }
-
Wenn der Fehler bei einem Domänen-FQDN statt einer Arbeitsgruppe weiterhin auftritt, handelt es sich um ein SPN-Problem. Microsoft KB 4549715 beschreibt die Workarounds
-IncludePortInSPNundspn_prefix.
„Zugriff verweigert“ beim Double-Hop beheben
Wenn die Remotesitzung einen UNC-Pfad erreicht, kann sie sich nicht authentifizieren, die Datei vorab kopieren oder sich innerhalb des Skriptblocks erneut authentifizieren.
-
Vorzugsweise: Kopieren Sie das Installationsprogramm zuerst auf das Ziel, wie im Multi-Computer-Skript, damit die Sitzung nur einen lokalen Pfad nutzt.
-
Oder verbinden Sie innerhalb der Sitzung ein Netzlaufwerk mit neuen Anmeldeinformationen. Der Aufruf von
New-PSDriveauthentifiziert eine Verbindung zum Dateiserver, und der untenstehende direkte UNC-Start verwendet diese Verbindung erneut, sodass die Anmeldeinformationen übernommen werden, obwohl der Befehl nie auf das zugeordnete Laufwerk verweist:
$cred = Get-CredentialInvoke-Command -ComputerName PC01 -ScriptBlock {New-PSDrive -Name X -PSProvider FileSystem -Root "\\fileserver\share" -Credential $using:cred | Out-NullStart-Process "\\fileserver\share\app.exe" -ArgumentList "/silent" -Wait}
winget 0x8a15000f und 0x8a150042 beheben
Beide Fehler entstehen dadurch, dass winget eine interaktive Anmeldung erwartet, die nicht vorhanden ist. Der Workaround ist im winget-cli tracker dokumentiert.
-
Melden Sie sich einmal als Administrator am Ziel an und führen Sie einen beliebigen winget-Befehl aus, zum Beispiel
winget list. Dadurch wird die Quelle initialisiert und0x8a15000fbei späteren Remoteaufrufen beseitigt. -
Übergeben Sie die Zustimmungs-Flags immer, um die Eingabeaufforderung
0x8a150042beim ersten Start zu vermeiden:winget install --id Google.Chrome --silent --accept-package-agreements --accept-source-agreements -
Verlassen Sie sich im SYSTEM-Kontext nicht auf winget. Das App-Installer-Paket, das winget bereitstellt, wird pro Benutzer registriert, und diese Registrierung ist für das SYSTEM-Konto normalerweise nicht vorhanden, sodass selbst der Aufruf des vollständigen Pfads in
C:\Program Files\WindowsAppshäufig weiterhin fehlschlägt. Für Bereitstellungen im SYSTEM-Kontext verwenden Sie stattdessenmsiexecüberPsExecoder ein Pakettool.
msiexec-Fehler 1603 beheben
Exitcode 1603 ist ein allgemeiner schwerwiegender Fehler, daher besteht die Behebung immer darin, das ausführliche Protokoll zu lesen, statt zu raten. Microsofts Problembehandlung zu 1603 weist auf denselben Ansatz hin.
-
Erneut ausführen mit ausführlicher Protokollierung in einen beschreibbaren Pfad auf dem Zielsystem:
msiexec /i "C:\Windows\Temp\app.msi" /qn /l*v "C:\Windows\Temp\install.log" -
Öffnen Sie das Protokoll und suchen Sie nach
return value 3, das direkt nach der fehlgeschlagenen Aktion steht. Häufige Ursachen sind zu wenig freier Speicherplatz, eine Nichtübereinstimmung zwischen Eigenschaften auf Benutzer- und auf Computerebene oder eine gesperrte Datei. -
Wenn das Protokoll nicht aussagekräftig ist, führen Sie die Installation interaktiv auf dem Zielsystem über RDP erneut durch, wo ein grafischer Installer seinen tatsächlichen Fehler anzeigen kann, da ein Start im SYSTEM-Kontext keinen Desktop hat, um ihn anzuzeigen.
So installieren Sie mithilfe von HelpWire Software aus der Ferne mit Administratorrechten
HelpWire ist Fernzugriffssoftware, mit der Sie eine Installation auf einem entfernten Rechner innerhalb einer interaktiven Live-Sitzung über die App (Operator) auf Ihrem Gerät ausführen können. Sie verbinden sich über einen Link und fordern Administratorrechte auf der entfernten Seite an. Sobald die Rechte gewährt wurden, startet die App des entfernten Benutzers (Client) neu, damit Sie Installationsprogramme direkt ausführen können.
Administratorrechte während einer Sitzung anfordern
-
Starten Sie eine Sitzung und stellen Sie eine Verbindung zur Remote-Workstation her. Den vollständigen Ablauf finden Sie im HelpWire-Leitfaden zu Administratorrechten.
-
Klicken Sie auf Administratorzugriff anfordern in der Symbolleiste der Operator-App.
-
Der Client klickt auf Zugriff gewähren und dann bei der Eingabeaufforderung zur Geräteänderung auf Ja. Die Client-App wird mit Administratorrechten neu gestartet und die Verbindung wird wiederhergestellt.
-
Wenn in der Symbolleiste Adminzugriff gewährt angezeigt wird, führen Sie Ihr Installationsprogramm über den Remotedesktop mit vollen Administratorrechten aus.
Wenn Sie die Anmeldedaten selbst besitzen, verwenden Sie das Dropdown-Menü neben Administratorzugriff anfordern und wählen Sie Administrator mit Anmeldedaten, dann geben Sie den Benutzernamen und das Passwort für das Administratorkonto ein. Der Remote-Benutzer kann die Berechtigungen auch auf seiner Seite über Als Administrator neu starten in der Client-App erhöhen.
Übertragen Sie das Installationsprogramm, dann verbinden Sie sich später erneut
Sie können ein Installationsprogramm direkt in die Sitzung bringen, ohne Probleme beim Kopieren und Einfügen über RDP, oder es auf das Operator-Fenster ziehen. Wenn eine Fehlerbehebung Folgearbeiten erfordert, ermöglicht unbeaufsichtigter Zugriff, später erneut eine Verbindung mit demselben eingeschalteten Computer herzustellen, ohne dass der Remote-Benutzer anwesend ist.
Die Rechteerhöhung auf Administrator erfolgt innerhalb eines echten interaktiven Desktops, sodass Installationsprogramme und ihre UAC-Eingabeaufforderungen sich normal verhalten, ohne Änderungen an der Registrierung des Zielsystems.
Der Remote-Benutzer behält die Kontrolle. Jede Anforderung von Administratorrechten erfordert seine Zustimmung, und er kann den Zugriff jederzeit widerrufen.
Häufig gestellte Fragen
Es hängt davon ab, wessen Berechtigungen fehlen. Eine systemweite Installation, die in Program Files oder HKLM schreibt, benötigt Administratorrechte auf dem Zielsystem; wenn Sie sie also starten, geben Sie Administratoranmeldedaten an oder führen eine Rechteerhöhung über ein Tool durch, das den Benutzer dazu auffordert. Der Endbenutzer am Ziel benötigt keine Administratorrechte, wenn ein Administrator einen Bereitstellungsmechanismus vorkonfiguriert hat: Über Gruppenrichtlinien computerzugewiesene Software installiert systemweite Anwendungen beim Start im SYSTEM-Kontext, ohne dass der Benutzer eine Rechteerhöhung vornehmen muss. Benutzerspezifische Apps wie Google Chrome werden ebenfalls ohne Administratorrechte im Benutzerprofil installiert.
Setzen Sie LocalAccountTokenFilterPolicy auf 1 auf dem Ziel, und verwenden Sie dann PsExec mit -h oder PowerShell mit dem Computer, der zu TrustedHosts hinzugefügt wurde. Arbeitsgruppenrechner haben keine Domäne, die vollständige Token ausstellt, daher sind sowohl der Registrierungswert als auch die NTLM-Authentifizierung mit expliziten lokalen Anmeldeinformationen erforderlich.
Es hängt von der Methode ab. Eine RDP-Verbindung trennt die Person an der Konsole, sperrt deren Sitzung, während ihre Programme weiterlaufen, wohingegen PsExec, PowerShell-Remoting und eine stille /qn-Installation im Hintergrund laufen, ohne sie zu stören. Ein Remote-Support-Tool, das den aktiven Desktop teilt, lässt den Benutzer ebenfalls an Ort und Stelle, was wichtig ist, wenn man mitten am Arbeitstag auf dem Rechner einer anderen Person installiert.
Prüfen Sie den Exitcode des Installationsprogramms, nicht nur, ob der Befehl beendet wurde. Eine 0 bedeutet Erfolg, 3010 und 1641 bedeuten Erfolg mit anschließendem Neustart, und 1603 bedeutet einen schwerwiegenden Fehler. Der Exitcode ist das verlässliche Signal, daher erfassen Sie ihn mit -PassThru in PowerShell. Die meisten MSI- und EXE-Apps, die ein Deinstallationsprogramm registrieren, erscheinen außerdem unter den Deinstallationsschlüsseln bei HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall, dessen Zweig WOW6432Node für 32-Bit-Apps, und HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall für benutzerspezifische Installationen, auch wenn nicht jede App dort einen Eintrag schreibt. MSIX- und andere AppX-verpackte Apps erscheinen stattdessen über Get-AppxPackage, unabhängig von ihrer Quelle. Verzichten Sie auf Get-CimInstance Win32_Product, da es nur Windows-Installer-Produkte auflistet und seine Abfrage eine langsame MSI-Konsistenzprüfung auslösen kann.
