Windows Server 2016'da Remote Desktop Service Yapılandırması

Windows Server 2016 üzerinde Remote Desktop Services (RDS), kullanıcıların merkezi bir sunucu üzerinden uygulamalara ve masaüstü ortamlarına uzaktan erişimini sağlayan kapsamlı bir çözümdür. RDS, özellikle dağıtık yapıya sahip büyük ölçekli Network'lerde kullanıcıların farklı cihazlar ve lokasyonlar üzerinden güvenli bir şekilde çalışabilmesi için kritik bir rol oynar. Bu hizmet, işletmelerin BT altyapısının verimliliğini artırırken, kullanıcı deneyimini iyileştirmeyi hedefler.

RDS, birden fazla bileşenin bir arada çalıştığı kompleks bir sistemdir. Bu bileşenler arasında Remote Desktop Session Host (RDSH), Remote Desktop Connection Broker, Remote Desktop Gateway, Remote Desktop Web Access (RD Web Access) ve Remote Desktop Licensing (RD Licensing) gibi çeşitli servisler bulunur. Bu bileşenler, kullanıcılara kesintisiz ve güvenli bir oturum sunmak için entegre çalışır. Her bir bileşen, belirli bir rolü yerine getirir ve sistemin genel performansı ile güvenliğini doğrudan etkiler. Örneğin, Remote Desktop Session Host (RDSH), kullanıcıların sanal masaüstü ve uygulamalara erişimini sağlarken, Connection Broker, oturumların yük dengelemesini ve yeniden bağlanma işlemlerini yönetir.

RDS kurulumu sırasında, sistemin ihtiyaçlarına uygun olarak hangi bileşenlerin seçileceği dikkatle planlanmalıdır. Örneğin, büyük bir organizasyonda, kullanıcı oturumlarını dengelemek ve kaynak kullanımını optimize etmek için birden fazla Remote Desktop Session Host (RDSH) sunucusu kullanılması gerekebilir. Aynı şekilde RD Gateway, dışarıdan gelen bağlantıları güvenli bir şekilde yönlendirmek için yapılandırılmalıdır. Bu, özellikle kurumsal güvenlik politikalarının bir parçası olarak, uzak kullanıcıların veri merkezine şifreli bir bağlantı üzerinden erişim sağlamasını temin eder.

RDS'in tam işlevselliğini sürdürebilmesi için lisanslama işlemleri de kritik bir adımdır. Windows Server 2016 üzerinde RDS lisanslaması, User CAL veya Device CAL olarak iki şekilde yapılabilir. Lisanslama sırasında, kullanıcıların veya cihazların sayısına göre uygun lisanslama modelinin seçilmesi gerekir. User CAL, bir kullanıcının birden fazla cihaz üzerinden erişim sağlamasına izin verirken, Device CAL belirli bir cihaza bağlı olarak erişimi lisanslar. Bu iki modelin doğru bir şekilde uygulanması, maliyetlerin optimize edilmesi ve lisans uyumluluğunun sağlanması açısından büyük önem taşır.

Kurulum ve lisanslama işlemleri tamamlandıktan sonra kullanıcılar, Remote Desktop Connection (RDC) aracılığıyla Remote Desktop Protocol (RDP) üzerinden sunuculara bağlanarak, kendilerine atanan masaüstü ve uygulamalara erişebilirler. Bu süreçte, RD Web Access ile kullanıcıların tarayıcı üzerinden uygulamalara erişmesi de mümkündür. RD Web Access, uygulamaların Web tabanlı bir arayüz üzerinden erişilmesini sağlar ve kullanıcı deneyimini daha da geliştirir.  

Remote Desktop Services (RDS) Bileşenlerine Genel Bakış

Remote Desktop Services (RDS), merkezi uygulama ve masaüstü sunumunu kurumsal Network altyapılarıyla entegre eden sağlam bir yapıdır. Her şey istemcinin masaüstüne oturup dosyalarla çalışmasından ibaret değil; bu yapı, veri işleme, güvenlik, erişim kontrolü ve kaynak yönetimini tek noktadan ele alabilmeyi mümkün kılar. Fiziksel masaüstü bağımlılığını ortadan kaldırarak yönetim süreçlerini sadeleştirir, aynı zamanda farklı lokasyonlarda çalışan kullanıcıların aynı ortamda çalışmasına olanak tanır.

Yönetilebilirlik, bu yapının temel motivasyonlarından biridir. RDS kullanıldığında, masaüstü ve uygulama dağıtımı artık cihaz bazında değil, merkezi sunucular üzerinden gerçekleştirilir. Böylece kullanıcı cihazları ne kadar dağınık ya da heterojen olursa olsun, oturumlar aynı merkezden başlatılır, izlenir ve sonlandırılır. Bu durum, hem güvenlik politikalarının tutarlı şekilde uygulanmasını sağlar hem de yazılım güncellemelerinin kontrolünü kolaylaştırır. Günün sonunda her kullanıcı, oturumu boyunca yalnızca erişimine izin verilen kaynaklarla çalışır; daha fazlasıyla değil.

Bu yapının en dikkat çeken yönlerinden biri de, fiziksel donanım sınırlarını zorlamadan, çok sayıda kullanıcının aynı kaynak havuzunu paylaşabilmesidir. Ancak bu paylaşım, kaynak kaosu yaratmaz. Her oturum izole edilir, bellek ve işlemci gibi kaynaklar dinamik olarak tahsis edilir. Özellikle yüksek kullanıcı yoğunluğuna sahip senaryolarda, RDS ile elde edilen denge ve öngörülebilirlik klasik masaüstü senaryolarında ulaşılması güç bir avantaj sunar.

