Hur man fjärrinstallerar programvara på en annan dator

avatar okt 22, 2026
Remotely installing software on another computer

För att fjärrinstallera programvara på en annan dator, anslut via Fjärrskrivbord och kör installationsprogrammet som om du satt vid tangentbordet, eller rulla ut en tyst installation från kommandoraden med PowerShell Invoke-Command eller PsExec och msiexec /qn. Det är på kommandoraden som de flesta stöter på Access is denied även med rätt administratörslösenord, eftersom Windows ger vanliga lokala administratörskonton en filtrerad token vid en nätverksinloggning. Fjärrskrivbord kringgår filtret eftersom det är en interaktiv inloggning, och ett domänkonto från målets egen domän får en fullständig token oavsett.

För ett vanligt lokalt administratörskonto är den snabbaste lösningen ett enda registervärde på målet: ställ in LocalAccountTokenFilterPolicy till 1 under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System, kör sedan installationsprogrammet tyst och fånga dess returkod. Den här guiden täcker varje metod med testade kommandon, ett skript för flera datorer och en lösning för varje vanligt fel, från PSEXESVC-fel till winget 0x8a15000f.

Om du hellre vill hoppa över token-pusslet helt och hållet är HelpWire ett fjärrsupportprogram som ansluter till en dator i andra änden, och du kan begära administratörsrättigheter under sessionen. Du kör installationsprogrammet i en riktig interaktiv skrivbordsmiljö, så beter sig elevationsprompten likadant som när du sitter vid tangentbordet.

Innehållsförteckning

Varför fjärrinstallationer av programvara misslyckas även med ett administratörskonto

Orsaken är UAC-fjärrbegränsningar, även kallat tokenfiltrering. När ett lokalt konto som tillhör gruppen Administratörer loggar in över nätverket ger Local Security Authority det en filtrerad token med en medelhög integritetsnivå, så att gruppen Administratörer hamnar i ett deny-only-tillstånd och privilegierade åtgärder blockeras. Nätverksinloggning, det vill säga WinRM, PsExec, WMI eller en C$-kopiering, resulterar i en filtrerad token för lokala administratörer.

Två detaljer avgör om du påverkas. Ett domänkonto från målets egen domän, i den lokala gruppen Administratörer, är undantaget och får en fullständig token, vilket är anledningen till att domänmiljöer sällan ser detta. Den inbyggda administratören med RID 500 är också ett specialfall och filtreras inte om inte FilterAdministratorToken är aktiverat. Alla andra, alltså vanliga lokala administratörskonton och konton från en annan domän, får den filtrerade tokenen, oavsett om målet är i en arbetsgrupp eller anslutet till en domän. Detta ensamma faktum förklarar varför Access is denied från PsExec, net use, en C$-kopiering, samt den filtrerade icke-admin-token du landar med via Invoke-Command.

Den andra grundorsaken är den icke-interaktiva sessionen. Ett fjärrkommando körs där ingen kan klicka, så ett installationsprogram som förväntar sig ett fönster antingen fastnar och väntar på en knapp eller misslyckas direkt.

Så installerar du programvara på distans: dina metodalternativ jämförda

Det snabbaste sättet att installera programvara på distans är att anpassa metoden till din miljö, eftersom varje metod beter sig olika med administratörstoken, arbetsgrupper och Windows Home. Den här tabellen avgör det valet innan du kör ett enda kommando. Gruppolicy tas med här eftersom den bara fungerar i domäner och är värd att tidigt avgöra om den är aktuell eller inte.

Metod Administratörstokens beteende Fungerar i en arbetsgrupp Windows Home-värd Avbryter användaren Över internet
RDP Fullständig token, interaktiv Ja No host Ja, kopplar bort dem Med VPN
PowerShell-fjärrkörning Filtrerad för lokala administratörer Med TrustedHosts Ja Nej Sällan
cmd + PsExec Filtrerad. Använd -h. Med registerändring Ja Nej Nej
winget Fungerar inte under WinRM Endast lokal körning Ja Nej Nej
Gruppolicy SYSTEM, dator-tilldelad No, endast domän Endast domän Nej Nej
HelpWire Fullständig, interaktiv förhöjning Ja Ja Nej Ja

