Windows Server Lisans ve Aktivasyon Sorunları Çözümü

Sabah 8’de ofise geldiniz, kahvenizi aldınız ve tam oturduğunuzda telefonunuz çalmaya başladı. “Sunucu kilitli, kimse çalışamıyor!” Ekrana baktığınızda o korkunç mesajı görüyorsunuz: “Windows is not genuine” veya “Your Windows license will expire soon”. İşte bu yazı tam da bu anlar için.

Windows Server lisans ve aktivasyon sorunları, sysadmin’lerin en sık karşılaştığı ama en az belgelenmiş problemlerinden biri. Çözüm bazen tek bir komut, bazen KMS sunucusunu sıfırdan ayarlamak, bazen de Microsoft ile saatlerce uğraşmak anlamına geliyor. Gelin bu konuyu baştan sona, gerçek senaryolarla ele alalım.

Sorunun Kaynağını Anlamak

Windows Server aktivasyon mekanizması temelde üç yöntemle çalışır: MAK (Multiple Activation Key), KMS (Key Management Service) ve ADBA (Active Directory Based Activation). Hangi yöntemle aktive edildiğini bilmeden soruna müdahale etmeye çalışmak, hastayı tanı koymadan ameliyata sokmak gibidir.

Önce mevcut durumu tespit etmek için şu komutla başlayın:

slmgr.vbs /dli

Bu komut size lisans durumunu, aktivasyon yöntemini ve kalan grace period süresini gösterir. Daha ayrıntılı bilgi için:

slmgr.vbs /dlv

/dlv komutu özellikle KMS ortamlarında kritik. Hangi KMS sunucusuna bağlandığı, kaç kez aktivasyon denemesi yapıldığı gibi detayları buradan görebilirsiniz.

Bir de şunu kontrol edin, bazen en basit şeyleri atlıyoruz:

slmgr.vbs /xpr

Bu komut lisansın ne zaman dolacağını gösterir. Eğer “Volume activation expiration” yazıyorsa KMS sorunu, eğer tarih vermiyorsa lisans kalıcı olarak aktive edilmiş demektir.

Senaryo 1: KMS Sunucusuna Ulaşamıyor

Kurumsal ortamların büyük çoğunluğunda Windows Server lisansları KMS üzerinden aktive edilir. KMS’in güzel yanı otomatik yenileme yapması, kötü yanı ise araya bir şeyler girince her şeyin domino taşı gibi devrilmesi.

Bir müşteride yaşadığım gerçek bir örnek: Data center’ı taşıma sırasında KMS sunucusunun IP’si değişti, DNS kaydı güncellenmedi. 180 günlük grace period’un dolmasıyla birlikte ortamdaki 40 küsur sunucu aynı anda “unlicensed” moduna geçti. Sistematik yaklaşmazsanız saatler kaybedebilirsiniz.

Önce DNS’in düzgün çalışıp çalışmadığını kontrol edin:

nslookup _vlmcs._tcp

Bu sorgu KMS SRV kaydını döndürmelidir. Eğer yanıt gelmiyorsa sorun DNS’de. KMS sunucusu adını elle de belirtebilirsiniz:

slmgr.vbs /skms kms-sunucusu.domain.local:1688

Ardından aktivasyonu zorla tetikleyin:

slmgr.vbs /ato

Eğer bağlantı problemi devam ediyorsa, KMS portunu test edin. Windows Server’da telnet çoğu zaman kurulu gelmez ama PowerShell ile aynı işi yapabilirsiniz:

Test-NetConnection -ComputerName kms-sunucusu.domain.local -Port 1688

TcpTestSucceeded: True görüyorsanız bağlantı var ama aktivasyon yine de olmuyorsa sorun başka yerde demektir. Firewall tarafında 1688 portunu kontrol edin. Hem KMS sunucusunda hem de istemcide Windows Firewall’a bakın:

netsh advfirewall firewall show rule name="Key Management Service"

Senaryo 2: KMS Sunucusu Yeterli İstemci Sayısını Karşılamıyor

KMS’in bir sırrı vardır ve çoğu zaman belgelerde gömülü kalır: KMS aktivasyonu için minimum istemci eşiği vardır. Windows Server KMS ile aktive olabilmek için KMS sunucusuna en az 5 server istemci bağlanmış olması gerekir. Windows istemciler için bu sayı 25’tir.

Küçük ortamlarda, test lab’larında veya yeni kurulan sistemlerde “neden aktive olmuyor” diye saatlerce uğraşırsınız, sorun bu threshold’dur.