RDS mimarisi, merkezi yönetimin sadece teknik tarafına değil, operasyonel disipline de katkı sağlar. Kullanıcılar hangi uygulamalara, hangi zaman aralıklarında, hangi cihazlardan erişebilir; bu gibi soruların cevabı artık merkezi sistemler üzerinden net şekilde verilir. Network üzerinden sağlanan bu yapı sayesinde erişim log'ları tutulabilir, kimlik doğrulama süreçleri merkezi hale getirilir ve bağlantı şemaları bütünsel olarak yönetilebilir.

Son olarak, RDS ortamı uygulama dağıtımı açısından da klasik yöntemlerden ayrılır. Kurulum artık kullanıcı cihazlarında değil, merkezi sunucularda gerçekleşir. Uygulama güncellemeleri birden fazla cihaza tek tek uygulanmaz; yalnızca merkezi yapıda güncellenerek tüm oturumlara yansıtılır. Bu da hem zaman kazandırır hem de tutarsız sürüm problemlerini ortadan kaldırır. Kurum içinde verimli, güvenli ve kontrol edilebilir bir masaüstü deneyimi hedefleniyorsa, bu yapının sundukları bir adım geride durmaz.

Remote Desktop Session Host

Remote Desktop Session Host (RDSH), Microsoft'un Remote Desktop Services (RDS) bileşenlerinden biridir ve istemci cihazlarının sunucuya bağlanarak masaüstü ortamlarına ve uygulamalara erişim sağladığı ana platformdur. Remote Desktop Session Host (RDSH), Terminal Services mimarisinin temelini oluşturur ve kullanıcı oturumlarının işlendiği, uygulama işlemlerinin çalıştırıldığı yer olarak görev yapar. Remote Desktop Session Host (RDSH), kullanıcıların oturum açtığı her bir oturumu izole eder, bu da her kullanıcıya bağımsız bir çalışma ortamı sağlar.

Fiziksel sunucuların yanı sıra Hyper-V veya diğer sanallaştırma platformları üzerinde çalışan sanal makineler (VM) üzerinde de Remote Desktop Session Host (RDSH) rolü barındırılabilir. Bu esneklik, yük dengeleme ve kaynak optimizasyonu açısından kritik önem taşır. Remote Desktop Session Host (RDSH), aynı anda yüzlerce kullanıcıya hizmet verebilir ve bu kullanıcıların ihtiyaç duyduğu CPU, RAM ve Disk I/O gibi kaynakları dinamik olarak yönetir. Uygulama performansını optimize etmek ve kullanıcı deneyimini artırmak için Remote Desktop Session Host (RDSH) üzerinde Resource Metering ve Dynamic Fair Share Scheduling (DFSS) gibi gelişmiş yönetim özellikleri kullanılabilir.

Remote Desktop Connection Broker

Remote Desktop Connection Broker, RDS altyapısında kullanıcı oturumlarının yönetimini ve yönlendirilmesini sağlayan merkezi bileşendir. Connection Broker, özellikle yüksek erişilebilirlik (High Availability) ve yük dengeleme (Load Balancing) senaryolarında kritik bir rol oynar. Bu hizmet, kullanıcı oturumlarını izler, bir kullanıcının oturumu Disconnected olduğunda, aynı oturuma geri bağlanmasını sağlar. Bu, kullanıcı deneyimini iyileştirir ve veri kaybını önler.

Ayrıca, Connection Broker, yük dengeleme algoritmaları ile kullanıcı oturumlarını birden fazla RD Session Host sunucusu arasında dağıtır, bu da sunucu kaynaklarının etkin kullanılmasını sağlar. Bu bileşen, Active Directory ile entegre çalışır ve oturumlar arası sürekliliği sağlamak için kullanıcı kimlik doğrulama ve yetkilendirme süreçlerini yönetir. Connection Broker'ın doğru yapılandırılması, çok sunuculu RDS dağıtımlarında performans ve erişilebilirlik açısından hayati önem taşır.

Remote Desktop Web Access

Remote Desktop Web Access (RD Web Access), kullanıcıların RDS ortamındaki uygulamalara ve masaüstü oturumlarına Web tabanlı bir arayüz üzerinden erişim sağlamasına olanak tanır. RD Web Access, Internet Information Services (IIS) üzerinde çalışan bir Web uygulamasıdır ve HTML5 desteği ile kullanıcıların herhangi bir ek yazılım yüklemeden, tarayıcı üzerinden güvenli bir şekilde oturum açmasını sağlar.

RD Web Access, güvenli HTTPS protokolü üzerinden çalışır ve SSL sertifikaları ile veri trafiğini şifreler, bu da kullanıcıların Internet üzerinden güvenli bir şekilde bağlantı kurmasını sağlar. RD Web Access, özellikle dağıtık yapıdaki organizasyonlarda ve mobil çalışanlar için kritik bir bileşendir. Kullanıcılar, RD Web Access Portal üzerinden atanan uygulamalara veya sanal masaüstlerine erişebilir, bu da IT departmanının merkezi yönetim yükünü azaltır. RD Web Access ayrıca RemoteApp uygulamalarının dağıtımını ve yönetimini de kolaylaştırır.

