Bu makalemizde Microsoft’un ücretsiz olarak sunduğu Microsoft Deployment Tool ile fiziksel server ortamlarına çoklu olarak Windows Server işletim sisteminin nasıl dağıtımını yapıp hizmete hazır hale getireceğimiz anlatılacaktır.

Öncelikle neden işletim sistemi dağıtımı yapılır bundan kısaca bahsedeyim. Bir iki işletim sistemi kuracaksanız CD’yi takıp işletim sistemi kurduktan sonra Windows Update’ini yapıp hizmete hazır hale getirmeniz mantıklı olabilir. Fakat Cloud’a doğru giden gelişen dünya teknolojisinde eğer aşağıdaki gibi ihtiyaçlarınız varsa hazır imajdan dönme size hem zaman hem de maliyet avantajı sağlayacaktır. İşletim sisteminin dağıtımının en çok kullanıldığı yerler;

·         Ondan fazla Windows client işletim sistemlerinizi tek seferde, hiçbir soru sormadan (Katılımsız / Unattended / Otomatik) , ücretsiz ve sorunsuz olarak son sürüm Windows client işletim sistemine geçirme.

·         Belli bir amaç için kurulumu hazırlanmış (önceden gerekli tüm program ve bileşenleri yüklenip, full Windows Update’i yapılıp çalışır duruma getirilen) bir bilgisayarın referans imajını alarak çoğalmak.

·         Üzerinde data tutmayan kritik bir sistemde bir sorun olduğunda veya sorunu çözmenin uzun süreceği durumlarda hızlı aksiyon alma adına önceden hazırlamış olduğunuz imajdan dönülmesi

·         Yatay büyümenin gerektirdiği durumlarda (RDS, IIS, HyperV) hızlı aksiyon alma adına imajdan dönerek performans daralması problemlerinin çözümünde.

Data Center yönetimi eskiden çok külfetli ve zaman alan süreçlerdi. Şimdi ise Mimarinin gelişmesiyle birlikte az elaman ile çok iş yapılması sağlanmıştır. Data Center bakım maliyetleri arasında yer alan adam/gün iş kalemini azaltan süreçlerin başında işletim sistemi imaj dağıtımıdır. Bu sürecin nasıl yönetildiğini şimdi birlikte inceleyelim.

Server Deployment konusunu anlatımına başlamadan önce bilinmesi gereken bazı terminolojileri hızlıca değinelim.

UDP (User Datagram Protocol); gönderilen paketin ulaşıp ulaşmadığının kontrolünün yapılmadığı, büyük veri paketlerinin daha rahat gönderilmesinin yapıldığı veri iletişim alt protokolüdür. Gönderilen paketin doğru ulaşıp ulaşmadığına bakmadığından daha hızlı iletişim mümkündür.

TFTP (Trivial File Transfer Protocol); 1980’li yıllarda geliştirilen UDP protokolü üzerinden çalışan güvensiz ve hızlı dosya transfer protokolüdür. Basit yapısı ve az kaynak (CPU, RAM) kullanımından dolayı kullanılmaya devam etmektedir. Tek dezavantajı aynı anda sadece tek bir paketin dağıtımını yapmaktadır.

PXE (Preboot EXecution Environment); bilgisayarın disk ve işletim sistemine ihtiyaç duymadan network kart desteğiyle BootP protokolü üzerinden DHCP sunucudan yayın edilen TFTP server’a bağlanıp gerekli ön yükleme dosyalarını alarak açılmasını sağlayan bir arabirim ortamıdır.

Sysprep; Windows kurulumu yapılan makinenin Hostname, SID, Driver Cache ve Lisans verilerini resetleyen arabirim programdır. Bu uygulamanın kullanım amacı; aynı özelliklere sahip bilgisayarların imajını alıp hızlı bir şekilde dağıtımını yapmak için kullanılmaktadır. Kullanımıda şu şekildedir: Öncelikle bilgisayarlardan birisine normal kurulum yapılır. Ayrıca isteğe bağlı olarak diğer bilgisayarlarda kurulu olmasını istediğiniz uygulamalarda bu bilgisayara kurulur. Ardından sysprep (C:\Windows\System32\Sysprep) programı çalıştırılır. Bu program çalıştırıldığı kaynak bilgisayardaki bilgisayara özel bilgileri silerek bilgisayarı restart eder. Bu aşamadan sonra üçüncü parti bir image programı (ImageX, Norton Ghost, Acronis gibi) aracılığıyla hard diskin imajı diğer bir hard diske alınır. Daha sonra bu hard disk hedef bilgisayara takılır ve bilgisayar açıldığında kullanıcının karşısına mini bir setup programı çıkar ve bilgisayara özel bilgilerin girilmesi sağlanır. İstenirse bu bilgisayara özel bilgiler setup manager programı kullanılarak oluşturulan bir inf (sysprep.inf) dosyasından da alınarak otomatik hale getirilebilir.

Not: Aynı bilgisayarı en fazla 3 defa sysprep yapabilirsiniz. Değişik yöntemlerle sysprep işleminde sayacın artmaması sağlanabiliyor fakat bu yapılan işlem sonrasında ürünün tamamen unsupported olmasına neden olmaktadır. Bilgisayarınızın kaç defa sysprep yapıldığını görmek için “RunAs Administrator” ile açacağınız komut satırına “slmgr.vbs /dlv” yazıp enterlayarak görebilirsiniz. Aşağıda örnek ekran görüntüsünü verdiğim makine sadece 1 kere sysprep yapılmış olduğunu görüyorsunuz

WAIK; XP’nin katılımsız kurulumu için kullandığımız “unattended setup”la oluşturduğumuz winnt.sif isimli konfigürasyon dosya yapısı Vista için gelen WAIK aracıyla yerini “autounattend.xml” aldı. Bu yeni XML formatlı yanıt dosyası ile çok daha fazla şeyi özelleştirebiliyoruz. Ayrıca GUI arayüzü sayesinde daha anlaşılabilir gelişmiş seçenekler sunduğundan daha hızlı ve bilinçli autounattend.xml dosyası oluşturmanızı sağlamaktadır. Bu özelleştirdiğimiz dosyayı sysprep yaparken veya imajdan dönerken kullanabiliriz. Ayrıca SP1’li Win7 ve 2008r2 dağıtımı yapacaksanız WAIK 3.0’ın SUPPLEMENT update’ini kullanmanız gerekmektedir.

WinPE (Windows Pre Environment); WAIK ile gelen ve komut satırından bootable bir iso oluşturmamızı sağlayan bir araçtır. WinPE, Windows Vista/2008 sonrası işletim sistemlerinin en basit halidir desek, herhalde yanlış olmaz. WinPE ile işletim sistemi olmayan bir bilgisayar boot edilerek belirli lokasyonlardan imaj yükleyebilir. Çeşitli exe uzantılı araçların Winpe ile oluşturulmuş imaj içerisine entegre edilerek işletim sistemi olmadan kullanılabilir yani gelişmiş ThinPC yapılabilir.

WIM (Windows Imaging Format); Microsoft’a ait bir dosya uzantısıdır. Windows / DVD’si içerisindeki yükleme dosyası da .wim uzantılıdır. imagex ile aldığımız imaj’lar .wim uzantılıdır. Ayrıca WDS (Windows Deploymet Server) üzerinden network’e dağıtacağımız işletim sistemi imaj’larınında .wim uzantılı olması gerekir. Bu yüzden imageX.exe bizim için önemli bir araç olmaktadır.

İmagex Tool; Vista işletim sistemi ile birlikte tanıştığımız bir araçtır. Kendisi bir imaj alma ve geri yükleme aracı olarak kullanılmaktadır. Ghost, Acronis gibi bildiğimiz imaj alma programlarından farklı olarak WIM formatında imajlar alıp bunları geri yükleyebiliyor. Alınan imajlar sektör tabanlı olmadığından daha sorunsuz dönüşler yapılması hedeflenmiştir. Böylelikle 80 Gb’lik diskten alınan 4 Gb’lik imajı 40 Gb’lik diske dönebilirsiniz. Dönüşlerde mini Windows setup çalıştırmaktadır. Bu işlem size DISM’i kullanma imkanı sağlayacaktır.

DISM (Deployment Image Servicing and Management); Windows 7 ile beraber gelen ve imaj yönetim uygulamalarından biridir. Bu tool ile wim imaj dosyasını bilgisayarımıza mount (disk olarak bağlayarak) ederek role, feature veya Windows update pack kurabiliriz. Böylelikle imaj yedeği aldığınız bir sistemi güncellemek için başka bir makinede açmak zorunda kalmayacaksınız.

WDS (Windows Deployment Services); Windows Server 2003’te kullanılan Remote Installation Service’in Windows Server 2008 gelişmiş versiyonudur. Network tabanlı wim formatlı Windows işletim sistemi kurulumlarda kullanılmaktadır. 2008r2 ile birlikte Çoklu deployment’ı desteği ile aynı anda birden fazla katılımsız kurulumu başlatıp çok kısa sürede bitirebilirsiniz. MDT ile birlikte kullanıldığında bizim için güvenli PXEBoot ve TFTP sunuculuğu yapacaktır.

MDT (Microsoft Deployment Toolkit); Windows XP’nin çoklu ve katılımsız dağıtımı için 2003 yılında Microsoft içindeki bazı Premier Field Engineering (PEF)’lerin özel gayretleriyle oluşturdukları script tabanlı hazırlanmış internal tool olan sonradan ise sadece SA (Microsoft Software Assurance) müşterilerine sunulan Automated Deployment Services (ADS)’in gelişmiş versiyonudur. Ürün SCCM ürününü birebir takip etmektedir. SCCM üzerindeki her güncellemede MDT’de gücellenmektedir. Bu uyumluluğun nedenine daha sonradan değineceğimizde burada kısaca kesiyorum.

MDT 2012 ile Server Deployment işlemi için gerekenler:

DHCP Server :

Network üzerinden kurulum yapılabilmesi için bilgisayarın açıldığında PXE client servisinin ortamdaki DHCP servisinden ip adresi BootP servis bilgilerini alması gerekiyor. Bu nedenle öncelikle eğer Windows domain ortamında Windows DHCP servisi kullanılacaksa DHCP server’a DC tarafından delegasyonu (ip dağıtma yetkisi) yapılmış olması gerekmektedir. Daha sonrasında ise işletim sistemi dağıtımı yapılacak ip adresi scope’unda ek olarak aşağıdaki options’ların girilmesi gerekmektedir.

#060 = Client Identifier olarak adlandırılan bu alana "PXEClient" olarak girin. (Bu alanı WDS kullanacaklar girmeyedebilir. Sorunsuz çalışıyor )

#066 = Boot Server Host Name (Biz WDS kullanacağımızda WDS sunucusunun ip adresi girilmeli)

#067 = BootFile Name (default olarak boot\x64\wdsnbp.com yazmanız yeterli, bu dosya hem 32 hem de 64 bit bootP file içermektedir.)

Not: Eğer DHCP ile dağıtım yapılacak makineler arasında firewall varsa UDP 67 portuna izin verilmeli.

DNS:

DHCP servisi tarafından verilen bilgilere ulaşılması için çalışır durumda DNS servisine ihtiyaç bulunmaktadır.

AD :

Eğer dağıtım yapılacak sunucular domain’e alınacaksa ortamda erişilebilir Domain Controler olması gerekmektedir. Bunun dışında güvenlik gerekçesiyle imajların paylaşıldığı alanlara verilecek yetkilendirmelerde domain hesapları kullanılabilir. Biz çalışmamızı domain ortamında kullanacağız.

WDS:

2008r2 ile birlikte ; daha geniş driver desteği, driver ekleme, EFI, VHD disk desteği, Çoklu kurulum desteği, IPv6 ve AD olmaksızın dağıtım yapılabilme imkanı gelmiştir. Biz server dağıtımı yapacağımızdan 2008r2 üzerinde WDS’i kullanacağız. Bildiğiniz üzere deployment sürecinde iki önemli etken bulunmaktadır. Bunlar; network ve disk performansıdır. Bu yüzden imajınızı storage üzerinden yaymanız size artı sağlayacaktır. Fakat imajın dağıtımını sunucu üzerinden yapacaksanız Diskte I/O performans sorunu yaşamamak için ve en önemlisi yeni kurulum yapacaksanız diski ikiye bölüp kurulum yapmanız. Diskin bir bölümünde işletim sistemi diğer bölümde ise dağıtım imajlarının bulunmasıdır. Biz bu çalışmamızda sunucu kaynaklarını kullanacağımızdan dağıtım imajlarını da sunucu üzerinde barındıracağım. WDS kurulumu Daha önce portalımız yazarlarından Belgin Taştan’ın yazdığı “Microsoft Deployment Toolkit (MDT) 2010 Bölüm 1 Organizasyon Gereksinimleri“ isimli makalesinde anlatıldığı için burada tekrarlamayacağım.

Not: WDS ile dağıtım yapılacak makineler arasında firewall açık ise UDP 4011 portunun açılması gerekmektedir. Ayrıca Eğer sunucunuz 6 ve üstü core’a sahip CPU’lu ise KB2121690 numaralı hotfix’ini yükleyiniz.

WAIK:

MDT sizin yaptığınız işlemleri arka planda WAIK’e yaptırdığından projemiz için önemli bir yazılım olmaktadır. Ayrıca ileride değineceğimiz bazı bileşenler için aktif olarak kullanılacaktır. Kurulum ve yapılandırma yönüyle bir değişiklik olmadığından Belgin Taştan’ın yazdığı “Microsoft Deployment Toolkit (MDT) 2010 Bölüm 1 Organizasyon Gereksinimleri“ isimli makalesinde anlatıldığı için burada nasıl kurulacağını tekrarlamayacağım. Sadece biz Sp1’e sahip 2008r2 dağıtımı yapacağımızdan şuan için en güncel versiyon olan Waik3.0 ü indirip kurulumu bittikten sonra “waik_supplement_en-us” isimli dosyayı indirip uygun bir yere açın. Sonra [ xcopy E:\waik_supplement_en-us "C:\Program Files\Windows AIK\Tools\PETools" /ERDY ] komutunu kullanarak güncel WinPE imajlarını WAIK altına kopyalamış oluyoruz. Kopyalama bittiğinde WAIK’i repair ederek WinPE’yi 3.1’e yükseltmiş olursunuz. WinPE 3.1 bize daha fazla donanım desteği sağladığı gibi dağıtımını yapacağımız Sp1 içerikli Win7 ve 2008r2 desteğini sağlamaktadır.

Not: kuruluma başlamadan önce .Net 3,5 ve 4’ü kurmayı unutmayın.

MDT:

Aslında MDT 2012, kurulum ve yapılandırma olarak bakındığında 2010 versiyonundan bir farkı görülmemektedir. Peki neden 2012? Bu soruya portalımız yazarlarından Belgin Taştan’ın “MDT 2012 Beta 1 ve MAP 6.0 Beta Yayınlandı” başlıklı yazdığı makalede anlatıldığı için ben tekrarlamayacağım. Fakat bizimle alakalı bir özellik var ki o da sunucu dağıtımında çok baş ağrıtan gelişen donanım yapısı içerisinde Unified Extensible Firmware Interface (UEFI) arabirimi tanıyıp GPT partition table tipi üzerine yazabiliyor olması. Bu sayede 2011 ve sonrası tüm sunucu donanımlarında, blade sistemlerine artık sorunsuz ve SSCM’e ihtiyaç kalmadan daha az uğraşla ZeroTouch kurulum yapılabilecek olmasıdır.

Gerekli kurulumlar tamamlandıktan sonra simdi çalışmamıza başlayabiliriz. Öncelikle bu çalışmamızın kapsamını sizlerle paylaşayım. Burada yapacağımız çalışma WDS&MDT2012 ikilisi ile;

1.       Tüm ayarları yapılmış, gerekli uygulama ve güncellemeleri yüklenmiş makinenin önce sysprep yapılmadan imajını almak. Sonra aldığımız imajı bir başka fiziksel sunucuya kurmak. Hemen akıllara “madem master imaj alıyoruz neden sysprep yapmadık?” Sorusu gelebilir. Buradaki amacımız Sysprep kısmında bahsettiğim lisans sayacına takılmadan istediğimiz gibi güncellenecek master imaj sunucusunu muhafaza etmek. İlk başta süreci uzatmış gibi görünebiliriz fakat bu her üç seferde bir sıfır master imaj sunucusu kurma zahmetinden bizi kurtaracaktır.

2.       İmajdan Kurulumu yapılan makinenin sysprep yapılıp imajını almak

3.       Sysprep’li master imajımızı kullanarak katılımsız çoklu sunucu kurulumunu gerçekleştirmek.

MDT’nin Yapılandırılması

Gerekli ön hazırlıkları bitirdiğimize göre şimdi MDT’nin yapılandırılmasına geldi.

1.       Biz Sp1’li 2008r2 sunucusunun dağıtımını yapacağımız için öncelikle “Operating Systems” tabına daha önceden bir klasöre açtığımız (ben 7zip programını kullanarak bu işlemi gerçekleştirdim) iso dosyası içerisindeki işletim sistemine ait wim imajını import edelim. Bu işlem için mouse ile “Operating Systems” sağ ile tıklayıp “import” deyiniz. İmport işlemi sonrasında kullanmayacağınız OS çeşitlerini silelim.

Not: Dağıtım ve imaj alacağınız işletim sistemi dili ne ise oluşturacağınız Task’ler de o OS CD imajını kullanın. Hatta mümkünse WAIK’de aynı dilde olsun. Değişik dillelere ait bileşenleri veya değişik OS’leri bağladığınızda boot hataları alınmaktadır. (Tecrübe ile sabittir)

2.       Dağıtım yapılacak OS import’u bittikten sonra yukarıda belirttiğimiz amacımıza uygun “Task Sequences” tanımlarını yapalım. Bu kısımda amacımız sadece genel hatlarıyla TASK’leri oluşturmak. Makalemizin ilerleyen kısımlarında bazı TASK’lerin yapılandırmasına geri dönülecektir.

Bu işlem için “Task Sequences” üzerinde sağ tıklayarak “New Task Sequences” deyin.

a.       Karşınıza gelecek ekranda “Task Sequence ID” tabına ilgili işlem numarasını girin. Daha sonradan bu ID numaralarını kullanarak kendimize katılımsız kurulumlar gerçekleştireceğiz.

                                                   i.      Kapsamımızda belirttiğimiz ilk Task’imiz “sysprepsiz imaj almak” olduğundan bu işlemi gerçekleştirmek için “Sysprep and Capture” i secin. (Sysprep yazıyor ama biz ilerleyen adımlarda Sysprep’i disable ederek Sysprep yapmasını engelleyeceğiz.)

                                                 ii.      Opeting System altına daha önceden eklemiş olduğumuz işletim sistemi dosyasını gösterip sorduğu sorulara uygun cevap vererek işlemi tamamlıyoruz.

                                                iii.      Yaptığımız “task sequence”’de imaj alırken sysprep yapma dememiz için tanımladığımız task üzerinde sağ ile tıklayıp Propertise’i seçin.

                                               iv.      Gelen ekranda “Task Sequence” tabı içerisindeki “Execute Sysprep”’lar bulunup tıklayın. Yan tarafta açılan alanda Options tabına girip “Disable this step” alanı işaretlenir.

b.      Kapsamımızda belirttiğimiz ikinci adımımız olan “master imaj sunucunun sysprep yapmadan alınan disk imajının dağıtımı” işlemi için “Standart server task squence” seçilir ve işlem tamamlanır. Master Imaj sunucumuzun imajı alındıktan sonra TASK’ımızı yapılandırmaya devem edeceğiz. Bu yüzden şimdilik genel olarak oluşturup ilerleyelim.

c.       Kapsamımızda belirttiğimiz üçüncü adımımız olan “sysprepsiz imajdan döndüğümüz makineyi sysprep yapıp imajını almak” için bir değişiklik yapılmadan “Sysprep ve Capture” seçeneği seçilip işleme konulur

d.      Son task için “Server Deploy” isminde “Standart Server Task Sequence” seçilip işlem genel olarak tamamlanır. Sysprepli imajımız alındıktan sonra TASK’ımızı yapılandırmak için geri geleceğiz.

3.       Eğer işlem yapılacak sunucuda WinPE’nin tanımadığı driver varsa “Out-of-box Drivers” altına ilgili donanım sürücülerinin inf dosyalarının bulunduğu dizini göstererek import işlemini yapınız.

4.       Şimdi sıra full unattended olarak deployment yapabilmek için MDT’nin yapılandırılmasına geldi. MDT Deployment Workbench yapılandırılmasına geçmeden önce dağıtımını yapacağımız ortama göre MDT’nin şekillendirilmesi gerekmektedir. Bu işlem için “MDT Deployment Share” üzerinde sağ tıklanarak Properties’i tıklayın.

Amacımız Sp1’li 2008r2 Server dağıtımı olduğundan General sekmesi altında x86 platformuna ait işareti kaldıralım ki her update ve yenilemede kullanmayacağımız x86 dosyalarını oluşturmak için bizi bekletmesin (sürecin ne kadar uzun sürdüğünü görünce hak vereceksiniz). MDT’yi amacımıza göre ne kadar ince yapılandırırsak o kadar hızlı ve sorunsuz olur.

Not: Eğer Siz aynı WDS&MDT ikilisine ait sunucu üzerinde client dağıtımı da yapacaksanız bu ayarı YAPMAYIN.

Deployment sürecinde oluşacak hataları incelemek için WDS sunucusu üzerinde bir klasör açarak içerisine SCCM’in Trace64 isimli log okuma programını ekleyin. Sonra bu eklediğiniz klasörün yolunu WindowsPE tıklayıp Platform olarak x64’ü seçtikten sonra “Extra directory to add” kısmına klasör yolunu yazın. İlerleyen bölümde Trace64 ile nasıl hata ayıklaması yapılacağı anlatılacağından burada bahsetmeyeceğim.

MDT Management’i amacımıza uygun olarak şekillendirdikten sonra unattended deployment için kurallarımızı oluşturmaya başlayalım. MDT’de Deployment iki kısımdan oluşmaktadır. Birincisi WinPE ile açılan ön işletim sisteminin yüklendiği aşamadır ki biz bu aşamada sorulan soruları üzerinde çalıştığı sunucuya göre cevaplandırıp hiç bize sormadan deployment aşamasına gelmesini sağlayacağız. Diğer kısım ise WinPE’nin çalışması sonrasında WMI ile envanter bilgisi alınan sunucunun mac adresine göre bizim belirleyeceğimiz şekilde ilgili MDT Task’ini çalıştırmasıdır.

İlk kısım olan WinPE ile başlayan sistemin bize sormadan üzerinde çalıştığı sunucunun mac adresine göre deploy aşamasına gelebilmesi için aşağıda örnek olarak oluşturduğumuz ve sizin isteklerinize göre daha da geliştirebileceğiniz tanımlamaları “MDT Deployment Share Properties” içerisindeki Rules tabına girip “Edit BootStrap.ini” butonuna tıklayarak girebileceğiniz gibi “\deploymentshare$\Control” klasörü altından da BootStrap.ini dosyasına ulaşıp yazabilirsiniz. Unutulmaması gereken nokta klasör üzerinden ulaşıyorsanız sadece NotePad programını kullanın ki karakter yapısı değişmesin.

Ek Bilgilendirme ;

[ ile başlayıp ] ile biten kısım kuralın tipini belirtir

# ile başlayıp # ile biten kısım size özel tek satırlık açıklama alanı sağlar.

# ile başlayan komutlar çalıştırılmaz

Aşağıda göreceğiniz işlemlerin olabilmesi için bir domain kullanıcısına ihtiyacımız bulunmaktadır. Kullanıcının ismi ve şifresinin sunucu üzerinde BootStrap ve CustomSettings dosyalarında yer alacağından güvenlik gerekçesiyle kullanıcının RDP erişiminin kapatılıp sadece WDS sunucusunda dosya erişimi ve AD üzerinde obje oluşturma yetkisi verilmesi gerekmektedir.

Örnek BootStap.ini Dosyası:

[Settings]

Priority=Default

[Default]

SkipBDDWelcome=YES

SkipLocaleSelection=YES

UserLocale=tr-TR

KeyboardLocalePE=041f:0000041f

SystemLocale=tr-TR

UILanguage=en-US

#oluşturmuş olduğumuz task’leri ve dosyaları download edebilmesi için share adresinin FQDN bilgisini erişecek hesap bilgilerini giriyoruz#

DeployRoot=\\sunucunun_full_domain_adresi\DeploymentShare$

UserID=domain_user_name

UserDomain=domain

UserPassword=domain_user_şifresi

WinPE ile sorgusuz başlayan sistemimizin hangi sunucunun oluşturduğumuz TASK’e göre işlem yapacağını belirlemek için Rules kısmına veya “\deploymentshare$\Control” klasörü altındaki CustomSettings.ini dosyasına aşağıda örnek yazmış olduğum kuralları inceleyip kendi sistemine göre geliştirerek yazınız.

Eğer birden fazla network interface’i varsa önerim hepsini yazmanız. Bazen yazılan mac adresini alamadığını gördüm. Bu sorunu gidermek için en az iki mac adresini girerek kural oluşturun.

Örnek CustomSettings.ini Dosyası:

[Settings]

Priority=MACAddress, Default

# Priority ile işlem yapılacak sistemde neye göre önceliklendirme yapılacağı belirtiliyor#

#Biz burada önceliği mac adresine göre belirledik. Mac adresi tutmayan sunucular default ayarlarla açılacak#

Properties=MyCustomProperty

# MyCustomProperty ile benim belirlediğim ayarlara göre kurulum yapılacağı bildiriliyor#

[Default]

#Tüm sunucular için genel ayarları buraya girilir#

SkipLocaleSelection=Yes

#WinPE ile başlayan her soru başlığını ilgili skip parametresi ile geçilmesini sağlıyoruz#

#Eğer verdiğimiz skip parametresi sonrasında uygun cevapları vermezsek anlaşılamayan değişik hatalara neden olabilir. Bu yüzden Skip ile göstermediğiniz kısmın cevaplarını veriyor olmanız gerekmektedir.# SkipTimeZone=YES

KeyboardLocale=tr-TR

TimeZone=130

TimeZoneName=GTB Standard Time

SkipAdminPassword=YES

AdminPassword=$ifreGirin01

#Eğer referans olarak oluşturacağınız imajın lokal Administrator kullanıcısının şifresini her seferinde kendiniz belirlemek istiyorsanız AdminPassword’u yazmayın

SkipSummary=YES

SkipFinalSummary=YES

#arada ve iş sonunda rapor göstermesini istiyorsanız SkipSummary ve SkipFinalSummary yazmayın#

SkipProductKey=YES

