Başka bir bilgisayara uzaktan yazılım nasıl kurulur

Remotely installing software on another computer

Başka bir bilgisayara yazılımı uzaktan kurmak için, Uzak Masaüstü ile bağlanın ve klavyedeymişsiniz gibi yükleyiciyi çalıştırın ya da PowerShell Invoke-Command veya PsExec ve msiexec /qn ile komut satırından sessiz bir kurulum gönderin. Çoğu kişinin doğru yönetici parolası olsa bile Access is denied hatasına takıldığı yer komut satırıdır; çünkü Windows, ağ üzerinden oturum açıldığında sıradan yerel yönetici hesaplarına filtrelenmiş bir belirteç verir. Uzak Masaüstü ise etkileşimli bir oturum olduğu için bu filtreyi aşar; ayrıca hedefin kendi etki alanından bir etki alanı hesabı her iki durumda da tam bir belirteç alır.

Sıradan bir yerel yönetici hesabı için en hızlı çözüm, hedefte tek bir kayıt defteri değeridir: HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System altında LocalAccountTokenFilterPolicy değerini 1 yapın, ardından yükleyiciyi sessizce çalıştırın ve çıkış kodunu yakalayın. Bu kılavuz; test edilmiş komutlarla her yöntemi, birden çok bilgisayar için bir betiği ve PSEXESVC hatalarından winget 0x8a15000f‘e kadar tüm yaygın hatalar için bir düzeltmeyi kapsar.

Token bulmacasını tamamen atlamak isterseniz, HelpWire uzaktaki bir makineye bağlanan bir uzaktan destek yazılımıdır ve oturum sırasında yönetici ayrıcalıkları talep edebilirsiniz. Yükleyiciyi gerçek bir etkileşimli masaüstünde çalıştırırsınız, bu nedenle yetki yükseltme istemi klavyenin başındaymışsınız gibi davranır.

Yönetici hesabıyla bile uzaktan yazılım kurulumları neden başarısız olur

Neden UAC uzak kısıtlamalarıdır; diğer adıyla belirteç filtreleme. Yöneticiler grubuna ait olan yerel bir hesap ağ üzerinden oturum açtığında, Yerel Güvenlik Yetkilisi ona orta bütünlük düzeyine sahip filtrelenmiş bir belirteç verir; böylece Yöneticiler grubu yalnızca reddet durumuna düşer ve ayrıcalıklı eylemler engellenir. Ağ üzerinden oturum açma, yani WinRM, PsExec, WMI veya bir C$ kopyalama, yerel yöneticiler için filtrelenmiş bir belirteç üretir.

Etkilenip etkilenmeyeceğinizi iki ayrıntı belirler. Hedefin kendi etki alanından olup yerel Yöneticiler grubunda bulunan bir etki alanı hesabı muaftır ve tam bir belirteç alır; bu yüzden etki alanı ortamlarında bu durum nadiren görülür. Yerleşik RID 500 Yönetici de özel bir durumdur ve FilterAdministratorToken etkinleştirilmedikçe filtrelenmez. Diğer herkes, yani sıradan yerel yönetici hesapları ve farklı bir etki alanından gelen hesaplar, hedef bir çalışma grubunda olsun ya da bir etki alanına katılmış olsun, filtrelenmiş belirteç alır. Bu tek olgu, PsExec, net use, bir C$ kopyası üzerinden Access is denied hatasının neden görüldüğünü ve Invoke-Command üzerinden ulaştığınız filtrelenmiş, yönetici olmayan belirteci açıklar.

İkinci kök neden etkileşimsiz oturumdur. Uzak bir komut kimsenin tıklayamayacağı bir yerde çalışır; bu nedenle bir pencere bekleyen bir yükleyici ya bir düğmeyi beklerken takılı kalır ya da doğrudan başarısız olur.

Uzaktan yazılım nasıl kurulur: Yöntem seçeneklerinizin karşılaştırması

