Storage Migration Service Nedir? Windows Server 2025 ile Dosya Sunucusu Taşıma
Storage Migration Service (SMS), eski dosya sunucularını yeni Windows Server sistemlerine veya Azure üzerinde çalışan Windows Server sanal makinelerine taşımak için geliştirilmiş bir Microsoft hizmetidir. Windows Admin Center üzerinden envanter çıkarma, dosyaları ve paylaşım yapılandırmasını kopyalama, ardından isteğe bağlı olarak kaynak sunucunun adını ve IP adresini hedefe devretme (cutover) aşamalarını yönetebiliriz.
2026 güncellemesi: Bu yazının uygulama ekranları Mart 2022 tarihli Windows Server 2008 R2 → Windows Server 2022 laboratuvarından alınmıştır. Aşağıdaki 32 orijinal görüntüyü koruyorum. Windows Admin Center sürümü değiştiğinde ekran yerleşimleri farklı olabilir; buna karşın envanter, aktarım ve cutover aşamalarının mantığı aynıdır. Güncel hedef seçeneğimiz Windows Server 2025’tir.
Önemli: SMS kaynak sunucudaki dosyaları silmez. İlk veri kopyalama işlemi sırasında eski sunucuda çalışma sürdürülebilir; ancak cutover sırasında yeniden başlatmalar, isim/IP geçişleri ve DNS/AD yayılımı nedeniyle kısa bir erişim kesintisi planlanmalıdır. Bu nedenle “sıfır kesinti garantili taşıma” ifadesini doğru bulmuyorum.
Storage Migration Service hangi senaryolarda kullanılır?
- Windows Server 2008 R2, 2012 R2 veya daha yeni dosya sunucularının Windows Server 2022/2025’e taşınması.
- Birden fazla dosya paylaşımının, uygun izin ve yapılandırmalarla yeni bir sunucuda birleştirilmesi.
- Windows Failover Cluster dosya sunucusu kaynaklarının uygun küme hedeflerine taşınması; kümenin kendisi SMS ile taşınmaz.
- Desteklenen Samba tabanlı Linux veya NetApp CIFS kaynaklarından Windows Server’a veri geçişi.
- Eski UNC yollarının korunması için isteğe bağlı sunucu kimliği ve IP adresi devri.