SkipBitLocker=YES

#Eğer BitLocker i enable etmek istiyorsanız SkipBitLocker yazmayın#

EventService=http://sunucu_ismi.domain.name:9800

#REFERANS ALINAN SUNUCU#

#Sysprepsiz alınacak imaj#

[00:10:18:AB:01:18]

[00:10:18:AB:01:1A]

DoCapture=YES

#imaj alma komutu#

SkipTaskSequence=YES

TaskSequenceID=1

#Bu mac adresine sahip makinenin çalıştıracağı TASK buradan belirlenir#

SkipComputerBackup=YES

ComputerBackupLocation=\\sunucu_ismi.domain.name\deploymentshare$\captures

BackupFile=masterimaj.wim

#Alınacak imajın nereye kopyalanacağını bildirilir#

SkipComputerName=YES

ComputerName=masterimaj

SkipDomainMembership=YES

JoinWorkgroup=COZUMPARK

#Master imajımız her an güncellenebilir olcağından domain e almayacağız#

#SYSPREPLI RDS SUNUCUSU#

#bu sunucuya hem imaj basılıp hemde imaj alınacağından karışıklığa neden olmamak adına tam otomatik kod yazılmamıştır#

[00:10:18:9F:BE:A4]

[00:10:18:9F:BE:A6]

SkipComputerName=YES

ComputerName=RDSSysprep

SkipDomainMembership=YES

JoinWorkgroup=TFKBRDS

#SUNUCU DAĞITIMI 01#

[00:10:18:AB:05:F8]

[00:10:18:AB:05:FA]

SkipTaskSequence=YES

TaskSequenceID=4

SkipComputerName=YES

ComputerName=RDS01

SkipDomainMembership=YES

JoinDomain=COZUMPARK

DomainAdmin=domain_user_name

DomainAdminDomain=domain_ismi

DomainAdminPassword=$ifre

#her bir kullanıcı default’ta 3 makineyi domain’e alabilir. Yazılacak şifre cleartext olacağından önerim RDP yetkisi olmayan ve AD üzerinde obje oluşturma yetkisine sahip basit bir System hesabı oluşturmanız#

MachineObjectOU=OU=FCS,OU=ComputeR,DC=Cozumpark,DC=com

# MachineObjectOU ile domain e aldığını makinenin hangi OU altında oluşturulacağını belirtirsiniz. BU OU üzerinde service user için yetki oluşturmayı unutmayın#

# MachineObjectOU da yazacağınız OU yolunda boşluk bırakmadan yazılacaktır#

SkipComputerBackup=YES

SkipCapture=YES

Böylelikle değişik sunucular için değişik task’ler çalıştırıp süreci katılımsız olarak yönetmemizi sağlayacak kuralları girdikten sonra şimdi ayarların uygulanabilmesi için “MDT Deployment Share” üzerinde sağ tıklanarak “Update Deployment Share” diyeceğiz. Her yaptığınız değişiklikten sonra bu işlem tekrarlanması gerekmektedir.

MDT yapılandırmasından sonra eğer ilk defa update işlemini yapacaksanız veya WinPE’nin boot dosyası üzerinde bir değişiklik yaptıysanız “Completely regenerate the boot images” kısmını işaretleyerek ilerleyin diğer şartlarda ise sadece “Optimize the boot image updating process” i işaretleyerek devam ediniz. Artık ufak bir kahve molası J verebiliriz.

MDT ile oluşturduğumuz WinPE’nin WDS ile dağıtımı için WDS yönetim arabirimini açınız. “Boot Images” sekmesine sağ ile tıklayıp “DeploymentShare\Boot” altındaki LiteTouchPE_x64.wim’i ekleyiniz. WDS birden fazla boot dosyasının PXE server’lığını yapabiliyor. Fakat böyle bir durumda PXEClient’ın önüne gelen seçeneklerden birisini seçmesini bekleyecektir/belirleyeceksiniz. Böyle bir ortamda otomatik kurulum gerçekleştirilmesi zorlanacağından yapmamamız daha sağlıklı olacaktır.

İlerleyen zamanda MDT’nin bootstap.ini dosyası üzerinden yaptığınız her değişiklik için öncelikle MDT’yi “Completely regenerate the boot images” olarak update edip sonra WDS boot dosyasını Replace Image seçip üzerine yazmanız gerekmektedir.

Kapsamımız dahilinde belirlediğimiz 3 iş adımlarımızı şimdi sırayla oluşturmaya başlayalım

1)      Sysprepsiz Master Sunucunun Imajını almak:

Boot imajımızı oluşturup açılışa hazır hale getirdikten sonra öncelikle master imaj olarak oluşturduğumuz makinenin üzerinden \\sunucu.domain.com\DeploymentShare$\Scripts\LiteTouch.vbs dosyasını çalıştırın. Eğer oluşturmuş olduğunuz kodda hata yoksa gerekli işlemleri yapıp makinenin imajını almak için restart yapacaktır. Bu aşamada öncelikle mevcut diskin içerisinde geçici bir bölüm oluşturarak restart sonrasında kullanacağı dosyaları buraya kaydetmektedir. Daha sonrasında restart sonrası yeni oluşturduğu bu geçici disk bölümünü boot sector’e işlemektedir. Imaj alma işlemi bittiğinde bu oluşturmuş olduğu geçici dizini silip boot sector’ü düzeltecektir.

Not: Tüm imaj alma işlemleri işletim sistemi açıkken sunucu üzerinde paylaşılan LiteTouch.vbs dosyasının çalıştırılmasıyla olmaktadır.

Eğer sunucu açılırken aşağıdaki gibi Status: 0x000000f hatası verip açılmazsa telaşlanmayın. Sebebi oluşturmuş olduğu geçici pattition’ı boot sektor’den açamaması. (UEFI ve GPT’li her sistemde bu sorunu yaşadım) Bu soruna ilişkin internette çok değişik öneriler bulunmakta fakat sunucumuz master imaj olarak kullanacağımızdan bizim için büyük önem arz eden sunucuda çözüm olarak biz fazla değişiklik yapmadan F12 ile PXEBoot olarak sistemi açıp sürecin kaldığı yerden başlamasını sağlayın.

2)      Sysprepli Master Imajın Oluşturulması:

Captures klasörü altına Sysprepsiz imajı alınan master sunucumuzun wim dosyasını “Deployment Workbench” altındaki “Operationg System” altına “Custom image file” seçeneğini seçerek import edelim.

Dosyanın yerini gösterirken move seçeneğini aktif edersek alınan imajı “DeploymentShare\Operating Systems” altına taşıyarak yerden tasarruf etmemizi sağlayacaktır.

Almış olduğumuz imaj dosyasına her hangi bir işleme tabi tutulmayacağı için “Setup and Sysprep files are not needed” seçeneğini seçip işlemi tamamlayın

Almış olduğumuz sysprepsiz master imaj dosyasının sysprep yapılacak sunucuya deploy edilmesi için daha önceden “Master imaj Deploy” isimli TASK’ı çift tıklayıp açılan ekranda “Task Sequence” tabında aşağıdaki ayarları yaparak yapılandırın.

a)      Bu task’imiz deployment olduğundan öncelikle “State Capture” ve “State Restore” gruplarını tıkladıktan sonra sağ tarafta açılan Option sekmesi altındaki “Disable this step” işaretlenerek çalışmasını engelleyin.

b)      “Format and Partition Disk” işaretlenerek hangi diskinize kurulum yapılacağı seçilir. Bu çalışmayı yürüttüğümüz sunucular Raid1 tek partition üzerinde GPT disk tipini kullandığından ben aşağıdaki gibi yapılandırdım. Sizde kendi yapınıza uygun olan seçenekleri buradan belirleyin

c)       Son olarak deploy edilecek imaj dosyasının “install Operating System” altında gösterilmesi gerekiyor. Bu işlem için “Operating System to install” altındaki Browser sekmesi tıklanarak seçiniz.

Aynı fiziksel sunucu hem imaj alınıp hem de imaj basılacağından full unattended işleme tabi tutulamayacağından bizim yazmış olduğumuz kodlarla en azından daha az soru sormasını sağlamış olduk.

Bu işlemler bittiğinde MDT ve WDS’i yukarıda tarif ettiğimiz şekilde update ederek Sysprepsiz master imajın basılacağı sunucuyu restart edip F12 ile PXEBoot ile açın. “Master imaj Deploy” isimli TASK’ı seçerek deployment sürecini başlatın.

Deploy işlemi tamamlanıp işletim sistemi açılıp gerekli kontrolleri yaptıktan sonra \\sunucu.domain.com\DeploymentShare$\Scripts\LiteTouch.vbs dosyasını çalıştırıp “Sysprep and Capture” isimli oluşturduğumuz TASK’ı çalıştırın. Uygun isim vererek Capture klasörü altına imaj alınmasını sağlayın.

3)      Server Deployment

Sysprepli imajı alma işlemi bittikten sonra öncelikle alınan imajın yukarıda ayrıntılı olarak bahsettiğimiz gibi “Operationg System” altına import edilir. Sonra daha önceden oluşturduğumuz “Sysprepli RDS Deploy” TASK çift tıklanarak açılıp aşağıdaki ayarlamalar yapılır.

a)      “State Capture Group” disable edilir

b)      Preinstall grubu altındaki “Format and Partition Disk” tıklanıp sol tarafda açılan menüde sunucunuzun disk tipine göre ayarlama yapılır.

c)       “İnject Drivers” disable edilir

d)      “Install Operating System” tıklanıp sysprepli aldığımız imaj dosyası eklenir

e)      “State Restore” grubu altında “Recover from Domain” ve “Restore group” hepsi disable edilir.

Çalışmamız tamamlanmış bulunmaktadır. Siz örnek MDT Rule’unu istediğiniz gibi genişletip arttırabilirsiniz. Başarılar. . .

HATA AYIKLAMA (Troubleshooting)

Tüm işlem bu kadar kolay ve sorunsuz görünse de Murphy Kanunlarını unutmamak lazım. Peki ya her şey beklediğimiz gibi gitmezse? Bu durumda imdadımıza yetişecek araç WinPE’nin içine yerleştirdiğimiz Trace64’dür.

Genelde hataların büyük bir bölümü kod veya TASK’ın düzgün yapılandırılmamasından kaynaklanmakta olsa da bunu ekranda görülen hata mesajından çıkarma imkanımız bazen olmayabilir. Hatalara yönelik nokta atışı tespitlerimizi WinPE ekranında F8 e basarak açacağımız komut satırı penceresini kullanarak yapacağız.

MDT loğlarının dışında hata ayıklama adımlarımız:

1)      Komut satırında root dizine düştükten sonra (cd\ komutu ile) trace64 yazıp enterlayın. Eğer daha önceden formatlanmış Windows diski üzerine MDT’yi çalıştırıyorsanız loğları c:\MININT\SMSOSD\OSDLOGS altında toplamaktadır. Formatlanmamış disk üzerine kurulum yapılıyorsa X:\MININT\SMSOSD\OSDLOGS altındaki loğları inceleyiniz.

Hatanızı anlayıp MDT üzerinde gerekli değişikliği yapıp update ettikten sonra hata ekranını kapatıp komut satırından wpeinit yazıp enterlayarak Wizard’ı yeniden başlatabilirsiniz.

2)      MDT Kuralımızı mac adresine göre yaptığımız için öncelikle “ipconfig /all” ile sunucu üzerindeki mac adresleri ile kuralımızı karşılaştırın

4)      WDS sunucusuna ping atın. Paket kaybı var mı?

5)      Disk tanımlarınızı kontrol edin bu işlem için diskpart yazıp enter ile diskpart yönetiminin içine girin. “list disk” ve “list volume” komutları ile disk durumunu görüntüleyin. Disk tipi ile TASK’de belirtiğiniz aynı mı? kontrol edin.

Emeği ve desteğinden dolayı Yağmur Şahin ve Ozan Köksal Hocalarıma’a sizler huzurunda teşekkürü borç bilirim.

Merhaba arkadaşlar bu makalemizde Pfsense update konusunu işleyeceğiz. Eğer daha önceden yapınız içerisine Pfsense nin önceki sürümlerini kurduysanız ve son sürüme geçmek gibi bir düşünceniz varsa bunu direk pfsense dashboard üzerinden gerçekleştirebilirsiniz. Benim senaryomda Pfsense 2.0 RELEASE (i386) yani bir önceki sürümü olan 32 bit lik sürümünü Pfsense 2.0.1 RELEASE (i386) sürümüne yükselteceğiz. Bundan önce muhakkak Pfsense yi backup lamanızı öneririm. Güncelleme sonrasında yaşanacak her hangi bir sıkıntıdan dolayı pfsense makinenizin çökmesi ihtimalini göz önünde bulundurmamız gerekmekte aksi taktirde yaşanacak bir sıkıntıda pfsense makinemizi tekrar konfigure etmemiz gerekebilir. Buda bizim için zaman kaybı olarak artı bir iş yükü çıkaracak ve yapımız içerisinde olan tüm clientlerimiz bu zaman zarfında internete çıkamayacaklar bu da tüm işlerin aksamasına neden olacaktır. İsterseniz Pfsense Update işlemine geçebiliriz.

Pfsense Update-01

Pfsense arayüzüne baktığımızda version bilgisisi olarak 2.0- Release (i386) versiyonunu kullandığımızı görebilirsiniz. Update işlemini başlatabilmek için Update available. Click here tıklamamız gerekmekte Update available bize yeni bir güncellemenin mevcut olduğunu belirtiyor. Click Here tıklayalım.