Yazılımı uzaktan kurmanın en hızlı yolu, yöntemi ortamınıza uyarlamaktır; çünkü her biri yönetici belirteçlerinde, çalışma gruplarında ve Windows Home’da farklı davranır. Bu tablo, tek bir komut çalıştırmadan önce bu seçimi netleştirir. Grup İlkesi burada dahil edilmiştir çünkü yalnızca etki alanlarında çalışır ve erken aşamada kullanılıp kullanılmayacağına karar vermeye değerdir.

Yöntem Yönetici belirteci davranışı Çalışma grubunda çalışır Windows Home ana bilgisayar Kullanıcıyı kesintiye uğratır İnternet üzerinden
RDP Tam belirteç, etkileşimli Evet Ana bilgisayar yok Evet, bağlantısını keser VPN ile
PowerShell uzaktan yönetimi Yerel yöneticiler için filtrelenmiş İle TrustedHosts Evet Hayır Nadiren
cmd + PsExec Filtrelenmiştir. Şunu kullanın -h. Kayıt Defteri düzeltmesiyle Evet Hayır Hayır
winget Şununla çalışmaz: WinRM Yalnızca yerelde çalışır Evet Hayır Hayır
Grup İlkesi SYSTEM, bilgisayara atanan Hayır, yalnızca etki alanı Yalnızca etki alanı Hayır Hayır
HelpWire Tam, etkileşimli yetki yükseltme Evet Evet Hayır Evet

Aşağıdaki tüm komut satırı yöntemlerini belirleyen tek şey şudur: bağlandığınız hesap. Hedefin kendi etki alanından olup Administrators grubunda bulunan bir etki alanı hesabı, tam bir belirteç alır ve olduğu gibi çalışır. Sıradan bir yerel yönetici hesabı ise filtrelenmiş belirteç alır; bu nedenle C$ kopyaları ve PsExec çağrıları Access is denied döndürür ve PowerShell uzaktan bağlantısı ya oturumu reddeder ya da yönetici hakları olmadan çalıştırır; ta ki hedefte LocalAccountTokenFilterPolicy değerini 1 olarak ayarlayana kadar, bu da düzeltmeler bölümünde ele alınmıştır. RDP istisnadır, çünkü bu bir ağ oturumundan ziyade etkileşimli bir oturum açmadır.

Uzak Masaüstü ile başka bir bilgisayara uzaktan yazılım kurma

Uzak Masaüstü, başka bir bilgisayara uzaktan yazılım kurmanın en temiz yoludur, çünkü UAC istemini onayladıktan sonra tam yönetici belirteciyle çalışan etkileşimli bir oturumdur. Bağlanın, ardından sanki bilgisayarın başındaymışsınız gibi kurun.

  1. Hedef bilgisayarda, Win + R tuşlarına basın, SystemPropertiesRemote yazın ve Bu bilgisayara uzak bağlantılara izin ver seçeneğini etkinleştirin.

  2. Makinenizde Uzak Masaüstü Bağlantısı (mstsc.exe) açın, hedef adını veya IP’yi girin ve orada yerel bir yönetici olan bir hesapla oturum açın.

  3. Yükleyiciyi oturum üzerinden kopyalayın veya ona erişebilmek için Local Resources bölümünde yerel bir sürücüyü eşleyin.

  4. Yükleyiciyi çalıştırın. UAC istemi göründüğünde, RDP penceresinde onaylayın, ardından sihirbazı tamamlayın.

Buna güvenmeden önce sınırlarını bilmekte fayda var. Windows Home sürümleri RDP oturumunu hiç barındıramaz. Yalnızca istemciyi çalıştırırlar. İstemci Windows’ta tek bir konsol esas alınır, bu yüzden bağlanmak makinede oturum açmış kişiyi oturumdan çıkarır. Ve uzak makinede yönetici kimlik bilgileri olmayan standart bir kullanıcı yine de istemi onaylayamaz; bu da sizi aşağıdaki komut satırı yöntemlerine yönlendirir.

