Remote Desktop Services Yüksek Erişilebilirlik Çözümleri makale serimizin bu bölümünde Remote Desktop bağlantılarımızın daha güvenli sağlanmaları ve merkezi bağlantı yönetimini sağlayabilmek için RD Gateway Rolünü ekliyoruz.

Daha önceki bölümlerde RDS HA Server grup içinde RD Gateway rolünü yükleyecek olduğumuz sunucuları eklememiştik. Server grup düzenlenmesi işlemlerini Bölüm 11 RDS Farmına Birden Fazla Collection Eklenmesi bölümünde gerçekleştirmiştik. Aynı işlemi RD Gateway sunucuları içinde gerçekleştirdik. Bu bölümü tekrardan paylaşmıyorum.

RD Gateway sunucuları yüksek erişilebilirlik çözümleri ile gerçekleştirilecektir ve kullanacak olduğumuz yüksek erişilebilirlik teknolojisi Microsoft NLB’ dir. Bölüm 3 Network Load Balancing Yapılandırılması konulu makalemizde RD Web Access sunucularımız için yapmış olduğumuz NLB yapılandırılmasının aynısını RD Gateway sunucularımız için gerçekleştiriyoruz.

RD Gateway bağlantıları Sertifika ile doğrulanmaktadır. Sertifikamız için ihtiyaç duyulan SAN bilgileri bu makalemiz içinde paylaşılacaktır ve sertifika oluşturulması için Bölüm 5 RDS Farmı Sertifika Oluşturulması makalemizde paylaşmıştık.

RD Gateway Sunucumuz RDS Farmımız içinde bulunan RDS sunucuları ile aynı network içinde barınacaktır. Topolojinin basit çizimi yukarıda belirtilmiştir. Bu topoloji içinde gösterilen bütün RDS Rolleri Yüksek erişilebilirlik özelliği ile yapılandırılmış ve her bir sunucudan en az iki tane bulunmaktadır. Farklı topoloji seçimleri ve firewall üzerinde izin verilmesi gerekli olan protokoller için Bölüm 15 RD Gateway Topoloji Seçimi makalemizde paylaşmıştık.

Yukarıda ki bölümde ön gereksinimlerimizi belirttik ve RD Gateway Rolünün kurulumu için Deployment Overview bölümünü açıyoruz ve RD Gateway butonuna basıyoruz. Yeşil artı işaretini görebilmektesiniz.

Add RD Gateway Server sihirbazımız içinde Server Grup içine eklemiş olduğumuz RDGW01 isimli sunucumuzu seçiyoruz ve ilerliyoruz.

Remote Desktop Clientların RD Gateway sunucusuna iletişim kuracakları ismi belirtiyoruz. Buraya yazacak olduğumuz isim daha sonra yapılandıracak olduğumuz sertifikanın içinde olmak durumundadır. RD Gateway Sertifika ihtiyacını Self-Signed certifika olarak oluşturabileceğimiz gibi Güvenilir bir sertifika otoriteden temin ettiğimiz sertifika veya etki alanımız içinde bulunan Local CA sunucusundan alabiliriz.

RDGW00.live.local ismi RDP clientlarımızın RD Gateway sunucumuza iletişim kuracakları isimdir. Topolojimiz içinde iki adet RD Gateway sunucusu yapılandıracağımız için NLB küme ismini burada belirtiyorum.

Confirmation bölümünde gelen bilgileri doğruluyoruz ve Add işlemi ile RDS farmımıza RD Gateway Rolümüzü ekliyoruz.

RD Gateway Rolü yükleme işlemi gerçekleştiriliyor.

RD Gateway rolü aktif olarak çalışabilmesi için yeniden başlatmaya ihtiyaç duymaktadır. Self Signed Sertifika oluşturacaksak bu bölümde Configure Certificate bölümü ile bu ihtiyacı karşılayabiliriz. Bizler daha önceden Local CA üzerinden sertifika oluşturduğumuz için Close ile sihirbazımızı kapatıyoruz.

RDS Farmımız içinde RD Gateway Rolü başarılı bir şekilde eklendi. Deployment Overview ekranında RDS farmımızın son durumunu görebilmekteyiz.

Deployment Server bölümünde RD Gateway sunucumuzun eklendiğini görüyoruz. Bu bölüme kadar anlatmış olduğumuz işlemlerin aynısını RDGW02 sunucumuz için yapmamız gerekmektedir.

RDGW02 sunucumuzu RDS farmımıza ekledikten sonra RD Gateway Rolü için yüksek erişilebilirlik çözümünü gerçekleştirmiş olacağız. RD Gateway sunucumuzu RDS farmı içinde tanımlanması için, RD Web Access üzerinden yapılacak olan RDP bağlantıları için geçerli olabilmesi için Configure Deployment özelliğini düzenliyoruz. Bu bölümde RD Gateway bölümüne geliyoruz ve RDS farmımız içinde bir RD Gateway sunucusu olduğunu RDS Farmına tanıtıyoruz. Bu yapılandırmayı yapmazsak eğer RDP kullanıcılarımız RD Web Access üzerinden RD Gateway sunucumuzu kullanamayacaktır ve firewall izinlerini RD Gateway üzerinden yapılandırdıysak External kullanıcılarımız RDS ortamına bağlantı yapamayacaklardır.

Bu bölümde yapacak olduğumuz işlemler Use These RD Gateway server settings bölümünde RD Gateway sunucumuza erişim sağlanacak FQDN bilgisini tanımlıyoruz. Kimlik doğrulama yöntemi olarak Password Authentication yöntemini seçiyoruz.

RD Gateway bağlantısı ile gerçekleştirilen RDP bağlantıları iki taraflı kimlik doğrulama istemektedir. Bunlardan bir tanesi RD Gateway bağlantısı ve diğeri ise Remote Desktop Session Host bağlantısıdır. Bu iki bağlantı aynı kullanıcı ile gerçekleştirilecekse Use RD Gateway credentials for remote conputer kutusunu işaretlenir ve iki bağlantı tek kimlik doğrulaması üzerinden gerçekleştirilir.

RDP aracında olduğu gibi RD Web Access bağlantısı da bağlantının yapılmış olduğu networkü anlayabilmektedir. Eğer bağlantılar RDS ortamının bulunmuş olduğu networkten yapıldıysa RDP bağlantılarının daha yavaş olmaması adına RD Gateway kullandırtılmaya bilinir. Bypass RD Gateway server for local address kutusu ile bunu yapabilmekteyiz.

Remote Desktop Services Yüksek Erişilebilirlik Çözümleri makale serimizin bu bölümünde RDS farmına eklemiş olduğumuz RD Gateway sunucumuzun özelliklerini ve temel yapılandırma adımlarını gerçekleştireceğiz.

RD Gateway sunucumuzu yapılandırmak için diğer RDS rollerinde olduğu gibi Deployment Overwiew ekranı kullanılmamaktadır. Yönetim işlemlerini RD Gateway sunucumuz üzerinde gerçekleştirebilmekteyiz. RD Gateway rolü yükleme sırasında RD Gateway Manager yönetim konsolu yüklenmektedir ve bu konsol ile RD Gateway sunucularımızın yönetimini ve yapılandırmasını gerçekleştirebiliriz.

RD Gateway Manager üzerinde RD Gateway rolünü yüklediğimiz sunucumuzu konsola ekliyorum. Yukarıda görüldüğü gibi konsol ve içeriği çok basit bir ara yüze sahip. Bu bölümde Policies bölümü altında CAP ve RAP policiylerini görebilir, düzenleyebilir, yedekleme vb. işlemleri yerine getirebiliriz.

Hemen altında bulunan Monitoring bölümünde aktif bağlantıları izleyebilmekteyiz.

RD Gateway Manager üzerinde her bir RD Gateway sunucumuz üzerinde bulunan bağlantı durumlarını Connection Status bölümünde görebiliriz. Bu bölümde bağlandığımız RD Gateway sunucumuza bağlı bulunan bağlantı sayısını, kullanıcısı sayısını görebilir, izleyebilir ve bağlantıları sonlandırabiliriz.  Configuration Status bölümünde RD Gateway sunucumuz üzerinde oluşturmuş olduğumuz Policyleri görebilir ve bu kısayol üzerinden ihtiyaç duyulan değişiklikleri yapmak üzere hızlı bir şekilde yönlendirilebilmekteyiz.

RD Gateway sunucumuzun temel yapılandırma işlemlerini ve neler yapabileceğimizi, değiştirebileceğimizi inceleyelim.

General bölümünde RD Gateway sunucumuzun sahip olduğu kaynaklara bağlı olarak bağlantıları limitleyebilmekteyiz. Önerilen Allow the maximum supported simultaneeus connections yapılandırmasıdır. Limit maximum supported simultaneeus connections to bölümü ile sayı belirtebilir ve bu sayının üzerinde bağlantının eş zamanlı olmamasını sağlatabiliriz. Bu sayı UDP, http ve RPC-http bağlantılarının toplamı kadar olmalıdır. Bir RDP bağlantısında 3 farklı protokol ile bağlantı kurulduğu düşünülürse 10 eş zamanlı bağlantı için bu sayının 30 olarak verilmesi sağlıklı olacaktır. Elbetteki bu değeri önermemekteyiz. Disable new connectionskutusunu işaretlediğimiz zaman, mevcut bağlantıları kesmeden yeni bağlantıların kabul edilmemesi gerektiğini belirtebiliyoruz. Bağlantısı kopan veya oturumdan çıkan kullanıcı bu kutu işaretli olduğu sürece tekrar bağlantı kuramayacaktır.

SSL Certificate bölümünde RD Gateway sunucumuz üzerinde self signed certificate oluşturabiliriz. Bu sertifika oluşturması kolay ama güvenilirliği ve dağıtımı zor olduğu için tercih etmediğimiz bir yöntemdir. Çoklu RD Gateway ortamında zaten bu sertifika kullanılmamaktadır. RD Gateway Rolümüz içinde oluşturmuş olduğumuz sertifika RD Gateway sunucumuza yüklü durumda. İmport seçeneceği ile bu sertifikanın kullanılmasını sağlayacağız.

RD Gateway sunucumuza yüklediğimiz live-DC01-CA sunucumuz tarafından yayınlanan sertifikayı import ediyorum.

Yapmış olduğumuz bu değişiklik sonrasında RD Gateway servisinin yeniden başlatılacağına ve RD Gateway üzerinde bağlantı varsa bu bağlantıları kopartacağını bildiren uyarı ile karşılaşıyoruz. Bu işlemleri yapacağımız zaman dilimini iyi seçmiş olmamız gerekmektedir.

Sertifikamız RD Gateway sunucumuza başarılı bir şekilde yüklendi.

Transport Settings bölümünde RD Gateway sunucumuzun kullanmış olduğu http, https ve udp portlarını değiştirebiliriz. Bu bölümde yapacak olduğumuz değişiklikler bağlantıların yöntemini ve firewall üzerinde oluşturulan kuralları etkileycektir. Benzer değişiklikleri bağlantı yapacak olan clientlar üzerinde ve firewall üzerindeki kurallarda yapmamız gerekmektedir.

RD CAP Store bölümünde RD Gateway sunucumuzun kullanacak olduğu policylerin tutulacağı yeri belirtiyoruz. Bölüm 15 RD Gateway Topoloji Seçimi makalesinde belirttiğimiz gibi merkezi bir NPS server varsa bu sunucu kullanılabilir demiştik. Bizler merkezi bir NPS Server kullanmadığımız için Local Server running NPS bölümünde bir değişiklik yapmıyoruz. Eğer ortamımızda merkezi bir NPS server olsaydı Central server running NPS bölümünü seçmemiz ve NPS sunucumuzun ismi veya ip adresini tanımlamamız yeterli olacaktır.

RD Gateway sunucumuza bağlantı kuracak olan clientların durumlarının bağlantı yapılmadan önce RD Gateway sunucumuza gönderilmesini şart koşabiliriz. Bu özellik ile RAP ppolitikalarında belirttiğimiz kuralların sağlanıp-sağlanamadığının bilgisini bağlantı yapılmadan önce RD Gateway sunucumuza gelmesini sağlarız. Bu özellikle bağlantı sağlanacak olan clientların Firewall durumlarını, RDP versiyonlarını, OS bilgilerini, AV durumlarını vb. politikaya belirtmiş olduğumuz bilgileri isteyebiliriz. Bu bölümü Request Client To Send A Statement Of Health kutusunun işaretlenmesi ile gerçekleştirebiliyoruz.

Server Farm bölümünde RDS farmı içine eklemiş olduğumuz RD Gateway sunucularımızın hostname bilgilerini yazıyoruz. Önerilen RD Gateway yüksek erişilebilirlik çözümü NLB yapılandırılmasıdır ve NLB üyesi durumunda bulunan her bir RD Gateway sunucumuzu bu bölüm içine ekliyoruz.

Auditing bölümünde RD Gateway sunucumuza yapılan başarılı, başarısız bağlantıları, RD Gateway yapılandırma değişiklikleri vb. olayların kayıt altına alınmasını ve saklanmasını belirtiyoruz.

SSL Bridging bölümünde kullanmış olduğumuz firewall özelliklerine bağlı olarak bağlantıların köprülenmesini isteyebiliriz. Bu yapılandırma için firewallımızın bu özelliği desteklemesi gerekmektedir. Gelen bağlantıların Https’ den Http olarak dönüştürülmesini, dış networkten erişimlerin hangi şifreleme yöntemi ile sağlanacağını belirtiyoruz.

Messaging bölümünde RD Gateway sunucumuza bağlantı kuran kullanıcılarımıza bağlantılarını başarılı bir şekilde sağladıklarını bildiren bir mesaj bildirimi gerçekleştirebilmekteyiz.

Remote Desktop Services Yüksek Erişilebilirlik Çözümleri makale serimizin bu bölümünde RDS farmımız içine dâhil ettiğimiz RD Gateway sunucumuz üzerinde güvenlik politikalarımızı belirleyeceğiz.

Bu makalede yapılandıracak olduğumuz işlemlerden sonra RD Gateway üzerinden RDS ortamına bağlantı kurabilecek kullanıcıları, kullanıcı bilgisayarlarını, kullanıcı ayarlarını, süresini vb. birçok politikaları oluşturmuş olacağız.

İlk önce şunu belirteyim. Çözümleri Bölüm 16 RDS Farmına RD Gateway Sunucusunun Eklenmesi makalemiz içinde belirtilen son adımı Configure the Deployment yapılandırmasını yaptıysanız hiçbir kullanıcı bu makale içinde belirtilen işlemleri gerçekleştirmeden RDS ortamına bağlantı gerçekleştiremeyecektir ve yukarıdaki hata ile karşılaşacaktır. RD Gateway üzerinde oluşturulan varsayılan politikalar bağlantıların kabul edilmemesi yönündedir.

RD Gateway üzerinde birçok RD RAP ve RD CAP politikaları oluşturabiliriz. Bu oluşturma işlemlerini tek bir sihirbaz ile yapabildiğimiz gibi her bir politika için ayrı sihirbazları kullanabiliriz. RD Gateway sunucumuz tek bir tane RDS ortamını yöneteceği için bir adet RAP ve bir adet CAP politikaları benim için yeterli olacaktır, bu sebepten mevcut politikaları düzenlemeyi uygun görüyorum.

Connection Authorization Policies ile RD Gateway üzerinden Remote Desktop Bağlantısı kurabilecek kullanıcıları, kullanıcı kimlik doğrulama yöntemlerini, bağlantı sürelerini ve bağlantıları sırasında kullanabilecekleri kaynakları belirleyebilmekteyiz.

Varsayılan değerde oluşturulmuş RDG_CAP_ALLUsers isimli politikamızı düzenliyoruz. İlk olarak bu policynin ismini değiştiriyorum ve RD Gateway CAP Policy 1 ismini veriyorum. Bu policy ismini değiştirmeden önce zaten aktif durumdaydı ve Enable this policy kutusu üzerinde bir değişiklik yapmıyor, aktif olarak bırakıyorum.

Requirements bölümünde Oluşturulan/Düzenlenen bu CAP policysini kullanarak RD Gateway sunucumuza bağlantı gerçekleştirecek kullanıcıları ve gruplarımızı belirliyorum. Bu gruplar RD Gateway üzerinde oluşturulacak yerel kullanıcı ve gruplar olabildiği gibi önerilen etki alanımız içinde bulunan kullanıcı ve grupların kullanılmasıdır. RD Session Host sunucumuza bağlantı izinlerini vermiş olduğum grupları bu bölümde ekliyorum. Her bir grup yetkilerini farklı-farklı denetlemek farklı yetkiler vermek isteseydim ayrı politikalar hazırlayarak bu ihtiyacı karşılayabilirdim. Client computer group membership (optional) bölümünde ise bağlantı yapabilecek bilgisayarları belirleyebilir ve güvenliğimi arttırabilirim. Optional bölüme ekleyecek olduğumuz clientların en az RDP 7.0 aracına sahip olmaları gerekmektedir. Windows Authentication yöntemi olarak Password kutusunu işaretliyorum.

Device Redirection bölümünde RDP bağlantılarında, bağlantıyı kuran bilgisayar üzerindeki hangi kaynakların RDP oturumunda kullanılıp-kullanılmayacağını belirliyoruz. Enable device rediretion for all client devicesseçimini gerçekleştirirsek hiçbir kaynak engellenmeden RD Gateway üzerinden oturuma bağlantı sağlanacaktır. Disable device redirection fort he following client devices types bölümünde seçmiş olduğumuz kaynaklar RD Gateway üzerinde engellenecek ve RD Session Host üzerine yapılan RDP bağlantılarında kullanılmayacaktır. Bölüm 12 Collection Yapılandırılması makalesi içinde Client Settings bölümünde bu kaynaklardan bahsetmiştik.

Bir senaryo düşünelim. Collection yapılandırmamız içinde varsayılan ayarı bıraktık yani bütün kaynaklara izin verdik. CAP politikamızda ise yukarıda görüldüğü gibi Ports (Com and LPT) ve Plug and Play Devices özellikli aygılatımızın engellenmesini istedik. Bağlantılar RD Gateway üzerinden yapıldığı zaman disable olarak yapılandırmış olduğumuz kaynaklar hiçbir şekilde oturuma gitmeyecektir. Ama oturumlar RD Gateway kullanılmadan direk olarak RD Session Host üzerine gerçekleştirilirse Collection üzerinde yapmış olduğumuz yapılandırmalar geçerli olacaktır. Only allow client connections to Remote Desktop Session Host servers that enforce RD Gateway device redirection kutusunu işaretlediğimiz zaman belirlemiş olduğumuz bilgisayarlar bu yapılandırmadan etkilenmeden kaynaklarını oturum içinde kullanabileceklerdir.

Timeouts bölümü Bölüm 12 Collection Yapılandırılması makalesi içinde Client Settings bölümünde Session yapılandırmalarından bahsetmiştik. RD Gateway üzerinde ki Timeouts yapılandırması buna denk gelmektedir. RD Gateway üzerinde belirlemiş olduğumuz Enable idle timeout bölümünü 10 dakika olarak belirledik. Kullanıcımız 10 Dakika boyunca RDP oturumunda bir işlem yapmazsa RD Gateway tarafından oturum sonlandırılacaktır. Enable Session Timeout bölümünü yapılandırmıyoruz. Bu bölüm içinde yer alan oturum zamanlamaları RD Session Host üzerinde yapmış olduğumuz zaman yapılandırması ile beraber çalışacaktır. Önerim bu yapılandırmaların Collection Seviyesinde yapılandırılmasıdır. Sebebini bir senaryolaştıralım. RD Gateway üzerinde Idle zamanını 10 dakika verdik Collection yapılandırmasında 15 Dakika olarak belirledik. Kullanımız RD Gateway üzerinden RDP bağlantısı kurdu ve 10 dakika boyunca bir işlem yapmadı. Bunun sonrasında RD Gateway bağlantıyı kesecektir, hâlbuki Collection yapılandırılmasında idle zamanının dolması için 5 dakikalık bir zaman dilimi daha var. 10 dakika sonrasında RD Gateway bağlantıyı Idle olarak algılayıp kesecek RD Session Host ise idle olarak bekleyen oturumun bağlantısı kesildiği için Disconnected from session ayarlarını devreye alacaktır.   

Özet olarak CAP politikaları ile RDP bağlantılarımızı daha güvenli ve merkezi olarak yönetebiliyoruz. Fakat burada yaptığımız CAP Politikalarımızı Collection yapılandırması ile birlikte, uyumlu yapılması daha sağlıklı ve güvenli bağlantıları bizlere sağlayacaktır.

Resources Authorization Policies ile RD Gateway üzerinden Remote Desktop Bağlantısı kurabilecek bilgisayarları, bilgisayarların barınmış olduğu networkü ve bağlantı kuracakları RDP belirleyebilmekteyiz.

Varsayılan değerde oluşturulmuş RDG_RAP_ALLComainComputers isimli politikamızı düzenliyoruz. İlk olarak bu policynin ismini değiştiriyorum ve RD Gateway RAP Policy 1 ismini veriyorum. Bu policy ismini değiştirmeden önce zaten aktif durumdaydı ve Enable this policy kutusu üzerinde bir değişiklik yapmıyor, aktif olarak bırakıyorum.

User Group CAP Policysinde olduğu gibi RD Gateway sunucusu kullanarak RDP Oturumuna bağlantı kuracak kullanıcılarımızı User Group Altına ekliyorum.

Network Resources bölümünde RD Gateway üzerinden RDP oturumuna bağlantı kuracak bilgisayarları ve networkleri belirliyoruz. Select an Active Directory Domain Services network resource grup ile etki alanımız içinde bulunan ve RDP oturumu gerçekleştirecek olan bilgisayarları ekleyebiliriz. Select ans existing RD Gateway-managed group or create new oneözelliği ile RD Gateway üzerinde oluşturmuş olduğumuz local bilgisayarları ekleyebilir veya bu bölümde RDP bağlantısı gerçekleştirecek bilgisayarları oluşturabiliriz. Bizim gerçekleştirecek olduğumuz seçim Allow users to connect to any network resource özelliğidir. Bu özellik ile RDP bağlantısını gerçekleştirecek olan bilgisayarların herhangi bir networkten ve herhangi bir RDP aracı yüklü bulunan bir aygıttan yapılmasını sağlıyoruz.

Allowed Ports bölümü Rd Gateway üzerinden RD Session Host sunucularımıza yapılacak olan RDP portlarını belirleyebiliriz.  Allow connections only to port 3389 ile varsayılan değer kullanılarak bağlantının yapılmasını isteyebiliriz. Güvenliğimiz için RDP portunu değiştirmediysek bu bölüm seçilmelidir. Allow connections to these ports ile farklı, birden fazla portu belirleyebilmekteyiz. RD Gateway sunucumuz birden fazla RD Session host veya RDP özelliği aktif duruma getirilmiş birden fazla sunucunun RDP oturumunu denetleyecekse ve portları farklılık gösteriyorsa bu bölümü seçmeliyiz ve RD Session host sunucumuz üzerinde düzenlemiş olduğumuz portları bu bölüme eklemeliyiz. Birden fazla port yazılma işlemi ; karakteri ile ayrılmalıdır. Allow connection to any port ile herhangi bir port sınırlandırılması olmadan bağlantının yapılmasını belirleyebiliriz.

RAP ve CAP politikalarımızı düzenledik ve artık RD Gateway sunucumuz üzerinde RDP bağlantıları sağlanabilir duruma geldi. Monitoring ekranını kontrol ettiğimiz zaman hangi bilgisayarın, hangi RD Session Host sunucusuna ne zaman, hangi port kullanılarak bağlandığı gibi detaylı bilgileri görebilmekteyiz ve bu oturumları yönetebilmekteyiz.

