PowerShell'de MSI Dönemi Bitiyor: MSIX'e Geçiş Rehberi

⏱️ 7 dk okuma📅 12 Nisan 2026👁️ görüntülenme

Geçen hafta bir müşterimizin sistem yöneticisiyle muhabbet ediyorduk. Adam bana şunu dedi: “Abi biz PowerShell’i hâlâ MSI ile deploy ediyoruz, 200+ sunucuya Group Policy üzerinden dağıtıyoruz, gayet de çalışıyor.” Ben de sordum: “Çalışıyor, haklısın — ama o MSI paketi yakında gelmeyecek, haberin var mı?” Yüzündeki ifadeyi görmeniz lazımdı. Gerçekten.

Evet. Microsoft resmî olarak açıkladı — PowerShell 7.7-preview.1’den itibaren, yanı Nisan 2026 itibarıyla, MSI installer paketi artık sunulmayacak. Yerine MSIX geliyor. Mevcut sürümler için — 7.6 dahil — MSI desteği devam ediyor, ama 7.7 GA ve sonrasında MSI yok — bence çok yerinde bir karar —. Neden önemli bu? Nokta.

Açıkçası, Masaüstünde PowerShell kullanan biri için bu belki büyük bir şey değil. Ama kurumsal ortamlarda, SCCM veya Intune ile binlerce makineye dağıtım yapan ekipler için (evet, doğru duydunuz). işler biraz karışacak. En azından geçiş döneminde.

MSI Neden Gidiyor, Gerçekten Eski mi?

Açık konuşayım. MSI teknolojisi gerçekten yaşlı. Windows Installer 1999’dan beri var. Yirmi beş yılı aşkın bir teknolojiden bahsediyoruz (kendi tecrübem). Çalışıyor mu? Çalışıyor. Peki nasıl çalışıyor — işte mesele tam da orada.

MSI’ın en büyük derdi custom action’lar, yanı kurulum sırasında çalıştırılan özel script’ler ve komutlar. Bunlar bazen sessizce başarısız oluyor, bazen yarım kalıyor, bazen de ortam değişkenlerini allak bullak ediyor. 2022’de Logosoft’ta bir finans kuruluşunun 400+ sunucusuna PowerShell 7.3 dağıtımı yapıyorduk — MSI paketini SCCM ile push ettik, 380 sunucuda sorunsuz kuruldu. Kalan 20’sinde? Custom action’lar patlamış, PATH değişkeni bozulmuş, eski sürüm kaldırılamamış; temizlemek yarım günümüzü aldı. Yarım günü.

Bir de erişilebilirlik meselesi var. Bu kısmı çoğu kişi atlıyor ama Microsoft bunu özellikle vurgulamış — MSI installer’lar ekran okuyucu yazılımlarıyla düzgün çalışmıyor. Tab stop’ları tutarsız, duyurular eksik. Görme engelli bir kullanıcı MSI kurulumunu bağımsız olarak yapamıyor. MSIX bu konuda deklaratif modeli sayesinde çok daha iyi bir noktada.

MSI vs MSIX: Temel Farklar

Özellik	MSI	MSIX
Kurulum modeli	İmperatif (script tabanlı)	Deklaratif (manifest tabanlı)
Güncelleme yöntemi	Komple yeniden kurulum	Diferansiyel (sadece değişen kısım)
Erişilebilirlik	Yetersiz	Modern standartlara uygun
Sandbox/İzolasyon	Yok	Var (konteyner benzeri)
Remoting desteği	Tam	Henüz eksik ⚠️
Task Scheduler entegrasyonu	Tam	Sınırlı ⚠️
Kurumsal dağıtım (GPO/SCCM)	Köklü destek	Gelişmekte

Tabloya bakınca bir şey göze çarpıyor hemen — MSIX modern, temiz, kavramsal olarak güzel. Ama bazı kritik enterprise senaryolarda henüz MSI’ın tam yerini dolduramıyor. Microsoft da bunu kabul ediyor. Yine de geçiş kararını aldılar. Yön belli. Geri dönüş yok.

MSIX’in Eksikleri — Fil Odada Dürüyor

Bak şimdi, Şimdi ben MSIX’i seviyorum, kavram olarak gerçekten mantıklı. Ama sahada işler genelde kavramsal güzelliklere göre yürümüyor. Maalesef.

En büyük sorun şu: MSIX ile kurulan PowerShell, system-level servisler tarafından çalıştırılamıyor (ki bu çoğu kişinin gözünden kaçıyor). Task Scheduler’da SYSTEM hesabıyla bir PowerShell script’i tetikliyorsanız — ki kurumsal ortamların büyük çoğunluğu tam olarak bunu yapıyor — MSIX kurulumunda bu çalışmıyor. Aynı şekilde PowerShell remoting de sorunlu.

