Windows Server 2012 - Certification Authority

Windows Server 2012 - Active Directory Installation

Selam,

VAMT ile merkezi olarak tüm lisanslarınızı kontrol edebilir ve/veya  güncelleyebiliriz. Bunun için önce sunucu tarafında tüm clientları etkileyen bir GPO yapıp (Default Domain Policy),  49154 portunu açmamız gerekir. Tabiki ardından bir kereye mahsus clientlarda gpupdate yapılmalı, yada clientlar restart edilmelidir. Sonrasında bu port üzerinden VAMT server (herhangi bir bilgisayara kurulabilir), sistemde sizin belirlediğiniz bir user ile (domainde ise domain user yada admin olabilir) tüm makinelere bağlanıp size aktivasyon bilgilerini getirir. Ve biz de isteğe göre bunlara keyler ekleyerek tüm bilgisayarları tek bir noktadan aktive edebiliriz. Bu tool’u indirmek için google’ da volume activation management tool yazmanız lazım.

Nasıl Yapılır ?

Volume Activation Management Tool

Merhaba,

Bu yazımda sizlere, uzunca bir süre önce üstünkörü çektiğim bir videoyu detaylıca anlatacağım. Makalenin sonunda da iki bölümden oluşan ve baştan sona eksiksiz videoyu bulabilirsiniz. Office yüklemeleri özellikle kalabalık networklerde tek tek yapmaktan sıkıldığımız, yorucu bir iştir. Ve bunu merkezden yapmak genelde GPO (group policy objects) tarafında software installation ile olur. Bu yazıda bir office networke merkezden nasıl tam olarak dağıtılır bunu yazdım. Gereksinimlerimiz ;

* Volumce License versiyon Office 2010

- Bir office uygulamasının VL versiyon olduğunu nasıl anlarsınız, zaten siz satın aldığınız için bilmeniz lazım ama bilmiyorsanız da kurulum folderları içerisinde Admin folderı varsa, bilin ki elinizdeki versiyon VL versiyondur. Bu neden mi önemli? Çünkü diğer sürümler GPO ile deploy edilmeye yani uzaktan kuruluma uygun değiller. Çoğu zaman yapılan hatadır. Box lisansları merkezden kurmaya boşuna uğraşmayın.

* Microsoft’un verdiği startup script. Makalenin sonunda linkini vereceğim.

Aslında bu kadarı yeterli ama, wmi filter dediğimiz olayı da ben aksiyon olsun diye ekledim. Çünkü ortamda hem 32bit hem de 64bit bilgisayarlar olduğunu düşünmek lazım. WMI filter, bize policy oluştururken bazı özelleştirmeler yapabilmemizi sağlıyor. Mesela işletim sistemi versiyon numarası, işlemci addresswidth’i gibi. 32 ve 64 bit ‘e ayrı ayrı dağıtım yapmak istiyorsak bize iki ayrı policy gerekiyor hem 32 hem 64 için. WMI filter burda devreye girerek işlemcinin AddressWidth’ ini bize söylüyor. Policy’ de, biz hazırladığımız WMI filter’i yaptığımız policy’e gömüyoruz.

32 bit için WMI Filter cümlesi : SELECT * FROM Win32_Processor where AddressWidth = “32″

64 bit için WMI Filter cümlesi : SELECT * FROM Win32_Processor where AddressWidth = “64″

Bu cümleyi bize veren tool için download linki –> WMI CODE CREATOR

Cümlede geçen where kelimesi ve  AddressWidth = “32″ ibareleri bize şunu söyler : işlemcinin address uzunluğu 32 bit ise, 64 bit ise .

Bu cümleyi kurduğumuz için WMI filter ile bütünleştirdiğimiz policy’ler, işlemcisine göre dağılır ve gereksiz setup’ları tüm makinelere göndermemiş oluruz. WMI Filter kullanmazsak, 32 yada 64 bit ayrımı olmadan tek setup bütün makinelere gidecekti. Ben bunu istememiştim.

Bir de kurulumun başında oluşturulan office ve officelog klasörleri var. Bunlar paylaşıma açık, office klasöründe everyone için Read, officelog klasöründe de everyone için read & write yetkisi var. Office adlı klasörde everyone için read yetkisini client makinelerin gelip o klasörden dosyayı okumaları ve kendilerine çekmeleri için veriyoruz, bu sebeple ayrıca write vermeye gerek kalmıyor. Officelog  klasöründe ise, kurulum sırasında bilgisayarlar oraya gelip office bana kuruldu, yada kurulmadı gibi bir text dosya oluşturacaklarından, read ve write yetkisini birlikte veriyoruz. Yoksa kurulumla ilgili bir log yazılmaz. Log tutmak zorunda değiliz aslında ama, çoklu kurulumlarda hangi bilgisayara kuruldu yada kurulmadı gibi bir takip yapmak istiyorsak çok faydalı olabilir. Bunları da hazırladık. Sıra geldi startup scriptindeki parametrelere.

Script’teki cümlelerde değiştirdiğimiz yerlere göz atalım :