Pfsense Update-02

Yukarıda ki ekranı inceleyecek olursak -1 adımda Auto Update tabında bulunan Invoke Auto Upgrade yeni güncelleştirmeleri çağırıyoruz.

Pfsense Update-03

Altı kırmızı ile çizili olan Update cannot continue. You can disable this check on the updater settings tab. Yani güncellemelere devam edemediğini ve Updater settings tabına geçmemizi ve gerekli izinlerin verilmesini belirtmekte.

Pfsense Update-04

Yukarıda ki ekranda Updater Settings tabına geldik. Görüldüğü gibi her hangi bir yapılandırma mevcut değil. İsterseniz bir sonra ki şekle geçerek gerekli yapılandırmaları yapmaya başlayabiliriz.

Pfsense Update-05

Yukarıda ki şekle bakacak olursak -1 adımda Default Autı Update URLs bölümünde yükseltmek istediğimiz. Sürümü 64 bit mi yoksa 32 bit olarak mı yükselteceğimizi sormakta makalemizin başında belirttiğim gibi 32 bit bir pfsense kullandığım için yine Pfsense 32 bit yani pfsense i386 stable updates (kararlı güncelleme) seçiyorum. -2 adımda Firmware Auto Update URL (Firmware otomatik güncelleme) otomatik olarak seçilmekte -3 adıma bakacak olursak Unsigned images (imzasız imaj) eğer indirdiğimiz sürüm pfsense tarafından imzalı değilse yine de indirebileceğini belirtiyoruz. Son adımda ise Save diyerek yaptığımız yapılandırmayı kaydediyoruz.

Pfsense Update-06

Tekrar AutoUpdate tabına gelerek Invoke Auto Upgrade tıklıyoruz. Otomatik güncellemeleri çağırıyoruz. Yukarıda ki ekranda görüldüğü gibi update image sini indirmeye başlıyoruz. İndireceğimiz ve daha önceki versiyon bilgilerini de yine yukarıda ki ekranda görmemiz gerekmekte.

Pfsense Update-07

Artık yeni updates (güncellemeleri) indirmeye başladık. Yukarıda ki ekranda indirdiğimiz update paketinin boyutlarını görebiliriz.

Pfsense Update-08

Pfsense makineme tekrar dönüyorum. Görüldüğü gibi pfsense makinem benim yaptığım aksiyonlardan etkileniyor ve yaptığı işlemler hakkında ekranda bilgiler vermeye başlıyor. Upgrade işlemi bittikten sonra makinemizi yeniden başlatıyor. Bu işlemler pfsense tarafından otomatik olarak gerçekleşmekte.

Pfsense Update-09

Yukarıda ki ekranda The firewall will reboot once the operetion is completed. Upgrade işlemi gerçekleştikten sonra pfsense makinemizin yeniden başlayacağını belirtiyor.

Pfsense Update-10

Pfsense upgrade dosyalarını indirerek dosyaları çıkarttığını görebiliriz.

Pfsense Update-11

Görüldüğü gibi artık pfsense makinemizi Pfsense 2.0 RELEASE (i386) yani bir önceki sürümü olan 32 bit lik sürümünü Pfsense 2.0.1 RELEASE (i386) sürümüne yükseltik. Pfsense makinemiz artık başladı.

Pfsense Update-12

Pfsense dashboard (pfsense panele) döndüğümüzde artık pfsense versiyonumuzun 2.0.1-RELEASE (i386) sürümüne yükselttiğimizi görebiliriz. Bu da güncellemelerimizi başarılı bir şekilde tamamladığımızı göstermekte. Bu makalemde sizlere Pfsense Update işleminin ne kadar kolay olduğunu göstermeye çalıştım. Umarım sizler için faydalı olmuştur. Başka makalelerde tekrar görüşmek ümidiyle…

Windows 8 ile birlikte gelen ve beni çok etkileyen özelliklerinden birini sizinle bu makalemde enine boyuna paylaşmak istedim. Peki nedir bu özellik Hyper-V Client sanallaştırma ile ilgilenen arkadaşlarımız yakından bilirler ki Windows 7 üzerinde sanallaştırma yapılamıyordu. Hyper-V sadece tool olarak yüklememiz ve başka bir sunucuya bağlanmamız gerekiyordu. Ya da 3.party bir yazılıma ihtiyaç duyuyorduk. Şimdi ise böyle bir kaygımız yok. Windows 8 ile birlikte gelen Client Hyper-V ile test ortamlarımızı 3.party yazılımlara veya aktif çalışan fiziksel bir sunucuya ihtiyacımızı kaldırıyor. Sanallaştırma daha doğrusu test ortamlarımızı bir client OS ile gerçekleştirmemiz mümkün. Tabii ki client hyper-V ile bir takım senaryoları gerçekleştiremeyeceğiz. Ama Hyper-V rolünün kullandığı özelliklerin neredeyse tamamını Windows 8 Client Hyper-V ile birlikte kullanabileceğiz. Client Hyper-V daha çok yazılım geliştiricileri ve IT dünyasında bulunan BT uzmanlarını hedef alıyor. Düşünsenize yazılımcısınız. Ama yazdığınız programları farklı işletim sistemleri üzerinde test etmeniz gerekmekte. Bunun için ya 3.party bir yazılıma ihtiyaç duyacaksınız. Ya da 64 Bit bir Server 2008 kullanmak zorunda kalacaksınız. Şimdi diyebilirsiniz. Client Hyper-V ye Hangi OS kurabiliriz. Server 8 in desteklemiş olduğu linüx olsun veya başka bir yazılım olsun Client Hyper-V de bunları destekleyecektir. Tabii burada şu sıkıntı doğuyor. Client Hyper-V kuracağımız Makinemizin her şeyden önce 64 Bit bir CPU kullanmamız bu da yetmemiş gibi işlemcimizin Second Level Address Translation (SLAT) mimarisini kullanan bir işlemci olması gerekmekte. Tabii ki dezavantajlarının olduğu gibi avantajlarının da olacağı kesin. SLAT kullanılmasının temel amacı sanal makinelerin performans bakımından yüksel olacağını belirtmekte fayda var. Peki bu SLAT ? nedir Second Level Address Translation : Adındanda anlaşılacağı üzere İkinci Seviye Adres Çeviri yapan donanımsal CPU teknolojisidir. Intel ve Amd tarafından farklı isimlerle tanımlanır. Intel tarafında EPT (Extended Page Tables), Amd tarafında ise RVI(Rapid Virtualization Indexing) olarak bilinir.Teknolojinin asıl amacı ise, Hypervisor'de yönetilen yada tutulan VM'lerin memory bitleri ile fiziksel memory bitleri mapping table'lar ile yapılırken, Slat sayesinde mapping table'lar yerine bu iş CPU ya verilerek Hypervisor üzerindeki yük ciddi anlamda azaltılmış oluyor. Buda VM ler üzerinde performans artışına katkı sağlıyor. Alıntıdır. Yukarıda ki alıntı olan açıklama bu konuda bence çok iyi daha fazla yorum yapmaya gerek yok bence J şunu da önemle belirtmekte fayda var. Windows Server 8 üzerinde SLAT özelliği aranacak mı ? hayır SLAT özelliği en azından şimdilik Windows Server 8 için aranan şartlardan birisi değil bu özellik tamamıyla Client Hyper-V üzerinde aranacak bir özelliktir. Bu açıklamalardan sonra isterseniz Client Hyper-V kurulabilmesi için neler gerekli ve hangi aşamaları uygulamalıyız.

Sistem Gereksinimleri

64 Bit CPU

SLAT (Client Hyper-V için)

Windows 8

Windows 8 Client Hyper-V Kurulumu

Yukarıda ki açıklamalardan sonra zannediyorum ki Client Hyper-V hakkında kafanızda bir şeyler canlanmıştır. İşin özü Microsoft bizleri Client Hyper-V kullanarak 3.party yazılımlardan tamamıyla soyutlayacak ve elimizde ki imkanlarla müthiş işler başaracağız. Artık Windows 8 Client Hyper-V kurulumuna başlayabiliriz. Öncelikle birkaç ayrıntıya değinmek istiyorum. Benim elimde 2 adet diz üstü bilgisayarım var. Bunlardan birisi 64 bit mimarisine sahip ve sanallaştırmayı destekleyen AMD işlemcili bir bilgisayar. Client Hyper-V kuracağımız. İlk makine bu sizler için örnek teşkil etmesi yönünden bu uygulamayı uygun gördüm.

Windows 8 Client Hyper-V-01

Windows Featureslere baktığımda Client Hyper-V rolünün yüklene bildiği lakin Hyper-V Platformun yüklenemediğini görüyoruz. Yani işlemcimizin SLAT desteği bulunmamaktadır.

Windows 8 Client Hyper-V-02

Şimdi http://technet.microsoft.com/en-us/sysinternals/cc835722 belirtilen adrese giderek Coreinfo v3.04 toolunu indirelim. Bu tool ile işlemcimizin tüm özelliklerini görebiliriz. İndirdikten sonra bu dosyayı C: dizini içerisine çıkaralım.

Windows 8 Client Hyper-V-03

C: dizini içerisine çıkarmış olduğumuz. Coreinfo.exe dosyasını çalıştırmamız gerekmekte bunun için Command prompt yi sağ tıklayalım ve yönetici olarak çalıştıralım. Yukarıda ki şekle bakacak olursak dosyamızı C: dizini içerisine çıkarttığımız için cd c: \ yazarak c: dizini içerisine ulaşalım. C: dizinine ulaştıktan sonra coreinfo.exe –v komutunu yazalım ve toolumuzu çalıştıralım. Kırmızı alan içerinde görüldüğü üzere işlemcimizin SLAT özelliği bulunmamakta şimdi başka bir dizüstü bilgisayara geçerek bunu aynı adımları uygulayarak test edelim.

Windows 8 Client Hyper-V-04

Yukarıda ki şekli inceleyecek olursak core i7 bir işlemciye sahip dizüstü bilgisayar kullanmaktayım.

Windows 8 Client Hyper-V-05

Şekil-3 den hatırlayacağınız üzere coreinfo.exe dosyasını çalıştırabilmemiz için bazı adımlar uygulamıştık. Aynı adımları burada da uyguluyorum. Intel işlemciler SLAT özelliğini EPT (Extended Page Tables) olarak kullandıkları için EPT yazan satıra baktığımızda karşısında * işareti görünmekte bu demek oluyor ki işlemcimiz SLAT yani Second Level Address Translation özelliğini desteklemekte. Bu demek oluyor ki heyecan verici Windows 8 Client Hyper-V deneğimimize başlayabiliriz. Client Hper-V yi 3 şekilde kurmamız mümkün bunlar;

Grafik Arayüz

PowerShell

Commandline

Biz senaryomuz gereği grafik arayüz kullanarak kurulum işlemimizi tamamlayacağız.

Windows 8 Client Hyper-V-06

Masa üstüne gelerek settings bölümünü seçelim.

Windows 8 Client Hyper-V-07

Karşımıza yukarıda ki ekran gelecek buradan control panel i tıklayalım.

Windows 8 Client Hyper-V-08

Programs and Features tıklayalım.

Windows 8 Client Hyper-V-09

Karşımıza Programs and Features ekranı gelmekte burada da Turn Windows features on or of tıklıyoruz. Burada yeni Windows özelliklerini ekleyip kaldırabiliriz.

Windows 8 Client Hyper-V-10

İşte karşımızda can alıcı o süper nokta J Hyper-V şekil-1 den hatırlarsanız Hyper-V Platform aktif değildi. Yani işlemcimiz SLAT özelliğini desteklemediği için seçim yapamıyorduk. Artık seçebiliyoruz. Hyper-V ve tüm bileşenlerini seçtikten sonra OK diyelim.

Windows 8 Client Hyper-V-11

Kurulum işlemi çok kısa sürecektir. Windows 7 üzerinde bu işlemi yapmak daha uzun ve isteklerimize cevap vermiyordu. Şimdi ise Client Hyper-V ile isteklerimize cevap bulabileceğiz. Kurulum işlemi tamamlandıktan sonra makinemizi restart edelim.

Windows 8 Client Hyper-V-12

Metro arayüze baktığımızda Hyper-V managerı görebiliriz. Hyper-V Manager e tıklayalım.

Windows 8 Client Hyper-V-13

Windows 8 üzerinde Client Hyper-V kurulumumuzu gerçekleştirdik. Artık yeni sanal makineler oluşturabilir. Ve Hyper-V nin hepsi olmasa da hemen hemen tüm nimetlerinden faydalanabiliriz.

Windows 8 Client Hyper-V-14

Yukarıda ki şekli şöyle bir inceleyelim. Kişisel dizüstü bilgisayarlarımıza test amaçlı Windows Server 2008 R2 kurduğumuzda Hyper-V manager üzerinde wireless kartlarımızı gösteremiyorduk. Artık hem Server 8 tarafında hem de Windows 8 tarafında wireless kartlarımızı Hyper-V manager üzerinde aktif bir şekilde kullanabileceğiz. Makalemizin başında Client Hyper-V ile bazı senaryoları gerçekleştiremeyeceğimizi söylemiştik. Peki bu senaryolar nerlerdir ? Live Migration sanal makinelerimizi canlı olarak taşıyamayacağız. Synthetic Fiber Channel yapamayacağız. Hyper-V replica özelliğini, SR-IOV, Remote FX özelliklerini kullanamayacağız. Remote FX özelliği Client Hyper-V üzerinde yazılım sal olarak 3D özelliğini kullanabiliriz. Bu makalemde sizlere Windows 8 üzerinde Client Hyper-V yi nasıl kurabileceğimizi ve genel özelliklerinden bahsetmeye çalıştım umarım sizler için faydalı olmuştur.