PowerShell kullanarak yazılımı uzaktan nasıl kurulur

Uzaktan yazılım kurmak için PowerShell kullanırken Invoke-Command‘a güvenirsiniz, ancak neredeyse herkesi yakalayan iki tuzak vardır. Uzak oturum etkileşimli değildir, bu nedenle yükleyicinin tamamen sessiz çalışması gerekir ve kontrolü hızla geri veren bir yükleyici tamamlanmadan oturum kapanabilir; bu da kurulumu iptal eder. Kevin Marquette’in uzaktan kurulumlar üzerine iyi bilinen bir yazısı bunların her ikisini de açıklar ve ikincisi için çözüm Start-Process -Wait‘tir.

Invoke-Command ile tek bir bilgisayara yükleme

  1. Hedefte, uzaktan yönetimi bir kez etkinleştirin. Yönetici olarak açılmış bir PowerShell penceresinde Enable-PSRemoting -Force komutunu çalıştırın.

  2. Oturumun hiçbir zaman bir ağ yoluna erişmek zorunda kalmaması için yükleyiciyi hedefe kopyalayın:
    Copy-Item -Path "C:\Installers\app.msi" -Destination "\\PC01\c$\Windows\Temp\app.msi"

  3. Sessizce çalıştırın ve bitmesini bekleyin:
    Invoke-Command -ComputerName PC01 -ScriptBlock {

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

    }

    -Wait seçeneğini atlamanız durumunda, yükleyici hâlâ dosyaları kopyalarken betik bloğu sonlanabilir ve oturumu kapatmak kurulumun yazma işlemi sürerken yarıda kesilmesine neden olur. Yükleyici herhangi bir pencere gösterirse takılır, çünkü etkileşimsiz bir oturumda onu tıklayabilecek hiçbir şey yoktur.

Birden çok bilgisayara uzaktan yazılım yüklemek için PowerShell betiği

Bir PowerShell betiği bir bilgisayar listesini dolaşır, yükleyiciyi her makineye kendi oturumu üzerinden kopyalar, çalıştırır ve her makinede neyle sonuçlandığını bilmeniz için çıkış kodunu kaydeder. Bu, oturum içinden bir paylaşıma erişmek yerine önceden kopyalama yaparak double-hop sorununu ele alır.

$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]@{ Bilgisayar = $pc; ÇıkışKodu = $code; Başarılı = $ok }
Remove-PSSession $s
}
catch {
$results += [pscustomobject]@{ Bilgisayar = $pc; ÇıkışKodu = "Uygulanamaz"; Başarılı = $false }
}
}
$results | Export-Csv "C:\Installers\install-report.csv"
-NoTypeInformation

3010 ve 1641‘i başarısızlık değil, başarı olarak değerlendirin. Her ikisi de kurulumun başarılı olduğunu ifade eder: 3010 tamamlamak için yeniden başlatma gerektiği, 1641 ise yükleyicinin yeniden başlatmayı zaten başlattığı anlamına gelir. Birçok ham betik bunları hatalı şekilde başarısızlık olarak işaretler. Copy-Item -ToSession‘ın tek seferde bir oturum yürüttüğünü unutmayın; bu nedenle, Invoke-Command birden çok hedefe yayılabilse de kopyalama adımı makine başınadır.

Çift sıçrama için önerildiğini göreceğiniz CredSSP kestirmesinden kaçının. Topluluk bundan uzaklaştı çünkü uzak ana bilgisayarda yönetici kimlik bilgilerinizi önbelleğe alır ve bir saldırgan bunu ele geçirebilir. Yukarıdaki gibi önceden kopyalama, sorunu bütünüyle atlatır.

Kontrol edilmesi gereken yaygın msiexec çıkış kodları:

Çıkış kodu Anlamı
0 Başarılı
1603 Kurulum sırasında kritik hata
1618 Başka bir kurulum zaten devam ediyor
1619 Yükleyici paketi açılamadı
1638 Ürünün başka bir sürümü zaten yüklü
1641 Başarılı, yeniden başlatma başlatıldı
3010 Başarılı, yeniden başlatma gerekiyor

