Server 2025 DHCP Geçişi: 20138 ve XML Şema Hatası Çözümü
DHCP rolü, kurumsal ağların sessiz ama kritik bileşenlerinden biridir. Çalıştığı sürece fark edilmez; durduğunda ise kullanıcılar IP alamaz, bağlantılar kopar ve yardım masası telefonları susmaz. Bu nedenle eski bir Windows Server ortamından Windows Server 2025’e geçiş planlanırken DHCP taşıma işlemi dikkatle ele alınması gereken bir adımdır.
Microsoft’un sunduğu Export-DhcpServer ve Import-DhcpServer PowerShell cmdlet’leri, scope’ları, rezervasyonları, seçenekleri ve isteğe bağlı olarak lease kayıtlarını tek bir XML dosyası üzerinden taşımaya olanak tanır. Yöntem pratiktir. Ancak yıllardır çalışan sunuculardan alınan export dosyaları, yeni sürümlerin artık desteklemediği eski protokollere ait kalıntılar içerebilir. Bu yazıda bu kalıntıların yol açtığı iki tipik hatayı, nedenlerini ve güvenli bir çözüm yolunu ele alacağız.
Karşılaşılan Hatalar
Eski sunucudan alınan export dosyası Windows Server 2025 üzerinde içe aktarılırken aşağıdaki hatalardan biri veya her ikisi görülebilir:
Network Access Protection is not supported by the server. (20138)XML schema validation failed: The element 'IPv4' has invalid child element 'NpsUnreachableAction'
Her iki mesaj farklı görünse de aynı temel sorundan kaynaklanır: Export dosyasında hedef sunucunun tanımadığı alanların bulunması.
Network Access Protection (NAP)
Network Access Protection (NAP), istemcilerin ağa bağlanmadan önce sağlık durumlarının (güvenlik duvarı, antivirüs, güncelleme seviyesi gibi) denetlenmesini amaçlayan bir teknolojiydi. DHCP tarafında da bu mekanizmayla entegre çalışabiliyordu. NAP, Windows Server 2012 R2 ile kullanımdan kaldırıldı ve Windows Server 2016 ile sonraki sürümlerde yer almıyor.
Burada önemli bir ayrım yapmak gerekir: NPS (Network Policy Server) hizmeti ortadan kalkmadı. NPS, RADIUS işlevleriyle kullanılmaya devam ediyor. Kaldırılan, NAP bileşeni ve ona bağlı sağlık denetimi altyapısıdır.
Hatanın teknik kaynağı ortamınızda NAP’ı hiç kullanmamış olsanız bile, DHCP export dosyası NapEnabled ve NpsUnreachableAction gibi eski alanları barındırabilir. Bu alanlar scope yapılandırmasının bir parçası olarak dosyaya yazılmıştır. Windows Server 2025 üzerindeki DHCP modülü ve hedef XML şeması bu alanları tanımadığında, import işlemi ya 20138 koduyla ya da şema doğrulama hatasıyla sonlanır.
Çözüm Yaklaşımı
Çözümün mantığı basittir: Export dosyasındaki NAP ve NPS ile ilişkili düğümleri kaldırarak hedef şemayla uyumlu, temizlenmiş bir kopya oluşturmak ve İmport işlemini bu kopya üzerinden yapmak.
Bu noktada tek bir kural vardır: Orjinal export dosyasını asla değiştirmeyin. Temizleme işlemi her zaman ayrı bir dosya üzerine kaydedilmelidir; böylece bir sorun çıktığında başlangıç noktasına dönebilirsiniz.
Export Alma
Temizlik işlemine geçmeden önce kaynak sunucudan export dosyasını aldığınızdan emin olun. Lease bilgilerini de taşımayı planlıyorsanız -Leases parametresini kullanın:
Export-DhcpServer -ComputerName "ESKI-DHCP" -File "C:\backup\dhcp_raw.xml" -Leases
NAP/NPS Düğümlerini XML’den Temizleme
Aşağıdaki script, adı Nap veya Nps ile başlayan tüm XML düğümlerini bulur, bağlı oldukları üst düğümden çıkarır ve sonucu yeni bir dosyaya kaydeder:
[xml]$xml = Get-Content "C:\backup\dhcp_raw.xml"
$nodes = $xml.SelectNodes("//*[starts-with(name(),'Nap') or starts-with(name(),'Nps')]")
foreach ($n in $nodes) { [void]$n.ParentNode.RemoveChild($n) }
$xml.Save("C:\backup\dhcp_clean.xml")
Script’in çalışma mantığı şöyledir:
- İlk satır XML dosyasını belleğe, düzenlenebilir bir XML nesnesi olarak yükler.
SelectNodesiçindeki XPath ifadesi, dokümanın herhangi bir seviyesinde adıNapveyaNpsile başlayan tüm öğeleri seçer.foreachdöngüsü her düğümü kendi üst düğümünden kaldırır.[void]ifadesi,RemoveChildçıktısının konsola yazılmasını engeller.- Son satır, temizlenmiş içeriği orijinalin üzerine yazmadan yeni bir dosyaya kaydeder.
Bu adım yeni sunucuda, yönetici yetkisiyle açılmış bir PowerShell penceresinde uygulanır. Import-DhcpServer çalışırken -BackupPath ile belirtilen dizine mevcut yapılandırmanın yedeğini DHCP Server servisi yazar. Servisin bu dizinde yazma yetkisi yoksa işlem erişim reddedildi hatasıyla sonlanabilir. Bu nedenle import öncesinde klasörü oluşturup servis hesabına gerekli izni verin:
New-Item -Path "C:\backup\import_bkp" -ItemType Directory -Force
icacls "C:\backup\import_bkp" /grant "NT SERVICE\DHCPServer:(OI)(CI)F" /T
Temizlenmiş Dosyayı Import Etme
Import-DhcpServer -ComputerName "YENI-DHCP" -File "C:\backup\dhcp_clean.xml" `
-BackupPath "C:\backup\import_bkp\" -Leases -Force
Parametrelerin rolü:
- -ComputerName: İçe aktarmanın yapılacağı hedef sunucu.
- -File: Temizlenmiş XML dosyası.
- -BackupPath: Import öncesinde hedef sunucunun mevcut yapılandırmasının yedekleneceği dizin. Geri dönüş planınız için önemlidir.
- -Leases: Aktif lease kayıtlarının da taşınmasını sağlar.
- -Force: Onay istemeden işlemi gerçekleştirir. Bu nedenle yalnızca test ortamında doğruladığınız bir akışta kullanılmalıdır.
Dikkat Edilmesi Gereken Noktalar
Şema Zorunlulukları
Bu çözüm her ortamda tek seferde sonuç vermeyebilir. Bazı şemalar belirli alanları zorunlu tutabilir; bu durumda NAP/NPS düğümlerini kaldırdıktan sonra farklı bir doğrulama hatasıyla karşılaşabilirsiniz. Böyle bir durumda hata mesajını dikkatle okuyup hangi öğenin eksik veya geçersiz olduğunu belirlemek ve düzeltmeyi bu bilgiye göre yapmak gerekir.
Geniş Kapsamlı Filtre Riski
XPath ifadesi, adı Nap veya Nps ile başlayan her düğümü seçtiği için kapsamı geniştir. Standart bir DHCP export dosyasında bu önekle başlayan ve silinmemesi gereken bir düğüm beklenmez; yine de temizlik sonrası dosyayı orijinaliyle karşılaştırıp hangi düğümlerin kaldırıldığını gözden geçirmek iyi bir pratiktir. Kaldırılan düğümleri önce listelemek isterseniz döngüden önce $nodes | Select-Object Name komutunu çalıştırabilirsiniz.
Test Ortamında Doğrulama
Üretim geçişinden önce import işlemini bir laboratuvar veya test sunucusunda denemek, hem şema uyumluluğunu hem de scope, seçenek ve rezervasyon bilgilerinin doğru taşındığını görmenizi sağlar. Bu adımı atlamak, planlı bakım penceresinde sürpriz hatalarla uğraşmak anlamına gelir.
Import Sonrası Kontrol Listesi
İçe aktarma başarıyla tamamlandığında geçişin bittiğini varsaymayın. Aşağıdaki adımları sırasıyla uygulayın:
- Scope’ları doğrulayın.
Get-DhcpServerv4Scope -ComputerName "YENI-DHCP"çıktısını eski sunucudakiyle karşılaştırın; adres aralıkları, alt ağ maskeleri ve durumlar eşleşmelidir. - Rezervasyonları ve lease sayılarını karşılaştırın. Özellikle sabit IP atanan yazıcı, sunucu ve ağ cihazlarının rezervasyonlarının eksiksiz taşındığından emin olun.
- Yeni sunucuyu Active Directory’de yetkilendirin. Etki alanı ortamında DHCP sunucusu yetkilendirilmeden hizmet vermez:
Add-DhcpServerInDC -DnsName "YENI-DHCP.alanadi.local" - Eski sunucudaki scope’ları devre dışı bırakın. Aynı scope’ların iki sunucuda aynı anda aktif olması IP çakışmalarına yol açabilir. Eski sunucuyu tamamen kaldırmadan önce bir süre devre dışı halde bekletmek, gerekirse hızlı geri dönüş imkânı sağlar.
Sonuç
XML tabanlı export/import yöntemi, DHCP migrasyonunda hâlâ en güvenilir ve izlenebilir yaklaşımlardan biridir. Ancak yıllar içinde biriken eski protokol kalıntıları, yeni sunucu sürümlerinin şemalarıyla çakışabilir. NAP’ın kullanımdan kalkmış olması, bu alanların neden artık kabul edilmediğini açıklar.
Teknik açıdan geçiş akışı şu sırayı izlemelidir: kaynak sunucudan alınan orijinal XML dosyası değiştirilmeden arşivlenir; Nap ve Nps önekli düğümler XPath sorgusuyla ayıklanarak hedef şemayla uyumlu ayrı bir kopya üretilir; bu kopya üretim geçişinden önce test ortamında Import-DhcpServer ile doğrulanır.
Üretimde içe aktarma, -BackupPath ile hedef yapılandırma yedeklenerek gerçekleştirilir. İşlem sonrasında scope, rezervasyon ve lease tutarlılığı kontrol edilir, sunucu Active Directory’de yetkilendirilir ve kaynak sunucudaki scope’lar devre dışı bırakılır. Bu yaklaşım, şema uyumsuzluğundan kaynaklanan import hatalarını ortadan kaldırırken IP çakışması ve veri kaybı riskini de en aza indirir.
Bir sonraki teknik makalede görüşmek üzere..