Print Server’la ilgili yazıcı kurma ve yönetme gibi operasyonel işleri Admin olmayan bir başkasına veya guruba devrederek iş yükünüzü azaltmak isteyebilirsiniz. Bu işlem için “Control Panel >> All Control Panel Items >> Administrative Tools” altındaki “Print Management” tools sağ tıklanarak açılan alanda “Run as Administrator” seçilerek çalıştırılır.

Açılan ekranda Print Servers sekmesi altında listelenen sunucumuz üzerinde sağ tıklayarak Properties tıklanarak açılır.

Gelen ekranda Security tabı altına altındaki ADD butonuna basın.

Gelen ekranda boş alana yetki vermek istediğiniz kullanıcı veya gurup adını girip “Check Names” butonuna bastıktan sonra OK butonuna basarak gurubu ekrana getirin.

Security tabı altında yetki verilecek kişi veya gurup göründükten sonra aşağıda belirtilen uygun yetkiler seçilerek önce APPLY sonra OK butonlarına basarak işlemi kaydedin.

Print Server Security Yetki Açıklamaları:

Print: Yazıcıya bağlanma, yazdırma, kendisine ait belgeyi duraklatma / iptal etme gibi temel yazdırma izin tipidir.

Manage Printers: Printer’a ait temel yetkilerin dışında printer ve spooler ayarlarının değiştirilmesi, izinlerinin yönetilmesini, driver değişikliği, yazıcı kuyruğunun yönetimi, Form eklemesini sağlar.

Manage Documents: Yazdırmak için printer’a gönderilen tüm dökümanların duraklatılması / iptal edilmesi gibi temel yönetimi yapmaktadır.

View Server: Default’ta Everyone yetki gurubu içerisinde yer alan bu hak ile kullanıcı sunucu üzerinde paylaştırılmış tüm yazıcıları ve sunucu durumunu görmesini sağlamaktadır. Bu temel yetki verilmeden diğer haklar çalışmaz.

Manage Server: Yeni printer/port tanımlama/silme; driver güncelleme/yüklemesi gibi üst düzey işlemlerin yapmasını sağlamaktadır.

Yetki Tipleri:

Full Yetki: Eğer driver kurma da dahil tüm operasyonel yetkiler atanacaksa tüm alanlar işaretlenmelidir.

Sınırlı Yetki: Bu yetki tipinde genel olarak sadece sorun tespiti ve yazıcı kurulumu (Yazıcı ekleme, Yazıcı kuyruğunu silme hariç yönetimi, Yazıcı ayarlarının görüntülenmesi,  Port ve Form yönetiminin) yapılacaksa Print, View Server, Manage Server yetkileri verilmelidir.

Sadece Yazdırma Yetkisi verilecekse Print ve View Server yetkileri verilmelidir.

Eğer Full yetki verilecekse;

Driver kurulumu için sunucunun System32 klasörüne kullanıcının erişim yetkisinin olması gerekmektedir. Bunun için öncelikle kullanıcıyı “Print Operators” gurubuna ekleyiniz. Bu işlem için Server Manager Tools üzerinden Tools tabı altında “Computer Management” tıklanarak açılır.

Açılan ekranda Groups altındaki “Print Operators” çift tıklanarak açılır.

Gelen ekranda ADD butonuna basarak yetki verilen kullanıcı veya gurubu ekleyiniz .

Son adım olarak sunucunun “C:\Windows\System32\spool\drivers\x64\3” klasöre yetki verilecek kişi veya gurubu full yetki verilmesi gerekiyor. Bu işlem için klasör üzerinde sağ tıklanarak Properties tıklanarak açılır.

Gelen ekranda Security tabına altındaki Advanced butonuna basınız.

Gelen ekranda ADD butonuna basınız.

Açılan pencerede “Select a principal” linkine basıp yetki atanacak kişi veya gurubu yazınız.

Yetki verilecek gurubu veya kişiyi doğru yazıp yazmadığınızı “Check Names” butonuna basarak teyit ediniz. Sonra OK tuşuna basarak yetkilendirmeye geçiniz.

Gelen ekranda “Full Control” kutucuğunu işaretleyip OK ile değişikliği kayıt altına alınız.

Yapılan yetkilendirmenin bulunduğunuz klasör ve altına yazılabilmesi için “Replace all child . . . “ kutucuğunu işaretleyip önce Apply sonra OK butonuna basınız.

Owner olmadığınız için mevcut klasör içerisindeki dosyalara yazma hakkı olmadığından hatalar alabilirsiniz. Continue deyip geçiniz.

Bu işlemleri tamamladığınızda artık Admin olmayan kullanıcılar bile printer sürücüsünü güncelleyebileceği gibi tüm operasyonel işlemleri de yapabilecektir.

Makalemin sonuna geldik. Umarım faydalı bir makale olmuştur.

Windows Server Doküman ve Yazıcı (Print) Sunucusu; özetle dağınık durumdaki yazıcılarınızı, faks cihazlarınızı ve tarayıcılarınızı merkezi bir ortamdan paylaşımını / dağıtımını sağlamak için kurulan bir servistir. 

Genellikle GPO ile kullanıcılarınıza otomatik yazıcı dağıtımının yapılması, Merkezi tek bir ekrandan yazıcı / baskı durumlarının izlenmesi, RDS veya Muhasebe sunucuları gibi yoğun iş yükü servislerinin spooler servisinin crash olmasının önlenmesi, Birden fazla RDS sunuculu ortamlarda yazıcı kurulum / yönetim maliyetlerinin azaltılması için kullanılmaktadır.  Ayrıca çok kolay şekilde faks yönetimiyle zaman ve kâğıt israfını önlemiş olursunuz.

Aşağıda linkini verdiğim makalelerde Print Server ile detaylı bilgi verildiğinden bu makalemizde Windows Server 2012 R2 ile gelen Print Server (Yazıcı Sunucusu) servisindeki yenilikleri ve kurulumu anlatılacaktır.

http://www.cozumpark.com/blogs/windows_server/archive/2014/03/30/server-2008-r2-print-server-kurulumu-yonetimi-ve-cluster-yapilandirmasi.aspx

http://www.cozumpark.com/blogs/windows_server/archive/2011/09/11/windows-server-2008r2-print-server-yonetimi.aspx

http://www.cozumpark.com/blogs/windows_server/archive/2010/10/03/windows-yazdirma-sureci-ve-rhs-easy-printer.aspx

1.       Server 2012 ile Gelen Yenilikler:

Aşağıda verdiğim özet tabloda görüneceği üzere Windows Server 2012 R2 ile gelen birçok yeni özellik eklenmiştir.

Type 4 Drivers:

v4 yazıcı sürücü modeli basit ve bir o kadar da esnek bir yönetim deneyimi sağlar. En büyük özelliği güncelleme ve dağıtımını Windows Update / WSUS ile yapılabilmesidir.

Kazanımları:

* Yazıcı paylaşımı için öncesinde driver dağıtımına gerek yoktur. Driver kurulumu için ek yetki gerekmemektedir.

* Driver dosyalarının ismi çakışmaları önleyerek birbirinden yalıtılmıştır.

* v3 sürücülerinden daha küçük ölçekli olduklarından çok daha kısa sürede kurulum gerçekleşir.

* Daha stabil ve kullanıcı dostu ara yüze sahiptir.

* Windows 7 ile birlikte desteklenen 2100 yazıcı driver’ı için 538 Mb yer kaplamaktadır. Windows 8 ile birlikte v4’e geçilirse %60 kazanım sağlanacaktır.

Mimari Yapı:

Aşağıdaki v3 ve v4’ün çalışma yapısına ait diyagramda görüleceği üzere çıktı alma süreci başladığında donanım üreticisine bağımlılık büyük oranda azalmaktadır. Bu da driver nedenli kesintilere ve hataları azaltmış olacaktır.

Print Class Driver (v4) Model Topolojisi

v3 Print Driver Model with GDI Rendering Topolojisi:

Branch Office Direct Printing (BODP):

Server 2012 ile birlikte gelen ve sadece Windows 8 ve Server 2012 üzerinden yapılacak yazıcı paylaşımlarında kullanılabilecek bu özellik ile WAN üzerinden yazıcı erişimlerinde hem ağ trafiğini ve Print Server üzerindeki iş yükünü azaltırken hem de daha hızlı yazdırma kabiliyeti sağlanmış olacaktır.

Aşağıdaki diyagramda görüleceği üzere BODP tanımlanmış yapıda, önce yazdırma işlemi yapan bilgisayar üzerinde Client Side Rendering ile yazdırılacak dosya işlenip Print Server’a gönderilir. Print Server’ın kuyruğunda biriktirilen iş Rendering bittiğinde direk client bilgisayar üzerinden yazıcıya gönderilir.

Web Services for Devices (WSD) Secure Printing

Temel olarak güvenli olmayan cihazlar/yazıcıları IPSec kullanılarak WEB üzerinden çıktı alınması sağlanmaktadır. Active Directory ile yazıcı arasında Print Server güvenilirlik için (trust arbitrator) arabuluculuk yapmaktadır. Buda trojen veya virüslerle yazdırma işleminin ele geçirilip kontrolsüz yazdırmayı önlemektedir. Bu işlemi yaparken Clinet’lara bir etkisi bulunmamaktadır.

Enhanced Point and Print

Server 2012 ve Windows 8 ile birlikte gelen bu özellik baskı yönetimini kolaylaştırmak için geliştirilmiştir. Ek bir sürücü kullanımına gerek kalmadan Windows 8 ve Server 2012 üzerinden yazıcı paylaşımının yapılması hedeflenmektedir. Üç Ana bölüme ayrılarak incelenmektedir. Bunlar;

Basic: Enhanced Point and Print’ın temelini oluşturur. Erişim, varsayılan kullanıcı ara birimini kullanarak sağlanır ve yazdırma işlemi Print Server’da olur.

Custom user interface (Optional): varsayılan kullanıcı arabiriminde desteklenmeyen bu gelişmiş özellikleri uygun desktop and Windows Store App’ların yazdırma süreçlerinde kullanılabilir.

Rendering (Optional) : Windows 8 ve v4 Type Driver kullanılan yazdırma sürecindeki cevirim işlemini Client tarafında yapmaktadır.

Enhanced Point and Print ile yazdırma süreci aşağıda sunulmuştur.

Geliştirilen ve Yeni Eklenen Fonksiyonlar:

Çıkartılacak Özellik:

LPD servisi; Server 2012’e kadar desteklenen fakat sonrası sunucu işletim sistemlerinde kaldırılacaktır. Eğer Line Printer Daemon Protocol (LPR/LPD) servisini kullanıyorsanız en kısa sürede bağlantı tipinizi ya IP Printer’a ya da Windows Standard Port Monitor’e geçmek için gerekli çalışmalara başlamalısınız.

2.       Sunucunun Hazırlanması:

Bu kısma kadar Server 2012 ile gelen yenilikleri görmüş olduk. Şimdi ise kurulacak olan sunucumuzun devreye alınmadan önce gerekli şekilde hazırlığının yapılmasını göreceğiz. Öncelikle temiz ve full güncellenmiş (Optinal sekmesinde yer alan güncellemelerde dahil) yapılarak kurulumu tamamlanmış sunucumuza aşağıdaki adımlar uygulanır.

Redirection’ın Kapatılması:

Bu aşamada sunucularda sistem stabilitesini sağlama adına ve olası problemlerin önlenmesi için uzak bağlantı ile gelen port ve printer yönlendirmelerinin kapatılması gerekmektedir. Server 2012’de RDS role’ü kurulmadan “Remote Desktop Session Host Configuration Tools” gelmemektedir.

Bunun için ya varolan 2008 ve 2008R2 sunucularımız üzerinden Control Panel’inden Administrative Tools >> Terminal Services (Remote Desktop Services) >> Terminal Services Configuration’u (Remote Desktop Session Host Configuration) çalıştırın. Gelen ekranda “RD Sesion Host Configuration” üzerinde sağ tıklayıp “Connect to Remote Desktop Sesion Host Server”’ı seçin.

Gelen ekranda “Another Computer” seçmesini tıklayıp açılan alana yöneteceğiniz sunucunuzun ismini girin.

Gelen ekranda RDP-Tcp üzerinde sağ ile tıklayıp Properties girin.

Açılan ekranda  “Client Setting” altında Clipboard hariç hepsini işaretleyin.

İkinci yönden ise GPO ile yapmaktır. GPO’dan yapmak için; Computer Configuration >> Policies >> Administrative Templates >> Windows Components >> Remote Desktop Services >> Remote Desktop Session Host >> Printer Redirection altındaki değerler aşağıdaki gibi yapılır.

Ayrıca Computer Configuration >> Policies >> Administrative Templates >> Windows Components >> Remote Desktop Services >> Remote Desktop Session Host >> Device and Resource Redirection altındaki değerler aşağıdaki gibi yapılır.

Açık Sesion Sürelerinin Sınırlandırılması:

Performans ve olası problemlerin önlenmesi için Sunucuya bağlanan kullanıcıların belli bir süre sonra logoff edilmesi gerekmektedir. Kendi yapınıza göre uygun süreyi belirleyebilirsiniz. Bu işlem için Remote Desktop Session Host Configuration Tools’da Session sekmesini tıklayın. Açılan pencerede;

Idle Sesion Limit: Sunucuya bağlanan kullanıcının ne kadar süre boşta kaldığında disconnect yapılacağı belirleniyor.

Override user settings: Sunucuya bağlanan kullanıcıların ne kadar süre disconnect’te kaldığında logoff edileceği belirleniyor.

When sesion limit is reached or connection is broken: Sunucuya daha önceden hesap açmış bir kullanıcı yeniden bağlanırsa ne yapılacağı soruluyor. Burada ya “disconnect from sesion” secilerek aynı oturumuna bağlanması sağlanabilir veya “end sesion” denilerek öncekini sonlandır yeni oturum aç diyebilirsiniz.

Eğer Group Policy üzerinden yapılmak istenilirse “Computer Configuration >> Policies >> Administrative Templates >> Windows Components >> Remote Desktop Services >> Remote Desktop Session Host >> Sesion Time Limits” altındaki aşağıdaki ayarlar yapılır.

Server 2012 Windows NIC Teaming

Server 2012 üzerinde Network Teaming yapılacaksa kesinlikle Windows NIC Teaming feature’ı ile yapılandırılmadır. Bunun nedeni Microsoft’a açılan network problemlerine ilişkin case’lerde eğer farklı bir üreticiye ait teaming varsa öncelikle teaming’in bozulması istendiğinden olası bir problem yaşanmaması adına Server 2012 işletim sistemli sunucularımızda Teaming yapılandırmanızı Windows NIC Teaming feature’ı ile yapınız.

Bu işlem için Server Manager Tools’dan Local Server’a gelin. “NIC Teaming” yanındaki disable’ı tıklayarak veya lbfoadmin kısa ismini yazarak yönetim alanına gelin.

Gelen ekranda TEAMS alanı içerisinde Tasks’ı tıklayarak “New Team” secin. Açılan ekrana oluşturacağınız Team için isim girip “Member Adapters” kısmında listelenen uygun interface’leri işaretleyin.

“Additional Properties” tabını tıklayarak genişletin. Açılan ekranda “Teaming Mode” kısmında listelenen modellerden uygun olanı seçiniz.

Teaming Mode Çeşitleri:

Static Teaming: (IEEE 802.3ad) Eğer switch’iniz LACP’yi desteklemiyorsa bunu seçiniz. Burada team’e üye 1 interface aktif olurken diğerleri standby’da beklemektedir. Bu işlem için switch üzerinde de karşılıklı eş ayarların yapılması gerekmektedir.

Switch Independent: Farklı Switchlere takılı portlarınız varsa bunları tek bir team’e üye yapabilirsiniz. İsterseniz standby’da portta bırakabilirsiniz.

LACP: (IEEE 802.1ax, Link Aggregation Control Protocol) Team’e üye yapılan tüm portları aktif olarak kullanır. Gelişmiş ve dinamik bir yapı olduğundan aynı switch’e bağlı ve switch’de destekliyorsa LACP’nin kullanılmasıdır.

Network Team’lerini oluşturduktan sonra yukarıda bağsedilen Network için gerekli yapılandırmayı yaparak devreye alabilirsiniz.

Antivirüs:

Sunucular üzerine kurulacak anti-virüs muhakkak yönetilebilir ve sunucu mimarisine uygun olmalıdır.

Microsoft tarafından özel olarak oluşturulup yayınlanan Anti-Virus Exclusion Listesine bakarak servisiniz için uygulanacak exclution tanımlarını aşağıdaki linkte gösterildiği gibi yapınız.

http://support.microsoft.com/kb/822158/en-us

Ayrıca buna ek olarak aşağıdaki adresleride Exclusion tanımlanmalı.

%SystemDriver%\pagefile.sys

%allusersprofile%NTUser.pol

%SystemDriver%\Windows\System32\Spool

%SystemDriver%\Windows\Temp

%SystemRoot%\Windows\System32\Spool

DEP’in Kapatılması:

Data Execution Prevention değerini “Windows Programs and services” yapınız. Bu işlem için isterseniz Privilege (Run as Administrator) mode’da açılan komut penceresine “bcdedit.exe /set {current} nx OptIn” komut yazılıp enterlanır. İstersenizde “Control Panel >> System >> Advanced system settings >> Advanced >> Performans >> Settings >> Data Execution Prevention” altından ulaşabilirsiniz.

UAC’ın Kapatılması:

Third Party backup ürünü kullanıyorsanız olası problemlerin yaşanmaması için önerim UAC’ın (User Account Control Settings) kapatılmasıdır. Bu işlem için “Control Panel >> System and Security >> Action Center” altındaki “Change User Account Control Settings” tıklayıp açılan pencerede çubuğu aşağı çekerek “Never Notify”’ye getirin.

Sadece buradan kapatmak yetmiyor. Windows+F tuş kombinasyonuna basarak açılan ekranda regedit yazıp “Run As Administrator” ile çalıştırın.   

“HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\” altındaki EnableLUA anahtarını 1 yapıp sunucuyu restart edin. Eğer EnableLUA yoksa ise EnableLUA isimli yeni bir DWORD (32 bit) oluşturup değerini 1 yapın.

Ayrıca Server Manager Tools’dan Local Security Policy’e giriniz. Açılan ekranda “Local Policies >> Security Option” veya Group Policy’den “Computer Configuration >>  Windows Setting >> Security Setting >> Local Policies >> Security Options” altındaki “User Account Control: Run all administrators in Admin Approval” değerini Disabled yapınız.

 TCP Auto-Tuning Yapılandırması

Vista ile birlikte Network Performansı için gelen “TCP Auto-Tuning” özelliğinin File Server, Exchange, SQL, RDS gibi yoğun network trafiği kullanan sistemlerde kapatılması gerekmektedir.

Not:

* Server 2012 ve yeni donanım ise yapılmasına gerek bulunmamaktadır.

* Server 2012’nin NIC Teaming servisi kullanılıyorsa Tuning otomatik olarak kapalıdır.

Bunun için öncelikle “netsh int tcp show global” komutu çalıştırılır. Eğer enable ise disable yapılmak için aşağıdaki işlem komutları çalıştırılır

netsh int tcp set heuristics disabled

netsh int tcp set global chimney=disabled

netsh int tcp set global rss=disabled

netsh int ip set global taskoffload=disabled

netsh int tcp set global autotuninglevel=disabled

Genel Yapılandırma Ayarları:

* Eğer sunucunuzun RAM’i 25 GB ve üstü ise pagefile’i 22528 Mb olarak set edin. Altında ise RAM kadar pagefile verilmesi önerilir fakat asla otomatikte bırakmayın.

* Eğer sunucunuz fiziksel ve devamlı power kablosu takılı ise sunucu performansı için Contol Panel’den PowerOption’a girip “High Performance” a getirin.

* Özellikle sunucunuz network üzerinden yapılan file erişimlerinde veya network share alanında dosya çalıştırmaya ihtiyaç duyuyorsa Server Manager’ın ana ekranında öncelikle “Local Server” tıklayın. Açılan pencerede “IE Enhanced Security” yanındaki ON’u tıklayın.

Açılan ekranda hepsini OFF’a getirin.

* Eğer sunucunuzun işlemci CPU core sayısı 24’den fazla ise “Physical APIC Mode”’un enable edilmesi gerekiyor. Privilege (Run as Administrator) mode’da açılan komut penceresine aşağıdaki komut yazılıp Enter'lanır ve  sunucu restart edilir.

bcdedit /set usephysicaldestination yes

* Sunucunun saat ayarlarını kontrol ediniz. Türkiye için İstanbul seçilmeli.

* Task Scheduler üzerinden Defrag işlemi disable edilir.

* (Eğer fiziksel sunucuya kurulum yaptı iseniz) işletim sistemi cevap veremeyip siyah ekranda kaldığında sunucu donanıma ait uzak bağlantı konsolundan memory dump alınarak restart edilmesi için OS’e gelen NMI isteklerinin kabul edilmesi sağlamak için regedit Run as Administrator ile açılıp aşağıdaki adımlar uygulanır.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl altına NMICrashDump isimli yeni bir DWORD oluşturulup değeri 1 yapılır

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WHEA\Policy altına NMICrashDump isimli yeni bir DWORD oluşturulup değeri 1 yapılır

3.       Print Server Kurulumunun

Server Manager Tools üzerinden Manage sekmesi altında “Add Roles and Features” tıklayınız.

Burada da sadece RD lisans servisinin kurulumu ve yapılandırması anlatılacağından “Role-based or feature-based installation” seçeneği seçilip ilerliyoruz.

2012 Server Manager’ın özelliği uzak sunucu yönetiminin kolaylaştırılmasıdır. İsterseniz başka bir sunucu üzerinden kurulumu başlatabilirsiniz.

Biz sunucu üzerinden kurulum yapacağımızdan “select a server. . . “ kısmında default’ta gelen işlem yapacağımız sunucunun ismini seçip ilerliyoruz.

Gelen ekranda kurulum yapılacak Role’ün ismi isteniliyor. Burada “Print and Document Services” seçip ilerliyelim.

“Print and Document” rolü seçildiğinde “Print and Document Services Tools” kurulumu isteyip istemediğiniz sorulacaktır. Burada İnclude kutucuğunu işaretleyip “Add Feature” i seçin.

Gelen Feature ekranında; .Net 3.5, LPR Port Monitor, Telnet Client, Server Backup ve XPS Viewer bileşenleri seçilip NEXT butonu ile ilerleyelim.

Gelen ekranda “Print and Document” rolüne ait hangi servislerin kurulacağının seçilmesi istenmektedir. Burada kullanacağınız servisleri belirleyiniz. Bu servislerin kısaca açıklamak gerekirse;

Print Server: Temel yazdırma servisidir.

Distributed Scan Server: Ağ tarayıcılarının yönetilmesi, tarama süreçlerinin merkezi alandan yönetilmesi için kullanılmaktadır.

Internet Printing: Web servisleri üzerinden yazdırma hizmetini sağlamak için kullanılmaktadır. Bunu seçtiğinizde IIS üzerinde default web page oluşturarak yazıcılarınızı web üzerinden paylaşılmasını sağlamaktadır.

LPD Service: Line Printer Daemon (LPD) servisi, Unix base yazıcıların ve ip printer olmayan Windows client PC’lere bağlı yazıcıların print server üzerinden paylaşmasını sağlamaktadır.