En sak avgör varje kommandoradsmetod nedan: kontot du ansluter med. Ett domänkonto från målets egen domän, i dess Administrators-grupp, får en fullständig token och fungerar direkt. Ett vanligt lokalt administratörskonto får en filtrerad token, så att dess C$-kopieringar och PsExec-anrop returnerar Access is denied, och PowerShell-fjärrkörning antingen nekar sessionen eller kör den utan administratörsrättigheter, tills du ställer in LocalAccountTokenFilterPolicy till 1 på målet, vilket behandlas i avsnittet med åtgärder. RDP är undantaget, eftersom det är en interaktiv inloggning snarare än en nätverksinloggning.

Så här installerar du programvara på en annan dator på distans med Fjärrskrivbord

Fjärrskrivbord är det mest renodlade sättet att fjärrinstallera programvara på en annan dator, eftersom det är en interaktiv session som körs med en fullständig administratörstoken när du väl har godkänt UAC-dialogrutan. Anslut och installera sedan som om du satt vid datorn.

  1. På målet, tryck på Win + R, skriv SystemPropertiesRemote, och aktivera Tillåt fjärranslutningar till den här datorn.

  2. Öppna på din dator Anslutning till fjärrskrivbord (mstsc.exe), ange målets namn eller IP-adress och logga in med ett konto som är lokal administratör där.

  3. Kopiera installationsprogrammet via sessionen, eller mappa en lokal enhet under Lokala resurser så att du kan komma åt den.

  4. Kör installationsprogrammet. När UAC-prompten visas, godkänn den i RDP-fönstret och slutför sedan guiden.

Det är värt att känna till begränsningarna innan du förlitar dig på det. Windows Home-utgåvor kan inte agera värd för en RDP-session alls. De kör bara klienten. På Windows-klienter räknas bara en enda konsol, så att ansluta kopplar från den person som är inloggad vid datorn. Och en standardanvändare utan administratörsbehörighet på fjärrdatorn kan fortfarande inte godkänna uppmaningen, vilket leder dig till kommandoradsmetoderna nedan.

Så här installerar du programvara på distans med PowerShell

För att installera programvara på distans med PowerShell förlitar du dig på Invoke-Command, men två fällor fångar nästan alla. Fjärrsessionen är icke-interaktiv, så installationsprogrammet måste köras helt tyst, och sessionen kan stängas innan ett installationsprogram som returnerar snabbt hinner bli klart, vilket avbryter installationen. Kevin Marquettes välkänd artikel om fjärrinstallationer beskriver båda, och lösningen på den andra är Start-Process -Wait.

Installera på en enskild dator med Invoke-Command

  1. På måldatorn aktiverar du fjärrkommunikation en gång. Från ett förhöjt PowerShell-fönster kör du Enable-PSRemoting -Force.

  2. Kopiera installationsfilen till måldatorn så att sessionen aldrig behöver komma åt en nätverkssökväg:
    Copy-Item -Path "C:\Installers\app.msi" -Destination "\\PC01\c$\Windows\Temp\app.msi"

  3. Kör det i tyst läge och vänta tills det är klart:
    Invoke-Command -ComputerName PC01 -ScriptBlock {

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

    }

    Om du utelämnar -Wait, kan skriptblocket avslutas medan installationsprogrammet fortfarande kopierar filer, och om sessionen stängs avbryts installationen mitt under skrivningen. Om installationsprogrammet visar något fönster hänger det, eftersom inget i en icke-interaktiv session kan klicka på det.

PowerShell-skript för att fjärrinstallera programvara på flera datorer

Ett PowerShell-skript går igenom en lista över datorer, kopierar installationsprogrammet till varje maskin via dess egen session, kör det och registrerar avslutskoden så att du vet vad som hamnade på varje maskin. Detta hanterar double-hop-problemet genom att kopiera i förväg i stället för att nå en delad resurs inifrån sessionen.

$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 = "Ej tillämpligt"; Success = $false }
}
}
$results | Export-Csv "C:\Installers\install-report.csv"
-NoTypeInformation

