Kullanıcılarınızın masa üstü öğeleri, browser için sık kullanılan linkleri veya kişisel ayarlarının her logon olduğunda sıfırlandığını düşünün? Böyle bir ortamda kullanıcıların çalışması mümkün olmayacaktır. Alışkın olduğumuz kullanıcı masa üstleri için aslında böyle bir risk yoktur. Çünkü mevut bir laptop veya masa üstü bilgisayarı kendileri için sabit olarak kullanmakta ve hep aynı kullanıcı profilini yüklemektedir. Ancak VDI ortamlarında işler biraz değişiktir. VDI ortamlarındaki kullanıcı profil yönetimine geçmeden önce kısaca VDI nedir ondan bahsetmek istiyorum.

VDI teknolojisi Sanal Masaüstü Altyapısı’ dır. Veri merkezimizin içinde bulunan Sanal bilgisayarların uzak masa üstü protokolleri sayesinde son kullanıcılarımızın hizmetine sunulmasıdır. Sanallaştırma teknolojileri içinde bulunan ve belki de toplam sahip olma maliyetlerinde azalma göstermeyen ve aksine toplam sahip olma maliyetlerinde artış gösteren bir sanallaştırma çözümüdür. Çünkü VDI teknolojisinde yatırım son kullanıcı bilgisayarlarına değil, veri merkezlerimizin içine yapılmaktadır. Bu sebepten ötürü, veri merkezi yatırımları pahalı olduğu için maliyetlerimizi arttıran bir teknolojidir.

VDI teknolojisiyle ilgili yanlış bilinen bir inanç vardır. Birçok kurum şu düşünce içinde olabilirler;

“VDI teknolojisiyle birlikte son kullanıcı aygıt yatırımını düşürdük ve son kullanıcılarımıza Aptal Terminaller tahsis ettik, son kullanıcılarımıza zengin kaynaklara sahip bir donanım vermedik. Böylelikle VDI teknolojisi sayesinde toplam sahip olma maliyetlerimizde tasarruf elde ettik”

Yukarıda aktarılan düşünce yanlıştır!

VDI teknolojisi incelendiği zaman son kullanıcılarımızın kullanmış oldukları aygıtlar sadece VDI bileşenlerinden bir tanesidir. VDI teknolojisi bir bütün olarak incelendiği zaman pahalı ve hatta toplam sahip olma maliyetlerinde artış gösteren bir teknoloji olduğu tespit edilecektir.

Peki, VDI tanımını yaptık isek eğer şimdi sıra geldi kullanıcı profillerinin önemine. Yukarıda da özetlediğimiz gibi kullanıcılar artık basit istemcilerden veya son günlerin modası olan BYOD dediğimiz (bring your own device) yani çalışanların kendi mobil aygıtları üzerinden şirket kaynaklarına erişmesi modelinde masa üstünüz hep sabit olmalıdır.

Bu ve bunun gibi pek çok nedenden dolayı VDI ortamlarında kullanıcı profil yönetimi büyük önem taşımaktadır.

VDI için bir adet golden imajdan sonra kullanıcı tarafından yapılan her şey ( masa üstü arka planı, uygulama ayarları, Windows ayarları, masa üstü, belgeler ve benzeri klasörlerdeki dosyalar) profili üzerinde kayıt edilir ve bizimde amacımız bu profili herhangi bir VDI ortamında (sanal masa üstü) logon olursa olsun aynı kullanıcı deneyimi yaşatmasını sağlamaktır. Eğer işletmenizin ihtiyaçları doğrultusunda kullanıcıların herhangi bir şekilde kişiselleştirmeye gitmesini istemiyorsanız, ya da yaptığı tüm değişiklikler log off sonrasında ilk haline dönmesini istiyorsanız buna mandatory profiles denir ki bu bizim şu anda üzerinde durduğumuz bir konu değildir. Ancak bunu da bir çözüm olduğunu ve kullanıldığını söylemek isterim.

Kullanıcı profil yönetimi denince pek çok ürün olduğunu ve bunlardan bazılarının özellikle VDI ortamları için geliştirildiğini görebiliyoruz.

Peki, masa üstünü sanallaştırmadan önce profilleri ne yapmalıyız? Buradaki en önemli fikir tabiki artık profilleri yerel disklerde tutmamak olacaktır. Bu sayede User State Virtualization (USV) dediğimiz kullanıcıların yönetilen tüm cihazları için aynı kullanıcı deneyimi yaşamasını sağlayabileceğiz. USV, kullanıcıların her zaman kişisel tecrübelerine yönetilen herhangi bir cihaz üzerinden erişmesi demektir. Temel anlamda kullanıcının herhangi bir bilgisayardaki dosyaları, ayarları gibi kendisine ait kişiselleştirilmiş bilgileri tüm makinelerden sunmaktır. Bu sayede kullanıcıların herhangi bir yerden herhangi bir zamanda çalışmasına yardımcı olarak üretkenliği arttırılabilir. Bu özelliğin Microsoft tarafından sağlanması için Folder Redirection, Roaming Profile, One Drive Pro, Offline Files gibi teknolojiler birlikte kullanılabilir. Ben ise makalemde mevcut bu teknolojilerden roaming ve folder rediretion’ dan bahsedeceğim.

Not: Ek olarak Windows Server 2012 ile RDS ortamları için sunulan User Profile Disk teknolojisi için aşağıdaki makaleyi inceleyebilirsiniz.

Makale

Öncelikle VDI ortamları ile yerleşik bilgisayar ortamlarındaki en büyük fark aslında mobil platform kullanımıdır. Yani şirket çalışanları ister şirket içerisinde masa üstü bilgisayarı, ister yine şirket içerisinde toplantıda kullandığı laptop, veya evindeki tablet yada cep telefonu ile aynı kullanıcı deneyimi yaşamak ister. Durum böyle olunca da bunu Active Directory Roaming Profile ile sağlayabilirsiniz. (VDI Floating Pool)