Başka makalelerde tekrar görüşmek ümidiyle hoşçakalın.

Bu makalemizde Ofis 365 üzerinde bulunan mahkeme nedeniyle tutma özelliğini ele alıyor olacağız. “Bu özellik nedir?” , “Ne işe yarar?” gibi kısımları aşağıdaki gibi soru cevap yaparak daha iyi anlamaya çalışalım.

Posta kutusunu neden mahkeme nedeniyle tutma durumuna alınır?

Kuruluşunuz bir yasal işlemle ilişkiliyse, kanıt olarak kullanılabilecek e-posta iletileri gibi ilgili verileri korumak için önlem almanız gerekebilir. Bu gibi durumlarda, belirli kişiler tarafından gönderilen ve alınan tüm e-postayı veya kuruluşunuzda belirli bir süre boyunca alınan ve gönderilen tüm e-postaları korumanız gerekebilir. Posta kutularını mahkeme nedeniyle tutma durumuna almak, bu tür yasal gereklilikleri sağlamanın ilk adımıdır.

Bir posta kutusu mahkeme nedeniyle tutma durumuna alındığında ne olur?

Kullanıcılar iletilerini Silinmiş Öğeler klasöründen sildiğinde ya da bir posta kutusu öğesini kalıcı olarak silmek için Shift+Delete tuşlarına bastığında silinen öğeler kullanıcının posta kutusunda gizli bir klasöre kopyalanır. Bu klasöre Kurtarılabilir Öğeler adı verilir. Aynı zamanda dumpster adı da verilir.

Dumpster klasöründeki öğeler varsayılan olarak 14 gün tutulur, ardından Microsoft Exchange tarafından silinir. Bir posta kutusu mahkeme nedeniyle tutma durumuna alındığında Dumpster klasörü silinmez ve klasördeki öğeler süresizce saklanır. Mahkeme nedeniyle tutma durumu kullanıcının günlük e-posta akışını etkilemez, böylece kullanıcılar normalde olduğu gibi posta kutusu öğelerini değiştirip silmeye devam edebilirler.

Kullanıcılar öğeleri Dumpster klasöründen el ile silebilirler.

• Microsoft Outlook 2010 Klasör sekmesini tıklatın, Silinmiş Öğeleri Kurtar > Seçili Öğeleri Temizle'yi seçin
• Outlook Web App Silinmiş Öğeler > Silinmiş Öğeleri Kurtar > Seçili Öğeleri Temizle

Kullanıcının posta kutusu mahkeme nedeniyle tutma durumuna alınırsa, Microsoft Exchange Dumpster klasöründen el ile temizlenen öğeleri tutar.

Bir posta kutusu mahkeme nedeniyle tutma durumundan çıkarıldığında ne olur?

Bir posta kutusu artık mahkeme nedeniyle tutma durumunda olmadığında Microsoft Exchange silinen öğeleri ya da özellikleri değiştirilen öğelerin kopyalarını saklamaz. Mahkeme nedeniyle tutma nedeniyle tutulan öğeler anında Dumpster klasöründen silinmez ancak, Microsoft Exchange'in 14 günden eski öğeler için Dumpster klasörünü sonraki denetlemesinde temizlenir.

Bu özelliğimizden bu şekilde bahsettikten sonra Ofis 365 Online Portal üzerinde bu özelliğin nasıl devreye alındığını inceleyelim. Öncelikle portalımıza yönetici hesabımızla login olalım.

Login olduktan sonra Admin panelimizden Exchange bölümünden “Manage” linkine tıklayalım.

Açılan ekranımızda kullanıcı ve gruplarımız listelenmektedir. “Mahkeme Nedeni ile Tutma” ilkesi atamak için bir kullanıcı seçip “Ayrıntılar” butonumuza tıklayalım. Ben “UFUK ŞAHAN” isimli kullanıcımı seçip “Ayrıntılar” butonuna tıklıyorum.

Açılan ekranımızda Organizasyonumuz içerisinde daha önce oluşturduğumuz kullanıcının özelliklerin bulunduğu konsol karşımıza geldi. Bu konsol kullanıcının özelliklerinin yönetilebileceği, değiştirilebileceği birçok ayarı içermektedir.

Biz makalemizin de konusu olan ”Mahkeme Nedeniyle Tutma” özelliğini aktif edeceğiz. Bu işlem için kullanıcı özelliklerinden “Posta Kutusu Özellikleri” ekranını açalım. Bu kısımda kullanıcımızın Arşiv ve Mahkeme Nedeniyle Tutma Özellikleri Aktif veya pasif edilebilmektedir. Kullanıcımız üzerinde bu ayarın üzerine gelerek “Etkinleştir” butonumuza tıklayalım ve ayarların etkin olması için “Kaydet” butonumuza tıklayalım.

Şu anda ayarımız etkin olarak gözüküyor. Bu ayarımızın tam olarak aktif bir şekilde çalışabilmesi için 1 saat gibi bir süreye ihtiyaç vardır. Bu bazen bu sürenin altında da olabilir. Bu özelliğimizin üstüne çift tıklayarak kullanıcının posta kutusunun “Mahkeme Nedeniyle Tutma” ilkesine tabi olduğunu belirtebiliriz. Bu bildirimi kullanıcı Outlook 2010 kullanıyorsa görebilir.

Ayarımız etkin oldu.

Şimdiye kadar olan kısımda kullanıcının mailboxının “Mahkeme Nedeniyle Tutma” özelliğini aktif etme kısmına değindik. Şimdi ise bu kullanıcının maillerinin nasıl izleneceğiz ve silse dahi silinen maillere nasıl göz atacağımıza değinelim. Exchange Yönetim Paneli->Kuruluşumu Yönet->Posta Denetimi sekmesinde “Bulma” isimli bir butonumuz olması gerekir. Bu buton şu anda gözükmüyor.

Butonumuzun gözükmemesinin nedeni bulma işlemini yapacak olan yetkilinin bu görevi yapabilmesi için yetkili grubuna üye olması gerekmektedir. Bu şirket içinden biri olacağı gibi büyük bir kurumsa eğer gelen adli yetkiliye bir mailbox tanımlanıp bu yetki verilerek maillere kendisinin bakması sağlanabilir. Aynı yetki İnsan Kaynaklarına verilerek IT depertmanı üzerindeki yük azaltılabilir. Bu işlem için “Roller ve Denetim” sekmesine gelerek yönetici rolleri kısmındaki “Discovery Managenet” rolüne çift tıklatalım.

Açılan ekranda bu denetimi yapacak olan yetkiliyi bu role atayalım. Ben bu kısımda “RIZA ŞAHAN” kullanıcısını yetkili kıldım. Kaydet ile işlemimizi tamamlayalım.

Bu yetki işleminden sonra “BULMA” butonunun aktif olduğunu görebiliyoruz.

Şimdi “Mahkeme Nedeniyle Tutma” ilkesi uyguladığımız “UFUK ŞAHAN” kullanıcı mailboxına bakalım. Kullanıcımızın belli bir mail trafiği olduğunu görebiliyor.

Kullanıcının maillerini sildiğini ve geride yaşanabilecek hukuksuz bir olayda kanıt bırakmak istemediğini düşünelim. Bu nedenle kullanıcının tüm maillerini siliyorum.

Kullanıcımızın biraz iyi bir kullanıcı olduğunu planlayarak “Silinmiş Öğeleri Kurtar” kısmından da maillerini sildiğini düşünerek mailleri buradan da siliyorum.

Şu anda maillerimiz hem mailbox hem de silinmiş öğeleri kurtar kısmından tamamı ile silindi.

Şimdi hukuksal bir denetim olduğunu düşünerek “Mahkeme Nedeniyle Tutma” ilkesi uyguladığımız kullanıcımızın maillerine nasıl ulaşacağımıza bakalım. Exchange Yönetim Paneli->Kuruluşumu Yönet ->Posta Denetimi sekmesinde “Bulma” isimli bir butonumuza tıklayalım.

Karşımıza gelen ekranda “Yeni” butonuna tıklayarak yeni bir arama sorgusu başlatalım.

Karşımıza mail araması yapmak için detaylı bir sorgu ekranı geldi. Burada birçok kıstas ve arama kriteri belirleyebilirsiniz. Ben basit ve tarih v.s. sorgusu girmeden geniş kapsamlı bir arama yapacağım. Burada arama işlemini bir tek mailbox üzerinde yapacağım için ilkemin uygulanmış olduğu mailboxı seçiyorum. Arama işlemime bir isim veriyorum. Siz burada tüm organizasyonda bu ilkeyi uygulayabilir ve içeriği yasal olmayan bir postayı tüm kuruluş içinde aratabilirsiniz. Bu sizin şirket politikanızla ilgili bir durum.

Yukarıdaki ekranıma sığmadığı için ekranın alt kısmını bu resimde paylaşıyorum. Arama sonuçlarıma bakmak için bunların bir mailbox üzerine aktarılmasını istiyorum. Bu nedenle sonuçlara ulaşmak için “Discovery Mailbox” ı seçiyorum. Exchange üzerinde bulunan bu mailbox bu tarz işlerde kullanılmak için sistem tarafından otomatik olarak tanımlanmış durumdadır. Kaydet butonu ile arama sorgumuzu kaydederek aramanın başlatılmasını sağlıyorum.

Şu anda arama işlemimiz kriterlerimiz doğrultusunda başladı ve devam ediyor. Arama yapılan mailbox sayısı ve bunun içeriğindeki mail miktarına göre işlemimiz zaman alacaktır.

İşlemimiz şu anda tamamlandı. Bulunan öğeler Discovery Mailbox içerisine aktarıldı. Ok işaretinin gösterdiği alandaki “aç” kısmına tıklayarak maillerimizin açılmasını sağlayalım.

Şu anda “Mahkeme Kararı ile Tutma” klasörü altında kullanıcımızın mailboxında yer alan ve sildiğimiz mailboxları görebiliyoruz.

Yukarıda kullanıcının “Mahkeme Nedeniyle Tutma” ilkesinden etkilendiğinden haberdar olması için açıklama kısmına bir açıklama girmiştik bu açıklama ise aşağıdaki gibi Outlook üzerinde “Dosya->Bilgi “ menüsünde yer almaktadır. Bizim resimde seçili alana uyarımız eklenmedi. Bu uyarının eklenmesi için biraz zaman geçmesi gerekmektedir.

Ofis 365’in yetenekleri yavaş yavaş kullanıldıkça ortaya çıkıyor. Umarım yararlı olmuştur bir başka makalede görüşmek dileğiyle.

Windows Server 2008 R2 sunucu işletim sistemi release süresi üzerinden yaklaşık iki (2) yılı aşkın bir süre geçti. Ortalama her üç yılda bir yenilenen server ve client işletim sisteminde 2012 yılı içerisinde çıkacağını tahmin ettiğimiz client yani istemci tarafında Windows 8, server yani sunucu tarafında da Windows Server 2012 işletim sistemi yeni versiyona yaklaşmanın heyecanı gittikçe artıyor. Sizlerle şu ana kadar hem beta öncesi sürüm olan Windows Server 8 Developer Preview versiyonu üzerinde hem de kısa süre önce çıkan Windows Server “8” Beta sürümü üzerinde aşağıdaki makalelerle, workshop etkinlikleri ve web seminerleri ile yenilikleri paylaşmıştık :

Windows Server 8 Kurulumu
Windows Server 8 Active Directory Kurulumu
Windows Server 8 Yenilikleri
Windows Server 8 Active Directory Yenilikleri
Windows Server 8 ve Hyper-V 3.0 – Hızlı Bakış
Windows Server 8 Failover Clustering Yenilikler ve Cluster Kurulumu
Windows Server 8 Active Directory Recycle Bin (Geri Dönüşüm Kutusu)
Windows Server 8 Grafiksel Arayüzün (GUI) Devre Dışı Bırakılması/Etkinleştirilmesi
Windows Server 8 Fine Grained Password Policies
Windows Server 8 DHCP Failover
Windows Server 8 Data Deduplication (Veri Tekilleştirme)
Windows Server 8 Server Manager
Windows Server 2003 R2 Active Directory’den Windows Server 8 Active Directory’ ye Migration
Windows Server 2008 R2 Active Directory’den Windows Server 8 Active Directory’ye Migration
Windows Server 8 Remote Desktop Services - Bölüm 1
Windows Server 8 Remote Desktop Services - Bölüm 2
Webcast - Windows Server 8 Yenilikleri
Webcast - Windows Server 8 File Server Yenilikleri - Data Deduplication, Dynamic Access Control, File Classification
Webcast - Windows Server 8 Active Directory Yenilikleri
Webcast - Windows Server 8 Active Directory Uygulamaları - Bölüm 1
Webcast: Windows Server 8 Active Directory Migration
Webcast - Windows Server 8 Hyper-V 3.0 Yenilikleri (DP)
Webcast - Hyper-V 3.0 Yüksek Erişilebilirlik Özellikleri
Webcast - Windows 8 Cluster Yenilikler - Uygulamalı
Seminer - Windows Server 8 Yenilikleri
Seminer - Windows Server 8 Active Directory Yenilikleri
Seminer - Windows Server 8 Hyper-V Yenilikleri