Behandla 3010 och 1641 som lyckade, inte som fel. Båda betyder att installationen lyckades: 3010 betyder att en omstart krävs för att slutföra, och 1641 betyder att installationsprogrammet redan har initierat omstarten. Många enkla skript flaggar felaktigt dessa som fel. Observera att Copy-Item -ToSession kör en session i taget, så kopieringssteget sker per maskin även om Invoke-Command kan köras parallellt.

Undvik CredSSP-genvägen som du ser föreslagen för dubbelhoppet. Gemenskapen har gått ifrån den eftersom den cachar dina administratörsreferenser på den fjärrvärd där en angripare kan komma åt dem. Förkopiering, som ovan, kringgår hela problemet.

Vanliga msiexec-utgångskoder att kontrollera mot:

Returkod Betydelse
0 Lyckades
1603 Allvarligt fel under installationen
1618 En annan installation pågår redan
1619 Installationspaketet kunde inte öppnas
1638 En annan version av produkten är redan installerad
1641 Lyckades, omstart initierad
3010 Lyckades, omstart krävs

Hur man installerar programvara på distans med cmd

För att fjärrinstallera programvara med cmd har du tre sätt: PsExec, winget och det äldre WMIC-kommandot, även om bara de två första är tillförlitliga i nuvarande Windows. Var och en interagerar med administratörstoken på olika sätt, så växlarna är viktigare än verktyget.

PsExec med msiexec

  1. Ladda ned PsExec från Microsoft Sysinternals och packa upp det. Öppna cmd som administratör, eftersom PsExec installerar en tjänst (PSEXESVC) vid varje körning, och det kräver förhöjda rättigheter.

  2. Kopiera MSI-filen till måldatorns administrativa delning:
    copy "C:\Installers\app.msi" \\PC01\C$\Windows\Temp\

  3. Kör den tysta installationen med en förhöjd token. Flaggan -h är den viktiga. Den kör processen med kontots förhöjda token:
    psexec \\PC01 -h -accepteula msiexec.exe /i "C:\Windows\Temp\app.msi" /qn /norestart

Hoppa över flaggan -i som äldre guider kopierar runt. Den tvingar skrivbordsinteraktion, vilket motverkar en tyst installation och kan orsaka just de hängningar du försöker undvika. Beteendet för -h och hela listan över växlar kommer direkt från PsExec-referensen. Om du ser Couldn't install PSEXESVC service: Access Denied är den vanliga orsaken en lokal prompt som inte är förhöjd, även om en blockerad ADMIN$-delning eller det filtrerade tokenet på målet gör samma sak. Om du ser Couldn't access <PC>: Access is denied mot en arbetsgruppsdator är det den tokenfiltrering som täcks i avsnittet med åtgärder.

winget från kommandoraden

winget installerar appar lokalt från cmd med en enda rad, och det är den moderna ersättaren för äldre verktyg:

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

Att köra det på distans är där det krånglar. Över en WinRM-session kastar winget ofta A specified logon session does not exist eller rapporterar att winget inte känns igen, eftersom det körs som en paketerad app som förutsätter en interaktiv inloggning. En sedan länge pågående winget-cli-fråga tar upp detta, och en relaterad rapport visar att ett första fjärranrop misslyckas med 0x8a15000f tills en administratör har kört valfritt winget-kommando lokalt på den datorn en gång. På en ny maskin stöter du också på 0x8a150042, ett fel vid inmatningsprompt, om du inte anger --accept-source-agreements. winget stöder inte heller officiellt SYSTEM-kontot, och på Windows Server stöds det bara på 2025 och senare, exklusive Server Core, där 2019 och 2022 inte stöds och betraktas som experimentella.

Varför WMIC-metoden inte längre fungerar

Det gamla knepet wmic product call install fungerar inte längre i Windows 11 24H2 och senare. Enligt Microsofts meddelande om borttagning av WMIC inaktiverades verktyget som standard i Windows 11 23H2 och 24H2, togs bort vid uppgradering till 25H2 och plockades bort ur 24H2 och 25H2 genom förhandsversionsuppdateringen i augusti 2026, med 26H1 som levereras utan det och ingen Funktion på begäran för att återställa det. I dessa utgåvor returnerar skript som anropar wmic.exe 'wmic' is not recognized. Microsoft begränsade borttagningen till Windows 11, så WMIC levereras fortfarande med Windows 10 och Windows Server tills vidare, men rekommendationen överallt är att gå över till PowerShells Get-CimInstance och Invoke-Command. HelpWires cmd-installationsguide går igenom kommandoradsalternativen mer ingående.