KMS sunucusu üzerinde mevcut istemci sayısını kontrol etmek için:

slmgr.vbs /dli

Çıktıdaki “Current count” değerine bakın. Eğer bu değer eşiğin altındaysa aktivasyon olmaz. Bu durumda MAK anahtarı kullanmak daha pratik bir çözümdür.

MAK anahtarını uygulamak için:

slmgr.vbs /ipk XXXXX-XXXXX-XXXXX-XXXXX-XXXXX
slmgr.vbs /ato

MAK ile aktivasyonda internet bağlantısı yoksa telefon aktivasyonu da kullanılabilir:

slmgr.vbs /dti

Bu komut size bir Installation ID verir. Microsoft’un aktivasyon hattını arayarak bu ID ile Confirmation ID alırsınız. Sonra:

slmgr.vbs /atp <ConfirmationID>

Senaryo 3: Lisans Anahtarı Karışıklığı

“Sunucuya Server 2019 Standard kurdum ama Datacenter anahtarı aldım” veya tam tersi. Ya da kurulum medyası bir sürüm için ama lisans başka bir sürüme ait. Bu durumlar düşündüğünüzden çok daha sık yaşanıyor, özellikle hızlı kurulum yapılan ortamlarda.

Önce mevcut ürün sürümünü öğrenin:

(Get-WmiObject -Class Win32_OperatingSystem).Caption

Ya da klasik yöntem:

winver

Eğer anahtarın hangi sürüme ait olduğunu bilmiyorsanız, anahtar prefix’i size ipucu verebilir ama en güvenilir yol VLSC (Volume Licensing Service Center) portalına girip anahtarı sorgulamaktır.

Yanlış anahtarla aktivasyon denediğinizde genellikle şu hata kodları karşınıza çıkar:

0xC004F069: Yüklü ürün için geçersiz anahtar
0xC004E003: Aktivasyon sunucusu anahtarı geçersiz saydı
0xC004C003: Talep edilen ürün anahtarı bloke edilmiş

Doğru anahtara sahipseniz ve sürüm de doğruysa şu şekilde temiz bir şekilde uygulayın:

slmgr.vbs /upk
slmgr.vbs /cpky
slmgr.vbs /ipk YENİ-ANAHTAR-BURAYA
slmgr.vbs /ato

/upk mevcut anahtarı kaldırır, /cpky registry’deki anahtar cache’ini temizler. Bu ikisini atlarsanız bazen eski anahtar bilgileri yeni aktivasyona müdahale eder.

Senaryo 4: Sanal Makine Klonlama Sonrası Aktivasyon Sorunları

VMware veya Hyper-V ortamında bir VM’i klonladıktan sonra aktivasyon sorunuyla karşılaşmak çok yaygın. Özellikle template’ten hızlıca VM çıkarırken Sysprep atlandığında bu sorunlar kaçınılmaz oluyor.

Sorunun teknik nedeni: KMS aktivasyonu, makineye özgü bir Client Machine ID (CMID) üretir. Klonlama bu ID’yi kopyalar ve KMS sunucusu aynı CMID’yi farklı makinelerden görünce aktivasyonu reddeder.

CMID’yi kontrol etmek için:

slmgr.vbs /dlv

Çıktıda “Client Machine ID” satırını not alın. Eğer klonlanan birden fazla VM’de aynı değeri görüyorsanız sorun bu.

Çözüm için CMID’yi sıfırlayın:

slmgr.vbs /rearm

Bu komut aktivasyon durumunu sıfırlar ve yeni bir CMID oluşturur. Komut sonrası sistemi yeniden başlatın, ardından aktivasyonu tekrar deneyin.

Not: /rearm komutu sınırlı sayıda kullanılabilir. Varsayılan olarak 3 kez kullanım hakkı var. Kaç kez kullandığınızı görmek için:

slmgr.vbs /dlv

Çıktıdaki “Remaining Windows rearm count” değerine bakın.

Uzun vadeli çözüm için VM template’lerinizde mutlaka Sysprep çalıştırın ve generalize flag’ini kullanın. Bu sorunu kökten çözer.

Senaryo 5: KMS Sunucusu Kendisi Aktive Değil

“KMS sunucusu çalışıyor ama istemciler aktive olmuyor” dediğinizde aklınıza gelmeyebilecek bir ihtimal: KMS sunucusunun kendisi aktive değil olabilir. Özellikle KMS host rolünü yeni bir sunucuya taşıdığınızda bu durum yaşanır.

KMS host’un aktivasyon durumunu kontrol edin:

slmgr.vbs /dli