cmd kullanarak uzaktan yazılım nasıl yüklenir

cmd kullanarak uzaktan yazılım yüklemek için üç yolunuz var: PsExec, winget ve daha eski WMIC komutu; ancak yalnızca ilk ikisi güncel Windows’ta güvenilirdir. Her biri yönetici belirteciyle farklı şekilde etkileşir, bu yüzden bayraklar araçtan daha önemlidir.

PsExec ile msiexec

  1. Microsoft Sysinternals’tan PsExec‘i indirin ve çıkarın. cmd‘yi yönetici olarak açın, çünkü PsExec her çalıştırmada bir hizmet (PSEXESVC) yükler ve bunun için yetki yükseltmesi gerekir.

  2. MSI’yi hedef bilgisayarın yönetici paylaşımına kopyalayın:
    copy "C:\Installers\app.msi" \\PC01\C$\Windows\Temp\

  3. Sessiz kurulumu yükseltilmiş bir belirteçle çalıştırın. Önemli olan -h bayrağıdır. Bu, işlemi hesabın yükseltilmiş belirteciyle çalıştırır:
    psexec \\PC01 -h -accepteula msiexec.exe /i "C:\Windows\Temp\app.msi" /qn /norestart

Eski kılavuzların her yerde kopyaladığı -i bayrağını kullanmayın. Bu, masaüstü etkileşimini zorlar; bu da sessiz kurulumla çakışır ve tam da kaçınmaya çalıştığınız donmalara yol açabilir. -h davranışı ve tam anahtar listesi doğrudan PsExec referansından gelir. Couldn't install PSEXESVC service: Access Denied görürseniz, yaygın neden yönetici olarak çalışmayan yerel bir komut istemidir; ancak hedefte engellenmiş bir ADMIN$ paylaşımı veya filtrelenmiş belirteç de aynı etkiyi yaratır. Bir çalışma grubu makinesinde Couldn't access <PC>: Access is denied görüyorsanız, bu, düzeltmeler bölümünde ele alınan belirteç filtrelemesidir.

komut satırından winget

winget, cmd’den tek bir satırla uygulamaları yerel olarak yükler ve eski araçların modern ikamesidir:

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

Onu uzaktan çalıştırmak asıl sorunlu kısımdır. Bir WinRM oturumu üzerinden, winget sık sık A specified logon session does not exist hatasını verir ya da winget‘in tanınmadığını bildirir; çünkü etkileşimli oturum açma bekleyen paketlenmiş bir uygulama olarak çalışır. Bunu izleyen bir uzun süredir devam eden winget-cli sorunu vardır ve ilgili bir rapor, bir yönetici o makinede yerelde bir kez herhangi bir winget komutunu çalıştırana kadar ilk uzak çağrının 0x8a15000f ile başarısız olduğunu gösterir. Yeni bir makinede, --accept-source-agreements parametresini geçmezseniz, bir girdi istemi hatası olan 0x8a150042 ile de karşılaşırsınız. winget ayrıca resmi olarak SYSTEM hesabını desteklemez ve Windows Server’da yalnızca 2025 ve sonrasında, Server Core hariç, desteklenir; 2019 ve 2022 desteklenmez ve deneyseldir.

Neden WMIC yöntemi artık çalışmıyor

Eski wmic product call install yöntemi Windows 11 24H2 ve sonraki sürümlerde artık çalışmıyor. Microsoft’un WMIC’i kaldırma duyurusuna göre, araç Windows 11 23H2 ve 24H2’de varsayılan olarak devre dışı bırakıldı, 25H2’ye yükseltmede kaldırıldı ve Ağustos 2026 önizleme güncellemesiyle 24H2 ve 25H2’den çıkarıldı; 26H1 ise onsuz sunuluyor ve onu geri yüklemek için bir Feature on Demand bulunmuyor. Bu sürümlerde, wmic.exe çağıran betikler 'wmic' is not recognized döndürür. Microsoft kaldırmayı Windows 11 ile sınırladı, bu nedenle WMIC şimdilik Windows 10 ve Windows Server’da yer almaya devam ediyor, ancak genel öneri PowerShell’in Get-CimInstance ve Invoke-Command komutlarına geçmek yönünde. HelpWire cmd kurulum kılavuzu komut satırı seçeneklerini daha ayrıntılı olarak ele alıyor.

