Saatlerdir süren testler sonrası, bir türlü VMM üzerinde Sysprep yapamamış bulunmaktayım. Sorunu bir türlü çözebilmiş değilim ne yazık ki. Umarım sizde aynı sorun meydana gelmez. Normalde template oluşturma işlemi çok basit bir işlem olmasına rağmen, template’ten vds oluşturma işi işkenceye dönüşebiliyor. Fakat genel olarak neler yapılması gerektiğini anlatmak istiyorum.

Öncelikle source makinanın Administrator şifresi, mutlaka boş olmalı. Yani hiç bir şifre girmemeniz gerekiyor. Böylece sysreping adımında, VMM’in gerekli ayarlamaları yapabildiği söyleniyor. Gerçi benim yaptığım testlerde, bu şifre boş olsa bile bu adımda takılmış durumdayım.

Bunun dışında, makina üzerine virtual guest services’i kurmanız gerekli. Zaten VMM üzerinde, sunucuya sağ tıklayıp, “install virtual guest services” diyerek, kolay bir şekilde kurulum yapabiliyoruz.

Bu işlemlerden sonra makinanın üzerine sağ tıklayıp, “New Template” demeniz gerekiyor. Birkaç adım daha atladıktan sonra en önemli adıma geçiyoruz, yani sysrep adımı. Burada VMM sizden sunucu adı, product key, admin password gibi bilgiler talep ediyor. Fakat girseniz de anlayamadığım bir şekilde vds oluşturamıyorsunuz. Fakat bunu da şu şekilde aşabilirsiniz. Windows Server ürününü, öncelikle kendi içersinde sysrep’leyip daha sonra aşağıdaki gibi “gerekli değil” diyebilirsiniz.

Böylece sanal sunucunun deployment işlemi gerçekleştirilirken, VMM sysprep yapmıyor ve bu adımı atlıyor. Tabi siz, işletim sistemi içinden sysprep yaptığınız için, herhangi bir sıkıntı oluşmuyor. VMM sysprep neden çalışmıyor bilmiyorum fakat çözümü bulur bulmaz buraya ekleyeceğim. Ben bulana kadar siz aynı sorunu yaşarsanız, yukarda anlatmış olduğum çözüm, sizi bir süre idare edecektir. İyi çalışmalar hepinize..

Sonunda beklenen Service Pack geldi. Bildiğiniz gibi Windows Server 2008 üzerinde Exchange Server yedekleri alınamıyordu. Bu sorunu ya farklı yedekleme çözümleri kullanarak ya da küçük hackler yardımıyla yapabiliyorduk. Fakat bir felaket durumunda bunlar ne kadar işe yarardı acaba? Sonuçta önemli olan yedek almak değil, zaten yedeği bir şekilde alabiliyorsunuz, fakat önemli olan bir felaket senaryosunda bu yedekten ne kadar hızlı ve doğru geri dönebildiğinizdir. İşte burada güven veren bir yazılım ile çalışmak sistem yöneticileri için önemli olacaktır.

Her ne kadar DPM yani Data Protection Manager ile Exchange Mail Database’lerini yedekleyebiliyor olsakta, System State yedeği alamıyorduk. Bu da beni hep tedirgin ederdi. “Ya exchange database’i değil de tüm sunucu çökerse?”. İşte SP1 öncesinde böyle bir durumda yapmanız gereken ceketinizi alıp çıkmak olacaktı. Fakat SP1 ile birlikte artık System State yedeği alabiliyoruz. System State yedeğini almaya çalışırken biraz zorlandığımı kabul etmeliyim. Çünkü senkronizasyon sorunları yaşanıyor ve düzgün olarak system state yedeği alamıyorsunuz. Fakat bunu da çözmenin yolu var. Bu makale ile ilgisi olmadığı için yazmıyorum fakat ilerki makalelerimde mutlaka göreceksiniz.

SP1 ile gelen bir diğer yenilik ise artık Hyper-V’nin de DPM’in kanatları altında olmasıdır. Bunun dışında DPM’de bir çok iyileştirme yapılmış durumda. Yalnız belirtmeden geçmek istemiyorum, DPM SP1 kurduktan sonra mutlaka Agent update yapmanız gerekmekte. Çünkü SP1 ile DPM server üzerindeki Agent dosyaları değişiyor. Sizin bu dosyaları, korunan sunuculara yüklemeniz lazım. Yalnız update sonrası restart istiyor. Yani önemli sunucularınız varsa, bu update işlemini gece yapmanızı tavsiye ederim.

DPM 2007 Service Pack 1 için Microsoft Download Center bağlantısı aşağıdadır:

Umarım sorunsuz bir şekilde yapınızı güncelleyebilirsiniz. İyi çalışmalar..

VMM kurulumunu tamamlandınız, HyperV sunucunuzu VMM’e eklediniz. Fakat bir baktınız, host üzerinde bir ünlem işareti var. “Need attention” şeklinde uyarı veriyordu sanırım. Bu durum, HyperV’deki bazı update’lerin eksik olmasından kaynaklanıyor. Microsoft update ile çıkmadığı için elle bu updateleri yüklemeniz gerekli. VMM kurduktan sonra, aşağıdaki iki update’i yapmanız gerekiyor. Microsoft update ile cıkmıyor ne yazık ki.

Hyper-V Update for Windows Server 2008 x64 Edition (KB956589)
Install this update to resolve potential issues when you manage Hyper-V with System Center Virtual Machine Manager (SCVMM).