Remote Desktop Licensing

Remote Desktop Licensing (RD Licensing), RDS ortamında kullanıcıların veya cihazların lisanslanmasını sağlayan merkezi bileşendir. RD Licensing, RDS'in yasal ve tam işlevsel olarak çalışabilmesi için gerekli lisans yönetimini gerçekleştirir. Lisanslama, User CAL (User Client Access License) ve Device CAL (Device Client Access License) olmak üzere iki model üzerinden yapılır. User CAL modeli, belirli bir kullanıcının birden fazla cihazdan erişimini lisanslarken, Device CAL modeli, belirli bir cihazın birden fazla kullanıcı tarafından erişimini lisanslar.

RD Licensing sunucusu, Active Directory ile entegre çalışarak, kullanıcıların veya cihazların lisans durumunu izler ve yönetir. Lisans sunucusu, lisansların dağıtımını otomatik olarak gerçekleştirir ve lisansların uygunluğunu denetler. RD Licensing'in doğru yapılandırılması, lisans uyumluluğunu sağlamak ve lisans maliyetlerini optimize etmek açısından kritik öneme sahiptir. Ayrıca, lisans sunucusu yedekliliği ve yük devri (failover) senaryoları için RD Licensing sunucularının High Availability (HA) yapılandırmaları da desteklenir.

Remote Desktop Virtualization Host

Remote Desktop Virtualization Host (RDVH), kullanıcıların Virtual Desktop Infrastructure (VDI) üzerinden sanal masaüstlerine erişimini sağlayan bir RDS bileşenidir. RDVH, Hyper-V sanallaştırma platformu ile entegre çalışarak, kullanıcı oturumlarının izole edilmiş sanal makineler üzerinde çalıştırılmasını sağlar. Bu mimari, özellikle yüksek güvenlik gereksinimleri olan ortamlarda ve veri merkezli iş yüklerinde kullanılır. RDVH, her bir kullanıcıya özel bir sanal masaüstü sunar, bu da kişisel verilerin merkezi olarak yönetilmesini ve güvenliğini sağlar.

Sanal makineler üzerinde çalışan bu masaüstleri, merkezi olarak yönetilir ve güncellenir, bu da yönetim kolaylığı ve güvenlik açısından büyük avantajlar sunar. RDVH, ayrıca, sanal masaüstlerinin dağıtımını ve yönetimini optimize eden özellikler sunar, örneğin sanal masaüstü havuzları ve kişisel sanal masaüstleri arasında seçim yapılabilir. RDVH, yüksek yoğunluklu kullanıcı ortamları için optimize edilmiştir ve donanım kaynaklarını verimli bir şekilde kullanarak, sanal masaüstü performansını en üst düzeye çıkarır.

Remote Desktop Service (RDS) Kurulumu

1- Remote Desktop Session Host sunucu hizmetini barındıracağım Server üzerinde Server Manager > Manage > Add Roles and Features seçeneğine tıklıyorum.



2- Select Installation type adımında Remote Desktop Services Installation seçeneğini seçip, Next butonuna basarak devam ediyorum.



3- Select deployment type adımında karşımıza üç seçenek çıkıyor. 

1. Standard Deployment

Bu seçenek, RDS bileşenlerini birden fazla sunucuya yayarak dağıtmak isteyen ortamlar için kullanılır. Yani Remote Desktop Session Host, Connection Broker ve Web Access gibi roller farklı fiziksel ya da sanal sunucular üzerinde ayrı ayrı kurulabilir. Büyük ve ölçeklenebilir kurumsal yapılarda tercih edilir. Bu modelde yük dengeleme (Load Balancing), yüksek erişilebilirlik (High Availability) gibi gelişmiş senaryolar uygulanabilir. Kurulum adımları daha detaylı ve esnektir ama yönetimi de biraz daha karmaşıktır.

2. Quick Start

Tek sunuculu, küçük ya da test amaçlı kurulumlarda kullanılan seçenektir. RDS rollerinin tamamını tek bir sunucu üzerine otomatik olarak kurar. Ayrıca bir RemoteApp Collection da oluşturur, yani uygulama yayınlama süreci de otomatik hale getirilmiş olur. Bu seçenek, özellikle demo ortamları veya Proof of Concept (PoC) senaryoları için idealdir. Ancak büyük ölçekli yapılarda önerilmez çünkü ölçeklenebilirlik ve ayrıştırma imkanı sınırlıdır.

3. MultiPoint Services

Bu model, tek bir bilgisayar ya da sunucuya birden fazla klavye, mouse ve monitör bağlayarak, her kullanıcıya ayrı bir oturum sunulmasını sağlar. Genellikle eğitim kurumları, sınıflar ya da kütüphane ortamları gibi düşük maliyetli çoklu oturum gerektiren senaryolarda tercih edilir. Kullanıcılar fiziksel olarak aynı cihazı paylaşır, ama yazılımsal olarak her biri ayrı bir oturumla çalışır. Zero Client ya da USB Hub üzerinden terminal bağlantılarla çalışabilir.

Tek bir sunucu üzerinde tüm Remote Desktop Services (RDS) bileşenlerini kuracağım ve tüm RDS bileşenlerinin aynı sunucu üzerinde çalışacağı bir yapı hedeflendiği için, Quick Start seçeneğini tercih ediyorum. Bu seçenek, RDS rollerini otomatik olarak tek sunucu üzerine dağıtarak hızlı bir başlangıç yapılmasını sağlar. Ardından Next butonuna basarak yapılandırma adımlarına geçiyorum.