ÖNEMLİ NOT: LPD servisi Server 2012 ile birlikte bırakılmaya başlanmıştır. 2012 sonrası işletim sistemlerinde artık bu servis olmayacağı bildirilmiştir. Eğer LPD servisi kullanıyorsanız en kısa süre TCP veya  Internet Printing servislerine geçişini yapmalısınız.

Gelen ekranda kurulum sonrasında restart işleminin otomatik yapılması için onay ekranındaki “Restart the destination server automatically if required” alanı işaretlenir.

Bu son adımda teyit amaçlı kurulacak servisler görüntülenmektedir. Eğer bir değişiklik varsa “Previous” butonu ile geri gelip düzeltmeleri yapabilirsiniz. Install diyerek kuruluma başlayabilirsiniz.

Ayrıca Server 2012’de .Net 3.5 kurabilmeniz için CD’yi mount edip kurulumun son adımında “Specify an alternate source path”kısmına CD’deki \sources\sxs klasörünün yeri gösterilmeli.

Eğer bu şekilde. Net 3.5’u kuramaz, hata alırsanız kurulum ekranından çıkın sunucuyu restart edin ve aşağıdaki komut ile cd yolunu göstererek kurabilirsiniz.

Dism /online /enable-feature /featurename:NetFx3 /All /Source:<drive>:\sources\sxs /LimitAccess

4.       Kurulum Sonrası Ayarlar

Hotfix Güncellemeleri:

Kurulum tamamlandığında sunucu restart istemezse siz restart edin. Arkasından aşağıdaki adreste belirtilen hotfixleri yükleyiniz.

http://blogs.technet.com/b/yongrhee/archive/2014/04/30/list-of-print-related-hotfixes-post-rtm-for-windows-8-1-and-windows-server-2012-r2.aspx

Hotfix yüklemesi tamamlandığında full Windows Update yaparak eklenen role ve feature’lar için geçerli güncellemeleri alın.

Eğer güncellemeleri yükleme sırasında hata alırsanız update paketlerinin KB kodunu aşağıdaki linke yazarak manuel indirip kurunuz.

http://catalog.update.microsoft.com/v7/site/home.aspx

PowerShell Yapılandırması:

Server 2012 ve 2012 R2 PowerShell’e dayalı çalışmaktadır. 2012 Print Server’a yeni eklenen gelişmiş PowerShell desteği ile eskiden komut satırından yaptıklarımızı artık PowerShell üzerinden daha kolay yapabilmekteyiz. Bu nedenle öncelikle PowerShell’de role komutlarının yüklenmesi lazım.

Bu işlem için PowerShell üzerinde sağ tıklanıp “Run ISE as Administrator” çalıştırılır.

Sonra aşağıdaki komutları çalıştırmanız gerekmektedir.

Set-ExecutionPolicy -ExecutionPolicy Unrestricted

Import-Module ServerManager

5.       Kaynak:

http://technet.microsoft.com/en-us/library/hh918357.aspx

http://technet.microsoft.com/en-us/library/hh831468.aspx

http://www.cozumpark.com/blogs/windows_server/archive/2010/10/03/windows-yazdirma-sureci-ve-rhs-easy-printer.aspx

http://www.cozumpark.com/blogs/windows_server/archive/2011/09/11/windows-server-2008r2-print-server-yonetimi.aspx

http://www.masterofmalt.com/software-development/blog/?p=18

http://ahmetmusakosali.com.tr/content/physical-apic-mode

http://support.microsoft.com/kb/927069

http://support.microsoft.com/kb/2877237/EN-US

Bir önceki yazımızda Windows Server 2012 Print Server (Yazıcı Sunucusu) ile gelen yenilikleri ve kurulumu bahsetmiştik. Aşağıdaki linkten bu makaleme ulaşabilirsiniz.

http://www.cozumpark.com/blogs/windows_server/archive/2014/06/29/windows-server-2012-r2-print-server-yazdirma-sunucusu.aspx

Bu bölümde sizlere daha önceden aşağıda linkini verdiğim “Windows Server 2008R2 Print Server Yönetimi” isimli makalemde olmayan ve 2012 ile yeni gelen özelliklerin yönetimini anlatacağım. 

http://www.cozumpark.com/blogs/windows_server/archive/2011/09/11/windows-server-2008r2-print-server-yonetimi.aspx

1)      Type v4 Driver Ekleme

Server 2012 ile gelen en önemli özellik v4 veya Class Drivers olarak isimlendirilen yeni sürüm yazıcı sürücüleridir. Ne olduğunu kısaca özetlemek gerekirse; yazıcı üreticilerine bağımlılığı en aza indirerek daha hızlı, daha az yer kaplayan ve stabil yazdırma işlemlerinin sağlanabilmesi için geliştirilmiştir. Geliştirilmeye de devam edilmektedir. Güncellemeler ise Windows Update ile yapılacaktır.

Eğer yazıcıyı kullanacak Windows 8 ve Server 2012 client’larınız varsa Type v4 Class Drivers kullanmanızdır. Vista ve üstü işletim sistemlerinde Type v4 Class Drivers çalışmaktadır. Eğer karışık bir ortamınız varsa Önerim öncelikle yapınızda v4 sürücülerin istediğiniz gibi çalışabilirliğini test etmelisiniz.

Bu işlem için öncelikle Print Management Tools çalıştırılıp Print Server altında listelenen Yazıcı Sunucunuzun altındaki Drivers tabı üstünde sağ tıklayarak ADD DRIVERS deyiniz.

Gelen ekranda Print Server üzerinden yazıcıya bağlanıp yazdıracak işletim sistemi sorulmaktadır. Client’larınıza göre işletim sistemi sürümünüzü seçip NEXT ile ilerleyiniz.

Ortamınızdaki yazıcı modeline seçip sol tarafta Printers tabı altında listelenen sürücülerden sonunda Class Drivers veya V4 yazanlardan uygun olanı seçip NEXT butonuna basarak ilerleyip işlemi sonlandırınız.

2)      TCP/IP Yazıcı Tanımlama:

Network yazıcılarınızı TCP/IP kullanarak Print Server’a tanımlamak için öncelikle Print Management Tools çalıştırılıp Print Server altında listelenen Yazıcı Sunucunuzun altındaki Printers tabı üstünde sağ tıklayarak ADD PRINTERS deyiniz.

Gelen ekranda “Add a TCP/IP . . . .” ile başlayan alan işaretlenip NEXT butonuna basarak ilerlenir.

Gelen ekranda “Type of Divece” seçeneği ile yazıcınıza uygun erişim tipinin seçilmesi istenmektedir. Web Servis üzerinden erişilebiliyorsa erişimin isterseniz “Web Services Secure Printer” seçeneği ile IPSec ile güvenli hale getirebilirsiniz.

Autodetect seçeneğinde ise yazıcıyı test ederek TCP veya Web olarak girişini kendisi yapar. Önerim Auto’da bırakmamanızdır.

Gelen ekranda yüklenecek yazıcı için driver yüklemesinin yapılması istenmektedir. Önerilen yazıcı kurulumundan önce driver kurulumunun yapılmasıdır. Bizde bir önceki ekranda sürücü kurulumunu tamamlamıştık. Bu yüzden “Use an existing printer . . . . “ seçeneğini işaretleyip combo box’tan yazıcı için yüklediğimiz uygun driver’i seçip NEXT butonuna basarak ilerliyoruz.

İsterseniz bu aşamada  “install a driver” seçeneğini seçerekte yazıcı kurulu ile birlikte driver kurulumunu gerçekleştirebilirsiniz.

Gelen ekranda Share Name ve Printer Name kısımlarına Türkçe karakter kullanmadan boşluksuz bir şekilde uygun isim vererek. NEXT butonuna basarak ilerleyiniz.

Son ekran onay ekranıdır. Eğer ekranda görülenler arasında değişiklik yapacaksanız BACK tuşu ile geri geliniz. Eğer sorun yok ise NEXT butonu ile işlemi tamamlayınız.

Bu ekran da dikkat edilecek Publish:No yazması. Yani yazıcı şuanda Active Directory üzerinde paylaşılmış değil.

3)      Yazıcı Ayarları:

Yazıcıya ait ince ayar yapılması gerekiyorsa yazıcı üzerinde sağ tıklanıp Properties’e giriniz.

Bu kısımda yapılacak ilk yapacağımız işlem yazıcının Active Directory üzerinden paylaşım bilgisinin görüntülenmesinin sağlanmasıdır. Bu işlem için Sharing tabı altındaki “List the directory” kutucuğunu işaretleyiniz.

Bu alanda sonradan isterseniz paylaşım ismini değiştirebilirsiniz.

Port tabında yazıcının erişim adresi değiştiğinde yeni adresin girildiği alandır. Eğer bağlantı adresi değişikliği yapılacaksa öncelikle ADD PORT diyerek yeni adresin girişini yapınız sonrasında yeni girişi yapılan adresin yanındaki kutucuğu işaretleyin.

Advanced tabında yazıcının driver’ını değiştirmek için kullanırız. Bu işlem için Driver combo box içerisinden uygun driver’ı seçip geçerli kılabilirsiniz.

Security tabından kime hangi yetkiyi vereceğiniz ayarladığınız alandır. İlk kurulum yapıldığında Everyone kullanıcı gurubu çıktı almak için print yetkisine sahip olarak gelmektedir. Bu sayede ek bir şey yapmadan herkes bu yazıcıdan çıktı alabilmektedir. Bu işlem güvenlik açığı oluşturacağından kaldırılmalıdır. Bu işlem için Everyone üzerine bir kere tıklayıp Remove butonuna basılır.

Önerilen sadece ilgili kişi veya guruplara ihtiyacı kadar yetki verilmesidir. Fakat bazı durumlarda buna imkân olmamaktadır. Bu tip durumlarda en azında ADD butonuna basıp gelen alana Domain Users yazarak eklemektir.

Device Settings tabında ise yazıcıya ait genel ayarlar bulunmaktadır.

4)      Çoklu Olarak Kuyruğu Temizleme

Uzun süre kapatılmadan çalışan sunucunuz ve gönderim yapılmış bir şekilde arızaya düşmüş yazıcılarınız varsa Print Server performansınız düşmeye başlayacaktır. Bunun çözümü için belli aralıklara tüm yazıcı kuyruklarının temizlenmesidir.

Server 2012 ile gelen Print Server PowerShell komutları ile yazıcılarınıza ait yazdırma kuyruğunun temizlenmesini zamanlanmış görev yapabilirisiniz. Aşağıda kullanabileceğiniz komutlar yazılmıştır.

Son 1 günün üstünde kuyrukta bitikmiş iş varsa aşağıdaki komut ile temizleyebilirsiniz.

Get-Printer -ComputerName PrintServer1 | get-printjob | where{$_.SubmittedTime -lt ((Get-Date).adddays(-1))} | Remove-PrintJob

PowerShell üzerinden tüm kuyruktaki işleri temizlemek için aşağıdaki komutu yazınız

Get-Printer -ComputerName <SystemName>| Get-PrintJob | Remove-PrintJob

Eğer tek bir yazıcıya ait kuyruktaki işleri iptal edecekseniz aşağıdaki komutu yazınız

Remove-PrintJob -ComputerName tctp22wspsx01 -PrinterName <TestPrinter> -ID 2

Eğer bu işlemi Print Management Tools üzerinden yapılmak istenilirse listelenen yazıcılardan birine tıklayıp Ctrl+A tuş kombinasyonuna birlikte basarak tüm yazıcıları seçip sağ tuş ile tıklayın. Açılan menüden “Cancel All Jobs” ı işaretleyinizi. Bu işlem o anda yazılanlarda dâhil hepsini iptal edecektir.

5)      Tüm Yazıcıların AD Paylaşımının Yapılması:

Active Directory Etki Alanı Hizmetleri (AD DS) yazıcıları listelemek kullanıcıların daha kolay yazıcıları bulup yüklemelerini sağlar. Bu nedenle bir yazıcı sunucusuna yazıcıları yükledikten sonra, AD DS listelemek için kayıt olunur. Bu işlem tek bir yazıcı için yapılacağı gibi tüm yazıcılar içinde toplu olarak yapılabilir. 3

Eğer toplu olarak tüm yazıcıları Print Management Tools üzerinden AD üzerinde listelenmesinin yapılması istenilirse Print Server altında Yazıcı Sunucunuzun isminin altındaki Printers sekmesini tıklayıp sol tarafta listelenen yazıcılardan birine tıklayıp Ctrl+A tuş kombinasyonuna birlikte basarak tüm yazıcıları seçip sağ tuş ile tıklayın. Açılan menüden “List in Directory” ı işaretleyiniz.

Eğer PowerShell üzerinden toplu olarak tüm yazıcıların AD kaydının yapılması istenilirse aşağıdaki komutu çalıştırınız.

Get-Printer | ? published -eq $false | Set-Printer -Published:$true

Eğer tek bir yazıcıda işlem yapılacaksa yazıcı üzerinde sağ tıklanıp açılan menüden “List in Directory” yi tıklayarak yapılabilir.

Bir diğer yöntem ise ve tek bir yazıcıda işlem yapılacaksa yazıcı üzerinde sağ tıklanıp Properties’e girilip Sharing tabı altındaki “list in Directory” kutucuğunu işaretleyiniz.

6)      Kullanıcıların Yazıcı Driver Yüklemelerine İzin Verilmesi

Kullanıcı bir yazıcıyı map edip çalıştırmak istediğinde eğer driver yüklü değil ise yükleme talebinde bulunulacaktır.

Eğer kullanıcı çalıştığı ortamda Local Admin değil ise “Install Driver” butonuna basılsa bile kurulum yapılmasına izin verilmeyecektir.

Type v4 Class Drivers’ların güncellemesi Windows Update üzerinden yapılacağından kullanıcının sorun yaşamaması için GPO’dan driver kurma yetkilerinin verilmesi gerekmektedir. Bu işlem için Group Policy Management Console (GPMC) üzerinden ;

User Configuration > Policies > Administrative Templates > Control Panel > Printers giriniz

.

“Point and Print Restrictions” çift tıklayarak açıp Enabled diyerek policy’yi aktif edin

“Users can only point and print to these servers” ve “Users can only point and print to machines in their forest” eğer işaretli iseler check box’ın içini boşaltın

“When installing drivers for a new connection” sorusuna “Do not show warning or elevation prompt” cevabını seçin

“When updating drivers for an existing connection” sorusuna “Show warning only” cevabını seçin.

7)      Branch Office Direct Printing Ayarının Yapılması

Client işletim sistemi Windows 8 ve üstü sistemlerde yazdırma performansının iyileştirilmesi için geliştirilen Branch Office Direct Printing (BODP) özelliği her bir yazıcı için ayrı ayrı yapılmaktadır.

BODP özelliğinin aktif edilmesi için iki yol bulunmaktadır. Eğer Print Management Tools üzerinden yapılmak istenilirse ilgili yazıc üzerinde sağ tıklayarak açılan menüden “Enable Branch Office Direct Printing” seçin

Eğer PowerShell üzerinden yapılmak istenilirse aşağıdaki komutu çalıştırmanız gerekmektedir.

Set-Printer -name <String> -ComputerName <String> -RenderingMode BranchOffice

8)      Internet Printing Servisinin Devreye Alınması

Web üzerinden printer hizmetinin sunulması için Internet Printer Protokol (IPP) servisinin devreye alınması gerekmektedir. Bu işlem için eğer Print Sever rolü kurulurken Internet Printing servisini seçmediyseniz kurulum yapmanız için Server Manager Tools altında Manage tabı altındaki “Add Roles and Feature Wizard” çalıştırılır.

Roles altında “Print and Document” altındaki “Internet Printing” işaretlenir.

IPP hizmeti IIS üzerinden sağlandığından eğer sunucuda IIS kurulu değil ise kendisi ihtiyaç duyulan bilşenlerin eklenmesi için onayınıza sunacaktır. Gelen ekranda “Add Features” ı seçerek kuruluma devam edilir.

IIS rolüne ait kurulacak bileşenler sorulduğunda “Management Service” işaretli gelmiyor. IIS yönetimi için ihtiyaç duyulan bu servis için yanındaki kutucuğu işaretleyin.

Kurulum tamamlandığında sunucuya kurulu tüm yazıcılar sunucu üzerinden http://localhost/printers/ adresinden görüntülenirken başka bir ortamdan http://servername/printers adresinden erişilebilmektedir.

Yazıcıyı tıkladığınızda yönetim ve erişim bilgi alanı gelmektedir. Genel Menülerin açıklaması şu şekildedir:

Document List: Yazıcı kuyruğunu gösterir

Properties: Read Only olarak Yazıcı erişim bilgilerini ve genel özelliklerini göstermektedir.

Network Name: kullanıcılarımızın bağlanacakları adresi göstermektedir.

Eğer http://servername/printers şeklinde değil de http://servername yazarak bağlanılmasını istiyorsanız. Server Manager’dan Tools tabı altındaki IIS Manager’ı çalıştırın.

Gelen ekranda Default web sayfasının üzerinde sağ tıklayarak gelen menüden Remove diyerek silin.

IIS Manager Tools üzerindeki Sites üzerinde sağ tıklayarak “Add Website” diyerek yeni bir tane Web Sitesi oluşturalım.

Gelen ekranda SiteName kısmına uygun bir isim verip PhysicalPath alanına C:\Windows\Web\Printers klasörünü gösterip OK diyerek işlemi kaydedin.

IIS Manager üzerinden oluşturmuş olduğunuz Web Sites’a tıklayın. Sol tarafta açılan menüden “Default Document” ı tıklayarak açın.

Gelen menüde sol üst kısımdaki ADD butonuna basarak açılış sayfası girişini yapınız.

Gelen ekranda Web Print Server için açılış sayfası ipp_0001.asp olarak giriniz.

9)      Kim ne kadar çıktı aldı?

“Bir kullanıcı ne kadar çıktı aldı” veya “hangi yazıcıdan ne kadar çıktı alındı” soruları Biz sistem yöneticilerinin hep aradığı soruların cevabıdır. Server 2012 ile birlikte gelişmiş log yöntemi ile artık ek bir uygulama satın almaksızın bu bilgileri toplayabilirsiniz.

Bu işlem için öncelikle Event Viewer’da loğların toplanabilmesi için Sırasıyla “Application and Services Log”  altında Microsoft altında Windows altında PrintService altındaki Operational üzerinde sağ tıklayın.

Açılan menüde “Enable Log” tıklayın. Böylelikle yazıcı işlemlerinin kayıt altına alınmış oldu.

Aşağıda örnek bir event kaydı görülmektedir. Bu kayıtta görüleceği üzere kimin hangi makine üzerinden hangi yazıcıya çıktı gönderdiği gösterilmektedir.

Şimdi ise log kaybı olmaması için Event Viewer’da belirlediğimiz büyüklüğe log ulaştığında arşivleyip yeni bir log açması için “Application and Services Log”  >> Microsoft >> Windows >> PrintService >> Operational üzerinde sağ tıklayıp Properties’e girin.

Gelen ekranda “Archive the log when full, do not overwrite events” seçeneğini işaretleyin.

Bu aşamadan sonra oluşan log dosyaları aşağıdaki adreste toplanmaktadır.

%SystemRoot%\System32\Winevt\Logs\Microsoft-Windows-PrintService%

Bu işlemden sonra eğer Log Management yazılımı kullanıyorsanız işiniz çok kolay eğer kullanmıyorsanız excel’de oluşturacağınız makro ile istediğiniz raporu düzenli olarak çekebilirsiniz.

İsterseniz aşağıdaki PowerShell scripti ile düzenli olarak oluşturacağınız zamanlanmış görevle verileri çekip ilgili belirleyeceğiniz database’e import edebilirsiniz.

Get-WinEvent -LogName Microsoft-Windows-PrintService/Operational | `

Where-Object ID -eq 307 | `

Select-Object TimeCreated, `

@{Name="User";Expression={$_.Properties[2].Value}}, `

@{Name="Source";Expression={$_.Properties[3].Value}}, `

@{Name="Printer";Expression={$_.Properties[4].Value}}, `

@{Name="Pages";Expression={$_.Properties[7].Value}}

İki bölümden oluşacak yeni bir makale serisi ile sizlerle Windows Server 2012 R2 yeteneklerini paylaşmaya devam ediyoruz. Bu serimizde de sizlerle Microsoft’un yeni nesil işletim sistemi olan Windows Server 2012 R2 bakış açısı ile Active Directory Domain Servislerinde “Grup Seviyesinde Yönetilen Servis Hesapları (Group Managed Service Accounts (gMSA) ) konusunu detaylarıyla ve uygulamalı olarak ele alacağız. Bundan önceki makalelerimizde Stand-Alone Managed Service Account konusunu hem Windows Server 2008 R2 hem de Windows Server 2012 R2 için incelemiştik. Stand-Alone MSA hesapları kısıtlarından dolayı çok fazla öne çıkmamıştı. Windows Server 2012 ve Windows Server 2012 R2 ile gelen gMSA ile yönetilen servis hesaplarının yetenekleri daha da geliştirilmesiyle BT çalışanları için her geçen gün daha da önemli olduğunu gözlüyoruz. Zira hem servis hesaplarında otomatik parola ve SPN yönetimi, hem güvenlik risklerinin minimum seviyede olması ve operasyonel kolaylık avantajları ile kurum ve kuruluşlarda “servis hesaplarının dönüşümü” ya da “yeni servis hesabı modeline geçiş” gibi başlıklar altında gündemdeki yerini çoktan almış durumda. Makalemizde Windows Server 2012 R2 ile Group Managed Service Account (gMSA) yani Grup Seviyesinde Yönetilen Servis Hesaplarını  detaylarıyla, uygulamalı olarak inceliyoruz.

Grup Seviyesinde Yönetilen Servis Hesaplarını (gMSA) Tanıyalım:

Servis hesabı kullanan ya da gereksinim duyan SQL Server, IIS (Internet Information Server), SCCM (System Center Configuration Manager), SCOM (System Center Operations Manager) ve 3.parti diğer uygulamaların kurulumunu yapmış ya da kurulan uygulamayı halihazırda kullanıyor olabilirsiniz. Bu uygulamaların çalışmasını, işlevini yerine getirmesini ve kullanıcıların da bu uygulamalara bağlanıp işlemlerini yapmaları için uygulamalara ait alt yapıda gerekli servislerin sağlıklı bir şekilde çalışıyor olması gerekiyor. Uygulamalara ait bu servislerin çalışmasını sağlayan servis hesapları uygulamanın kurulumu esnasında ya da uygulama kurulumundan sonra tanımlanabilir. Örneğin bir SQL Server kurulumunu yaparken (SQL Server 2008 kurulumu ve kurulum aşamasındaki ayarları SQL SERVER 2008 – Kurulum  makalesinden inceleyebilirsiniz.) kurulum esnasında SQL Server uygulamasına ait bileşenler için servis hesabı tanımlamasını gerçekleştiririz. Servis hesabı sadece kurulan uygulamalarda değil, özellikle Windows içerisinde zamanlanmış görevleri (scheduled tasks) çalıştıracak spesifik bir hesap tanımlarken de sıklıkla kullandığımız yapılardır. Burada kullanacağımız servis hesabını bugüne kadar active directory domain yapısında ya da yerel bilgisayarımızda normal bir kullanıcı hesabı gibi oluşturup, güvenli bir parola tanımı yaparak gerçekleştiriyorduk. Bu hesabın şifresinin sınırsız süre ile yenilenmemesi için de hesap özelliklerinden “Password Never Expires” seçeneğini aktif hale getirerek çözüyorduk.