set DeployServer = \\Server Adı\office\x64 yada x86. Burada server adı bölümüne office klasörünü paylaştırdığımız serverı veriyoruz. Sonrasındaki path ise Admin folderının durduğu klasör olmak zorunda. Çünkü setup oradan çalışıyor. VL lisans office kurulumunda, en dışarıda da bir setup.exe var ama bizim onunla işimiz yok. Clientlar Admin folderının bulunduğu yerdeki setup.exe’ yi çalıştıracak.

Set ConfigFile = \\Server\office\x64\ProPlus.WW\config.xml

Burdaki path, config.xml ‘den git parametreleri çek diyor. Yani aslında Office customization tool ile yaptıklarımızın hepsi, config.xml ‘in içerisindeki cümlelerde de mevcut. Customization tool içerisinde değiştirilen ayarların anlamları :

Bu ayarları .msp olarak kaydedip kurulum dosyamızı hazırladık. Script bu ayarlara göre şunu yapar ;

reg query HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\%ProductName%
if %errorlevel%==1 (goto DeployOffice) else (goto End)

Önce client makinede, yukarıdaki registry path’i kontrol eder, eğer office bu dizinde varsa kurulumu başlatmadan bitirir ( Scriptin sonundaki goto End).

REM If 1 returned, the product was not found. Run setup here.
:  DeployOffice
start /wait %DeployServer%\setup.exe /config %ConfigFile%
echo %date% %time% Setup ended with error code %errorlevel%. >> %LogLocation%\%computername%.txt

REM ile başlayan komut ile şunu anlıyoruz ; git registry path’i kontrol et, path boş ise yani office kurulu değilse, start /wait %DeployServer%\setup.exe ‘yi çalıştır ve kurulumu başlat. Sonra da echo date, time, mesaj (setup ended… ) log yerine git bilgisayar adıyla log yaz.

Sonrasında kurulum biter. Peki biz, office customization toolda bu ayarları yaptıktan sonra bir de gidip config.xml ‘de ayarlamalar yapsaydık (config.xml dosyasında customization tool içerisindeki ayarların metine dökülmüş halleri vardır.) ne olurdu?

Cevap : config.xml dosyasına yazılanlar, msp dosyalarımızdaki konfigürasyonları ezerdi. Yani config.xml ‘ de ne belirttiysek o geçerli oluyor. Bu sebeple msp dosyası ile kurulum yapacaksak, config.xml ‘e pek dokunmuyoruz.

Group Policy Ayarları

GP Management Console’ u açtık, WMI filtrelerini yukarıda anlattığım şekilde 32 bit ve 64 bit için oluşturacağız. Tabiki uygun cümleleri kurarak. Policy yapmadan önce bilgisayarları OU’lara taşımamız lazım. Ve yine policyleri yaparken computer configuration ‘dan yapmamız gerekiyor. Çünkü biz, user bağımsız hareket etmek istiyoruz. O bilgisayara kim otutursa otursun, hangi kullanıcı ile oturum açarsa açsın office kurulsun diyoruz. GPO ‘ da yapmamız gereken ilk değişiklik ;

Maximum wait time for Group Policy script  : Default = 600 sn.

Bu şu demek, eğer kurulum 10 dk ‘ dan fazla sürerse script çalışmayacak. Biz bunu garanti altına almak için GPO ‘ da bu değeri sıfır (0) yaptık.

Sonra Scripts menüsüne geldik ve ilgili scriptimizi ekledik. Dikkat edilmesi gereken nokta şu ; script eklerken defaultta browse yapınca, \\sysvol klasörünnü altındaki policy klasörü gelir. Fakat biz, startup scriptini bat olarak herhangi bir yere kaydetmiş olabiliriz. Browse yaptıktan sonra o herhangi bir yerden scripti oraya koyarsak policy çalışmaz. Çünkü bir client,  serverdan policy alırken SYSVOL klasörünün altındaki klasörlere girer. Siz desktop’a kaydedip oradan browse ile script eklerseniz, her şeyi doğru yaptım ama niye çalışmadı diye düşünürsünüz. Bizler windows kullanmayı bilen adamlar olarak, scripti nereye attıysak, oradan SYSVOL klasörünün altındaki ilgili yere (Browse ettiğinizde direkt o klasör açılacak) paste (yapıştır) edebiliriz. Her iki ayrı policy için de bu ayarları yaptıktan sonra artık gpupdate diyebiliriz. Son olarak ufak üç beş not :

* Clientların DNS ‘te kaydı bulunmalı ve isim çözümlemesi doğru çalışmalı

* Clientlar serverdaki SYSVOL klasörüne ulaşabilmeli

* Kurulum için Admin yetkisine gerek yok

START UP SCRIPT –> http://technet.microsoft.com/en-us/library/ff602181.aspx / (sayfayı aşağı çekin)

Videolar Bölüm 1

Office 2010 Deploy with Group Policy - 1

 Bölüm 2

Office 2010 Deploy with Group Policy - 2

Windows 8 DHCP Failover

Multi PfSense Failover (CARP)

ARCServe D2D Kurulum & Backup

ARCServe Mailbox Backup Restore

PFSense 2.0 - Dual WAN Failover Yapılandırma

IPSec RDP (IPSec ile Remote Desktop)