29 Şubat itibariyle beta versiyonu görücüye çıkan Windows Server 8 üzerinde gelen yenilikleri sizlerle sıcağı sıcağına paylaşmaya devam ediyoruz. Bu hafta içerisinde ürün grubunun yayınladığı son haberlere göre yeni nesil sunucu işletim sisteminin resmi adı Windows Server “8” değil, Windows Server 2012 olacak.

Not : 2012 yılı içerisinde çıkmasını beklediğimiz yeni nesil sunucu işletim sistemi resmi adı Windows Server “8” yerine Windows Server 2012 olarak değiştiği konusunda güncel bilgiler ulaştı. Dolayısıyla Windows Server “8” olarak hazırladığımız makale içerisinde Windows Server 2012 ya da Windows Server 2012 “Beta” olarak değişiklikleri yaptık.

Microsoft’un Windows Vista ve Windows Server 2008 ile başlattığı sunucu işletim sistemi ile istemci işletim sisteminin paralel geliştirme süreci Windows 7 ve Windows Server 2008 R2’den sonra Windows 8 ve Windows Server 2012 ile de devam ediyor. Şu anda hem Windows 8 istemci (client) hem de Windows Server 2012 sunucu (server) versiyonlarında Beta versiyonu indirilebilir olarak genele açık bir platformda sunuldu ve ilk günlerden milyonlarca kullanıcı tarafından indirildi. Windows Server 8 Developer Preview sürümündeki gibi sadece MSDN üyelerine değil tüm dünya geneline indirilebilir olarak yayınlandı. Aşağıdaki adreslerden Windows 8 Client ve Windows Server 2012 beta sürümünü indirebilirsiniz:

Windows 8 Consumer Preview (Client) için:

http://windows.microsoft.com/en-US/windows-8/iso

Windows Server 2012 Beta için:

http://technet.microsoft.com/en-us/evalcenter/hh670538.aspx

Çok taze bilgileri sizlerle paylaşmak istediğimizden şu aşamada yayınladığımız makaleler BUILD 8250 versiyonunda gelen ortama göre olacak. Tabi daha henüz ilk beta olan Windows Server 2012’de zaman içerisinde yeni geliştirmeler ve değişiklikler görebiliriz.

Bu makalemizde de sizlerle Windows Server 2012 İle Virtualized Domain Controller (VDC) ve VDC Klonlama (VDC Cloning) konsepti ve adım adım uygulamaları ile ilgili detayları beraber inceliyoruz:

VM-Gen ID Teknolojisi ile Risksiz ve Sorunsuz Active Directory Domain Controller Sanallaştırma Desteği

Bildiğiniz gibi günümüzde çok sayıda şirket artık sunucu sanallaştırma teknolojilerini kullanıyor ve mümkün olduğunca tüm sunucuları, servisleri ya da uygulamaları fiziksel yerine sanal ortama konuşlandırmayı tercih ediyor. Özellikle test ya da geliştirme ortamlarının hemen hemen tamamını sanal ortamda oluşturarak hem zamandan kazanma, hem operasyonel yükü azaltma, hem de donanım maliyetinden tasarruf etme gibi nedenlerle tercihlerini bu yönde kullanıyorlar.

Bazen de elimizde bulunan fiziksel bir sunucuyu sanallaştırma alanındaki araçları kullanarak fizikselden-sanala dönüştürme (physical-to-virtual / P2V) yapabiliyorlar. Böylece sanal ortamda bu sunucuyu sıfırdan kurup, yapılandırmak yerine P2V yöntemi ile çok hızlı dönüşümle oluşan sanalı hemen ayağa kaldırarak devreye alabiliyorlar.

Sanal ortamlarda standart uygulama ve servislerin barındırılması, işletilmesi, geri yüklenmesi gibi süreçler active directory domain servisleri uygulamasında ciddi farklılıklar arz ediyor.

Windows Server 2012 işletim sistemine kadarki gelinen süreçteki tüm işletim sistemlerinde sanal ortama kurulan active directory domain controller sunucuları ile ilgili şu şekilde çağrılarla sıkça karşılaşabiliyorduk:

Müşteri active directory yapısında çalışan domain controller sunucularını sanal platform üzerinde kurmuş.Domain controller sunucularının system state yedekleri yerine snapshot kopyalarını almış. Müşteri active directory ortamında son zamanlarda yapılmış bazı değişiklikleri geri almak ve sistemi bu değişikliklerden önceki yapıya gerİ döndürmek istiyor. Bunun için DC’lerden birini eski tarihli snapshot kopyaya geri dönüyor. Ve replikasyon yapısı bozuluyor. Netlogon servisi duruyor. DC üzerinde Event Viewer’da Directory Service log kategorisinde 2095 ID’si ile kaynağı NTDS Replication olan eventlar oluşuyor. Ayrıca yine Directory Service olay kayıtlarında yine kaynağı NTDS General olan 1113 ve 1115 ID’li günlükler oluşuyor. Bu şekilde olan domain controller üzerinde komut satırına düşüp repadmin aracını kullanarak aşağıdaki komutu çalıştırınca da “Current DC Options: IS_GC DISABLE_INBOUND_REPL DISABLE_OUTBOUND_REPL” hatası karşımıza geliyor.

repadmin /options < DCAdi>

Windows Server 2012 ile beraber artık rahatlıkla active directory domain controller sunucularınızı sanallaştırabilirsiniz. Windows Server 2012 ile oldukça yaygınlaşacak yeni bir domain controller kavramı geliyor : sanal etki alanı denetleyicisi (virtual domain controller – VDC). Bunun en büyük nedeni artık sanallaştırma uygulamaları active directory yapısına duyarlı olarak geliştirilmesidir. Bunu yaparken de Windows Server 2012 üzerinde VM generation ID (gen ID) olarak adlandırılan bir etiket ile active directory domain controller sunucusu üzerine geri yüklenen snapshot’dan sonraki değişiklikler tespit edilerek AD ortamı bozulmadan korunmuş oluyor. Bu makalemizde bunları detaylı olarak inceliyor ve adım adım uygulamalarını yapıyor olacağız.

Active Directory Domain Servislerde Sanallaştırma

Active Directory Domian Servislerinde sanallaştırma özellikle son birkaç yıldır sistem ve sanallaştırma uzmanları arasında uzun uzun konuşulan, tartışılan önemli konuların başında geliyordu. Windows Server 2012 (Windows Server “8”) Beta ile active directory domain ortamında çalışan domain controller sunucular için tam uyumlu ve active directory-servislerine duyarlı sanallaştırma desteği geliyor. Bir diğer deyişle artık sanallaştırılmış etki alanı denetleyicileri (virtualized domain controllers – vdc) adında yeni bir sanal kavram geliyor. Bu sayede active directory ortamında çalışan domain controller sunucularımızı güvenli bir biçimde sanallaştırabiliyoruz. Sanallaştırılmış Domain Controller desteği sayesinde çok hızlı bir biçimde mevcutta çalışan bir domain controller sunucunun kopyasını alıp, bu kopyadan sanal ortamda yeni domain controller sunucuları çok hızlı bir biçimde devreye alabiliyoruz. Yani artık özellikle additional domain controller kurulumları için, sıfırdan bir Windows Server 2012 işletim sistemi kurup, sonrasında da bu sunucu üzerine active directory domain servis rolünü yükleyip, konfigüre etme gibi süreçleri gerçekleştirmeye gerek olmadan, sanal platformda çalışan mevcut bir Windows Server 2012 additional domain controller sunucusunun Sanal Diskini (Hyper-V için VHD ya da VHDX) kopyalayarak kısa sürede yeni bir additional domain controller hazırlayabiliyoruz. Windows Server 2012 ile bulutan giden yolda active directory domain controller sanal sunucuları için gelen bu tam-destekli sanallaştırma yeteneği bulut servislerinin yaygınlaşmasına da ciddi hız kazandıracaktır. Gerek şirketlerin kendi ortamına ya da veri merkezi ortamlarına kuracakları özel bulut yapıları, gerek herkese açık olacak genel bulut yapıları, gerek se birbirine entegre şekilde çalışan şirket ortamındaki active directory domain hizmetleri (on-premise) ile bulutta çalışan active directory hizmetlerine ciddi kolaylıklar ve katma-değerler getirecektir.

Domain Controller Sunucularda Güvenli Sanallaştırma

Hepimizin bildiği gibi active directory mantıksal olarak saat-bağımlı bir replikasyon şeması kullanır. Bu mantıksal saat-bağımlı replikasyon şemasında, active directory replikasyonu USN (Update Squence Number) adı verilen artan bir değerle işletilir ve kontrol edilir. USN numarası her domain controller sunucusunda üzerinde ekleme, silme, değiştirme uygulanan nesnelere atanan bir numaradır. Diğer yandan her domain controller üzerinde bir active directory veritabanı örneği (database instance) bulunur. Bu veritabanı örneğinin InvocationID adı verilen kendine ait bir kimliği vardır. Domain Controller’a ait InvocationID ile yine bu domain controller’ın USN numarasının biraraya gelmesi ile o domain controller için forest çapında benzersiz bir kimlik bilgisi üretilir. Active Directory replikasyonu her domain controller üzerindeki InvocationID ve USN’lere bakarak diğer domain controller’lara replikasyon yapılacak değişikliklere karar verir. Eğer bir domain controller zaman içerisinde eski bir yedeğe ya da snapshot kopyasına geri yüklenirse, domain controller sunucusu bunun farkına varamadığından aynı USN numaralarını tamamen farklı işlemler için tekrar üretecek ve böyle bir durumda da diğer domain controller sunucuları ile replikasyon gerçekleşmeyecektir. Çünkü diğer domain controler sunucuları tekrar kullanılan USN numaralarının önceden farklı bir çoğaltma için kendilerine geldiğini bilirler. Özellikle bu durum sanallaştırma uzmanları ve sanallaştırma uygulamaları tarafından bilinmediğinden yanlışlıkla yapılan domain controller snapshot geri yüklemelerinde (restore) bu sorunlar karşımıza gelirdi.

Windows Server 2012 Beta ile sanal platformlar üzerinde bir sanal sunucu olarak çalışan active directory domain controller sistemleri için VM-Generation ID adı verilen ilave bir kimlik bilgisi üretilerek mevcut active directory domain ortamının yapısının korunması ve güvenli bir biçimde sanal domain controller sunucularının eski snapshot geri yüklemelerini yapmaları sağlanmış oluyor. VM-GenerationID tasarımı sanal makinenin adres alanında bu kimlik bilgisini ortaya çıkarmak için bir hipervisör-agnostik mekanizması kullanır. Bu kimlik bilgisi sanal makine içerisinde koşan servisler ve uygulamalar tarafından örneklenerek zaman içerisinde sanal sunucu üzerinde geri yükleme yapılıp yapılmadığını tespit etmede kullanılır.

Not : Windows Server 2012 Beta hyper-V hipervizörü bu kimlik bilgisini guest adres alanında ortaya çıkartır.

Active Directory başlangıçta VM GenerationID değerini domain controller yükseltmesi esnasında oluşan active directory veritabanı ya da dizin ağacında oluşan domain controller’ın bilgisayar hesabı (computer account) nesnesinin msDS-GenerationID attribute’ünde depolar. Sonraki işlemler esnasında sanal sunucuya ait VM GenerationID’nin mevcut değeri active directory dizin ağacındaki değer ile karşılaştırılır. Eğer bu iki değer farklı ise, invocationID resetlenir ve USN’lerin tekrar kullanımları ve mükerrer security-principal oluşumu önlenmiş olur. Eğer bu iki değer aynı ise, işlem normal olarak gerçekleştirilir. Domain Controller sunucusu her yeniden başlatıldığında active directory sanal sunucudaki VM GenerationID’nin mevcut değerini dizin ağacındaki (DIT veritabanı) değerle karşılaştırır ve eğer farklı ise invocationID resetlenir ve yeni bir değer üretilerek DIT veritabanı da güncellenir. Windows Server 2012 Beta ile gelen bu emniyet tedbirleri ya da koruyucu mekanizmalar active directory yöneticilerine sanal ortamlarda domain controller kurulması ve yönetilmesi konusunda benzersiz avantajlar sağlamaktadır.

Windows Server 2012 Beta ile Active Directory VM-GenerationID duyarlı/destekli hipervizörler üzerinde kurulan ve çalışan domain controller sanal sunucularında bu koruma/emniyet tedbirlerini işleterek, bilerek ya da planlı bir biçimde snapshot geri yüklemelerinde ya da sanal sunucunun eski kopyalara geri alınması durumlarında active directory ortamının bozulmamasını ya da bu işlemlerden etkilenmemesini garanti altına almış olacaktır. Bu koruma sayesinde USN buble ya da lingering object gibi replikasyon problemlerinin oluşması önlenmiş olacaktır. Tabii burda hemen şunu da vurgulamak da fayda var. Artık domain controller sunucuları eski snapshot versiyonlarına güvenli bir biçimde geri dönebiliyoruz demek, domain controller’lar için yedekleme uygulamaları ile bu sunucuların yedeklerini almaya gerek olmadığı anlamına gelmesin. Çünkü alınan snapshot kopyaları yedeklemeye tam bir alternatif değildir. Dolayısıyla yine her zaman olduğu gibi düzenli olarak domain controller sunucuların yedeklerini Windows Server Backup ya da üçüncü-parti VSS-writer tabanlı yedekleme çözümleri ile almaya devam edeceğiz.

Sanallaştırılmış Domain Controller Klonlama (VDC Clone)