Eğer KMS host lisansı “Licensed” değilse, önce KMS host anahtarını (CSVLK – CSV License Key) yükleyin. Bu anahtar normal Windows Server anahtarından farklıdır, VLSC’den ayrıca temin edilir.

KMS host aktivasyonunu yeniden tetiklemek için:

slmgr.vbs /ato

KMS hizmetinin çalışıp çalışmadığını da kontrol edin:

Get-Service -Name sppsvc | Select-Object Status, StartType

Servis durmuşsa:

Start-Service -Name sppsvc
Set-Service -Name sppsvc -StartupType Automatic

DNS’e KMS SRV kaydını elle eklemek gerekebilir. Bu özellikle otomatik yayımlama devre dışı bırakılmış ortamlarda gereklidir:

dnscmd /RecordAdd domain.local _vlmcs._tcp SRV 0 0 1688 kms-sunucusu.domain.local

Event Log Okuma Sanatı

Aktivasyon sorunlarını çözerken olay günlüklerini okumak kritik. Çoğu sysadmin /ato komutu hata verince direkt Google’a koşuyor, ama Event Log çok daha fazla bilgi içeriyor.

Aktivasyon ile ilgili olaylar iki yerde toplanır:

Get-WinEvent -LogName "Application" | Where-Object {$_.ProviderName -eq "Microsoft-Windows-Security-SPP"} | Select-Object TimeCreated, Id, Message | Format-List

Alternatif olarak belirli bir zaman aralığında bakmak için:

Get-WinEvent -FilterHashtable @{LogName='Application'; ProviderName='Microsoft-Windows-Security-SPP'; StartTime=(Get-Date).AddDays(-7)} | Select-Object TimeCreated, Id, Message | Format-List

Önemli Event ID’leri:

8193: Aktivasyon başarısız, hata kodu içerir
8194: Aktivasyon başarılı
8198: Lisans doğrulama hatası
8200: Otomatik aktivasyon başlatıldı

Event ID 8193’ü gördüğünüzde mesajın içindeki hex hata kodunu not alın. Bu kod size sorunun tam nedenini söyler.

Yaygın Hata Kodları ve Çözümleri

Hata kodları bazen insanı korkutuyor ama çoğunun çözümü oldukça basit.

0x8007232B – DNS name does not exist

Bu hata KMS SRV kaydı bulunamadığında gelir. DNS’i kontrol edin veya KMS sunucusunu elle belirtin:

slmgr.vbs /skms kms-ip-adresi:1688
slmgr.vbs /ato

0x8007007B – The filename, directory name, or volume label syntax is incorrect

Yine DNS kaynaklı, KMS hostname çözümlenemiyor. Yukarıdaki çözüm burada da geçerli.

0x8004FE21 – This computer is not running genuine Windows

Genellikle sistem dosyası bütünlük sorunu veya aktivasyon bilgilerinin bozulmasından kaynaklanır. Önce sistem dosyalarını kontrol edin:

sfc /scannow

Sonra DISM ile:

DISM /Online /Cleanup-Image /RestoreHealth

0xC004F074 – The Key Management Service is unavailable

KMS sunucusuna bağlantı sağlanamıyor. Ağ, firewall ve DNS sırasıyla kontrol edilmeli.

0xC004F038 – The count reported by your Key Management Service is insufficient

Daha önce bahsettiğimiz threshold sorunu. İstemci sayısı yetersiz.

Toplu Aktivasyon Durumu Kontrolü

50 sunucuyu teker teker kontrol etmek kimsenin işi değil. PowerShell ile bunu otomatize edebilirsiniz. Aşağıdaki script domain’deki sunucuların aktivasyon durumunu toplu olarak çeker:

$Computers = Get-ADComputer -Filter {OperatingSystem -like "*Windows Server*"} | Select-Object -ExpandProperty Name