Windows sürümüne göre komut satırı aracı desteği:

Özellik Durum Notlar
WMIC Şu sürümlerde kaldırıldı 24H2, 25H2, 26H1 Ağustos 2026 itibarıyla İsteğe Bağlı Özellik yok
winget Win 10 1809+, Win 11, Server 2025 (Core değil) SYSTEM desteği yok; Server 2019/2022 deneysel
RDP ana bilgisayarı Pro, Enterprise, Education Home sürümleri yalnızca istemciyi çalıştırır
 

Çoğu insanın ilk denediği şey ve neden başarısız olduğu

Yüzeysel çözümler saatlerce vakit kaybettirir; çünkü belirtileri tedavi ederler, uzak taraftaki filtrelenmiş belirteci değil. Yerel cmd‘nizi yönetici olarak çalıştırmak hiçbir şeyi değiştirmez; çünkü filtreleme makinenizde değil, hedefte gerçekleşir. Sıradan bir yönetici hesabıyla runas kullanmak, yönetici grup üyeliğine sahip ancak yükseltilmiş ayrıcalıklara sahip olmayan bir pencere verir; bu yüzden kurulumlar yine başarısız olur.

EnableLUA‘yı 0 olarak ayarlayarak UAC’yi tamamen devre dışı bırakmak kuruluma izin verir, ancak yönetici haklarını kontrolsüz bırakır ve Mağaza uygulamalarını bozar; bu nedenle Microsoft ve topluluk buna karşı uyarır. Bunların hiçbiri asıl nedene dokunmaz; bunu bir sonraki bölüm yapar.

“Erişim engellendi” ve yükseltme hataları için kanıtlanmış düzeltmeler

Önce hata mesajıyla başlayın, ardından çözümüne geçin. Aşağıdakilerin her biri, Microsoft belgeleri, satıcı bilgi tabanları ve topluluk konuları genelinde doğrulanmıştır.

Hata iletisi Tarafından oluşturulan Asıl neden
Erişim reddedildi PsExec, net use, C$ Filtrelenmiş yönetici belirteci
PSEXESVC hizmeti kurulamadı PsExec Yerel komut istemi yükseltilmemiş veya hedef ADMIN$/belirteç engellenmiş
0x80090322 WinRM Çalışma grubu veya SPN sorunu
Erişim reddedildi Invoke-Command bir paylaşıma Çift sıçrama
0x8a15000f winget üzerinden WinRM Kaynak verisi eksik
1603 msiexec Ölümcül kurulum hatası

LocalAccountTokenFilterPolicy ile “Erişim engellendi” hatasını düzeltin

Hedefte tek bir kayıt defteri değeri ayarlayın; bu, yerel yönetici hesaplarına ağ üzerinden tam belirteç verir. Bu, PDQ, Broadcom ve sayısız PsExec başlığı tarafından doğrulanmış düzeltmedir.

  1. Hedefte, Kayıt Defteri Düzenleyicisi‘ni (regedit) açın ve şu konuma gidin:
    HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System

  2. LocalAccountTokenFilterPolicy adlı bir DWORD oluşturun ve değerini 1 olarak ayarlayın. Veya yönetici yetkileriyle açılmış bir komut isteminde şunu çalıştırın:
    reg add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1 /f

  3. Kurulumu yeniden deneyin. Sonrasında geri almak için değeri tekrar 0 olarak ayarlayın; bu, uzak UAC filtrelemesini yeniden etkinleştirir.