4- Select deployment scenario adımında, Remote Desktop Services rolünün hangi amaçla kullanılacağını belirlememiz gerekir.

Eğer bir Virtual Desktop Infrastructure (VDI) mimarisi kurulacaksa, bu durumda Virtual machine-based desktop deployment seçilmelidir. Bu seçenek, sanal makineler üzerinde oturum açılmasını sağlar ve Hyper-V entegrasyonu gerektirir.

Eğer kullanıcılar, doğrudan RDS sunucusu üzerinde oturum açacaksa, yani Session-based oturum modeli kullanılacaksa, bu durumda Session-based desktop deployment seçeneği tercih edilmelidir. Bu model, aynı sunucu üzerindeki kullanıcı oturumlarının izole şekilde yönetildiği klasik RDS yapısını ifade eder.

Daha net bir ifadeyle, Session-based oturum modeli dediğimizde, her bir kullanıcının fiziksel ya da sanal ayrı bir makineye değil, aynı Remote Desktop Session Host (RDSH) sunucusu üzerinde başlatılan kendi izole oturumuna bağlandığı bir yapıyı kastediyoruz.

Ben bu senaryoda, Session-based desktop deployment seçeneğini seçerek oturum tabanlı bir yapı kuracağım. Devam etmek için Next butonuna basıyorum. 

5- Select a Server adımında RDS servisinin kurulacağı Server'ımızı seçiyorum.



6- Yaptımız seçimlerle birlikte RDS servisinin ihtiyacı olan Connection Broker, Web Access ve Session Host rol bileşenleri aynı Server üzerine kurulacaktır. Kurulumun yapılması için Restart the Destination Server automatically if required seçeneğini seçip, Deploy butonuna basıyorum.





7- Remote Desktop Service Kurulum işlemi başladı.



8- Remote Desktop Service Kurulum işlemi başarılı bir şekilde tamamlandı.

RD Licensing Kurulumu ve Lisans Server Aktivasyonu

1- RD Licensing Rol Bileşeni Kurulumu

Remote Desktop Services kurulumu kapsamında Connection Broker, Web Access ve Session Host rol bileşenlerinin yapılandırılması tamamlandıktan sonra, sıradaki adım lisans sunucusunun kurulmasıdır. Bu amaçla, RD Licensing rol bileşeni eklenir ve yapılandırılır.

Varsayılan olarak, Remote Desktop Services kurulumu tamamlandığında lisans gerektirmeyen 2 kullanıcı erişim hakkı tanınır. Ancak bu geçici hak dışında, RDS ortamında oturum açacak kullanıcılar için RDS CAL (Client Access License) gereklidir. Microsoft, RDS kurulumundan sonra bu lisansların tanımlanması için 120 günlük bir değerlendirme süresi tanır. Bu sürenin sonunda herhangi bir lisansı yüklenmemişse, RDS ortamı hiçbir kullanıcı oturumuna izin vermez.

Bu nedenle, üretim ortamlarında 120 günlük değerlendirme süresi sona ermeden önce RDS CAL Lisansı satın alarak lisans sunucusuna yüklemek ve etkinleştirme işlemini tamamlamak gerekir.

9- Server Manager'ı açıyor, Remote Desktop Services > Overview altında RD Licensing rol Bileşenininin yüklenebilmesi için yeşil artı (+) butonuna tıklıyorum.



10- Select a Server adımında RD Licensing rol bileşeninin yükleneceği Server'ımı Selected altına taşıyorum.



11- Confirm selections adımında Add butonuna tıklayarak RD Licensing rol bileşenini ekliyorum.



12- Add butonuna tıkladıktan sonra RD Licensing rol bileşeni yükleme işlemi başladı.



13- Yükleme işlemi tamamlandı.

2- License Server Aktivasyonu

14- Lisanlama işlemi için Administrative Tools altındaki Remote Desktop Services dizinindeki Remote Desktop Licensing Manager'a tıklıyorum.



15- RD Licensing Manager üzerinde Server Host Name'imiz üzerinde sağ tıklayarak Active Server seçeneğini seçiyorum. Lisanslama işleminden önce yapılması gereken ilk işlem, Server'ı aktif duruma getirmektir.



16- Activate Server Wizard, RD Licensing sunucusunun aktivasyon sürecinin ilk adımını oluşturur. Bu adımda, Connection Method ekranında lisans sunucusunun Microsoft Clearinghouse ile nasıl iletişim kuracağını belirlememiz gerekir.

Ben bu aşamada, bağlantı yöntemi olarak Automatic connection (recommended) seçeneğini işaretliyorum. Bu seçenek, lisans sunucusunun doğrudan Internet üzerinden Microsoft ile güvenli bir bağlantı kurarak otomatik olarak etkinleştirilmesini sağlar. Genellikle ilk kurulumda bir kereye mahsus yapılır ve işlem tamamlandığında lisans sunucusu aktive edilmiş olur.

Connection Method ekranında sunulan seçenekler şunlardır:

✅ Automatic connection (recommended)

Sunucunun Internet üzerinden Microsoft Clearinghouse ile doğrudan iletişim kurmasını sağlar. Secure Sockets Layer (SSL) kullanılarak güvenli bir bağlantı oluşturulur. En hızlı ve önerilen yöntemdir. Internet bağlantısı olan ortamlarda tercih edilmelidir.