Uygulamaların kurulumu ya da kurulum sonrası servisler üzerinde tanımlanan bu hesapların zaman içerisinde şifrelerinin değiştirilmesi durumunda o andan itibaren bu kullanıcı hesabını kullanan uygulama servisleri çalışmayacaktır. Böyle bir durumda çözüm olarak kullanıcı heasabına eski şifreyi tanımlamanız gerekecek, ya da yeni şifreyi uygulamaya ait tüm servislerde yeni şifreyi tek tek tanımlamanız gerekecektir. Tabi burdaki en büyük handikap bu servis hesabının hangi sunucular üzerinde ve hangi uygulamalar için kullanıldığının elinizde dökümantasyonu yoksa başlıyor. Bu durumda ya tek tek sunuculara bağlanıp bu servis hesabının kullanıldığı yerleri tespit edip güncellemek ya da bu ayrı bir makalede inceleyeceğimiz PowerShell script çözümü ile sunucuları uzaktan tarayıp bir CSV dosyasına bu hesabı kullanan listeyi çıktı veren çözümü uygulamak olacaktır. Group Managed Service Account’lara geçiş ile bütün bu dertlerden kurtulmuş olacaksınız. Windows Server 2012 & R2 ile daha da geliştirilen ve sadece uygulamalara ait servisler üzerinde kullanmak için tasarlanmış Group Managed Service Account (gMSA) – Grup Seviyesinde Yönetilen Servis Hesapları sayesinde artık yukarda söz ettiğimiz zorluklar ortadan kalkmış olacak. gMSA Servis Hesapları ile active directory domain ortamlarındaki Service Principal Names (SPNs) yönetimi de daha da iyileştirilmiş oldu. Bu özellik sayesinde uygulamalar meydana gelebilecek kesilmeleri de azaltılarak toplam sahip olma maliyeti düşürülmüş olacak (Örneğin yukarıda da bahsettiğimiz gibi değiştirilen servis hesabı şifrelerinin yeniden tanımlanmasından doğan kesintiler.) .

Yönetilen servis hesabına active directory tarafından parola ataması domain controller sunucu ile uygulamaya ait servisin çalıştığı sunucu arasında bizim herhangi bir müdahalemize gerek kalmadan arka planda otomatik şifre yönetimi gerçekleştilen bir süreçtir. Ve bu atanan parola yine parola yenilenme  dönemlerinde active directory tarafından otomatik olarak yenilenerek hesabın kullanıldığı bilgisayarlardaki servislere de otomatik olarak güncellenir. Burada manager service account şifre yönetimi standart bilgisayar hesaplarına atanan şifre yönetimine benzer bir süreçte gerçekleşmektedir.

Yönetilen servis hesapları ile Windows Server 2008 R2 işletim sisteminde tanıştığımız makalemizin başlangıcında da bahsetmiştik. Windows Server 2008 R2 üzerinde tek tip yönetilen servis hesabı vardı :Stand-alone managed service accounts(MSA).

Stand-alone MSA hesaplarının belli kısıtları bulunuyordu. Bu konuda detaylar ve uygulama adımları için Windows Server 2008 R2 İle Active Directory Domain Servislerinde Gelen Yenilikler – Managed Service Accounts (Yönetilen Servis Hesapları) makalemizi inceleyebilirsiniz.

Windows Server 2012 ve Windows Server 2012 R2 ile yönetilen servis hesapları iki tipte geliyor:

·         Stand-alone Managed Service Accounts (MSA)

·         Group Managed Service Accounts (gMSA)

Stand-Alone Managed Service Accounts (MSA) konusunu daha önceki makalemizde detaylarıyla ele almıştık. gMSA hesapları stand-alone MSA hesaplarından farklı olarak aynı anda çoklu sunucularda kullanılabilme özelliğine sahiptirler. Bu özelliği sayesinde özellikle cluster servislerinin kullanıldığı sunucu farm yapılarında, örneğin IIS Network Load Balance yapıları, Exchange DAG üyeleri ve SQL Failover Cluster mimarilerinde kullanılma desteğini getirmiştir. Böylece cluster mimarilerinde de servis hesapları Windows işletim sistemi tarafından otomatik yönetilme desteği gelmiş oldu.

gMSA Servis Hesaplarının Karakteristik Özellikleri :

gMSA yönetilen servis hesaplarının genel özellikleri:

Standart kullanıcı hesapları gibi domainden uygulanan password politikaları ya da fine-grained password politikalarına bağlı olarak tanımlanmazlar.

gMSA hesaplar için kompleks, 240 byte yani 120 karakter uzunluğunda ve kriptolanmış yapıda atanırlar. Domain controller tarafından belirlenen bu şifreler gMSA hazırlık aşamasında oluşturulan root key, gMSA hesabının SID değeri ve o anki zaman bilgisine bağlı otomatik olarak oluşur.

Not: Root Key, gMSA oluşturulmaya başlamadan önce Windows Server 2012 R2 ya da Windows Server 2012 domain controller sunucular üzerinde üretilen bir kimlik bilgisidir. Bu anahtar bilgisi tüm KDC server rolüne sahip domain controller sunucular arasında replikasyona tabi tutulur.

gMSA şifre üretme işlemi Windows Server 2012 R2 ya da Windows Server 2012 KDC domain controller sunucular tarafından gerçekleştirilebilir.

gMSA hesabı için atanan şifrelere bilgisayar hesaplarında olduğu gibi sadece Windows kimlik doğrulama altyapısı ile erişmek mümkündür.

gMSA hesaplarına ait şifreler Windows Server 2012 ve Windows Server 2012 R2 Domain Controller sunucular üzerinde Key Distribution Center (KDC) servisi tarafından üretilir ve yönetilirler.

gMSA hesapları domain içerisindeki bilgisayar hesaplarına benzer bir modelde çalıştırılır.

Stand-alone MSA hesapları aynı anda tek bir sunucu üzerinde kullanılabilirken, Group Managed Service Accounts (gMSA) çoklu sunucular üzerinde kullanılabilme desteğini getirmiştir.

gMSA hesapları zamanlanmış görevlerde de kullanılabilir.

gMSA hesaplarda lock olma durumu söz konusu değildir.

gMSA hesaplarının yenilenme süresi varsayılan olarak 30 gündür.

gMSA hesaplar normal kullanıcı hesapları gibi interaktif logon olma yetenekleri yoktur. Dolayısıyla herhangi bir şekilde gMSA şifresini ele geçiren birinin sistemlere standart kullanıcı hesaplarındaki gibi logon olması söz konusu değildir.

gMSA hesaplarının hangi sunucular ya da sistemler üzerinde kullanılabileceğini sistem yöneticileri belirlerler.

gMSA hesapları yetki olarak standart kullanıcı hesapları gibi minimum seviyede yetkiye sahiptirler ve ilave grup üyeliği vb. yetkiler atanmadıkça yüksek seviyede yetkileri de yoktur.

Sistem yöneticileri de gMSA hesaplarının şifrelerini belirleyebilirler, fakat bunu tavsiye etmiyoruz, genel olarak bir anlam da ifade etmiyor.

gMSA hesaplarının şifreleri sistem yöneticileri tarafından istenildiği zaman varsayılan 30 günü beklemeden de resetlenebilir.

Tüm yönetilen servis hesapları varsayılan olarak domain içerisinde CN=Managed Service Accounts, DC=<domain>, DC=<com> kabı altında oluşmaktadır. İstenirse farklı organizational unit ya da kaplar içerisinde de tanımlanabilirler.

Active Directory Schema yapısı Windows Server 2012 ya da Windows Server 2012 R2 seviyesine yükseltildikten sonra schema içerisinde msDS-GroupManagedServiceAccount adında bir obje sınıfı (class) otomatik olarak oluşur.

Active Directory Schema konsolu içerisinden bu sınıf nesnelerine ait objeleri aşağıdaki şekilde görüntüleyebilirsiniz.

msDS-GroupMSAMembership niteliği gMSA hesabını kullanacak bilgisayar ya da bilgisayarları yönetmek için kullanılır. Bu nitelik (attribute) sayesinde gMSA hesabının kullanılabileceği bilgisayarlar bu nitelikte tanımlanmış hesaplarla sınırlandırılmıştır.

msDS-ManagedPassword niteliği gMSA hesabının önceki şifresi, mevcut şifresi ve şifre değiştirme aralığı gibi bilgileri tutar. gMSA kullanan sunucular domain controller bilgisayarını mevcut şifre bilgisi için sorgularlar.

msDS-ManagedPasswordInterval niteliği gMSA hesabı oluşturulmasında belirlenir ve sonrasında değiştirilemez, şifrenin kaç günde bir değiştirileceği bilgisini tutar.

msDS-ManagedPasswordID niteliği gMSA hesabı için Key Distribution Center (KDS) tarafından kullanılan anahtar tanımlayıcıdır ve şifre üretiminde görev alır.

msDS-ManagedPasswordPreviousID niteliği gMSA hesabına ait önceki şifre anahtar tanımlayıcısıdır.

Yönetilen Servis Hesabı Ortam Gereksinimleri:

Yönetilen Servis Hesaplarının oluşturulması ve kullanımı için belli gereksinimlerin sağlanması gerekir. Bunlar:

Group Managed Service Account kullanımı için active directory schema versiyonunun minimum Windows Server 2012 olması gerekir.

Group Managed Service Account kullanımı için domain ortamında minimum bir adet Windows Server 2012 ve üzeri versiyonda domain controller olmalıdır.

gMSA şifrelerinin üretilmesi için öncelikle root KDS anahtarı oluşturulmalı ve diğer domain controller sunucularına replikasyonun tamamlanması gerekir. Uygulama adımlarında bunu daha detaylı inceliyor olacağız.

gMSA hesabı kullanılacak sunucuların işletim sistemi Windows Server 2012 ve üzeri versiyonda sunucu işletim sistemi ya da Windows 8 ve üzeri client işletim sistemi olmalıdır. Ayrıca bu sistemler üzerinde Windows PowerShell Active Directory modülünün yüklenmesi gerekir.

gMSA hesabı yönetimi Windows 2012 ya da Windows 8 işletim sistemi ve üzerinde çalışan sistemler üzerinden PowerShell komut satırı araçları ile gerçekleştirilir. 3rd parti GUI araçlar kullanılarak da bu yönetim gerçekleştirilebilir.

Otomatik şifre ve Service Principal Name (SPN) yönetimi için domain fonksiyonel seviyesinin minimum Windows Server 2008 R2 seviyesinde olmalıdır. Windows Server 2008 R2 domain seviyesi altındaki senaryolarda şifre yönetimi otomatik gerçekleşir, fakat otomatik SPN yönetimi çalışmaz, SPN yönetimi sistem yöneticileri tarafından gerçekleştirilmelidir.

gMSA Yönetilen Servis Hesabı Oluşturma Aşamaları

Yönetilen Servis Hesaplarının uygulama aşamalarını şu şekilde tanımlayabiliriz:

Active Directory domain içerisinde KDS Root Key oluşturulması

Bu işlem her domain için sadece bir defa yapılır.

gMSA hesabı Oluşturulması ve Yapılandırılması

gMSA hesabının Kullanıcılak  Sunucular Üzerinde Yapılandırılması

SONUÇ

İki bölümden oluşacak makale serimizin ilk bölümünün sonuna geldik. Bu bölümde sizlerle Windows Server 2012 R2 ile Group Manager Service Accounts(gMSA) mimarisini, bu özelliğin bizlere neler sağladığı, bu özelliği kullanmaya başlamadan önce yapmamız gereken ön hazırlıkları ve altyapı gereksinimlerini paylaştık. Bir sonraki bölümde de Windows Server 2012 R2 ile gMSA yönetilen servis hesabı adım adım uygulama aşamalarını inceliyor olacağız. Bir sonraki bölümde görüşmek dileğiyle esenkalın.

İki bölümden oluşan makale serimizin ikinci bölümüne devam ediyoruz. İlk bölümde Windows Server 2012 R2 bakış açısı ile Active Directory Domain Servislerinde “Grup Seviyesinde Yönetilen Servis Hesapları (Group Managed Service Accounts (gMSA) ) konusunu mimarisi, uygulama alanları, altyapı gereksinimleri gibi detaylarını inceledik.Makale serimizin bu bölümünde de Windows Server 2012 R2 ile Group Managed Service Account (gMSA) oluşturma aşamalarını detaylarıyla, uygulamalı olarak inceliyoruz.

Group Managed Service Accounts – gMSA Oluşturma Adımları:

gMSA Yönetilen Servis Hesaplarının uygulama aşamalarını makalemizin birinci bölümünde şu şekilde tanımlamıştık:

         Active Directory domain içerisinde KDS Root Key oluşturulması

o   Bu işlem her domain için sadece bir defa yapılır.

         gMSA hesabı Oluşturulması ve Yapılandırılması

         gMSA hesabının Kullanıcılak  Sunucular Üzerinde Yapılandırılması

Şimdi bu adımları detaylı olarak sırayla uygulayalım.

1.      Active Directory Domain İçerisinde KDS Root Key Oluşturulması

Windows Server 2012 R2 işletim sisteminde çalışan domain controller sunucumuzda PowerShell komut satırı aracını çalıştırdıktan sonra Add-KDSRootKey –EffectiveImmediately komutunu aşağıdaki şekilde uyguluyoruz.

Komut çalıştırılmasından sonra oluşan root key’in domain içerisindeki diğer domain controller sunuculara replikasyon yapılması için 10 saate kadar beklemeniz gerekecektir. 10 saatlik süre özellikle çoklu site yapılarında çalışan active directory topolojilerinde replikasyonun tamamlanmasını garantileyen bir süre tanımıdır. Bu süreci hızlandırmak ve 10 saatlik beklemeyi ortadan kaldırmak için özellikle test ortamları için Add-KDSRootKey komutunu aşağıdaki şekilde bir ince ayarla kullanabiliriz.

Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))

2.      Active Directory İçerisinde Security Group Oluşturulması

Bu adım bir best-practice önerisidir. gMSA hesabınının kullanılacağı sistemleri ya da bilgisayarları bu gruba üye yaparak dinamik bir yönetim mekanizması oluşturulabilir. Bu adım zorunlu olmamakla beraber özellikle öneriyorum. Bu adım gerçekleştirilmezse servis hesabı oluşturma aşamasında servis hesabının kullanılacağı sistemlerin tanımlanması gerekecektir.

Not : Servis hesabının kullanıldığı sunucular üzerinde grup üyeliğinin etkinleşmesi için sunucuların yeniden başlatılması gerekecektir. Gruptan çıkarıldıklarında da yine etkinleştirme için sunucuların yeniden başlatılması gerekecektir.

Biz uygulamamızda servis hesapları için yukarıdaki şekilde görüldüğü gibi ServisHesaplari adında Global-Security grup oluşturup ilgili sunucuları da bu gruba üye yapıyoruz.

3.      gMSA Hesabın Oluşturulması

gMSA hesabınının oluşturulması için Windows Server 2012 R2 domain controller sunucu üzerinde PowerShell komut satırına geçiyoruz. Ve aşağıda görüldüğü gibi New-ADServiceAccount komutunu ilgili parametreleri ile çalıştırıyoruz.

Öncelikle active directory powershell modülünü yüklüyoruz:

Import-Module ActiveDirectory

Not: PowerShell 3.0 ve üzeri versiyonlarda Active Directory modülünü Import-Module ile yüklemeye gerek kalmadan doğrudan New-ADServiceAccount komutu kullanılabilir. Bu işlemle active directory modülü otomatik olarak memory’ye yüklenecektir.

Daha sonra New-ADServiceAccount komutu ve parametrelerini tanımlıyoruz:

New-ADServiceAccount -name <ServiceAccountName> -DNSHostName <fqdn> -PrincipalsAllowedToRetrieveManagedPassword <group> -ServicePrincipalNames <SPN1,SPN2,…>

Name :  gMSA servis hesap adı, bir başka ifade ile samAccountName tanımı.

DNSHostName : gMSA servis hesabının  tam DNS host tanımı.

PrincipalsAllowedToRetrieveManagedPassword :  gMSA servis hesabını kullanacak bilgisayar hesaplarının üye yapıldığı active directory grup tanımı.

ServicePrincipalNames :  gMSA servis hesabının SPN tanımı/tanımları.

Biz buradaki uygulamada Windows Task Schedular uygulamasında zamanlanmış görevlerde kullanmak amaçlı TaskRunMSA adında bir adet servis hesabı oluşturacağız:

         TaskRunMSA

New-ADServiceAccount -Name TaskRunMSA -DNSHostName MSTDC01.mesutaladag.local -PrincipalsAllowedToRetrieveManagedPassword "ServisHesaplari”

NOT : Bu aşamada “Key Does Not Exist” hatası alırsanız bunun nedeni birinci adımın atlanması yani Root Key oluşturulmamasındandır.

Bu adımdan sonrasında active directory içerisinde Managed Service Accounts kabı içerisinde ilgili servis hesaplarına ait nesneler oluşmuş olacaktır:

4.      gMSA Hesabının Sunucular Üzerinde Yapılandırılması:

Öncelikle MSTDC01 isimli sunucu üzerine active directory içerisinde oluşturmuş olduğum Gmsa servis hesabının yüklenmesi ve testini aşağıdaki adımlarla gerçekleştireceğiz.

Install-ADServiceAccount komutunu kullanabilmek için sunucular üzerinde Active Directory PowerShell modülünün yüklü olması gerekir. Benim domain controller sunucumda bu modül yüklü olduğu için herhangi bir işlem yapmıyorum. Fakat domain içerisindeki üye olan sunucular üzerinde böyle bir modül yüklü olmadığı durumlar için öncelikle aşağıdaki şekilde görüldüğü gibi Install-WindowsFeaturekomutu ile bunun yüklenmesini gerçekleştirmeniz gerekiyor. Bu yüklemeyi Server Manager konsolundan Add Roles and Features sihirbazı ile grafiksel arayüzden de gerçekleştirebilirsiniz:

Şimdi de Install-ADServiceAccount TestRunMSA komutu ile kullanacağımız servis hesabını ilgisi sunucu üzerine yüklüyoruz.

Not: Install-ADServiceAccount komutu ile yüklemede başarısız olursanız ilgili sunucunun yeniden başlatılarak gruba üye özelliğinin etkin hale gelmesi noktasını burada tekrar hatırlatmış olalım.

Yukarıdaki şekilde görüldüğü gibi artık servis hesabını da yüklemiş olduk. Yükleme işlemi sonrasında Test-ADServiceAccount komutu ile de servis hesabının yüklenmesini doğrulayabilirsiniz.

Bu komut sonrası çıktıda True sonucu ile servis hesabının başarıyla yüklendiğini doğrulamış olduk. Sıra geldi servis hesabını ilgili servis ya da görev üzerinde kullanmaya.

Bu işlem için de öncelikle Windows Services konsolunu açıyoruz. Örnek olarak Windows Internal Database servisinin Properties’ine giriyoruz ve Logon tabına geçiyoruz. Browse butonuna tıklayarak oluşturmuş olduğumuz TaskRunMSA servis hesabını gösteriyoruz.

Password ve Confirm Password kutularını boş bırakarak, Apply ile onaylıyoruz. Böylece servis hesabına ilgili servis üzerinde gerekli yetkiler tanımlanmış oluyor.

General tabına geçerek servisi Start ya da Restart ile yeni servis hesabı üzerinden çalışmasını tetikliyoruz. Bu aşamada bu bilgisayar Windows 2012 R2 ya da Windows 2012 domain controller ile iletişime geçerek servis hesabına ait şifreyi temin ediyor ve servis üzerinde bunu set ederek çalıştırıyor. Artık Windows Internal Database servisi oluşturmuş olduğumuz Gmsa servis hesabı ile çalışmaya başladı. Bundan böyle bu servis hesabının şifre yönetimini Windows işletim sistemi üzerinde ilgili bilgisayarın hesabı ile domain controller sunucu bilgisayarının hesabı karşılıklı haberleşerek gerçekleştirmiş olacaklar.

Windows Task Schedule İle Yönetilen Servis Hesaplarının Kullanımı:

Yukarıda bir Windows servisi üzerinde yönetilen servis hesabının yapılandırmasını adım adım nasıl yapıldığını inceledik. Şimdi de bir zamanlanmış görev üzerinde “Run As Account” olarak yönetilen servis hesabının kullanımını görelim.

Öncelikle yukarıdaki adımların benzerini gerçekleştirerek “RunAsAccount” isimli bir servis hesabı oluşturuyoruz:

Bu hesabı ilgili sunucu üzerine Install ediyoruz.

Şimdi de bu hesabın bir task üzerinde kullanımını görelim. Zamanlanmış görevlerde yönetilen servis hesaplarının yapılandırması grafiksel Task Scheduler uygulama arayüzünden desteklenmemektedir. PowerShell komut satırı aracı ile hazırlanan zamanlanmış görevlerde yönetilen servis hesabı yapılandırılabilir. Örneğin C: sürücüsü içerisinde düzenli çalışan “RunScript.cmd” isimli bir çalıştırılabilir komut dosyasını yönetilen servis hesabına ilişkilendirerek nasıl programladığımızı adım adım gerçekleştirelim:

Yukarıdaki $kullanici değişkenine atanan kullanıcı hesabı oluşturmuş olduğumuz RunAsAccount isimli yönetilen servis hesabıdır. Burada LogonType parametresinden sonraki Password ifadesi gerçek şifre değildir, servis hesabına ait şifrenin domain controller sunucusundan talep edileceğini belirtmektedir.

Şimdi bu parametreleri kullanarak bir zamanlanmış görev tanımlayalım. Bu işlem için de Register-ScheduledTask isimli powershell komutunu kullanıyoruz.

Bu işlem sonrasında Task Scheduler konsolu içerisine oluşturduğumuz zamanlanmış görevin geldiğini göreceksiniz:

Bundan böyle bu zamanlanmış görev yönetilen servis hesabı ile çalışacak ve bu hesabın şifre yönetimi de sunucuya ait bilgisayar hesabı ile domain controller arasındaki iletişimle otomatik olarak yönetilmiş olacaktır. Task scheduler konsolunda listelenen bu zamanlanmış görevle ilgili değişikliklerin yine PowerShell komut satırı ile gerçekleştirilmesi gerekir.

ÖNEMLİ : Zamanlanmış toplu işlem komutları ya da script dosyalarını yukarıdaki olduğu gibi yönetilen servis hesabı ile çalıştırılması senaryolarında, yönetilen servis hesabının ilgili sunucu ya da sunucular üzerinde “Logon as a batch” yetkisine sahip olması gerekir.

Logon as a batch yetkisini sunucunun Local Security Policy ayarlarından ya da active directory içerisinde sunucuya uygulanan Group Policy ayarları içerisinde Computer Configuration altında User Rights Assignment altından verebilirsiniz. Varsayılan olarak Administrators ve Backup Operators grupları bu yetkiye sahiptir. Yönetilen servis hesabını bu gruplara üye yaparak da yetki tanımını gerçekleştirebilirsiniz.

Üçüncü Parti GUI gMSA Yönetim Aracı

Şu ana kadar gMSA yönetimini hep PowerShell komut satırı uygulamaları ile gerçekleştirmiştik. Şimdi de free olarak yazılmış olan ve http://www.cjwdev.co.uk/Software/MSAGUI/Info.html adresinden indirebileceğiniz grafiksel yönetim aracını da kullanabilirsiniz:

Bu aracı indirdikten sonra Windows Server 2012 R2 sunucumuza yüklüyoruz.

Uygulama kurulduktan sonra çalıştırdığınızda aşağıdaki şekilde ekran karşımıza gelecektir.