Hedefin kendi etki alanındaki bir etki alanı yönetici hesabıyla bağlandığınızda, zaten tam bir belirteç aldığı için bu gereksizdir. Microsoft, döngüsel geri bağlantı saldırılarını engellemek için filtrelemeyi tasarladı, bu nedenle bunu kapatmak saldırı yüzeyini genişletir. Bunu bilinçli olarak ayarlayın ve iş bittiğinde geri alın.

“PSEXESVC hizmeti yüklenemedi” hatasını düzeltin

Bu, neredeyse her zaman yerel bir ayrıcalık yükseltme sorunudur, Microsoft Q&A‘da doğrulanmıştır.

  1. Komut isteminizi kapatın ve cmd veya PowerShell’i yönetici olarak yeniden açın. PsExec her çalıştırmada hizmetini yükler ve bunu standart bir komut isteminden yapamaz.

  2. Hâlâ başarısız oluyorsa, eski bir psexecsvc.exe hedefte takılı kalabilir. Uzak makinede %windir% konumunu kontrol edin ve varsa kalan kopyayı kaldırın, ardından yeniden deneyin.

  3. Hedefteki ADMIN$ paylaşımına erişilebildiğini ve Dosya ve Yazıcı Paylaşımı‘nın (TCP 445 üzerinden SMB) güvenlik duvarından geçmesine izin verildiğini doğrulayın; çünkü PsExec, PSEXESVC hizmetini çalıştırmak için oraya kopyalar.

Çalışma grubu bilgisayarlarında WinRM 0x80090322 hatasını düzeltin

İş grubu PowerShell uzaktan iletişimi başarısız olur çünkü Kerberos yerel bir hesabı kimlik doğrulayamaz, bu yüzden hedefi TrustedHosts içine eklersiniz ve NTLM’yi zorlarsınız. WinRM hata metninin kendisi TrustedHosts yolunu belirtir.

  1. Bilgisayarınızda, yönetici yetkileriyle açılmış PowerShell üzerinden hedefi ekleyin:
    Set-Item WSMan:\localhost\Client\TrustedHosts -Value "PC01" -Concatenate

  2. Negotiate’ın NTLM’e geri dönmesi için açıkça belirtilmiş bir yerel kimlik bilgisiyle bağlanın:
    $cred = Get-Credential

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

  3. Hata bir çalışma grubu yerine bir etki alanı FQDN’sinde devam ediyorsa, bu bir SPN sorunudur. Microsoft KB 4549715 -IncludePortInSPN ve spn_prefix geçici çözümlerini kapsar.

Çift atlama “Access denied”i düzeltin

Uzak oturum bir UNC yoluna ulaştığında, kimlik doğrulaması yapamaz, dosyayı önceden kopyalayamaz veya betik bloğu içinde yeniden kimlik doğrulaması yapamaz.

  1. Tercihen: oturum yalnızca yerel bir yola erişsin diye, çoklu bilgisayar betiğinde olduğu gibi, önce yükleyiciyi hedefe kopyalayın.

  2. Ya da oturum içinde yeni bir kimlik bilgisiyle bir sürücü eşleyin. New-PSDrive çağrısı dosya sunucusuna bağlantı için kimlik doğrulaması yapar ve aşağıdaki ham UNC başlatma bu bağlantıyı yeniden kullanır; böylece komut eşlenen sürücüye hiç atıfta bulunmasa da kimlik bilgisi geçerli olur:
    $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 ve 0x8a150042'yi düzeltin