Geçen ay bir telekom müşterimizde tam olarak bu durumu test ettik; adamların 150+ scheduled task’ı var, hepsi PowerShell 7 üzerinden koşuyor, MSIX ile kurulum yaptığımızda Task Scheduler “access denied” fırlattı — çünkü MSIX paketi kullanıcı bağlamında çalışıyor, SYSTEM context’inde değil. Geri MSI’a döndük tabi. Şimdilik.

Microsoft bu eksikliklerin farkında ve aktif olarak çalıştıklarını söylüyor. Ama “aktif olarak çalışıyoruz” lafını Microsoft’tan kaç kere duyduk, değil mi? Bakalım ne zaman tamamlanacak.

Açık konuşayım, Bir de şu var — MSIX paketleri Group Policy ile dağıtılamıyor. GPO üzerinden.msi dağıtımı yapan kuruluşlar için bu ciddi bir değişiklik. Intune kullanıyorsanız sorun yok, MSIX doğrudan destekleniyor. Ama hâlâ on-premises AD ve GPO ile yönetilen ortamlar var. Az değil, azımsanmayacak kadar çok var.

Pratik Geçiş Senaryoları

Küçük Ekipler ve Geliştiriciler

Eğer 10-50 kişilik bir ekipseniz ve herkes kendi makinesine kuruyorsa… aslında hiçbir şey değişmiyor. winget ile zaten MSIX paketi kuruluyordu. Hatta farkında bile olmamış olabilirsiniz:

winget install Microsoft.PowerShell
# veya preview için:
winget install Microsoft.PowerShell.Preview

Bu komut zaten MSIX paketini indirip kuruyor. Yanı küçük ekipler için bu geçiş “zaten olmuş” sayılır. Rahat olun.

Enterprise Ortamlar — İşte Asıl Mesele Burada

Size bir şey söyleyeyim, Binlerce makineye dağıtım yapan, SCCM veya Intune kullanan büyük kuruluşlar için durum biraz daha karmaşık. Şöyle bir geçiş planı öneriyorum:

Envanter çıkarın: Hangi makinelerde hangi PowerShell sürümü var? MSI mi, MSIX mi, ZIP mi kurulu? $PSVersionTable ve Get-Package ile tarayın.
Bağımlılıkları tespit edin: Task Scheduler görevleri, remoting yapılandırmaları, system-level servisler — bunların listesini çıkarın.
7.6’da kalın (şimdilik): 7.6 LTS olarak MSI desteği devam edecek. Acele etmeyin.
Pilot grup oluşturun: 50-100 makinede MSIX ile 7.7 preview deneyin, sorunları kaydedin.
Intune geçişini planlayın: Hâlâ GPO ile dağıtım yapıyorsanız, bu belki Intune’a geçiş için de bir fırsat.

💡 Bilgi: PowerShell 7.6 bir LTS (Long Term Support) sürümü olarak MSI ile dağıtılmaya devam edecek. Yanı “yarın MSI’sız kalacağız” paniği yersiz. Ama 7.7 ve sonrası için şimdiden hazırlık yapmakta fayda var.

ZIP ve Alternatif Kurulum Yöntemleri

Ha bu arada — herkes MSI vs MSIX tartışırken unutulan bir şey var. ZIP paketi. PowerShell’i her zaman ZIP olarak indirip istediğiniz yere açabilirsiniz, hiçbir installer gerektirmiyor, PATH’e kendiniz ekliyorsunuz, bitti.

2019’da kendi lab ortamımda bunu çok kullanıyordum — farklı PowerShell sürümlerini yan yana çalıştırmak istediğimde ZIP neredeyse kesinlikle en pratik yöntemdi. Hâlâ da öyle. Enterprise ortamda biraz daha zahmetli tabi, her makineye ZIP açıp PATH ayarlamak ölçeklenmiyor (evet, doğru duydunuz). Ama test ve geliştirme ortamları için fena değil.

Bir de dotnet tool olarak kurulum var: PHP 8.5 Azure App Service’te: Ne Değişti? yazımızda bu konuya da değinmiştik.

dotnet tool install --global PowerShell

Ama bunu production’da kullanan görmedim açıkçası (evet, doğru duydunuz). Geliştirici makinelerinde işe yarar belki.

Microsoft’un Asıl Mesajı Ne?

Küçük bir detay: Dur bir saniye. Şunu düşünmek lazım gerçekten: Microsoft neden tam da şimdi bu kararı aldı? “MSI eski” demek tek başına yeterli bir açıklama değil bence. MSI 25 yıldır zaten eskiydi. Neden şimdi? Copilot CLI Metrikleri Artık Birleşik: Ne Değişti? yazımızda bu konuya da değinmiştik.

Bence birkaç faktör bir araya geldi (buna dikkat edin). Sız ne dersiniz? Birincisi, erişilebilirlik konusu artık yasal bir zorunluluk hâline geliyor — ABD’de ADA kapsamında yazılım erişilebilirliğiyle ilgili davalar artıyor ve Microsoft bu konuda proaktif davranıyor, haklı olarak da.