Bu ekranda hali hazırda mesutaladag.local domaininde oluşturulan yönetilen servis hesaplarının listelendiğini göreceksiniz. Şimdi adım adım bu aracı kullanarak Group-Managed yönetilen servis hesabının yönetimini nasıl yaptığımız inceleyelim:

Öncelikle New butonuna tıklıyoruz.

Karşımıza gelen New Managed Service Account ekranında aşağıdaki şekilde bir ClustergMSA01 isimli servis hesabı tanımını giriyoruz. Hesabin oluşturulacağı kap olarak Managed Service Account varsayılan konumu yerine farklı bir organizational unit de gösterebilirsiniz. Hesap tipi olarak da Group MSA seçiyoruz.

Additional Options butonu genişletilerek hesap için son kullanma tarihi ve SPN tanımlarını da yine burdan girebilirsiniz.

OK ile onaylayarak servis hesabı oluşturma işlemini tamamlamış olacaksınız. Karşımıza gelen Associate With Computer ekranında oluşturulan servis hesabını active directory domain içerisinde bir bilgisayara atama yapıp yapmayacağımızı soracaktır.

Yes ile onaylıyoruz. Karşımıza gelen Edit Group MSA Hosts ekranında Add butonu kullanarak servis hesabının atanacağı bilgisayar hesabı gösterilir. Ben cluster yapıda çalışan SQL01 ve SQL02 hesaplarını sırayla ADD butonunu kullanarak ekliyorum.

OK ile tüm pencereler onaylanır. Ve başarıyla atamanın gerçekleştiği bilgisi gelecektir.

OK ile bu ekranı kapattıktan sonra listeye oluşturduğumuz gMSA hesabı gelmiş olacaktır.

Bu aşamadan sonra kalan tek adım ilgili sunucuya gidip bu servis hesabını ilgili uygulamaya tanımlamak olacaktır. SQL Cluster yapısının kurulu olduğu sunucularımdan ilkine bağlanıyorum. Windows Services konsolunu kullanarak aşağıdaki şekilde görüldüğü gibi oluşturduğumuz ClusterMSA01$ hesabını gösteriyorum.

Password ve Confirm Password kutucuklarını boşaltıyoruz. Şifre atamasını arka planda active directory domain controller sunucu ile iletişime geçerek sunucu kendisi yapacaktır. OK ile onayladıktan sonra yapmanız gereken servisi yeniden başlatmaktır. Servisi yeniden başlattığınız herhangi bir hata almadan sorunsuz başlattı ise cluster’ın ilk node’u üzerindeki işimiz bitti. İkinci node’a bağlanarak aynı işlemleri sırayla onun üzerinde de gerçekleştiriyoruz.

Eğer servisi yeniden başlattığınızda aşağıdaki gibi bir hata mesajı alırsanız bunun çözümü için sunucunun Local Security Policy konsolunda User Rights Management altından “Logon as a Service” yetkisini vermeniz gerekir.

Managed Service Accounts GUI aracı ile aşağıdaki araç çubuğu kısayolları kullanılarak farklı görevleri de yerine getirebilirsiniz:

Edit Hosts : Yönetilen servis hesabının ilişkili olduğu sunucu listesine eklemeye ya da listeden çıkarma yapılabilir.

View/Edit : Yönetilen servis hesabının özelliklerini görüntüleme ve düzenleme işlemleri.

Delete : Yönetilen servis hesabının active directory içerisinden tamamen silinmesi.

SONUÇ

Toplamda iki bölümden oluşacak makale serimizin ikinci bölümünün de sonuna geldik. Bu bölümde sizlerle Windows Server 2012 R2 ile Group Manager Service Accounts(gMSA) oluşturma, yapılandırma ve test adımlarını uygulamalı olarak paylaştık. Bir başka Windows Server 2012 R2 makalesinde görüşmek dileğiyle esenkalın.

Bu makalemizde de sizlere mevcut Windows Server 2003 R2 ortamında kullanılan DHCP Server altyapısının Windows Server 2012 R2 DHCP mimarisine yükseltilmesi yani migration adımlarını adım adım uygulamalı olarak gerçekleştiriyor olacağım. Microsoft Windows Server DHCP servisi ağ ortamındaki istemci bilgisayarlarına, sunucu sistemlerine ve ağ cihazlarına ip adresi, alt ağ maskesi (subnet mask), varsayılan ağ geçidi (default gateway), DNS Sunucu adresleri vb gibi TCP/IP  konfigürasyon bilgilerini merkezi olarak dağıtan bileşen olduğunu önceki Windows Server sürümlerine ait makalelerimizde detaylı olarak paylaşmıştık.

DHCP Server sahip olduğu sorumluluk itibariyle ağınızdaki kritik sunucu rollerinden biridir. Dolayısıyla DHCP servisi rolüne sahip sunucu rolünün herhangi bir şekilde ulaşılamaması ya da devre dışı kalması durumunda ağdaki kullanıcılara ya da cihazlara TCP/IP konfigürasyonunun dağıtılmasında kesintiler yaşama ihtimalinizden dolayı yapınızdaki iletişim de bu durumda olumsuz etkilenecektir. Dolaysıyla özellikle domain ya da sadece DHCP sunucularının migration aşamalarını son derece dikkatli ve sorunsuz gerçekleştirmek, mevcut yapılandırmayı olduğu gibi Windows Server 2012 R2 versiyonuna aktarmak ve işler bir yapıda sonlandırmak büyük önem arz ediyor.

Şu ana kadar DHCP konusunda aşağıdaki makalelerle size detaylı bilgileri aktarmıştım:

Windows Server 2012 DHCP Failover
Windows Server 2012 R2 DHCP Failover

Bu makalemde de Windows Server 2003 R2 DHCP Rolünün Windows Server 2012 R2 DHCP Rolüne Yükseltilmesini Migration yöntemi ile adım adım inceliyor olacağız.

Şimdi bu açıklamalardan sonra uygulamalara geçelim.

Lab Altyapısı:

Öncelikle mevcut yapımızı tanıyalım:

Yukarıdaki şekilde de görüldüğü üzere COZUMPARK.LOCAL isimli bir active directory domain yapımız var.  Benim Windows 2003 R2 eğitim ortamımda kullanmış olduğum domain controller sunucusu üzerinde DHCP rolünü yine Windows Server 2012 R2 üzerindeki DHCP servisine taşıyacağım. Gerçek dünyada da domain controller sunucular üzerinde DHCP rolünü de konumlandıran çok sayıda organizasyonla karşılaşabilirsiniz. Elbette best-practice olan mümkün olduğunca servisleri ya da sunucu rollerini farklı sunuculara ayırmaktır. Fakat ayrı ayrı sunucular kurmadan aynı sunucu üzerinde de burada olduğu gibi birden fazla rolü kullanan senaryolar da pek az sayılmaz.

Mevcut Windows Server 2003 sunucumuz ile ilgili ekran çıktılarını aşağıda görmektesiniz:

Sunucumuz Windows Server 2003 R2 x86 mimarisinde çalışmaktadır.

Sunucu adımız POSTA ve domain adımız cozumpark.local domainidir.

DHCP konsolunda aşağıdaki şekilde görüldüğü gibi 172.16.0.0 adres havuzumuz bulunmaktadır. Şu aktif olarak kullanıcılarımıza bu havuzdan ip dağıtımı yapılmaktadır.

Scope ve Server seçenekleri aşağıdaki şekilde görüldüğü gibi DNS Server, Default Gateway (Router) ve Domain Adı bilgilerini dağıtacak şekilde yapılandırılmıştır.

Aktif olarak bu şekilde kullanılan DHCP sunucumuzu şimdi adım adım Windows Server 2012 R2 işletim sistemine Migration yöntemi ile taşıyacağız.

DHCP rolünün yükseltilmesinde iki farklı aracı kullanabiliriz:

·         NETSH

·         PowerShell CmdLet

NETSH komutu eski Windows versiyonlarından bu yana kullanılırken, günümüzde yerini artık yavaş yavaş PowerShell CmdLet’lere bırakmıştır. Biz makalemizde NETSH yöntemi ile ilerliyor olacağız.

Windows Server 2003 Sistem Üzerinde Yapılacak Ön Hazırlıklar:

Windows Server 2003 R2 sunucumuz üzerinde komut satırını lokal Administrators grubuna üyeliği olan bir kullanıcı ile logon olup başlatıyoruz:

NETSH komutlarını aşağıdaki sırayla çalıştırıyoruz:

·         NETSH

·         DHCP

·         SERVER \\POSTA

·         EXPORT C:\DHCPYedek\dhcpexport all

·         Exit

Böylece C:\DHCPYedek klasörü altına dhcpexport adında bir dosyaya DHCP verilerinin yedeğini almış olduk.

Not: NETSH yerine PowerShell komut satırından Export-DHCPServer cmdlet ile de kaynak sunucudaki DHCP scope bilgilerini bir dosyaya aktarabilirsiniz.

Bu alınan yedeği Windows Server 2012 R2 sunucumuza kopyalıyoruz ve Windows Server 2012 R2 sunucumuz üzerinde DHCP yapılandırması ve DHCP verilerinin aktarımını gerçekleştireceğiz.

Windows Server 2012 R2 Sistem Üzerinde Yapılacak Ön Hazırlıklar:

Sunucumuzu aşağıdaki listede görülen hazırlıklarını öncelikle tamamlıyoruz:

·         Sunucu adının belirlenmesi

·         Sunucu ip adresi, subnet mask, default gateway ve DNS adresi gibi TCP/IP ayarlarının yapılandırılması

·         Sunucunun Windows Server 2012 R2 işletim sistemi güncellemelerinin tamamlanması

·         Sunucu üzerinde Windows Firewall’un devre dışı bırakılması

·         Sunucunun cozumpark.local domainine üye yapılması

·         Sunucu üzerine Windows Server 2003 R2 DHCP sunucudan alınan yedeğin kopyalanması

Yukarıdaki hazırlıklar tamamlandıktan sonra sıra geldi DHCP Rolünün kurulmasına. Bu işlem için ister grafiksel arayüzden Server Manager konsolundan Manage menüsünden Add Roles and Features kısayolunu kullanabilirsiniz, isterseniz de PowerShell komut satırından Install-WindowsFeatures cmdlet kullanabilirsiniz.

Server Manager arayüzünden Add Roles and Features sihirbazını başlattıktan sonra Before you begin aşamasını Next ile geçiyoruz.

Select installation type ekranında Role-based or feature-based installation seçeneğini seçip Next ile ilerliyoruz:

Select destination server ekranında alt kısımdan sunucu ismimizin seçili olduğundan emin olduktan sonra Next ile sonraki adıma devam ediyoruz.

Select Server Roles ekranında DHCP Server rolünü ve ilgili feature’larını Add Features ile yüklüyoruz.

Next ile ilerliyoruz. Select features ekranında ilave bir feature yüklemeyeceğimiz için Next ile sonraki adıma devam ediyoruz.

Karşımıza gelen DHCP Server bilgilendirme ekranını Next ile geçiyorum.

Rolün kurulumu sonrası sunucunun yeniden başlatılması gereksinim varsa otomatik başlatması için aşağıdaki şekilde görülen Restart ile başlayan kutucuğu da işaretleyip gelen onay penceresini Yes ile onaylıyoruz.

Install ile kurulum sürecini başlatıyoruz.

DHCP Server rolü ve ilgili feature kurulumları tamamlandıktan sonra yapılandırma sihirbazı karşımıza gelecektir. Complete DHCP Configuration ile sihirbazı başlatıyoruz.

Description ekranında sihizbaz adımlarında gerçekleştirilecek aksiyonları bahsediyor.

Next ile ilerliyoruz.

DHCP Sunucunun TCP/IP bilgilerini dağıtması amacıyla active directory içerisinde yetkilendirilmesi gerekir ki bu işleme de Authorize adını veriyoruz. Bu amacı gerçekleştirirken kullanılacak hesabı gösteriyoruz:

Commit ile süreci onaylıyoruz. Summary ekranında başarıyla sürecin tamamlandığına dair onayı alıyoruz.

Close ile DHCP rolünün kurulum aşamalarını tamamlamış olduk.

DHCP Rolünü ve ilgili feature’ların kurulumunu Server Manager grafiksel arayüzü yerine PowerShell komut satırını kullanarak da Install-WindowsFeature komutu ile aşağıdaki şekilde gerçekleştirebilirsiniz:

Rol ve feature kurulumlarından sonra yapacağımız ilk iş öncelikle DHCP Server servisini durdurmak. Bu işlemi de ister grafiksel arayüzden Services konsolunu kullanarak isterseniz de komut satırından net stop DHCPServer ya da stop-service DHCPServer komutları ile gerçekleştirebiliriz.

Servisi durduktan sonra Windows\System32\DHCP klasörü içerisindeki DHCP.mdb dosyasını siliyoruz.

Silme işleminden sonra DHCPServer servisini tekrar başlatıyoruz, böylece yeni bir DHCP.mdb veritabanı dosyasının otomatik olarak oluştuğunu göreceksiniz.

Şimdi geldik Windows Server 2003 R2 üzerinden aldığımız DHCP yedeğinin geri yüklenmesine bu işlem için de komut satırından NETSH aracını kullanacağız. Windows Server 2012 R2 sunucumuz üzerinden CMD komut satırına düşüp sırayla aşağıdaki komutları çalışıtıyoruz:

·         NETSH

·         DHCP

·         SERVER \\Sunucuadi

·         IMPORT C:\DHCPYedek\dhcpexport

DHCP yedeğinin başarıyla geri yüklenmesinden sonra ilgili mesaj yukarıdaki şekilde görüldüğü gibi gelecektir. Exit ile komut satırından çıkıyoruz.

Not: NETSH yerine PowerShell komut satırından Import-DHCPServer cmdlet ile de DHCP scope bilgilerini bir dosyadan alabilirsiniz.

Tekrar DHCPServer servisini yeniden başlatıyoruz:

Şimdi de DHCP Server konsolunu açıp Windows Server 2003 R2’deki yedeklenen yapılandırmaların geldiğini kontrol ediyoruz.

Böylece genel olarak DHCP veritabanının ve yapılandırmasının Windows Server 2012 R2 işletim sistemine geçişini tamamlamış olduk.

Bu aşamadan sonra eski Windows Server 2003 R2 üzerindeki DHCP Servisini durdurup, DHCP Server servisini de Disabled konumuna getirin. Birkaç gün yeni Windows Server 2012 R2 DHCP sunucu ile çalıştıktan ve artık herhangi bir sorun yaşamadığınızdan emin olduktan sonra Windows Server 2003 R2 üzerinden DHCP Server servisini ve rolünü tamamen kaldırabilirsiniz.

Eski Windows Server 2003 R2 DHCP Server sunucusundan ip bilgilerini alan istemciler, sistemler ya da aygıtlar yenileme zamanı geldiğinde (IP Renewal) eski Windows Server 2003 R2 sunucuya ulaşamayacakları için kira süresi sonunda artık isteklerinin Windows Server 2012 R2 DHCP sunucusu karşılayacaktır. Bu süreci hızlandırmak ya da kira sürecini beklemeden Windows Server 2012 R2 DHCP sunucu üzerine entegrasyon için sistemleri yeniden başlatabilir ya da manuel olarak IPCONFIG /RELEASE, IPCONFIG /RENEW komutlarını sırasıyla çalıştırarak yeni Windows Server 2012 R2 sunucuya entegrasyon sağlanabilir.

Bir diğer yandan DHCP Server’ın ip adresi artık değiştiği için özellikle 802.1X kullanan yapılar yapılar için Controller cihazları üzerindeki tanımlarda Wireless ağlara ip dağıtıcı DHCP Server adresi olarak yeni Windows Server 2012 R2 sunucunun ip adresini tanımlamak gerekecektir.

Yine farklı VLAN ya da lokasyonlara ip dağıtımında router cihazları üzerinde ip helper address tanımlarında yine yeni Windows Server 2012 R2 DHCP sunucunun ip adresinin tanımlanması gerekir.

Bir diğer önemli nokta da mevcut yapınızdaki ağ cihazlarının ve özellikle 802.1x Access Control Cihaz ve Uygulamalarının Windows Server 2012 R2 domain yapısı ve Windows Server 2012 R2 DHCP Server ile entegrasyon desteğinin olup olmadığının araştırılması da en önemli noktalardan. Muhtemelen özellikle Windows Server 2012 R2 DHCP Server ile birlikte çalışabilmesi için Firmware güncellemesi vb. hazırlıkların yukarıdaki geçiş adımları öncesinde kontrol edilmesi gerekecektir.

Ayrıca Windows Server 2012 R2 DHCP Server geçişi sonrasında hem yedeklilik hem de yük dağılımı amacıyla ikinci bir Windows Server 2012 R2 DHCP Server daha yapılandırıp bu iki sunucuyu DHCP Failover mimarisinde yapılandırmanızı da özellikle öneriyorum. Bu konuda adım adım uygulama detaylarıyla ilgili olarak aşağıdaki makalelerimizi incelemenizi tavsiye ederim.

Windows Server 2012 DHCP Failover
Windows Server 2012 R2 DHCP Failover

Sonuç Olarak;

Bu makalemizde sizlerle Windows Server 2003 DHCP Rolünün Windows Server 2012 R2 DHCP Rolüne Yükseltilmesini Migration yöntemi ile adım adım detaylarıyla inceledik. Bir başka makalemizde görüşmek üzere hoşçakalın.

Bu makalemizde de sizlere mevcut Windows Server 2008 R2 ortamında kullanılan DHCP Server altyapısının Windows Server 2012 R2 DHCP mimarisine yükseltilmesi yani migration adımlarını adım adım uygulamalı olarak gerçekleştiriyor olacağım. Microsoft Windows Server DHCP servisi ağ ortamındaki istemci bilgisayarlarına, sunucu sistemlerine ve ağ cihazlarına ip adresi, alt ağ maskesi (subnet mask), varsayılan ağ geçidi (default gateway), DNS Sunucu adresleri vb gibi TCP/IP  konfigürasyon bilgilerini merkezi olarak dağıtan bileşen olduğunu önceki Windows Server sürümlerine ait makalelerimizde detaylı olarak paylaşmıştık.

DHCP Server sahip olduğu sorumluluk itibariyle ağınızdaki kritik sunucu rollerinden biridir. Dolayısıyla DHCP servisi rolüne sahip sunucu rolünün herhangi bir şekilde ulaşılamaması ya da devre dışı kalması durumunda ağdaki kullanıcılara ya da cihazlara TCP/IP konfigürasyonunun dağıtılmasında kesintiler yaşama ihtimalinizden dolayı yapınızdaki iletişim de bu durumda olumsuz etkilenecektir. Dolaysıyla özellikle domain ya da sadece DHCP sunucularının migration aşamalarını son derece dikkatli ve sorunsuz gerçekleştirmek, mevcut yapılandırmayı olduğu gibi Windows Server 2012 R2 versiyonuna aktarmak ve işler bir yapıda sonlandırmak büyük önem arzediyor.

Şu ana kadar DHCP konusunda aşağıdaki makalelerle size detaylı bilgileri aktarmıştım:

Windows Server 2012 DHCP Failover
Windows Server 2012 R2 DHCP Failover

Bu makalemde de Windows Server 2008 R2 DHCP Rolünün Windows Server 2012 R2 DHCP Rolüne Yükseltilmesini Migration yöntemi ile adım adım inceliyor olacağız.

Şimdi bu açıklamalardan sonra uygulamalara geçelim.

Lab Altyapısı:

Öncelikle mevcut yapımızı tanıyalım:

Yukarıdaki şekilde de görüldüğü üzere COZUMPARK.LOCAL isimli bir active directory domain yapımız var.  Benim Windows 2008 R2 eğitim ortamımda kullanmış olduğum domain controller sunucusu üzerinde DHCP rolünü yine Windows Server 2012 R2 üzerindeki DHCP servisine taşıyacağım. Gerçek dünyada da domain controller sunucular üzerinde DHCP rolünü de konumlandıran çok sayıda organizasyonla karşılaşabilirsiniz. Elbette best-practice olan mümkün olduğunca servisleri ya da sunucu rollerini farklı sunuculara ayırmaktır. Fakat ayrı ayrı sunucular kurmadan aynı sunucu üzerinde de burada olduğu gibi birden fazla rolü kullanan senaryolar da pek az sayılmaz.

Mevcut Windows Server 2008 R2 sunucumuz ile ilgili ekran çıktılarını aşağıda görmektesiniz:

Sunucumuz Windows Server 2008 R2 x64 mimarisinde çalışmaktadır.

DHCP konsolunda aşağıdaki şekilde görüldüğü gibi 172.16.0.0 adres havuzumuz bulunmaktadır. Şu aktif olarak kullanıcılarımıza bu havuzdan ip dağıtımı yapılmaktadır.

Scope ve Server seçenekleri yukarıdaki şekilde görüldüğü gibi DNS Server, Default Gateway (Router) ve Domain Adı bilgilerini dağıtacak şekilde yapılandırılmıştır.

Aktif olarak bu şekilde kullanılan DHCP sunucumuzu şimdi adım adım Windows Server 2012 R2 işletim sistemine Migration yöntemi ile taşıyacağız.

DHCP rolünün yükseltilmesinde iki farklı aracı kullanabiliriz:

·         NETSH

·         PowerShell CmdLet

NETSH komutu eski Windows versiyonlarından bu yana kullanılırken, günümüzde yerini artık yavaş yavaş PowerShell CmdLet’lere bırakmıştır. Biz makalemizde NETSH yöntemi ile ilerliyor olacağız.

Windows Server 2008 R2 Sistem Üzerinde Yapılacak Ön Hazırlıklar:

Windows Server 2008 R2 sunucumuz üzerinde komut satırını lokal Administrators grubuna üyeliği olan bir kullanıcı ile logon olup başlatıyoruz:

NETSH komutlarını aşağıdaki sırayla çalıştırıyoruz:

·         NETSH

·         DHCP

·         SERVER \\POSTA

·         EXPORT C:\DHCPYedek\dhcpexport all

·         Exit

Not: NETSH yerine PowerShell komut satırından Export-DHCPServer cmdlet ile de kaynak sunucudaki DHCP scope bilgilerini bir dosyaya aktarabilirsiniz.

Böylece C:\DHCPYedek klasörü altına dhcpexport adında bir dosyaya DHCP verilerinin yedeğini almış olduk.

Bu alınan yedeği Windows Server 2012 R2 sunucumuza kopyalıyoruz ve Windows Server 2012 R2 sunucumuz üzerinde DHCP yapılandırması ve DHCP verilerinin aktarımını gerçekleştireceğiz.

Windows Server 2012 R2 Sistem Üzerinde Yapılacak Ön Hazırlıklar:

Sunucumuzu aşağıdaki listede görülen hazırlıklarını öncelikle tamamlıyoruz:

·         Sunucu adının belirlenmesi

·         Sunucu ip adresi, subnet mask, default gateway ve DNS adresi gibi TCP/IP ayarlarının yapılandırılması

·         Sunucunun Windows Server 2012 R2 işletim sistemi güncellemelerinin tamamlanması

·         Sunucu üzerinde Windows Firewall’un devre dışı bırakılması

·         Sunucunun cozumpark.local domainine üye yapılması

·         Sunucu üzerine Windows Server 2008 R2 DHCP sunucudan alınan yedeğin kopyalanması

Yukarıdaki hazırlıklar tamamlandıktan sonra sıra geldi DHCP Rolünün kurulmasına. Bu işlem için ister grafiksel arayüzden Server Manager konsolundan Manage menüsünden Add Roles and Features kısayolunu kullanabilirsiniz, isterseniz de PowerShell komut satırından Install-WindowsFeatures cmdlet kullanabilirsiniz.