Update for Windows Server 2008 x64 Edition (KB956774)
Install this update to resolve the scenario where a Background Intelligent Transfer Service (BITS) client cannot handle files that have paths that contain the volume GUID in Windows Server 2008.

Önemli bir adım aslında VMM ayarlamasında. Fakat VMM kuralı uzun bir zaman olduğu için bu makaleyi eklemek sonradan aklıma geldi.

Aslında güncelleme çıkalı uzun bir süre oldu sayılır. Eğer hala güncellemenizi yapmadıysanız bağlantıyı aşağıda vereceğim. Rollup 5 ile ciddi sorunları çözebileceğimizi umuyorum. Özellikle Microsoft’un açıklamasında düzeltilen bazı problemler gözüme çarptı.

Update için Microsoft Download Center bağlantısı aşağıda:

Update için Microsoft açıklamalarını aşağıdaki bağlantıda görebilirsiniz:

Bu arada, mümkün olduğunca bu tür güncellemeleri manual olarak yapmanızı tavsiye ederim. Microsoft update üzerinden yapılan Exchange Rollup Update’lerinin tamamında Exchange çakılmaları yaşamış durumdayız. Özellikle kurulum sonralarına doğru sunucunun mavi ekran vermesi sonrası OWA bile uçabiliyor. Bu yüzden rollup gibi önemli updateleri manual olarak yapmanızı önermekteyim. Sayın Steve Balmer ne düşünür bu konuda bilemiyorum. Hep Microsoft öneride bulunacak değil ya?

Bir kaç hafta önce çok ilginç bir sorun keşfettik Can ile. Hyper-V rolüne sahip makinalardan birine, USB Cdrom takılacak olursa VMM ile Hyper-V arasında iletişim problemi oluyor. VMM’den alınan yanıt, “kalp atışı yok” şeklinde oluyor. USB Cdrom’u söktükten sonra iletişim probleminin çözüldüğünü görüyorsunuz. Evet size saçma geliyor olabilir fakat bu Technet forumu üzerinde de onaylanmış bir problem. Henüz bir çözüm ürettiler mi bilmiyorum fakat ben bu durum için bir teori üretmiş durumdayım. Söyle ki, biz HyperV sunucularını VMM üzerine eklerken, belli donanım bileşenleri ile birlikte kayıt ediyoruz. Zaten VMM üzerinde bu bilgileri görebilirsiniz.

Yukardaki imajdan görebileceğiniz üzere, VMM aslında tüm hostların donanımsal bilgilerini kayıt altında tutuyor. Resimde görüldüğü gibi sunucuda herhangi bir dvdrom vs. takılı değil. Zaten Slim USB Dvdrom’ların çıktığı bu yüzyılda, ide/sata cdrom kullanmak mantıksız olurdu. Peki biz ne yapıyoruz? VMM ve Hyper-V iletişim kurarken, Hyper-V’ye usb cdrom takıyoruz, yani Hyper-V’de bir donanım değişikliği yapıyoruz. VMM’de bu donanım değişikliği nedeniyle, yeni değişiklikleri kendine almaya çalışıyor. Belki de Hyper-V açıkken donanım değişikliği olamayacağını düşünüp, çakılıyor da olabilir. Fakat bana mantıklı gelen tek fikir bu oldu. Yoksa usb cdrom’un iletişim bozması nasıl mümkün olabilir sizce? Bu hata muhtemelen birilerinin daha başına gelecektir :)

Aşağıda yer alan belgelerden, faaliyet alanınıza uygun olan bir tanesinin Nic.tr (“.tr” Alan Adları) Yönetimi’ne iletilmesi yeterli olacaktır.

Yukardaki belgeler, “.net.tr” uzantısı için geçerli. Vakit buldukça diğer alan adları için gerekli olan belgeleri de paylaşacağım.

Geçen hafta bir müşterimiz, Cpanel ile ilgili sıkıntı çekiyordu. Bazı Cpanel dosyaları eksikti ve bazı servisler düzgün olarak çalışmıyordu. Cpanel clean install istese de, fix etmek için size pratik bir çözüm sunuyorlar. Cpanel ile ilgili sıkıntılarınız var ise aşağıdaki yolu deneyebilirsiniz.

Öncelikle SSH üzerinden ‘root’ olarak giriş yapın. SSH’a oturum açtıktan sonra, aşağıdaki komutları sırasıyla girin.

1
2
3
4

cd /scripts
./updatenow
./upcp --force
./fixeverything

Sunucu gücüne göre 10 dakika ila 30 dakika arası bir süre sonra Cpanel’iniz tamir edilmiş olacaktır. Daha sonra WHM üzerinden giriş yaparak, down görünen servisleri, aktif hale getirebilirsiniz. Servislerin kırmızıdan yeşile dönmesi, restart süresine göre 10 dakika bulabilir.

Servisleriniz, restart’tan sonra hala kırmızı olarak görünüyorsa, elle servis kontrolü yapmanız faydalı olacaktır. Bunun için aşağıdaki komutu çalıştırmalısınız.

1

/etc/init.d/chkservd start

Anlaşılacağı üzere Cpanel servisleri, yukardaki komutun belirli periyodlarla çalıştırmasıyla kontrol edebiliyor. Yani bir servisi sizin kırmızı görmeniz, aslında o anda o servisin çalışmadığı anlamına gelmemesi lazım. Doğal olarak WHM üzerindeki servis sayfasının %100 doğru olacağı gibi bir garanti yok. Kolay gelsin..