✅ Web Browser

Bu seçenek, Internet bağlantısı olmayan sunucularda kullanılır. Sistem, lisans bilgilerinin manuel olarak kopyalanıp bir tarayıcı aracılığıyla Microsoft’un Web portalına gönderilmesini gerektirir. Daha sonra elde edilen aktivasyon yanıtı, sisteme elle girilir.

✅ Telephone

Internet'e erişimin mümkün olmadığı durumlar için bir diğer alternatiftir. Aktivasyon süreci, Microsoft Volume Licensing Service Center (VLSC) Support, yani Microsoft destek hattı üzerinden gerçekleştirilir. Sistem tarafından sağlanan kimlik bilgileri, telefonla destek ekibine iletilir ve aktivasyon kodları manuel olarak girilir.

Bu seçenekler arasından Automatic connection, Network ortamında Internet erişimi olduğu sürece her zaman tercih edilmelidir çünkü diğer yöntemlere kıyasla hem daha hızlı hem de hata riski daha düşüktür. Aktivasyon tamamlandıktan sonra RD Licensing sunucusu lisans yüklemeye hazır hale gelir.



17- Seçeneği seçip, Next butonuna bastığınızda Microsoft ile iletişime geçme işlemi başlayacaktır.



18- Company Information adımında isim, soyisim, şirket adı ve ülke/bölge ayarları girilmelidir. Gerekli bilgiler girildikten sonra Next butonuna basarak devam ediyorum.



19- Company Information ikinci adımında diğer gerekli bilgiler girip, Next butonuna basarak devam ediyorum.



20- Activate Server Wizard ile aktivasyon işleminin ilk ayağını tamamlamak için lisanlama işlemine hemen geçmek için dilerseniz Start Install Licenses Wizard now seçeneğini işaretleyip, Next butonuna basarak devam ededilir.



20.1- Dilerseniz de bu seçeneği seçmeyip, Finish butonuna basarak Wizard'ı sonlandırabilirsiniz.



💡 Start Install Licenses Wizard now seçeneği işaretlenirse ve Next butonuna basılırsa:

✔ Lisans sunucusunun aktivasyonu tamamlanır.

✔ Hemen ardından Install Licenses Wizard otomatik olarak açılır.

✔ Bu Wizard üzerinden satın almış olduğun RDS CAL lisanslarını girerek lisans yükleme işlemini başlatabilirsin.

✔ Genellikle kurulum sürecinde kesintisiz devam etmek isteyenler bu yolu tercih eder.

💡 Start Install Licenses Wizard now seçeneği işaretlenmezse ve Finish butonuna basılırsa:

✔ Lisans sunucusu yine başarıyla aktive edilir.

✔ Ancak lisans yükleme adımı atlanır, yani sonradan Install Licenses Wizard üzerinden RDS CAL lisanslarını yüklemek için manuel olarak işlem yapman gerekir.

✔ Bu durum genellikle lisans bilgileri henüz hazır olmayan ya da lisans dosyaları sonradan temin edilecek senaryolarda tercih edilir.

Bu fark yalnızca zamanlama ile ilgilidir; teknik sonuçta her iki durumda da lisans yüklenebilir, ancak biri kurulum sırasında devam eder, diğeri ise sonraya bırakılır.

21- Aktivasyon işleminin ilk kısmı tamamlandı.



21- Aktivasyon işleminin ikinci adımında, lisans sunucusunun doğru şekilde çalışabilmesi için hem Lisans Server'ın hem de NETWORK SERVICE hesabının, Active Directory Users and Computers konsolu altında Builtin konteynerinde yer alan Terminal Server License Servers grubuna üye yapılması gerekir.

Bu kontrolü gerçekleştirmek için, RD Licensing Manager üzerinde sunucunun listede görünen Host Name'ine sağ tıklayıp Review Configuration... seçeneğini seçiyorum. Bu Wizard, gerekli izinlerin tanımlanıp tanımlanmadığını kontrol eder ve eksik olan yapılandırmaları düzeltme konusunda yönlendirme sağlar.

Bunun için RD Licensing Manager üzerinde Server Host Name'imiz üzerinde sağ tıklayarak Review Configuration... seçeneğine tıklıyorum.



21.1- Açılan pencerede ilk seçenekte Lisans Server'ımızı ve NETWORK SERVICE hesabını Active Directory User and Computers'ta Builtin Container'ındaki Terminal Server License Servers Group üyesi olarak eklemek için Add to Group butonuna tıklıyorum.

RD Licensing sunucusunun tam olarak işlevsel hale gelebilmesi için, hem lisans sunucusunun kendisinin hem de sistem hesabı olan NETWORK SERVICE'in, Active Directory üzerindeki Terminal Server License Servers grubuna üye olması gerekir. Bu grup, Builtin konteyneri altında yer alır ve sadece Per User CAL dağıtımı ve takibi için zorunludur.

Bu kontrolü gerçekleştirdiğimizde, karşımıza gelen ekranda yer alan sarı uyarı kutusu şunu belirtir:

This license server or the Network Service account is not a member of the Terminal Server License Servers group in Active Directory Domain Services.

Bu, lisans sunucusunun veya NETWORK SERVICE hesabının henüz Terminal Server License Servers grubuna üye olmadığını ifade eder.

Eğer bu işlem yapılmazsa:

❌ Domain kullanıcılarına RDS Per User CAL atanamaz.
❌ Kullanıcı lisanslarının kullanımı izlenemez veya raporlanamaz.

Bu nedenle, hemen sağ tarafta bulunan Add to Group butonuna tıklayarak lisans sunucusunu ilgili gruba otomatik olarak ekliyorum. Bu işlem, hem grup üyeliğini oluşturur hem de gerekli Active Directory izinlerini tanımlar.

21.2- Ekleme işleminin yapılabilmesi için Domain Administrator yetkisine sahip bir kullanıcı olmamız gerektiği konusunda bir uyarı mesajı ile karşılaşıyorum. Continue butonuna basarak devam ediyorum.



21.3- Lisans Server'ımızın ve NETWORK SERVICE hesabının Active Directory User and Computers'ta Builtin Container'ındaki Terminal Server License Servers Group üyesi olarak ekleme işlemi başarılı bir şekilde gerçekleşti. OK butonuna basıyorum.



21.4- OK butonuna basarak Configuration pencresini kapatıyorum.

22- Remote Desktop Licensing servisi Restart edilmesinden sonra, Lisans Server'ımız aktif duruma geldi.



23- Bu adımdan sonra, Remote Desktop Services için Microsoft tarafından tanımlanan 120 günlük değerlendirme süresi başlar. Bu süre boyunca, lisans sunucusu yapılandırılmış olmasına rağmen, henüz RDS CAL lisansı yüklenmediği için sistem, kullanıcı veya cihaz başına herhangi bir lisans kontrolü uygulamaz.

Yani bu 120 gün içerisinde, Remote Connection üzerinden oturum açabilecek kullanıcı sayısında herhangi bir kısıtlama uygulanmaz. Lisans uyarıları gösterilse bile bağlantılar reddedilmez ve kullanıcı erişimi sağlanmaya devam eder. Ancak bu yalnızca geçici bir tolerans sürecidir.

120 günlük süre sona erdiğinde, ortamınızda kaç kullanıcı veya cihaz RDS oturumu açacaksa, bu sayı kadar RDS CAL lisansı satın almanız ve lisans sunucusuna yüklemeniz gerekir. Aksi durumda, oturum açma talepleri reddedilir ve hiçbir kullanıcı sisteme uzaktan erişim sağlayamaz.

Görüldüğü gibi, RD Licensing Manager üzerinde lisans durumu şu anda aşağıdaki gibidir:

👉 Total Licenses: Unlimited
👉 Available: Unlimited
👉 Issued: 0

Bu değerler, henüz gerçek bir RDS CAL lisansı yüklenmediğini ve sistemin halen RD Licensing Grace Period içerisinde çalıştığını gösterir. Lisanslar tanımlanmadığı sürece bu ekran aynı kalır ve bu yapı üretim ortamları için uygun değildir.

3- Remote Desktop Lisanslama

22- Aktivasyon işlemini tamamladıktan sonra, Remote Desktop lisans yükleme işlemine geçmek için RD Licensing Manager üzerinde Server Host Name'imiz üzerinde sağ tıklayarak Install Licenses seçeneğine tıklıyorum.



23- Kaşımıza Install Licenses Wizard penceresi çıkıyor. Next butonuna basarak devam ediyorum.



23- Install Licenses Wizard ekranındaki License Program adımı, lisansın hangi satın alma modeli üzerinden temin edildiğini belirtmemiz gereken bölümdür. 

Open License, Microsoft’un küçük ve orta ölçekli kuruluşlara yönelik sunduğu hacimli lisanslama modelidir. Bu lisanslama türü, genellikle 5 veya daha fazla lisans satın alımında geçerli olur ve satın alma sonrasında bir Authorization Number ve buna bağlı olarak bir License Number ile lisansların yüklenmesini sağlar.

Open License modelinin teknik avantajları şunlardır:

✅ Lisansların merkezi olarak izlenebilmesini sağlar.

✅ RDS CAL gibi istemci lisanslarının Microsoft Volume Licensing portalı üzerinden kolayca temin edilmesine olanak tanır.

✅ Fiziksel medyaya gerek kalmadan, yalnızca yetkilendirme numaralarıyla lisans yükleme imkanı sunar.

✅ Satın alınan lisanslar Microsoft’un Volume Licensing Service Center (VLSC) platformu üzerinden yönetilir.

Bu kurulumda Open License seçeneğini tercih etmemin nedeni, lisansların Microsoft tarafından toplu şekilde bu modelle sunulmuş olmasıdır. Eğer satın aldığın RDS CAL lisansları bir Microsoft yetkili satıcısı üzerinden Volume Licensing kapsamında temin edildiyse, doğru seçim bu olacaktır.

Enterprise Agreement, Select Plus, License Pack gibi diğer seçenekler, yalnızca lisanslama modelin bu seçeneklerden biriyle uyumluysa kullanılmalıdır. Aksi durumda lisans yükleme işlemi başarısız olur.

Bu nedenle ortamda hangi lisans modeli kullanılıyorsa, bu adımda mutlaka ona uygun seçimin yapılması gerekir. Bizim senaryomuzda bu model Open License olduğundan doğru eşleşme sağlanmış olur.

Bu ekranda genellikle en çok tercih edilen modellerden biri olan Open License seçeneğini işaretliyor ve ardından Next butonuna basarak devam ediyorum.