Server Manager arayüzünden Add Roles and Features sihirbazını başlattıktan sonra Before you begin aşamasını Next ile geçiyoruz.

Select installation type ekranında Role-based or feature-based installation seçeneğini seçip Next ile ilerliyoruz:

Select destination server ekranında alt kısımdan sunucu ismimizin seçili olduğundan emin olduktan sonra Next ile sonraki adıma devam ediyoruz.

Select Server Roles ekranında DHCP Server rolünü ve ilgili feature’larını Add Features ile yüklüyoruz.

Next ile ilerliyoruz. Select features ekranında ilave bir feature yüklemeyeceğimiz için Next ile sonraki adıma devam ediyoruz.

Karşımıza gelen DHCP Server bilgilendirme ekranını Next ile geçiyorum.

Rolün kurulumu sonrası sunucunun yeniden başlatılması gereksinim varsa otomatik başlatması için aşağıdaki şekilde görülen Restart ile başlayan kutucuğu da işaretleyip gelen onay penceresini Yes ile onaylıyoruz.

Install ile kurulum sürecini başlatıyoruz.

DHCP Server rolü ve ilgili feature kurulumları tamamlandıktan sonra yapılandırma sihirbazı karşımıza gelecektir. Complete DHCP Configuration ile sihirbazı başlatıyoruz.

Description ekranında sihizbaz adımlarında gerçekleştirilecek aksiyonları bahsediyor.

Next ile ilerliyoruz.

DHCP Sunucunun TCP/IP bilgilerini dağıtması amacıyla active directory içerisinde yetkilendirilmesi gerekir ki bu işleme de Authorize adını veriyoruz. Bu amacı gerçekleştirirken kullanılacak hesabı gösteriyoruz:

Commit ile süreci onaylıyoruz. Summary ekranında başarıyla sürecin tamamlandığına dair onayı alıyoruz.

Close ile DHCP rolünün kurulum aşamalarını tamamlamış olduk.

DHCP Rolünü ve ilgili feature’ların kurulumunu Server Manager grafiksel arayüzü yerine PowerShell komut satırını kullanarak da Install-WindowsFeature komutu ile aşağıdaki şekilde gerçekleştirebilirsiniz:

Rol ve feature kurulumlarından sonra yapacağımız ilk iş öncelikle DHCP Server servisini durdurmak. Bu işlemi de ister grafiksel arayüzden Services konsolunu kullanarak isterseniz de komut satırından net stop DHCPServer ya da stop-service DHCPServer komutları ile gerçekleştirebiliriz.

Servisi durduktan sonra Windows\System32\DHCP klasörü içerisindeki DHCP.mdb dosyasını siliyoruz.

Silme işleminden sonra DHCPServer servisini tekrar başlatıyoruz, böylece yeni bir DHCP.mdb veritabanı dosyasının otomatik olarak oluştuğunu göreceksiniz.

Şimdi geldik Windows Server 2008 R2 üzerinden aldığımız DHCP yedeğinin geri yüklenmesine bu işlem için de komut satırından NETSH aracını kullanacağız. Windows Server 2012 R2 sunucumuz üzerinden CMD komut satırına düşüp sırayla aşağıdaki komutları çalışıtıyoruz:

·         NETSH

·         DHCP

·         SERVER \\Sunucuadi

·         IMPORT C:\DHCPYedek\dhcpexport

DHCP yedeğinin başarıyla geri yüklenmesinden sonra ilgili mesaj yukarıdaki şekilde görüldüğü gibi gelecektir. Exit ile komut satırından çıkıyoruz.

Not: NETSH yerine PowerShell komut satırından Import-DHCPServer cmdlet ile de DHCP scope bilgilerini bir dosyadan alabilirsiniz.

Tekrar DHCPServer servisini yeniden başlatıyoruz:

Şimdi de DHCP Server konsolunu açıp Windows Server 2008 R2’deki yedeklenen yapılandırmaların geldiğini kontrol ediyoruz.

Böylece genel olarak DHCP veritabanının ve yapılandırmasının Windows Server 2012 R2 işletim sistemine geçişini tamamlamış olduk.

Bu aşamadan sonra eski Windows Server 2008 R2 üzerindeki DHCP Servisini durdurup, DHCP Server servisini de Disabled konumuna getirin. Birkaç gün yeni Windows Server 2012 R2 DHCP sunucu ile çalıştıktan ve artık herhangi bir sorun yaşamadığınızdan emin olduktan sonra Windows Server 2008 R2 üzerinden DHCP Server servisini ve rolünü tamamen kaldırabilirsiniz.

Eski Windows Server 2008 R2 DHCP Server sunucusundan ip bilgilerini alan istemciler, sistemler ya da aygıtlar yenileme zamanı geldiğinde (IP Renewal) eski Windows Server 2008 R2 sunucuya ulaşamayacakları için kira süresi sonunda artık isteklerinin Windows Server 2012 R2 DHCP sunucusu karşılayacaktır. Bu süreci hızlandırmak ya da kira sürecini beklemeden Windows Server 2012 R2 DHCP sunucu üzerine entegrasyon için sistemleri yeniden başlatabilir ya da manuel olarak IPCONFIG /RELEASE, IPCONFIG /RENEW komutlarını sırasıyla çalıştırarak yeni Windows Server 2012 R2 sunucuya entegrasyon sağlanabilir.

Bir diğer yandan DHCP Server’ın ip adresi artık değiştiği için özellikle 802.1X kullanan yapılar yapılar için Controller cihazları üzerindeki tanımlarda Wireless ağlara ip dağıtıcı DHCP Server adresi olarak yeni Windows Server 2012 R2 sunucunun ip adresini tanımlamak gerekecektir.

Yine farklı VLAN ya da lokasyonlara ip dağıtımında router cihazları üzerinde ip helper address tanımlarında yine yeni Windows Server 2012 R2 DHCP sunucunun ip adresinin tanımlanması gerekir.

Bir diğer önemli nokta da mevcut yapınızdaki ağ cihazlarının ve özellikle 802.1x Access Control Cihaz ve Uygulamalarının Windows Server 2012 R2 domain yapısı ve Windows Server 2012 R2 DHCP Server ile entegrasyon desteğinin olup olmadığının araştırılması da en önemli noktalardan. Muhtemelen özellikle Windows Server 2012 R2 DHCP Server ile birlikte çalışabilmesi için Firmware güncellemesi vb. hazırlıkların yukarıdaki geçiş adımları öncesinde kontrol edilmesi gerekecektir.

Ayrıca Windows Server 2012 R2 DHCP Server geçişi sonrasında hem yedeklilik hem de yük dağılımı amacıyla ikinci bir Windows Server 2012 R2 DHCP Server daha yapılandırıp bu iki sunucuyu DHCP Failover mimarisinde yapılandırmanızı da özellikle öneriyorum. Bu konuda adım adım uygulama detaylarıyla ilgili olarak aşağıdaki makalelerimizi incelemenizi tavsiye ederim.

Windows Server 2012 DHCP Failover
Windows Server 2012 R2 DHCP Failover

Sonuç Olarak;

Bu makalemizde sizlerle Windows Server 2008 R2 DHCP Rolünün Windows Server 2012 R2 DHCP Rolüne Yükseltilmesini Migration yöntemi ile adım adım detaylarıyla inceledik. Bir başka makalemizde görüşmek üzere hoşçakalın.

Windows Server 2012 R2 sunucu işletim sistemi çıkış süresi üzerinden yaklaşık bir yıl gibi bir süre geçti.  Windows Server 2012 ile başlayan bulut-tabanlı işletim sistemi geliştirme süreci Windows Server 2012 R2 ile beraber bir adım daha ileri taşınarak buluta entegre kabiliyetler artırılmış ve yönetilebilirlik alanında da bulut-tabanlı yönetim servisleri, geliştirme platformları bu yeni sürümle daha da güçlendirilmiştir. Bildiğiniz gibi Microsoft’un yeni nesil sunucu işletim sistemi ve bu sistemleri uçtan-uca yönetim platformlarını da içine alan yeni bir vizyonu var : Cloud OS yani Bulut İşletim Sistemi. Bulut işletim sistemi sunucu tarafında Windows Server 2012 R2 ve yönetim alanında da System Center 2012 R2’nin birlikte oluşturmuş olduğu yeni nesil platform. Bu yeni vizyonla, özellikle sunucu sistemlerinde sadece sanallaştırma katmanı değil bu katmanı yöneten ilave yönetim ve orkestrasyon araçları ile sanal sistemlerin bulut-mimarisinde kurulumu, yönetimi, temel işletim sistemi fonksiyonlarının izlenmesi gibi yetenekler hem Windows Server 2012 R2 hem de System Center 2012 R2 sürümleri ile sunulmaktadır. Benzer şekilde istemci tarafında da yine Windows 8.1 sürümü ile gerek mobilite, gerekse de bulut-tabanlı uygulamalara, servislere erişim, mobil cihaz arayüzlerinden bu uygulamaların kullanımına yönelik çok daha yeni ve zengin yetenekler de beraberinde geliyor. Biz de bulut işletim sisteminin yeniliklerini tüm detaylarıyla sizlerle paylaşmaya devam ediyoruz.

Windows Server 2012 R2 Active Directory İle Teknolojide Yeni Trendler makalemizde sizlerle Active Directory entegrasyonunda gelen mobilite alanındaki BYOD özelliklerini genel olarak incelemiştik. Ayrıca özellikle Windows Server 2012 active directory domain yapıları ile henüz çalışmamış olup, doğrudan Windows Server 2012 öncesi domain yapılarından Windows Server 2012 R2 domain yapısına geçiş yapan ya da yapacak arkadaşlarımın aşağıdaki makale ve video sunumunu da ayrıca incelemelerini tavsiye ederim. Zira, Windows Server 2012 öncesine göre Windows Server 2012 işletim sistemi ile başlayan süreçte gelen yeni özellikler Windows Server 2012 R2 işletim sistemi üzerinde de geçerli.

Ø  Makale - Windows Server 2012 Active Directory Yenilikleri

Ø  Webcast - Windows Server 2012 Active Directory Yenilikleri

Biz bu makalemizde daha detaylı olarak Windows Server 2012 R2 Active Directory Servislerinde Gelen Yenilikleri inceliyoruz.

Detaylara geçmeden genel olarak maddeler halinde yeni gelen özellikleri sıralayacak olursak:

Ø  Active Directory Domain Servis Yenilikleri

o   Windows Server 2012 R2 Schema Güncellemesi

o   Windows Server 2012 R2 Forest ve Domain Fonksiyonel Seviyeleri

o   Protected Users Güvenlik Grubu

o   Authentication Policy ve Silo Yapı Taşları

o   LSASS Bellek Koruma Yeteneği

o   FRS Konusunda Son Gelişmeler

Ø  Active Directory Federasyon Servisleri Yenilikleri

o   OAuth 2.0 Desteği

o   ADFS İçin Soft Account Lockout Desteği

Ø  Active Directory Sertifika Servislerinde Gelen Yeni Özellikler

o   TPM Anahtar Doğrulama Desteği

o   BYOD Amaçlı NDES Yetenekleri

Ø  Active Directory Dijital Hak Yönetim (RMS) Yenilikleri

Ø  Active Directory DNS Yenilikleri

Active Directory Domain Servis Yenilikleri

Windows Server 2012 R2 Schema Güncellemesi

Active directory domain yapılarında, çalışmakta olduğunuz mevcut active directory yapısını bir üst versiyona yükseltmek istiyorsak öncelikle active directory schema versiyonunun güncellenmesi gerekiyor. Bu active directory dizin servisinin ilk versiyonundan bugüne kadar benzerlik gösteren bir operasyon. Bu işlem forest-seviyesinde bir defaya mahsus gerçekleştirilen ve yeni nesne sınıflarını (class), nesne özniteliklerini (attribute) ve nesneleri oluşturan bir güncellemedir.

Windows Server 2012 R2 ile gerçekleştirilecek schema güncellemelerine ait dosya ve scriptler ISO içerisinde support\adprep altında gelmektedir. Normal şartlarda Windows Server 2012 R2 öncesi mevcut bir domaine Windows Server 2012 R2 additional domain controller kurulumu esnasında öncelikle buradaki dosyalar kullanılarak schema güncellemesi yapılır ve daha sonra da o sunucu üzerinde active directory domain servis yapılandırmasına devam edilir. Eğer amaç active directory yapılandırması yapmadan sadece active directory schema güncellemesi yapmaksa bu durumda yine support\adprep klasörü içerisindeki adprep.exe aracı ile eski versiyonlarda olduğu gibi adprep.exe /forestprep , adprep.exe /domainprep /gpprep, adprep.exe /rodcprep komutları uygulanabilir. Burada eskiden farklı olarak adprep aracının sadece 64-bit versiyonunun gelmesidir, artık 32-bit versiyon gelmiyor. Windows Server 2012 R2 ile adprep ile schema güncellemesi için forest içerisindeki tüm domain controller sunucuların Windows Server 2003 ve üzeri versiyonda olmaları gerekir. Bugüne kadarki active directory schema versiyonları:

Ø  Windows 2000 Active Directory (Versiyon 13)

Ø  Windows 2003 Active Directory (Versiyon 30)

Ø  Windows 2003 R2 Active Directory (Versiyon 31)

Ø  Windows 2008 Active Directory (Versiyon 44)

Ø  Windows 2008 R2 Active Directory (Versiyon 47)

Ø  Windows 2012 Active Directory (Versiyon 56)

Ø  Windows 2012 R2 Active Directory (Versiyon 69)

Buradaki versiyon numaraları her işletim sistemi sürümünde gelen dosya güncellemesi sayısından ortaya çıkmıştır. Dolayısıyla son versiyon itibariyle toplamda 69 adet LDF dosyasını kapsamaktadır. Windows Server 2012 R2 ile active directory schema içerisinde msDS-Device isimli yeni bir nesne sınıfı geliyor. Bu sayede Windows Server 2012 R2 ile BYOD(Bring Your Own Device) amaçlı Workplace Join özelliği de kullanılabiliyor olacak.BYOD konusunda Windows Server 2012 R2 Active Directory İle Teknolojide Yeni Trendler makalemizi de inceleyebilirsiniz.

Mevcutta çalışılan schema versiyonunu görüntülemek için dsquery komutunu ya da PowerShell komutlarını da kullanabilirsiniz:

msDS-Device isimli yeni nesne sınıfı içerisindeki özniteliklerden bazıları:

Ø  msDS-IsEnabled: Aygıtın aktif/pasif edilmesi

Ø  msDS-DeviceID: Aygıtın ID kimlik bilgisi

Ø  msDS-DeviceOSType: Aygıtın işletim sistemi tipi

Ø  msDS-DeviceOSVersion: Aygıtın işletim sistemi versiyonu

Ø  msDS-DevicePhysicalIDs: Aygıtın fiziksel ID bilgisi

Ø  msDS-DeviceObjectVersion: Aygıtın schema versiyon bilgisi

Ø  msDS-RegisteredOwner: Aygıtın AD'ye kaydeden ilk kullanıcı bilgisi.

Ø  msDS-ApproximateLastLogonTimeStamp: Aygıttan son logon olma zaman bilgisi

Ø  msDS-RegisteredUsers: Aygıtı AD'ye kaydeden tüm kullanıcı listesi

Ø  msDS-IsManaged: Aygıtın şirket ortamındaki bir MDM uygulaması tarafından yönetilip yönetilmediği bilgisi

Ø  msDS-CloudIsManaged: Aygıtın bulut-tabanlı bir MDM tarafından yönetilip yönetilmediği bilgisi

Windows Server 2012 R2 ile schema içerisinde gelen ms-DS-AuthN-Policy sınıf ile merkezi kimlik doğrulama politikaları (authentication policy) yazabiliyoruz. Bu özellik sayesinde kullanıcı-bazında Kerberos ticket life-time belirlenebiliyor. Bu sayede Kerberos-tabanlı saldırılara karşı daha sıkı politikalar belirlenebiliyor, domain admin gibi yüksek yetkili hesaplara daha düşük süreli ticket kullanımları tanımlanabiliyor.

Windows Server 2012 R2 Domain ve Forest Fonksiyonel Seviyeleri

Active Directory mimarisinde domain ve forest içerisinde desteklenen domain controller işletim sistemleri ile forest ve domain yeteneklerini belirleyen iki önemli kriter vardır: forest fonksiyonel seviyesi (forest functional level – FFL) ve domain fonksiyonel seviyesi (domain functional level – DFL). Domain ve Forest Fonksiyonel seviyeleri konusunu Windows Server 2012 R2 bakış açısıyla ayrı bir makalede ele alacağız. Domain ve Forest Fonksiyonel seviyeleri çalışılan domain ya da forest yapılarının yeteneklerinin sınırlarını belirler. Örneğin, active directory domain yapınızda kullanıcı seviyesinde şifre ve hesap kilitleme politikaları amaçlı fine-grained-password-policy uygulamak isterseniz domain fonksiyonel seviyesinin Windows 2008 ya da üzerinde olması gerekir. Yine active directory içerisinde silinen nesneleri geri dönüşüm kutusundan kurtarmak amaçlı recyle-bin özelliğini kullanmak isterseniz forest seviyesinin minimum Windows Server 2008 R2 ya da üzerinde olması gerekir. Forest ya da domain seviyelerini istenilen seviyeye yükseltmek için o domain ve forest içerisindeki tüm domain controller sunucuların tamamının minimum yükseltilmek istenen versiyon seviyesinde olması gerekir. Ve domain ve forest seviyelerinin yükseltilmesi sonrasında o domaine daha alt versiyonda bir domain controller kurulumu yapılamaz.

ÖNEMLİ : Tamamen yeni kurulan bir Windows Server 2012 R2 active directory domain ve forest yapısında minimum forest ve domain seviyesi Windows Server 2008 ve üzeri seviyelerde çalışabilir. Mevcutta çalışan bir Windows 2003 domain yapısında ise forest ya da domain level Windows 2003 ve üzeri versiyonlarda olabilir.

Windows Server 2012 R2 domain seviyesi ile gelen yetenekler:

·         Authentication policy ve silo kullanımı

Windows Server 2012 R2 forest seviyesine geçiş ile Windows 2012 forest fonksiyonel seviyesinden farklı bir yetenek şu an için yükseltmeye gereksinim göstermiyor.

Protected Users Güvenlik Grubu:

Windows Server 2012 R2 ile güvenlik amaçlı yeni bir global security grup geliyor : Protected Users. Bu grup sayesinde özellikle yüksek seviyede yetkili yönetimsel hesaplar koruma altına alınabiliyor. Protected Users grubuna üye yapılan kullanıcılara ait karakteristik özellikleri maddeler halinde ele alırsak:

·         Düşük seviyeli kimlik doğrulama protokollerini (NTLM, Digest Authentication, CredSSP) kullanarak kimlik-doğrulama sürecini gerçekleştiremezler.

·         Grup üyeleri Kerberos kimlik doğrulama protokolünü kullanmaları zorunludur.

·         Kimlik doğrulama süreci öncesindeki kullanıcı bilgilerinin şifrelenmesinde DES ve RC4 gibi zayıf seviyeli şifreleme teknikleri desteklenmez.

·         Kerberos tarafından atanan ticket-granting-ticket (TGT) geçerlilik süreleri çok daha düşüktür.

·         Normal hesaplarda gerçekleştirilen cache yapısındaki bilgilerle çevrimdışı (offline) logon olabilme yeteneği bu grubun üyeleri tarafından gerçekleştirilmez.

·         Bu grubun üyesi kullanıcılar için sınırlı delegasyon (constrained delegation) amaçlı kullanılamaz.

·         Bu gruba servis hesapları ve bilgisayar hesaplarının üye yapılması önerilmez.

Protected Users grubunun kullanılabilmesi için gereksinimler:

·         Active directory schema yapısının Windows Server 2012 R2’ye yükseltilmesi

·         Domain fonksiyonel seviyesinin Windows Server 2012 R2’ye yükseltilmesi

·         PDC Emulator FSMO rolüne sahip domain controller sunucunun Windows Server 2012 R2 versiyonunda çalışıyor olması

·         Bu özelliğin kullanılacağı istemci bilgisayarların Windows 8.1, sunucu bilgisayarların da Windows Server 2012 R2’ye yükseltilmesi (bu grup sayesindeki koruma yeteneklerini sağlayan yeni kodlar bu versiyonlarda sağlanmıştır.)

Protected Users ile ilgili detaylı uygulama ve diğer bilgileri ayrı bir makalede ele alıyor olacağız.

Authentication Policy ve Silo Yapı Taşları

Authentication Policy ve Silo yapı taşları sayesinde kullanıcıların hangi bilgisayarlardan domaine logon olabilecekleri kontrol altına alınabilir. Protected Users güvenlik grubu ile entegre bir yapıda kullanılarak logon olan hesaplara erişim kontrol kuralları (access control condition) yazılarak, belli politikalara göre logon denetimi sağlanabilir.Kimlik doğrulama politikaları Kerberos Authentication Service (AS) ya da Ticket Granting Service (TGS) değişimi aşamalarında devreye girerek uygulanır. Authentication Policy ve Silo kullanımı için gereksinimler:

·         Active directory schema yapısının Windows Server 2012 R2’ye yükseltilmesi

·         Domain fonksiyonel seviyesinin Windows Server 2012 R2’ye yükseltilmesi

·         PDC Emulator FSMO rolüne sahip domain controller sunucunun Windows Server 2012 R2 versiyonunda çalışıyor olması

·         Logon olunan istemci tarafında bu koruma politikalarının uygulanabilmesi için işletim sisteminin Windows 8.1 versiyonuna yükseltilmesi

Authentication Policy ve Silo Yapı Taşları ile ilgili detaylı uygulama ve diğer bilgileri ayrı bir makalede ele alıyor olacağız.

LSASS Bellek Koruma Yeteneği

Local Security Authority Subsystem Service (LSASS), Windows işletim sistemlerinde güvenlik politikalarının uygulamasından sorumlu servistir. Windows işletim sistemi ortamına giriş yapan kullanıcının doğrulanması, şifre değişim zamanlarının kontrolü, erişim jetonlarının (access token) oluşturulması gibi faaliyetleri yerine getirir. Bu işlem süreçleri ile ilgili bilgileri de Windows Security günlük kayıtlarına yazar. Arka planda çalışan process adı, lsass.exe’dir. Bu ismi kullanan farklı zararlı yazılımlar da bilgisiyarınıza bulaşarak ciddi zararlar verebilir. Dolayısıyla Windows sistemindeki lsass.exe ile sahte olanlarını iyi ayırt etmek gerekir. Bu konuda ilk bakılacak kriter orjinal lsass.exe’nin Windows\system32 dizini altında olmasıdır.  Bu konumun dışında çalışan lsass.exe process’leri yüksek ihtimalle virus, trojan, worm gibi zararlı, bulaşıcı uygulamalardır. LSA (Local Security Authority) ise, bir sistem üzerindeki yerel güvenlik ile ilgili her türlü bilginin tutulduğu ve Local Security Policy olarak da bilinen LSASS içerisinde bulunan Windows’un korumalı altsistemidir. Policy bilgilerini tutmasının yanında isimlerle, security identifier (SID) çevrimlerini de sağlar. LSA Authentication adı verilen bir süreç ile kullanıcılar yerel bilgisayara kimlik doğrulama sürecinden geçerek logon olmaları da yine LSA ile sağlanır. LSA bellek koruma yeteneği için LSA plug-in sürücüsünün (smart-card sürücüsü ya da password filtresi) Microsoft tarafından dijital imzalı olması gerekir. Bu imzanın olabilmesi için ilgili sürücülerin Microsoft’un laboratuvarlarında test edilme ve onaylanma sürecinden (WHQL Sertifikasyon Süreci) geçmiş olması gerekir. Ayrıca yine Microsoft’un güvenlik geliştirme süreçlerinden de (SDL) geçmiş olmalıdır. Dolayısıyla kendi geliştirmiş olduğunuz ya da üçüncü parti olarak satın alınan bir şifre filtreleme uygulamasının kullanıcı logon sürecinde devreye girmesi ve fonksiyonunu icra etmesi için Microsoft’un WHQL sertifikasyon sürecinden onaylanmış olma zorunluluğu vardır.