Her iki hata da winget’in sahip olmadığı etkileşimli bir oturum açma beklentisinden kaynaklanıyor. Geçici çözüm, winget-cli izleyicisi genelinde belgelenmiştir.

  1. Hedefe yönetici olarak bir kez oturum açın ve herhangi bir winget komutu çalıştırın, örneğin winget list. Bu, kaynağı başlatır ve daha sonraki uzak çağrılarda 0x8a15000f‘i temizler.

  2. İlk çalıştırmada 0x8a150042 girdi isteminden kaçınmak için anlaşma bayraklarını her zaman iletin:
    winget install --id Google.Chrome --silent --accept-package-agreements --accept-source-agreements

  3. SYSTEM bağlamında winget’e güvenmeyin. Winget’i sağlayan App Installer paketi kullanıcı başına kaydedilir ve bu kayıt normalde SYSTEM hesabı için mevcut değildir; bu nedenle C:\Program Files\WindowsApps içindeki tam yolu çağırmak bile çoğu zaman yine de kurulumu gerçekleştiremez. SYSTEM bağlamındaki dağıtım için bunun yerine PsExec aracılığıyla msiexec veya bir paket aracı kullanın.

msiexec 1603 hatasını düzeltin

Çıkış kodu 1603 genel bir ölümcül hatadır; bu nedenle çözüm, tahmin etmek yerine her zaman ayrıntılı günlüğü okumaktır. Microsoft’un 1603 ile ilgili sorun giderme aynı yaklaşıma işaret eder.

  1. Hedefte yazılabilir bir yola ayrıntılı günlük kaydıyla yeniden çalıştırın:
    msiexec /i "C:\Windows\Temp\app.msi" /qn /l*v "C:\Windows\Temp\install.log"

  2. Günlüğü açın ve başarısız olan işlemin hemen ardından yer alan return value 3 ifadesini arayın. Yaygın nedenler, yetersiz disk alanı, kullanıcıya özel ile makine genelindeki özellikler arasındaki uyumsuzluk veya kilitli bir dosyadır.

  3. Günlük yeterince açıklayıcı değilse, RDP üzerinden hedefte kurulumu etkileşimli olarak yeniden gerçekleştirin; böylece bir GUI yükleyicisi gerçek hatasını gösterebilir, çünkü SYSTEM bağlamında başlatıldığında, hata iletisini gösterecek bir masaüstü oturumu yoktur.

HelpWire kullanarak yönetici yetkileriyle uzaktan yazılım nasıl yüklenir

HelpWire, cihazınızdaki uygulama (Operator) üzerinden canlı ve etkileşimli bir oturum içinde uzak taraftaki bir makinede bir kurulum çalıştırmanıza olanak tanıyan bir uzaktan erişim yazılımıdır. Bir bağlantı aracılığıyla bağlanır ve uzak tarafta yönetici yetkileri talep edersiniz. Yetkiler verildikten sonra, yükleyicileri doğrudan çalıştırabilmeniz için uzak kullanıcının (Client) uygulaması yeniden başlatılır.

Oturum sırasında yönetici erişimi iste

  1. Bir oturum başlatın ve uzak iş istasyonuna bağlanın. Tam süreci görmek için HelpWire yönetici ayrıcalıkları kılavuzuna bakın.

  2. Operator uygulamasının araç çubuğunda Yönetici erişimi iste‘ye tıklayın.

    Helpwire Operator uygulamasının araç çubuğundaki Yönetici erişimi talep et düğmesine tıklama
  3. Kullanıcı önce Erişim izni ver‘e, ardından cihaz değişikliği isteminde Evet‘e tıklar. İstemci uygulaması yönetici yetkileriyle yeniden başlatılır ve bağlantı yeniden kurulur.

  4. Araç çubuğunda Yönetici erişimi verildi göründüğünde, kurulum programınızı uzak masaüstü üzerinden tam yetkili bir yönetici olarak çalıştırın.

    “Yönetici erişimi verildi” bildirimi HelpWire araç çubuğunda

Kimlik bilgileri sizdeyse, Yönetici erişimi iste yanındaki açılır menüyü kullanıp Kimlik bilgileriyle yönetici seçeneğini seçin, ardından yönetici hesabının kullanıcı adı ve parolasını girin. Uzak kullanıcı da kendi tarafından İstemci uygulamasında Yönetici olarak yeniden başlat ile yetkilerini yükseltebilir.

