home
projects
about
contact
follow
feed
settings
Categories
Sponsors
Archive
 Blogroll
Badges
Community
|
Posted in Virtual Machine Manager | No Comment | 3,644 views | 29/08/2009 12:59
Bir kaç gün önce System Center Virtual Machine Manager 2008 R2 çıktı ve artık indirilebilir durumda. Daha çok kısa bir süre önce Hyper-V R2’nin RTM olması üzerine SCVMM 2008 R2’nin RTM olması çok sevindirici bir gelişme. Tabi bizim için uykusuz geceler tekrar başlıyor. Tüm yapıyı R2’ye yükseltmek biraz zaman alacak ve bu işlemleri kesintileri en aza indirgeyerek yapabilmek için gece yapmamız gerekiyor. SCVMM 2008 R2 ve Hyper-V R2 ile birlikte gelen yeni özellikleri aşağıdaki bağlantıdan inceleyebilirsiniz: Bu arada hala MSDN üzerinde mevcut değil SCVMM 2008 R2. Umarım en kısa zamanda MSDN üzerinden indirme şansına sahip oluruz.
Posted in Windows Server | No Comment | 5,589 views | 29/08/2009 03:54
Bugün bir müşterimiz ile görüşürken, böyle bir geri bildirim aldım. Hyper-V’nin Snapshot özelliğinin kullanılmasının ilerde sorunlara yol açtığı söyleniyormuş. Yaklaşık 1 yıldır Hyper-V üzerinden bu işi yapıyoruz ve Snapshot yüzünden kötü bir tecrübe yaşamadık. Aslında insanlarda, Snapshot’la ilgili yanlış bir düşünce var. Snapshot’lar daha çok yedekleme mantığıyla alınıyor ki bu çok yanlış. Hyper-V üzerindeki bir makinanın Snapshot’ını almamız halinde karşılaşabileceğimiz olumsuz durumları kısaca anlatmak gerekirse;
1) Snapshot’lar, farklı bir lokasyonda, farklı bir AVHD dosyası üzerinde tutulmaya başlarlar. Siz sunucunuzu kullandıkça bu Snapshot dosyaları şişer ve iki farklı VHD üzerinden çalıştığınız için sunucudan alacağınız performans düşmeye başlar. Eğer sunucu diskini “Dynamically Expanding” olarak oluşturduysanız, performans kayıplarını pek hissetmeyebilirsiniz. Fakat “Fixed Size” olarak oluşturulmuş disklerde, ciddi performans kayıpları olduğunu göreceksiniz.
2) Snapshot’ı alınan sanal sunucuları, Cluster yapılarında kullanamazsınız. Cluster yapılan bir sanal sunucunun, snapshot’ı alınması halinde, Node’lar arasındaki geçişler sırasında makinanın network ayarlarında sorunlar meydana gelmektedir. 3) Snapshot’ı alınan makina, daha fazla disk alanı kullanmaya başlayacaktır. Çünkü farklı Snapshot state’lerine bağlı olarak farklı AVHD dosyaları oluşturulacak ve dosyalarınız bu AVHD dosyalarında saklanmaya başlanacaktır. 4) Fiziksel bir disk sürücüsü bağlı olan sanal sunucularınızın Snapshot’ını alamazsınız. 5) En önemli olumsuzluklardan bir tanesi de silinen Snapshot sonrası sanal sunucu üzerinde Merge işleminin gerçekleşmesinin gerekmesidir. Merge işlemi sırasında makinanın bir süre kapalı kalması gerekir. Merge işlemi sırasında eski AVHD dosyası ile VHD dosyası merge edilmeye başlanır. Merge süresi ne kadar uzun olursa, sanal sunucunuz da o kadar kapalı kalacak demektir. 6) Snapshot’ı olan bir sanal sunucuyu silmeniz, normal sunuculara göre daha uzun sürmektedir. Nedeni ise silme işlemine önce Snapshot’lardan başlanmasıdır. Tüm Snapshot’lar önce teker teker silinir, merge işlemi gerçekleşir ve sonrasında ana sunucu silinir. Peki Snapshot’ların bu kadar olumsuz tarafı varken neden tercih nedeni olsunlar? Tecrübelerimi paylaşmaya devam edeyim: 1) Öncelikle Snapshot’ları asla yedekleme aracı olarak görmeyin. Snapshot’lar daha çok yapacağınız riskli bir iş öncesi kullanabileceğiniz hayat sigortası gibi bir şey olsun. Yeni çıkan bir Windows Update öncesi Snapshot alarak, doğabilecek sistem sorunlarının önüne geçebilirsiniz. Yalnız yapacağınız iş, Active Directory DC’leri üzerinde ise Snapshot’ın restore için fayda sağlayamayabileceğini unutmayın.
2) Sunucu üzerinde çok önemli ayarlar yaptınız. Bu ayarlarda bir problem olması halinde, sunucunuzun ilk günkü konumuna geri dönebilmesini istiyorsuz. İşte burada da Snapshot kullanılabilir. Fresh bir kurulum sonrası Snapshot alabilirsiniz. Fakat Fresh kurulumun Snapshot’ını almak yerine, komple VHD dosyasını yedeklemek, daha yararlı bir yöntem olacaktır. 3) Eğer sunucu diski “Dynamically Expanding” ise ve herhangi bir cluster yapısı kurmayı düşünmüyorsanız, sunucunuza ait Restore point’ler almanız sorun çıkarmayacaktır. Diskiniz üzerinde yer kaplayan AVHD dosyalarının, Snapshot için kullanıldığını bilin ve bunları silmemeye dikkat edin. Bu dosyaları silmeniz halinde, büyük bir veri kaybı yaşayıp restore point’i aldığınız konuma geri döneceğinizi hatırlayın.
Bununla birlikte asla yapmamanız ya da çok dikkat etmeniz gereken durumlar: 1) Snapshot sildikten sonra mutlaka disklerin Merge edilmesini sağlayın.
2) Snapshot’ı alınmış bir sanal sunucunun diskini asla Expand etmeyin! Disk büyütme işlemini gerçekleştirebilmeniz için tüm Snapshot state’lerini silmeniz ve ana sunucuyu kapatarak, Merge işlemini gerçekleştirmeniz gerekmektedir. 3) AVHD dosyalarını asla silmeye çalışmayın. Bazı dosyaların silinmesi, tüm Snapshot’lara erişmenizi engelleyebilir.
Bu arada Snapshot’ı alınmış sanal sunucuları, ilk Snapshot’ına döndürüp, ondan sonra silerseniz, VM silme işleminin daha hızlı gerçekleştiğini göreceksiniz. Bu da benden ufak bir ipucu olsun.
Posted in Windows Server | No Comment | 5,375 views | 28/08/2009 11:40
DNS içersindeki _msdcs kayıtları, Active Directory Service kayıtlarının tüm Forest içersinde replike olmasını sağladığını bir önceki yazımda anlatmıştım. Fakat bazen _msdcs kaydı hatalı olabilir ya da yanlışlıkla silmiş olabilirsiniz. Peki bu durumda _msdcs kayıtlarınızı eski haline nasıl getirebilirsiniz? Öncelikle Start -> Run -> Services.msc diyip, Netlogon servisini Stop edin. Sonrasında tekrar Start diyerek, Netlogon servisini çalıştırın. Bu işlem sonrasında yeniden çalışan Netlogon servisinin, DNS içersindeki _msdcs kaydını tamir etmesi lazım. Netlogon servisinin restart edilmesi sonrası hala bu kayıtlar geri gelmemiş ise aşağıdaki KB’ye göz atmanız gerekiyor: Yukarda bağlantı adresini vermiş olduğum KB ile _msdcs’nin nasıl manual olarak yaratılabileceğini görebilirsiniz.
Posted in Windows Server | No Comment | 6,226 views | 28/08/2009 11:21
Active Directory Partition: Domain partition, Domain ile ilgili user ve computer hesapları gibi bilgileri içerir. Replikasyon domain dc’lerine olur. Configuration Partition: Forest yapısı, foresttaki domain yapısı, foresttaki dc’ler, DC’ler replikasyonu kimlerle yapıyor gibi tüm forestça bilinmesi gereken bilgileri içerir. Forest çapında replike edilir. Schema Partition: Yedek parça havuzu. Objeler oluşturulurken buradaki attributelar birleştirilerek obje oluşturulur. Obje oluşturulurken hangi attributeların kullanılacağı object class’ında belirlenmiştir. Bu da forest çapında replike edilir. Active Directory Application Directory Partition: Normalde database doğasında olmayan ama uyguluma destekliyorsa (DNS gibi) uygulama kendine ait datayı ad database’inde tutabiliyorsa, application directory’dir. DNS’lerde _msdcs.domain.com olarak tutulur ve service kayıtlarının tüm Active Directory DC’lerinde replike olmasını sağlar ve böylece High Available durumda olur. KCC = Knowledge consistency checker. Bu service her DC’de çalışır ve 15 dakikada bir DC’nin diğer yapılarla görüşmesini check eder. DC’nin kimlerle replikasyonu gireceğini belirler. Replication sorununuz varsa, makinaların sağlıklı bir şekilde ayakta olduğundan eminseniz, DNS’i ve DNS’teki makinalara ilişkin kayıtları, delegasyon kayıtlarını ve forwarder’ları kontrol edin. Cache’leri boşaltın, tekrar elle topology’i check ettirin. GRUPLAR
Global Group ROOTDC’de iki tane group GL_Sec DL_Sec Universal Group Domain LOCAL group Aynı haklara ve aynı ihtiyaçlara sahip objeleri Global gruplar altında toplamak gerekir: MUHASEBE_GL
FINANS_GL IK_GL DOMAIN LOCAL: Kaynaklarda hak sahibi yapacağınız gruplardır. Domain local
GLOBAL Universal Group: Her yerden gözükür. GLOBAL Group: Her yerden gözükür. Global Katalog: Forest çağındaki objelerin nerelerde olduklarını, o objelere erişmek nerelere danışmak gerektiğini bilir. Serach işlemleri için kullanılır. Universal grupların üyelerinin kimler olduğunu sadece global katalog bilir. Mümkün olduğunca Universal Group kullanmayın. Sadece önemli hesapları universal group altında toplayın ve üyelikleri ile çok oynamayın. 2003 functional level kullanmıyorsanız replikasyon full olarak gerçekleşir.
Posted in Exchange Server, Windows Powershell | No Comment | 6,018 views | 26/08/2009 19:31
You can get message tracking logs of Exchange Server 2007 with Powershell:
You can change Result Size with changing -ResultSize parameter.
Posted in Exchange Server | 2 Comments | 8,295 views | 23/08/2009 16:15
Şirket dışından Outlook ile Exchange Server’a bağlanmaya çalıştığınızda, kullanılmakta olan sertifikanın sadece Active Directory yapısı içersinde güvenilir olması nedeniyle SSL bazlı hatalar alırsınız. Bu hatalar, Outlook’un geç bağlanmasına, yavaş çalışmasına hatta bağlantı kopmalarına neden olur. Şimdi Exchange Server 2007 için SSL yapılandırmasının nasıl olması gerektiğine bakalım. Öncelikle external network’ten erişim sağlayan kullanıcıların tarayıcılarının sorunsuzca tanıyabileceği bir güvenlik sertifikası edinmemiz gerekiyor. Güvenlik sertifikanızı, çok uygun bir fiyata, Radore Hosting’den temin edebilirsiniz. Yıllık 29$ + KDV’ye satılan AlphaSSL sertifikaları, GlobalSign güvencesinde olup, tarayıcılar üzerinde sorunsuz çalışmaktadır. Satın alma sayfasına aşağıdaki bağlantıdan ulaşabilirsiniz: Güvenlik sertifikamızı satın alabilmemiz için öncelikle Exchange Server üzerinden CSR kodumuzu oluşturmalıyız. CSR kodunu oluşturabilmek için Exchange Management Shell’i açmamız gerekiyor. Exchange Management Shell’i, Başlat menüsü altından çalıştırabilirsiniz.
Exchange Management Shell açıldıktan sonra aşağıdaki Powershell komutu ile SSL başvurusu yapmamız gerekiyor.
AlphaSSL’den satın alacağımız için sertifika başvurusuna SAN’ları eklemedim. Sertifikalardaki SAN’ın açılımı, Subject Alternative Names olup, farklı subdomain’ler için de sertifikanızın geçerli olmasını sağlamaktır. Örneğin http://rh.com.tr için yapılan bir SSL başvurusunda, http://www.rh.com.tr adresine giden ziyaretçilerin SSL hatası almaması için www.rh.com.tr adresi SAN olarak sertifika başvurusuna eklenmelidir. Eğer Active Directory üzerinde kurulu bir sertifika sunucusundan sertifikanızı basacaksanız, SAN isimlerini de ekleyerek, SSL başvurunuzu yapabilirsiniz. Aşağıdaki bağlantıdan, Exchange Server için hızlı bir şekilde sertifika başvurusu oluşturmanız mümkün. Yalnız biz External Network’teki kullanıcıların sorunsuz erişimini sağlamaya çalıştığımız için SAN ile ilgilenmiyoruz. Bu yüzden yukarda vermiş olduğum “New-ExchangeCertificate” komutunu kullanarak sertifika başvurunuzu yapmanız yeterli olacaktır. Komutu çalıştırmanız sonrasında “C:\Exchange.csr” içersinde, sertifika başvurunuzu yapabilmeniz için gereken CSR kodlarını bulabilirsiniz. Bu CSR kodları ile Radore Hosting üzerinden SSL başvurunuzu yapmanız gerekiyor. SSL başvurunuzu tamamladığınızda email adresinize onay maili gönderilecek. Bu maili onayladıktan sonra Radore’den tarafınıza sertifika dosyanızın ulaştırılmış olması gerekiyor. Size gönderilmiş olan mail içersindeki “CERT (PKCS7)” kodlarını, bir txt içersine atıp, dosyanın adını “Exchange.p7b” yaparak, C:\ içersine kaydedin. Şimdi Exchange Management Shell’e giderek, SSL başvurusunu tamamlayabiliriz.
Yukardaki komutu çalıştırdığınızda hata almıyorsanız, sertifikanın yüklenmesi tamamlanmış anlamına gelmektedir. Sertifikanın import edilmesi sonrası Servis hatası alıyorsanız, IMAP, POP, UM, IIS ya da SMTP servislerinden bir tanesini kullanmadığınız anlamına gelir. Herhangi bir şey yapmanıza gerek kalmadan kalan işlemlere devam edebilirsiniz. Aşağıdaki komutları, External URL’nize göre düzenleyerek, Exchange Management Shell üzerinden çalıştırın.
Şimdi Exchange Management Console’u açalım ve satın almış olduğumuz SSL’e ait CN’e uygun olarak, External URL’leri ayarlamaya devam edelim. Server Configuration altında bulunan Client Access menüsüne geçiş yapalım.
Ekran görüntüsünde görebileceğiniz gibi External URL ile Internal URL’yi aynı yaptım. Çünkü iç yapıda da External URL’yi kullanmaya devam ediyoruz. OAB’nın URL’sini ayarladıktan sonra aynı işlemleri OWA ve ActiveSync üzerinde de yaparak, URL işlemlerini tamamlıyoruz. Şimdi sıra Autodiscover sorununu çözmeye geldi. Autodiscover, IIS’te Default Web Site isimli sitenin altında bulunmakta. Default Web Site’a sadece tek sertifika tanımlayabildiğiniz için farklı alan adları ile Outlook üzerinden giriş yapmaya çalıştığınızda SSL sertifikası sorunu yaşamanız normal bir durum. Bu yüzden yeni bir Autodiscover sitesi yaratıp, farklı alan adlarının buraya düşmesini sağlayacağız. Bu site de gelen her bağlantıyı, URL redirect ile SSL’i tanımladığımız sayfaya yönlendirecek. Böylece Outlook, URL ile SSL’i kontrol ederken, bir problem bulamayacak. Şimdi IIS üzerinden, Default Web Site’ın Bindings’ini aşağıdaki gibi düzenleyelim.
Ekran görüntüsünde de görebileceğiniz gibi HTTPS’e statik ip tanımlayıp, HTTP’yi de hostname ekledim. Şimdi yeni bir web sitesi oluşturuyorum ve URL redirect ile gelen tüm bağlantıların, External URL’ye yönlendirilmesini sağlıyorum. Bunun için Autodiscover adında yeni bir site oluşturdum. Sitenin altına Autodiscover isimli bir klasör ekledim ve bu klasör altına da Autodiscover.xml isimli boş bir xml dosyası attım. Sonrasında aşağıda da görebileceğiniz gibi HTTP Redirect’i ayarladım.
Bu işlemleri tamamladığınızda, OWA ve Outlook üzerinde SSL sorunu yaşamadan, mail alıp göndermeye başlayabilirsiniz. Yalnız şirket dışından Outlook erişimlerinde, Outlook Anywhere yapılandırmasını düzgün yapmış olduğunuza emin olun. Outlook Anywhere hakkında detaylı bilgiyi Bing üzerinden bulabilirsiniz.
Posted in Hayattan | 2 Comments | 3,157 views | 23/08/2009 03:44
Microsoft Connect is the worst feedback website on the net. I always thought, the worst feedback websites belong to Linux but Connect changed my mind. You can’t see any feedbacks. Everytime I try to reach website, I get “The system has encountered an unexpected error. We apologize for the inconvenience. The issue will be addressed as quickly as possible.” What a lie!
Microsoft Connect is encountring issues for months but haven’t fixed yet. I don’t know who is in charge but Microsoft should fire whole Connect team if there is a team. I think whole team is on holiday.  |