Windows Server 2012 Beta üzerinde gelen sanallaştırılmış domain controller klonlama özelliği sayesinde sistem yöneticilerinin sanalda çalışan mevcut domain controller sunucunun bir kopyasını alarak klonlanmış yeni domain controller’ların güvenli bir biçimde oluşturmaları sağlanmış olacaktır. Dolayısıyla sanal ortamlarda artık sistem yöneticileri sürekli sysprep uygulanan sunucu imajları kullanma, sunucuyu domain controller rolüne yükseltme ve kurulan her additional domain controller için gerekli konfigürasyonları yeniden yapma gibi zorunluklar da kalkmış oluyor.

Not : Sistem yöneticileri domain içerisindeki ilk domain controller sunucuyu kurarken yine eski yöntemlerle sunucuyu sysprep imajlanmış şekilde bir VHD hazırlayıp, bu sunucuyu domain controller rolüne yükseltip, gerekli ilave konfigürasyonları da yapmış olmaları gerekir. Herhangi bir felaket senaryosunda da domain içerisindeki ilk kurulan domain controller üzerine en güncel yedek geri yükleme yapılmalıdır.

VDC Klonlamanın Getirdiği Avantaj Senaryoları

Windows Server 2012 Beta ile gelen VDC klonlama yeteneğini kullanmanın çok sayıda avantajı bulunmaktadır.

·         Yeni bir forest ya da domain içerisinde hızlı bir biçimde additional domain controller kurulumu ve devreye alınması

·         Felaket anında işletilen felaketten kurtarma sürecinde devre dışı kalan sistemleri hızlı bir biçimde geri getirmek ve klonlama sayesinde gerekli active directory kapasitesini hızlıca eski haline getirmek

·         Özellikle özel bulut yapılarında yaşanan büyümelerde domain controller sunucularının hızlı bir biçimde ölçeklenebilir olmasını sağlamaktadır.

·         Test ortamlarının hızlı bir biçimde kurulumu, hazırlanması ile artan verimlilik.

·         Şube ofisi büyümelerinde mevcut domain controller sunucularından klon alınarak artırılmış kapasite ihtiyaçlarına çok hızlı çözüm üreten altyapı desteği

Görevler Ayrılığı

Sanallaştırılmış domain controller sunucularının klonlama ile çoğaltılması yetkisi active directory domain yapısını yöneten sistem yöneticisine ait olmalıdır. Sanallaştırma yöneticileri kendi başlarına active directory domain controller sunucuların klonunu alıp, yetki almadan bu klondan yeni domain controller’lar oluşturmamaları gerekir. Zaten bir active directory domain controller sanal sunucusunun klonlanabilmesi için gerekli yetkilendirmeyi active directory içerisinden active directory sistem yöneticisi hazırlamalıdır. Active Directory yöneticilerinin yetkilendirmesi sonrasında sanallaştırma yöneticileri bu sunucuların klonlarını alarak kurulum ve konuşlandırma adımlarını tamamlayabilirler.

Domain Controller Klonlama Nasıl Gerçekleştirilir?

Domain Controller Klonlama üç ana aşamadan oluşan bir süreç:

1.       Klonu alınacak mevcut sanal domain controller sunucunun active directory içerisinde yetkilendirilmesi ,

2.       Yetkilendirilen sanal sunucu üzerinde klon konfigürasyon dosyasının oluşturulması,

3.       Yetkilendirilen sanal sunucunun sanal diskinin (virtual hard disk – VHD ya da VHDX) ya da sanal sunucunun tamamının kopyalanarak klon sunucunun oluşturulması,

Klonlanan domain controller, bir diğer domain controller sunucunun kopyası olduğunu farketmesini sağlayan ve süreci tetikleyen iki önemli tetikleyici vardır:

1.       Sanal sunucunun sahip olduğu VM-GenerationID değeri ile DIT veritabanı içerisinde depolanan VM-GenerationID değeri farklı ise,

Not: Hipervizör platformu VM-GenerationID desteğini sağlamalıdır. Windows Server 2012 Beta Hyper-V, VM-GenerationID desteğini sağlıyor.)

2.       DIT veritabanının olduğu dizinde DCCloneConfig.xml isimli bir XML dosyasının varlığı.

Sanal domain controller sunucusu yukarıdaki tetikleyiciler vasıtasıyla kendisinin klonlanmış bir domain controller sunucu olduğunu anladıktan sonra, klonlama sürecinden geçerek yeni domain controller sunucu hazırlanır.

Klonlanan domain controller, klon alınırken kullanılan kaynak domain controller’ın güvenlik bilgilerini kullanarak Windows Server 2012 Beta Primary Domain Controller (PDC) Emulator FSMO rolüne sahip domain controller sunucusu ile bağlantı kurar. PDC FSMO rolünün sahibi Windows Server 2012 Beta versiyonunda çalışacak bir domain controller olmalıdır.

Önemli Not : PDC Emulator FSMO rolüne sahip domain controller Windows Server 2012 Beta işletim sisteminde çalışmalıdır. Bu sunucu fiziksel ortamda çalışan bir sunucu olabileceği gibi sanal ortamda çalışan bir sunucu da olabilir.

PDC Emulator rolüne sahip domain controller öncelikle kendisi ile bağlantı kuran klonlanmış domain controller’ın klonlama için yetkilendirilip yetkilendirilmediğini doğrular. Eğer talepte bulunan domain controller klonlama için yetkilendirilmişse, PDC Emulator bu sunucu için klonlanmış bir domain controller olduğunu gösteren bir bilgisayar hesabı kimliği, SID, isim, ve password bilgilerini oluşturur ve bunları tekrar klona geri gönderir. Klonlanan domain controller active directory veritabanı dosyalarını bir kopya olarak hazırlar ve gerekli sysprep aracına ait bağlantı sağlayıcıları çağırarak sunucunun durum bilgisini temizler. Klonun bu aşamada çağırdığı sysprep bağlantı sağlayıcılayıcı bileşenlerinin listesi Windows\system32 dizini altından alınır.

Klonlama Bileşenleri

DefaultDCCloneAllowList.xml : Bu dosya her Windows Server 2012 domain controller üzerinde %windir%\system32 dizini altında varsayılan olarak gelmektedir. Bu dosya içerisinde varsayılan olarak klonlanan servisler ve yüklü uygulamaların listesi bulunmaktadır. Bu dosyanın konumu ve içeriği değiştirilmemelidir, eğer değişirse klonlama başarısız sonuçlanır.

DCCloneConfig.xml : Bu dosya da varsayılan olarak Windows Server 2012 domain controller üzerinde %windir%\system32 altında bir örnekle gelmektedir. Klonlamanın başarıyla gerçekleşmesi için, bu dosyanın olması gereken konum DIT veritabanının olduğu yerdir. Genellikle bu lokasyon %windir%\NTDS klasörüdür. Klonlamanın tespit edilmesi ve klonlama sürecinin başlatılmasını sağlamasının yanında, bu dosya kullanılarak domain controller sunucusunun adı, ip adresi, site adı, dns ve default gateway gibi ayarlarına ait konfigürasyonlar tanımlanır. Klonlanmış domain controller sunucu konfigürasyonunda kullanılan bu parametreler için gerekli bilgiler bu dosyada belirtilmelidir. Değer belirtilmeyen parametreler active directory tarafından üretilen değerlerle konfigüre edilirler.

DCCloneConfig.xml dosyası için gerekli XML şeması tüm Windows Server 2012 Beta bilgisayarlarda %windir%\system32\DCCloneConfigSchema.xsd içerisinde tanımlıdır.

DCCloneConfig.xml için tüm Windows Server 2012 Beta bilgisayarlarda %windir%\system32\SampleDCCloneConfig.xml adında hazır gelen şablon bir dosya vardır.

CustomDCCloneAllowList.xml : Tüm Windows Server 2012 Beta bilgisayarlarda %windir%\system32\DefaultDCCloneAllowList.xml adında hazır gelen şablon bir dosya vardır. Bu dosyanın bir kopyası alınarak CustomDCCloneAllowList.xml adı ile klonu alınacak mevcut sanal domain controller sunucu üzerinde DIT veritabanının olduğu konumda oluşturulmalıdır. DefaultDCCloneAllowList.xml içerisinde listelenmemiş servisleri ve uygulamaları tespit etmek için Get-ADDCCloningExcludedApplicationList komutu çalıştırılır. Bu komutun çalıştırılması sonrasında gelen çıktıda listelenen bir uygulama ya da servis varsa, bunların klonlamada başarıyla kopyalanabilmesi için CustomDCCloneAllowList.xml dosyası içerisinde belirtmek gerekir. Eğer bu komut sonrasında gelen çıktıdaki servis ya da uygulama güvenilir değilse, kaynak domain controller sunucu üzerinden kaldırılıp, ondan sonra klon kopyası alınmalıdır.

Önemli Not : Kaynak domain controller sanal sunucuyu klonlamadan önce üzerinde çalışan uygulama ve servislerin gerekli lisanslarının olup olmadığının tespit edilmesi gerekir.

CustomDCCloneAllowList.xml dosyasında izin verilen uygulama ya da servisler <Name> ve </Name> tagları arasına yazılmalıdır.

Get-ADDCCloningExcludedApplicationList komutu klonlama süreci öncesinde kaynak domain controller sunucu üzerinde çalıştırılan ve varsayılan DefaultDCCloneAllowList.xml dosyasında tanımlı desteklenen uygulamalar ve servisler listesinde bulunmayan, sunucu üzerindeki servislerin ve uygulamaların listesini verir. Bu PowerShell komutu kaynak domain controller üzerindeki servisler ve yüklü programlar için arama yapar, HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstall altındaki program listesine bakar, varsayılan DefaultDCCloneAllowList.xml ve kullanıcı tanımlı CustomDCCloneAllowList.xml dosyasında tanımlı olmayanları bulur. Gelen çıktı raporunda listelenen uygulama, servis ya da programlar klonlamada sorun teşkil etmeyecekse, CustomDCCloneAllowList.xml dosyası içerisine eklenir. Eğer çıktı raporunda listelenen uygulama, servis ya da programların klonlama desteği yoksa ve klonlamada sorun teşkil edecekse, kaynak domain controller sunucusu üzerinden klon medyası hazırlanmadan önce kaldırılmalı, sonrasında klon kopya oluşturulmalıdır.

Klon Oluşturma Senaryoları 

Sanal Domain Controller Klonlamada desteklenen senaryolar:

·         Kaynak domain controller sunucusunun sanal disk dosyasını (virtual hard disk (VHD ya da VHDX)) kopyalama yöntemi ile klon oluşturmak

·         Hipervizörün export/import yöntemini kullanarak kaynak domain controller sunucusuna ait sanal makinenin kopyasını alarak klon oluşturmak

Öngereksinimler

·         Ortamda mutlaka active directory domain yapısı olmalıdır.

·         PDC Emulator FSMO Rolü Windows Server 2012 Beta domain controller sunucusunda olmalıdır. Bu sunucu fiziksel sunucu olabileceği gibi bir sanal sistemde olabilir. Ve klonlama sürecinde PDC Emulator rolüne sahip domain controller’ın açık ve ulaşılabilir olması gerekir.

Önemli Not : PDC Emulator FSMO rolüne sahip domain controller sunucusu kaynak sunucu olarak kullanılıp, bunu kaynak domain controller olarak kullanarak yapılacak bir klonlama senaryosu desteklenmez. PDC Emulator dışındaki additional domain controller sanal sunucularından alınan klonlamalar desteklenir.

·         Klonlanan domain controller sunucusu açılış sürecinde mutlaka PDC Emulator rolüne sahip domain controller ile iletişim kurabilmesi gerekir.

·         Hyper-V Host Server rolünün Windows Server 2012 Beta işletim sisteminde çalışan fiziksel sunucu olması gerekir.

·         Eğer ortamda birden fazla Hyper-V fiziksel host varsa ve klona kaynaklık yapan domain controller ile klonun kopyasının çalışacağı Hyper-V fiziksel host farklı ise her iki Hyper-V Host’un da aynı domain içerisinde olması gerekir.

·         Eğer ortamda birden fazla Hyper-V fiziksel host varsa ve klona kaynaklık yapan domain controller ile klonun kopyasının çalışacağı Hyper-V fiziksel host farklı ise her iki Hyper-V Host üzerindeki virtual network switch isimleri aynı olmalıdır.

·         Klonlama özelliği için fiziksel Hyper-V host sunucuların domain ortamına dahil edilmiş olması gerekir.

·         Klon kopyasının kaynağını barındıran Hyper-V hostu ile klonun çalışacağı Hyper-V hostlarının işlemci mimarileri birbirinden farklıysa, klon almadan önce kaynak sanal domain controller sunucunun Settings ile ayarlarına girip, sol taraftan Processor bölümüne gelip, Compatibility seçeneğinin seçilip, “Migrate to a physical computer with a different processor version” seçimi yapılmalıdır. Böylece sanal makinenin farklı işlemci mimarisinde çalışan Hyper-V host sunucularda sorunsuz çalışması sağlanmış olur.

·         Bir diğer önemli nokta da normalde domain controller klonlama için bir adet Windows Server 2012 Beta’da çalışan Hyper-V Hosta sahip olmanız yeterlidir.