2026 için mimari ve desteklenen sistemler
Temel yapıda üç rolümüz var: kaynak sunucu (eski dosya ve SMB paylaşımları), hedef sunucu (yeni Windows Server) ve orkestratör (Storage Migration Service işini yöneten sunucu). Windows Admin Center yönetim arayüzü aynı sunucuda veya ayrı bir bilgisayarda çalışabilir. Tek sunucu geçişinde, uygun Windows Server 2019 ve üzeri hedef sistem orkestratör olarak da kullanılabilir; birden fazla sunucuda ayrı orkestratör tavsiye ederim.
| Bileşen | Güncel yaklaşım |
|---|---|
| Kaynak | Windows Server 2003’ten Windows Server 2025’e kadar Microsoft’un destek matrisinde yer alan sürümler; senaryoya bağlı küme, Samba ve NetApp CIFS kaynakları |
| Hedef | Tercihen Windows Server 2025 veya 2022; Microsoft ayrıca 2019 ve bazı eski hedefleri de listeliyor |
| Orkestratör | Windows Server 2019 veya sonrası; çoklu taşımalarda ayrı sunucu |
| Yönetim | Güncel Windows Admin Center ve Storage Migration Service uzantısı |
| Azure | Azure üzerindeki Windows Server VM hedef olabilir; Azure Files doğrudan SMS hedefi değildir |
| Azure Local | Doğrudan SMS hedefi olarak desteklenmez; senaryo bazında Windows Server VM veya Azure File Sync değerlendirilir |
Desteklenmeyen ya da özel koşul gerektiren varyasyonlar için geçiş öncesinde Microsoft’un sürüm ve gereksinim matrisini mutlaka kontrol edin. Eski Linux dağıtımlarının bir kaynak listesinde yer alması, o dağıtımların günümüzde güvenlik desteği aldığı anlamına gelmez.
Geçiş öncesinde kritik kontroller
- Kaynak ve hedef için doğrulanmış tam yedek; geri dönüş ve bakım penceresi planı.
- Kaynak paylaşımlar, NTFS izinleri, dosya sahipliği, yerel kullanıcı/grup hesapları ve kota/FSRM yapılandırmaları için envanter.
- Dosyaları kilitleyen uygulamalar, açık dosyalar, özel servis hesapları ve kullanıcı erişim modeli.
- Yeterli disk kapasitesi, NTFS/ReFS uyumluluğu, DNS, Active Directory, sunucu adı ve ağ arabirimi planı.
- Gerekli yönetici yetkileri, WMI/DCOM/SMB erişimi ve güvenlik duvarı kuralları; 445/TCP ve 135/TCP gibi bağlantılar yalnızca güvenilen ağlarda açılmalı.
- Aynı etki alanına kimlik devri yapılacaksa kaynak ile hedefin domain üyeliği; alanlar arası geçişte özel DNS ve kimlik sorunları için ayrı plan.
Microsoft’un cutover belgesinde SMB-In (TCP 445), Netlogon NP-In (TCP 445), WMI DCOM-In (TCP 135) ve WMI-In kuralları açıklanıyor. Hedefe Storage Migration Service Proxy kurulduğunda gerekli güvenlik duvarı kurallarının bir bölümü otomatik yapılandırılabilir; yine de ağ segmentleri ve kurumsal firewall politikaları kontrol edilmeli.
Get-WindowsFeature *Migration*
Get-SmbShare | Select-Object Name,Path,Description
Get-SmbShareAccess -Name "PAYLASIM_ADI"
Get-NetIPConfiguration
Get-Volume | Select-Object DriveLetter,FileSystem,SizeRemaining,Size
Bu komutlar örnek bir salt okunur ön kontrol sağlar; üretimdeki tüm paylaşımları kapsayan bir rapor veya yedekleme yerine geçmez. Bir dosyanın yalnızca NTFS izni değil, SMB paylaşım izni de erişimi etkiler.
Laboratuvar: Windows Server 2008 R2’den Windows Server 2022’ye taşıma
Orijinal laboratuvarımda Windows Server 2008 R2 kaynak dosya sunucusu, Windows Server 2022 hedef dosya sunucusu, Windows Server 2022 domain controller ve Windows Admin Center yönetim sunucusu bulunuyordu. Bu bölüm, 2022’de kaydettiğim gerçek ekran akışını korur. Windows Server 2025 ile de aynı yüksek seviyeli aşamalar takip edilir; ekranlar birebir aynı olmayabilir.
1. Windows Admin Center ve hedef sunucu hazırlığı

Windows Admin Center bağlantısını açıyorum. Yönetim ekranında sunucuların erişilebilirliğini kontrol etmek ilk adım.

Add seçeneğiyle laboratuvardaki hedef ve kaynak sunucuları envantere ekliyorum.

Sunucu türünü ve ekleme yöntemini seçiyorum.

AD üzerinden arama yaparak hedef ve diğer laboratuvar makinelerini tanımladım.

Hedef sunucuda Storage Migration Service Proxy özelliğini yüklüyorum. Özellikle Windows Server 2019 ve sonraki hedeflerde aktarımın daha doğrudan yapılmasına yardımcı olur.

Orkestratöre bağlanıp Windows Admin Center içindeki Storage Migration Service bölümünü açıyorum.

Install ile hizmeti ve gerekli bileşenleri kuruyorum.
2. Taşıma işi oluşturma ve kaynak envanteri

New Job ile bir taşıma işi başlatıyorum.

Taşıma işine sonradan kolay izlenebilecek benzersiz bir ad veriyorum.