24- Devam eden adımda, License Program bölümünde seçili olan Open License modeline ait lisans bilgilerini giriyorum. Bu lisanslama türünde Microsoft, satın alma sonrasında Authorization Number ve License Number olmak üzere iki ayrı bilgi sağlar.

Bu ekranda, ilgili alanlara sahip olduğum Authorization Number ve License Number bilgilerini giriyorum. Bu bilgiler, Microsoft tarafından Volume Licensing işlemi tamamlandıktan sonra Volume Licensing Service Center (VLSC) üzerinden sağlanır.

Bu iki numara, lisansların doğrulanması ve Microsoft Clearinghouse tarafından lisans sunucusuna atanabilmesi için zorunludur. Eksik ya da hatalı girilirse işlem başarısız olur ve lisans yüklenemez.

Girilen değerlerin biçimi, ekranın alt kısmında Sample bölümünde örnek olarak gösterilir. Bilgilerin doğru girildiğinden emin olduktan sonra Next butonuna tıklayarak lisans yükleme adımlarına devam ediyorum.



25- Product Version and License Type adımında Product version bölümünde, hangi Windows Server işletim sistemi versiyonu için lisans girişi yapacağımızı seçiyoruz. Windows Server 2016 olarak seçiyorum.



25.1- License type adımında, ortamda kullanılan lisanslama modeline uygun olarak RDS Per Device CAL, RDS Per User CAL veya VDI Suite Suite Per Device Subscription License türlerinden biri seçilmelidir. 

RDS Per User CAL, her bir kullanıcıya bir lisans atanmasını gerektirir ve bu kullanıcı hangi cihazdan bağlanırsa bağlansın, tek bir lisans yeterli olur. Bu model, kullanıcıların hem Desktop hem de Laptop gibi birden fazla cihaz kullandığı yapılarda daha avantajlıdır.

Ekrandaki diğer seçenekler şunlardır:

⚡ RDS Per Device CAL

Her bir cihaza lisans atanır. Cihazdan kim bağlanırsa bağlansın, o cihaz lisanslı sayılır. Kiosk veya Call Center (çağrı merkezi) ortamlarındaki paylaşımlı bilgisayarlarda daha uygundur.

⚡ VDI Suite Per Device Subscription License

Bu, Virtual Desktop Infrastructure (VDI) senaryolarında kullanılan, sanal masaüstü erişimi için özel olarak sunulan bir lisanslama modelidir. Yıllık abonelik modeline dayanır ve genellikle VDI altyapılarında tercih edilir.

Ben bu kurulumda, ortamımda kullanıcı temelli oturum senaryoları uygulandığı için RDS Per User CAL seçeneğini işaretliyorum.



25.2- Sarı ünlemle dikkat çekilen uyarı alanında, yüklediğiniz lisans tipinin, ortamda kullanılan lisanslama modu ile aynı olması gerektiği belirtiliyor. Eğer bu ekranda RDS Per User CAL lisansı yüklüyorsanız, ortamınızda Remote Desktop Session Host (RDSH) ya da Remote Desktop Virtualization Host (RDVH) rolü yüklü olan tüm sunucuların lisanslama modunun da RDS Per User CAL olarak ayarlanmış olması gerekir. Aksi takdirde, lisans sunucusu doğru çalışsa bile kullanıcı oturumlarında lisans uyumsuzluğu nedeniyle bağlantı hataları yaşanabilir.

Bu nedenle lisans yüklemesinden önce, ortamınızdaki tüm Remote Desktop Session Host (RDSH) sunucularında lisanslama modunun Per User CAL olarak yapılandırıldığından mutlaka emin olunmalıdır. Bu ayar, yalnızca Group Policy üzerinden veya Registry düzenlemesiyle gerçekleştirilebilir; Server Manager arayüzünden ayarlanamaz.

İlgili Group Policy ayarı, aşağıdaki gibidir:

Bu Group Policy ayarı, Remote Desktop Session Host (RDSH) rolüne sahip sunucularda hangi lisanslama modunun (Licensing Mode) kullanılacağını zorunlu olarak belirlemek amacıyla yapılır. Yani amaç, RDSH sunucularının, kullanıcı bağlantıları için Per User CAL ya da Per Device CAL gibi doğru lisanslama modunu kullanmasını garanti altına almak.

Bu GPO ile:

✔ RDSH sunuculara açık ve net bir şekilde şu lisanslama modunu kullanacaksın demiş oluyorsun.

✔ Lisans sunucusundaki mod ile RDSH sunuculardaki mod uyumlu hale getirilmiş oluyor.

✔ Uyuşmazlık nedeniyle oluşabilecek bağlantı reddi, log uyarısı ya da uyumluluk sorunları ortadan kaldırılıyor.

Kısacası License Server ayrı, RDSH Server'lar ayrı çalışır. Bu ayar, ikisinin aynı dili konuşmasını sağlar.

Bir diğer önemli konu, Quantity yani satın aldığınız lisans adedidir. Satın aldığınız lisans adedinden daha fazla değer girmenize teknik olarak bir engel yoktur. Yani Microsoft, lisans sunucusuna 50 lisans almış olsanız bile 100 adet CAL değeri girmenizi yazılımsal olarak engellemez. Bu alan, tamamen beyana dayalı bir yapı ile çalışır ve bu esneklik, lisans sözleşmesinin ihlal edilmesini meşrulaştırmaz.