Stöd för kommandoradsverktyg efter Windows-version:

Funktion Status Anmärkningar
WMIC Borttagen i 24H2, 25H2, 26H1 Ingen funktion på begäran från augusti 2026
winget Win 10 1809+, Win 11, Server 2025 (inte Core) Inget stöd för SYSTEM; Server 2019/2022 experimentellt
RDP-värd Pro, Enterprise, Education Home-utgåvor kör endast klienten
 

Vad de flesta försöker först, och varför det misslyckas

De ytliga åtgärderna slösar timmar eftersom de behandlar symptomet, inte den filtrerade tokenen på fjärrsidan. Att köra din lokala cmd som administratör ändrar ingenting, eftersom filtreringen sker på målet, inte på din dator. Att använda runas med ett vanligt administratörskonto ger dig ett fönster som har medlemskap i administratörsgruppen men saknar förhöjda rättigheter, så installationer misslyckas ändå.

Att helt inaktivera UAC med EnableLUA satt till 0 släpper igenom installationen, men lämnar administratörsrättigheter okontrollerade och gör att Store-appar slutar fungera, vilket är varför Microsoft och communityn varnar för det. Inget av detta berör den faktiska orsaken, vilket nästa avsnitt gör.

De beprövade lösningarna på ”Åtkomst nekad” och fel vid upphöjning av behörighet

Börja med felmeddelandet och hoppa sedan till dess åtgärd. Var och en nedan är bekräftad i Microsofts dokumentation, leverantörers kunskapsbaser och communitytrådar.

Felmeddelande Genereras av Grundorsak
Access is denied PsExec, net use, C$ Filtrerat administratörstoken
Couldn't install PSEXESVC service PsExec Lokal prompt inte förhöjd, eller målet ADMIN$/token blockerat
0x80090322 WinRM Problem med arbetsgrupp eller SPN
Access denied Invoke-Command till en delad resurs Dubbelhopp
0x8a15000f winget över WinRM Källdata saknas
1603 msiexec Allvarligt fel vid installation

Åtgärda ”Åtkomst nekad” med LocalAccountTokenFilterPolicy

Ställ in ett registervärde på målsystemet för att ge lokala administratörskonton en fullständig token över nätverket. Detta är lösningen som bekräftats av PDQ, Broadcom och otaliga PsExec-trådar.

  1. På måldatorn, öppna Registereditorn (regedit) och gå till:
    HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System

  2. Skapa ett DWORD med namnet LocalAccountTokenFilterPolicy och ställ in det på 1. Eller kör detta från en kommandotolk med administratörsbehörighet:
    reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f

  3. Försök att installera igen. För att återställa efteråt, ställ tillbaka värdet till 0, vilket återaktiverar fjärr-UAC-filtrering.

Det är onödigt när du ansluter med ett domänadministratörskonto från målets egen domän, vilket redan får en fullständig token. Microsoft utformade filtreringen för att blockera loopback-attacker, så att stänga av den vidgar attackytan. Ställ in det medvetet och återställ när arbetet är klart.

Åtgärda “Kunde inte installera PSEXESVC-tjänsten”

Detta är nästan alltid ett lokalt behörighetsproblem, bekräftat på Microsoft Q&A.

  1. Stäng din prompt och öppna cmd eller PowerShell på nytt som administratör. PsExec installerar sin tjänst vid varje körning och kan inte göra det från en vanlig prompt.

  2. Om det fortfarande misslyckas kan en inaktuell psexecsvc.exe fastna på måldatorn. Kontrollera %windir% på den fjärranslutna datorn och ta bort eventuell kvarvarande kopia, försök sedan igen.

  3. Bekräfta att målets ADMIN$-resurs är åtkomlig och att Fildelning och skrivardelning (SMB över TCP 445) tillåts genom dess brandvägg, eftersom PsExec kopierar tjänsten PSEXESVC dit för att köra den.

Åtgärda WinRM 0x80090322 på datorer i en arbetsgrupp