·         Klonu alınacak kaynak Windows Server 2012 domain controller sunucusu SYSVOL replikasyonu için FRS’den DFS-R’e geçiş yapılmış bir domain controller olmaması gerekir. Bu durumla ilgili Windows Server 2012 Beta üzerinde bilinen bir uyumsuzluktan dolayı klonlanan domain controller’da SYSVOL konfigürasyonunda sorun oluşturmaktadır. Genelde bu senaryo özellikle Windows Server 2003 ya da Windows Server 2003 R2’den Windows Server 2012 Beta geçişi yapılan durumlarda meydana gelebilir.

·         Sadece Windows Server 2012 Beta Hyper-V hostu üzerinde çalışan sanal Windows Server 2012 Beta domain controller sunucularının klonlaması yapılabilir. Windows Server 2012 öncesi işletim sistemlerinde çalışan Hyper-V hostlarında böyle bir uygulama desteklenmemektedir. Benzer şekilde sanalda çalışan ve klonlama yapılacak domain controller sunucusunun işletim sistemi de Windows Server 2012 Beta’da çalışması gerekir.

·         Klonlamada kaynak sunucu olarak kullanılacak Windows Server 2012 domain controller aynı zamanda DNS Server rolüne de sahipse, klonlanan yeni domain controller da aynı zamanda DNS Server rolüne de sahip olacaktır. DNS Client ayarları klonlamaya dahil edilmez, bunun yerine bu ayarlar DCCloneConfig.xml dosyasından alınır. Eğer bu dosya içerisinde de DNS tanımlamaları yoksa, klonlanan domain controller varsayılan olarak kendisini Primary DNS Server adresi olarak konfigüre edecektir.

·         Windows Server 2012 Beta domain controller sunucuları için dolayısıyla VDC için Windows Server 2012 Beta AD DS Schema versiyonu 52 ve Forest Functional Level seviyesi Windows Server 2003 ya da üzeri olmalıdır.

·         ÖNEMLİ : Windows Server 2012 Beta üzerinde PDC emulator rolüne sahip domain controller sunucuyu klon kopya kaynağı olarak kullanılamaz. Doğal olarak burda şu yorumu da yapabiliriz: Tek domain controller sunucunun bulunduğu domainlerde VDC klonlama desteklenmemektedir. Bu durum Windows Server 2012 Beta’nın RC (Release Candidate) ve RTM(ReleaseToManufacturing) versiyonlarında değişip değişmeyeceğini zaman içerisinde göreceğiz.

·         VDC Klonlama ve VM-GenID desteği veren sanallaştırma platform desteği tablosu aşağıdadır:

Kaynak Sanal Domain Controller’ın Klonlama İçin Yetkilendirilmesi

Sanal platformda çalışan bir additional domain controller sunucunun klon kopyasının alınabilmesi için öncelikle active directory içerisinde klonlama için yetkilendirilmesi gerekir. Bunun için Active Directory Users and Computers (ADUC) ya da Active Directory Administrative Center (ADAC) konsollarında Users kabı içerisinde gelen Cloneable Domain Controllers grubuna klonlama yapılacak kaynak domain controller sunucularının bilgisayar hesaplarının üye yapılması yeterlidir.

DCCloneConfig.XML Dosyası

Önemli Not : Bu uygulama için Windows Server 2012 Beta sürümünde IPv6 desteklenmemektedir.

Örnek Dosya:

1.       <?xml version="1.0"?>

2.       <d3c:DCCloneConfig xmlns:d3c="uri:microsoft.com:schemas:DCCloneConfig">

3.       <ComputerName>KlonDC03</ComputerName>

4.       <SiteName>Default-First-Site-Name</SiteName>

5.       <IPSettings>

6.       <IPv4Settings>

7.       <StaticSettings>

8.       <Address>192.168.100.245</Address>

9.       <SubnetMask>255.255.255.0</SubnetMask>

10.   <DefaultGateway></DefaultGateway>

11.   <DNSResolver>192.168.100.252</DNSResolver>

12.   <DNSResolver>127.0.0.1</DNSResolver>

13.   </StaticSettings>

14.   </IPv4Settings>

15.   <IPv6Settings>

16.   <StaticSettings>

17.   <DNSResolver></DNSResolver>

18.   <DNSResolver></DNSResolver>

19.   <DNSResolver></DNSResolver>

20.   <DNSResolver></DNSResolver>

21.   </StaticSettings>

22.   </IPv6Settings>

23.   </IPSettings>

24.   </d3c:DCCloneConfig>

DCCloneConfig.xml dosyası içerisinde dinamik IPv4 ayarları da desteklenir. Bu durumda aşağıdaki dosyada görüldüğü şekilde <IPv4Settings> elementinin altındaki <StaticSettings> elementi yerine <DynamicSettings> elementi kullanılmalıdır.

<?xml version="1.0"?>

<d3c:DCCloneConfig xmlns:d3c="uri:microsoft.com:schemas:DCCloneConfig">

    <ComputerName>KlonDC03</ComputerName>

    <SiteName>Default-First-Site-Name</SiteName>

    <IPSettings>

        <IPv4Settings>

            <DynamicSettings>

                <DNSResolver></DNSResolver>

                <DNSResolver></DNSResolver>

                <DNSResolver></DNSResolver>

                <DNSResolver></DNSResolver>

                <PreferredWINSServer></PreferredWINSServer>

                <AlternateWINSServer></AlternateWINSServer>

            </DynamicSettings>

        </IPv4Settings>

        <IPv6Settings>

            <DynamicSettings>

                <DNSResolver></DNSResolver>

                <DNSResolver></DNSResolver>

                <DNSResolver></DNSResolver>

                <DNSResolver></DNSResolver>

            </DynamicSettings>

        </IPv6Settings>

    </IPSettings>

</d3c:DCCloneConfig>

<IPSettings> elementinin altındaki ayarlar isteğe bağlıdır. Eğer element tagları içerisinde herhangi bir ayar yapılmazsa, klondan oluşturulan yeni domain controller için ağ ortamındaki varsa DHCP sunucudan TCP/IP ayarları otomatik olarak alınır.

DCCloneConfig.xml dosyası içerisindeki alanlar boş bırakılırsa, domain controller sunucunun bilgisayar adı, ağ ayarları gibi konfigürasyon değerleri active directory ve içerisindeki DHCP gibi konfigürasyon sunucuları tarafından sağlanır.

VDC Klonlama Adımları

1.       Klonu alınacak domain controller sunucu üzerinde özelleştirilmiş DcCloneConfig.xml dosyasının oluşturulması.

2.       Kaynak domain controller sunucu üzerinde uyumsuz programların tespit edilmesi.

3.       PDC emulator rolünün Windows Server 2012 Beta üzerinde olduğunu, klon kaynağı olacak domain controller sunucunun PDC rolüne sahip sunucu olmayacağının ve sürekli erişilebilir durumda olduğunun kontrolü.

4.       Kaynak domain controller sunucunun klonlama için yetkilendirilmesi.

5.       Kaynak domain controller sunucunun kapatılması ve diskinin kopyalanması

6.       Kopyalanan diskleri kullanarak klonlanmış yeni sanal sunucu oluşturmak

7.       Kaynak ve klon kopyası domain controller sunucusunu başlatmak ve klonlanan sunucudaki süreçlerin tamamlanmasını beklemek.

8.      Not : Bu süreçlerin gerçekleştirilmesi esnasında Domain Admins grubuna üye olan yetkili bir kullanıcı hesabı ile logon olmanız gerekir. Ayrıca yukarıdaki adımlardan 1-5 arasındakileri klonu alınacak mevcut domain controller üzerinde gerçekleştirmeniz gerekir.

MEVCUT UYGULAMA ORTAMININ TANITILMASI

Aşağıdaki şekilde görüldüğü gibi VDC Klonlama uygulaması için mevcut yapımızda Windows Server 2012 active directory domainine sahibiz. Bu domain içerisinde PDC Emulator FSMO rolü WIN-GNIKS6NNFPG isimli Windows Server 2012 sunucu üzerinde. Yine domain içerisinde WINSRV08 isimli Windows Server 2012 işletim sisteminde çalışan ve üzerinde Hyper-V rolü yüklü sunucumuz mevcut. Ve yine domain yapısı içerisinde WIN-UVQL8S3TMES isimli Windows Server 2012 Hyper-V sanal platformda kurulu bir de additional domain controller sunucumuz var.

PDC EMULATOR ROLÜNE SAHİP WINDOWS SERVER 2012 BETA ÖZELLİKLERİ

Windows Server 2012 Beta (Windows Server “8” Beta) işletim sisteminde çalışan ve PDC Emulator FSMO rolüne sahip domain controller sunucumuzun konfigürasyon bilgileri aşağıdadır:

Sunucu adımız WIN-GNIKS6NNFPG ve cozumpark.local active directory domain adımız.

Sunucunun TCP/IP ayarları da aşağıdadır:

Sunucunun Server Manager konsolunda bir görünümü de yine aşağıdaki şekilde görmektesiniz.

Active Directory Users and Computer konsolunu açıyoruz.

Domain Controllers OU’su içerisinde DC sunucunun bilgisayar hesabını görmektesiniz.

Computers kabı içerisinde de Hyper-V rolünün kurulu olduğu WINSRV08 isimli Windows Server 2012 Beta işletim sisteminde çalışan sunucu ve Additional Domain Controller olarak yapılandıracağımız WIN-UVQL8S3TMES isimli Windows Server 2012 Beta sunucularına ait bilgisayar hesaplarını görmektesiniz.     

Aşağıdaki şekilde de görüldüğü üzere DNS konsolu içerisinde cozumpark.local DNS zone’una ait kayıtlar ve DNS yapısını görmektesiniz.

Sahip olduğumuz active directory domain ve forest functional level seviyesi de Windows Server 8 seviyesinde yani yeni adıyla Windows Server 2012 seviyesinde olduğunu görmektesiniz.

PDC Emulator FSMO rolünün Windows Server 2012 (Windows Server 8) işletim sisteminde çalışan WIN-GNIKS6NNFPG isimli sunucu üzerinde olduğunu kontrol etmek için uygulanan NETDOM QUERY FSMO komutuna ait çıktıyı da aşağıda görmektesiniz.

HYPER-V HOST SERVER UZERINDEKI KONTROLLER

Windows Server 2012 (Windows Server 8) işletim sisteminde çalışan ve cozumpark.local isimli mevcut active directory domain yapısına dahil olan Hyper-V fiziksel hostuna ait gerçekleştirdiğimiz kontrollere ait ekran çıktılarını da yine aşağıda görmektesiniz.

Server Manager konsolundan alınmış ve Hyper-V rolünün kurulu olduğunu gösteren ekran görüntüleri aşağıdadır:

Hyper-V sunucumuzun adı WINSRV08 ve hali hazırda da cozumpark.local isimli active directory domain yapımıza üye yapılmış durumdadır:

WINDOWS SERVER 2012 ADDITIONAL DC SANAL SUNUCU HAZIRLANMASI

Windows Server 2012 (Windows Server 8) PDC Emulator domain controller sunucumuzun yanında klonlamada kullanacağımız ve klon kaynağı olacak olan Windows Server 2012 işletim sisteminde çalışacak additional domain controller sunucumuzun kurulumunu gerçekleştiriyoruz. Bu işlem için öncelikle Windows Server “8” Beta (yeni adıyla Windows Server 2012) işletim sisteminde çalışan Hyper-V hostumuz üzerinde yine Windows Server 2012’de çalışan bir sanal sunucu kurulumu gerçekleştirerek hazırlıyoruz. Bu sunucumuz üzerinde gerekli TCP/IP ayarlarını yaptıktan sonra da bu sunucuyu cozumpark.local isimli mevcut active directory domain yapısı içerisine dahil ediyoruz.

Aşağıda bu sunucumuzun TCP/IP ayarlarını görmektesiniz.

Bu ayarlar sonrasında bu sunucumuzu domaine üye yaptıktan sonra üzerine de additional domain controller olarak yapılandırmak için active directory domain services rolünü kuracağız. Şimdi bu adımları gerçekleştirelim:

Server Manager konsolu içerisinde Manage menüsünden Add Roles and Features linkine tıklayarak kurulum sihirbazını başlatıyoruz.

“Before You Begin” aşamasını Next ile geçiyoruz.

Gelen “Select installation type” ekranında “Role-based or feature-based installation” seçeneği seçili iken Next ile sonraki adıma geçiyoruz.

Gelen “Select destination server” ekranında üzerine active directory domain services rolünü kuracağımız additional domain controller sunucu adını seçtikten sonra Next ile sonraki adıma geçiyoruz.

“Select server roles” ekranında Active Directory Domain Services rolünü seçip, Next ile sonraki adıma geçiyoruz.

Next ile sonraki adıma geçiyoruz. “Select features” ekranında da ilave yüklenecek bir feature olmağı için yine Next ile sonraki adıma geçiyoruz.

Active Directory Domain Services ekranını da yine Next ile geçiyoruz.

“Confirm installation selections” ekranında “Restart” kutucuğunu işaretleyerek kurulum sonrasında sunucumuzun otomatik olarak yeniden başlatılmasını ayarlıyoruz.

“Install” butonuna basarak kurulumu başlatıyoruz.

Kurulum sürecini “Installation progress” ekranında takip edebilir ya da Close ile kapatıp Server Manager konsolunda üst bölümdeki bayrak simgesini kullanarak ilerleme durumuna oradan da ulaşabilirsiniz.

Kurulum tamamlandıktan sonra aşağıdaki şekilde de görüldüğü üzere “Promote this server to a domain controller” adında active directory konfigürasyon link kısayolu gelecektir. Bu kısayol üzerine tıklıyoruz.