Sihirbazın ön koşullarını okuyup doğrulayarak ilerliyorum.

Kaynak sistemde yetkili kimlik bilgilerini giriyorum. Yetki kapsamını kurumsal güvenlik politikasına göre sınırlandırmak önemli.

Laboratuvarda küme seçeneği açık olduğundan ilgili RSAT bileşenlerinin kurulumu isteniyor. Küme kullanmıyorsanız bu gereksinim değişebilir.

Eski dosya sunucusunu seçiyorum.

Envanterden Windows Server 2008 R2 sunucumu buluyorum.

Start scan ile kaynak üzerinde paylaşım ve yapılandırma envanteri başlatılıyor.

Tarama bittiğinde paylaşım, disk, ağ arabirimi ve yapılandırma bilgilerini gözden geçiriyorum.
Kontrol: Envanterde görünmeyen klasör, kullanıcı veya paylaşım varsa veri aktarımına başlamadan nedenini araştırın. SMS; VSS üzerinden alınmış eski “Previous Versions” geçmişini taşımaz, ayrıca işletim sistemi klasörleri gibi belirli özel dizinleri dışlar.
3. Hedef seçimi, veri aktarımı ve hata analizi

Hedef Windows Server için yönetici kimlik bilgilerini giriyorum.

On-prem hedefi veya Azure VM senaryosunu seçebiliriz. Ben Windows Server 2022 hedefimi kullanıyorum. Sonra hedef disk ve kaynak paylaşımları eşleştiriyorum.

Çakışma yönetimi, tekrar deneme ve uygun doğrulama seçeneklerini ayarlıyorum. CRC64 verinin aktarım sırasında doğrulanmasına yardımcı olabilir; yedekleme veya uygulama seviyesinde doğrulamanın yerine geçmez.

Gerekli proxy ve diğer bileşenler kontrol ediliyor.

Veri aktarımından önce sunucuların erişimi ve disk eşleştirmeleri doğrulanıyor.

Uyarı ve hataları bu aşamada gideriyorum. Hata alındığında doğrudan firewall sorunu varsaymak yerine DNS, kimlik bilgileri, servis ve logları birlikte incelemek gerekir.

Start transfer ile ilk tam veri kopyalamasını başlatıyorum. Büyük ortamlarda sonraki geçişlerle yeni veya değişmiş dosyaları tekrar kopyalamak mümkündür.

Tamamlanan klasörler, kopyalama hızı ve başarısız dosyalar izleniyor.

Tamamlanma sonrasında CSV raporlarını ve başarısız dosyaları kontrol ediyorum.

Kilitli veya erişilemeyen dosyaları loglardan ayıklayıp tekrar aktarım öncesinde düzeltiyorum.
Üretim notu: Aktarım sürecinde uygulamaların kilitlediği dosyalar atlanabilir; SMS bunları otomatik yeniden denese de tamamının kopyalandığını varsayamayız. Cutover öncesinde kullanıcı yazma işlemlerini planlı biçimde durdurup son delta aktarımı ve rapor kontrolünü tamamlamak gerekir.
4. Cutover: kaynak sunucunun adını ve IP adresini yeni sunucuya devretme
Cutover zorunlu değildir. Yeni UNC yollarını elle güncelleyecekseniz bu aşamayı kullanmayabilirsiniz. Ancak uygulamalar hâlâ \\ESKISUNUCU\Paylasim yoluna bağlıysa kaynak sunucunun ağ kimliğini hedefe geçirmek ciddi kolaylık sağlar. İşlem esnasında erişim kesintisi yaşanabileceği için bakım penceresi şarttır.

Kaynak ve hedef için gerekli yetkileri doğrulayıp ağ kimliği devri ayarlarını inceliyorum.