PowerShell-fjärrkörning i en arbetsgrupp misslyckas eftersom Kerberos inte kan autentisera ett lokalt konto, så du lägger till målet i TrustedHosts och tvingar NTLM. Själva feltexten för WinRM anger sökvägen till TrustedHosts.

  1. På din dator, från en PowerShell med administratörsbehörighet, lägg till målet:
    Set-Item WSMan:\localhost\Client\TrustedHosts -Value "PC01" -Concatenate

  2. Anslut med explicita lokala inloggningsuppgifter så att Negotiate faller tillbaka på NTLM:
    $cred = Get-Credential

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

  3. Om felet kvarstår med ett domän-FQDN i stället för en arbetsgrupp är det ett SPN-problem. Microsoft KB 4549715 täcker lösningarna -IncludePortInSPN och spn_prefix.

Åtgärda dubbelhoppsfelet “Åtkomst nekad”

När fjärrsessionen når en UNC-sökväg kan den inte autentisera sig, kopiera filen i förväg eller autentisera sig på nytt inuti skriptblocket.

  1. Helst: kopiera först installationsprogrammet till målet, som i skriptet för flera datorer, så att sessionen bara använder en lokal sökväg.

  2. Eller mappa en enhet med nya autentiseringsuppgifter i sessionen. Anropet till New-PSDrive autentiserar en anslutning till filservern, och den direkta UNC-starten nedan återanvänder den anslutningen, så att autentiseringsuppgifterna följer med även om kommandot aldrig hänvisar till den mappade enheten:
    $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

    }

Åtgärda winget 0x8a15000f och 0x8a150042

Båda felen beror på att winget förväntar sig en interaktiv inloggning som inte är tillgänglig. Den tillfälliga lösningen är dokumenterad i winget-cli:s ärendehanterare.

  1. Logga in på målsystemet en gång som administratör och kör valfritt winget-kommando, till exempel winget list. Detta initierar källan och rensar 0x8a15000f vid senare fjärranrop.

  2. Ange alltid avtalsflaggorna för att undvika 0x8a150042-inmatningsprompten vid första körningen:
    winget install --id Google.Chrome --silent --accept-package-agreements --accept-source-agreements

  3. Lita inte på winget i SYSTEM-kontexten. Paketet App Installer som tillhandahåller winget registreras per användare, och den registreringen finns normalt inte för SYSTEM-kontot, så misslyckas installationen ofta ändå trots att man anropar den fullständiga sökvägen i C:\Program Files\WindowsApps. För distribution i SYSTEM-kontext, använd msiexec genom PsExec eller ett paketverktyg i stället.

Åtgärda msiexec-fel 1603

Utgångskod 1603 är ett generiskt allvarligt fel, så lösningen är alltid att läsa den detaljerade loggen i stället för att gissa. Microsofts felsökning av 1603 pekar på samma tillvägagångssätt.

  1. Kör om med utförlig loggning till en skrivbar sökväg på målet:
    msiexec /i "C:\Windows\Temp\app.msi" /qn /l*v "C:\Windows\Temp\install.log"

  2. Öppna loggen och sök efter return value 3, som kommer precis efter den misslyckade åtgärden. Vanliga orsaker är brist på diskutrymme, en egenskapskonflikt mellan per användare och per dator, eller en låst fil.

  3. Om loggen inte är entydig, återskapa installationen interaktivt på målsystemet via RDP, där det grafiska installationsprogrammet kan visa sitt verkliga felmeddelande, eftersom en körning i SYSTEM-kontot inte har något skrivbord att visa det på.

Hur fjärrinstallerar man programvara med administratörsrättigheter med hjälp av HelpWire

HelpWire är fjärråtkomstprogramvara som låter dig köra en installation på en maskin i andra änden i en live, interaktiv session från appen (Operator) på din enhet. Du ansluter via en länk och begär administratörsrättigheter på fjärrsidan. När rättigheterna har beviljats startas fjärranvändarens (Client) app om så att du kan köra installationsprogram direkt.