foreach ($Computer in $Computers) {
    try {
        $LicenseInfo = Get-WmiObject -Class SoftwareLicensingProduct `
            -ComputerName $Computer `
            -Filter "Name like 'Windows%' AND PartialProductKey IS NOT NULL" `
            -ErrorAction Stop

        foreach ($License in $LicenseInfo) {
            $Status = switch ($License.LicenseStatus) {
                0 { "Unlicensed" }
                1 { "Licensed" }
                2 { "OOBGrace" }
                3 { "OOTGrace" }
                4 { "NonGenuineGrace" }
                5 { "Notification" }
                6 { "ExtendedGrace" }
            }

            [PSCustomObject]@{
                ComputerName = $Computer
                LicenseStatus = $Status
                PartialKey = $License.PartialProductKey
                ExpirationDate = $License.GracePeriodRemaining
            }
        }
    }
    catch {
        [PSCustomObject]@{
            ComputerName = $Computer
            LicenseStatus = "Erişilemedi: $($_.Exception.Message)"
            PartialKey = "N/A"
            ExpirationDate = "N/A"
        }
    }
}

Bu script size her sunucunun lisans durumunu, kısmi ürün anahtarını ve eğer grace period’daysa kalan süreyi gösterir. Sonuçları CSV’ye aktarıp raporlama da yapabilirsiniz, Export-Csv ile sonuna ekleyin yeter.

Grace Period’u Uzatmak

Sorunun kaynağını bulmak zaman alıyor ama sistemi ayakta tutmak zorundaysınız. Grace period’u uzatmak geçici ama hayat kurtarıcı bir çözüm.

slmgr.vbs /rearm

Bu komut grace period’u sıfırlar ve size 30 gün daha verir. Daha önce belirttiğim gibi bu komut 3 kez kullanılabilir. Sonrasında yeniden kullanmak için registry hack var ama bunu production’da önermiyorum, asıl sorunu çözmek her zaman daha doğru.

Kaç gün kaldığını sürekli kontrol etmek yerine bir monitoring alarmı kurmak çok daha akıllıca:

$LicenseInfo = Get-WmiObject -Class SoftwareLicensingProduct `
    -Filter "Name like 'Windows%' AND LicenseStatus = 2" 

if ($LicenseInfo) {
    $GraceDays = [math]::Round($LicenseInfo.GracePeriodRemaining / 1440)
    if ($GraceDays -le 14) {
        Send-MailMessage -To "[email protected]" `
            -From "[email protected]" `
            -Subject "UYARI: $env:COMPUTERNAME Lisans $GraceDays gun icinde doluyor" `
            -Body "Sunucunun Windows lisansi $GraceDays gun icinde dolacak. Lutfen aktivasyonu kontrol edin." `
            -SmtpServer "smtp.sirket.com"
    }
}

Bu script’i Task Scheduler’a ekleyip günlük çalıştırın. Sabah kahve içerken değil, 14 gün önceden haberiniz olsun.

Proxy Ortamlarında Aktivasyon

Bazı ortamlarda internetle direkt bağlantı yok, her şey proxy üzerinden gidiyor. Bu durumda aktivasyon sunucularına ulaşmak sorun olabilir.

Önce mevcut proxy ayarlarını kontrol edin:

netsh winhttp show proxy

Eğer proxy tanımlı değilse ve aktivasyon direkt internet üzerinden yapılacaksa:

netsh winhttp set proxy proxy-sunucusu:8080

Sonra aktivasyonu tekrar deneyin. Kurumsal proxy’lerde bazen SSL inspection aktivasyon sertifikalarına müdahale eder. Bu durumda Microsoft aktivasyon domain’lerini (mshoa.microsoft.com, afs.microsoft.com, licensing.mp.microsoft.com) proxy bypass listesine eklemek gerekir.

Sonuç

Windows Server aktivasyon sorunları, panik yaptırdığı kadar da zor değil aslında. Sistematik yaklaşırsanız çoğu sorunu 30 dakika içinde çözebilirsiniz.

En büyük tuzak, aceleyle yanlış yönde koşmak. Önce /dli ve /dlv ile durumu anlayın, sonra senaryo bazlı ilerleyin. KMS mı, MAK mı, DNS mi, firewall mı, istemci sayısı mı, sistemi klonlama mı? Her birinin farklı çözümü var.

Uzun vadede en iyi yatırım bir monitoring sistemi kurmak. Lisans sorunlarını kullanıcılar size bildirmeden önce siz fark etmelisiniz. Yukarıdaki PowerShell script’lerini alın, Task Scheduler veya SCOM’a entegre edin, kendinizi “sabah 8’de iş yerine gelen ve sunucu kilitli bulan” sysadmin olmaktan kurtarın.

Son bir not: VLSC portalına erişim bilgilerinizi ve KMS host anahtarlarınızı güvenli bir yerde saklayın. Bu belgeleri sorun yaşandığında aramak, saçınızı başınızı yoldurmakla eşdeğer. Her lisans anahtarını, hangi sunucuda kullanıldığını ve son aktivasyon tarihini düzenli olarak belgelendirmek sizi gelecekteki kendinizin lanetlemesinden korur.

Windows Server Lisans Hatası ve Aktivasyon Sorunları Nasıl Çözülür