RDS lisanslama modeli, Microsoft’un Volume Licensing Terms dokümanlarında açıkça tanımlanmıştır ve sisteme girilen lisans miktarının, fiziksel olarak satın alınmış lisans sayısıyla birebir eşleşmesi gerekir.

Fazla giriş yapmanız durumunda herhangi bir teknik uyarı almazsınız Çünkü Install Licenses Wizard, girilen lisans miktarını teknik olarak Microsoft sunucularında doğrulamaz; yani sistem, o lisansı gerçekten satın alıp almadığınızı anlık olarak online kontrol etmez.

Bu davranışın temel nedeni, RDS Licensing sunucusunun yalnızca beyana dayalı çalışmasıdır. Yani;

✔ Lisans yükleme adımında girdiğiniz Authorization Number ve License Number, Microsoft Clearinghouse üzerinden doğrulanır ama sadece lisans türü ve program bilgisi bazında kontrol edilir.

✔ Kaç adet lisans yüklediğiniz, bu kontrolün parçası değildir. Çünkü Microsoft, o anda sizin ne kadar lisans satın aldığınızı gerçek zamanlı olarak lisans sunucunuza karşı doğrulamaz.

✔ Bu işlem bir anlamda Honor System durumuna dayanır. Yani sen "ben 100 kullanıcı için lisans aldım" diyorsan, Microsoft sana güvenerek bu sayıyı girmeni sağlar ama denetimde Audit, bunu faturalandırma kaydınla karşılaştırır.

Özellikle RDS Per User CAL lisanslaması, sunucu tarafında denetlenebilir değil, raporlamaya ve denetime açık bir sistemdir. Microsoft, Audit süreçlerinde Volume Licensing sözleşmenizdeki kayıtlar ile RD Licensing sunucusu üzerindeki girilmiş değerleri karşılaştırarak lisans uyumsuzluğu tespit edebilir.

Bu nedenle:

✔ Gerçekten satın aldığınız kadar lisansı girin.

✔ Fazla giriş yapılması lisanslama açısından çalışır gibi görünse bile bu durum, lisans ihlali anlamına gelir.

✔ Özellikle kurumsal denetimlerde bu fark ciddi yaptırımlara yol açabilir. Kısacası, sistem size sınırsız giriş imkanı tanır ama sorumluluk kullanıcıya aittir. Yasal olarak, yalnızca satın aldığınız RDS CAL miktarı kadar giriş yapılmalıdır.

Install Licenses Wizard üzerindeki işlemlerimi tamamladıktan sonra Next butonuna basarak ilerliyorum. Bu adım, lisans sunucusuna fiziksel olarak lisans atamasının yapılacağı bölümdür ve satın alınan hakların RD Licensing Server üzerinde görünmesini sağlar.

Windows Server 2016'da Remote Desktop Services kurulumu ve lisanslama süreci, doğru yapılandırma yapıldığında oldukça esnek ve güçlü bir uzaktan erişim altyapısı sunar. Özellikle RD Session Host, RD Connection Broker, RD Licensing ve RD Gateway gibi bileşenlerin nasıl bir araya geldiği iyi anlaşılırsa, ölçeklenebilir bir mimari oluşturmak mümkündür.

Bu makalede, Windows Server 2016 üzerinde Remote Desktop Services bileşenlerinin kurulumu ve lisanslama sürecine dair uçtan uca bir kurulum senaryosu üzerinden ilerledik. RDS mimarisinde rol oynayan RD Connection Broker, RD Web Access ve RD Session Host gibi bileşenlerin yapılandırma sırasına dikkat ederek, ortamın hem işlevsel hem de lisans açısından sürdürülebilir olması için gerekli adımları detaylıca ele aldık. Özellikle Session-based dağıtımlarda kullanıcıların aynı RD Session Host üzerinde birbirinden izole oturumlarla nasıl çalıştığını, bu oturumların arka planda hangi bileşenlerle yönetildiğini ve lisanslama modelinin buna nasıl entegre edildiğini örneklerle açıklamaya çalıştık.

Kurulum sürecinde dikkat edilmesi gereken noktaların başında, lisanslama modeline göre doğru RD Licensing sunucusunun belirlenmesi ve Active Directory içindeki gerekli izinlerin eksiksiz uygulanması yer alıyor. Aksi halde kullanıcı bağlantıları sınırlanabilir veya lisans uyarılarıyla karşılaşılabilir. Ayrıca RD Connection Broker bileşeninin, özellikle yüksek erişilebilirlik senaryolarında merkezi oturum yönetimi açısından nasıl konumlandığını da yapının sağlıklı çalışması için belirleyici bir nokta olarak irdeledik.

Genel yapının sağlamlığı, doğru role atamaları, sertifika yapılandırmaları ve kullanıcı erişim testleriyle tamamlandığında Remote Desktop Services, merkezi oturum yönetimi ihtiyacı olan birçok ortam için oldukça esnek ve yönetilebilir bir çözüm haline geliyor. Buraya kadar anlatılan yapı taşları, ilerleyen kurumsal senaryolarda gerek Load Balancing gerekse Multi-Factor Authentication (MFA) gibi gelişmiş entegrasyonlara da zemin hazırlayacak nitelikte. Bu noktadan sonra yapılacak her geliştirme, aslında üzerine inşa edilen temelin ne kadar doğru kurulduğuyla doğrudan ilişkili olacak.

Faydalı olması dileğiyle...