Begär administratörsåtkomst under en session

  1. Starta en session och anslut till fjärrarbetsstationen. Se HelpWires guide om administratörsbehörigheter för hela processen.

  2. Klicka på Begär administratörsåtkomst på verktygsfältet i Operator-appen.

    Att klicka på knappen Begär adminåtkomst i Helpwire Operator-appens verktygsfält

  3. Klienten klickar på Bevilja åtkomst, sedan Ja i dialogrutan för enhetsändring. Klientappen startas om med administratörsrättigheter och anslutningen återställs.

  4. När Administratörsåtkomst beviljad visas i verktygsfältet, kör ditt installationsprogram via fjärrskrivbordet som fullständig administratör.

    Avisering “Administratörsbehörighet beviljad” på HelpWire-verktygsfältet

Om du har inloggningsuppgifterna själv, använd rullgardinsmenyn bredvid Begär administratörsåtkomst och välj Administratör med inloggningsuppgifter, ange sedan användarnamnet och lösenordet för administratörskontot. Den fjärranslutna användaren kan också höja behörigheten från sin sida med Starta om som administratör i Klientappen.

Flytta över installationsprogrammet, återanslut senare

Du kan få in ett installationsprogram direkt i sessionen utan problem med kopiera och klistra in i RDP, eller dra det till Operator-fönstret. När en åtgärd kräver uppföljning gör obevakad åtkomst att du kan återansluta till samma påslagna dator senare utan att fjärranvändaren behöver vara närvarande.

Upphöjning till administratör sker i ett riktigt interaktivt skrivbord, så installationsprogram och deras UAC-dialogrutor beter sig normalt utan några registerändringar på måldatorn.

Fjärranvändaren behåller kontrollen. Varje begäran om administratörsrättigheter kräver deras godkännande, och de kan när som helst återkalla åtkomsten.

Vanliga frågor

Det beror på vems behörighet som saknas. En maskinvis installation som skriver till Program Files eller HKLM kräver administratörsbehörighet på måldatorn, så om det är du som initierar den anger du administratörsinloggningsuppgifter eller höjer behörigheten via ett verktyg som uppmanar användaren. Slutanvändaren på måldatorn behöver inte administratörsbehörighet när en administratör har förkonfigurerat en distributionsmekanism: Gruppolicy med datortilldelad programvara installerar maskinvisa program i SYSTEM-kontot vid uppstart utan att användaren behöver höja behörigheten. Användarspecifika appar som Google Chrome installeras också i användarprofilen utan administratörsbehörighet.

Ställ in LocalAccountTokenFilterPolicy till 1 på måldatorn, använd sedan PsExec med -h eller PowerShell med datorn tillagd i TrustedHosts. Datorer i en arbetsgrupp har ingen domän som kan utfärda fullständiga token, så både registervärdet och NTLM-autentisering med uttryckliga lokala inloggningsuppgifter krävs.

Det beror på metoden. En RDP-anslutning kopplar bort personen vid konsolen och låser deras session medan deras program fortsätter att köras, medan PsExec, PowerShell-fjärrkörning och en tyst /qn-installation körs i bakgrunden utan att störa dem. Ett fjärrsupportverktyg som delar det aktiva skrivbordet lämnar också användaren kvar, vilket spelar roll när du installerar på någons dator mitt under arbetsdagen.

Kontrollera installatörens avslutningskod, inte bara om kommandot returnerade. En 0 betyder att det lyckades, 3010 och 1641 betyder att det lyckades med en omstart, och 1603 betyder ett fatalt fel. Avslutningskoden är den tillförlitliga signalen, så fånga den med -PassThru i PowerShell. De flesta MSI- och EXE-appar som registrerar en avinstallerare visas också under avinstallationsnycklarna på HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall, dess WOW6432Node-gren för 32-bitarsappar, och HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall för installationer per användare, även om inte varje app skriver en post där. MSIX och andra AppX-paketerade appar visas i stället via Get-AppxPackage, oavsett deras källa. Hoppa över Get-CimInstance Win32_Product, eftersom den bara listar Windows Installer-produkter och dess fråga kan utlösa en långsam MSI-konsistenskontroll.

HelpWire
4.8

Fjärråtkomstprogramvara för smidig IT-support. Gratis plan tillgänglig.

Besök webbplatsen
Fjärråtkomst: Vid behov/obevakad
Stödda system: Windows, macOS, Linux
HelpWire