Roaming Profile için temel çalışma mantığı son derece basit olup AD üzerinde kullanıcı için profile path tanımlanır ve kullanıcı çalışma yaptıktan sonra log off olur, log off sırasında o makinedeki tüm dosyalar sunucu üzerine gönderilir. Daha sonra evine gittiğinde tablet bilgisayarı ile sanal masa üstüne bağlandığında logon olurken sunucu üzerinden tekrar bu profil bilgileri yüklenir ( Aslında bu yükleme tablet bilgisayara olmaz, tablet bilgisayar üzerine kullandığınız VDI alt yapısının bir istemcisini kuruyorsunuz ve bu istemci yazılımı ile sanallaştırma sunucularına bağlanıyorsunuz.

Bu senaryo içerisinde aklınıza bazı durumlar takılabilir, bunlardan ilki çalışanlarınızın log off olmaması. Evet bu kötü bir durum olup log off olmaması durumunda bu bilgiler sunucu üzerine yazılmayacağı için başka bir bilgisayardan profil’ e ulaştığı zaman en güncel profili yüklenmeyecektir. Hatta zaman damgası mantığı ile çalıştığı için evdeki pc de çalışır, sonra şirketteki makineyi log off olmadan kapatıp açar ise o makinedeki çalışmaları da log on olurken ezilir. Bu tür senaryolar için tabiki çözümlerimiz var. Bunlardan ilki roaming profile ile beraber folder redirection dediğimiz profil içerisindeki belgelerinizin, masa üstü çalışma alanınızın aslında size ayrılan bir file server üzerinden çalışması, bu sayede siz log off olmasanız bile yazdığınız tüm işler sunucu üzerinde olacaktır. Folder redirection yoğun bir network kullanımına neden olur, çünkü aslında kullandığınız masa üstü ve belgelerim gibi ( bunları seçebilirsiniz) yollar, direkt olarak file server üzerinden okuma ve yazma yapmaktadır.  Bu bahsettiğim ikinci yöntem yani Roaming Profile ile Folder Redirection çözümlerinin beraber kullanılması aynı zamanda logon ve log off sürelerini de kısaltacaktır. Çünkü roaming profile için tüm kullanıcı profilinin yeni bir makineye yüklenmesi bazen ciddi bir zaman alabilir. Veya mevcut bir makinede hızlı bir şekilde logon oldu ancak 5GB lık bir veri çalışması yaptı ve log off olarak şirketten çıkmak istiyor, bu durumda bu 5GB’ ın sunucuya atılmasını beklemek zorundadır.

Peki, gelelim uygulama tarafına, aslında bu bölüm bir hayli uzun sürecek, yani Roaming Profile ile başlayıp Folder Redirection’ ın beraber kullanma senaryolarına kadar adım adım uygulamalı bir anlatım planladım, ancak her bir demo için ortam hazırlamak ve tek bir solukta yazmak benim iş yoğunluğumda uzun bir zaman alacağı için bölüm temeli yazıp sizler ile paylaşmak istiyorum.

İlk olarak Roaming Profile ile başlıyorum.

Romaing Profile için aşağıdaki gibi bir yol izlememiz gerekmektedir;

·         Farklı profil sürümlerinin desteklenmesi 

·         Roaming User Profiles için bir security group oluşturmak

·         Roaming user profiles için bir dosya paylaşımı hazırlamak

·         Roaming User Profiles için isteğe bağlı olarak GPO oluşturmak

·         Roaming User Profiles ayarlarının kullanıcılar için tanımlanması

·         Roaming User Profiles için isteğe bağlı bilgisayar ayarları

·         Roaming User Profiles için tanımlanan GPO’ nun devreye alınması

·         Test İşlemleri

Farklı Profil Sürümlerinin Desteklenmesi 

Kullanmış olduğunuz işletim sisteminin sürümüne göre kullanıcı profilleri farklılıklar göstermektedir. Yani ilk olarak bir Windows 7 de oturum açan bir roaming user daha sonra bir Windows 8 de oturum açar ise veya tam tersi bir Windows 8 de oturum açan roaming user sonrasında Windows 7 makineye logon olursa tek olarak tutulan bu profil dosyası her iki işletim sisteminin tüm ayarlarını doğru bir şekilde yapılandırmak için yeterli değildir. Bu nedenle aşağıdaki gibi profil versiyonları bulunmaktadır.

Windows 7 - Windows Server 2008 R2= v2
Windows 8 - Windows Server 2012 = V3
Windows 8.1 - Windows Server 2012 R2 = V4
Windows 10 = V5

Yukarıdaki örnekte aynı kullanıcı için iki adet farklı sürümü görebiliyoruz.

Ancak varsayılan olarak bu özellik açık olmadığı için aşağıdaki gibi iki işletim sistemi sürümü için hotfix yüklemeniz ve bir kayıt defteri ayarı değiştirmeniz gereklidir.

Windows 8.1 ve Server 2012 R2 için http://support.microsoft.com/kb/2887595

Windows 8 ve Server 2012 için http://support.microsoft.com/kb/2887239

Kayıt defteri girdisi aşağıdaki gibi olup değeri “1” olacaktır

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ProfSvc\Parameters\UseProfilePathExtensionVersion

Bunu GPO ile aşağıdaki gibi tüm makinelere uygulayabilirsiniz

Artık sürüm desteğine kavuştuğumuza göre ikinci adıma geçebiliriz.

Roaming User Profiles için bir security group oluşturmak

Bu adım son derece basit olup örneğin “Roaming User Profiles Users and Computers” ismin de bir Security – Global grup oluşturuyoruz.

Roaming user profiles için bir dosya paylaşımı hazırlamak

Bu adımda ise kullanıcı profil dosyaları için bir file server üzerinde paylaşım oluşturacağız. Bunun için öncelikle Server Manager ekranında “File and Storage Services” düğümüne geliyoruz ve Share kısmına tıklayarak paylaşımların gösterildiği ekranı açıyoruz.

Sağ üst köşedeki Task menüsü altından New Share diyerek yeni bir paylaşım oluşturmak için sihirbazı açıyoruz.

Karşımıza çıkan ekranda SMB Share Quick diyerek ilerliyoruz. Eğer siz içerik ve kota yönetimi gibi sunucu tarafında beklenmedik bir yoğunluk oluşumunu engellemek istiyorsanız SMB Share Advanced seçeneği ile ilerleyebilirsiniz.

Hangi sunucu ve volume üzerinde paylaşım açacak ise onu seçiyoruz ( Server manager üzerinden birden çok sunucuyu yönetme şansınız olduğu için birden çok sunucu üzerinde de paylaşım açabilirsiniz)

Paylaşım için anlamlı bir isim veriyoruz, sonuna $ işaretini koyarak isek herkesin görmesini istemediğimiz gizli bir paylaşım olmasını sağlıyoruz.

Bu bölümdeki seçenekler isteğinize bağlı olup ben yine bir kişinin bir paylaşım üzerinde yetkisi olmayan klasörleri listelememesi için “Enable access-based enumeration” kutucuğunu işaretliyorum.

Bir sonraki bölüm ise izinler. Bu bölüm son derece kritik bir öneme sahip olup gösterilen izinleri uygulamak güvenlik açısından en doğru konfigürasyonu yapmanızı sağlayacaktır.

İlk olarak karşımıza çıkan ekranda “Customize permissions” linkine tıklıyoruz.

Daha sonra açılan pencerede “Disable inheritance” ve ardından karşımıza çıkan uyarı ekranında

Kırmızı işaretli linke tıklıyoruz.

Daha sonra ise izinleri yukarıdaki tabloda gösterildiği gibi tanımlıyoruz.

İzinlerin son hali yukarıdaki gibidir.

Artık Roaming Profile için gerekli olan dosya paylaşımını tamamlamış bulunuyoruz.

Evet adımlarımıza makalemin bir sonraki bölümünde devam edeceğim. Umarım bu bölüme kadar faydalı bir makale olmuştur, bir sonraki bölümde görüşmek üzere.

Kaynaklar

http://searchvirtualdesktop.techtarget.com/tip/User-profile-management-tools-16-options-to-consider

http://searchvirtualdesktop.techtarget.com/feature/Tips-for-VDI-user-profile-management

https://technet.microsoft.com/en-us/library/jj649079.aspx#EnableProfileVersions

Makalemin VDI tanımı Fatih Karaalioğlu’ nun aşağıdaki makalesinden alıntıdır

http://www.cozumpark.com/blogs/citrix/archive/2012/07/15/citrix-flexcast-teknolojisi-bolum1-sunucu-bilesenleri-ve-vdi-nedir.aspx

Makalemin ilk bölümünde genel olarak VDI, Roaming Profile, User State Virtualization, Folder Redirection gibi kavramlardan bahsetmiş ve uygulama olarak ise Roaming User Profile için gerekli adımları listelemiş ve bu adımlardan ilk 3 tanesinin nasıl yapılacağını sizler ile paylaşmamıştım.

Makalemin ilk bölümüne aşağıdaki link üzerinden ulaşabilirsiniz.

Bölüm1

Bu bölümde ise kaldığımız yerden roaming user profile uygulamasına devam ediyoruz.

·         Farklı profil sürümlerinin desteklenmesi 

·         Roaming User Profiles için bir security group oluşturmak

·         Roaming user profiles için bir dosya paylaşımı hazırlamak

·         Roaming User Profiles için isteğe bağlı olarak GPO oluşturmak

·         Roaming User Profiles ayarlarının kullanıcılar için tanımlanması

·         Roaming User Profiles için isteğe bağlı bilgisayar ayarları

·         Roaming User Profiles için tanımlanan GPO’ nun devreye alınması

·         Test İşlemleri

İlk 3 adımı gerçekleştirmiş ve 4. Adım ile devam ediyoruz.

Roaming User Profiles için isteğe bağlı olarak GPO oluşturmak

Eğer Roaming User Profile ayarlarını GPO ile yönetmek istiyorsanız bir OU oluşturabilir ve buna şimdilik boş bir GPO bağlayabilirsiniz. Makalemin ilerleyen bölümlerinde bunun detaylarını paylaşıyor olacağım. Şimdilik GPO oluşturmayı paylaşacağım.

Hatırlarsanız makalemin ilk bölümünde Roaming User Profile için bir grup oluşturmuş ve ilgili kullanıcıları bu gruba eklemenizi tavsiye etmiştim, şimdi ise GPO kaynaklı benzer bir aksiyon alacağız, bir OU oluşturup bu kullanıcıları da bu OU altına taşıyacağız.

OU oluşturduktan sonra buna boş bir GPO bağlıyoruz.

GPO oluşturduktan sonra sağ tıklıyoruz ve link kısmını kaldırıyoruz.

Bu sayede artık yapacağımız GPO değişiklikleri biz tekrar bağlayana kadar geçerli olmayacaktır.

Şimdi GPO Security Filter bölümünü de aşağıdaki gibi güncelliyoruz.

Yaptığımız işin özeti, burada var olan “Authenticated users” grubunu kaldırıp, roaming için tanımlamış olduğumuz grubu eklemektir.

Bu adımı da tamamlamış olduk. GPO içeriğini Roaming Profile ince ayarlarında ayrıca anlatacağım. Ama anlatacağım GPO ayarlarının çalışması için bu alt yapının hazır olması gerekmektedir. Eğer GPO ile Roaming Profile için herhangi bir ayar değişikliği yapmayacaksanız bu bölümü atlayabilirsiniz.

Roaming User Profiles ayarlarının kullanıcılar için tanımlanması

Bu bölümde ise AD üzerinde kullanıcıların profile yolu bilgisini tanımlayacağız. Bunun için ilgili kullanıcıyı bulup Profile Sekmesine aşağıdaki gibi yolu tanımlıyoruz;

\\fs1.cozumpar.local\UserProfiles$\%username%

Öncelikle burada dikkat etmeniz gereken bu kullanıcının her ortam için, yani kendi bilgisayarı veya bir terminal server – VDI ortamı için roaming kullanmasını istediğimden dolayı Profile sekmesini kullanıyorum. Bazı şirket ortamlarında şube yapısında kullanıcıların kendi bilgisayarlarına girerken Roaming Profile olmaması, yani local profil ile çalışmaları ancak RDS sunucularına bağlanırken belirli bir yerden profil çekmesini ve yine RDS den çıkarken bu profili güncellemesini veya tam tersi Mandatory Profile dediğimiz yöntem ile çıkışta bilgilerin kayıt edilmemesi için farklı bir sekme kullanıyoruz. Bu sekmenin ismi ise “Remote Desktop Services Profile”. Burada yapacağınız ayarlar lokal profile için geçerli olmayıp sadece RDS’ e erişim durumunda aktif olacaktır.

Yazım şekline dikkat ederseniz %username% gibi bir sonra ek kullanıyoruz ve uygula dedikten sonra aşağıdaki gibi aslında kullanıcı adına dönüyor.

Bunun temel sebebi, siz yüzlerce veya binlerce kişinin profil ayarlarının aynı anda değiştirmek istediğinizde size kolaylık sağlamak içindir.

Yukarıda gördüğünüz gibi istediğiniz kullanıcıları seçtikten sonra profile tabına yolu yazıp sonuna %username% demeniz herkesin klasörünün kendi hesap ismi ile ayrılacağını gösterir.

Roaming User Profiles için isteğe bağlı bilgisayar ayarları

Eğer kullanıcı bazlı değil de makine bazlı Roaming profile uygulamasını kullanmak istiyorsanız bu durumda GPO ile ilgili makinelere oturum açan kullanıcılar için bir yol belirtmemiz gerekmektedir. Yani sizin kullanıcılarınız aslında roaming profile kullanmayacak, ancak bazı makinelere logon olan kullanıcılar ki bu Terminal Server’ lar olabilir, giriş yaptıklarında arka planda bir havuz olduğu ve en uygun sunucu hangisi ise ondan oturum açacağı için bu makinelerde roaming profile kullanımı mantıklı olabilir. Böyle bir durum için yukarıda oluşturduğumuz GPO objesinin aşağıdaki gibi düzenliyoruz.

Computer Configuration - Administrative Templates - System - User Profiles  Bölümünde “Set roaming profile path for all users logging onto this computer” seçeneğine çift tıklıyoruz ve aşağıdaki gibi roaming user profile için ayarlanmış olan paylaşımın yolunu gösteriyoruz.

Roaming User Profiles için tanımlanan GPO’ nun devreye alınması

Makalemin başında belirtmiş olduğum GPO objesini tekrar ilgili OU’ ya bağlayarak aşağıdaki bölümden temel anlamda yönetim sağlayabilirsiniz.

Eğer bu OU ya makine da koyarsanız ki özellikle RDS gibi Roaming Profile kullanılacak makineler, daha çok seçeneğiniz olacaktır. Yukarıdaki seçenekler sadece kullanıcı policy için geçerlidir. Ancak aşağıdaki seçenekler makineler için geçerlidir.

Örneğin Roaming User Profile uygulamadan önce kullanılacak bilgisayarların bulunduğu OU için aşağıdaki ayarları yapmanızı tavsiye ederim.

Computer Configuration > Policies > Administrative Templates > System > User Profiles

Altında “Add the Administrator security group to roaming users profiles” bölümüne “Enable” yapıyoruz. Bunun temel nedeni, bir kullanıcı bir bilgisayarda ilk defa oturum açtıktan sonraki ilk log off sırasınca profilini ortak dizine gönderecektir. İşte bu klasörün yöneticiler tarafından da görüntülenmesi için ACL değişikliği yapılmasını sağlar. Eğer bunu yapmadan RUP sürecine başlarsanız, bu GPO dan önceki profil dosyalarına admin hakları ile erişmeniz mümkün değildir. Eğer dosya sahipliğini alıp erişirseniz bu durumda ise kullanıcı profilini yükleyemez.

Hakan kullanıcısı için bu hakkımız yok ancak bu GPO’ yu istemci bir makineye uygular, sonra bu makinede RUP ayarları başka bir kullanıcı olan Serkan kullanıcısı ile giriş yaparsak sonuç aşağıdaki gibi olacaktır.

Bu adımı da tamamladıktan sonra test işlemlerine başlayabiliriz. Bu işlemleri makalemin bir sonraki bölümünde sizler ile paylaşıyor olacağım.

Kaynaklar

http://searchvirtualdesktop.techtarget.com/tip/User-profile-management-tools-16-options-to-consider

http://searchvirtualdesktop.techtarget.com/feature/Tips-for-VDI-user-profile-management

https://technet.microsoft.com/en-us/library/jj649079.aspx#EnableProfileVersions

Makalemin ilk iki bölümünde temel kavramlar ve Roaming Profile için uygulama adımlarınızı sizler ile paylaşmıştım. Bu bölümde ise Roaming Profile için test adımları ve Folder Redirection uygulaması ile devam edeceğim.

Makalemin ilk iki bölümüne aşağıdaki linkler üzerinden ulaşabilirsiniz

Bölüm1
Bölüm2

Tüm hazırlıkları bitirmiş ve Roaming Profile için “hakan uzuner” isimli kullanıcıyı seçmiştik. Şimdi bu kullanıcı ile Windows 8 bir makinede logon olarak çalışalım, sonra biraz dosya çoğaltıp log off olalım ve bu dosyalardan bir profil klasörünü oluşmuş mu kontrol edelim.

Logon işleminden önce profil dosyası yok.

Windows 8 işletim sistemine lokal olarak logon oluyorum.

Kısa bir çalışma sonrasında log off oluyorum ve file server’ ı kontrol ediyorum.

Evet, profil dosyam oluşmuş, hem de versiyon bilgisi ile ( hatırlarsanız bunun için bir yama ve kayıt defteri değişikliği yapmıştık.

Şimdi bu işletim sistemi için bir takım çalışmalar yapıyorum.

Yukarıda gördüğünüz gibi W8-PC1 makinesinde bu bilgiler kayıtlı. Şimdi log off olup diğer PC ye logon oluyorum.

Gördüğünüz gibi farklı bir PC ye giriş yapmamız rağmen çalışma dosyalarımızı görebiliyoruz. Yani Roaming Profile sorunsuz bir şekilde çalışmaktadır.

Gelelim bu log on ve log off zamanının düşürme ayarlarına. Bildiğiniz gibi zaten makalemin konularından biri de bu, yani Folder Redirection, ancak ondan önce GPO ile de birkaç tane ayar deneyebilirsiniz.

Özetlemek gerekir ise, Roaming Profile çözümlerinde log on ve log off zamanlarını aşağıdaki 2 temel adım ile düşürebiliriz;

Folder Redirection

GPO –Computer Configuration altında

Configuration\Policies\Administrative Templates\System\User Profiles and User

Configuration\Policies\Administrative Templates\System\User Profiles

Bu GPO örneklerinden birisi “Background upload of a roaminguser profile's registry file while the user is logged on” Bu arka planda kullanıcının HKCU kayıt defteri bölümünü belirli aralıklar ile profile yoluna kopyalar, bu sayede kullanıcı ayarlarını almış olursunuz.

Şimdi ise hangi durumlarda RUP, hangi durumlarda FR veya hangi durumlarda her ikisini bir arada kullanabiliriz konusunun senaryo bazlı inceleyelim.

Senaryo1

Bir şirket çalışanı şirket network bağlantısı içerisinde dokümanlarına her bilgisayardan erişmek istiyor, ancak kişisel ayarlarını görmek gibi bir talebi yok. Örneğin bir üniversite öğrencisi, üniversite kampüsünde ki herhangi bir bilgisayardan kendi Word ve benzeri proje dokümanlarına erişmek ister, ama kişisel masa üstü ve benzeri kullanımı veya ihtiyacı yoktur. Bu durumda en iyi çözüm Folder Redirection’ dır.

Senaryo2

Bu senaryoda da şirket çalışanı şirket network bağlantısı içerisinde dokümanlarına ve bazı uygulamaları için kişisel ayarlarına her bilgisayardan erişme ihtiyacı vardır ( örneğin Office uygulamalarındaki yaptığı kişiselleştirmeler gibi). Örneğin bir avukat kendisinin davalar için kişiselleştirdiği Office dokümanlarına ve hatta sözlüğünü düzenlediği Word programına erişmek isteyebilir. Bu durumda da çözüm Folder Redirection olarak görülüyor. Kullanıcının “Documents” klasörünü ve “App Data(Roaming)” klasörlerini yönlendirmeniz yeterlidir.

Senaryo3

Bu senaryoda da şirket çalışanı şirket network bağlantısı içerisinde dokümanlarına ve tüm kişiselleştirilmiş profiline herhangi bir bilgisayardan erişmek istemektedir. Bu senaryodan zaten çözümün Roaming User Profile + Folder Redirection olduğunu görebiliyoruz.

Peki, şimdi mevcut bu yapı üzerine Folder Redirection özelliğini nasıl ekleyebiliriz.

Öncelikle bunun için ihtiyaçları belirlemek gereklidir. Yani neden Roaming Profile kullanılan bir yapıda Folder Redirection kullanma ihtiyacınız var? Bunlardan birisi log on ve log off sürelerini düşürmek olabilir. Malum büyük boyutlu dosyalar ile çalışan tasarımcı ve benzeri iş pozisyonu için çok uygun görünmeyen romaing profile çözümünün VDI ve benzeri mimarilerde kullanılmasının zorunlu olması durumunda alternatif çözüm yöntemlerinden biri olabilir. Örneğin şirketinizin yöneticileri çalışanların daha esnek ve üretken olması için mobil çalışmaya teşvik ediyor ancak bununda bir takım güvenlik zafiyetleri doğurmasından korkuyordur. Örneğin tasarımcı veya yazılımcılar evden, işten herhangi bir yerden herhangi bir zamanda hep aynı kullanıcı deneyimi kazanmak için VDI çözümü ile ilerleyebilirsiniz. Bu sayede kullanıcılar kendi laptoplarından, tablet bilgisayarlarından veya şirketin vermiş olduğu cihazlardan bağlantı yapabilir ancak aynı kullanıcı profili görmek için Roaming kullanmanız gerekebilir. Fakat yukarıda da belirttiğim gibi bazı durumlarda Roaming profile sizi yorabilir.

Burada farklı çalışma modelleri olduğunu bir kez daha hatırlatmak isterim. Eğer Roaming Profile klasik olarak lokal makinelerde kullanılıyor ise, bu durumda bu makinelerin log on ve log off süreleri profildeki değişikliklere bağlı olarak değişecektir. Bunun değiştirmek için Folder Redirection yapılır ise bu durumda ise bu makineler ile file server arasında hızlı bir network bağlantısı olması gerekmektedir. Çünkü folder redirection’ ın temel çalışma mantığı dosyanın lokasyonunu yerel makineden uzaktaki file server olarak değiştirmesi olup tüm okuma ve yazma işlemlerini file server üzerinden gerçekleştirmektedir. Şirket dışında iken bu dosyalara erişimi ihtiyacı olması durumunda ise offline files denilen teknoloji ile ihtiyaç duyulan dosyaları offline olarak kendi bilgisayarınızda saklayabilirsiniz.

VDI veya RDS senaryolarında ise aslında siz bir istemci bilgisayardan ki bu bir thinclient olur, laptop veya tablet olur bu platformlara bağlanıyorsunuz. Yani istemciniz için network hızı veya şirket içerisinde – dışında olması önemli değildir, ancak bağlandığınız makine için yine bu değerler geçerlidir. Örneğin bir terminal server’ a bağladınız ve 5GB lık farklı yeni profili çekmeye çalışıyorsunuz, bu hem terminal server yerel disk kaynakları, hem network kaynaklarını kullanacaktır. Zaten bu ve benzeri durumlar için GPO içerisinde cache size denilen bir ayar ile belirli boyuttan büyük cache dosyalarının silinmesini sağlayarak terminal server gibi ortak kullanılan sunucuların bir kişi tarafından kullanılamaz hale getirilmesinin önüne geçmeye özen göstermeliyiz.

User Configuration\Policies\Administrative Templates\System\User Profiles altında

Limit profile size

Evet daha fazla GPO ve detaya girmeden öncelikle Folder redirection için temel paylaşım gereksinimleri, GPO ayarları ve demo olarak ilerlemek istiyorum. Zaten yine bu makale serimin sonunda bu yapı için tavsiye ettiğim ve etmediğim GPO ayarlarını sizler ile paylaşıyor olacağım.

Folder Redirection adımlarını makalemin bir sonraki bölümünde sizler ile paylaşıyor olacağım.

Makalemin ilk üç bölümünde temel kavramlar ve Roaming Profile için uygulama adımlarını sizler ile paylaşmıştım. Bu bölümde ise Folder Redirection yapılandırması ile devam edeceğiz.

Makalemin ilk bölümlerine aşağıdaki link üzerinden ulaşabilirsiniz.

Bölüm1
Bölüm2
Bölüm3

Öncelikle kısa bir tanım ile başlayalım. FR, temel olarak aşağıdaki gibi listelenen kullanıcı profil klasörü içerisindeki bilgilerin direkt olarak server üzerinden çalışmasını sağlar. Yani log on ve log off sırasında eşitleme ama lokalden çalışma şeklinde değil de, klasörlerin doğrudan yazdığı ve okunduğu yolu network yolu olarak belirttiğimiz bir çözümdür.

Yukarıda işletim sistemine göre hangi klasörleri yönlendirebileceğimiz görüyoruz.

Temel faydaları nedir?

Network üzerinde kullanıcılar istedikleri makinelerden logon olabilirler ve dosyalarına erişebilirler.

Offline Files özelliği ile önemli dokümanları kendi bilgisayarlarında ağ bağlantıları yokken de erişmek üzere saklayabilirler.

Veriler merkezi bir yerde tutulduğu için yedeklemek ve yönetmek kolaydır.

Veriler anlık olarak yazıldığı için log off olmama nedeni ile yaşanabilecek veri kayıplarının önüne geçilmiştir.

Kullanıcı verileri lokal disklerde tutulmadığı için lokal disklerdeki bir sorun veya yeni işletim sistemi kurulumları kullanıcıları etkilemeyecektir.

Merkezi yönetim sayesinde kullanıcılara kota ve içerik yönetimi gibi policyler uygulanabilecektir.

Folder redirection için aynı Roaming User Profile’ da olduğu gibi ilk olarak paylaşım noktasındaki güvenlik ayarlarını yapmamız gerekiyor. Eğer makalemin başındaki gibi Roaming Profile için gerekli olan güvenlik ayarlarını düzgün bir şekilde yapmışsanız aynı dizinleri kullanabilirsiniz. Veya benzer özelliklerde ayrı bir paylaşım da açabilirsiniz.

Size tavsiyem ise ayrı bir paylaşım açmanız olacaktır.

Bunun için öncelikle Server Manager ekranında “File and Storage Services” düğümüne geliyoruz ve Share kısmına tıklayarak paylaşımların gösterildiği ekranı açıyoruz.

Sağ üst köşedeki Task menüsü altından New Share diyerek yeni bir paylaşım oluşturmak için sihirbazı açıyoruz.

Karşımıza çıkan ekranda SMB Share Quick diyerek ilerliyoruz. Eğer siz içerik ve kota yönetimi gibi sunucu tarafında beklenmedik bir yoğunluk oluşumunu engellemek istiyorsanız SMB Share Advanced seçeneği ile ilerleyebilirsiniz.

Hangi sunucu ve volume üzerinde paylaşım açacak ise onu seçiyoruz ( Server manager üzerinden birden çok sunucuyu yönetme şansınız olduğu için birden çok sunucu üzerinde de paylaşım açabilirsiniz)

Paylaşım için bir isim belirliyoruz.

Bu bölümdeki seçenekler isteğinize bağlı olup ben yine bir kişinin bir paylaşım üzerinde yetkisi olmayan klasörleri listelememesi için “Enable access-based enumeration” kutucuğunu işaretliyorum.

Bir sonraki bölüm ise izinler. Bu bölüm son derece kritik bir öneme sahip olup gösterilen izinleri uygulamak güvenlik açısından en doğru konfigürasyonu yapmanızı sağlayacaktır.

Öncelikle hedefimiz olan izinleri bir görelim.

Paylaşım tarafında everyone için full control verebilirsiniz, sonuçta klasör izinlerinde detaylı çalışma yapacağız. Ancak tavsiye edilen FR için bir group oluşturup o grup için Full Control vermek en doğru yöntemdir.

Root yani ana dizin için izinler aşağıdaki gibi olmalıdır.

Root dizini altında kullanıcı yönlendirilmiş dosyası için izinler (Users’ Redirected Folders)

Yukarıdaki izinleri gerçekleştirmek için aşağıdaki gibi ilerlemeye devam edelim.

İlk olarak karşımıza çıkan ekranda “Customize permissions” linkine tıklıyoruz.

Daha sonra açılan pencerede “Disable inheritance” ve ardından karşımıza çıkan uyarı ekranında

Kırmızı işaretli linke tıklıyoruz.

Daha sonra ise izinleri düzenleyip aşağıdaki gibi son duruma getiriyoruz.

Not: listede olmayan ek bir administrators grubuna izin verdim, amacım makale yazarken sizlere bu klasörün için hakkında bilgi vermek.

Daha sonra ilerleyerek paylaşımı tamamlıyoruz.

File server üzerindeki süreci tamamladıktan sonra GPO bölümüne geçebiliriz.

FR için GPO kullanıcı bazlı olup aşağıdaki gibi ulaşabilirsiniz.

Yönlendirmek istediğini klasörün üzerine sağ tıklayıp özellikler demeniz halinde aşağıdaki gibi bir pencere açılacaktır.

Temel olarak ayarlar kısmında “Basic” ve “Advanced” olarak iki seçenek gelir.

Basic – Redirect everyone’s folder to the same location

Bu seçenek, ilgili GPO’ yu alan tüm kullanıcılar aynı yol üzerinde klasör oluşturmasını sağlar. Bu seçeneğin altında ise aşağıdaki gibi 3 temel seçenek vardır

Create a folder for each user under the root path

Bu seçenek örneğin aşağıdaki gibi bize bir yol tanımlamamızı sağlar;

\\server\share\User Account Name\Folder Name

Yukarıdaki gibi bir yol tanımladığınız da kullanıcı bazlı bir ayrım yapmış oluyoruz. Örneğin ben yol olarak “\\rds\userprofiles$\ yazdım sadece, ancak yol aşağıdaki gibi olacaktır

\\rds\userprofiles$\hakan\Desktop

Redirect to the following location, bu seçenek ise aynı klasörün birden çok kullanıcı tarafından kullanılacağı durumlar için düşünülmüştür.

Yukarıda da gördüğünüz gibi bu yol verildiği zaman herkes bu klasörü kullanacaktır, kullanıcı bazlı bir ayrım olmayacaktır.

Redirect to the local user profile location, bu seçenek ise folder redirection özelliğinin devre dışı bırakılmadan önce belgelerin kullanıcının lokal diskine geri gönderilmesi için kullanılır.

Advanced—Specify locations for various user groups, bu seçenek ise klasörlerin grup üyelikleri bazında dağıtılması istendiğinde kullanılmaktadır.

Bu bölümü biraz daha detaylandırmak gerekir ise, aslında temel seçenekler ile aynı olan yine 3 seçeneğimiz var, fakat bundan farklı olarak bu GPO’ yu alan gibi bir kullanıcı mantığından öte bu GPO yu alan ve yukarıda da gördüğünüz gibi seçtiğim grubun üyesi bir kullanıcı için “muhasebe” yolunu seçerken, diğer bir grup için başka bir yol tanımlaması yapabilirim.

Birde ek olarak Follow the Documents folder seçeneği görebilirsiniz ki bunu sadece Music , Pictures , Videos klasörleri için görebilirsiniz. Bu ayarı yapmanız halinde bu 3 klasör dokümanların altına mapleneceği için dokümanlar klasörü ile beraber hareket eder.

Not configured, bu ise varsayılan ayar olup ilgili GPO için Folder redirection seçeneği silinmiş oluyor. Yani artık bu klasörler için ek bir yönlendirme yapmaz, klasörlerin üzerindeki ayar ne ise o şekilde çalışmaya devam eder.

Bir diğer ayar ise Settings bölümünde

“Grant the user exclusive Rights to Desktop”

Bu kutucuğun işaretli olması durumunda kullanıcı için oluşturulan klasörde sadece kullanıcı yetkili olup yönetici olarak erişmeniz mümkün olmayacaktır. Roaming User Profiles için hatırlarsanız benzer bir durum söz konusu olup onun içinde bir GPO ayarı vardı. Tavsiyem bu kutucuğu işaretlemeyin, bu sayede yönetici olarak yönetim hakkına sahip olabilirsiniz.

“Move the contents of Desktop to the new location”

Bu seçenek varsayılan olarak seçili olup mevcut klasörlerin yeni lokasyona taşınmasını sağlar ki bu da istediğimiz bir şey. Ama yok mevcut dosyalar değil bundan sonraki dosyalar taşınsın gibi bir durum isterseniz kutucuğu temizleyebilirsiniz.

“Also apply redirection policy to Windows 2000, Windows 2000 Server, Windows XP, and Windows Server 2003 operating system”

Şimdi biz bir path girişini yapalım

Şimdi GPO uygulanan bir kullanıcı da gpupdate yaptıktan sonra veya bir log off log on olup yani GPO’ yu almasını sağlayalım. Daha sonra yönlendirdiğimiz bu klasör üzerindeki klasörlerin özelliklerinden path bilgisini kontrol edelim.

File server üzerini kontrol edelim.

İçeriğini admin olarak göremiyoruz, ana dizine izin vermiştim ek olarak hatırlarsanız, amacım yukarıdaki gibi ayrı klasörleri göstermekti, ama alt klasörler için yine hatırlarsanız izin vermemiştim. Şimdi kullanıcı tarafından da içeriği bir görelim.

ABE açık olduğu için serkan klasörünü göremiyor kullanıcı, yani sadece yetkisi olan klasörleri görebiliyor. İçine girelim.

Evet burada da masa üstü klasörümüzü görebiliyoruz. Gördüğünüz gibi son derece basit bir şekilde hem Roaming User Profile hem de Folder Redirection uygulamasını kullanarak gerek VDI ortamları için gerekse lokal kullanımlar için kullanıcı profil yönetimini görmüş olduk. Makalemin bu bölümünde daha çok folder redirection üzerinde durmuş olup son bölümünde GPO seviyesinde tavsiye edeceğim ayarları paylaşacağım.

Makalemin ilk dört bölümünde temel kavramlar, Roaming Profile için uygulama adımları ve Folder Redirection adımlarını sizler ile paylaşmıştım. Bu bölümde ise RUP ve FR için tavsiye edeceğim GPO ayarlarını paylaşacağım.

Makalemin ilk bölümlerine aşağıdaki link üzerinden ulaşabilirsiniz.

Bölüm1
Bölüm2
Bölüm3
Bölüm4

İlk olarak GPO tarafındaki tavsiyem

Computer > Policies > Administrative Templates > System altında bulunan “Display highly detailed status messages” Eski ismi “Verbose vs normal status message” ayarı olacaktır.

Bu ayarı açmamız halinde kullanıcı logon ve log off olurken ek olarak yapılan detaylar ekrana yansıtılacaktır. Örneğin “Mapping Drives, Playing Logon Sound, Mapping Printers, Applying Power Settings, Stopping Services” gibi mesajlar ekranda belirecektir. Aslında bunu size logon ve log off işlemlerini hızlandırmak için tavsiye ediyorum J Sorarsanız nasıl yani hızlandırıyor? Aslında hızlandırmıyor ancak sürekli olarak ekrandaki bu bilgiler kullanıcının dikkatini çekiyor ve o da fark etmeden aslında süreç hızlanmış gibi geliyor, bayağı psikolojilerine oynuyoruz yani J Tavsiye ederim mutlaka açın.

Bir diğer ayarı makalemin zaten içerisinde sizler ile paylaşmıştım.

Computer Configuration > Policies > Administrative Templates > Systems > User Profiles altındaki

“Add the Administrator security group to roaming users profiles”

Ayarı. Bu özellikle roaming user profile için yöneticilerinde profile klasörüne erişmesini sağlamaktadır. Malum bazı durumlarda profil klasörleri bozulabilir ve silip yeniden oluşturmak gerekebilir. Böyle durumlar için yöneticilerin bu klasörler üzerine yetkisi olmalıdır.

Bir diğer aya ise yine aynı bölümde yer alan

“Set the schedule for background upload of a roaming user profile's registry file whilw user is logged on” Eski ismi “Background upload of a roaming user profile’s registry file while user is logged on”

Bildiğiniz gibi RUP mimarisinde kullanıcı verileri log off olmadan file server üzerine yazılmıyor. Bunun için robocopy ile bir takım çözümler üretebilirsiniz ancak yerleşik olan GPO ile en azından kullanıcının kendi kişisel ayarlarını içeren kayıt defteri bilgisi belirli aralıklar ile sunucu tarafına atılabilir. Ancak bu kullanıcı verilerini kapsamaz, buna dikkat edin lütfen, sadece kayıt defteri içindir.

Bir diğer policy ise yine aynı bölümde yer alan “Delete user profiles older than a specified number of days on system restart” ayarıdır.

Bu ayar ise kullanıcı profillerini tutan örneğin RDS sunucuları gibi makineler için çok önemlidir. Kişisel bilgisayarlarda genellikle tek bir kullanıcı profili saklandığı için çok sorun olmamak ile beraber bir terminal server için durum değişir. Örneğin 500 kullanıcı bir yapıda 10 adet terminal server olsun ve havuz mantığı ile NLB sayesinde gelen kullanıcılar rastgele en uygun RDS sunucuya gitsin. Bu durumda aslında belirli bir süre sonra bir makinede belki de tüm bu 500 kullanıcı profili saklanıyor olabilir ki bu da o sunucunun yerel disklerinin dolması anlamına gelir. İşte bunu engellemek için bu GPO ayar ile örneğin son 30 gün aktif olmayan profil dosyalarının silinmesini otomatik olarak gerçekleştirebiliriz.

Bir diğer policy ise aşağıdaki yol altında

Users Configuration > Policies > Administrative Templates > Systems > User Profiles

Limit Profile Size

Bu policy yi kullanmanızı tavsiye etmiyorum. Kullanım noktasında iyi bilgilendirme yapmamanız halinde sizi ve kullanıcılarınızı bir hayli üzecektir.

Exclude directories in roaming profile

Eğer Roaming User Profile içerisinde Folder Redirection kullanmıyorsanız bazı uygulamaların gereksiz oluşturduğu büyük boyutlu cache dosyalarının sürekli taşınması ve yer kaplamaması için bu dizinleri bu süreçten hariç tutmak mantıklı olacaktır.

Bir diğer ipucu ise eğer masa üstü veya start menüsünü file server’ a redirect ettikten sonra bu lokasyonlardan herhangi bir kısa yol veya program çalıştırmaya çalıştığınız zaman aşağıdaki gibi bir uyarı alırsanız bunun temel nedeni file server makinesini internet Explorer için trusted site içerisine eklememiş olmanızdır.

Bu işlemi de GPO ile yapabilirsiniz. Ancak tahmin ettiğiniz yerden değil belki J

Gördüğünüz gibi sites bölümü gri yani kullanılamıyor durumda. Bunun için aşağıdaki yolu izliyoruz.

User Configuration > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page altında “Site to Zone Assignment List” ayarlarından bunu yapabilirsiniz.

Sağ bölümde 1-4 arasında rakamları aşağıdaki gibi tablodaki gibi kullanabiliriz.

Evet GPO dendiği zaman malum bu işin sonun getirmek çok zor ancak ilk aşamada tavsiye ettiğim bu GPO ayarları ile daha verimli bir RUP ve FR yapısı kurabilirsiniz.

Bir sonraki makalemizde görüşmek üzere.

Kaynak

http://www.grouppolicy.biz/2010/08/best-practice-roaming-profiles-and-folder-redirection-a-k-a-user-virtualization/

System Center ürün ailesinin bir üyesi olan Service Manager uygulaması sayesinde kurumlar IT süreçlerinde ki Sorun Kaydı (Incident), Hizmet İsteği (Service Request), Değişiklik İsteği (Change Request) vb. işlemleri kayıt altında tutabilmekte ve raporlayabilmektedir. Bu makalemde sizlere Service Manager 2012 Sp1 ürününün Service Manager 2012 R2 sürümüne yükseltilmesini anlatmaya çalışacağım. Upgrade işlemi Self-Service Portal haricinde inplace upgrade i desteklemektedir. Service Manager da güncelleme işlemi için aşağıda ki sıranın takip edilmesi gerekmekte.

Datawarehouse Sunucusu

Service Manager Management Sunucu ya da Sunucuları

Self-Service Portal

Service Manager konsolları

Not: Self-Service portal inplace upgrade işlemini desteklemediği için sıfırdan kurulması gerekmektedir.

Not: Yükseltme işleminin yapılabilmesi için tüm Service Manager bileşenlerinin üzerinde minimum Update Rollup 2 geçilmiş olmalıdır. Aksi halde aşağıda ki hata ile karşılaşılacaktır.

Not: Yükseltme işlemine başlanmadan önce eğer sanal makine kullanılıyor ise full yedek ya da en azından snapshot alınması karşılaşılacak bir olumsuzluk durumunda faydalı olacaktır.

Yükseltme işlemine yukarıda ki sıraya uyarak Datawarehouse sunucumuzdan başlayalım. İşlemi gerçekleştirebilmemiz için tüm Datawarehouse Job larının Not Started durumda olması gerekmektedir. Aksi halde yükseltme işlemi gerçekleştirilemez. Bunu sağlamak için bir poweshell ekranı açalım (administrator olarak) ve aşağıda ki komutları sırasıyla çalıştıralım.

Set-ExecutionPolicy -force RemoteSigned

Ardından powershell komut satırında C:\Program Files\Microsoft System Center 2012\Service Manager klasörü içerisine gelelim ve aşağıda ki komutu çalıştıralım. Böylece datawarehouse komut tanımlarını yüklemiş olacağız.

Import-Module .\Microsoft.EnterpriseManagement.Warehouse.cmdlets.psd1

Son olarak aşağıda ki komutu çalıştırarak Datawarehouse Job larını listeleyelim.

Get-SCDWJob

Yukarıda ki ekran görüntüsünden de görüleceği üzere bazı job lar Running durumunda. Ben bu durumda bu job ların tamamlanmasının beklenmesini tavsiye ederim. Tüm job lar Not Started durumuna geldiğinde sırasıyla aşağıda ki komutları çalıştırarak Datawarehouse job larını disable edelim.

Disable-SCDWJobSchedule -JobNanme Extract_DW_"Datawarehouse Management Grup Adı"

Not: Yukarıda ki komutta "Datawarehouse Management Grup Adı" bölümü tırnak işaretleri olmadan yazılmalıdır. Eğer Grup adı bilinmiyor ise Service Manager konsolunda Datawarehouse--> Data Sources bölümüne bakılarak öğrenilebilir.                                                                                                                                                                                           

Disable-SCDWJobSchedule -JobName Extract_"Service Manager Grup Adı"

Not: Yukarıda ki komutta "Service Manager Management Grup Adı" bölümü tırnak işaretleri olmadan yazılmalıdır. Eğer Grup adı bilinmiyor ise Service Manager konsolunda Datawarehouse--> Data Sources bölümüne bakılarak öğrenilebilir.

Disable-SCDWJobSchedule -JobName Transform.Common

Disable-SCDWJobSchedule -JobName Load.Common

Disable-SCDWJobSchedule -JobName DWMaintenance

Disable-SCDWJobSchedule -JobName MPSyncJob

Start-SCDWJob -JobName MPSyncJob

Not:  Çalıştırılan son komut extraction, transformation ve loading job larının tamamlanmasını sağlamak içindir. Bu işlem kısa sürede tamamlanacak ve ardından tüm job lar Not Started durumda olacaktır. Bunu Get-SCDWJob komutunu çalıştırarak ya da Service Manager konsolunda Datawarehouse--> Datawarehouse Jobs bölümünden görebiliriz.

Datawarehouse job larını disable yaptığımıza göre artık yükseltme işlemine başlayabiliriz. Service Manager 2012 R2 medyasından setup ı çalıştıralım ve karşımıza gelen ilk ekranda Upgrade seçeneği altında ki "Service Manager data warehouse management server" seçeneğine tıklayalım.

Karşımıza gelen "Prepare for upgrade" penceresinde yükseltme için gerekli olan bilgilere haiz olduğumuzu ve disaster recovery için gerekli hazırlıklarımızı yaptığımızı kutuları işaretleyerek kabul ediyoruz.

Next diyerek ilerlediğimiz de karşımıza lisans anahtarını gireceğimiz bölüm çıkmakta. Bu alanı elimizde ki lisans anahtarını girerek geçelim. Sistemimizde zaten Service Manager kurulu olduğundan prerequisites bölümünde herhangi bir eksiklik olayacaktır. Bu bölümü de Next diyerek geçelim ve son ekranda Install diyerek yükseltme işlemini başlatalım.

Yükseltme işlemi tamamlandığında karşımıza gelen ekranda Encryption Backup and Restore Wizard seçeneğinin seçili olduğundan emin olalım. Eğer bu key i almaz isek bir disaster durumunda elimizde yedeğimiz olsa dahi geri dönüş şansımız olmayacaktır.

Close a tıkladığımızda karşımıza  Encryption Backup and Restore Wizard penceresi gelecektir. Burada Backup Encryption key seçeneği seçili durumda iken Next diyerek ilerleyelim.

Provide location penceresinde anahtar dosya için bir isim ve kayıt edileceği yeri seçelim.

Next diyerek ilerlediğimizde bizden anahtar dosyası için bir parola belirlememiz istenecektir. Burada ki parola unutmayacağımız bir parola olmalıdır :)

Böylece Service Manager Datawarehouse sunucumuzu 2012 R2 sürümüne yükseltmiş olduk. Sırada  Service Manager Management sunucusunun yükseltilmesi işlemi var.

Management sunucusuna bağlanalım ve Service Manager 2012 R2 kurulum dosyasını çalıştıralım. Karşımıza gelen ekranda Upgrade seçeneği altında ki linki tıklayarak yükseltme işlemine başlayalım.

Karşımıza datawarehouse yükseltmesinde ki gibi yükseltme için gerekli olan bilgilere haiz olduğumuzu ve disaster recovery için gerekli hazırlıklarımızı yaptığımızı kutuları işaretleyerek kabul ediyoruz ve Next diyerek ilerliyoruz. Karşımıza benzer şekilde lisans ve prerequisites ekranları gelecektir. Bunları da bir önceki işlemde olduğu gibi yaparak geçelim. Yükseltme işlemi tamamlandığında karşımıza gelen ekranda Encryption Backup and Restore Wizard seçeneğinin seçili olduğundan emin olalım.

Bir önceki datawarehouse yükseltmesinde ki gibi key in yedeğini aldığımızda Service Manager Management Sunucumuzu da 2012 R2 sürümüne başarılı bir şekilde yükseltmiş olduk.

Bu işlem ile birlikte artık Datawarehouse sunucumuz üzerinde ki job ları çalıştırabilir ve senkronizasyon işleminin başlatabiliriz. Bunun için datawarehouse sunucusu üzerinde bir powershell ekranı açalım ve aşağıda ki komutları çalıştıralım.

Import-Module .\Microsoft.EnterpriseManagement.Warehouse.cmdlets.psd1

Enable-SCDWJobSchedule -JobNanme Extract_DW_"Datawarehouse Management Grup Adı"

Enable-SCDWJobSchedule -JobName Extract_"Service Manager Grup Adı"

Enable-SCDWJobSchedule -JobName Transform.Common

Enable-SCDWJobSchedule -JobName Load.Common

Enable-SCDWJobSchedule -JobName DWMaintenance

Enable-SCDWJobSchedule -JobName MPSyncJob

Start-SCDWJob -JobName MPSyncJob

Not: Makaleyi yazdığım dönemde son olarak Update Rollup 5 bulunmakta idi. Bu güncelleme de yine yükseltme sırasında olacak şekilde tüm makinelere geçilmesi gerekmektedir. Ancak Service Manager Datawarehouse sunucusuna güncellemenin geçilebilmesi için yükseltme sonrası tüm Datawarehouse Job ların çalışıp tamamlanmış olması gerekmektedir. Aksi halde güncelleme geçilemeyecektir.

Artık geriye Service Manager konsolu kurulu olan bilgisayarlarda yükseltme işleminin yapılması kaldı. Konsol kurulumlarının gerçekleştirilmesi oldukça kolay bir şekilde yapılabilmektedir. Ancak Service Manager Self-Service  Portal güncellemeyi aynı makine üzerinde desteklememektedir. Bu nedenle sıfır kurulum yapılması gerekmektedir. Self-Service Portal kurulumunu http://www.cozumpark.com/blogs/windows_server/archive/2015/02/22/service-manager-2012-r2-self-service-portal-kurulumu-bolum-1.aspx ve http://www.cozumpark.com/blogs/windows_server/archive/2015/02/22/service-manager-2012-self-service-portal-kurulumu-bolum-2.aspx adreslerinde ki makalelerden takip ederek yapabilirsiniz.

Bu makalemde sizlere Service Manager 2012 Sp1 ürününün Service Manager 2012 R2 sürümüne yükseltilmesini anlatmaya çalıştım.

Faydalı olması dileğiyle...

Ekim ayının başında Microsoft’ un sunucu ve son kullanıcı işletim sistemi Windows 10 Technical Preview yayınlandı ve bizler de test ortamlarımız içinde bu yeni ürünü kurmaya, test etmeye ve bizleri gelecekte neler beklediğini öğrenmeye başladık.

Yeni nesil işletim sistemleri içinde bulunacak olan yeni web tarayıcımız Internet Explorer 11. Bu yeni tarayıcımızın nasıl çalıştığını öğrenmek istiyorsak Windows indirmeleri sayfasından bu son sürüme sahip olabilir ve kullanmaya başlayabilirsiniz.

Her yeni üründe olduğu gibi, bu yeni ürün içinde kaygılarımız olabilir ve ürünün gelişmesini, test edilmesini bekleyebilir ve gerçek ortamlara yüklemekten kaçınabilirsiniz. Fakat bu kaygılarımız her zaman olduğu gibi merakımızın önüne geçemez. Yeni web tarayıcısında bizleri neler bekliyor öğrenmek isteriz, araştırma yaparız, blogları okuruz, merakımızı gidermeye çalışırız. Yenilikleri öğrendikçe merakımız gitmez, daha fazla artar. Ama yeterli kaynaklarımız olmadığı için test ortamı kuramayız ve bir çıkmazda kalırız.

Bu çıkmaz durumdan kurtulmak için Microsoft Azure Takımı ile Microsoft RDS takımının ortaklaşa çalışma sonrasında RemoteIE ‘yi son kullanıcılarda kullanabilmek üzere Microsoft RemoteApp yazılımına entegre ettiler. Bu makalemiz içinde Microsoft RemoteApp yazılımına Internet Explorer 11 Technical Preview ürünü entegre etmeyi, uzaktan IE11 yazılımını çalıştırmayı ve yeni neler gelmiş bunları paylaşacağız.

Microsoft RemoteApp yazılımını inidirip sahip olduğunuz bilgisayara yüklemeniz gerekmektedir. Microsoft RemoteApp yazılımını isterseniz microsoft live hesabı ile oturum açabilir veya on-premise ortamınız ile entegre ettiyseniz yerel domain hesabınız ile oturumda açabilirsiniz.

Microsoft RemoteApp aracı ile ile IE11 web tarayıcısını test etmek için https://remote.modern.ie/ sayfası üzerinde onay vermeniz gerekmektedir. Bu onay sayfasında IE11 için Beta olduğunun belirtisi görülmektedir. Bulunduğunuz bölgeyi belirtip, Submit butonuyla Microsoft RemoteApp uygulamalarımızın güncellenmesini istiyoruz.

Yapmış olduğumuz bu değişiklikten sonra Microsoft RemoteApp yazılımını, değişiklik yapmış olduğumuz hesabımız ile oturum açtığımızda Internet Explorer uygulamasının geldiğini görmekteyiz ve Done butonuyla onaylıyoruz.

Microsoft RemoteApp aracı üzerinde yeni web tarayıcımız IE Technical Preview kullanıma hazır durumdadır. Kendi bilgisayarımıza Preview versiyonunda olan bir yazılımı yüklemeden, sanal ortamlar üzerinde efor harcamadan, test ortamı kurmadan bu yeni web tarayıcısını test edebilir durumdayız.

Internet Explorer 11 Yenilikleri

Üzücü bir haber. IE11 tarayıcısı üzerinde geliştirilen bütün yenilikler Windows 8.1 için hazırlanmış durumda. Eğer Windows7 işletim sistemine sahipsek IE11’ e yükseltme yapmak için bir nedenimiz yok gibi. Microsoft’un ve bağımsız firmaların yapmış olduğu hız testlerinde gözlemlenen, Windows 7 üzerinde ki IE10 ‘un yeni yüklenen IE11’e göre daha hızlı ve stabil çalıştığı yönünde.

Kullanmış olduğunuz işletim sistemi Windows 8 ise sevinebilir ve makalenin devamını okuyabilirsiniz.

Google’ nin geliştirmiş olduğu SPDY/3 desteği sayesinde daha hızlı ve daha sağlıklı bir gezinti bizleri beklemektedir. Bu özellik sayesinde SPDY destekli sitelerde, yavaş açılan web sayfalarında bile önizleme yapılabilmektedir.

Web Graphics Library (WebGL)özelliğini desteklemekte ve bu özellik sayesinde 3D oyunları daha hızlı oynayabilmemiz için uygun bir platform sağlayabilmektedir. Sahip olduğumuz donanım DirectX 9 ve sonrasıysa sahip olduğumuz donanıma göre değişiklik yapabilmek ve yeni tarayıcımızı donanımımıza uyumlu duruma getirebilmekteyiz.

Fareleri bir kenara bıraktık ve her şeye tıklamak yerine dokunmaya başladık. IE11 üzerinde dokunma deneyimi daha keyifli duruma geliyor. Yeni tarayıcımız, dokunmatik özelliğe sahip cihazlarımız için geliştirilmiş durumda. Sayfalar arasında ilerlemeyi, sayfalar arasında geçişi, tıklamaklar yerine iterek, ileri-geri sürükleyerek yapabilmekteyiz.

Eş zamanlı olarak çoklu monitörler kullanıyorsak ve monitörlerimiz farklı çözünürlüklere sahiplerse pixels per inchözelliği sayesinde farklı çözünürlüklerde farklı ölçeklendirmeler yapıyor ve daha hızlı, daha kaliteli sonuçları bizlere sunuyor. Eş zamanlı olarak 100 adet web sayfasını açmamıza imkan sunuyor. Elbette kaybolmayacağınızın garantisi bulunmamakta...

Web Standartları ile uyumlu durumda. Farklı yazılım dilleri ile geliştirilmiş web sitelerini açmak için geliştirilmiş durumda. IE11 in desteklemiş olduğu web tabanlı standartların listesi aşağıda yer almaktadır.

·         WebGL

·         Canvas 2D L2 extensions

·         Full screen API

·         Encrypted media extensions

·         Media source extensions

·         CSS flexible box layout module

·         Mutation observers like DOM4 and 5.3

Hepimizi rahatsız duruma getiren otomatik açılan reklam siteleri, gezindiğimiz sayfalar içinde bulunan reklam içerikleri, web sayfalarına gömülen dinamik contentler. Sayfalar içinde bulunan bu dinamik içerikler IE11 tarafından bulanıklaştırılıyor ve sayfalar içinde gezinmemizde dikkat bozukluğu yaşamamızın önüne geçiyor. Bir makale okurken, bir araştırma yaparken dikkatimizin dağılmasının önüne geçiyor. Reklam ajansları bu özelliği pek sevmeyecek olsalar bile bizler için bulunmaz bir nimet olacak.

Farklı cihazlara sahipsek gezinmelerimizi Syncing across devices özelliği sayesinde gezinme geçmişimizi farklı cihazlar içinde görebileceğiz. Windows 8 bilgisayarımı live hesabımız ile kullandığımız zaman zaten bu özelliğe sahiptik. Aynı şekilde Android ile Google hesabımızı birleştirdiğimiz zaman Crome üzerinde bu deneyimi yaşayabilmekteyiz. Farklı cihazlar ama aynı kullanıcıyız. Farklı ne var ilerleyen zamanda kıyaslayabileceğiz.

Click to callözelliği sayesinde Web sayfalarında bulunan telefon numaralarını çevirmek için IE11 i kullanabilmekteyiz. Google üzerinde yaşanılan bu deneyim Skyp’e ile hayatımıza girecek.

Daha iyi güvenlik ve daha iyi kullanıcı deneyimi için geliştirilen Enhanced Protected Mode (EPM) ve AppContainer özelliği var sayılan değerlerde açık durumda gelmektedir. EPM makalesi üzerinden bu teknoloji hakkında daha fazla bilgiye sahip olabilirsiniz.

Adobe Flash platformu Windows 8.1 üzerinde kullanılabilir durumda. Otomatik güncelleştirmelerde gelecek olan yeni güncelleştirmeler ile Adobe Flash platformunu IE11 ile birleştirebilmekteyiz.

Organizasyonlarımız için merkezi yönetimi sağladığımız Group Policyler ile uyumlu durumda. Aşağıdaki group policy yapılandırmaları ile IE9 uyumlu moda kadar destek verebilmektedir. Internet Explorer Administration Kit (IEAK) aracı IE11 içinde bulunmaktadır ve buradan indirebilirsiniz.

·         Turn off Page Prediction

·         Turn on the swiping motion for Internet Explorer for the desktop

·         Allow Microsoft services to provide more relevant and personalized search results

·         Turn off phone number detection

·         Allow Internet Explorer to use the SPDY/3 network protocol

Tek bir facebook hesabı artık bir çok web sitesinde oturum açmak için yeterli olabiliyor. Yeni bir web sayfasına giriş yaptık ve bir sürü bilgi vermek istemiyoruz. Sayfada facebook ile oturum aç bölümü var ve tıklıyoruz, facebook hesabımız ile oturum açıyoruz. Belirli bir süre sonra bu oturum açmış olduğumuz sitelerin facebook profilinde reklam yayınladığını görebiliyoruz ve şaşırıyoruz. Halbuki facebook ile oturum aç dediğimiz zaman bu siteler oturum açmış olduğumuz sitelerin yayınlamış olduğu güvenlik politikalarını kabul etmiş oluyoruz. Ve zaten bu güvenlik politikalarında söyleniyor. Sitemiz sizin adınıza paylaşımda bulunabilir. Gizlilik Politikalarımızı ve Sizin adınıza nasıl bir paylaşımda bulunacağımızı okuyun maddeleri bulunmaktadır. Okumuyoruz, bu kolay buton ile oturum açıyoruz sonra saçma-sapan paylaşımları gördüğümüz zaman şaşırıyoruz. Do Not Track (DNT) exceptionsözelliği sayesinde bu hataların önüne geçilmek hedeflenmiş durumda ve varsayılan değerlerde aktif durumda olacaktır.

IE11 arayüzü yazılımcılar ve geliştiriciler için daha gelişmiş F12 Developer Tools araçları sunmaktadır. Web sitelerimiz içinde bulunan hataları ayıklama, problemleri görme, performans iyileştirmeleri gibi geliştirilmiş özellikleri kullanabiliriz. F12 araçları içinde eklenen UI Responsiveness ve Memory Profiling  araçları bulunmakta. Yeni Live DOM Explorer ve CSS ise web sitelerinin nasıl hazırlandığı konusunda yazılımcılara fikirler vermektedir. F12 aracı çok eski web sürümleri için desteklenmeyeceğinin bilgisi ayrıca paylaşılmıştır. Yazılımcılar ve geliştiriciler Internet Explorer 11 guide for developers makalesini inceleyebilirler.

Internet Explorer 11 Technical Preview özelliğinde ve bir takım kısıtlamaları bulunmakta. Bu makale içinde paylaşılan bilgiler, ürün yayınlandığı zaman geri çekilebilir, ismi değiştirilebilir veya farklı yeni özellikler eklenebilir. Ayrıca testlerinizi RemoteIE üzerinden yapıyorsanız sizleri bekleyecek olan bir takım eksiklikler, kısıtlamalar daha olacaktır.

·         F12 aracı sadece uygulamalar için hazır durumda.

·         Kaynakların optimize edilmesi ve herkes tarafından test edile bilmesi için RemoteIE kullanımları sınırlandırılmıştır. RemoteIE ile bağlantı yaptığınız zaman boşta kalma süreniz 10 dk aktif kullanma süreniz 60 Dk ile sınırlıdır. Bu süreler sonrasında tekrardan oturum açmanız gerekmektedir.

·         RemoteIE üzerinde GPU acceleration bulunmamaktadır. Bu testleri yapmak istiyorsanız IE11 i kendi kaynaklarınız üzerinde çalışan bir Windows 8.1 işletim sistemi üzerine yüklemeniz gerekmektedir.

·         RemoteIE ile bir web sitesine gittiğiniz zaman bağlantılar bazı güvenlik politikalarına takılabilir. Web sayfaları arasında gezinme Microsoft’un güvenli duvarları üzerinden sağlandığı için bu güvenlik duvarları tarafından engellenebilirsiniz.

·         Bu makaleden sonra test edecek kişi sayısında artış olabilir. Sıra ile kullanalım, zira kaynaklar sınırlı ve hizmet kesintisi yaşanabilir.

Active Directory ortamlarında bilgisayarların domain den düşmesi görülebilen bir olaydır. Bunda bilgisayarın uzun süre (30 günden fazla) domain controller ile iletişime geçmemesi sonucunda domain controller ilgili bilgisayara artık güvenmediği için etki alanında oturum açtırmayacaktır. Bu durumda da bilgisayarın domain den çıkarılıp yeniden alınması gerekmektedir. Bu makalemde sizlere Orchestrator kullanarak domain de uzun süre oturum açmammış bilgisayarların listesini 90 günde bir otomatik olarak almayı ve e-mail ile iletilmesini anlatmaya çalışacağım.

Öncelikle Orchestrator sunucusu üzerinde Active Directory komutlarını çalıştıracağımız için sunucu üzerine Sever Manager konsolunda ManageàAdd Roles and Features yolunu izlereyek Features altında bulunan Role Administration Toolsà AD DS and AD LDS Tools—> Active Directory Module fow WindowsPowerShell seçeneğini seçerek Active Directory PowerShell eklentisini kuralım.

Orchestrator sunucusu üzerinde Runbook Designer ı açalım ve yeni bir runbook oluşturup ismini Eski Bilgisayarları Bul olarak verelim. Ardından Activitiesà System altında bulunan Run .Net Script aktivitesini runbook içerisine sürükleyip bırakalım.

Not:Çalıştıracağımız script bir html dosyası oluşturacaktır. Bu dosyanın oluşturulacağı yeri önceden belirlemeniz gerekmektedir. Ben orchestrator sunucusu üzerinde Test isimli bir klasör oluşturdum ve script içerisinde dosyasını burada oluşturulmasını sağladım.

Eklediğimiz aktiviteyi çift tıklayarak açalım. Language Type bölümünde Powershell i seçelim. Script bölümüne aşağıda ki script i yapıştıralım.

powershell{

$layout = "<style>"

$layout = $layout + "BODY{background-color:White;}"

$layout = $layout + "TABLE{border-width: 1px;border-style: solid;border-color: black;border-collapse: collapse;}"

$layout = $layout + "TH{border-width: 1px;padding: 5px;border-style: solid;border-color: black;background-color:LightGrey}"

$layout = $layout + "TD{border-width: 1px;padding: 5px;border-style: solid;border-color: black;background-color:ForalWhite}"

$layout = $layout + "</style>"

$d = [DateTime]::Today.AddDays(-90)

$stale = Get-ADComputer -Filter  'PasswordLastSet -le $d' -SearchBase "DC=mhclabs,DC=com" -properties PasswordLastSet

$liststale = $stale | Sort Name | ConvertTo-HTML -Head $layout Name, DistinguishedName, PasswordLastSet -Body "<H2>Aşağıda ki bilgisayarları 90 gündür domain ile iletişim kurmadı:</H2>" | Out-File \\srv-sco\C$\Test\Kullanılmayan_Bilgisayarlar.html}

Not:SearchBase bölümünü kendi domain adınıza göre düzenlemeniz gerekmektedir.

Not: Eğer 90 günden farklı bir gün sayısı belirlemek istiyorsanız $d = [DateTime]::Today.AddDays(-90) ifadesinde ki 90 değerini değiştirmeniz yeterli olacaktır.

Yukarıda ki aktivitemizi Finish diyerek kapatalım. Aktivitelerin tarih formatları US e göredir. Biz bu formatı değiştirmek istiyoruz. Bu işlemi yapmak için Activitesà Utilities altında bulunan Format Date/Time aktivitesini sürükleyip runbook içerisine bırakalım ve Run .Net Scirpt aktivitesi ile Format Date/Time aktivitelerini bağlayalım.

Format Date/Time aktivitesine çift tıklayalım (ben adını Tarihi Düzenle olarak değiştirdim) ve açılan pencerede Input Date/Time bölümüne sağ tıklayalım. Açılan menüden Subscribeà Published Data seçeneğine tıklayalım. Karşımıza gelen ekranda Activity bölümünde Run .Net Script seçili iken alt bölümde bulunan Show Common Published Data seçeneğine tıklayalım. Karşımıza gelen kalabalık listeden Activity end time seçeneğini seçelim ve Ok e tıklayalım. Böylece script in çalışma tarihini gün olarak almış olacağız.

Output Format kısmını da dd-MM-yyyy olarak düzenleyelim. Aktivitenin son hali aşağıda ki gibi olacaktır.

Finish diyerek yukarıda ki ekranı kapatalım. Şimdi script ile oluşturduğumuz html dosyasını mail yolu ile iletme kısmına geldik. Bunun için Activities altında bulunan Exchange Userà Create and Send E-mail aktivitesini runbook içerisine sürükleyip bırakalım.

Not: Eğer Exchange bağlantı bilgilerimiz yok ise öncelikle bunun Runbook Designer konsolunda Optionsà Exchange Admin yolunu takip ederek oluşturulması gerekmekte.

Aktiviteyi çift tıklayarak açalım ve Configuration bölümünden Exchange bağlantımızı seçelim. Configuration bölümünü belirledikten sonra alt tarafta bulunan Optional Properties e tıklayalım ve açılan pencerenin sol bölümünden Attachments ve Senderözelliklerini sağ tarafa (Selected bölümü) aktaralım ve Ok diyerek pencereyi kapatalım. Böylece script sonucu elde ettiğimiz dosyayı ek olarak maile koyabileceğiz. Sender özelliğini isterseniz eklemeyebilirsiniz. Ancak ben kurumsal olması açısından örneğin yardimmasasi@mhclabs.comşeklinde bir hesap oluşturup maillerin buradan gelmesini daha uygun bulduğumdan bu yöntemi kullanıyorum.

From kısmına mailin kime ya da hangi gruba gitmesini istiyorsak onun bilgilerini yazalım. Subject bölümüne ise anlamlı bir ifade yazalım. Body bölümünü ise ben aşağıda ki şekilde belirledim. Burada dikkat ederseniz Format Date/Time aktivitesinde düzenlemiş olduğumuz tarihi kullanıyorum.

Attachments bölümünde ise script sonucu dosya nerede oluşturuluyor ise ilgili klasör dahil dosyanın yolunu yazıyoruz. Örneğin, C:\Test\Kullanılmayan_Bilgisayarlar.html gibi. Bu işlemlerin ardından aktivitemizin son şekli aşağıda ki gibi olacaktır.

Finish diyerek yukarıda ki ekranı da kapatalım ve Runbook u Check-In diyerek kayıt edelim. Runbook muzun son hali aşağıda ki şekilde olacaktır.

Şimdi sıra oluşturmuş olduğumuz bu Runbook u nasıl çalıştıracağımıza geldi. Normal de Runbook için Activitiesà Scheduling altında bulunan Monitor Date/Time aktivitesi ile her 90 gün olduğunda çalış diyebiliriz. Ancak burada Orchestrator limitasyonu ile karşılaşıyoruz. Monitor Date/Time aktivitesi ile en fazla 48 günlük bir Monitor işlemi gerçekleştirilebilmektedir. Eğer bu aktiviteyi kullanabilseydik sadece bir rapor için runbook sürekli çalışır durumda olacaktı ki bu da Orchestrator sunucusunda gereksiz kaynak tüketimine neden olacaktı. Bu nedenle eski usül Windows Task Scheduları kullanacağız. Ancak bunun için ufak bir programcığa ihtiyacımız var. Komut satırından runbook çalıştırabilmemizi sağlayan SCO Jub Runner isimli bu uygulamaya http://orchestrator.codeplex.com/releases/view/87873 adresinden ulaşabilirsiniz. Sco Job Runner ı bir klasör içerisine açalım (Örneğin ben C:\Test\ScoJobRunner klasörü gibi). Oluşturacağımız görev de Sco Job Runner ın bulunduğu klasör içerisinde çalıştıracağız.

Task Scheduler konsolu üzerinden yeni bir Task oluşturmak için Actions altında ki Create Task linkine tıklayalım. Açılan pencerede Name bölümüne makul bir isim verelim, Security Options bölümünde Change User or Group seçeneğine tıklayarak bu task i çalıştıracak kullanıcıyı belirleyelim ve alt bölümde bulunan “Run whether user is logged on or not” seçeneğini seçelim.

Ardından Triggers sekmesine geçelim ve New seçeneğine tıklayalım. Açılan ekranda ben Monthly seçeneğini seçip 90 günde bir çalışmasını istediğim için ilgili ayları seçtim.

Not: En altta bulunan Enabled seçeneğinin işaretli olduğundan emin olalım.

Bu işlemlerin ardından Actions sekmesine geçelim ve New seçeneğine tıklayalım. Karşımıza gelen ekranda Program/Script bölümüne Sco Job Runner uygulamasının bulunduğu klasörü yazalım. Ben C:\Test\ScoJobRunner şeklinde belirttim. Son olarak Add arguments bölümüne komut setini yazmamız gerekmektedir. Sco Job Runner aşağıda ki gibi bir komut setini ek olarak beklemektedir.

ScoJobRunner.exe –RunbookPath:“Orchestrator içerisinde Runbook un bulunduğu klasörün yolu”

Benim sistemimde çalıştırılacak runbook aşağıda ki koyu ile belirtilen bölümde bulunmaktadır.

-RunbookPath:"\MHC LABS\Active Directory\Bilgisayar İşlemleri\Eski Bilgisayarları Bul"

Sco Job runner uygulamasının yolunu ve runbook yolunu yazdıktan sonra OK diyerek pencereyi kapatabiliriz.

İşlemleri tamamladığımıza göre OK diyerek Create Task penceresini kapatabiliriz. Ok e tıkladığımızda bizden ilk ekranda belirlemiş olduğumuz ve task i çalıştıracak olan kullanıcının parolası istenecektir.

Parolayı girdikten sonra deneme amaçlı olarak sağ tıklayalım ve Run diyelim. Task çalıştırıldığında runbook içerisinde belirlemiş olduğumuz mail adresine raporumuz gelecektir. Rapor aşağıda ki gibi gözükecektir.

Bundan böyle belirlenen zamanlarda görev çalıştırılacak ve rapor otomatik olarak oluşturulup mail adresine gönderilecektir.

Bu makalemde sizlere Orchestrator kullanarak domain de uzun süre oturum açmammış bilgisayarların listesini 90 günde bir otomatik olarak almayı ve e-mail ile iletilmesini anlatmaya çalıştım.

Faydalı olması dileğiyle…

RemoteApp Deneyimleri makale serimizin bu bölümünde, son kullanıcılarımıza atamış olduğumuz RemoteApp uygulamalarının güncelleştirilmesini inceleyeceğiz. Bu güncelleştirme işlemi, RemoteApp uygulamalarının versiyon güncelleştirmesi ile karıştırılmasın. Office 2013 den Office 2013 Sp1 vb... bir güncelleştirmeden bahsedilmemektedir.

Bu makale içinde yapacak olduğumuz güncelleştirme işlemleri, son kullanıcılarımıza dağıtmış olduğumuz RemoteApp uygulamaları üzerindeki User Assigment haklarının değiştirilmesi ve bu değişiklik sonrasında RemoteApp uygulamalarının RD Web Access üzerinde ve Access RemoteApp and Desktop Connection bağlantılarında güncelleştirilmesini kapsamaktadır.

Makale serimizin içinde bulunan RemoteApp Deneyimleri Bolum 8 RemoteApp User Assigment Yapılandırılması bölümünde, RemoteApp uygulamalarının kullanıcı / grup bazlı atanmasını ve sonrasında atamasını yapmış olduğumuz uygulamalara kullanıcılarımızın erişimlerini paylaşmıştık. Bu bölümde yapmış olduğumuz işlemde OneNote2013 uygulamasını live\RemoteAppOfficeUsers grubuna eklemiş ve bu grup üyesi olan kullanıcılarımızın OneNote2013 uygulamasını RD Web Access üzerinden erişmesini ve Access RemoteApp and Desktop Connection panelinden erişmelerini sağlamıştık.

OneNote2013 uygulaması üzerinde değişiklikler yapıyoruz. Uygulamamızı atamış olduğumuz grubu Live\DomainAdmins olarak değiştiriyorum.

Diğer bir uygulamamız olan ve RemoteApp Deneyimleri Bolum 7 RemoteApp Parameters Girilmesi makalesinde gerçekleştirdiğimiz Session Deployment uygulamasını sadece Live\DomainAdmins grubunun üyesi durumunda olan kullanıcılar erişebiliyorlardı. Bu uygulamamızı kullanabilmesi için Live\RemoteAppOfficeUsers grubunu ekledim.

Bu işlemler sonrsında Live\RemoteAppOfficeUsers grubunun üyesi durumunda bulunan bir kullanıcımla kontrollerimi yapıyorum.

Kullanıcımız RD Web Access ‘e bağlantı yaptığı zaman Session Deployment bağlantısının ana panele geldiğini görebiliyoruz. Bu uygulamamız için herhangi bir folder ataması yapmadığımız için ana panelde görülmekte ve kullanılabilmektedir.

RD Web Access üzerinde Office2013 folder içine girdiğim zaman OneNote2013 uygulamasının görülmediğini görebilmekteyim. Kullanıcımız Live\RemoteAppOfficeUsers grubunun üyesi ve bu grup için OneNote2013 uygulaması için izinleri almıştım.

Yapılan değişikliklerin, RD Web Access üzerinde otomatik olarak algılanabilmesi için bir işlem yapmaya gerek bulunmamaktadır. Yapılan değişiklikler eş zamanlı olarak algılanabilmektedir.

Access RemoteApp and Desktop Connection ile son kullanıcı bilgisayarlarımızın Metro User Interface ve Start Menülerine tanımladığımız bağlantılar bu kadar hızlı sonuç vermemektedir. Access RemoteApp and Desktop Connection güncelleştirildiği zaman bu değişiklikler algılanacaktır. Değişiklik süresini bekleye bilir veya RemoteApp and Desktop Connections bölümünde güncelleştirmeyi tetikleyebiliriz.

RemoteApp and Desktop Connections bölümünde Most recent updata bölümünde son güncelleştirmenin 5:18 AM de yapıldığı görülmekte. Yani oturum ama saati ile aynı. Güncelleştirmeler oturum açma ile birlikte her seferinde yenilenmekte ve değişiklikleri algılamaktadır.

Oturumu kapatmadan ve tekrardan açmadan güncellenmesi için Most Recent Update bölümünde View details bölümüne giriş yapıyoruz ve Update now butonuna tıklıyoruz.

Güncelleştirme işlemi hızlı bir şekilde gerçekleştirildi. Hazır yayınlanan program sayısı 7 olarak güncelleştirme tamamlandı.

Kullanıcımıza atanan kullanıcılarımızı gördüğümüz zaman OneNote2013 uygulamasının olmadığını ve Session Deployment uygulamasının geldiğini görebiliyoruz.

Son güncelleştirme saati ise 6:17 AM olarak değiştirildi. Bizim el-ile tetiklemiş olduğumuz zaman dilimi.

Windows 8 işletim sistemine sahip kullanıcılarımız Start Paneline ekle eklemiş olduğu OneNote2013 uygulamasıda otomatik olarak kalktığını görebilmekteyiz.

Yeni eklediğimiz Session Deployment uygulamasının Start Panelde bulunmasını istiyorsak uygulama üzerinde Pin to Start işlemini yapmamız yeterlidir.

Günümüzde iletişimin çok aktif bir ivme kazanması, buna paralel olarak teknolojinin hızlı ilerlemesi ve yaygınlaşması ile birlikte her an, her yeden cihazlarımızın durumu hakkında bilgiler alıp bunlara göre aksiyonlar almaktayız. Örnek olarak sistemlerimizde ayarlı olan bir olay durumunda cep telefonumuzdaki maillerimize mail olarak veya sms yapımıza kısa mesaj olarak anında uyarılar şeklinde düşmekte ve bizde bununla eş zamanlı olmak üzere hızlı aksiyonlar almaktayız.

Makalemizin ana konusuna gelecek olursak artık yönettiğimiz sistemlerin birçoğunda, belirlenen aksiyon anında mail ile bildirim sistemi var. Bu sistemler bir mail server üzerinden bize anlık olarak bilgilendirme yapmakta. Bu yapımızdaki bir storage, nas kurulu olan bir rol örnek olarak file server rolü olabilir. Tabi bunları yüzlerce miktarda çoğalmak abartı olmaz.

Bu gibi durumlarda illa bir mail server sistemine sahip olmamız gerekmez. Windows Server 2012 R2üzerinde bulunan SMTPözelliği ile smtp özelliği olan bir mail adresini kullandırarak, içeri mail atamasını istediğimiz sistemlere yapımızda bir Mail Server varmış gibi mail atma özelliği kazandırabiliriz.

Aşağıda yer alan senaryomuza göre yol alacağız. Elimizde bulunan Windows Server 2012 R2 File Server Resources Managerüzerinde oluşan ve bize bilgi olarak gelmesini istediğimiz bir aksiyonu, ortamda yapılandıracağımız Windows Server 2012 R2 SMTPözelliği ile mail olarak ilgililere iletme konusunu ele alacağız.

Öncelikle elimizdeki sistemimize göz atalım. Windows Server 2012 R2 rolünde bir servere sahibiz.

Server Manager konsolumuzu açalım.

Server manager ekranımızdan Add role and features linkine tıklayalım.

Gelen wizard ekranını Next ile geçelim.

Karşımıza gelen ekranımızda rol eklemesi yapacağımız için “Role-based or feature-based installation” seçeneğini seçerek Next ile ilerleyelim.

Ortamımızda şu an tek sunucumuz olduğundan var olan sunucumuzu seçerek Next ile bir sonraki ekranımıza ilerleyelim.

Biz bir rol değil Feature ekleyeceğimiz için bu ekranda bir işlem yapmadan Next butonu ile bir sonraki ekranımıza ilerleyelim.

Features ekranında SMTP Serverözelliğini seçelim.

Karşımıza bu özelliğin kurulabilmesi için gerekli olan bileşenlerin listesini içeren bir ekran geldi. Bu bileşenlerinde eklenmesi gerektiği için Add Features butonuna tıklayalım.

Şu anda SMTP Server özelliğimiz seçili hale geldi. Next butonu ile bir sonraki ekranımıza ilerleyelim.

SMTP Serverözelliğinin kurulabilmesi için, IIS rolü ile ilgili olarak bir bilgilendirme ekranı geldi. Next ile bir sonraki ekranımıza ilerleyelim.

Buradaki seçili olan bileşenleri olduğu gibi bırakarak Next ile bir sonraki ekranımıza ilerleyelim.

Kurulumu yapılacak olan Rol ve Özelliklere dair bir özet ekranı karşımıza gelmiş durumda. Install butonuna tıklayarak kurulum işleminin başlamasını sağlayalım.

Gerekli olan kurulumlar başarı ile tamamlandı. Close ile özellik ekleme adımlarımızı tamamlayalım.

Metro Arayüz ekranında oluşan kısayollardan IIS 6.0 Manager kısa yoluna tıkladığımızda SMTP server ekranı karşımıza geliyor. Şimdi bunu yapılandırma adımlarına geçelim.

Öncelikle rolümüzü yapılandırmak için sağ tuşu tıklayalım ve Properties menüsüne tıklayalım.

Öncelikle açılan ekranımızda mail yollama işlemini yapacak olan sunucunun ip adresini seçelim. Benim tek sunucum tek Ethernet kartım olduğundan dolayı var olan 10.81.2.21 ip adresimi seçiyorum.

Access tabımızda gerekli yetki ayarını yapmamız gerekmektedir. Bu nedenle Relay… butonumuza tıklayalım.

İçeriden gelen tüm adreslerden mail yollanmasına izin verdiğim için All except the list bellow seçeneğini seçiyorum. İçeride belirli ip adreslerinden mail yollanabilmesini istersek Only the list bellow seçeneğini seçerek gerekli gördüğümüz ip adreslerini tanımlamamız gerekmektedir.

Message tabımızda gerekli mail boyutu mail yollama limiti gibi limitlemeler yapabilmekteyiz. Varsayılan ayarlar bizim işlemlerimizi karşılayacağı için ayarlarımı varsayılan şekilde bırakıyorum.

Outbound Security… tabına tıklayarak mail yollayacak olan yani SMTP özelliği olan mail adresimi tanımlayacağım. Ben testlerimde gmail adreslerinde SMTP desteği olduğu için bir gmail adresi kullanacağım.

Basic authencation seçeneğini seçerek gmail adresimi ve şifremi girerek OK’liyorum.

Outbound Connections ekranında mail yollamak için kullanacağım portu belirliyorum. Tabi firewall üzerinde bu portlara izin verilmiş olması gerekmektedir.

Son olarak Advanced butonuna tıklayarak Smart Host ekranına SMTP serverimin ismini giriyorum. Ben bir gmail hesabı kullandığım için Gmail Smtp adresi olan smtp.gmail.com adresini yazıyorum.

Ben File Server Resources Manager ekranımda bazı ilkeler tanımladım ve bu ilkeler kapsamında Email Notifications tabında gerekli mail server ayarlarını yapıyorum. Smtp server adresi olarak Localde kurduğumuz SMTP server özelliğine sahip sunucumun adresini giriyorum. Gönderici ve alıcı mail adreslerini giriyorum. Sonrasında işlemleri test edebilmek için Send Test E-mail butonuna tıklıyorum.

Outlook maillerime baktığımda test mailimin sorunsuzca geldiğini görebiliyorum.

Umarım yararlı olmuştur. Bir başka makalede görüşmek dileği ile.

Windows Disk Management üzerinden raid yazılımı ve kartı kullanmadan uygulama bazlı neler yapılabileceğini ve nasıl yedeklilik sağlanabileceğini portalımızda Rıza Sahan hocamız aşağıda linkini verdiğim sitede anlattığı için ben burada konunun detaylarına girmeden oluşturmuş olduğumuz Mirror diskin bozulması durumunda veri kaybı olmaksızın nasıl kurtarılacağını anlatacağım.

http://www.cozumpark.com/blogs/windows_server/archive/2010/06/28/windows-isletim-sistemleri-dosya-sistemleri-ve-disk-islemleri.aspx

Öncelikle hatırlama adına Windows Disk Management üzerinden Mirror (Raid 1) oluşturalım. Bu işlem için Mirror yapacağımız diskin boyutu kadar farklı bir diski sisteminize eklemiş olmanız gerekmektedir.

Aşağıda örnek sistemde görüldüğü üzere Disk1 ID’li 400 GB’lık diski Mirror yapacağım. Bunun için daha önceden eklemiş olduğum Disk2 ID’li 400 GB’lık diski kullanacağım.

Not: Mirror olarak ekleyeceğim disk silinmiş ve formatlanmamış olması gerekmektedir.

Mirror yapmak istediğim disk üzerinde sağ tıklayıp “Add Mirror” ‘ı işaretleyiniz. Gelen ekranda uygun diski seçip “Add Mirror” ile işlemi tamamlayınız.

Bu işlemden sonra bilgilerin yeni disk üzerine kopyalanması / eşitlemesi başlayacaktır. Eşitlenme süresi, diskin ve verinin büyüklüğüne göre değişecektir.

Bir şekilde Mirror içindeki diskiniz bozulur veya artık erişilemez olursa aşağıdaki ekran görüntüsünde görüldüğü gibi statüsü “Failed Redundancy” olacaktır.

Bu durumda arızalı diski çıkartıp değiştirdikten sonra Windows Disk Mangement üzerinde sağ tıklayıp “import Foreign Disk” denilir.

Kurtarma edilecek disk gurubu seçilip OK ile süreç başlatılır.

Veri kopyalama bir şekilde başlamazsa öncelikle eklemiş olduğunuz diski silip yeniden Mirror Disk gurubuna eklemeniz gerekmektedir. Bu işlem için disk üzerinde sağ tıklayıp “Delete Volume” denir.

Üzerindeki tüm verilerin silineceğini bildiren mesaja YES deyip ilerleyiniz.

Bu adımdan sonra sağlam ve çalışır durumdaki Mirror Disk gurup içindeki disk üzerinde sağ tıklayıp “Add Mirror” seçerek ilerleyin.

Yeni eklediğimiz diski seçin.

Disk Management üzerinden raid yapılabilmesi için disk tipinin Dynamic olması gerekmektedir. Eğer bu şekilde değilse değiştirileceğini bildiren mesaj görüntülenecektir. Bu mesaja YES deyip ilerleyiniz.

Disk tipi değişikliği sonrasında verilerin kopyalanması başlayacaktır.

Bu şekilde veri kaybı ve kesinti olmaksızın Mirror Disk Group (Raid 1) içerisindeki disklerden birinin arızalanması sonrasında diskin değişiminin yapılması anlatılmış bulunmaktadır.

Günümüzde kurum veya organizasyon yapılarında kurumsal içerikte farklı kullanıcılar tarafından değişik kategoride Microsoft Office uygulamaları ile yoğun bir doküman üretimi gerçekleştirilmektedir. Bu yoğun doküman kütüphanesinde özellikle kurumsal yazışmalar için kuruma özel doküman standartları belirlenerek, bu standartlara uygun doküman şablonları hazırlanmaktadır. Hazırlanan doküman şablonları ilgili kullanıcıların ulaşabileceği ortak alana kopyalanarak ihtiyaç anında bu alandan kopyalanarak kullanılması sağlanmaktadır.

İki bölümden oluşan bu makale serimizde hazırlanan Office doküman şablonlarını active directory üzerinden domain içerisindeki kullanıcılara merkezi olarak dağıtımı için gerekli teknik detayları uygulamalı olarak paylaşıyor olacağız. Makalemizdeki adımları başarıyla uyguladığınızda şirket kullanıcılarınız ortak alandan doküman şablonunu kopyalamaya gerek kalmadan Office uygulamalarını (Word, Excel, PowerPoint, vb.) başlattıklarında şirkete ait doküman şablonlarının bulunduğu kategorileri otomatik olarak görecek ve buradan istedikleri şablonu açıp kendi dökümanlarını üretmiş olacaklardır.

Şablon (Template) Nedir?

Şablon ya da İngilizce karşılığı ile Template, önceden tanımlanmış bir düzeni, yazı tipleri, kenar boşlukları, stilleri olan ve açıldığında kendisinin bir kopyasını oluşturan bir belge türüdür. Şablonlarla amaçlanan dökümanın yapısını sıfırdan oluşturmak yerine bu şablonları açıp belgenize özgü metin ve bilgileri doldurmaktır.

Microsoft Office Uygulamalarına ait şablon dosya uzantılarını aşağıdaki şekilde listeleyebiliriz:

·       Microsoft Office Word Şablonu (dotx)

·       Microsoft Office Word 97-2003 Şablonu (dot)

·       Microsoft Office Excel Şablonu (xltx)

·       Microsoft Office Excel 97-2003 Şablonu (xlt)

·       Microsoft Office PowerPoint Şablonu (potx)

·       Microsoft Office PowerPoint 97-2003 Şablonu (pot)

MS Office uygulamaları ile şablon oluşturma konusunda Yeni şablon oluşturma ve Office Online Şablonları ve Temaları makalelerinden detaylı bilgileri elde edebilirsiniz. Makalemizde şablon oluşturmaktan ziyade oluşturulan şablonların organizasyon içerisindeki kullanıcılara active directory üzerinden nasıl dağıtılacağını anlatıyor olacağız.

Uygulama Altyapı Bileşenleri

Microsoft Office dökümanlarının merkezi olarak dağıtımı için altyapıda kullanacağımız sunucular:

·       Active Directory Domain Controller

·       Dosya Sunucusu (File Server)

·       Test operasyonları için istemci bilgisayarlar

Biz makalemizde dosya sunucusu olarak da domain controller sunucusunu kullanıyor olacağız. Kurumsal yapılarda dosya sunucusu rolüne sahipseniz bu sunucunun üzerine doküman şablonlarını konumlandırmanızı öneriyoruz.

Doküman Şablonlarının Merkezi Dosya Sunucu Üzerine Konumlandırılması

Uygulamamızın birinci adımı oluşturulan Microsoft Office doküman şablonlarının dosya sunucusu üzerinde bir klasöre kopyalıyoruz. Burada klasör yapısı tamamen sizin kendi klasör standartlarınıza göre belirlenebilir. Bizim makale içerisindeki klasör hiyerarşimiz aşağıdaki şekildedir:

Biz uygulamamızda Word, Excel ve PowerPoint uygulamaları için gerekli şablonu oluşturduk. Siz ihtiyacınıza göre buna Project, Publisher, Visio vb. gibi diğer Office uygulamalarına ait şablonları da benzer adımlarla uygulayabilirsiniz.

Her ana klasörün içerisinde o uygulamaya ait aşağıdaki gibi şablon doküman dosyalarını kaydediyoruz. Biz makalemiz için örnek olarak birkaç doküman ekledik. Siz kurum içerisinde bunu genişletebilirsiniz.

Word Doküman Şablonları

ÖNEMLI NOT : Word şablon uzantıları dot ya da dotx olmalıdır. DOC ya da DOCX şablon dosyası değildir. Ayrıca dosya isimlerinde Türkçe karakter kullanılmamalıdır.

Excel Doküman Şablonları

ÖNEMLI NOT : Excel şablon uzantıları xlt ya da xltx olmalıdır. XLS ya da XLSX şablon dosyası değildir. Ayrıca dosya isimlerinde Türkçe karakter kullanılmamalıdır.

PowerPoint Doküman Şablonları

ÖNEMLI NOT : PowerPoint şablon uzantıları pot ya da potx olmalıdır. PPT ya da PPTX şablon dosyası değildir. Ayrıca dosya isimlerinde Türkçe karakter kullanılmamalıdır.

Doküman Şablonlarının Paylaşıma Açılması

Yukarıda klasör yapısını hazırladığımız ve doküman şablonlarını kopyaladığımız klasörümüzü kullanıcıların bu şablon dosyalarına erişimi için paylaşıma açıyoruz. Eğer bu klasörün ağ yolundan dosya sunucusuna erişildiğinde listelenmesini istemiyorsanız standart paylaşım yerine gizli paylaşım olarak açabilirsiniz. Bizim burada önerimiz gizli paylaşım yöntemini (paylasimadi$ şeklinde) kullanmanızdır.

Şablonlarını bulunduğu klasörü paylaşıma açmak için klasörün üzerinde sağ tuşa basıp Properties tıklıyoruz. Gelen ekranda Sharing sekmesine geçiyoruz. Sharing sekmesinde Advanced Sharing butonuna tıklıyoruz.

Gelen Advanced Sharing ekranında aşağıdaki gibi paylaşım adını sonuna $ simgesini de ekleyerek gizli paylaşıma açacak şekilde belirtiyoruz.

Bu ekrandan çıkmadan Permissions butonuna tıklayarak paylaşım izinlerinde Everyone:Read (Allow) yetkisinin olduğunu kontrol ediyoruz.

Daha önceki Windows Server 2012 R2 ile Dosya Sunucularda Paylaşım ve Güvenlik İzinleri – Bölüm 1 makalesinde de detaylı incelediğimiz gibi ağ üzerinde paylaştırılmış klasöre erişim sağlandığında paylaşım izinleri ile (Sharing sekmesi), güvenlik izinleri (Security sekmesi) arasında en kısıtlayıcı olan izin geçerlidir. Doküman şablonlarının bulunduğu paylaştırılan klasöre ağdan kullanıcılar erişim sağladığında bu paylaşımı okuyabilmeleri ve erişim sağlayabilmeleri için paylaşım izinlerinden minimum Read yetkisine sahip olmaları gerekir. Burada Everyone yerine ihtiyaca göre domain içerisinde açılmış daha dar kapsamlı bir security grubu da gösterebilirsiniz. Fakat uzun vadede farklı kullanıcıların da bu şablonlara erişiminde ilgili grupları ayrıca eklemeniz gerekecektir.

Bu kontrol sonrasında OK butonuna tıklanarak tüm ekranları onaylıyarak kapatıyoruz.

Böylece klasörümüz gizli paylaşıma açılmış oldu. Ağdan da erişim sağlayarak kontrol ediyoruz.

Küçük Resim Görüntüsü ve Önizleme Görüntüsü Dosyalarının Hazırlanması

Şablon dökümanlarına ait isteğe bağlı olarak küçük resim görüntüsü ya da önizleme görüntüsü resim dosyaları hazırlayarak Office uygulamalarında şablonlar açılmadan önce bu resimlerle önizleme görüntülerinin oluşması ve kullanıcıların kolaylık doküman içeriği hakkında fikir sahibi olması sağlanabilir. Eğer küçük resim ve önizleme görüntü dosyaları tanımlanmazsa doküman şablonu üzerine geldiğiniz kırmızı çarpı işareti şeklinde bir resim görüntülenecektir.

Küçük Resim Görüntüsü

Önizleme Görüntüsü

Şablon dökümanlarına ait aşağıdaki küçük resim ve önizleme görüntülerine ait hazırlanmış dosyaları da yine aynı konumda “images” klasörü içerisine kaydediyoruz. Bu tasarım için kurum içerisindeki grafik ve tasarım birimlerinden destek alabilirsiniz.

İmages Klasörü

Word Küçük Resim (Thumbnail) ve Önizleme (Preview) Görüntü Klasörleri

Word Önizleme (Preview) Resim Dosyaları

Word Küçük Resim Görüntüsü (Thumbnail) Resim Dosyaları

ÖNEMLİ NOT : Şablon Dökümanlarına ait küçük resim ve önizleme görüntü resim dosyalarını oluştururken belirli standartlara dikkat etmeniz gerekir. Küçük resim görüntüsü için 100x120 (genişlik X yükseklik), önizleme görüntüsü için de 256x350 boyutlarında olması gerekir. Ayrıca dosya uzantıları da .jpg, .png, .bmp, ya da .gif uzantısında kaydedilmiş olması gerekir.

İki bölümden oluşan ve kurumsal organizasyonlarda hazırlanmış Microsoft Office doküman şablonlarının active directory domaininde bulunan kullanıcılara active directory logon script kullanılarak merkezi bir sunucudan dinamik olarak dağıtımını içeren makalemizin ilk bölümünün de gerekli altyapıyı hazırladık. Makalemizin ikinci bölümünde görüşmek dileğiyle sağlıcakla kalın.

Günümüzde kurum veya organizasyon yapılarında kurumsal içerikte farklı kullanıcılar tarafından değişik kategoride Microsoft Office uygulamaları ile yoğun bir doküman üretimi gerçekleştirilmektedir. Bu yoğun doküman kütüphanesinde özellikle kurumsal yazışmalar için kuruma özel doküman standartları belirlenerek, bu standartlara uygun doküman şablonları hazırlanmaktadır. Hazırlanan doküman şablonları ilgili kullanıcıların ulaşabileceği ortak alana kopyalanarak ihtiyaç anında bu alandan kopyalanarak kullanılması sağlanmaktadır.

Makalemizin ilk bölümünde hazırlanan doküman şablonlarını bu bölümde de active directory üzerinden domain içerisindeki kullanıcılara merkezi olarak dağıtımı için gerekli teknik detayları uygulamalı olarak gerçekleştireceğiz. Makalemizdeki adımları başarıyla uyguladığınızda şirket kullanıcılarınız ortak alandan doküman şablonunu kopyalamaya gerek kalmadan Office uygulamalarını (Word, Excel, PowerPoint, vb.) başlattıklarında şirkete ait doküman şablonlarının bulunduğu kategorileri otomatik olarak görecek ve buradan istedikleri şablonu açıp kendi dökümanlarını üretmiş olacaklardır.

ŞABLON YAPILANDIRMA DOSYASI : TEMPLATES.XML

Hazırlanan şablon dökümanlarının Office uygulamalarında gelen Available Templates kategorisi altında görüntülenebilmesi için bir XML konfigürasyon dosyasında bu dökümanlara ait tanımlamaların yapılması gerekir. Microsoft Office uygulaması bu XML dosyasını referans alarak şablon dosyasının, küçük resim ve önizleme resim dosyalarının nereden ve nasıl alınacağına karar verir.

Aşağıda örnek bir XML konfigürasyon dosyası içeriğini görüyorsunuz:

XML dosyası içerisinde “application” ve “template” olmak üzere iki ana element parçası vardır. Resimde de görüldüğü gibi öncelikle “featuredcontent” isimli bir ana element açıyoruz. Hemen akabinde “application” elementi açıp içerisinde hangi uygulama için şablon tanımı yapılıyorsa bunu belirtiyoruz. Word için “WD”, Excel için “XL”, PowerPoint için de “PP” kısaltması kullanılır. İlgili uygulama içerisinde tanımlanacak tüm şablon dosyası tanımlarını kapsayan “featuredtemplates” elementi açılır. “Featuredtemplates” elementi içerisinde de her doküman şablonu dosyası için “featuredtemplate” elementi açılarak içerisinde şablon tanımına ilişkin tanımlamalar yapılır. “Title” alanı Office uygulamaları içerisindeki görünecek etiket adı, “source” alanında da dosyanın kaynak yolu tanımlanır. Her template tanımı için “media” elementi içerisinde küçük resim görüntüsü dosyasının özellikleri ve resim dosyası yol tanımı belirtilir. “Preview” elementi ile de önizleme görüntü resmi tanımı ile ilgili tanımlamaları gerçekleştiriyoruz. Her template tanımı sonunda “featuredtemplate” elementi kapatılmalıdır. Herhangi bir uygulama içerisindeki tüm şablon tanımları yapıldıktan sonra da “Featuredtemplates” elementi kapatılmalıdır. Sonrasında da ilgili uygulamaya ait “application” elementi kapatılmalıdır. Eğer Excel ya da PowerPoint gibi ikinci bir uygulama için de şablon tanımı yapılacaksa “featuredcontent” elementi kapatılmadan tekrar yeni bir “application” elementi açılır. Onun içerisinde de o uygulama ve uygulamanın şablonlarına ait alt element tanımları ve değerleri belirtilir ve sonunda da yine “application” elementi kapatılır. Tüm uygulamalara ait şablon tanımlamaları tamamlandıktan sonra da  “featuredcontent” elementi kapatılır.

Örnek bir XML dosyası için bu linküzerinden de erişebilirsiniz.

Biz uygulamamızda aşağıdaki XML dosyamızı oluşturduk ve içerisinde Word, Excel ve PowerPoint uygulamalarına ait şablon tanımlarını tanımladık.

Yukarıdaki şekilde de görüldüğü gibi Word, Excel ve PowerPoint uygulamaları için ayrı ayrı şablon tanımları yapılmıştır.

Bu tanımları içeren XML dosyasını da yine aynı konuma Templates.XML adıyla kaydediyoruz.

ÖNEMLİ NOT : Yeni bir şablon oluşturulduğunda da ilgili şablon ve resim dosyaları dosya sunucusu üzerindeki klasörlere kopyalandıktan sonra şablon yapılandırması mutlaka bu XML içerisine tanımlanmalıdır. Bu tanımlamalarda hiçbir yerde Türkçe karakter kullanılmamalıdır.

Bu oluşturduğumuz XML dosyasının geçerli olup olmadığı ve içeriğinin yorumlanmasını yapacak XML Schema dosyasını da (XSD) aynı konuma oluşturuyoruz. XSD dosyası isteğe bağlıdır, doğrulama yapmak istemiyorsanız tanımlamayabilirsiniz. Standartlar açısından konumlandırmanızı öneriyoruz. Örnek bir XSD schema dosyasına bu linkten erişebilirsiniz. Biz de uygulamamızda OfficeTemplates.xsd isimli schema dosyasını aynı konuma kopyalıyoruz.

Biz uygulamamızda bu linkten indirdiğimiz örneği aynen kullandık.

XML YAPILANDIRMA DOSYASINI OKUYACAK REGISTRY AYARLARININ TANIMLANMASI

Şu ana kadar yaptığımız hazırlıklarla şablon dosyaları, bunların önizleme resimleri, bu dosyaların tanımlamalarını içeren XML yapılandırma dosyamızı hazırladık. Sıra geldi Office uygulamasının bu yapılandırma dosyasını okuyacak şekilde kullanıcı bilgisayarlarında registry ayarlarının yapılandırılmasına. Bu işlem için de Templates.reg isimli bir registry yapılandırma dosyası hazırlıyoruz. Bunun hazırlarken Notepad açıp ilgili tanımlamaları yaptıktan sonra .REG uzantılı olarak dosyayı kaydedebileceğiniz gibi, mevcutta bir bilgisayarda bu tanımlamaları yapıp ilgili anahtar hiyerarşisini REG dosyasına export ederek de oluşturabilirsiniz.

\\MST-DC01\CozumPark-Templates$ paylaşımı altında Templates.reg dosyası içerisinde kullanıcı bilgisayarlarında registry içerisine yazılacak tanımlar girdi olarak belirtilir. Bu tanımlar sayesinde yukarıdaki şablonları içeren XML dosya okunarak istemci bilgisayarlarında ilgili şablonlar listelenecektir.

Templates.reg dosyası içeriğini de aşağıdaki şekilde görmektesiniz:

Buradaki tanımlarda Office 2010 olanlar için 14.0, Office 2013 olanlar için de 15.0 versiyonu için tanımları yaptık. Kullanıcı bilgisayarlarında her ikisi oluşmuş olacak ve kullanılan versiyona göre şablonlar otomatik olarak gelecektir. “ServiceURL” anahtarı ile şablonların okunacağı XML dosyasının kaynak yolu tanımlamasını belirtiyoruz. PROVIDERS altında belirttiğimiz anahtar adı Office uygulaması içerisinde bizim şablonlarımızın belirtileceği kategorinin görünen adıdır. Biz COZUMPARK TEMPLATES olarak tanımladık ve bu şekilde görüntülendiğiniz göreceğiz. DisableBootToOfficeStart tanımı da isteğe bağlıdır ve Office 2013 kullananlar için geçerlidir. Bildiğiniz gibi Office 2013 uygulamalarını başlattığınızda otomatik olarak hazır gelen şablonları ve çalışılan son dökümanları listeleyen bir başlangıç ekranı gelir.

Bunun gelmesini engellemek için DisableBootToOfficeStart registry anahtarını aktifleştiriyoruz. Böyle bir ihtiyaç ya da gereksiniminiz yoksa bunu da tanımlamayabilirsiniz. Biz her açılışta son çalışılan dökümanların otomatik gelmesini istemediğim için bu değeri de belirttik.

REGISTRY DOSYASININ LOGON SCRIPT OLARAK KULLANICILARA UYGULANMASI

Bir önceki adımda kullanıcı bilgisayarlarında Office doküman şablonlarını ve ilave özelliklerini XML yapılandırma dosyasında okuyup, kullanıcı bilgisayarlarına getirecek registry ayarlarını içeren REG dosyasına tanımladık. Şimdi de bu şablonları kullanacak kullanıcılar için REG dosyasını active directory domainine logon olan bu kullanıcılara logon script olarak uzaktan tetiklemeye geldik. Bunun için de bir BAT dosyası oluşturacağız. Biz örneğimizde REGADD.BAT olarak isimlendiriyoruz.

Yukarıdaki şekilde de görüldüğü gibi REG dosyasını ağ yolundan okuyarak import ediyoruz. Bu oluşturduğumuz BAT dosyasını NETLOGON klasörü içerisine kaydediyoruz.

ÖNEMLİ NOT : Eğer mevcut durumda kullanıcılara uygulanan bir logon script varsa bu durumda yukarıdaki BAT dosyasının içerisine yazdığımız satırı mevcut logon script dosyası içerisine ilave etmeniz yeterlidir. Böylece mevcut yapıyı bozmadan ya da değiştirmeden bu ilave satırı da ekleyip çözüme gidebilirsiniz.

Son olarak bu BAT dosyasını çalıştırmak istediğimiz kullanıcı hesabı özelliklerinde Profile tabında Logon Script olarak RegAdd.BAT isimli dosyanın tanımlanmasını yapalım.

Toplu olarak çok sayıda kullanıcı için bu tanımı DS komut satırı araçları, VBS script ya da PowerShell cmdlet ile de yapabilirsiniz. Hatta Active Directory Users and Computers konsolu içerisinde Saved Queries ile ilgili kullanıcıları listeleyip, tamamını aynı anda seçip Properties’den Profile tabından Logon Script tanımlayabilirsiniz. PowerShell ile bu konudaki örneklere burdan ulaşabilirsiniz.

Artık sıra geldi kullanıcı bilgisayarlarından logon olup test etmeye.

KULLANICI BİLGİSAYARINDAN TESTLERİN GERÇEKLEŞTİRİLMESİ

Biz demo ortamımızda Windows 7 işletim sistemi ile çalışan ve Office 2013 yüklü istemci bilgisayarından logon script tanımı yaptığımız MesutAladag isimli kullanıcımızla giriş yaparak yaptığımız ayarların uygulanıp uygulanmadığını test ediyoruz.

Word Uygulamasını çalıştırdığımızda New tıkladığımızda aşağıdaki gibi COZUMPARK TEMPLATES kategorisinin geldiğini göreceksiniz.

COZUMPARK TEMPLATES kategorisine tıkladığınızda da oluşturduğumuz şablonların listelendiğini göreceksiniz.

İstediğiniz şablonu açıp artık dökümanlarınızı hazırlayabilirsiniz.

Eğer Office 2010 kullanıyorsanız da oluşturduğumuz şablonların görüntüsü aşağıdaki şekilde olacaktır:

Bu gelen klasör kategorisine girdiğinizde yine ilgili şablonlarını listelendiğini göreceksiniz.

Bu kontroller Word, Excel, Powerpoint vb. tüm uygulamalar için ayrı ayrı kontrol edebilirsiniz.

Kullanıcı bilgisayarında Registry  uygulamasını başlatırsanız da ilgili registry anahtarları ve string değerlerinin oluştuğu ve doğru bir biçimde geldiğini de kontrol edebilirsiniz.

ÖNEMLİ NOT : Herhangi bir kullanıcı bilgisayarında şablonlar eksik gelirse ya da oluşmazsa [HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Common\ altından Spotlight anahtarı silinmelidir. Daha sonra log off olup tekrar logon olunduğunda logon script çalışacak ve ilgili şablonlar sağlıklı bir biçimde tekrar yüklenecektir. Bu işlemi logon script yöntemi ile active directory üzerinden uygulamak için de aşağıdaki içeriğe sahip bir REG dosyası oluşturup bunu yine ağ yoluna kopyalayıp logon script içerisinden de öncelikle bu dosyayı çağırabilirsiniz.

Burada dikkat çeken nokta Registry anahtarları tanımlarının başındaki “-“ işareti. Bu işaret ilgili anahtarın silinmesi anlamına geliyor.

Ağ yoluna bu REG dosyasını da kaydettik. Son olarak logon script içerisinden bu REG dosyasını da çağıracak satırı ekliyoruz. Bu satırı üste alıyoruz ki öncelikle mevcut bir tanım varsa registry içerisinden silsin ve daha sonra Templates.REG dosyasından ilgili ayarları import edilmiş olacaktır.

İki bölümden oluşan bu makale serimizde kurumsal organizasyonlarda hazırlanmış Microsoft Office doküman şablonlarının active directory domaininde bulunan kullanıcılara active directory logon script kullanılarak merkezi bir sunucudan dinamik olarak dağıtımını tüm detaylarıyla inceledik. Başka bir makalemizde görüşmek dileğiyle sağlıcakla kalın.

Microsoft’un yeni nesil işletim sistemi olacak olan Windows Server vNext geliştirme süreci devam ediyor. Ürünün 2016 yılı içerisinde piyasaya çıkacağını tahmin ediyoruz. Geçen günlerde geliştirme sürecinde “Windows Server Technical Preview 2” sürümü yayınlandı. Windows Server 2016 Technical Preview 2 ISO ya da VHD dosyasını aşağıdaki adresten indirerek testlerinize başlayabilirsiniz:
https://www.microsoft.com/en-us/evalcenter/evaluate-windows-server-technical-preview

Ürünün resmi adının ne olacağı konusunda şu an henüz net bir bilgi yok. Benim şu an için tahmin ettiğim, “Windows Server 2016” olacağı yönünde. Önceki sürümlerde olduğu gibi Windows Server 2016 ile birlikte “Cloud OS” yapısını oluşturan bir diğer ürün grubu olan “System Center” ürün ailesi de geliyor olacak. Böylece “Cloud OS” yapısının birlikte oluşturan “Windows Server” ve “System Center” ürünleri ile yeni nesil istemci işletim sistemi Windows 10 birlikte yeni bir dönemi başlatıyor olacak. Windows Server 2016 için şu an daha çok erken olmasına rağmen heyecan verici çok sayıda yeniliği beraberinde getireceğini belirtebiliriz. Bu makalemizde sizlere şu an için “Windows Server Technical Preview 2” sürümüne ile gelen ve gelmesini beklediğimiz diğer yeniliklerden bahsediyor olacağız. Ürün şu an için geliştirme aşamasında olduğundan dolayı anlatacağımız özelliklerde ya da arayüzde resmi sürümde farklılıklar ya da özelliklerin kaldırılması ya da eklenmesi gerçekleşebilir. Biz de zaman içerisinde çıkacak yeni sürümlerdeki yenilikleri bu makalemizi baz alarak güncellemeye ve en hızlı şekilde sizlerle paylaşmaya çalışacağız.

KURULUM SÜRECİ

Bu bölümde sizlerle Windows Server Technical Preview 2 kurulumuna ve kurulum sonrası yeni özelliklere hızlıca bakıyor olacağız.  

Windows Server Technical Preview 2 ISO’su ile kurulum sürecini başlattığımızda  karşımıza kurulumun ilk adımı olan aşağıdaki ekran gelecektir.

Bu ekranda “Language to install” liste kutusundan kurulacak işletim sistemi dili, “Time and currency format” liste kutusundan sistemin dil, saat ve parasal biçiminin hangi dilde olacağı,  “Keyboard or input method” liste kutusundan da klavye dilini seçiyoruz.

Next ile bir sonraki aşamaya geçiyoruz.

Karşımıza kurulumun ikinci aşaması olan aşağıdaki ekran gelecektir.

Gelen ekranda “Repair your computer” seçeneği kullanılarak mevcut kurulu Windows Server 2012 R2 işletim sistemi ile ilgili kurtarma seçeneklerinin bulunduğu moda geçebilirsiniz. Örneğin, mevcut işletim sisteminizin dosyalarında bir zarar görme ya da bozulma durumu oluşmuşsa bu seçenek kullanılarak bu dosyaların onarılarak mevcut işletim sisteminin tamir edilmesi sağlanabilir.  “Repair your computer” seçeneklerini ileriki bölümlerde detaylı olarak inceliyor olacağız. Biz bu aşamada henüz yeni bir işletim sistemi kurulu gerçekleştireceğimiz için “Install now” ile sonraki adıma ilerliyoruz.

“Select the operating system you want to install” ekranında ISO ya da DVD içerisinde mevcut bulunan Windows Server Technical Preview 2 sürümleri listelenir.

Hangi işletim sistemi sürümünü kuracaksak bu listeden seçiyoruz. Biz ISO dosyasından kurulum yaptığımız için gelen seçenekler buna göre geliyor. Gelen listede eski versiyonlar da “Server Core Installation” olarak geçen ifade yerine şimdilik “Windows Server Technical Preview 2” geliyor. Yine önceki versiyonlarda “Server with a GUI” olan madde yerine de “Windows Server Technical Preview 2 (with local admin tools)” olarak geliyor. Grafiksel arayüzün bulunduğu sürümü kuracaksanız  “Windows Server Technical Preview 2 (with local admin tools)” şeklinde listeleneni, tamamen komut satırı tabanlı sürümü kuracaksanız da “Windows Server Technical Preview 2” ile belirtileni seçmeniz gerekiyor. Ürün şu an henüz geliştirme sürecinde olduğu için benim tahminim bu seçenekler yine eskiden olduğu gibi benzer tanımlarla devam edecektir. Şimdilik bu tanımlamalara çok fazla nihai ve kalıcı olarak bakmamanızı tavsiye ederim. Önemli olan genel olarak neler geliyor inceliyor olmamız.  Biz bu aşamada “Windows Server Technical Preview 2 (with local admin tools)” seçeneği seçili iken Next ile sonraki adıma ilerliyoruz.

Bu aşamada gelen “License terms” altında lisans anlaşması metni gelecektir.

“I accept the license terms” kutucuğunu işaretleyerek şartları kabul edip, Next ile bir sonraki adıma geçiyoruz.

Karşımıza “Which type of installation do you want?” ekranı gelecektir. “Upgrade:Install Windows and keep files, settings, and applications” ve “Custom : Install Windows only (advanced)” kurulum seçeneklerinden gerçekleştirmek isteğimiz kurulum tipini seçiyoruz.

Eski versiyon Windows Server sürümünden (örneğin Windows Server 2012 ya da Windows Server 2012 R2 gibi) Windows Server 2016 işletim sistemine yükseltme yapacaksanız “Upgrade:Install Windows and keep files, settings, and applications” seçeneğini kullanıyoruz. Böylece mevcut işletim sistemi üzerindeki tüm uygulamalar, ayarlar korunarak Windows Server 2016 işletim sistemine yükseltme yapılmış olacaktır. Biz şu an için tamamen yeni bir Windows Server Technical Preview kurulumu için “Custom : Install Windows only (advanced)” seçeneği üzerine tıklayarak devam ediyoruz.

Karşımıza aşağıdaki şekilde görülen “Where do you want to install Windows” ekranı gelecektir. Bu adımda Windows Server Technical Preview 2 işletim sistemini hangi volume üzerine yükleyeceksek bu seçimi gerçekleştirmekle ilgili yapılandırmaları gerçekleştireceğiz.

Bu ekranda sürücü problemlerinden dolayı diski görmeme vb. durumlarda “Load Driver” seçeneği ile disk üreticisinden gelen uygun sürücüler yüklenerek disk medyasının tanınması sonrası adımlara devam edilebilir. Sunucu üzerine tanıtılmış fakat henüz bölümleme yapılmamış diskler bu aşamada bölümlenmemiş “Unallocated space” alanı olarak listelenir. Fiziksel ya da sanal sunucuya toplamda kaç farklı disk takılı ise o kadar disk listede gelecektir. Diski birden fazla farklı birimlere (volume) bölmek isterseniz alt kısımda gelen “New” seçeneğini kullanabilirsiniz. Biz şu an tek bir disk takılı olduğu ve bunun tamamına Windows Server Technical Preview kurulumu yapacağımız için  “Unallocated space” alanı seçili iken ilerliyoruz. Diskin tamamı tek bölüm olarak NTFS dosya sistemi ile biçimlendirilecek ve bu bölüme Windows Server Technical Preview 2 kurulumu yapılmış olacaktır. “Unallocated space” alanı seçili iken “Next” ile sonraki adıma ilerliyoruz.

Karşımıza gelen “Installing Windows” aşaması ile artık kurulum sürecini başlatmış olduk.

Bu aşamada artık Windows Server Technical Preview işletim sistemi kurulum dosyaları disk üzerine kopyalanıp, dosyalar kurulum için hazırlanacaktır. Kurulum sürecinde temel işletim sistemi bileşenleri ve özellikleri yüklenecek, kurulum medyasında gelen güncellemeler yapılacak ve kurulum süreci tamamlanmış olacaktır. Bu süreci “Installing Windows” ekranında takip edebilirsiniz.

Kurulum tamamlanınca sistem yeniden başlatılacak ve ilk açılışta karşımıza aşağıdaki şekilde de görülen “Administrator” kullanıcı hesabı için şifre tanımlaması ekranı gelecektir.

Şifre tanımlamamızı yaptıktan sonra ilk logon sürecini başlatıyoruz. Windows Server Technical Preview 2 sunucumuza ilk defa giriş yaptığımızda karşımıza yine önceki sürümlerdeki gibi kullanıcı arayüzü ve  “Server Manager” yönetim aracı gelecektir.  

Server Manager aracında ilk açılışta bir Dashboard ekranı bizi karşılar. Dashboard içerisindeki kısayolları kullanarak sunucumuza rol ya da özellik ekleme, uzaktan yönetmek istediğimiz diğer sunucuları ekleme ve sunucumuz üzerinde yüklü rollerin genel sağlık durumları hakkında bilgiler alabilirsiniz. Logon olduğumuz sunucu ile ilgili detaylar için sol tarafta gelen Local Server seçeneğini kullanabilirsiniz.

Local Server sayfasına geçince karşımıza sunucumuza ait aşağıdaki bilgiler ve bu bilgilerin yapılandırılmasına ilişkin bağlantı kısayollarını bulacaksınız:

·       Bilgisayar adı

·       Domain ve Workgroup tanımları

·       TCP/IP tanımları

·       Bölgesel ayarlara ait bilgiler ve yapılandırma bağlantıları envanter bilgileri ve diğer detaylar gelecektir. Server Manager ile rollerin kurulumu, incelenmesi ve detaylar diğer makalelerde inceliyor olacağız.

Windows Server Technical Preview 2 arayüzü ve genel çalışma ortamı olarak Windows Server 2012 ve Windows Server 2012 R2’ye benzer bir ortama sahip. Kurulum kısmına genel olarak bir göz attık şimdi de şu anki sürüm itibariyle gelen yenilikleri inceleyelim.

Active Directory Domain Servislerde Neler Geliyor?

Windows Server Technical Preview 2 ile Active Directory Domain Servislerinde (AD DS) özellikle active directory ortamlarının güvenliğini artırmaya, buluta-taşıma ya da hibrid mimaride bir kısmı kendi veri merkezinizde bir kısmı bulutta host edilen servislerin desteklenmesine yönelik geliştirmeler geliyor.

Şimdilik gözüken yenilikleri genel olarak sıralarsak:

·       Privileged Access management

·       Azure AD Join

·       Microsoft Passport

·       Windows Server 2003 Domain Controller Desteği Kalkıyor

·       Windows Server 2003 Functional Level Desteği Kalkıyor

·       File Replication Service (FRS) Desteği Kalkıyor

Privileged Access management: Active Directory ortamlarında erişim yetki yönetimi IT departmanları için hala tam anlamıyla oturtulamamış ciddi bir sorun esasında. Günlük işler için kullanılan standart kullanıcı hesaplarına yönetimsel bazı operasyonlar ya da uygulamaların yetki kısıtlarından dolayı domain admins ya da lokal admins yetkisi vererek kullanmaya devam eden çok sayıda örnek görebilirsiniz. Gerçekleştirdiğimiz projelerde ve danışmanlık verdiğimiz yapılarda ciddi bir güvenlik problemi olan bu durumu düzeltmek için elinizden geleni yapsanız da belli bir süre sonra tekrar eski davranışlara geri dönülüyor. Çünkü domain admin ya da local admin gerektiren operasyonlarda arka planda yapılacak işi bu yetkilere sahip bir hesapla gerçekleştirmek için kurum ya da kuruluşlar ilave 3.parti yetki yönetim çözümü ürünlerine başvurarak oluşan güvenlik açığını bu şekilde gideriyorlardı. Microsoft Windows Server 2016 ile bu alanda kendi çözümünü getiriyor : Privileged Access Management yani PAM. PAM, Active Directory ortamlarından güvenliği artırmaya yönelik bir yenilik. Özellikle kullanıcı kimlik bilgilerinin çalınması için kullanılan hash bilgisini ele geçirme, phishing benzeri saldırılara karşı yeni bir güvenlik mekanizması. Microsoft Identity Manager (MIM) kullanılarak yapılandırılan yeni bir yönetimsel erişim çözümü. Bu yeni çözüm sayesinde kullanıcı hesaplarına yönetimsel yetkilere sahip olmaları gereken durumlarda gerekli olan süre için yetki verilip sonrasında otomatik olarak alınmasını sağlıyor olacak. Bu özellik aslında şu anda PowerShell üzerinde de delegasyonda kullanılan Just-Enough-Administration (JEA)üzerine inşa edilen ve Just-In-Time (JIT) Administration olarak adlandırdığımız yönetim biçimi. PowerShell cmdletlerin çalıştırılmasını kısıtlamada kullanılan bir delegasyon yöntemi. JEA kabiliyetleri Window Server 2016 ile beraber sunucu tarafında diğer servislere de genişletilecek gözüküyor. Bu modelde yönetimsel yetkilerin minimum sayıda kullanıcıya verilmesi hedefleniyor. Bu yapıdaki bir diğer hedef de yetkili hesapların tamamen yeni kurulmuş ve güven ilişkisine sahip ayrı bir forest içerisinde tutulması hedefleniyor. Bu yapıda yetkili hesapların kullanımında standart kimlik doğrulama mekanizmalarına ilaveten daha güçlü ve ilave kontrol katmanlarının da etkinleştirilmesi sağlanmış olacak. Burada kafanızı karıştıran yüksek erişimli hesaplar için tamamen ayrı bir forest kurulması olabilir. Fakat mevcut active directory schema’yı genişletme ihtiyacı olmadan tamamen yetki ve hak yönetim amaçlı hesapları tutacak yeni bir forest kurulacak. Bu tip kullanım için yeni bir cross-forest güven ilişkisi geliyor. Bu yeni forest içerisinde mevcut forest içerisindeki gruplarla aynı SID (security identifier) değerine sahip güvenlik grupları oluşturulmuş olacaktır.Bu yapının yönetimini GUI arayüzünden yapmak için de Microsoft Identity Manager (MIM) ürününün kullanıyoruz. MIM, resmi adı FIM(Forefront Identity Manager) olan Microsoft’un kimlik yönetim ürünü ve yeni versiyonunun da 2015 son çeyreğinde çıkmasını bekliyoruz. Esasında burda yapılacak operasyon belli bir süre için kullanıcıları yetkiye sahip yönetimsel gruplara üye yapmak ve belirlenen sınırlı zaman sonunda otomatik olarak gruptan çıkartıp standart kullanıcı durumuna almaktır. Arka planda Kerberos Key Distribution Center (KDC) altyapısı da bu özelliğ destekleyecek şekilde belli bir süre limitli Kerberos token yayınlama desteği ile geliyor. Bu süreçleri tanımlarken hesaplar için kullanılacak kimlik doğrulaması (smart kart ya da PIN vb.) gibi koşullar da belirleniyor. Bu tip kullanım Azure Active Directory (AAD) ile buluta da genişletiliyor olacak. Bu özelliğin kullanılabilmesi için mevcut active directory forest fonksiyonel seviyesinin Windows Server 2012 R2 ya da üzerinde olması gerekir.

Azure AD Join : Kurumsal cihazların bulut domaini olan Azure Active Directory yapısına üye yapabilme desteği. Bu özelliğin öncelikle Azure hesabında aktifleştirilmesi sonrasında aygıtları Azure Active Directory yapısına üye yapabiliyoruz.

Microsoft Passport : Microsoft password anahtar-tabanlı yeni kimlik doğrulama mekanizmasıdır. Password güvenliğinin de ötesine geçerek, kullanıcının kullandığı aygıta bir biometric yöntemlerle (parmak izi vb.) ya da PIN kodu ile giriş yapmasına göre tasarlanmış bir yapı. Özellikle sisteme login olmak isteyen kullanıcının password hash bilgisinin kimlik doğrulama sürecinde ağ üzerinden ele geçirilme ya da çalınma gibi durumlarına karşı geliştirilen yeni bir güvenlik mekanizması.

Windows Server 2003 Domain Controller Desteği Kalkıyor : Windows Server 2012 R2 ve öncesindeki sürümler için active directory geçişleri esnasında aynı anda Windows Server 2003 domain controller ile Windows Server 2012 R2 domain controller aynı domain içerisinde birlikte çalışabiliyordu.Windows Server 2016 ile aynı domain ortamında Windows Server 2003 domain controller ile Windows Server 2016 domain controller sunucuların birlikte çalışma desteği kalkıyor. Temmuz 2015 itibariyle Windows Server 2003 için destek sona erdiğini düşünürsek çoğu kurum ve kuruluş bu yapıya hazır olacağını düşünüyorum.

Windows Server 2003 Functional Level Desteği Kalkıyor : Windows Server 2016 active directory geçişi için sahip olduğunuz forest ve domain fonksiyonel seviyesinin minimum Windows Server2008 seviyesinde olması gerekecek. Temmuz 2015 itibariyle Windows Server 2003 için destek sona erdiğini düşünürsek çoğu kurum ve kuruluş bu yapıya hazır oluyor olacaktır.

File Replication Service (FRS) Desteği Kalkıyor : FRS active directory domain yapılarında domain controller sunucular arasında SYSVOL klasör içeriğinin replikasyonunu gerçekleştirmeyi sağlayan replikasyon servisidir. Daha güçlü ve tutarlı bir servis olan DFSR çıkışıyla artık FRS kullanımı azalmaya başladı. Windows Server 2008 ve üzerinde active directory domain seviyesinde çalışan çoğu organizasyon SYSVOL replikasyon mimarisini FRS’de DFSR’a yükseltmişlerdir. Windows Server 2016 active directory geçişi öncesinde eğer hala FRS kullanıyorsanız bunu öncelikle DFSR’a yükseltmeniz gerekecek. Çünkü Windows Server 2016 ile beraber FRS desteği tamamen kalkıyor.

Microsoft’un yeni nesil işletim sistemi olacak olan Windows Server vNext geliştirme sürecinde “Windows Server Technical Preview 2” sürümü ile gelen yeniliklerin özellikle “Active Directory Domain Servisleri” kısmını sizlerle genel olarak paylaştık. Makalenin başlangıcında da belirttiğimiz gibi ürün şu an için geliştirme aşamasında olduğundan dolayı anlattığımız özelliklerde ya da arayüzlerde ilerki sürümlerde farklılıklar ya da özelliklerin kaldırılması, eklenmesi gerçekleşebilir. Windows Server Technical Preview 2 ile gelen yenilikleri ikinci makalemizde incelemeye devam edeceğiz.

Microsoft’un yeni nesil işletim sistemi olacak olan Windows Server vNext ile gelen yenilikleri incelemeye devam ediyoruz. Makalemizin ilk bölümünde özellikle Active Directory Domain Service için gelen yenilikleri incelemiştik. Bu bölümde diğer özellikleri incelemeye devam edeceğiz.

İlk makalemizde de belirttiğimiz gibi Windows Server vNext geliştirme süreci devam ediyor. Ürünün 2016 yılı içerisinde piyasaya çıkacağını tahmin ediyoruz. Geçen günlerde geliştirme sürecinde “Windows Server Technical Preview 2” sürümü yayınlandı. Windows Server 2016 Technical Preview 2 ISO ya da VHD dosyasını aşağıdaki adresten indirerek testlerinize başlayabilirsiniz:
https://www.microsoft.com/en-us/evalcenter/evaluate-windows-server-technical-preview

Hyper-V Dünyasında Neler Geliyor?

Windows Server Technical Preview 2 Hyper-V rolünde gelen yenilikleri sıralayacak olursak:

·       Hyper-V Cluster Upgrade Yenilikleri 

·       Storage quality of service (QoS)

·       Sanal Sunucular İçin Konfigürasyon Versiyonu

·       Yeni Nesil Sanal Sunucu Konfigürasyonu Dosya Formatı

·       Yeni Nesil Snapshot Özelliği : Production Checkpoint

·       Hyper-V Manager Aracında Yenilikler

·       Windows Update Üzerinden Integration Service Dağıtımı

·       Kesintisiz NIC ve Memory Ekleme/Çıkarma

·       Linux Secure Boot

·       Connected Standby Uyumluluğu

Hyper-V Cluster Upgrade Yenilikleri  : Mevcut yapıda çalışan bir Windows Server 2012 R2 Hyper-V Cluster yapısına Windows Server Technical Preview 2 Hyper-V sunucusunu dahil edebilme desteği geliyor. Bundan önceki sürümlerde Hyper-V yükseltme projelerinde yeni versiyonla yeni bir cluster yapısı kurup, eski versiyondaki iş yüklerini bu yeni Hyper-V Cluster yapısına taşıyorduk. Windows Server Technical Preview 2 Hyper-V sunucular ile beraber artık yeni bir cluster kurmaya gerek kalmadan mevcut Windows Server 2012 R2 cluster yapısına “Node” olarak ilave edip geçişi gerçekleştiriyoruz. İlk etapta Cluster yapısı Windows Server 2012 R2 Cluster fonksiyonel seviyesinde çalışmaya devam edecek. Ve bu yapıda sanal sunucular Windows Server 2012 R2 ve Windows Server Technical Preview 2 arasından live migration vb. operasyonları destekleniyor. Tüm Hyper-V sunucular Windows Server Technical Preview 2 versiyonuna geçiş yapıldıktan sonra Cluster fonksiyonel seviyesini Windows Server Technical Preview 2’ye yükseltiyoruz. Bu yükseltme operasyonunu PowerShell komut satırından Update-ClusterFunctionalLevel cmdlet ile gerçekleştiriyoruz. Bu yükseltme sonrası Windows Server Technical Preview 2 Hyper-V ile gelen yenilikleri kullanabiliyor olacaksınız. Bu yükseltme yapılmadan Hyper-V tarafında gelen yenilikler aktif olmayacaktır. Windows Server 2012 R2 cluster fonksiyonel seviyesinde çalışan yapıda cluster, Hyper-V sunucular ve sanal sistemlerin yönetimi Windows Server Technical Preview 2 ya da Windows 10 Technical Preview sistemlerinden yapılabiliyor. Cluster fonkssiyonel seviyesi Windows Server Technical Preview 2’ye yükseltilmeden sanal makine konfigürasyon versiyonlarının da yükseltilmesi desteklenmiyor. Yükseltme sonrasında yine PowerShell komut satırından Update-VmConfigurationVersion cmdlet ile makine konfigürasyon versiyonlarının yükseltilmesini gerçekleştirebilirsiniz.

ÖNEMLİ NOT : Cluster fonksiyonel seviyesi Windows Server Technical Preview 2 yükseltildikten sonra tekrar Windows Server 2012 R2 fonksiyonel seviyesine geri dönüş desteklenmiyor. Windows Server Technical Preview 2 Cluster fonksiyonel seviyesine yükseltilen bir Hyper-V cluster yapısına artık Windows Server 2012 R2 Hyper-V sunucu eklenmesi desteklenmez.

Storage quality of service (QoS) : Windows Server Technical Preview 2 Hyper-V ile beraber Scale-Out File Server (SOFS) üzerine kurulu Hyper-V cluster mimarilerinde sanal diskler için storage QoS(Quality of Services)  politikaları uygulama desteği de geliyor. Böylece storage performansı belirlenen politikalara göre otomatik olarak davranış gösteriyor.

Sanal Sunucular İçin Konfigürasyon Versiyonu : Windows Server 2012 R2 Hyper-V sunucular üzerinde çalışan bir sanal sunucuyu Windows Server Technical Preview 2 Hyper-V sunucu üzerine taşıdığınızda ya da import ettiğinizde sanal sunucunun konfigürasyon dosyası otomatik olarak güncellenmiyor. Böylece yeni versiyon üzerinde oluşabilecek olumsuz durumlarda ya da üzerinde çalışan bir uygulamadan dolayı desteklenmeme gibi sorunlarda tekrar Windows Server 2012 R2 üzerine geri alabiliyor durumdayız. Fakat yukarıda bahsettiğimiz cluster fonksiyonel seviyesinde olduğu gibi sanal sunucuların konfigürasyon versiyonunu da Windows Server Technical Preview yükseltmeden yeni gelen sanal sunucu özelliklerini kullanamıyor durumdayız. Bir diğer deyişle sanal sunucunun konfigürasyon versiyonu o sanal sunucunun hangi Hyper-V versiyonundaki sunucularla uyumlu olduğunu gösterir. Sanal sunucu konfigürasyon versiyonunu manuel olarak yükseltiyoruz. Windows Server 2012 R2 uyumlu sanal sunucuların konfigürasyon versiyonu “5”’dir. Bu sanal sunucular hem Windows Server 2012 R2 hem de Windows Server Technical Preview 2 Hyper-V üzerinde çalışabilir. Sanal sunucu konfigürasyon versiyonu “6” ya yükselttikten sonra bu sanal sunucuların Windows Server 2012 R2 üzerinde çalışması desteklenmemektedir.

Mevcut durumda çalışan sanal sunucuların versiyon bilgisi için aşağıdaki gibi PowerShell komut satırından Get-VM cmdlet kullanarak Version özelliğinden elde edebilirsiniz.

Mevcut durumda çalışan sanal sunucuların versiyon yükseltmesi için de yine PowerShell komut satırından Update-VmConfigurationVersion cmdlet kullanıyoruz. Gördüğünüz gibi Windows Server Technical Preview ile PowerShell cmdletler daha renkli J Ve bu komutun kategorisine göre otomatik gelen bir özellik.

ÖNEMLİ NOT : Sanal sunucuların versiyon yükseltmesi sonrasında aşağıdaki durumlarla  karşılaşacaksınız:

·       Bu sanal sunucular artık Windows Server 2012 R2 Hyper-V sunuculara taşınamazlar.

·       Konfigürasyon versiyonu yükseltilen sanal sunucuların versiyonu 6’dan tekrar 5’e çekilemez.

·       Sanal sunucuların konfigürasyon versiyonunun yükseltilebilmesi için sanal sunucunun tamamen kapatılması gerekir. Bu da bir anlamda kesinti anlamına geliyor.

·       Cluster fonksiyonel seviyesi Windows Server 2012 R2 olan Hyper-V cluster yapılarından  Update-VmConfigurationVersion cmdlet bloklanmıştır. Dolayısıyla bu cmdlet kullanılabilmesi için cluster fonksiyonel seviyesinin Windows Server Technical Preview yükseltilmesi gerekir.

·       Sanal sunucuların konfigürasyon versiyonunun yükseltilebilmesi sonrasında yeni konfigürasyon dosya formatlarını kullanıyoruz.

Yeni Nesil Sanal Sunucu Konfigürasyonu Dosya Formatı : Windows Server Technical Preview 2 Hyper-V ile beraber artık sanal sunucuların konfigürasyon dosyaları formatı da değişiyor. Yeni formatla artık sanal sanal sunucu konfigürasyon bilgilerinin yazılması ve okunması çok daha sağlam, güvenli, performanslı ve verimli bir yapıda gerçekleşecek şekilde tasarlanmış. Ve özellikle storage hataları ya da problemlerinde konfigürasyon dosyalarındaki bozulmalar da en aza indirgenecek şekilde düzenlenmiş. Yeni konfigürasyon dosyaları:

·       .VMCX : Sanal sunucu konfigürasyon verilerini tutar.

·       .VMRS : Çalışma zamanı durum bilgisi tutar.

.VMCX binary formatında bir dosyadır. Hem .VMCX hem de .VMRS doğrudan düzenlenemez ya da içeriklerinde değişiklik yapılması desteklenmez.

Yeni Nesil Snapshot Özelliği,  Production Checkpoint : Windows Server Technical Preview 2 Hyper-V ile beraber artık sanal sunucular için iki farklı snapshot (checkpoint) geliyor: Standart CheckPoint ve Production Checkpoint. CheckPoint kavramı Hyper-V dünyasında snapshot teknik deyiminin karşılığı. Windows Server 2012 R2 Hyper-V ile beraber Snapshot kavramı System Center Virtual Machine Manager ürünündeki kullanımla da paralellik göstermesi açısından CheckPoint olarak isim değiştirdi. Kullanım amacı çalışır durumdaki bir sanal sunucunun disklerinin, CPU ve memory bilgisi, donanım konfigürasyonu, durum bilgisi ve verileri ile ilgili anlık yedeğini oluşturmaktır. Böylece gerçekleştireceğimiz bir aksiyon sonrası oluşabilecek olumsuz durumlarda alınan snapshot geri dönerek sağlıklı kopyayı etkinleştirmiş oluyoruz. Standart checkpoint bildiğimiz eski checkpoint operasyonu. Production checkpoint ise yeni bir özellik ve saved state teknolojisi yerine sanal sunucu üzerindeki VSS altyapısını kullanarak veri-tutarlı yedeklemeyi destekleyecek snapshot almayı sağlıyor.

Bu yeni checkpoint sayesinde artık sanalda çalışan ve veritabanı yapısını sahip SQL Server, Exchange Server gibi veri-yoğun sanal sistemlerin snapshot alıp, ihtiyaç durumunda bu snapshotlara geri dönüldüğünde sadece uygulamanın değil verilerin de tutarlı bir biçimde geri yüklenmesi sağlanıyor. İhtiyaç durumunda göre Production checkpoint alınamamsı durumunda Standart checkpoint alınacak şekilde de yapılandırabiliyoruz(Fallback yeteneği).

Hyper-V Manager Aracında Yenilikler : Windows Server Technical Preview 2 Hyper-V ile beraber Hyper-V yönetim konsolunda da yenilikler var:

·       Uzaktaki bir Windows Server Technical Preview ya da Windows 10 Technical Preview Hyper-V host bağlanırken alternatif kullanıcı hesabı bilgileri desteği.

·       Windows Server Technical Preview Hyper-V Manager ile artık eski versiyon Windows Server 2012, Windows Server 2012 R2, Windows 8 ya da Windows 8.1 Hyper-V sistemleri yönetebiliyoruz.

·       Windows Server Technical Preview Hyper-V Manager Hyper-V hostlarla WS-MAN protokolü üzerinde haberleşiyor. WS-MAN protokolü ile CredSSP, Kerberos ve NTLM kimlik doğrulama methodlarını destekleniyor. Ayrıca WS-MAN protokolü 80 portu üzerinden erişim sağladığı için network katmanındaki operasyonları ve erişim standartları açısından da avantajlar sağlıyor.

Windows Update Üzerinden Integration Service Dağıtımı : Windows Server Technical Preview Hyper-V ile sanal sunucular için Integration Service paketleri artık Windows Update servisi üzerinden dağıtılıyor durumda. Böylece integration service ISO dosyasını kullanarak yükleme gereksinimi ortadan kalkmış oluyor. Özellikle servis sağlayıcıların (hoster) müşteri sistemleri (tenant) için Windows güncellemeleri dağıtımında artık sanal sunucu için integration service güncellemeleri de yapılmış durumda olacak. Windows Server Technical Preview artık eskiden kullanılan vmguest.iso dosyasını da içermiyor.

Kesintisiz NIC ve Memory Ekleme/Çıkarma : Windows Server Technical Preview 2 Hyper-V ile sanal sunucu çalışıyorken kesinti olmaksızın ağ kartı aygıtı eklenip, çıkartılabiliyor. Bu özellik sadece Generation 2 sanal sunucular için hem Windows hem de Linux tabanlı işletim sistemleri için destekleniyor. Yine sanal sunucu çalışıyorken kesinti olmaksızın memory ilave etme ya da azaltma operasyonları servis kesintisi olmadan yapılabiliyor. Dynamic Memory aktif edilmemiş durumda da bu özellik destekleniyor. Memory değerinde artırma ve azaltma durumu hem Generation 1 hem de Generation 2 sanal sunucular için destekleniyor.

Linux Secure Boot : Windows Server Technical Preview 2 Hyper-V ile Linux işletim sisteminde çalışan Generation 2 sanal sunucular için secure boot desteği geliyor. Sanal sunucunun ilk açılışından önce Microsoft UEFI Certificate Authority kullanması için gerekli tanımlamayı yapmanız gerekiyor. Bu işlem için yine PowerShell komut satırında aşağıdaki komut icra ediyoruz:

Connected Standby Uyumluluğu : Always On/Always Connected (AOAC) güç modelini destekleyen bilgisayarlar üzerinde Hyper-V rolü etkinleştirildiğinde artık Connected Standby güç durumu destekleniyor. Özellikle Surface aygıtlarında karşılaştığımız ve üzerinde Hyper-V rolü etkinleştirildiğinde devre dışı kalan Connected Standby güç durumu artık devre dışı kalmıyor J Eski Hyper-V versiyonlarında ise Hyper-V rolü etkinleştirildiğinde sadece Hibernate ve Fast Startup güç durumları destekleniyor, Connected Standby etkinliğini kaybediyordu. Bu durumda da Surface cihazımız bir PC gibi çalışıyor, kapağını kapattığınızda cihaz uyku moduna geçmiyordu.

Yeni Nesil Client İle Geliyor ?

Windows Server Technical Preview 2 sunucu işletim sisteminin istemci (client) işletim sistemi de Windows 10 Technical Preview. Dolayısıyla Windows Server Technical Preview özelliklerinin istemci tarafı ile ilgili olanları Windows 10 Technical Preview üzerinde de geliyor.

Yeni İşletim Sistemi Dağıtımı : Windows Server Nano  

Windows Server vNext ile yeni bir işletim sistemi kurulum seçeneği geliyor : Windows Server Nano. Şu an için Windows Server Technical Preview 2 sürümü üzerinde henüz bu seçenek yok. Bundan bir sonraki çıkacak sürümde gelmesini bekliyoruz. Windows Server Nano, Windows Server işletim sisteminin 64-bit mimaride çalışan, komut satırı tabanlı bir dağıtımı. Windows Server 2012 R2 ya da Windows Server 2012 R2 Core’dan farkı konsol arayüzünün olmadığı, mikroservisler için tasarlanmış yeni bir dağıtım. Server Core sürüme göre daha da küçültülmüş bir sürüm. Windows Server 2012 R2 Core sürümü için kapladığı alan 4 GB iken, Windows Server Nano için bu değer 0.4 GB boyutunda.

Windows Server ve Windows Server Nano karşılaştırıldığında elde edilen sonuçlar:

·       Yüzde 93 daha küçük VHD boyutu

·       Yüzde 92 daha az kritik güncelleme gereksinimi

·       Yüzde 80 daha az yeniden başlatma gereksinimi

Bu kazanımlar aşağıdaki aksiyonlarla sağlanmış durumda:

·       Grafik arayüzü kaldırılmış

·       32-bit desteği (WOW64) kaldırılmış

·       MSI ve Server Core bileşenlerinden bazıları kaldırılmış

·       Yerel oturum açma desteği yok

·       Uzak masaüstü oturum açma desteği yok

·       Yönetim tamamen uzaktan özel olarak tasarlanmış web-tabanlı yönetim konsolu, Server Manager konsolu, PowerShell ya da WMI ile sağlanıyor.

·       Sonradan isteğe bağlı Windows Rol ya da feature eklenebiliyor. Fakat bu rol ya da feature’lara ait binary’ler işletim sistemi üzerinde mevcut değil.

·       Büyük oranda yönetim, kontrol ve izleme için PowerShell Desired State Configuration bileşeni kullanılıyor.

Nano Server ihtiyacı özellikle uzun yılların birikimi, müşteri talepleri ve bulut teknolojilerinin geldiği nokta ile ön görülen yol haritası da göz önünde bulundurularak aşağıdaki ihtiyaçlara cevap verecek şekilde geliştiriliyor:

·       Mümkün olan en minimum seviyede yama ve yeniden başlatma ihtiyacı

·       İşletim sistemi imajlarında çok daha küçük boyutlar

·       İşletim sistemi hazırlanması ve provizyonlama sürecinde mümkün olan en az kaynak kullanımı (özellikle bulut mimarisine hizmet veren sunucular için)

·       Windows Server sürücü desteği Nano server için de geliyor.

·       İşletim sistemi provizyonlama süresinin daha da azaltılması

·       Sunucu rolleri ve isteğe bağlı feature’ların Nano Server dışına çıkartılması

·       Yerel yönetim araçları yerine web tabanlı grafiksel yönetim araçları (Azure Portal benzeri)

·       Nano Server üzerinde gelen rol ve feature’lar : Hyper-V, Clustering, Storage rolleri, Core CLR, ASP.NET vNext, PaaSv2 ve Container’lar.

·       Nano server üzerinde yerleşik olarak Antimalware koruması geliyor.

Windows Nano Server gelecek kuşak bulut altyapı ve uygulamalarının üzerine inşa edileceği önemli bir sürüm. Güçlü altyapısı ile hem modern bulut altyapılarını güçlendirecek özellikleri barındırması hem de bulut tabanlı uygulamalar için optimize edilmiş olması Windows Nano Server’ı öne çıkaran yenilikler.

Windows Server 2012 ve sonrasında Windows Server Core ve Windows Server GUI modları arasında dönüşüm ya da geçiş feature ekleme ya da kaldırma ile mümkün olabiliyordu. Fakat aynı durumunda Nano Server için olmayacak gözüküyor. Ayrıca Nano Server, Core Edition ya da GUI sürümler gibi tüm rolleri desteklemiyor olacak.

Windows Server Antimalware Koruması

Windows Server Technical Preview 2 sürümü Windows Server Antimalware koruması yüklü ve aktif çalışır durumda geliyor. Windows Server Antimalware sayesinde sunucumuzun bilinen kötü amaçlı yazılımlara karşı aktif bir koruma sağlanmış olacak. Antimalware ile ilgili güncellemeler Windows Update üzerinden sürekli güncelleniyor olacak. İlk kurulumda Windows Server Antimalware için yönetim arayüzü kurulmuyor. Grafiksel aracı kurmadan WMI, PowerShell ya da Group Policy üzerinden yönetimi gerçekleştirebilirsiniz.

 İsteğe bağlı olarak Server Manager yönetim aracından Add Roles and Features Wizard, ya da PowerShell komut satırından Install-WindowsFeature cmdlet ile Windows Server Antimalware grafiksel aracının kurulumunu gerçekleştirebilirsiniz.

PowerShell İle Neler Geliyor?

Windows Server Technical Preview 2 sürümü ile şu an için PowerShell 5.0 sürümü geliyor. Windows PowerShell 5.0 ile Windows-tabanlı ortamların daha kolay ve daha kapsamlı yönetimi ve kontrol edilmesine yönelik önemli yenilikleri içeriyor.

Windows PowerShell 5.0 geriye-dönük uyumluluk desteği ile PowerShell 2.0, PowerShell 3.0 ve PowerShell 4.0 ile geliştirilmiş cmdlet, script, eklenti, fonksiyon vb. yapıları da herhangi bir değişikliğe gerek kalmadan destekliyor.

Windows PowerShell 5.0 şu an için hem Windows Server Technical Preview 2 sürümü ile hem de Windows 10 Technical Preview client ile kurulu olarak geliyor. Windows Server 2012 R2 ya da Windows 8.1 üzerinde kullandığınız PowerShell versiyonunu PowerShell 5.0 yükseltmek için Windows Management Framework 5.0 Preview paketini indirebilirsiniz.

Windows PowerShell 5.0 İle gelen yenilikleri maddeler halinde sıralayacak olursak:

·       $PSVersionTable.PSVersion değeri 5.0 olarak güncellendi.

·       Class kullanım desteği

·       PowerShell CLI’da komut yazımına göre otomatik renklendirme desteği

·       Etiketleme (Tagging) Destekli Write-Information Cmdlet

·       ConvertFrom-String Cmdlet

·       Dosya ve klasörlerin arşivlenmesi için Microsoft.PowerShell.Archive modülü

·       Yazılım paket yönetimi için PackageManagement (OneGet) modülü

·       Modül Arşive Deposu İçin PowerShellGet Modülü ve Register-PSRepository Cmdlet

·       Hidden Anahtar Sözcüğü

·       Get-Command cmdlet Çıktısında Version Özelliği

·       New-Item, Remove-Item, ve Get-ChildItem İçin SymbolicLink Item Tipi

·       Get-ChildItem cmdlet için –Depth parametre desteği

·       Copy-Item cmdlet ile komut satırı tabanlı Server Core ve Windows Nano Server’ı da destekleyecek Windows PowerShell oturumları arası dosya ve klasör kopyalama

·       Windows PowerShell ISE için Transcript Desteği

·       Detaylı PowerShell Script İzleme ve Analiz yeteneği

·       Mesaj Kriptolama Cmdlet Desteği (Get-CmsMessage, Protect-CmsMessage, ve Unprotect-CmsMessage)

·       Microsoft.PowerShell.Utility modülünde yeni cmdletler (Get-Runspace, Debug-Runspace, Get-RunspaceDebug, Enable-RunspaceDebug, ve Disable-RunspaceDebug)

·       Format-Hex cmdlet İle hexadecimal biçimde görüntüleme

·       Get-Clipboard ve Set-Clipboard cmdletler ile Windows PowerShell oturumları arası pano işlemleri

·       Microsoft.PowerShell.Management modülünde Clear-RecycleBin Cmdlet eklentisi

·       Script çalışmaları için New-TemporaryFileİle geçici dosya oluşturma desteği

·       Out-File, Add-Content, ve  Set-Content cmdletler için –NoNewline parametre desteği

·       New-Guid cmdlet

·       Windows PowerShell Scriptlerinde Debug İçin Enter-PSHostProcess ve Exit-PSHostProcess cmdlet desteği

·       Wait-Debugger cmdlet ile Scriptlerde bekletme yeteneği

·       PowerShell Workflow debugger için komut tamamlama ya da tab ile tamamlama desteği

·       PowerShell Job’larında debug işlemleri için Debug-Job cmdlet

·       PowerShell Job’ları için AtBreakpoint Durumu

·       Test-ModuleManifest cmdlet İle modül versiyon doğrulama desteği

·       NetworkSwitch modülü ile Windows Server logo-sertifikalı switch ve VLAN yönetimi

·       Import-Module ve  Remove-Module cmdlet için FullyQualifiedName parametre desteği ile aynı modülün çoklu versiyonlarını saklama ve çağırabilme desteği

·       Save-Help, Update-Help, Import-PSSession, Export-PSSession, ve Get-Command cmletler için FullyQualifiedName parametre desteği ile aynı modülün çoklu versiyonlarını kullanabilme desteği

Yukarıda sıraladığımız Windows PowerShell temel yapısındaki yeniliklere ilave olarak PowerShell Desired State Configuration (DSC) modülünde de önemli yenilikler geliyor. Bunları da genel olarak sıralayacak olursak :

·       PowerShell ile Class kullanım desteği sayesindeWindows PowerShell Desired State Configuration (DSC) kaynaklarının class ile kullanım desteği. Import-DscResource cmdlet ile ilgili modül içerisinde DscResource özniteliklerini çağırabilme desteği.

·       PSDesiredStateConfiguration modülü içerisindeki aşağıdaki cmdletlere ThrottleLimit parametre desteği eklendi. Bu sayede istenilen cmdletin aynı anda paralel olarak kaç sunucu ya da aygıtta o işi yapacağı belirleniyor olacak.

o   Get-DscConfiguration

o   Get-DscConfigurationStatus

o   Get-DscLocalConfigurationManager

o   Restore-DscConfiguration

o   Test-DscConfiguration

o   Compare-DscConfiguration

o   Publish-DscConfiguration

o   Set-DscLocalConfigurationManager

o   Start-DscConfiguration

o   Update-DscConfiguration

·       Merkezi DSC hata raporlama desteği ile hatalar sadece EventLog içerisine değil aynı zamanda merkezi bir konuma da gönderilerek sonradan analiz için kullanılabiliyor olacak.

·       Windows PowerShell ISE içerisinde Configuration ve Node blokları altında DSC kaynaklarının tanımlanmasına ilişkin yenilikler

·       Node blok içerisinde PSDscRunAsCredential ile istenilen kimlik bilgileri ile çalıştırma desteği

·       Configuration deyimi için 32-bit desteği

·       WaitForAll, WaitForAny, ve WaitForSome ile DSC konfigürasyonlarının çapraz sistemler arası senkronizasyonu

·       Delegasyon güvenliğinde Just Enough Administration (JEA)

·       PSDesiredStateConfiguration modülüne eklenen yeni cmdletler

o   Get-DscConfigurationStatus

o   Compare-DscConfiguration

o   Publish-DscConfiguration

o   Test-DscConfiguration

o   Update-DscConfiguration

Windows Server Technical Preview 2 sürümü ile Windows PowerShell 5.0 Integrated Scripting Environment (ISE) konsolunda da bazı yenilikler geliyor:

·       Uzaktaki sunucularda kayıtlı PowerShell script ya da dosyalarınn PowerShell ISE içerisinden düzenlenebilme desteği geliyor. Bu sayede üzerinde PowerShell ISE kurulu olmayan Server Core ya da Nano Server gibi sürümlerin üzerinde bulunan scriptlerinin uzaktan değiştirilebilmesi ve geliştirilebilmesi. Bu tip kullanım durumlarında PSEdit aracını kullanıyorak ilgili dosyanın yolunu tanımlıyoruz.

·       PowerShell ISE içerisinde Start-Transcript cmdlet desteği

·       Break All (Ctrl+B) menü komutu ile yerel ya da uzakta çalıştırılan tüm scriptlerin durdurulması

Ağ Hizmetlerinde Neler Geliyor?

Windows Server Technical Preview 2 sürümü ile ağ hizmetlerinde gelen yenilikler:

·       DHCP Scope’lar üzerinde NAP desteği kalkıyor.

·       DNS Sunucularda DNS Politikaları geliyor. Bu sayede DNS sunucunun DNS sorgularına cevap verme davranışı istemcinin konum, zaman vb. parametrelere göre belirlenerek değişkenlik gösterebilecek.

·       DNS Politikalarında konum-duyarlı DNS, trafik yönetimi, yük dengeleme, split-brain DNS vb. senaryolar uygulanabilecek.

·       PowerShell içerisinde DNS yönetimine yönelik yeni cmdletler

·       Windows Server Gateway rolünde Generic Routing Encapsulation (GRE) tunnelözelliği geliyor. GRE ile müşteri ağı ile dış ağlar arasında tek bir gateway kullanılarak erişim sağlanabiliyor. Bu özellik System Center VMM üzerinden de yönetilebiliyor.

Microsoft’un yeni nesil işletim sistemi olacak olan Windows Server vNext geliştirme sürecinde “Windows Server Technical Preview 2” sürümü ile gelen yenilikleri makale serimizin bu ikinci bölümünde sizlerle paylaşmaya devam ettik. Windows Server 2016 çıkışı için henüz çok erken olsa da sizlerle şimdilik görünen yenilikleri paylaşmaya devam ediyoruz. Ürün şu an için geliştirme aşamasında olduğundan dolayı anlattığımız özelliklerde ya da arayüzlerde ilerki sürümlerde farklılıklar ya da özelliklerin kaldırılması, eklenmesi gerçekleşebilir. Biz de zaman içerisinde çıkacak yeni sürümlerdeki yenilikleri paylaşmaya çalışacağız. Windows Server Technical Preview 2 yeniliklerini incelemeye devam edeceğiz. Bir sonraki makalemizde görüşmek üzere esenkalın.

Microsoft’un yeni nesil işletim sistemi olacak olan Windows Server vNext ile gelen yenilikleri incelemeye devam ediyoruz. Bundan önceki iki makalemizde Windows Server 2016 ile gelen yenilikleri genel olarak incelemiştik:

 Windows Server vNext 2016 Technical Preview 2 Yenilikleri – Bölüm1

Windows Server vNext 2016 Technical Preview 2 Yenilikleri – Bölüm2

Yukarıda linklerini verdiğimiz makalelerimizde de belirttiğimiz gibi Windows Server vNext geliştirme süreci devam ediyor. Ürünün 2016 yılı içerisinde piyasaya çıkacağını tahmin ediyoruz. Mayıs ayı içerisinde “Windows Server Technical Preview 2” sürümü yayınlandı. Yine Mayıs ayı içerisinde ürünün resmi adının da Windows Server 2016 olacağı duyuruldu. Windows Server 2016 Technical Preview 2 ISO ya da VHD dosyasını aşağıdaki adresten indirerek testlerinize başlayabilirsiniz:
https://www.microsoft.com/en-us/evalcenter/evaluate-windows-server-technical-preview

İki bölümden oluşan bu makale serimizde de sizlerle Windows Server 2016 ile network servislerinden DNS servisinde gelecek olan “DNS Politikaları (DNS Policies)” konusunu inceliyoruz.

DNS Politikalarına Giriş ve Öngereksinimler?

DNS Politikaları Windows Server 2016 Technical Preview 2 (TP2) ile gelen yeni bir özellik. Kullanım amacı, bir DNS sunucunun kendisine gelen DNS sorgularına nasıl cevap vereceğini belirlemek ya da belirtmek. 

DNS sorgularına nasıl cevap verileceğini belirleyen kuralları oluştururken aşağıdaki parametreler kullanılabilir:

İstemci IP Adresine göre (İstemcinin konumu)

Saate göre

İstemci subnet adresine göre

Taşıma protokolü (TCP ya da UDP)

IP Protokolü (IPv4 ya da IPv6)

Sunucu Ağ kartı IP Adresine göre (DNS Sunucunun DNS isteğini alan ağ kartının adresine göre)

FQDN Adresi (Sorgulanan kaydın FQDN adresine göre, burada wildcard (*) vb. kullanılabilir.)

Sorgu tipine göre (A, SRV, TXT, vb.)

Diğer çeşitli parametreler

Bu parametreler AND ya da OR gibi mantıksal operatörlerle birleştirilerek detaylı kurallar yazılabilir.

Yazılan politikalar sonucunda aşağıdaki aksiyonlardan biri gerçekleşmesi beklenir:

ALLOW : DNS sunucunun belirlenen kurala uygun olarak cevap vermesi sağlanır.

DENY : DNS sunucu gelen sorgu isteğine olumsuz yanıt verir.

IGNORE : DNS sunucu gelen sorgu isteğini sessizce yani yanıt dönmeden sonlandırır (drop).

DNS Politikaları aşağıdaki senaryolarda uygulanabilir:

Konum-duyarlı DNS Senaryosu : Bu senaryo kapsamında istemcinin bulunduğu konuma en yakın DNS sunucudan hizmet alması sağlanır.

DNS Trafik Yönetimi Senaryosu : Bu senaryo kapsamında istemcinin bulunduğu konuma en yakın veri merkezindeki DNS sunucudan hizmet alması sağlanır.

DNS Yük Dengeleme Senaryosu : Bu senaryo kapsamında DNS sunucular arasında yük paylaşımı sağlanır.

DNS Split-Brain Senaryosu : Bu senaryo kapsamında DNS kayıtları farklı zone havuzlarına bölünür,  DNS istemcileri bulunduğu alt ağ adresine bağlı olarak en yakın DNS sunucudan cevap alırlar.

Uygulamalar İçin Yüksek Erişilebilirlik Senaryosu : Bu senaryo kapsamında DNS istemcileri uygulamalar için en sağlıklı uç noktaya yönlendirilir.

Kara Liste Senaryosu : Bu senaryo kapsamında belirlenen coğrafi lokasyondaki DNS istemciler DNS sunucudan hizmet alamaz ve göz ardı edilirler.

DDoS Önleme/Azaltma Senaryosu : Bu senaryo kapsamında DNS cevap paket boyutları sınırlandırılabilir, sorgular karşılanmayabilir, istemciTCP üzerinden bağlantıya zorlanabilir, DNS cevapları belli eşik değerlere sınırlandırılabilir.

Forensics Senaryosu : Bu senaryo kapsamında kara listeye alınan DNS istemciler ulaşmaya çalıştıkları bilgisayar yerine farklı adreslere yönlendirilebilirler.

DNS politikaları sayesinde istemcilerin örneğin bir web sunucunun ip adresini istekten bulunan DNS sorgularının istemcinin bulunduğu alt ağa (subnet) en yakın veri merkezinden cevap verilmesi sağlanmış olacaktır. Benzer bir senaryoyu şirket ortamındaki DNS yapınızı (on-premise) Microsoft Azure genel bulutuna (Azure IaaS) genişletmişseniz bu durumda şirket içindeki alt ağlarda bulunan istemcilerin en yakın veri merkezindeki DNS sunucuya, şirket dışında bulunan kullanıcıların da Azure DNS sunuculardan destek alacak şekilde kurallar yazabilirsiniz.

Aşağıda başka bir detaylı örnek senaryoyu görmektesiniz. Avrupa ve Amerika lokasyonlarında iki farklı veri merkezine sahip büyük bir bulut sağlayıcının host ettiği woodgrove.com web servisi için müşterilerine bulundukları konumdaki en yakın veri merkezinden cevap vererek en hızlı ve kaliteli cevabı sağlamak istiyor.

Böyle bir senaryoda kullanıcı www.woodgrove.com adresine bağlanmak istediğinde oluşan DNS sorgu paketine kullanıcının bulunduğu coğrafi lokasyona en yakın veri merkezindeki web sunucudan cevap verecek şekilde bir senaryo uygulanabilir. Bu makalemizde benzer adımları uygulayarak sizlere adım adım gösteriyor olacağız.

DNS Politikaları “Windows Server Technical Preview 2” sürümü ile sadece PowerShell komut satırı arabiriminden (CLI – Command Line Interface)  yönetilebiliyor. Sonraki Preview versiyonlarında ya da RTM sürümünde DNS politikalarını grafiksel arayüzde DNS Server MMC konsolundan ya da üçüncü parti araçlarla yönetilebileceğini ön görüyoruz. PowerShell DNS modülü içerisinde DNS Politikaları yönetimi için kullanılan cmdlet listesini de aşağıda paylaşıyoruz:

Add-DnsServerRecursionScope

Remove-DnsServerRecursionScope

Set-DnsServerRecursionScope

Get-DnsServerRecursionScope

Add-DnsServerClientSubnet

Remove-DnsServerClientSubnet

Set-DnsServerClientSubnet

Get-DnsServerClientSubnet

Add-DnsServerQueryResolutionPolicy

Remove-DnsServerQueryResolutionPolicy

Set-DnsServerQueryResolutionPolicy

Get-DnsServerQueryResolutionPolicy

Enable-DnsServerPolicy

Disable-DnsServerPolicy

Add-DnsServerZoneTransferPolicy

Remove-DnsServerZoneTransferPolicy

Set-DnsServerZoneTransferPolicy

Get-DnsServerZoneTransferPolicy

DNS Politikaları ile çalışmaya başlamadan öncelikle Windows Server Technical Preview 2 sunucumuza DNS Server rolünü yüklememiz gerekiyor. Bu işlem için aşağıdaki PowerShell komutunu kullanabilirsiniz:

DNS rolünün kurulumu için Server Manager konsolu içerisinden Manage menüsünden Add Roles and Features sihirbazı kullanılarak  da DNS Server rolü seçilip kurulum yapılabilir.

Kurulum sonrası aşağıdaki PowerShell komutu ile de kontrol edebilirsiniz:

DNS rolünün kurulumu sonrasında yapmamız gereken ikinci ön hazırlık DNS içerisinde “zone” açmak. Benim bulunduğum ortamda hali hazırda bir active directory domaini olduğu için active directory domain ismine ait mesutaladag.local isimli bir zone yapım bulunuyor. Buna ilaveten cozumpark.local vb. test amaçlı zone yapılarını da aşağıda oluşturuyor olacağız.

NOT : DNS politikaları Windows Server 2016 TP2 versiyonunda sadece standart primary zone için uygulanabilir durumda. Fakat DNS sunucumuz domain ortamında çalışan bir domain controller ya da domaine üye bir member server olabileceği gibi, workgroup ortamda çalışan bir stand-alone server da olabilir. Active Directory Integrated Zone için destek gelip gelmeyeceğini önümüzdeki sürümlerde takip ediyor olacağız. Diğer yandan DNS politikalarını uygulamak için DNS sunucumuzun işletim sisteminin Windows Server 2016 Technical Preview 2 ya da üzeri versiyonda olması gerekiyor.

Uygulama Adımları

DNS Politikalarını şu anki Windows Server 2016 TP2 sürümünde sadece PowerShell CLI’dan uygulanabildiğini yukarıda bahsettik. Genel olarak adımları maddeler halinde belirtirsek:

DNS İstemci Subnetlerinin Tanımlanması (DNS Client Subnet)

Zone Havuzlarının Oluşturulması (Zone Scope)

Zone Havuzu İçerisine Kayıt Eklenmesi

DNS Politikalarının Oluşturulması

Şimdi de bu adımları gerçekleştirelim:

Öncelikle PowerShell DNS modülü içerisinde DNS politikaları için gelen powershell komutlarını listeliyoruz:

Gördüğünüz gibi bu komutlar birer PowerShell fonksiyonu olarak geliyor.

Bu komutlara ilişkin yardım dosyalarının güncel halini indirmek için de aşağıdaki resimde de görülen Update-Help cmdlet kullanmanız yeterlidir:

DNS Politikalarını uygulamak için DNS sunucumuzda bir zone yapısına sahip olmamız gerekir demiştik. Test amaçlı olarak “cozumpark.local” isimli Standart Primary tipinde bir zone aşağıdaki PowerShell komutu ile oluşturuyoruz:

Zone oluştuktan sonra da bunun oluştuğunu kontrol ediyoruz:

Benim bulunduğum ortamda hali hazırda bir active directory domaini olduğu için active directory domain ismine ait mesutaladag.local isimli Active Directory Integrated tipinde bir zone yapım bulunuyor. Buna ilaveten şimdi oluşturduğumuz cozumpark.local isimli Standart Primary zone yapısını da listede görüyorsunuz.

DNS İstemci Subnetlerinin Tanımlanması (DNS Client Subnet) :

Öncelikle DNS trafik yönetim politikalarını oluşturacağız. Bunun için kural yazacağım DNS subnetlerini ve network adreslerini aşağıdaki şekilde tanımlıyorum:

Benim ağ yapımda 192.168.1.0/24 ve 192.168.2.0/24 olarak iki adet C class yapıda çalışan ip farklı ağ yapım var. Bunları Subnet1 ve Subnet2 olarak tanımladım. Siz de kendi yapınızda DNS politikası yazmak istediğiniz tüm subnetleri bu şekilde ayrı ayrı tanımlanamız gerekiyor. Subnet isimleri olarak Subnet1 ya da Subnet2 yerine Subnet-Istanbul, Subnet-Ankara ya da Subnet-Prod, Subnet-Dev gibi isimler de verebilirsiniz.

Zone Havuzlarının Oluşturulması (Zone Scope)

İkinci adımda da Zone Scope’ları tanımlayacağız.

ZoneScope, DNS politikasını uygulayacağımız Zone’ları içeren ve kural uygulama kapsamına almak istediğimiz subnetlerle ilişkilendirmeyi içeren yapılar olacak.

Zone Havuzu İçerisine Kayıt Eklenmesi

Şimdi de cozumpark.local zone’u içerisinde ismi “testrecord” olan A kaydı açıyoruz:

İsmi aynı olsa da farklı iki subnet için o subnetlere göre ip adreslerini tanımlıyoruz. Subnet1 için 192.168.1.111, Subnet2 için de 192.168.2.111 .

DNS Politikalarının Oluşturulması

Sıra geldi DNS Server tarafında gerekli politikamızı yazmaya. Bunun için son olarak da örnek iki adet politika yazacağız. DNS sunucunun kendisine gelen isteklere nasıl cevap vereceği bu politika içerisinde belirtilen kurala göre işleyecektir.

Yukarıdaki şekilde de görüldüğü gibi DNS sunucumuz üzerinde farklı iki subnet için gerekli kurallarımızı yazarak bunların DNS sunucudan alacakları cevapları belirlemiş olduk. Subnet1’den gelen isteklere Subnet1ZoneScope içerisinde tanımladığımız kayıtlarla Subnet2’den gelen isteklere de Subnet2ZoneScope içerisinde tanımladığımız kayıtlarla cevap verecek şekilde yapılandırdık.

Artık yazdığımız DNS politikalarını test etmek için hazırız. Test istemcilerimizi öncelikle Windows Server 2016 TP2 sürümünde çalışan DNS Sunucu adresini kullanacak şekilde ayarlıyoruz. Bu işlem için de Set-DNSClientServerAddress cmdlet kullanabilir ya da Network and Sharing Center içerisinde grafiksel arayüz kullanarak  da Preferred DNS Server adresini belirleyebilirsiniz:

Şimdi oluşturduğumuz test record için farklı subnetlerde bulunan istemcilerin davranışlarını kontrol edeceğiz. Bizim örneğimizde 192.168.1.0/24 ve 192.168.2.0/24 subnetleri mevcut. Öncelikle 192.168.1.0 subnetindeki istemci üzerinden Resolve-DNSName isimli powershell cmdlet kullanarak testrecord.cozumpark.local kaydı için bir DNS isteği gönderiyoruz:

Görüldüğü gibi istemcinin subneti 192.168.1.0/24 olduğu için yazdığımız kurala uygun olarak 192.168.1.111 adresinden yanıt döndü.

Benzer şekilde Subnet2’den yine testrecord.cozumpark.local kaydı için bir DNS isteği gönderdiğimizde bize 192.168.2.111 olarak yanıt döndüğünü görüyoruz. Böylece yazmış olduğumuz kurala uygun olarak DNS sunucumuzun yanıt vermesini sağlamış olduk.

Şimdi de saat bazlı bir politika yazarak farklı bir senaryo uygulayalım. Bunun için Subnet1Policy isimli politikamızı sadece belli saatlerde cevap verecek şekilde güncelliyoruz. Bu işlem için aşağıdaki şekilde de görüldüğü gibi Set-DNSServerQueryResolutionPolicy cmdlet kullanıyoruz:

Bu yazdığımız kuralla DNS sunucumuzun cozumpark.local isimli zone için sadece 21:00 – 23:59 saatleri arasında cevap verecek şekilde bir kısıtlama uyguladık.

Bu kısıtlama sonrası istemciden test edeceğiz. Öncelikle DNS Client cache’ini Clear-DNSClientCache cmdlet ile temizliyoruz. Sonrasında da Get-Date cmdlet ile bulunduğumuz andaki sistem saatini kontrol ediyoruz:

Şu an bulunduğumuz saat 20:36 olduğu için DNS sunucumuz cozumpark.local isimli zone isteklerine cevap vermemesi gerekiyor. Şimdi testrecord.cozumpark.local isimli test kaydımızı tekrar sorgulayalım:

Evet aldığımız hatayı yukarıdaki şekilde görüyorsunuz. DNS sunucumuz böyle bir DNS kaydı olmadığını söylüyor. DNS sunucumun saatini 21:01 yapıyorum:

İstekte bulunacağım istemcime tekrar gidip DNS cache’ini temizleyip sonrasında tekrar istekte bulunduğumuzda herhangi bir sorun olmadan cevap verdiğini görüyoruz:

ÖNEMLİ NOT : Burada önemli olan sunucunun saatidir. DNS sunucumuz yazılan politikalar için saat kısıtlaması varsa burada kendi saatini baz alır.

Bu senaryoda da DNS sunucumuzun subnetlere göre farklı DNS zone’lar için sadece günün belli saatlerinde cevap vermesi, bu saatler dışında da o zone’lar için gelecek isteklere yanıt vermemesini sağlayabiliyoruz.

ÖZETLE :

Microsoft’un yeni nesil işletim sistemi olacak olan Windows Server 2016 geliştirme sürecinde “Windows Server Technical Preview 2” sürümü ile gelen yeniliklerden “DNS Politikaları” konusunu incelediğimiz iki bölümden oluşan makale serimizin ilkininin sonuna geldik. Windows Server 2016 çıkışı için henüz çok erken olsa da sizlerle şimdilik görünen yenilikleri paylaşmaya devam ediyoruz. Ürün şu an için geliştirme aşamasında olduğundan dolayı anlattığımız özelliklerde ya da arayüzlerde ileriki sürümlerde farklılıklar ya da özelliklerin kaldırılması, eklenmesi gerçekleşebilir. Biz de zaman içerisinde çıkacak yeni sürümlerdeki yenilikleri paylaşmaya çalışacağız. Windows Server Technical Preview 2 yeniliklerini incelemeye devam edeceğiz. “DNS Politikaları” konusunu incelediğimiz makalemizin ikinci bölümünde görüşmek üzere esenkalın.

Microsoft’un yeni nesil işletim sistemi olacak olan Windows Server vNext ile gelen yenilikleri incelemeye devam ediyoruz. İki bölümden oluşan “DNS Politikaları (DNS Policies)” konusunu incelediğimiz makale serimizin ikinci bölümü ile devam ediyoruz. Makalemizin ilk bölümünde de belirttiğimiz gibi DNS Politikaları Windows Server 2016 Technical Preview 2 (TP2) ile gelen yeni bir özellik. Kullanım amacı, bir DNS sunucunun kendisine gelen DNS sorgularına nasıl cevap vereceğini belirlemek ya da DNS trafiğini filtrelemek ya da yönetmek. Bir diğer ifade ile istemcilerin DNS sorgularının merkezi olarak politika-tabanlı kurallarla yönetimini sağlamak.

Makalemizin bu bölümünde ilk bölümde giriş yaptığımız DNS politikaları ile ilgili farklı kullanım senaryolarına ilişkin aşağıdaki örneklemeleri yapıyor olacağız:

DNS Sorgularına Filtreleme Uygulamaları

DNS Politikalar İle Uygulama Yük Dengeleme ve Paylaşım Uygulamaları

Makalemin ilk bölümüne ulaşmak için

http://www.cozumpark.com/blogs/windows_server/archive/2015/06/14/windows-server-2016-tp2-dns-politikalari-bolum-1.aspx

DNS Sorgularına Filtreleme Uygulamaları:

DNS Politikalarını şu anki Windows Server 2016 TP2 sürümünde sadece PowerShell CLI’dan uygulanabildiğini makalemizin ilk bölümünde bahsettik. Dolayısıyla uygulamalarımıza da PowerShell CLI uygulamasını açarak devam ediyoruz. Bu başlık altında DNS sorgularına filtreleme uygulamalarını inceliyoruz.

İlk örneğimizde; belli bir domaine göre DNS sorguların bloklanmasını gerçekleştirelim. Özellikle DNS sistem yöneticilerinin zararlı ya da organizasyon standartlarına uygun olmayan DNS belli domainler için DNS sunuculara gelen istekleri bloklamak isteyebilirsiniz. Bunu DNS politikaları ile kolaylıkla bloklayabiliriz. Bu işlem için de “Add-DnsServerQueryResolutionPolicy” isimli cmdlet aşağıdaki şekilde kullanılarak cozumpark.local ile biten DNS domaini için gelen DNS sorgu istekleri bloklanmış olur. Burada kuralımızı herhangi bir subnet ya da DNS zone parametresi belirtmeden uyguladık. Bu şekilde uygulanan politikalara “Sunucu Seviyesinde DNS Politikaları (Server-Level DNS Policies)” adını veriyoruz. Sunucu seviyesinde uygulanan DNS politikaları DNS sorgularında ilk uygulanan kurallardır. Uygulanan komuta dikkat edersek Action parametresine “IGNORE” aksiyonu aldırarak gelen isteklerin yanıt dönmeden sonlandırılması (DROP) sağlanmış oluyor.

DNS sunucu üzerindeki bu politika sonrasında istemci üzerinde testrecord.cozumpark.local için istekte bulunduğumuzda hata aldığımızı görüyoruz.

İkinci örneğimizde; belli bir ip subnetine göre DNS sorguların bloklanmasını gerçekleştirelim. Bu tip kullanım da özellikle virüs, trojan ya da solucan gibi zararlı yazılımların bulaşmış olduğu belli subnetlerden DNS sunucuya gelen isteklerin bloklanması için kullanılabilir. Bu işlem için de “Add-DnsServerClientSubnet” isimli cmdlet aşağıdaki şekilde kullanılarak Subnet parametresi ile belirtilen 192.168.2.0/24 subnet yapısından gelen DNS sorgu istekleri bloklanmış olur. Bu komutun uygulanabilmesi için öncelikle bu subnetin tanımlanmış olması gerekiyor. Subnet tanımlama işlemleri için makalemizin ilk bölümünü inceleyebilirsiniz.

Bu örneğimizi biraz daha genişleterek belirtilen subnetlerden yine sadece belli domainler için gelen DNS sorguları bloklansın isterseniz de FQDN parametresini de ekleyerek aşağıdaki komutu uygulayabilirsiniz:

Bu komut sonrasında Subnet1’den gelen ve cozumpark.local ile biten DNS sorguları bloklanmış olacaktır.

Üçüncü örneğimizde; belli bir sorgu tipine göre DNS sorgularının bloklanmasını gerçekleştirelim. Bu işlem için de “Add-DnsServerQueryResolutionPolicy” isimli cmdlet aşağıdaki şekilde kullanılarak ANY tipindeki yani tüm kayıt tipleri için gelen DNS sorgu istekleri bloklanmış olur.

Yukarıdaki komut içerisinde –Qtype parametresi içerisinde ANY yerine SRV,MX vb. kayıt tipi de belirtilebilir.

Dördüncü örneğimizde de; DNS sunucumuzun sadece belli bir domain için gelen sorgulara cevap verip, bunun dışındaki sorguları bloklaması için de aşağıdaki şekilde görülen komutu çalıştırıyoruz.

Komuta dikkat ederseniz –FQDN parametresinde EQ (Equal yani “eşittir”) yerine NE (Not Equal yani “eşit değildir”) ibaresi kullanıldı. Bu komut sonrasında ismi cozumpark.local ile bitmeyen tüm DNS sorguları bloklanmış olacaktır.

Beşinci örneğimizde de; DNS sunucumuzun sadece belli bir subnetten gelen sorgulara cevap verip, bunun dışındaki sorguları bloklaması için de aşağıdaki şekilde görülen komutu çalıştırıyoruz:

Örneğimize dikkat ederseniz AllowPolicy isimli sunucu seviyesinde oluşturduğumuz bir politika ile Subnet1 subneti dışındaki tüm subnetlerden gelen istekler bloklanıyor.

Altıncı örneğimizde de; DNS sunucumuzun sadece belli DNS kayıt tipleri için gelen sorgulara cevap verip, bunun dışındaki sorguları bloklaması için de aşağıdaki şekilde görülen komutu çalıştırıyoruz:

Komuta dikkat edersek AllowPolicyQType isimli bir politika ile A, AAAA,MX,NS ve SOA dışındaki DNS kayıtları için DNS sunucumuzun 192.168.1.200 ip adresli ağ kartına gelen istekler bloklanmış olacaktır.

Uygulama Yük Dengeleme ve Paylaşım Uygulamaları:

DNS politikaları ile uygulama sunucularında yük dengeleme ya da yük paylaşım senaryoları da tasarlanarak uygulanabilir.  Örneğin; aşağıdaki şekilde görüldüğü gibi cozumpark.com web adresi İstanbul, Ankara ve İzmir lokasyonlarındaki üç farklı veri merkezinden ve farklı ip adreslerinden yayın yaptığını düşünelim. Bu lokasyonlardan en yoğun istek alanı İstanbul veri merkezi ve buna paralel olarak da sunucu altyapısı daha güçlü bir mimaride tasarlanmış. Bu tasarıma göre isteklerin yarısı İstanbul veri merkezindeki sunucular üzerinden diğer yarısı da Ankara ve İzmir veri merkezlerindeki sunucular arasında paylaşılarak servis vermesini planlıyoruz.

Windows Server işletim sisteminin önceki versiyonlarında böyle bir tasarımı DNS katmanında gerçeklemek ve uygulamak mümkün değildi. DNS katmanında gerçeklenen en iyi model DNS round-robin çözümünü uygulamaktı. Fakat bu çözüm bizim yukarıda istediğimiz tasarımın uygulanması için yeterli değil. Windows Server 2016 ile gelen DNS politikaları ile uygulama sunucuları istenilen oranda DNS katmanında yük paylaşımına tabi tutmak mümkün. Bu senaryoyu hayata geçirmek için aşağıdaki aksiyonların sırayla yerine getirilmesi gerekir:

Zone Havuzlarının Oluşturulması

Zone Havuzlarına DNS Kayıtlarının Eklenmesi

DNS Politikalarının Oluşturulması

Zone Havuzlarının Oluşturulması:

Öncelikle İstanbul, Ankara ve İzmir için ilgili zone havuzlarını oluşturuyoruz. Zone havuzu o zone için benzersiz olan tanımdır. Bir DNS zone için birden fazla zone havuzu oluşturabilirsiniz. Her zone havuzu içerisinde kendisine özgü DNS kayıtlarını tanımlayabilirsiniz. Diğer yandan aynı kayıt birden fazla zone havuzu içerisinde de farklı ip adresleri ile tanımlanabilir.

Zone Havuzlarına DNS Kayıtlarının Eklenmesi:

Şimdi de web sunucumuza ait ip adresi kaydının zone havuzu içerisine ekliyoruz. IstanbulZoneScope içerisine İstanbul veri merkezinden yayın yapacak www.cozumpark.com için 192.168.1.205 ip adresli kaydımızı; AnkaraZoneScope içerisine Ankara veri merkezinden yayın yapacak www.cozumpark.com için 172.16.1.205 ip adresli kaydımızı; IzmirZoneScope içerisine de İzmir veri merkezinden yayın yapacak www.cozumpark.com için 10.1.1.205 ip adresli kaydımızı tanımlıyoruz.

DNS Politikalarının Oluşturulması

DNS sisteminde politika yazmak için gerekli bölümler yani zone havuzları tanımlandıktan sonra sıra geldi gelen istekleri bu zone havuzlarına paylaştıracak ya da yükü dağıtacak politikamızı yazmaya. Bu politika sayesinde www.cozumpark.com için gelen isteklerin %50’si İstanbul veri merkezindeki ip adresi tarafından karşılanırken, geriye kalan %50 yük de Ankara ve İzmir ip adresleri arasında eşit olarak DNS sunucu vasıtasıyla paylaştırılacak.

Yukarıdaki uygulanan komutta ZoneScope parametresi ile DNS sunucusunun <ZoneScope>,<weight> kombinasyonunda yapılandırılmıştır. Bu parametreye yapılan tanım ile DNS sunucuya www.cozumpark.com için gelen her dört sorgu için DNS sunucumuz ilk iki sorguya İstanbul veri merkezindeki web sunucunun ip adresini gönderirken, üçüncü sorgu için Ankara veri merkezindeki web sunucusunun ip adresini, dördüncü sorgu için de İzmir veri merkezindeki web sunucusunun ip adresini gönderecektir. Bu şekilde yüzlerce farklı politika tanımlayıp farklı veri merkezleri arasında yük dengelemesi sağlayacak şekilde istenilen kurallar yazılabilir. Yazılan DNS politikaları dinamik olarak devreye girecektir, DNS Server servisini yeniden başlatmaya gerek kalmayacaktır.

Split-Brain (Split-Horizon) Senaryosu:

DNS politikaları DNS zone yapılarında yaşanan split-brain ya da split-horizon senaryolarının yönetimi için de tasarlanarak uygulanabilir. Split-brain ya da split-horizon, bir DNS zone için birden fazla versiyon (bir tanesi iç kullanıcılar için diğeri de dış dünyadaki kullanıcılar için) bulunması durumunda gerçekleşen senaryodur. Bir başka ifade ile aynı DNS alan adı (zone) için yapılan DNS sorgulamasında istek yapan ip adresine göre DNS sunucu tarafından farklı ip adreslerinin geri dönülmesi durumu split-brain ya da split-horizon olarak ifade edilir.

Aynı DNS Alanı (Zone) İçin İki Farklı Versiyon

Örneğin; www.cozumpark.com web sitesi için; iç kullanıcılara hizmet vermek için 192.168.1.205 lokal ip adresinden, dış kullanıcılar yani dış dünya için de 188.132.200.15 numaralı gerçek ip üzerinden yayın yapacak şekilde iki farklı versiyona sahip olalım. DNS politikalarının olmadığını düşündüğümüzde yani Windows Server 2016 öncesi versiyonlarda bu ihtiyacı karşılamak için iki farklı Windows Server DNS sunucu üzerinde bu DNS alanları (zone) konumlandırılarak ayrı ayrı yönetilmesi gerekir. Windows Server 2016 ile gelen DNS politikaları sayesinde tek bir Windows Server DNS sunucu üzerinde host edilebilir durumdadır.

Eğer cozumpark.com dns alanını host eden DNS sunucusunun iki farklı Ethernet arabirimi bulunuyorsa; bir tane iç ağa bağlı 192.168.1.200 ip adresine sahip, bir tane de dış dünyaya bağlı 188.132.200.15 ip adresine sahip durumda ise böyle bir senaryo için oluşturulacak DNS politika adımlarını aşağıda bulabilirsiniz:

Zone Havuzlarının Oluşturulması

Zone Havuzlarına Kayıtların Eklenmesi

Politikaların Oluşturulması

Zone Havuzlarının Oluşturulması:

Öncelikle Internal isimli zone havuzunu oluşturuyoruz. Bu zone havuzu içerisinde www.cozumpark.com için iç kullanıcıların erişim yapacağı versiyon olacaktır.

Varsayılan durumda DNS sunucu üzerinde aynı alan adından (zone) bir zone havuzu mevcuttur. Bu zone havuzu aynı zamanda www.cozumpark.com adresi için dış erişim adresini de host ediyor olacak.

Zone Havuzlarına Kayıtların Eklenmesi

Bu adımda da web sunucuya ait iç ve dış erişim DNS kayıtlarının ilgili ip adresleri ile zone havuzuna eklenmesini gerçekleştireceğiz:

İkinci komuta dikkat ederseniz –ZoneScope parametresi kullanmadık. Çünkü bu kayıt varayılan zone havuzuna ekleniyor. Bu şekilde kullanım normal zone yapısına kayıt yapmakla aynıdır. Zaten bu işlemden sonra DNS konsolunu açarsanız DNS zone içerisinde –ZoneScope parametresi kullanmadan açılan kaydı göreceksiniz.

DNS Politikalarının Oluşturulması

Yukarıdaki adımlardan sonra sıra geldi DNS politikasını oluşturmaya. Aşağıdaki şekilde görüldüğü gibi SplitBrainZonePolicy isimli sunucumuzun iç ağa bağlı 192.168.1.200 ip adresine gelen cozumpark.com isteklerine izin veren bir politika yazdık.

Bu kural sonrasında DNS sunucusuna iç ağdan gelen sorgulara www.cozumpark.com için 192.168.1.205 olarak cevap dönerken, dış dünyaya bağlı Ethernet arabirimine gelen www.cozumpark.com istekleri için de dış dünyada tanımlı 188.132.200.15 ip adresini cevap olarak gönderecektir. 

ÖZETLE :

Microsoft’un yeni nesil işletim sistemi olacak olan Windows Server 2016 geliştirme sürecinde “Windows Server Technical Preview 2” sürümü ile gelen yeniliklerden “DNS Politikaları” konusunu incelediğimiz iki bölümden oluşan makale serimizin sonuna geldik. Windows Server 2016 çıkışı için henüz çok erken olsa da sizlerle şimdilik görünen yenilikleri paylaşmaya devam ediyoruz. Ürün şu an için geliştirme aşamasında olduğundan dolayı anlattığımız özelliklerde ya da arayüzlerde ileriki sürümlerde farklılıklar ya da özelliklerin kaldırılması, eklenmesi gerçekleşebilir. Biz de zaman içerisinde çıkacak yeni sürümlerdeki yenilikleri paylaşmaya çalışacağız. Windows Server Technical Preview 2 yeniliklerini incelemeye devam edeceğimiz yeni makalelerde görüşmek üzere esenkalın.

İki bölümden oluşacak bu makale serimizde organizasyonlarda her geçen gün yaygınlaşan Microsoft Internet Information Server (IIS) web ve ftp sunucu sistemleri üzerinde yönetimsel ve güvenlik alanlarında uygulanan en iyi uygulama kriterleri hakkında bilgi sahibi olacaksınız. Genel olarak önerilerimizi Windows Server 2012 R2 ile gelen IIS 8.5 versiyon arayüzünde inceliyor olsak da aynı standartlar IIS 7.0 ve sonrası tüm versiyonlar için geçerli olacaktır. Güvenlik teknolojilerindeki yeniliklere göre makalemizde belli dönemlerde güncellemeyi hedefliyoruz. Bu makalede belirtilen yöntemler en iyi uygulama deneyimleri ve gerçek hayattan uygulamalardan elde edilen tecrübeleri paylaşmak amacına yönelik bir içeriktir. Bu öneriler oluşabilecek güvenlik riskleri ya da zaafiyetlerini en aza indirgemeyi amaçlamakla birlikte güvenlik açıkları ya da problemlerinizin tamamen yok olacağı garanti edilmemektedir.

Web sunucusu üzerindeki yönetimsel ve güvenlik alanındaki en iyi yapılandırma prensiplerini aşağıdaki şekilde de görüldüğü gibi fiziksel katmandan başlayarak ele alıp ağ katmanı, kullanıcı katmanı ve verinin korunması katmanı olarak farklı seviyelerde ele alıyor olacağız.

Böylece çok katmanlı bir savunma yaklaşımı ile web sunucular üzerindeki yönetimsel ve güvenlik standartlarını değişen teknoloji ve kullanıcı deneyimleri de göz önüne alınarak daha da iyileştirmenizi hedefliyoruz.

Makalemiz içerisinde en iyi yapılandırma adımlarını aşağıdaki alanlarda inceliyoruz:

Kurulum

Temel Yapılandırmalar

Güvenlik Yapılandırmaları

ASP.NET Yapılandırmaları

Günlük Dosyalarının Yapılandırılması

İçerik Yönetim Yapılandırmaları

Yük Dengeleme Yapılandırmaları

Web Sunuculara Özel İzole Active Directory Yapılandırmaları

Diğer Yapılandırmalar

Bu makalemizde bahsi geçen belirli ticari marka isimleri kendi özgün sahiplerine aittir.

Kısaltmalar

Kurulum

Bu başlıkta IIS 8.5 web sunucularda kurulum alanındaki en-iyi-yapılandırma deneyimleri (best-practice) paylaşılacaktır:

IIS rolünü domain controller ya da additional domain controller sunucular üzerinde aktifleştirmemelisiniz. Bunun birinci nedeni özellikle web sunucularda sıklıkla kullanılan yerel hesapların (local account) domain controller rolüne sahip sunucular üzerinde bulunmamasıdır.

IIS web sunucu rolü ile domain controller rolünün aynı sunucu üzerinde olması da güvenlik hesabı seçeneklerinizi önemli oranda sınırlandırmaktadır.

Web servislerinden dolayı web sunucu üzerinde oluşan bir güvenlik zaafiyet vakası tüm domain yapısını hatta tüm ağ yapınızı etkileyecektir.

Web sunucular üzerine sadece gerekli olan modülleri ve bileşenleri kurmalısınız. IIS 8.5 ile kırkın (40) üzerinde modül içermektedir. İhtiyacınız olan modülü kolaylıkla ilave edebilir, kullanılmayan modülleri de kaldırabilirsiniz. Sadece ihtiyacınız olan modülleri yükleyerek potansiyel saldırı ya da ataklara karşı saldırı gelebilecek yüzeyi de daraltmış olacaksınız.

Peryodik olarak IIS modüllerini gözden geçirerek kullanılmayan ya da istenmeyen modülleri kaldırın. Bu bir önceki maddede bahsettiğimiz gibi sizin saldırı gelme riski olan alanı mümkün olan en aza indirgeyecektir.

Yüksek hacimli IIS kurulumları için (özellikle çok katmanlı uygulamalarda) SQL Server, Exchange Server gibi yoğun kaynak ihtiyacı olan ürünleri IIS sunucular dışında ayrı sunucularda konumlandırın.

Antivirüs, antimalware gibi güvenlik yazılımlarınızı güncel tutun.

IIS kurulumu sonrasında sistem sürücüsü altında oluşan “Inetpub” klasörünü ve diğer web sitelerine ait içerik klasörlerini farklı bir sürücüye taşıyın. Böylece hem sistem diskinde oluşabilecek disk alanı darboğazlarının önüne geçmiş hem de güvenlik etkilerini en aza indirgemiş olacaksınız. Inetpub içeriğinin taşınması için APPCMD.exe ve XCOPY araçlarını kullanabilirsiniz. Bu konuyu ayrı bir makalede ele alıyor olacağız.

Temel Yapılandırmalar

Bu başlıkta IIS 8.5 web sunucularda en-iyi-yapılandırma deneyimleri (best-practice) referans alınarak uygulanan temel yapılandırma standartlarını bulacaksınız.

Web İçeriğinin Sistem Diski Haricinde Bir Konumda Saklanması

IIS üzerinden yayınlanan servislere ait içerikler sistem diski dışında bir disk bölümünde saklanmalıdır. Bu sayede :

Web içerikleri sistem bölümünden izole bir alanda saklanmış olur.

Web içeriğinin sistem alanındaki yer kullanması ya da tüketiminin önüne geçilmiş olur.

Web içeriğinden oluşan I/O yükünün sistem dosyalarının performansı ve veri bütünlüğü açısından oluşabilecek riskler de en aza indirgenmiş olacaktır.

Ayrıca web içeriğinden oluşabilecek gizlilik ve hassas durumlar da ortadan kaldırılmış olur.

Web Siteleri Üzerinde Host Header Tanımlama Standardı

IIS üzerinden yayınlanan tüm web siteleri üzerinde Host Header tanımlaması yapılmalıdır.

Bu sayede :

Aynı ip adresi ve port numarasından çoklu web site yayını yapılabilir.

DNS rebinding saldırılarına karşı koruma sağlanmış olmaktadır.

IP-tabanlı taramalarda IIS üzerinde host edilen uygulamanın tanımlanması da kolaylıkla sağlanmış olacaktır.

Web Siteleri Üzerinde Directory Browsing Kapatılması

IIS üzerinden yayınlanan site yapılandırmalarında “directory browsing” özelliği kapatılmalıdır.

Bu sayede :

Web site içeriklerinin browser tabanlı web istemcileri üzerinden görülmesi engellenmiş olacaktır.

Web site içerisindeki özel bir dosya içeriğine doküman listesinden erişim riski azaltılmış olacaktır.

Web site içeriğindeki hassas dökümanlara kontrolsüz erişim engellenmiş olacaktır.

Web Siteleri ve Uygulamaları Tarafından Bağımsız Application Pool Kullanımı

Application Pool kimlikleri (Identity) web sunucuları üzerindeki w3wp.exe isimli iş süreçlerini çalıştırmaya yetkili hesap ya da otoritelerdir. Web siteleri ve uygulamaları üzerinde application pool ataması yaparken her web site ya da uygulama için benzersiz, farklı application pool tanımlanmasına özen gösterilmelidir. Bu sayede :

Web site ya da uygulamalarının birbirlerinden farklı uygulama havuzları kullanmaları sağlanmış olacaktır.

Web site ya da uygulamada meydana gelecek bir kilitlenme, duraklama ya da kaynak problemi diğer web site ya da uygulamaları etkilemeyecektır.

Yoğun-kaynak ihtiyacı olan web site ya da uygulamalarının farklı uygulama havuzları kullanmalarıyla sunucu ve servisin performansı da artırılmış olacaktır.

Uygulamaların erişilebilirlik seviyesi de artırılmış olacaktır. Herhangi bir uygulama havuzunda oluşan bir sorundan sadece o uygulama havuzunu kullanan web sitesi ya da servisleri etkilemiş olacak, diğerleri hizmet kesintisi ya da duraklama yaşamayacaktır.

Web site ve uygulamaları farklı uygulama havuzlarında barındırıldıkları için uygulama seviyesinde yetkisiz erişim riski de azaltılmış olacaktır.

Web site ve uygulamaları farklı uygulama havuzlarında barındırıldıkları için kullanılmayan bir uygulama havuzunu istenildiği zaman durdurmak diğer servislerde kesintiye neden olmayacaktır.

Güvenlik Yapılandırmaları

Bu başlıkta IIS 8.5 web sunucularda en-iyi-yapılandırma deneyimleri (best-practice) referans alınarak uygulanan güvenlik yapılandırma standartlarını bulacaksınız.

Windows Kimlik Doğrulamasın Genişletilmiş Koruma Özelliği

IIS web sunucuları üzerinde Windows authentication kimlik doğrulaması aktif ise mutlaka genişletilmiş koruma özelliği olan “Extended Protection” da açmanızı öneriyoruz.

Windows Authentication kullanılabilmesi için Web Server rolü altındaki bileşenlerden kurulmuş olması gerekir. Aşağıda PowerShell ile bu gereksinim kontrol edip yüklüyoruz.

Anonim Kimlik Doğrulamasını Doğru Yapılandırın

IIS web sunucuları üzerinde Anonymous authentication kimlik doğrulaması ile birlikte diğer kimlik doğrulama yöntemlerini aktif etmemeye mümkün olduğunca dikkat edin. Çünkü çalıştığı modüle bağlı olarak çoğu durumda öncelikli olarak Anonymous authentication kimlik doğrulaması devreye gireceği için diğer kimlik doğrulamalarında sorunlara neden olacaktır.

Diğer yandan sunucu dizinlerine ve kaynaklarına anonim kimlik erişim hesabına yetki vermeyiniz. Sunucuya yapılacak dosya yükleme ya da yazma işlemleri için anonim hesabı dışındaki hesapları özellikle kullanmanızı tavsiye ediyoruz.

Default Application Pool Kimliğinin Minimum Yetkiye Sahip Principal Hesabına Atanması

Application Pool kimlikleri (Identity) web sunucuları üzerindeki w3wp.exe isimli iş süreçlerini çalıştırmaya yetkili hesap ya da otoritelerdir. Bu sayede :

Doğru ve geçerli kimlik bilgisinin tanımlanması web uygulaması ya da servisinin fonksiyonel olarak doğru çalışmasını da garanti altına almaktadır.

Aynı zamanda web uygulaması ya da servisinin gerekli en az yetkili hesapla çalıştırılarak, gereğinden fazla yetkili hesap kullandırmayarak oluşabilecek güvenlik riskleri ve zafiyetleri de en aza indirgenmiş olacaktır.

Bu aksiyon web site içeriğinde yapılabilecek zararları ya da manipülasyonları da engellemiş olacaktır.

Web Siteleri ve Uygulamaları Tarafından Kullanılan Application Pool Kimliğinin Benzersiz Olmasına Dikkat Edilmesi

Application Pool kimlikleri (Identity) web sunucuları üzerindeki w3wp.exe isimli iş süreçlerini çalıştırmaya yetkili hesap ya da otoritelerdir. Web siteleri ve uygulamaları üzerinde application pool kimlikleri tanımlanırken her web site ya da uygulama için benzersiz, farklı kimlikler tanımlanmasına özen gösterilmelidir. Bu sayede :

Doğru ve geçerli kimlik bilgisinin tanımlanması web uygulaması ya da servisinin fonksiyonel olarak doğru çalışmasını da garanti altına alınmaktadır.

Aynı zamanda web uygulaması ya da servisinin gerekli en az yetkili hesapla çalıştırılarak, gereğinden fazla yetkili hesap kullandırmayarak oluşabilecek güvenlik riskleri ve zafiyetleri de en aza indirgenmiş olacaktır.

Bu aksiyon web site içeriğinde yapılabilecek zararları ya da manipülasyonları da engellemiş olacaktır.

Web site ya da web uygulamasının ilgili alanına sadece ilgili kimlik bilgisi ile minimum yetki seviyesinde erişim sağlanması garanti altına alınmış olacaktır.

Bu sayede her uygulama havuzunun (application pool) benzersiz bir kimlikle çalışması sağlanmış olacaktır.

Anonymous User Kimliği Olarak Application Pool Kimliğinin Yapılandırılması

IIS sistemleri üzerinde uygulama havuzları için farklı uygulama kimlikleri kullanılabilir. IIS web site ya da uygulaması üzerindeki application pool kimlik yapılandırmasında anonymous kullanıcı hesabı tanımlanmamışsa application pool isimli kimliğini kullanması şeklinde yapılandırma yapılabilir. Bu durumda IIS üzerinde ihtiyaç duyulan hesap kimliği de minimum sayıya indirgenmiş olacak, hesap yönetimi de kolaylaşacaktır. Önerilen Application Pool Identity’nin Anonymous User Identity olarak yapılandırılmasıdır. Bu yapılandırma minimum yetki ile servislere erişimin yapılmasını sağlarken, site yönetimini de kolaylaştıracaktır.

Web Sitesi Dynamic IP Address Kısıtlanması

IIS web sunucular üzerinde ihtiyaca göre ip adresi, network adresi ya da domain bilgisine göre erişim kısıtlamaları yapılmalıdır. Bu sayede :

Yetkisiz kişi ve sistemlerin web sitesine erişimi engellenmiş olur.

Dinamik olarak tanımlanan kapsamda olan sistemler kısıtlama kapsamına girmektedir.

DDOS saldırıları engellenmiş olacaktır.

Dynamic ip kısıtlaması için web sunucu üzerinde Web-IP-Security isimli IP and Domain Restrictions bileşeninin  kurulu olması gerekir. Standart web server kurulumunda bu özellik kurulu gelmez. Yüklemek için aşağıdaki şekilde görülen PowerShell komutlarını işletmek gerekecektir.

Bu işlemden sonra IIS konsolu içerisinde IP and Domain Restrictions görünmüş olacaktır.

IP Address and Domain Restrictions kısıtlamaları aşağıdaki seviyelerde uygulanabilir:

IIS Sunucu seviyesinde

Web Site seviyesinde

Web Application seviyesinde

Üst seviyeden uygulanan kısıtlamalar miras yoluyla alt seviyelere geçmektedir.

IP Address and Domain Restrictions simgesi üzerine çift tıklayınca gelen aşağıdaki ekranda sağ kısımda gelen Actions menüsü kullanılarak izin verilecekler için Allow Entry, yasaklanacaklar için de Deny Entry seçenekleri kullanılır. Spesifik IP adresi için kısıtlama ya da izin verme uygulanabileceği gibi IP adres aralığı ya da IP Subnet tanımı da yapılabilir.

Bu ekranda tanımlanmamış diğer adresler için geçerli olacak aksiyon ayarını da Edit Feature Settings ile belirleyebilirsiniz:

Yukarıdaki şekilde de görülen ekranda “Access for unspecified clients” ile tanımlanmamış istemciler için erişim durumu izin verilsin derseniz Allow yasaklansın derseniz de Deny seçeneklerinden uygun olanı liste kutusundan seçebilirsiniz. Yine bu ekranda “Enable domain name restrictions” kutucuğu işaretlenerek domain bazında da Allow Entry ya da Deny Entry tanımlanabilir, ilgili seçenekler Add Allow Entry ya da Add Deny Entry seçeneklerinden uygun olana tıklayınca gelecektir.

FTP Sitesi Erişiminin Kısıtlanması

IIS web sunucular üzerinde FTP hizmetlerinde ihtiyaca göre ip adresi, network adresi ya da domain bilgisine göre erişim kısıtlamaları yapılmalıdır. Bu sayede :

Yetkisiz kişi ve sistemlerin ftp sitesine erişimi engellenmiş olacaktır.

Dinamik olarak tanımlanan kapsamda olan sistemler kısıtlama kapsamına girmiş olacaktır.

Yetkisiz kişiler tarafından FTP içeriği görüntülenmesi ya da içerik yüklenmesi engellenmiş olacaktır.

Brute force ataklar bloklanmış olacaktır. Böylece yerel Administrator hesabının ele geçirilip saldırı yapılmasının da önüne geçilmiş olacaktır.

Yetkisiz kullanıcıların web site içeriğini kapsayan ftp alanına zararlı yazılımlarla oluşturabileceği riskler engellenmiş olacaktır.

FTP User Isolation yöntemi kullanılarak kullanıcıların FTP alanında sadece kendilerine izin verilen klasör alanına erişmeleri, yetkisiz alanlara erişmeleri engellenmiş olacaktır.

FTP Sitesine erişimde kullanıcı hesabı seviyesinde filtreleme ve sınırlandırma yapılarak yetkisiz kullanıcıların ftp sitesine erişimleri yasaklanmış olacaktır.

FTP Request Filtering yeteneği ihtiyaca göre kullanılarak FTP alanında belirtilen uzantılar dışında içerik yüklenmesi engellenmiş olacaktır.

Web Sitesi Global Authorization Rule İle Erişim Kısıtlanması

IIS 7.0 ile gelen URL Authorization sayesinde dosya sistemi yerine URL-bazlı yetkilendirme kuralları ile web sitesi koruması sağlanmalıdır. Authorization kuralları sunucu, web sitesi, web application, virtual directory ya da dosya seviyesinde uygulanabilir. URL authorization kuralları .NET modülleri, statik sayfalar, ASP sayfaları gibi tüm içeriklere gelen istekler için etkilidir. Bu kapsamda web servisi ve uygulamasına göre sunucu seviyesinde URL Authorization kuralları uygulanarak içerikle beraber hedefe taşınmaktadır. Böylece :

İçeriğin konumu değişse de yukardan aşağıya yetkilendirme kuralları miras olarak aktarılarak sürekli etkinliğini korunacaktır. Bu sayede uygulanan kısıtlamalar konum-bağımsız etkinliğini koruyacaktır.

Şu anki ve gelecekteki web içeriğine erişimde belirlenen kurallar dışında erişimin yapılması engellenmiş olacaktır.

İstek dışı ve yetkisiz erişimlerin yapılması engellenmiş olacaktır.

Web Sitesi Form Kimlik Doğrulamasında SSL Zorlanması

IIS üzerinden yayınlanan web sitesi içeriğine göre form-tabanlı kimlik doğrulaması kullanılan site ya da sayfalar üzerinde SSL erişim zorunluluğu getirilmelidir. Böylece forma girilen bilgilerin kriptolanarak web sunucuya güvenli mimaride iletilmesi sağlanacaktır. SSL sonlandırması uygulamaya göre bazı senaryolarda Load-Balancer aygıtı üzerinde gerçekleştirilebilir. IIS sunucularda gerçekleşen SSL sonlandırmalarında da Load-balancer (yük dengeleme) cihazı gelen isteklere SSL optimizasyon uygulaması sağlanabilir.

ÖZETLE :

İki bölümden oluşan bu makale serimizin ilk bölümünün sonuna geldik. İkinci bölümde de IIS sunucularımız üzerinde aşağıdaki maddeler için yönetimsel ve güvenlik alanında en iyi uygulama standartlarını paylaşmaya devam edeceğiz:

ASP.NET Yapılandırmaları

Günlük Dosyalarının Yapılandırılması

İçerik Yönetim Yapılandırmaları

Yük Dengeleme Yapılandırmaları

Web Sunuculara Özel İzole Active Directory Yapılandırmaları

Diğer Yapılandırmalar

Hoşçakalın.

Mesut ALADAĞ.
Microsoft MVP, MCT, P-TSP
www.cozumpark.com | www.mesutaladag.com

IIS 8.5 ile web sunucularda yönetimsel ve güvenlik alanındaki en iyi uygulamalardan deneyimlerimizi paylaştığımız makale serimizin ikinci bölümünde de birlikteyiz. Bu ikinci bölümde de aşağıdaki kırmızı ile belirtilen maddeleri incelemeye devam edeceğiz :

Kurulum

Temel Yapılandırmalar

Güvenlik Yapılandırmaları

ASP.NET Yapılandırmaları

Günlük Dosyalarının Yapılandırılması

İçerik Yönetim Yapılandırmaları

Yük Dengeleme Yapılandırmaları

Web Sunuculara Özel İzole Active Directory Yapılandırmaları

Diğer Yapılandırmalar

Makalemin ilk bölümüne aşağıdaki link üzerinden erişebilirsiniz

https://www.cozumpark.com/blogs/windows_server/archive/2015/06/21/_31013101_s-8-5-yonetimsel-ve-guvenlik-yapilandirma-uygulamalari-bolum-1.aspx

İlk bölümde olduğu gibi önerilerimizi Windows Server 2012 R2 ile gelen IIS 8.5 versiyon arayüzünde inceliyor olsak da aynı standartlar IIS 7.0 ve sonrası tüm versiyonlar için geçerli olacaktır. Güvenlik teknolojilerindeki yeniliklere ve makale yayınlama takvimimize göre makalemizde belli dönemlerde güncellemeyi hedeflediğimiz tekrar vurgulamak istiyorum. İlk bölümde de belirttiğimiz gibi bu makalemizde belirtilen yöntemler en iyi uygulama deneyimleri ve gerçek hayattan uygulamalardan elde edilen tecrübeleri paylaşmak amacına yönelik bir içeriktir. Bu öneriler oluşabilecek güvenlik riskleri ya da zaafiyetlerini en aza indirgemeyi amaçlamakla birlikte güvenlik açıkları ya da problemlerinizin tamamen yok olacağı garanti edilmemektedir.

Web Sunucu Günlüklerinin Yapılandırılması

Bu başlıkta IIS 8.5 web sunucularda en-iyi-yapılandırma deneyimleri (best-practice) referans alınarak uygulanan web sunucu günlüklerinin yapılandırma standartlarını bulacaksınız.

Web Sunucularda Varsayılan IIS Logging Konumunun Taşınması

IIS web sunucular üzerinde ihtiyaca göre standart log kayıtlarının tutulması amaçlı Logging özelliği aktifleştirilmelidir. Bu sayede sunucu, web sitesi ve web uygulaması seviyesinde olay kayıtları alınarak ilgili sistem ya da servise yapılan bağlantılarla ilgili standart log günlükleri tutulmalıdır.

Oluşan log günlükleri yukarıdaki şekilde de görüldüğü gibi varsayılan konumlarından farklı bir disk sürücüsü üzerine taşınmalıdır. Böylece log büyümelerinde sistem diskinin performansa ya da disk alanına negatif etki edebilecek riskler minimuma indirgenmiş olacaktır.

Web Sunucularda Advanced Logging Etkinleştirilmesi

IIS web sunucular üzerinde ihtiyaca göre ileri seviye log kayıtlarının tutulması amaçlı Advanced Logging özelliği aktifleştirilmelidir. Advanced Logging IIS 8.5 ile gelen ve standart günlük kayıtları yerine ihtiyaca göre özel alanlara ait bilgileri de günlüklemeyi sağlayan bir yetenektir. Bu sayede sunucu, web sitesi ve web uygulaması seviyesinde log tutma aktifleştirilerek ilgili sistem ya da servise yapılan bağlantılarla ilgili detaylı log günlükleri tutulmaktadır. Log kayıtları içerisinde standart alanların dışında ihtiyaca göre özel alanlar da tanımlanabilir (örneğin istemcinin ip adresi gibi.).  İleri seviyede günlük tutma yapılandırması için IIS 8.5 web sunucular üzerinde “Logging” bileşeni kullanılarak ileri seviye günlükleme yetenekleri aktifleştirilebilir:

Yine yukarıdaki şekilde de görüldüğü üzere oluşan log kayıtları sistem diski dışında farklı bir disk sürücüsü üzerinde saklanmalıdır.

Böylece log büyümelerinde sistem diskinin performansına ya da disk alanına negatif etki edebilecek riskler minimuma indirgenmiş olacaktır.

Yukarıdaki gibi özel alanlar eklendikten sonra IIS günlük metin dosya isimlerinin sonuna “_x” ilavesini yapacaktır. “_x” ibaresi günlük dosyası içerisinde özel bir alana ait günlük bilgilerinin tutulduğunu gösterir.

ASP.NET Yapılandırmaları

IIS üzerinden yayınlanan web sitesi içeriğine göre ASP.NET yapılandırmalarında da belli standartlar uygulanmaktadır. ASP.NET yapılandırma standartlarının uygulanması için web sunucumuz üzerinde ASP.NET bileşeninin de kurulmuş olması gerekir. Aşağıda PowerShell cmdlet’ler ile bu bileşenin kurulu olup olmadığını sorgulayıp, sonrasında da kurulumunu yapıyoruz:

IIS konsolu içerisine ASP.NET yapılandırma ayarlarını içeren kategori gelmiş olacaktır.

Artık şimdi ASP.NET için gerekli en iyi yapılandırma deneyimlerini etkinleştirebiliriz.

Debug Yeteneğinin Kapatılması

Uygulama geliştiriciler kod geliştirme sürecinde debug özelliğini aktifleştirirler ve genelde bu özellik bu şekilde kalır. IIS sunucu üzerinde ASP.NET yapılandırma ayarlarında debug özelliği kapatılarak sunucu seviyesinde bu özellik kapatılmalıdır. Böylece:

Potansiyel tehlike olan son kullanıcılara detaylı debug çıktısı vererek uygulamalar hakkında bilgi sahibi olmaları engellenmiş olacaktır.

Kod-seviyesinde açılmış debug özellikleri için savunma mekanizması oluşturuyor.

Debug kapatılması önerilen bir en iyi uygulama yöntemlerindendir.

Bilgi sızmalarına karşı da önemli bir yapılandırmadır.

.NET Özel Hata Sayfalarının Açık Tutulması

ASP.NET uygulaması başarısız olursa “HTTP/1.x 500 Internal Server” hatasına neden olduğunda ya da IIS kategorisindeki “Request Filtering” kurallarına takıldığında bir hata mesajı üretilecektir. Bu durumda kullanıcıya anlaşılır bir hata mesajı sayfası üretmek ya da göstermek isterseniz bu ayar önemlidir. Bu özellik kapalı durumda ise kullanıcıya çok genelleyici bir mesaj görüntülenecektir. Bu özellik açıksa oluşan hataya göre özel mesajlar üretilebilir. IIS sunucular üzerinde bu özelliği açık tutmanızı da öneriyoruz.

Web Sunucu İçerik Yönetim Yapılandırmaları

IIS Web sunucular üzerinden yayınlanan içeriğin yönetimi için merkezi yönetim, otomatik senkronizasyon, güncelleme ve güvenlik standartlarının da mutlaka uygulanmasını öneriyoruz. Şimdi de bunları inceleyelim.

DFS(Distributed File System) İle Merkezi İçerik Dağıtımı

DFS (Distributed File System), Windows sunucu sistemlerinde dosya sunucular için içerik çoğaltmak amacıyla kullanılan bir servistir. Özellikle dosya sunucusu (file server) rolüne sahip sunucular üzerinde File Server rolü altından etkinleştirilebilen bir alt bileşendir. Windows 2000 işletim sisteminden bu yana Windows Server işletim sistemleri üzerinde aynı isimle gelen ve kullanılan bir bileşen. Windows 2008 domain fonksiyonel seviyesi ve sonrası active directory yapılarında da SYSVOL içeriğinin domain controller sunucular arasında replikasyonunu gerçekleştiren DFS Replication bileşeninin de altyapısını oluşturur. Web sunucular için içerik yönetimi de son derece önem arzeden ve sürekli güncel tutulması gereken bir konu. Sahip olduğunuz web sunucu altyapınızda da yük dengeleme mimarisinde yedekli olarak çalışan çok sayıda web sunucuya sahipseniz bunlar üzerinden yayınlanan içeriklerde herhangi bir değişiklik olduğunda bu değişikliğin tüm diğer web sunuculara da tek tek kopyalanması gerekir. Web sunucular üzerindeki bu içerik senkronizasyonunu ya da çoğaltmasını merkezi olarak tek bir sunucu üzerinden gerçekleştirip diğer tüm web sunuculara da DFS altyapısını kullanarak otomatik olarak dağıtabilirsiniz. Bu amaçla web sunuculara ait içerik her web sunucunun kendi üzerinde ayrı ayrı tutuluyorsa tüm web sunuculara aynı zamanda File Server ve DFS Replication rollerini kurup DFS altyapısını oluşturabilirsiniz.

Oluşturulacak DFS altyapısı ile web sunucular üzerinde web içeriklerinin bulunduğu dizinler belirlenen rol dağılımına göre otomatik olarak senkronize edilecektir. DFS topolojisinde yer alan web sunuculardan bir tanesini Primary (Master) olarak seçip, diğerlerini de Replica Member olarak yapılandırıyoruz.

Böylece Primary (Master) sunucu üzerinde bulunan web site içeriklerine ait yapılacak bir güncelleme sonrasında güncellenen içerik ile beraber, güvenlik ayarları, dökümanların nitelikleri, özellikleri ve güvenlik ayarları birlikte (encryption, permission, compression vb.) diğer DFS Replica Member sunuculara belirlenen peryotlarda otomatik olarak senkronize olacaktır.Yapılan içerik senkronizasyonu ya da çoğaltması ile ilgili olarak rutin rapor kayıtları çekilerek operasyonel geçmişe ait raporlarda alınabilir. Böylelikle web site içerik güncellemelerinde yeni kodlar ya da içerikle tek bir sunucuya yüklenecek buradan da otomatik olarak saniyeler içerisinde diğer sunuculara DFS altyapısı ile çoğaltılmış olacaktır.

Robocopy Aracı İle İçerik Senkronizasyonu

Web sunucular üzerinde bulunun içeriğin çoğaltılması ya da senkronizasyonu için kullanılabilecek ikinci seçenek de Robocopy aracı olabilir. Robocopy aracı günümüzde Windows sunucu işletim sistemleri üzerinde yerleşik olarak gelen ve ileri seviye özelliklere sahip dosya transferi aracıdır. Yukarıda DFS servisi kullanılarak yapılan içerik senkronizasyonunu doğrudan Robocopy ile de gerçekleştirebilirsiniz. Benim önerim sunucular arasında içerik senkronizasyonu için DFS altyapısını kullanmanız. Eğer aynı sunucu üzerinde  farklı klasör lokasyonları arasında (aynı disk birimi içerisinde ya da farklı disk birimlerinde konumlandırılmış klasörler olabilir) dosya senkronizasyon ihtiyacınızı olursa da burda Robocopy aracını kullanmanızı öneririm. Bu senkronizasyonda kaynak klasörden hedef klasöre gönderilen içerikle beraber, güvenlik ayarları, doküman nitelikleri, özellikleri (encryption, permission, compression vb.)  belirlenen peryotlarda çoğaltılmaktadır.

Ağ Katmanında Web Sunucular İçin Yük Dengelemesi

Organizasyonunuzda bulunan IIS web sunucuları yedekli ve yük paylaşımını esas alan mimari standartlara göre bir altyapıda konumlandırmalısınız. Yük dengeleme ve yük paylaşımını fiziksel yük dengeleme cihazları ile yapabileceğiniz gibi Windows Network Load Balacing bileşenini ya da IIS’in Application Request Routing (ARR) bileşenini de kullanabilirsiniz. Benim önerim bu amaçla da IIS Web sunucu  farm’ı içerisinde bulunan tüm sunucuların önünde fiziksel olarak yine yedekli mimaride çalışan yük dağıtım ve dengeleme cihazları (Load Balancer) konumlandırılmasıdır. Eğer fiziksel yük dengeleme cihazınız yoksa ya da bütçeniz müsait değilse de IIS’in ARR bileşeni ile bu yük dengelemeyi gerçekleştirmeniz olacaktır. (ARR’ın yük dengeleme dışında gelen isteklerin yönetilmesi ve yönlendirilmesi konularında ileri yetenekleri de mevcuttur.) Yük dengeleme cihazları üzerinde dışardan gelen bağlantının gitmek istediği hedef adrese göre tüm web sunucu tanımları yapılandırılmalı, sunucuların yük dağılımına göre otomatik olarak uygun sunucuya trafik yönlendirilmelidir. IIS web sunuculardan herhangi birinde yaşanacak bir kesinti ya da erişilememe durumunda yük dengeleme cihazı gelen istekleri diğer sunuculara yönlendirerek servis sürekliliğini de sağlamış olacaktır.

Dış Dünyaya Açık Web Sunucu Active Directory Domain Yapılarının Ayrılması

Sahip olduğunuz organizasyon bünyesinde bulunan active directory yapısını dış dünyaya servis veren IIS web sunucuları için kesinlikle kullanmamanız öneriyoruz. Dış dünyaya açık web sunucular için DMZ ağında tamamen izole bir active directory domain yapısı kurulmasını özellikle tavsiye ediyoruz. Bu oluşturulacak DMZ domainde belirlenen domain güvenlik standartları etkinleştirilerek web sunuculara uygulanmalıdır. DMZ ağında oluşturulacak active directory domain yapısında çalışan domain controller sunucular da yine birden fazla sayıda yedekli mimaride kurulmuş olmalıdır.

Diğer Yapılandırmalar

Buraya kadarki kısımda genel olarak dosya sunucular üzerinde uygulanmasını önerdiğimiz başlıkları ayrı ayrı inceledik. Bu başlık altında da genel olarak diğer uygulanması gereken standartları maddeler halinde bahsediyor olacağız:

IIS sunucularınızın periyodik olarak düzenli yedeklerini alın. Günlük ya da iki günde bir system state ve web içerik yedeklerini ihmal etmeyin. Özellikle yama geçişleri ya da yazılım güncellemeleri öncesinde de yine sunucunun son durumdaki bir yedeğini, eğer sanal ortamda ise de snapshot (checkpoint) kopyasını alın.

Sistem yöneticisi dışındaki hesaplar için IIS sunucular üzerinde minimum yetkileri tanımlayın. Böylece bu kullanıcıların web sunucular üzerine yazma ya da script çalıştırma gibi farklı zafiyetlere neden olabilecek aksiyonlarını engellemiş olacaksınız.

Yukarıda da belirttiğimiz gibi web trafiğinin ve verilerinizin güvenliği için SSL servisini mutlaka aktifleştirin. Özellikle bilgi girişi yapılan form vb. sayfalar için SSL’siz kullanım yapmamanızı tavsiye ediyoruz. Kullandığınız SSL güvenlikli servislere ait dijital sertifikaların bakımı, yedeklenmesi ve periyodik güncellemelerini, yenilemelerini kesinlikle ihmal etmeyin.

Basic authentication temel kimlik doğrulaması kullanılan tüm web servisleri için mutlaka SSL güvenliğini devreye alarak trafiği güvenli hale getirin. Aksi halde kullanıcı hesabınızdan verilerinize kadar herşey açık metin olarak kolaylıkla ele geçirilecektir.

Web siteleri üzerinde verilen delegasyon kurallarında varsayılan yetkilerin üzerinde yetkiler vermemeye mümkün olduğunca dikkat edin.

Web sunucularınızın sistem, performans, uygulama sağlığı, ağ bağlantıları ve servis ağacına ait sağlık durumlarını düzenli olarak profesyonel bir ürün ya da platform ile proaktif olarak izleyin. Böylece meydana gelebilecek olumlu ya da olumsuz durumların önceden farkında olarak gerekli aksiyonları ya da önlemlerinizi almış olursunuz. Bu konuda Microsoft System Center platformu içerisindeki System Center 2012 R2 Operations Manager (SCOM) ürünü ihtiyacınıza cevap verecektir. SCOM ile gelen yönetim paketlerini (management pack) kullanarak web sunucularınızın detaylı izlenmesini proaktif bir deneyimle gerçekleştirebilirsiniz.

Web sunucular üzerinde dönemsel olarak gerçekleştirilen operasyonel faaliyetler ya da zaman alan işlemler için yine Microsoft System Center platformu içerisindeki System Center 2012 R2 Orchestrator ürünü ile ya da PowerShell script çözümleri hazırlayarak bu rutin işleri mutlaka otomasyona bağlayın. Böylece günün birinde IIS günlüklerinden dolayı disk alanınızın kalmadığı ya da sunucu yama geçişlerinde atlanan bir prosedür ya da sunucudan dolayı oluşabilecek güvenlik zafiyetlerinden kaynaklı başınıza gelebilecek itibar ya da zaman kayıplarının önüne önceden geçmiş olacaksınız.

ÖZETLE :

İki bölümden oluşan bu makale serimizle organizasyonlarda her geçen gün yaygınlaşan Microsoft Internet Information Server (IIS) web ve ftp sunucu sistemleri üzerinde yönetimsel ve güvenlik alanlarında uygulanan en iyi uygulama yapılandırmalarını sizlerle paylaştık. Umarım faydalı olmuştur. Bir sonraki makalemizde görüşmek dileğiyle, esenkalın.

Mesut ALADAĞ.
Microsoft MVP, MCT, P-TSP
www.cozumpark.com | www.mesutaladag.com

Bu makalemizde Microsoft IIS sunucular üzerinde en iyi güvenlik yapılandırma önerilerinden bir tanesi olan Inetpub dizininin sistem sürücüsü yerine farklı bir sürücüye taşınmasını ele alıyoruz.

Uygulamalarımızı Windows Server 2012 R2 ile gelen IIS 8.5 versiyon arayüzünde inceliyor olsak da aynı standartlar IIS 7.0 ve sonrası tüm versiyonlar için geçerli olacaktır.

INETPUB İÇERİĞİNİ TANIYALIM :  

IIS web sunucularda güvenlik alanındaki en-iyi-yapılandırma pratiklerinden bir tanesi de Inetpub dizininin varsayılan olarak oluştuğu sistem diskinden farklı bir disk sürücüsüne taşınmasıdır. IIS 8.5 öncesi versiyonlarda bu işlemi işletim sistemi kurulumu esnasında katılımsız kurulum dosyası (unattend file) ile yapabiliyorduk. Özellikle Vista ve Windows Server 2008 ile başlayan yeni kurulum süreci ile bu uygulama biraz farklılaştı. Kurulum sonrasında Inetpub dizini otomatik olarak Windows ile aynı dizinde geliyor. Ve Inetpub dizinini Windows harici farklı bir disk sürücüne taşımak da kurulum sonrası gerçekleştirilmesi gerekiyor artık.

Aşağıdaki varsayılan kurulum sonrası Inetpub dizinini kullanan yapılandırma dosyalarını görüyorsunuz. Şimdi bu yapılandırma dosyalarını ve bunların farklı bir dizine nasıl taşındığını birlikte ele alalım. Bazı dizin isimleri sadece IIS 7 ve 7.5 versiyonuna ait olup 8.5 versiyonunda bulamayabilirsiniz.

LOGS\FREBLOGS : Failed Request Event Buffering (FREB) başarısızlıkla sonuçlanan isteklere ait günleri tutar. Varsayılan dizin yolu %systemdrive%\inetpub\logs\FailedReqLogfiles

LOGS\LOGFILES : IIS günlük dosyaları için varsayılan yol tanımı. Varsayılan dizin yolu %systemdrive%\inetpub\logs\logfiles

TEMP\AppPools : AppPool Isolation, ilk olarak IIS 7 ile gelmiş olan yeni bir özellik. IIS üzerinde oluşturulmuş uygulama havuzlarına ilişkin (application pools) yapılandırma dosyaları burada saklanmaktadır. Varsayılan konumu %systemdrive%\inetpub\temp\appPools

HISTORY : IIS sunucular için yapılandırma geçmişini tutar. Bir diğer ifade ile IIS yapılandırma ayarlarının saklandığı administration.config ve applicationHost.config dosyalarının sürekli bir yedeğini saklar. Böylece gerçekleştirilen yapılandırmalar geri alınabilir. Varsayılan konumu %systemdrive%\inetpub\history

TEMP\ASP COMPILED TEMPLATES : Classic ASP uygulamalarında derlenen ASP kodu hafıza alanında 250’yi geçerse derlenen kodlar disk üzerindeki bu alana yazılırlar. Varsayılan disk önbellekleme konumu %systemdrive%\inetpub\temp\ASP Compiled Templates

TEMP\IIS TEMPORARY COMPRESSED FILES : IIS sunucular sıkıştırılmış dosyaları gerektiğinde disk üzerinde önbellekleyebilir. Sıkıştırma önbelleği için varsayılan konum %systemdrive%\inetpub\temp\IIS Temporary Compressed Files

WWWROOT : IIS sunucular Default Web Site isimli varsayılan web sitesi ile gelmektedir. Bu siteden de varsayılan IIS yayını yapılmaktadır. Varsayılan konumu %systemdrive%\inetpub\wwwroot dizinidir.

CUSTERR : IIS sunucular için özelleştirilmiş hata sayfalarının depolandığı dizindir. Varsayılan konumu %systemdrive%\inetpub\custerr dizinidir.

WWWROOT ve FTPROOT: Özellikle servis paketleri (SP) ya da diğer kurulumlarda WWWROOT ve FTPROOT dizinlerinin nerede olduğuna ait bilgiler talep edilir. Bunda dolayı WWWROOT ve FTPROOT dizinlerine ait konum bilgisi registry içerisinde de kayıtlıdır.

INETPUB İÇERİĞİNİ TAŞIYORUZ : 

Yukarıdak maddeler halinde anlattığımız dizinleri sırasıyla taşımaya başlıyoruz. Bu taşıma operasyonlarında APPCMD komut satırı aracını kullanacağız. Tüm yapılandırma dosyaları taşındıktan sonra da INETPUB dizinini XCOPY aracı ile istenilen disk sürücüsüne kopyalayacağız.

LOGS\FREBLOGS Taşınması:

%windir%\system32\inetsrv\appcmd set config -section:system.applicationHost/sites -siteDefaults.traceFailedRequestsLogging.directory:"E:\inetpub\logs\FailedReqLogFiles"

LOGS\LOGFILES Taşınması:

%windir%\system32\inetsrv\appcmd set config -section:system.applicationHost/sites -siteDefaults.logfile.directory:"E:\inetpub\logs\logfiles

%windir%\system32\inetsrv\appcmd set config -section:system.applicationHost/log -centralBinaryLogFile.directory:"E:\inetpub\logs\logfiles

%windir%\system32\inetsrv\appcmd set config -section:system.applicationHost/log -centralW3CLogFile.directory:"E:\inetpub\logs\logfiles

TEMP\AppPools Taşınması:

reg add HKLM\System\CurrentControlSet\Services\WAS\Parameters /v ConfigIsolationPath /t REG_SZ /d E:\inetpub\temp\appPools

HISTORY Taşınması:

%windir%\system32\inetsrv\appcmd set config -section:system.applicationhost/configHistory -path:E:\inetpub\history

TEMP\ASP COMPILED TEMPLATES Taşınması:

%windir%\system32\inetsrv\appcmd set config -section:system.webServer/asp -cache.disktemplateCacheDirectory:"E:\inetpub\temp\ASP Compiled Templates"

TEMP\IIS TEMPORARY COMPRESSED FILES Taşınması:

%windir%\system32\inetsrv\appcmd set config -section:system.webServer/httpCompression -directory:"E:\inetpub\temp\IIS Temporary Compressed Files"

WWWROOT Taşınması:

%windir%\system32\inetsrv\appcmd set vdir "Default Web Site/" -physicalPath:E:\inetpub\wwwroot

CUSTERR Taşınması:

%windir%\system32\inetsrv\appcmd set config -section:httpErrors /[statusCode='401'].prefixLanguageFilePath:E:\inetpub\custerr

%windir%\system32\inetsrv\appcmd set config -section:httpErrors /[statusCode='403'].prefixLanguageFilePath:E:\inetpub\custerr

%windir%\system32\inetsrv\appcmd set config -section:httpErrors /[statusCode='405'].prefixLanguageFilePath:E:\inetpub\custerr

%windir%\system32\inetsrv\appcmd set config -section:httpErrors /[statusCode='404'].prefixLanguageFilePath:E:\inetpub\custerr

%windir%\system32\inetsrv\appcmd set config -section:httpErrors /[statusCode='406'].prefixLanguageFilePath:E:\inetpub\custerr

%windir%\system32\inetsrv\appcmd set config -section:httpErrors /[statusCode='412'].prefixLanguageFilePath:E:\inetpub\custerr

%windir%\system32\inetsrv\appcmd set config -section:httpErrors /[statusCode='500'].prefixLanguageFilePath:E:\inetpub\custerr

%windir%\system32\inetsrv\appcmd set config -section:httpErrors /[statusCode='501'].prefixLanguageFilePath:E:\inetpub\custerr

%windir%\system32\inetsrv\appcmd set config -section:httpErrors /[statusCode='502'].prefixLanguageFilePath:E:\inetpub\custerr

WWWROOT ve FTPROOT Taşınması:

reg add HKLM\Software\Microsoft\inetstp /v PathWWWRoot /t REG_SZ /d E:\inetpub\wwwroot

reg add HKLM\Software\Microsoft\inetstp /v PathFTPRoot /t REG_SZ /d E:\inetpub\ftproot

INETPUB İçeriğinin Kopyalanması: Yukarıdaki adımlarla yapılandırma dosyalarının yeni konumları belirlendikten sonra tüm INETPUB içeriğini Windows dizininin bulunduğu sistem sürücüsünden farklı bir disk sürücüsüne tüm klasör ve dosyaların izinleri ve boş dizinleri ile beraber taşıma yapacağız. Bunun içinde XCOPY aracını ya da ROBOCOPY aracını kullanabilirsiniz. Aşağıda örnek olarak XCOPY aracının parametreleri ile taşıma yapacak komutumuzu görüyorsunuz:

XCOPY C:\Inetpub E:\Inetpub /E /O /I

/E : Boş dizinleri de kopyalar.

/O : Dosya ve dizinleri üzerlerinde tanımlı izinlerle birlikte kopyalar.

Böylece tüm Inetpub içeriğini E: sürücüsüne taşımış olduk.

ÖZETLE :

Microsoft IIS sunucular üzerinden web tabanlı mimaride hizmet veren servisler ve uygulamalar yaygınlaştıkça güvenlik önlemleri de daha fazla önem kazanmaktadır. Bu makalemizde IIS sunucular üzerinde en iyi güvenlik yapılandırma önerilerinden bir tanesi olan Inetpub dizininin sistem sürücüsü yerine farklı bir sürücüye taşınmasını ele detaylı adımlarla ele aldık.Yeni bir makalede görüşmek dileğiyle, hoşçakalın.

Mesut ALADAĞ.
Microsoft MVP, MCT, P-TSP
www.cozumpark.com | www.mesutaladag.com