Yükleyiciyi karşıya taşıyın, ardından daha sonra yeniden bağlanın

RDP kopyala-yapıştır sorunları olmadan bir yükleyiciyi doğrudan oturuma alabilir veya onu Operator penceresine sürükleyebilirsiniz. Bir düzeltmenin takip çalışması gerektiğinde, gözetimsiz erişim uzak kullanıcı olmadan daha sonra aynı açık durumdaki makineye yeniden bağlanmanıza olanak tanır.

Yönetici ayrıcalıklarına yükseltme gerçek bir etkileşimli masaüstünde gerçekleşir, bu nedenle yükleyiciler ve onların UAC istemleri hedefte herhangi bir kayıt defteri düzenlemesi olmadan normal şekilde davranır.

Uzak kullanıcı kontrolü elinde tutar. Her yönetici isteği onların onayını gerektirir ve erişimi istedikleri zaman iptal edebilirler.

SSS

Kimin yetkilerinin eksik olduğuna bağlıdır. Program Files veya HKLM gibi konumlara yazan makine başına bir kurulum, hedefte yönetici yetkileri gerektirir; bu nedenle başlatan kişi sizseniz, yönetici kimlik bilgilerini sağlarsınız ya da kullanıcıdan onay isteyen bir araç aracılığıyla yetki yükseltirsiniz. Bir yönetici bir dağıtım mekanizmasını önceden yapılandırmışsa, hedefteki son kullanıcının yönetici yetkilerine ihtiyacı yoktur: Grup İlkesi ile bilgisayara atanan yazılımlar, başlangıçta kullanıcıdan herhangi bir yetki yükseltmesi olmadan SYSTEM bağlamında makine başına uygulamaları kurar. Google Chrome gibi kullanıcıya özel uygulamalar da yönetici yetkileri olmadan kullanıcı profiline kurulur.

Hedefte LocalAccountTokenFilterPolicy‘yi 1 olarak ayarlayın, ardından PsExec‘i -h ile veya makineyi TrustedHosts‘a ekleyerek PowerShell kullanın. Çalışma grubu makinelerinde tam belirteçleri sağlayacak bir etki alanı yoktur, bu nedenle hem kayıt defteri değeri hem de açıkça belirtilmiş yerel kimlik bilgisiyle NTLM kimlik doğrulaması gereklidir.

Bu, yönteme bağlıdır. Bir RDP bağlantısı, konsoldaki kişinin bağlantısını keser, programları çalışmaya devam ederken oturumunu kilitler; buna karşılık PsExec, PowerShell uzaktan yönetimi ve sessiz bir /qn kurulum, onları rahatsız etmeden arka planda çalışır. Etkin masaüstünü paylaşan bir uzak destek aracı da kullanıcıyı oturumunda bırakır; bu, birinin bilgisayarına iş gününün ortasında kurulum yaparken önemlidir.

Komutun yalnızca bitip bitmediğine bakmayın; yükleyicinin çıkış kodunu kontrol edin. Bir 0 başarı anlamına gelir, 3010 ve 1641 yeniden başlatma ile başarı, 1603 ise ölümcül hata anlamına gelir. Çıkış kodu güvenilir göstergedir; bu nedenle PowerShell‘de -PassThru ile yakalayın. Bir kaldırıcı kaydeden MSI ve EXE uygulamalarının çoğu ayrıca HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall altındaki kaldırma anahtarlarında, 32 bit uygulamalar için bunun WOW6432Node dalında ve kullanıcı başına kurulumlar için HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall altında görünür, ancak her uygulama oraya bir giriş yazmaz. MSIX ve diğer AppX paketli uygulamalar ise, kaynakları ne olursa olsun, bunun yerine Get-AppxPackage aracılığıyla listelenir. Get-CimInstance Win32_Product‘u atlayın; çünkü yalnızca Windows Installer ürünlerini listeler ve sorgusu yavaş bir MSI tutarlılık denetimini tetikleyebilir.