Windows 8.1 ve Windows Server 2012 R2 ile yukarıda anlattığımız LSA kimlik doğrulama aşamasında devreye giren process’ler için ilave koruma kontrolleri geliyor. Bu kontroller sayesinde yetkisiz süreçler tarafından bellekteki bilginin okunması, hatta kod-enjekte edilmesi gibi istenmeyen durumlar önlenebiliyor. Bu yetenek sayesinde LSA üzerinde depolanan ve yönetilen kullanıcı erişim bilgilerine ilave güvenlik korumaları da sağlanmış oluyor. Bu koruma Windows 8.1 üzerinde uygulanabilirken, şu an için Windows RT 8.1 üzerinde yapılandırılamaz. Bu yetenek ile birlikte Secure Boot seçeneği de ortaklaşa kullanılırsa daha yüksek seviyede bir koruma da sağlanmış olacaktır.

LSASS Belek Koruması için gereksinimler:

İşletim sistemi Windows Server 2012 R2 ya da Windows 8.1 olmalıdır.

Bu özelliğin domain controller üzerinde etkinleştirilebilmesi için active directory schema versiyonunun Windows Server 2012 R2’ye yükseltilmesi ve domain controller sunucuların da Windows Server 2012 R2 versiyonuna yükseltilmesi gerekir.

LSASS Bellek Koruma Yeteneği ile ilgili detaylı uygulama ve diğer bilgileri ayrı bir makalede ele alıyor olacağız.

FRS Konusunda Son Gelişmeler

File Replication Service(FRS), Windows Server işletim sistemleri üzerinde paylaştırılmış dosyaları ve GPO(Group Policy Object) nesnelerinin çoğaltılması, dağıtımı ve replikasyonunundan sorumlu olan servistir. Windows NT zamanındaki NT LAN Manager Replikasyon servisinin yerini almıştır. Zaman içerisinde FRS’de yerini DFSR(Distributed File System Replication) servisine bırakmıştır. DFSR aynı zamanda servisi çalıştıran dosyanın isminden de çıkışla NTFRS olarak da tanımlanır. FRS ile bir dosya oluşturulması, dosyada değişiklik yapılması gibi durumlar gözlemlenerek bu değişikliğin diğer sunuculara ya da sistemlere senkronizasyonu sağlanır. Aynı dosya üzerinde farklı sunucularda yapılan değişikliklerdeki çakışmalar tarih ve saat bilgileri kullanılarak çözümlenir. Active Directory yapılarında FRS,  domain controller sunucular arasındaki SYSVOL paylaşımının replikasyonu için kullanılır. Bildiğiniz gibi SYSVOL içerisinde group policy nesneleri ve script dosyaları bulunmaktadır ve bunlar logon olan tüm kullanıcılar ve sistemler için kritik öneme sahip dosyalardır. Dolayısıyla FRS replikasyonundaki sağlamlık ve tutarlılık son derece önemlidir. Windows 2003 R2 ve Windows 2008 ile beraber DFS servisi de replikasyon servisi olarak gelmiştir. DFS’in replikasyon programlama, bant genişliği sınırlandırma gibi destekleri de vardır. DFS, Remote Differential Compression özelliği ile dosyaların tamamı yerine sadece değişikliklerin senkronizasyonunu gerçekleştirme yeteneği vardır. Günümüzde FRS de SYSVOL replikasyonu için hala kullanılmaktadır. Fakat Windows 2008 ve üzeri domain yapılarında active directory geçişleri sonrasında SYSVOL replikasyonunun da FRS’den DFSR’a taşınması gerçekleştirilmeli ve FRS servisi de durdurulmalıdır. Böylece daha performanslı, güvenilir, sağlam ve yeni teknolojide SYSVOL replikasyonu çalışmış olacaktır. Tamamen yeni bir kurulum ile yapılandırılmış Windows 2008 ve üzeri active directory domain yapılarında SYSVOL replikasyonu otomatik olarak DFSR üzerinden gerçekleştirilmektedir.

Windows Server 2012 R2 sonrasında artık FRS tamamen kalkıyor. Dolayısıyla özellikle Windows Server 2012 R2 active directory domain geçişi sonrasında FRS’den DFSR’a geçiş zorunlu hale geliyor, aksi halde bir sonraki active directory versiyonuna geçiş desteklenmeyecek.

SYSVOL replikasyonunun FRS’ten DFSR’a geçişini ayrı bir makalede adım adım uygulamalarıyla ele alıyor olacağız.

Active Directory Federasyon Servis Yenilikleri

OAuth 2.0 Desteği

Windows Server 2012 R2 ile Active Directory Federasyon Servislerinde OAuth 2.0 kimlik doğrulama framework desteği geldi.

OAuth 2.0 teknik olarak bir yetkilendirme sistemi ya da çerçevesidir. OAuth 2.0, bir mobil istemci üzerinde çalıştırılan bir uygulamanın bir kaynağa erişim isteğinde, ortamdaki “Authorization sunucusundan” aldığı token ile kaynağın bulunduğu sunucuya bağlanır. OAuth 2.0 protokolünün günlük hayattaki kullanımına en güzel örnek bir kimlik sağlayıcıdan aldığınız hesapla twitter, facebook gibi sistemlere logon olmayı örnek gösterebiliriz. Örneğin; facebook, linkedin ya da twitter hesabınızla, bu platformlara entegre uygulama ya da web platformlarına giriş. Bu tip bağlantılarda kimlik doğrulama sürecini incelerseniz oauth barındıran adresleri göreceksiniz. OAuth 2.0 aynı zamanda bulut-servisleri ve bulut-tabanlı uygulamalara özellikle mobil sistemlerden daha güvenli erişim imkanı sağlamaktadır. Kerberos’a göre daha esnek bir protokol olmasının yanında, implementasyonu daha komplekstir. Özetle OAuth 2.0 bir yetkilendirme ve kimlik doğrulama protokolüdür. OpenID Connect ise OAuth 2.0 üzerinde bulunan basit kimlik katmanıdır. OpenID Connect, kimlik sağlayıcıların ve dış partilerin OAuth 2.0 kullanarak birbiri arasındaki kimlik bilgilerinin iletişimi ve erişiminin nasıl sağlanacağını tanımlayan bir spesifikasyondur. Bu spesifikasyon sayesinde OAuth 2.0 tarafından gereksinim duyulan birçok alana varsayılan değer atanarak OAuth 2.0 implementasyonu daha da kolaylaştırılmıştır. OpenID Connect aynı zamanda farklı implementasyonlar için Oauth yapılandırmasında standardizasyonu da sağlar. Özellikle farklı üreticiler için OAuth yapılandırmalarını daha da kolay hale getirir. Geçen yıl Gartner tarafından yapılan bir araştırmada internet üzerinden perakende satış yapan sitelerin yarısından fazlasının Microsoft, Facebook, Google, Linkedin, Twitter gibi sosyal ağlardaki kimlik bilgileriyle sağlanacağı tahmin ediliyordu. Böyle bir uygulama için yetkilendirme ve kimlik yönetiminde ortak methodları sağlayan platform olarak OAuth 2.0 ve OpenID Connect öne çıkmayı başardı. Özetle, OAuth 2.0 ve OpenID Connect framework’lerini, bulut servislerinde kimlik doğrulama süreçlerini işleten, bulutun Kerberos’una benzetebiliriz.

ADFS İçin Soft Account Lockout Desteği

Active Directory ortamlarında bulunan ve dışardan ADFS-koruması üzerinde erişim sağlanan uygulamalara ya da sistemlere erişimde sistemde bulunan kullanıcı hesaplarına yapılabilecek DOS ya da brute-force şifre deneme ataklarına karşı bir koruma önlemi diyebiliriz. Dışardan yapılan yanlış şifre denemelerini ADFS üzerinden doğrudan içerdeki active directory domain servislerine aktarıp, domain politikalarında belirlenen yanlış girme sayısı dolduğunda hesabın kilitlenmesi yerine arada “soft lockout” politikasını devreye alıp, active directory domain servislerine yanlış denemeleri geçirmeyip, ADFS üzerinde bunu kontrol eden bir mekanizma kurabiliyoruz. Soft lockout politikası ADFS üzerinde PowerShell ile Set-ADFSProperties cmdlet ile etkinleştirilebilir. Bu senaryoda erişim yapılan uygulamayı Windows Server 2012 R2 ile Web Application Proxy (WAP) ile dışarıya açıyoruz. Ve soft-lockout etkinleştirmesi WAP üzerinden dışardan yapılan erişimler için geçici olarak uygulanıyor. Gerçekte içerdeki kullanıcı hesabında badPwdCount sayısını etkilemeden, herhangi bir kilitleme gerçekleştirilmiyor.

Active Directory Sertifika Servis Yenilikleri

TPM (Trusted Platform Module) Anahtar Doğrulama Desteği

TPM korumalı anahtar desteği bildiğiniz gibi Windows 8’den bu yana kullanılıyor. TPM bu kullanımda sertifikaya ait özel anahtarın korunması görevini yerine getiriyor. Windows Server 2012 R2 öncesinde sertifika otoritesinin sağladığı dijital sertifikaya ait sertifika istek özel anahtarının bir TPM tarafından korunup korunmadığını kriptografik olarak doğrulaması için bir mekanizma bulunmuyordu.

Windows Server 2012 R2 ile beraber sertifika sağlayacı tarafından sertifika isteğindeki özel anahtarın TPM tarafından korunup korunmadığı kontrolü yapılabiliyor ve bu doğrulama bilgisi de yayınlanan sertifikaya yansıtılıyor.

BYOD Amaçlı NDES Yetenekleri

Network Device Enrollment Service (NDES), Active Directory Sertifika Servislerinin bir alt rol servisi olup, kullanım amacı ortamdaki ağ cihazlarına sertifika dağıtımı ve yönetimi yapmaktır. NDES, Microsoft’un Simple Certificate Enrollment Protocol (SCEP) implementasyonudur. SCEP, Cisco Systems tarafından geliştirilen ve daha sonra IETF Standartlarına kabul edilen, aygıtlar üzerine x509 v3 sertifikaların istekte bulunma ve yüklenme problemini ortadan kaldıran bir standarttır. Microsoft kendi platformunda bunu NDES olarak getiriyor. NDES’in standart SCEP’e göre daha üstün özellikleri de bulunmaktadır. Windows Server 2012 R2 ile beraber özellikle BYOD kanalında tüm IOS ve Windows cihazlar için sertifika dağıtımı desteği geldi.

Active Directory Dijital Hak Yönetim Servisi (RMS) Yenilikleri

Windows Server 2012 R2 ile beraber Active Directory RMS Servislerinde ADFS v1 web ajan desteği de kalktı. AD RMS SDK için de 2.0 versiyonu geldi ve eski versiyon kalktı. Dolayısıyla RMS ile uygulama geliştirmek için AD RMS SDK 2.0 versiyonuna geçiş yapmanız gerekir.

DNS Yenilikleri

Zone Seviyesinde İstatistikler:

Windows Server 2012 ile beraber gelen Get-DNSServerStatistics powershell komutu ile şu başlıklarda istatistiksel bilgileri alabiliyorduk: CacheStatistics, DatabaseStatistics, DnssecStatistics, DsStatistics, ErrorStatistics, MasterStatistics, MemoryStatistics, NetBiosStatistics, PacketStatistics, PrivateStatistics, Query2Statistics, QueryStatistics, RecordStatistics, RecursionStatistics, SecondaryStatistics, SecurityStatistics, TimeoutStatistics, TimeStatistics, UpdateStatistics, ve WinsStatistics.

Windows Server 2012 R2 ile beraber zone seviyesinde ZoneQueryStatistics, ZoneTransferStatistics, ZoneUpdateStatistics hakkında da bilgiler alabiliyoruz artık.

DNSSEC Yenilikleri :

Windows Server 2012 R2 ile beraber zone imzalamada kullanılan anahtarların üretimi, depolanması, yenilenmesi, silinmesi ve yaşlandırılması gibi operasyonlar zone’un primary DNS sunucusundan ayrı Key Master isimli bir sunucuda gerçekleştirilecek şekilde izolasyon desteği geldi. Bu sayede artık Key Master sunucusu bu anahtarların yönetimini yaparken, diğer DNS sunucular ilgili anahtara erişerek zone’ların imzalanması vb. süreçleri yerine getirebiliyorlar.

Yeni PowerShell DNS CmdLet Komutları:

Windows Server 2012 R2 ile beraber DNS yönetimi için aşağıdaki powershell cmdlet’ler geldi:

Ø  Step-DnsServerSigningKeyRollover

Ø  Add-DnsServerTrustAnchor –Root

Ø  RootTrustAnchorsURL

Sonuç Olarak;

Bu makalemizde Windows Server 2012 R2 Active Directory ile bu yılın öne çıkan teknoloji trendlerinden olan ve hedefi insan merkezli IT vizyonunu hayata geçirmeyi amaçlayan BYOD (Bring Your Own Device) için gelen çözümleri inceledik. Önümüzdeki makalelerde Windows Server 2012 R2’de BYOD uygulamasının implementasyonunu adım adım tüm detaylarıyla ele alıyor olacağız. Bir başka makalemizde görüşmek üzere hoşçakalın.

Microsoft’un yeni nesil sunucu işletim sistemi olan Windows Server 2012 R2 ile Active Directory Domain Servislerinde gelen yenilikleri incelemeye devam ediyoruz. Bu makalemizde özellikle Windows 2003 ya da Windows 2003 R2 active directory ortamlarından Windows Server 2012 R2 active directory ortamına geçiş yapanlar için gerekli olan önemli geçiş operasyonlarından birini inceliyoruz: Domain Controller Sunucular üzerinde SYSVOL Replikasyonunun File Replication Service(FRS)’ten Distributed File System Replication (DFRS)’a Geçişi. Bu geçiş esasında active directory domain geçiş sürecinin bir parçası olmasına rağmen çoğu yerde bunun atlandığını ya da böyle bir geçişten bilgilerinin dahi olmadığı gibi durumlarla karşılaşabiliyor.

Bu konudaki sorulara yanıt olması açısından ve bundan sonrası için bir referans kaynak olması amacıyla bu makalemizde konuyu detaylı olarak ele almaya çalıştık.  Sadece Windows Server 2012 R2 active directory yapısına geçiş yapanlar değil, hali hazırda Windows 2008 ve üzeri active directory yapısında çalışan tüm sistem yöneticileri bu makalemizi kullanarak mevcut SYSVOL replikasyonlarının FRS’ten DFSR’a taşıyabilecekler.

ÖNEMLİ HATIRLATMA : Windows Server 2012 R2 sonrası active directory domain yapılarına geçiş için SYSVOL replikasyonunun FRS’den DFSR’a taşınması bir ön gereksinim olarak zorunlu hale gelmiştir. Makalemizdeki adımlarla mevcut active directory mimarinizde SYSVOL replikasyonunu FRS’ten DFSR’a bugünden geçiş yapmanızda fayda olacaktır.

Giriş

File Replication Service(FRS), Windows 2000 Server işletim sistemi ile tanıştığımız, Distributed File System (DFS) mimarisindeki klasörler içeriklerinin ve domain controller sunucular üzerindeki SYSVOL klasörlerinin dağıtık yapıdaki farklı sunucular arasında replikasyonunu sağlayan Microsoft tarafından geliştirilmiş teknolojidir. Windows Server 2008 R2 ile beraber DFS Replikasyonu için FRS'in yerini tamamen DFS (Distributed File System) teknolojisi almıştır. Aslında Windows 2003 R2 ile beraber Microsoft FRS'in yerine DFS Replikasyonuna(DFSR) geçiş sürecini başlatmıştı. Windows 2003 R2 ile birlikte daha verimli, sağlam ve güçlü bir servis olan DFS Replikasyon(DFSR) FRS'in yerini almaya başlamıştı, fakat domain controller sunucular üzerinde SYSVOL replikasyonu için hala FRS kullanılmaktaydı.

Windows Server 2008 ile birlikte Windows 2008 domain fonksiyonel seviyesinde çalışan yapılar için SYSVOL replikasyonunda FRS'in yerini DFS Replikasyonu aldı. Windows Server 2008 R2 ile birlikte, FRS yalnızca Windows Server 2003 ya da Windows 2000 domain fonksiyonel seviyesinde çalışan domainlerde SYSVOL replikasyonu için kullanılıyordu. Önceden FRS tarafından gerçekleştirilen tüm replikasyon görevler artık DFS Replikasyon servisi ile sağlanıyordu. Ve Windows Server 2008 R2'ye yükseltilen sunucularda FRS kopyaları disable konumuna alınıyordu.

DFS ReplikasyonuN FRS'e Göre Avantajları

Özellikle active directory geçişleri sonrasında FRS mimarisinin DFSR'a geçişini öneriyoruz ve gerçekleştiriyoruz. Çünkü DFS'in FRS teknolojisi üzerinde çeşitli avantajları bulunmaktadır. Bunlardan bazıları:

·         DFS Replikasyon yapılan testlerde veri bütünlüğü açısından daha verimli, ölçeklenebilir, daha sağlam mimaride çalışan dosya çoğaltma protokolüdür.

·         DFS Replikasyon protokolü FRS'e göre daha hızlıdır. Aktifleştirilen Remote Differential Compression (RDC) sayesinde büyük dosyalarda oluşan değişiklikler çok daha hızlı senkronize olmaktadırlar. Örneğin, RDC-aktifleştirilmiş bir yapıda 2 MB PowerPoint dosyasındaki ufak bir değişiklik ile ağdan sadece 60 KB'lik bilgi gönderilerek, ağ trafiğinde %97 oranında bir tasarruf sağlanmış olacaktır.

·         FRS NTFS volume'ün USN Journal bilgisini kullanarak bir dosyadaki değişikliği algılar ve replikasyonu tetikler.Bir dosyada değişiklik varsa FRS dosyanın tamamını replikasyona tabi tutarken, DFSR sadece değişiklikleri gönderir.

·         DFS, yeni yönetim konsolu ile daha kolay bir yönetim sağlıyor.

·         Yerleşik sağlık durumu izleme araçları ile yapıyı kolaylıkla gözlemleyebilirsiniz.

·         Read Only Domain Controller desteği mevcuttur.

FRS'den DFS Replikasyona Geçiş Gereksinimleri

FRS protokolünden DFS yapısına geçiş için gereksinimler:

·         Standart dosya repliasyonu için kullanılan DFS mimarisini FRS'den DFSR'a geçiş yapıyorsanız tüm sunucular Windows Server 2003 R2 SP2 ya da üzeri olmalıdır.

·         Domain controller sunucular üzerindeki SYSVOL replikasyonunu FRS'den DFSR'a taşıyorsanız da domaindeki tüm domain controller işletim sistemlerinin Windows 2008 ve üzeri versiyonda olması gerekir.

·         Domain controller sunucular üzerindeki SYSVOL replikasyonunu FRS'den DFSR'a taşıyorsanız da domain fonksiyonel seviyesinin Windows 2008 ya da üzeri olması gerekir.

Not : Mevcut yapıda çalışan FRS ortamınız Windows 2000 Server işletim sisteminde çalışıyorsa, bunları doğrudan sadece Windows Server 2003 R2 SP2 versiyonuna yükseltebilirsiniz. Daha sonra sunucular Windows 2008 ve üzeri versiyonlar yükseltilebilir. Burada işletim sistemi mimarisine de dikkat etmek gerekir. 32-bit mimaride çalışan eski versiyon bir işletim sistemini 64-bit mimariye de yükseltemezsiniz. Alternatif yöntem olarak mevcut Windows 2000 Server sunucular için yerinde yükseltme yerine yeni sunucu konumlandırıp, FRS mimarisindeki sunucuları üst versiyonlara migration yöntemi ile taşıyabilirsiniz.

·         Standart dosya çoğaltması kullanılıyorsa FRS replikasyon mimarisindeki tüm sunucular üzerinde DFS Replication rol servisinin kurulu olması gerekir.

·         FRS konfigürasyonu yapılmış domainlerde Domain Admins grubuna üye olmanız gerekir.

·         Yönetim için ilgili sunucular üzerinde Distributed File System eklentisi (DFSGUI.MSC) kurulu olmalıdır.

Biz bu makalemizde active directory domain controller sunucular için SYSVOL replikasyonunun FRS'den DFSR'a geçiş adımlarını detaylı olarak ele alıyoruz.

SYSVOL Replikasyonun FRS’den DFSR’a Yükseltilme Adımları

Active Directory domain controller sunucular üzerinde SYSVOL replikasyonunun FRS’ten DFSR’a yükseltilmesi dört ana adımdan oluşan bir süreçtir. Bu adımlar:

·         Start : Geçiş öncesi bulunulan aşamadır.

·         Prepared : Start aşamasından sonraki aşamadır. SYSVOL replikasyonunu FRS yaparken, SYSVOL içeriğinin kendi dizinine replikasyonunu DFSR gerçekleştirir.

·         Redirected : Prepared aşamasından sonraki aşamadır. SYSVOL’ün DFSR kopyası kullanıcılar ile paylaşılır. Orijinal SYSVOL replikasyonunu FRS gerçekleştirirken, SYSVOL’ün kopyasının replikasyonunu DFSR gerçekleştirir.

·         Eliminated : Redirected aşamasından sonraki ve DFSR geçişinin tamamlanma aşamasıdır. SYSVOL replikasyonu tamamen DFSR üzerinden gerçekleştirilir, FRS’in artık SYSVOL replikasyonunda herhangi bir fonksiyonu yoktur.

Yukarıda listenen her aşamanın tamamlanması için o aşamada yapılan operasyon domain ortamındaki bütün domain controller sunuculara replikasyonun tamamlanmış olması gerekir. Replikasyon tamamlanmadan bir sonraki adıma geçiş yapılamaz. Uygulama aşamalarında bunu birlikte görüyor olacağız.

Arka planda gerçekleşen süreci de şu şekilde maddeler halinde özetleyebiliriz:

·         C:\Windows\SYSVOL_DFSR dizininin oluşturulması

·         C:\Windows\SYSVOL altındaki içeriğin C:\Windows\SYSVOL_DFSR altına kopyalanması

·         SYSVOL paylaşımının C:\Windows\SYSVOL_DFSR için yeniden oluşumu

·         C:\Windows\SYSVOL orijinal dizininin silinmesi

Geçiş sürecine başlamadan önce mevcut FRS mimarisinde ve active directory ortamında aşağıdaki sağlık kontrollerinin de gerçekleştirilmesini öneriyorum:

·         Net Share komutu ya da üçüncü parti bir araç ile SYSVOL paylaşımlarının bulunduğunun kontrolü

·         Repadmin /replsum ile replikasyon sağlık durumunun gözden geçirilmesi, varsa hataların çözümlenmesi

·         DCDiag /e /test:sysvolcheck /test:advertising ile SYSVOL replikasyon sağlık durumunun gözden geçirilmesi, varsa hataların çözümlenmesi

Lab Ortamı Mimarisi:

Hali hazırda cozumpark.local isimli Windows 2003 active directory yapısından Windows Server 2012 R2 active directory yapısına geçiş yapılmış bir active directory domain ortamında çalışıyoruz. Bu laboratuvar ortamı olduğu için şu anda benim sadece bir tane domain controller sunucum var. Domaindeki tüm domain controller sunucular Windows Server 2012 R2 ve Windows 2003 domain controller’lar active directory üzerinden silinmiş durumda, ya da bir başka deyimle Windows 2003 sunucular üzerinden active directory servisini kaldırıp, domain yapısını Windows Server 2012 R2’ye geçiş yaptık. Fakat SYSVOL replikasyonu FRS ile çalışmaya devam ediyor.

Şu anki domain fonksiyonel seviyemizin Get-ADDomain powershell komutu ile hangi seviyede olduğunu kontrol ediyoruz:

Şu anda Windows 2003 domain seviyesindeyiz. Öncelikle bunu minimum Windows 2008 ve üzeri seviyeye yükseltmemiz gerekiyor. Bu yükseltme işlemini Set-ADDomainMode cmdlet ile gerçekleştiriyoruz. Siz grafiksel arayüzden Active Directory Users and Computers ya da Active Directory Domains and Trusts konsollarını kullanarak da bu geçişi gerçekleştirebilirsiniz.

Bu geçişler sonrasında DFSRMIG aracı ile SYSVOL replikasyonu için mevcut durumu kontrol ediyoruz:

DFSR geçişinin henüz başlamadığı bilgisini alıyoruz.

Artık DFSR geçişi için hazırız, şimdi de adım adım geçiş operasyonlarına başlayalım.

FRS'den DFS Replikasyona (DFSR) Geçiş Adımları:

FRS'den DFS Replikasyona (DFSR) Geçiş için DFSRMIG.EXE aracını kullanıyoruz. 

DFSRMIG.EXE /GETGLOBALSTATE : Mevcut durumdaki DFSR geçişinde bulunulan aşamayı gösterir. Bu komutu verince aşağıdaki gibi DFSRMIG.EXE ile geçiş sürecinin başlatılabilmesi için domain fonksiyonel seviyesinin minimum Windows 2008 ya da üzeri olması gerektiği bilgisi gelecektir.

DFSRMIG.EXE /SETGLOBALSTATE [State] : Mevcut durumdaki DFSR geçişinde geçilecek adımı ayarlar.

DFSRMIG.EXE /GETMigrationSTATE : Mevcut durumda tüm domain controller için geçiş süreci hakkında bilgi verir.

Prepared Aşamasına Geçiş :  DFSR geçişini Start seviyesine yükseltmek için aşağıdaki komutu uyguluyoruz:

DFSRMIG.EXE /SetGlobalState 1

Event Viewer içerisinde de 8000, 8008, 8010,8012, 8014 ID numaralı olay kayıtları sırayla oluşmuş olacaktır.

Bu komutu uyguladıktan sonra DFSRMIG.EXE /getglobalstate ile yapılan değişikliğin tüm domain controller sunuculara replikasyon yapıldığından emin olmalısınız.

Tüm domain controller sunucularına replikasyon yapıldığı bilgisini aldıktan sonra bir sonraki aşamaya yani PREPARED aşamasına geçiş için ilgili komutu uyguluyacağız.

Redirected Aşamasına Geçiş :  DFSR geçişini Redirected seviyesine yükseltmek için aşağıdaki komutu uyguluyoruz:

DFSRMIG.EXE /SetGlobalState 2

Event Viewer içerisinde de yine ilgili olay kayıtları sırayla oluşmuş olduğunu kontrol edebilirsiniz.

Bu komutu uyguladıktan sonra da yine DFSRMIG.EXE /getglobalstate ile yapılan değişikliğin tüm domain controller sunuculara replikasyon yapıldığından emin olmalısınız.

Tüm domain controller sunucularına replikasyon yapıldığı bilgisini aldıktan sonra bir sonraki aşamaya yani ELIMINATED aşamasına geçiş için ilgili komutu uyguluyacağız.

Eliminated Aşamasına Geçiş :  DFSR geçişini Eliminated seviyesine yükseltmek için aşağıdaki komutu uyguluyoruz:

DFSRMIG.EXE /SetGlobalState 3

Bu komutu uyguladıktan sonra yine DFSRMIG.EXE /getglobalstate ile yapılan değişikliğin tüm domain controller sunuculara replikasyon yapıldığından emin olmalısınız.

Tüm domain controller sunucularına replikasyon yapıldığı bilgisini aldıktan sonra artık FRS’ten DFSR’a SYSVOL replikasyonunu taşımış olduk.

Bu sürecin sonunda C:\Windows altına baktığımızda SYSVOL klasörünün artık olmadığını ve yerine SYSVOL_Dfsr klasörünün geldiğini göreceksiniz:

ÖNEMLİ NOT : Eliminated aşamasına geçtikten sonra artık geriye dönüş mümkün değildir. Bir başka deyişle FRS’den DFSR geçişini iptal etmek isterseniz bunu 3 numaralı ELIMINATED aşamasına geçmeden yapmalısınız.

Geçiş süreci tamamlandıktan sonra Services konsolunda replikasyonun tamamen DFS Replication ile yapıldığını ve File Replication Service’in Disabled durumuna alındığını göreceksiniz.

Yine active directory domain içerisinden de FRS’e ait tüm replikasyon yapılandırmalarının, yerini SYSVOL’e bırakmış olacağını görmüş olacaksınız. ADSIEDIT konsolunda “Default Naming Context” altında Domain Controllers OU kabı içerisinde DFSR-LocalSettings kabı oluşmuş.

Yine ADSIEDIT konsolunda SYSTEM kabı altında File Replication Service kabından SYSVOL paylaşımının silindiğini göreceksiniz.

ADSIEDIT konsolunda System kabı altındaki DFSR-GlobalSettings kabının Properties’ine girince gelen CN=DFSR-GlobalSettings Properties ekranında ms-DFSRFlags değerinin 48 yani Eliminated olarak ayarlandığını görmüş olacaksınız.

Burada karşınıza gelebilecek değerler:

·         Start: 0

·         Prepared: 16

·         Redirected: 32

·         Eliminated: 48

Sonuç Olarak;

Bu makalemizde Windows 2003 ya da Windows 2003 R2 active directory ortamlarından Windows Server 2012 R2 active directory ortamına geçiş yapanlar için önemli geçiş operasyonlarından olan Domain Controller Sunucular üzerinde SYSVOL Replikasyonunun File Replication Service(FRS)’ten Distributed File System Replication (DFRS)’a geçişini adım adım tüm detaylarıyla uygulamalı olarak ele aldık. Bir başka makalemizde görüşmek üzere hoşçakalın.

Microsoft Volume Activation Management aracını özetleme için bir örnek ile konuya başlamak istiyorum. Diyelim ki ağımızda 500+ tane bilgisayarımız var ve Office 2007 kullanıyoruz sonrasında bir sabah müdürümüz geldi ve Office 2013’ e geçeceğimizi söyledi kurulumlarımızı yaptık ama aktivasyon da yapmamız gerekiyor işte burada VAMT yardımımıza koşuyor.

VAMT tüm Microsoft paketlerimizi toplu aktive edebileceğimiz bir basit bir yönetici yazılımıdır.

Gereksinimleri ise;

·         Yoğun donanımsal bir performans istemez (1 GB RAM, 1Ghz işlemci ve 16 GB disk alanı yeterlidir.)

·         İşletim sistemi olarak Windows 7 ve üstü ile Windows Server 2008 R2 ve üstü yeterli olacaktır.

·         Bağlantı kurabileceği bir SQL veri tabanına ihtiyaç duymaktadır. (Mevcutta bir veri tabanınız yok ise kurulumda SQL 2012 Express gelmektedir.)

·         PowerShell 3.0 kurulu olmalıdır. (Windows 8 ve 2012 içerisinde hazır gelmektedir.) http://www.microsoft.com/en-us/download/details.aspx?id=34595 (Windows 7 ve Server 2008 için)

·         .NET Framework 3.5 kurulu olmalıdır. (Windows 8 ve Server 2012 üstü)

Evet artık kuruluma geçebiliriz.

1.       Adım

http://www.microsoft.com/en-us/download/details.aspx?id=30652 adresinden Windows® Assessment and Deployment Kit (Windows ADK) paketini indiriyoruz.

2.       Adım

İndirmiş olduğumuz kurulum dosyasını çalıştırıp standart kurulum ekranları geçiyoruz.

3.       Adım

Kurulacak paketlerin seçim ekranına geliyoruz. Microsoft ADK Microsoft ürünleri ile ilgili kurulum ve dağıtım işlemlerini yapabileceğiniz oldukça kullanışlı araçları içerisinde barındırmaktadır.

Biz burada ihtiyacımız olan VAMT ve SQL Server 2012 Express paketlerini seçiyoruz. (Mevcutta bir veri tabanınız var ise SQL kurulumu yapmanıza gerek yoktur.)

4.       Adım

Evet VAMT ve SQL kurulumlarımızı yaptık sıra uygulamamızı çalıştırmaya geldi.

5.       Adım

İlk açılışta bize SQL sunucumuzu ve veri tabanı adını soruyor. (Ben yeni bir veri tabanı adı vereceğim) gerekli bilgileri girdikten sonra Connect diyerek SQL veri tabanı bağlantımı oluşturuyorum.

Önüme böyle bir veri tabanının bulunmadığı ve oluşturulacağına dair bilgi ekranı geliyor.

6.       Adım

Gerekli veri tabanı bağlantısı oluştuktan sonra VAMT önümüze geliyor. İlk olarak elimizdeki ürün anahtarları girmeye başlıyoruz. Bunun için sol tarafta bulunan Product Keys sekmesine sağ tıklayıp Add product keys’ i seçiyoruz.

7.       Adım

Ürün anahtarlarımızı tek tek veya toplu olarak ekleyebiliriz. Add keys diyerek ekleme işlemini gerçekleştiriyoruz. (Ürün anahtarlarının Microsoft tarafından doğrulanması için internet bağlantınızın mutlaka olması gerekiyor.)

Evet artık kurulum ve ilk ayarları tamamladık altta yüklemiş olduğumuz ürün anahtarlarını görebilirsiniz.

Sıra ürün anahtarlarını ağımızda bulanan bilgisayara yüklemeye geldi. Ağımızda bulunan bilgisayarları Active Directory üzerinden sorgulayarak veya IP adres aralığı belirleyerek bulabiliriz.

Sağ tarafta bulunan Actions menüsü üzerinden Discovery products’u seçiyoruz.

Ben burada Active Directory üzerinden sorgulamayı seçtim domain adımı yazıp aramayı başlatıyorum.

Arama işlemi sizin domain yapınız içerisinde bulunan istemci sayınıza göre farklılık gösterecektir. İşlem bittikten sonra tüm istemciler listelenecek ve sizde hangisinin lisanslı olup olmadığını ve hangi lisansı kullandığınızı görüyor olacaksınız.

İsterseniz tüm istemcileri seçip toplu lisans yüklemesi yapabilir yada sağ tarafta bulunan Product menüsünden Filter’ i seçerek istediğiniz bir istemcinin aktivasyonunu yapabilirsiniz.

Ben burada domainim üzerinde bulunan test isimli istemcimin aktivasyonunu yapacağım.

Süzmüş olduğum istemcinin üzerine sağ tıklayıp update license status sekmesinden Current credential’ ı seçiyorum.

Gerekli bilgi toplama işlemi yapıldıktan sonra bu istemci üzerinde hangi Microsoft yazılımının kullanıldığı bilgisi karşımıza geliyor.

Tekrar yükleme yapacağım istemcim üzerinde sağ tıklayarak Install product key’ i seçiyorum.

Yeni VAMT 3.0 en güzel özelliklerinden biri hangi ürün anahtarınızı yüklemeniz gerektiğini önermesidir. (Etiketleme yapmazsanız çok ihtiyaç duyacağınız bir özellik.)

İlgili ürün anahtarını seçip Install Key’ i seçiyoruz.

Yükleme işleminin tamamlandığına dair bilgi ekranı karşımıza geliyor.

Sıra yüklediğimiz ürün anahtarının aktivasyonunu yapmaya geldi. İstemcimiz üzerinde sağ tıklayarak Activate sekmesi üzerinde Online activate > Current credential’ ı seçiyoruz.

Evet artık lisans yükleme ve aktivasyon işlemlerini başarı ile gerçekleştirdik.

Makalemi bitirmeden önce sizlerle birkaç ipucu daha paylaşmak istiyorum.

VAMT 3.0 size kalan lisans sayınız hakkında bilgi verme özelliğine sahiptir.

VAMT sunucunuzu ileride taşımak isterseniz yüklemiş olduğunuz ürün anahtarlarını Export-Import edebilirsiniz.

Unable to connect to the WMI service on the remote machine hatası alır iseniz sebebi VAMT sunucunuzun istemcilerinize erişememesidir. Windows Firewall kapalı ise bu uyarıyı hiç almayacaksınız.

Ama Windows Firewall’ın kapalı olmasını sakıncalı buluyorsanız şu komutu istemciler üzerinde çalıştırabilirsiniz.

netsh firewall set service RemoteAdmin enable

Artık makalemizin sonuna geliyoruz.

Tekrardan görüşmek dileği ile.

Herkese iyi çalışmalar.

Microsoft’un yeni nesil sunucu işletim sistemi olan Windows Server 2012 R2’nin özelliklerini incelemeye devam ediyoruz. Üç bölümden oluşan makalemizin ikinci bölümünde sistem yöneticileri için temel konulardan biri olan “Kullanıcı Hesaplarının Yönetimini” incelemeye devam ediyoruz. Önceki birinci bölümde de belirttiğimiz gibi amacımız bu konuda uzun vadede referans olabilecek bir makale hazırlamak. Bu makaledeki anlatımlarımızı her ne kadar Windows Server 2012 R2 üzerinde yapmış olsak da, büyük bir kısmı özellikle Windows 2003’den bugüne tüm active directory ortamlarında geçerlilik arzediyor olacak.

Kullanıcı Hesabi Özelliklerinin İncelenmesi:

Domain kullanıcı hesaplarının üzerinde düzenlemeler gerçekleştirmek için Active Directory Users and Computers içerisinden, düzenleme yapılacak kullanıcı seçilir ve sağ tıklanarak açılan menüden Properties seçilir. Ya da kullanıcı hesabı üzerine mouse ile çift tıklanarak kullanıcının Properties penceresine erişilebilir.

Yerel kullanıcı hesaplarında düzenleme yapmak için, kullanıcının oluşturulduğu bilgisayar üzerinde ya da uzaktan yetkili bir hesapla bağlanarak Computer Management içerisindeki Local Users and Groups altındaki Users kabında, düzenleme yapılacak kullanıcı seçilir ve sağ tıklanarak açılan menüden Properties seçilir.

Bir domain kullanıcı hesabının özelliklerine girdiğinizde aşağıdaki ekran ile karşılaşırsınız.

Şekilde görülen özellikler standart bir sistemdeki kullanıcının standart özellikleridir. Şimdi bu standart özellikleri sırasıyla açıklayalım.

GENERAL SEKMESİ

Bu sekme içerisinde kullanıcıya ait genel bilgiler bulunmaktadır.

Kullanıcının Adı (First Name), Soyadı(Last Name), Active Directory Users and Computers konsolu içerisinde ve Exchange Adres defteri gibi yerlerde görünen adı (Display Name), kullanıcı ile ilgili tanımlayıcı bir bilgi (Description), kullanıcının web sayfası, telefon bilgileri buraya girilir. Telefon ve web sayfası kısımlarına eğer kullanıcının birden fazla telefon ve web adresi varsa Other butonuna tıklayarak açılan pencereden girilir. Şirket içerisindeki çalışanlarınıza ait olan kullanıcı hesapları üzerinde bu bilgilerin eksiksiz olarak doldurulması size yönetim esnasında önemli ölçüde fayda sağlayacaktır. Özellikle grup üyeliklerini belirlerken, ya da domain içerisinde bir arama yaparken kullanıcı özelliklerine girilen hemen hemen bütün kriterlere göre filtreleme yapılarak kolaylıkla istenilen hesaplara ulaşılabilir.

ADDRESS SEKMESİ

Kullanıcıya ait adresleme bilgileri (cadde, sokak, il, ilçe, ülke, posta kodu vb.) bu sekme içerisinde tanımlanmaktadır.

ACCOUNT SEKMESİ

Kullanıcı hesabı özelliklerindeki en önemli sekmelerdendir. Bir kullanıcının domain’e logon olurken kullandığı iki isim olduğunu makalemizin ilk bölümünde de bahsetmiştik. Bunların birincisi User Logon Name (pre-Windows 2000) , diğeri de User Principal Name(UPN ismi)’dir. User Logon Name (pre-Windows 2000), Windows XP ve öncesi istemcilerde logon olma esnasında Logon Information diyalog kutusunda,  kullanıcı adını user namekutusuna yazıp, password kutusuna şifreyi girip, en alttaki Log on To kutusundan da domain adını seçerek ya da UserName kutusuna DomainAdi\Kullaniciadi şeklinde girip, password kutusuna da şifreyi girerek yaptığımız logon olma yöntemidir. Bu tip logon olma hem Windows 2000 öncesi hem de Windows 2000 sonrası tüm istemci ve sunucu bilgisayarlar tarafından desteklenmektedir. Bu tip logon olmada kullanılan isim User Logon Name (pre-Windows 2000) altına girilen isimdir. Bir diğer deyişle User Logon Name (pre-Windows 2000) DomainAdı\KullanıcıAdı formatındaki isimdir. Normalde user logon name altına ne verilirse user logon name (pre-Windows 2000) kutusuna da aynısı gelir. Fakat isterseniz  user logon name (pre-Windows 2000) farklı verebilirsiniz. User Principal Name ise, user logon name kutusuna girilen isimle domain adının aralarına @ işaretini alarak birleşmiş hallerindeki logon ismidir. Örneğin, user logon name: Aladagm, domain adı da mesutaladag.local olduğunda user principal name(UPN ismi)  AladagM@mesutaladag.local şeklindedir. Dolayısıyla kullanıcı UPN ismini kullanarak da mail adresi formatındaki isimle domain’e logon olabilir. Bunun bize sağladığı avantaj, kullanıcının hangi domainde olduğunu bilmesine gerek kalmadan e-posta adresleri ile kullanıcıların logon olmasını sağlamaktır. Artık Logon diyalog kutusuna Aladagm@mesutaladag.local  yazarak da domain’e logon olabilirsiniz. User Logon Name (pre-Windows 2000) ile  logon olduğumuzdaki izinlerle, UPN ismini kullanarak logon olmadaki izinler arasında hiçbir farklılık yoktur. Fakat UPN ismi ile logon olmayı sadece Windows 2000 ve sonrasındaki istemci ve sunucu sistemleri destekler. Yani bir Windows 9X, Windows NT 4.0 bilgisayarından UPN ismi ile logon desteklenmiyordu.

                Logon Hours butonuna bastığınız zaman karşınıza aşağıdaki ekran gelir ve bu kullanıcının sisteme hangi saatlerde girip giremeyeceği ayarlanır.

Kullanıcının hangi zaman aralıklarında sisteme girmesini engellemek istiyorsanız bu aralıkları seçerek Logon Denied seçeneğine tıklamanız yeterlidir. Bir kullanıcı oluşturulduğu zaman, logon olma saatleri 7/24 Logon Permitted şeklindedir. Yani kullanıcı domaine 7/24 bağlantı gerçekleştirebilir. Özellikle kullanıcınızın izinli olduğu günlerde, domaine logon olmasını burayı kullanarak engelleyebilirsiniz. Böylece kullanıcı şirket dışında iken onun kullanıcı adını bilenlerin şifresini de tahmin ederek sisteme giriş denemeleri yapmalarının önüne geçmiş olursunuz.

Logon To butonuna basarak bir kullanıcının sisteme hangi bilgisayarlardan logon olabileceği belirlenir. Varsayılan olarak bir kullanıcı domaine, o domainin üyesi olan herhangi bir bilgisayardan logon olabilir. Fakat bu pek istenen bir durum olmadığından dolayı Logon To kullanılarak bu olaya bir çözüm getirilebilir. Logon To seçeneğini seçtiğinizde aşağıdaki ekranla karşılaşırsınız.

Bu ekranda The following computers seçeneğini  işaretleyerek, kullanıcının logon olacağı bilgisayarların isimlerini listeye ekleyebilirsiniz. Böylece domaine bu kullanıcı hesabı ile sadece bu bilgisayarlardan giriş yapabilirsiniz.

Account is locked out:

Bu seçenek Windows Server 2003 ve öncesi ile Windows Server 2003 sonrasında görüntü olarak aşağıdaki gibi bir farklılık gösterdi.

Yukarıdaki şekilde de görüldüğü gibi W2K3 ve öncesi zamanlarda bu seçenek normalde aktif değildi. Kullanıcı hesabı çeşitli nedenlerden dolayı kilitlendiği zaman (ki biz buna account lockout diyoruz.)  bu kutucuk aktifleşir,  bu kutucuğu tekrar boşaltarak kullanıcı hesabının kilidi kaldırılır ve domain’e logon olması sağlanmış olurdu. Örneğin; Domain Security Policy içerisinde Account Lockout Policy ayarlarında Account Lockout Threshold değeri 3 olarak ayarlanmışsa, bir kullanıcı şifresini logon olma esnasında arka arkaya 3 defa yanlış girerse, veya başkası tarafından kullanıcının şifresi tahmin yoluyla bulunmak istenip şifre 3 defa arka arkaya yanlış girilmişse kullanıcının hesabı kilitlenecektir. Dolayısıyla   bu kilitlenen hesabın tekrar kullanılabilmesi için kilidinin kaldırılması gerekir. Kilitlenen   kullanıcı hesabını açmak için bu kutucuğun boşaltılması yeterli idi. Windows 2008 ve sonrasında ise bu kutucuk doldurularak kilitlenen kullanıcı hesabının kilidi açılıyor artık. Hesabi kilitlenen bir kullanıcının Account sekmesindeki account lockout görünümü aşağıdaki şekilde olacaktır:

İşte bu durumda hesabın kilidini açmak için Unlock account kutucuğu doldurularak OK ile onaylanıp kullanıcı hesabının kilidi açılacaktır.

Account Expire : Kullanıcı hesabının geçerlilik ya da kullanım süresini Account Expire seçeneği ile belirleyebilirsiniz.

§  Never :  Kullanıcını hesabının hiçbir zaman süresi dolmasın.

§  End of: Belirtilen tarihte kullanıcı hesabının kullanımı sona erer. Bu seçenek şirket içerisindeki geçici kullanıcılar ya da stajerler için kullanılır. Eğer süre dolduktan sonra da kullanıcı hesabı kullanılmaya devam edecekse buradan süre uzatılmalıdır.

Account Seçenekleri (Account Options):

User must change password at next logon : Bu seçeneği seçtiğinizde, kullanıcının bundan sonraki ilk log on olma işlemi sırasında şifresini değiştirmesi ile ilgili olarak bir uyarı ile karşılaşmasına ve yeni bir şifre vermeye zorlanmasını  sağlayabilirsiniz . Bu işlem sadece ilk logon olma esnasında gerçekleşir ve kullanıcı şifresini tanımlarsa bir daha şifre süresi dolana kadar karşısına gelmez. Bu seçenek yeni bir kullanıcı sisteme logon olduğunda veya kullanıcı şifreyi unutursa ve admin kullanıcının şifresini resetlemesi gibi durumlarda kullanılır.