Kaynak sunucuya yeni bir ad/IP tanımlayıp eski ad ve IP’nin hedefe aktarılmasını planlıyorum. Bu işlem kaynak dosyaları silmez; kaynak sunucu servis dışı bırakılacak şekilde yeniden adlandırılır.

İlgili kimlik ve zaman aşımı parametrelerini yapılandırıyorum.

DNS, AD, ağ erişimi ve diğer ön koşullar tamamlanmadan devam etmiyorum.

Planlanan bakım penceresinde Start cutover işlemini başlatıyorum. Sunucular yeniden başlatılabilir, isim/IP değişiklikleri ve etki alanı yayılımı tamamlanana kadar erişim kısa süreli kesilebilir.
5. Taşıma sonrasında yapılacak doğrulamalar
- Eski sunucu adına erişimin gerçekten yeni sunucuya gittiğini DNS ve SMB üzerinden doğrulayın.
- Örnek kullanıcılarla SMB paylaşım ve NTFS izinlerini, sahiplikleri ve uygulama erişimlerini test edin.
- Dışarıdan dosyayı kilitleyen uygulamaların düzgün başladığını, batch görevlerinin ve hizmetlerin yeni sunucuda çalıştığını doğrulayın.
- SMB paylaşım adlarını, erişim denetimlerini, kota/FSRM ve antivirus ayarlarını gereksinime göre yeniden kontrol edin.
- Hedef sunucunun bilgisayar sertifikalarını inceleyin; eski hedef adına düzenlenmiş sertifikalar cutover ile otomatik yenilenmez.
- Taşıma CSV sonuçlarında başarısız veya atlanmış dosya bırakmayın; VSS Previous Versions gerektiğinde ayrıca planlayın.
- Güncel yedek alın ve geri dönüş prosedürünü sonlandırmadan önce iş biriminden kabul alın.
Resolve-DnsName ESKISUNUCU
Test-NetConnection ESKISUNUCU -Port 445
Get-SmbShare
Get-SmbShareAccess -Name "PAYLASIM_ADI"
Eski makine cutover sonrasında kapatılıp silinmiş olmaz: Microsoft, içeriğini ve geri dönüş imkânını koruyacak kontrollü bir devreden çıkarma planı öneriyor. Bu işlem tamamlanana kadar eski sunucuyu gelişigüzel temizlemeyin.
Sık yapılan hatalar ve sınırlar
- “Kesintisiz” varsaymak: Cutover aşamasında AD/DNS ve yeniden başlatma süreleri nedeniyle bakım penceresi gerekir.
- “Cutover kaynak dosyaları siler” düşüncesi: Hayır, kaynak veriler yerinde kalır; kaynak sunucunun kimliği değiştirilir.
- Domain controller’ı SMS ile taşımaya çalışmak: SMS domain controller geçiş aracı değildir; DC cutover desteklenmez.
- Azure Files hedeflemek: Doğrudan SMS hedefi olarak desteklenmez. Azure File Sync veya Azure VM senaryosu ayrıdır.
- Kümenin tamamını taşımak: SMS kümenin kendisini değil dosya sunucusu kaynaklarını taşır.
- Previous Versions geçmişini unutmak: VSS eski sürümleri SMS ile taşınmaz.
- Başarılı transfer raporunu yeterli sanmak: Kullanıcı erişimi, uygulama davranışı, ACL ve servisler ayrıca test edilmelidir.
Sonuç
Storage Migration Service, özellikle destek dışına çıkan dosya sunucularının Windows Server 2022 ve 2025’e geçirilmesinde çok değerli bir araç. Benim burada aktardığım 2008 R2 → 2022 laboratuvarı, gerçek bir geçişi adım adım gösteriyor. Üretimde ise başarıyı yalnızca “dosyalar kopyalandı” mesajıyla ölçmemek; izinler, uygulama erişimi, son delta kopyası, cutover ve geri dönüş testleriyle doğrulamak gerekiyor. Umarım faydalı olmuştur. Bir sonraki makalede görüşmek üzere.

