Windows Server ortamlarında Remote Desktop Services (RDS) rolü devreye alındığında Microsoft sistem yöneticilerine başlangıç aşamasında belirli bir esneklik tanımak amacıyla otomatik olarak 120 günlük bir grace period (lisanssız kullanım süresi) sunar.
Bu süre boyunca ortamda henüz bir RDS License Server tanımlanmamış olsa bile uzak masaüstü bağlantıları büyük ölçüde çalışmaya devam eder. Özellikle ilk kurulum, test, PoC veya geçici devreye alma senaryolarında bu yapı oldukça kullanışlıdır.
Ancak bu geçici kolaylık çoğu zaman gözden kaçar. Sistem ilk günlerde sorunsuz çalıştığı için lisanslama altyapısının daha sonra tamamlanacağı düşünülür fakat bu işlem ertelendiğinde 120 günlük sürenin sonunda çok ciddi erişim problemleri yaşanabilir.
Özellikle production ortamlarında bu durum kullanıcıların sisteme bağlanamaması, oturumların kesilmesi ve kritik uygulamalara erişimin durması gibi sonuçlar doğurabilir.
Grace Period Nedir ve Neden Vardır?
RDS rolü kurulduğunda Windows Server lisans sunucusu henüz tanımlı olmasa bile hizmetin tamamen bloke olmasını önlemek için bir geçiş süresi sağlar.
Bu 120 günlük dönem boyunca:
- RDS oturumları açılabilir,
- uzak masaüstü bağlantıları kabul edilir,
- sistem lisans doğrulamasını katı biçimde zorlamaz,
- altyapının lisanslama tarafı sonradan tamamlanabilir.
Bu yaklaşım özellikle kurulum aşamasındaki BT ekiplerine zaman kazandırır. Çünkü birçok kurumda lisans sunucusunun hazırlanması, CAL atamalarının yapılması, lisans modunun belirlenmesi ve Group Policy ayarlarının tamamlanması ayrı bir proje adımı olarak ele alınır.
Ancak burada kritik nokta şudur Grace period bir tolerans mekanizmasıdır lisanssız kalıcı kullanım modeli değildir. Süre dolduğunda sistem artık normal çalışma modundan çıkar ve lisanslama bileşenlerini aktif olarak beklemeye başlar.
120 Günlük Süre Neden Biter?
Aslında bu sürenin bitmesinin temel sebebi oldukça basittir Windows Server RDS hizmetinin lisanssız şekilde süresiz çalışmasına izin vermez. Kurulumdan itibaren sayaç başlar ve sistem bu sürenin sonunda artık aşağıdaki kontrolleri bekler:
- Geçerli bir Remote Desktop License Server tanımlanmış mı?
- Sunucu hangi lisans modunda çalışıyor?
(Per User veya Per Device) - İlgili RDS CAL’leri yüklenmiş mi?
- Oturum ana bilgisayarı (RD Session Host), lisans sunucusuna erişebiliyor mu?
- İlgili GPO veya manuel yapılandırmalar doğru uygulanmış mı?
Bu kontrollerin hiçbiri tamamlanmamışsa grace period sona erdiğinde sistem bağlantıları artık “geçici tolerans” kapsamında değerlendirmez. Sonuç olarak RDS rolü lisans doğrulama zorunluluğuna geçer.
Grace Period Dolduğunda Ne Olur?
120 günlük sürenin sona ermesiyle birlikte RDS altyapısı lisanslama açısından daha katı davranmaya başlar. Bu noktada ortamda lisans sunucusu yoksa tanımlı değilse veya yanlış yapılandırılmışsa aşağıdaki belirtiler ortaya çıkabilir:
Yeni RDP bağlantıları başarısız olur
Kullanıcılar uzak masaüstü bağlantısı kurmaya çalıştığında oturum açamayabilir. Bağlantı isteği ilk aşamada kabul edilse bile, lisans doğrulama aşamasında reddedilebilir.
Mevcut oturumlar kararsız hale gelir
Bazı senaryolarda aktif kullanıcı oturumları düşebilir ya da yeniden bağlantı sırasında sorun yaşanabilir. Bu durum özellikle terminal servisleri üzerinden kritik iş uygulamalarına erişen kullanıcılar için ciddi kesinti anlamına gelir.
RD Session Host erişilemez hale gelebilir
Sunucu teknik olarak ayakta olsa bile hizmet tarafında lisans doğrulama eksikliği nedeniyle RDS erişimi kullanılamaz hale gelir. Bu da sistem yöneticileri açısından “sunucu çalışıyor ama kullanıcı bağlanamıyor” türünden yanıltıcı bir durum yaratır.
Olay günlüklerinde (Event Log) lisanslama hataları görülür
Event Viewer üzerinde TerminalServices ile ilgili hata kayıtları oluşur. Özellikle lisans sunucusuna ulaşılamaması lisans modunun eksik olması veya CAL doğrulama problemleri burada izlenebilir.
Kısacası grace period’un sona ermesi yalnızca “bir uyarı daha çıkması” anlamına gelmez doğrudan servis sürekliliğini etkileyen operasyonel bir soruna dönüşebilir.
Sorunun Temel Kaynakları Nelerdir?
Grace period bittikten sonra yaşanan problemler çoğunlukla aşağıdaki nedenlerden kaynaklanır:
Lisans sunucusunun hiç kurulmaması
En sık karşılaşılan senaryo budur. RDS kurulmuş kullanıcılar haftalar hatta aylar boyunca bağlanmış ancak lisans sunucusu devreye alınmamıştır.
Lisans sunucusunun kurulmuş ama tanımlanmamış olması
Bazı ortamlarda RDS License Server kuruludur fakat RD Session Host tarafında bu sunucu açıkça belirtilmemiştir. Bu durumda servis lisans sunucusunu kullanamaz.
Lisans modunun yanlış seçilmesi
RDS ortamlarında Per User ve Per Device olmak üzere iki temel lisans modu vardır. Altyapıdaki lisans modeli ile sunucu üzerindeki yapılandırma uyuşmazsa doğrulama sorunları oluşabilir.
Ağ veya firewall erişim problemleri
Lisans sunucusu mevcut olsa bile RD Session Host ile lisans sunucusu arasındaki iletişim firewall kuralları, DNS hataları veya ağ segmentasyonu nedeniyle engelleniyor olabilir.
CAL yüklenmemesi veya eksik lisans yapılandırması
Lisans sunucusu ayakta olsa da ilgili CAL’ler yüklenmemişse ya da etkinleştirme tamamlanmamışsa ortam işlevsel görünse bile lisanslama tamamlanmış sayılmaz.
Geçici Çözüm: Grace Period Registry Üzerinden Sıfırlanabilir mi?
Evet, özellikle lab, test, izole demo veya kısa süreli doğrulama ortamlarında grace period bilgisi registry üzerinden sıfırlanabilir. Bunun için kullanılan anahtar genellikle şu konumdadır;
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Terminal Server\RCM\GracePeriod
Buradaki kayıt doğrudan silinmek istendiğinde çoğu zaman erişim engeline takılır. Bunun nedeni, anahtarın varsayılan olarak yüksek koruma seviyesinde tutulmasıdır. Bu nedenle işlem birkaç adımdan oluşur:
- Önce ilgili registry anahtarı için ownership alınır,
- ardından Administrators grubuna tam yetki verilir,
- daha sonra anahtar silinir,
- son olarak sunucu yeniden başlatılır.
Sunucu yeniden açıldığında grace period sayacı yeniden oluşturulabilir ve ortam geçici olarak tekrar bağlantı kabul etmeye başlayabilir.
Ancak burada çok önemli bir çizgiyi net biçimde çekmek gerekir: Bu yöntem kalıcı çözüm değildir. Teknik olarak yalnızca zaman kazandırır. Özellikle üretim sistemlerinde lisanslama yerine registry manipülasyonu ile ilerlemek, hem operasyonel hem de uyumluluk açısından doğru bir yaklaşım değildir.
PowerShell ile bu işlemeleri yapmak için;
# Mevcut Lisansı Kontrol Etmek
Get-RDLicenseConfiguration# Lisans sunucusunu ve lisans modunu PowerShell ile tanımlamak;
Set-RDLicenseConfiguration -LicenseServer "RDS-LIC01.contoso.local" -Mode PerUser
# Cihaz bazlı lisans için;
Set-RDLicenseConfiguration -LicenseServer "RDS-LIC01.contoso.local" -Mode PerDevice
# Tekrar doğrulamak için;
Get-RDLicenseConfiguration
# Lisans rolünün kurulu olup olmadığını kontrol etmek için;
Get-WindowsFeature RDS-Licensing
# Kurulu değil ise;
Install-WindowsFeature RDS-Licensing -IncludeManagementTools
# GPO/registry tarafından lisans ayarı uygulanmış mı kontrol etmek için;
Get-ItemProperty "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services"
Get-ItemPropertyValue -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services" -Name
"LicensingMode"
Get-ChildItem "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\LicenseServers"
#Lisans sunucusunu GPO ile tanımladıysanız;
gpupdate /force
Restart-Service TermService -ForceWrite-Host "=== RDS Licensing Check ===" -ForegroundColor Cyan
Write-Host "`n[1] RDS Licensing feature durumu"
Get-WindowsFeature RDS-Licensing | Select-Object DisplayName, Name, InstallState
Write-Host "`n[2] Deployment lisans ayarı"
try {
Get-RDLicenseConfiguration | Format-List *
}
catch {
Write-Warning "Get-RDLicenseConfiguration çalışmadı. Bu sunucu bir RDS deployment parçası olmayabilir."
}
Write-Host "`n[3] Policy registry kontrolü"
$tsPath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services"
if (Test-Path $tsPath) {
Get-ItemProperty $tsPath | Format-List *
} else {
Write-Warning "Terminal Services policy registry anahtarı bulunamadı."
}
Write-Host "`n[4] LicenseServers alt anahtarı"
$licSrvPath = "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\LicenseServers"
if (Test-Path $licSrvPath) {
Get-ChildItem $licSrvPath | Select-Object PSChildName
} else {
Write-Warning "LicenseServers anahtarı bulunamadı."
}Bu Yöntem Neden Production İçin Uygun Değildir?
Registry üzerinden grace period sıfırlamak kısa vadede erişim sorununu giderebilir; ancak üretim ortamlarında bu yaklaşımın ciddi sakıncaları vardır.
İlk olarak, bu yöntem lisanslama ihtiyacını ortadan kaldırmaz; yalnızca erteler. Yani aynı problem belirli bir süre sonra tekrar karşınıza çıkar.
İkinci olarak, bu müdahale kurumsal standartlara ve lisans yönetimi disiplinine aykırıdır. Özellikle denetlenen ortamlarda, lisanslama altyapısının manuel geçici müdahalelerle yürütülmesi kabul edilebilir değildir.
Üçüncü olarak, operasyonel risk yaratır. Sistem yöneticisi değiştiğinde, dokümantasyon eksik olduğunda veya restart sonrası davranışlar farklılaştığında sorun daha karmaşık hale gelebilir. Yani anlık rahatlama sağlarken uzun vadeli teknik borç oluşturur.
Production Ortamlar İçin Doğru Yaklaşım Nedir?
Üretim ortamında yapılması gereken doğru işlem nettir: RDS lisanslamasının eksiksiz ve desteklenen yöntemlerle tamamlanması gerekir.
1. RDS License Server kurulmalıdır
İlk adım lisanslama rolünün uygun bir Windows Server üzerine kurulmasıdır. Bu sunucu tek başına ayrılabilir ya da tasarıma bağlı olarak mevcut altyapı üzerinde konumlandırılabilir.
2. Lisans sunucusu etkinleştirilmelidir
Role kurulumu yeterli değildir. Lisans sunucusunun Microsoft ile etkinleştirilmesi ve çalışır duruma getirilmesi gerekir.
3. CAL’ler yüklenmelidir
Kurumun lisans modeline göre satın alınmış olan RDS CAL lisansları sunucuya tanımlanmalıdır.
4. Lisans modu doğru seçilmelidir
Altyapı tasarımına göre:
- Per User
- Per Device
modlarından uygun olan belirlenmeli ve RD Session Host tarafında buna uygun yapılandırma yapılmalıdır.
5. RD Session Host, lisans sunucusuna yönlendirilmelidir
Bu işlem GUI, PowerShell veya çoğunlukla tercih edildiği üzere Group Policy üzerinden merkezi biçimde yapılabilir. Özellikle aşağıdaki ayarların net olması gerekir:
- “Set the Remote Desktop licensing mode”
- “Use the specified Remote Desktop license servers”
Bu yapılandırmalar eksikse lisans sunucusu kurulu olsa bile ortam sağlıklı çalışmayabilir.
6. Erişim ve iletişim kontrolleri yapılmalıdır
DNS çözümlemesi, firewall kuralları, servis erişimi ve event log kontrolleri tamamlanmalıdır. Çünkü lisans sunucusunun varlığı kadar RD Session Host’un ona erişebilmesi de kritik önemdedir.
Operasyonel Açıdan Neden Proaktif Takip Şart?
RDS grace period konusu, ilk bakışta küçük bir detay gibi görünür. Çünkü sistem 120 gün boyunca çoğu zaman sorunsuz çalışır ve ekiplerde “şu anlık problem yok” algısı oluşur. Fakat tam da bu nedenle tehlikelidir. Sorun sessiz şekilde yaklaşır ve çoğu zaman ancak kullanıcılar bağlanamadığında fark edilir.
Kurumsal BT operasyonlarında bu tür süreli tolerans mekanizmaları mutlaka proaktif olarak izlenmelidir. Özellikle aşağıdaki kontroller düzenli yapılmalıdır:
- Yeni kurulan RDS sunucularında lisanslama durumu,
- grace period süresinin ne aşamada olduğu,
- lisans sunucusunun tanımlı olup olmadığı,
- CAL yükleme durumu,
- event log’larda lisans uyarıları,
- GPO uygulanma durumu.
Bu kontrollerin yapılmaması, küçük bir kurulum eksikliğinin büyük bir servis kesintisine dönüşmesine neden olabilir.
Script Link : https://github.com/velikadirkozan/RDS-Grace-Period-Reset