İkincisi, MSIX ekosistemi artık yeterince olgunlaştı. 2018’de çıktığında kimse ciddiye almıyordu. Şimdi Intune entegrasyonu var, Windows Package Manager yanı winget desteği var, App Installer altyapısı var — artık “deneysel” değil bu işler (ben de ilk duyduğumda şaşırmıştım) Bu konuyla ilgili Copilot’ta Yeni Limitler: Ne Değişti, Ne Beklemeli? yazımıza da göz atmanızı tavsiye ederim.

Üçüncüsü —. Bu benim kişisel teorim — Microsoft, (belki yanılıyorum ama) Windows’un kurulum ve paket yönetimi hikayesini sadeleştirmek istiyor; MSI, MSIX, AppX, ClickOnce, XCOPY derken fazla seçenek var ortada, uzun vadede MSIX’i tek standart yapmak istiyorlar gibi görünüyor ve PowerShell bu yolda önemli bir “flagship” uygulama olarak konumlanıyor. Hmm, aslında düşününce mantıklı. Bu konuyla ilgili GitHub Copilot Pro Denemeleri Neden Durdu? yazımıza da göz atmanızı tavsiye ederim.

Neyse, çok dağıttım — Azure MCP Server 2.0: Kendi Sunucunuzda Ajan Otomasyonu yazımda da benzer bir “eski teknolojiden yenisine geçiş” hikâyesi vardı. Bu tür geçişlerde her zaman bir sancılı dönem oluyor. İlginç, değil mi? Her zaman.

Benim Tavsiyem: Panik Yok Ama Hazırlık Şart

Bence, Lafı gevelemeden söyleyeyim. Eğer bugün MSI ile mutlu mesut PowerShell dağıtıyorsanız, 7.6’da kalın ve rahat olun — LTS desteği var, MSI paketi gelmeye devam edecek. Aceleniz yok.

İtiraf edeyim, Ama şunu da ekleyeyim: 7.7 GA çıktığında, muhtemelen 2026 sonu veya 2027 başı, artık MSI olmayacak (yanlış duymadınız). O zamana kadar MSIX’in enterprise eksikliklerinin giderilmesini umuyorum. Gerçekten umuyorum. Çünkü giderilmezse sahada ciddi sorunlar yaşanacak, bunu şimdiden söyleyeyim.

Bir arkadaşım geçen ay MSIX-only bir PowerShell deployment test etti — üç hafta uğraştı, sonunda Task Scheduler sorununu bir workaround ile çözdü, ama “production’a koymam” dedi. Bu kadar. Kağıt üstünde süper, pratikte biraz daha pişmesi lazım.

Ha, bir de şunu ekleyeyim — bu değişiklik sadece PowerShell’i değil, genel olarak Windows otomasyon stratejinizi etkileyebilir. Task Scheduler yerine Azure Automation veya GitHub Actions gibi alternatiflere bakmak da mantıklı olabilir bu noktada. GitHub Actions’ta 50 Yeniden Çalıştırma Sınırı: Sahada Ne Değişiyor? yazısında Actions’ın sınırlamalarını da ele almıştım, oraya da göz atabilirsiniz.

Sıkça Sorulan Sorular

PowerShell 7.6 için MSI desteği devam edecek mi?

Evet. PowerShell 7.6 bir LTS sürümü ve MSI paketi sunulmaya devam edecek. Microsoft yalnızca 7.7 ve sonraki sürümler için MSI’ı kaldırıyor. Mevcut sürümleriniz etkilenmeyecek.

MSIX paketi ile Task Scheduler’da PowerShell çalıştırabilir mıyım?

Şu an için hayır — MSIX ile kurulan PowerShell, SYSTEM context’inde çalışan Task Scheduler görevlerinde sorun yaşıyor. Microsoft bu eksikliği kabul etti ve düzeltme üzerinde çalıştığını açıkladı. Geçici çözüm olarak ZIP kurulumunu kullanabilirsiniz.

winget ile PowerShell kurduğumda MSI mı yoksa MSIX mi kuruluyor?

Araya gireyim: winget varsayılan olarak MSIX paketini kuruyor. Yanı aslında winget kullanan çoğu kişi zaten MSIX’e geçmiş durumda, farkında olmasa bile. winget install Microsoft.PowerShell komutuyla kontrol edebilirsiniz.

Group Policy (GPO) ile MSIX dağıtımı yapabilir mıyım?

GPO üzerinden doğrudan MSIX dağıtımı desteklenmiyor. Intune veya SCCM kullanmanız gerekiyor. Hâlâ GPO tabanlı bir ortamınız varsa, Intune co-management modeline geçişi değerlendirmenizi öneririm.

Bu değişiklik Linux ve macOS’u da etkiliyor mu?

Şunu fark ettim: Hayır. MSI ve MSIX sadece Windows’a özgü paket formatları. Linux’ta.deb/.rpm, macOS’ta.pkg paketleri aynen devam edecek. Bu değişiklik tamamen Windows tarafını ilgilendiriyor.