Exchange 2010 mimarisinde bildiğiniz gibi client erişim metodları değişti.aRTIK MAPI clientlar direk mailbox server’a bağlanmak yerine RPC endpoint’I olan CAS sunuculara bağlanıyorlar.

Burada High Availability opsiyonlarında bir değişiklik söz konusu.DAG ( Database Availability Group) kullanarak mailbox serverların yüksek erişilebilirlik özelliklerine sahip olmasını sağlayabilirsiniz.

Peki ortamda iki adet CAS sunucunuz var ve bunlarında HA olarak çalışmasını istiyorsanız ne yapmanız gerekiyor?

Bu konu ile ilgili benzer bir yazıyı yazmıştım ama temelde 3 metodunuz bulunuyor.

• DNS Round robin kullanarak otomatik olmayan bir yöntem kullanabilirsiniz.Bunun için CAS sunucular için iki kayıt açıp TTL sürelerini 5 dk düşürürsünüz.Bir CAS sunucu down olduğunda DNS üzerinden bu kayıdı silerseniz 5 dakika içinde clientların cacheleri temizlenip diğer casa bağlanırlar
• Hardware Based Load Balancer
• Windows Network Load Balancer

Buradaki fiyat performans açısından en uygun metod toplamda 8 CAS server ve binlerde kullanıcı destekleyebilen WNLB tabiki.

Yapılması gereken gayet basit.Adım adım;

1. CAS lar üzerinde NLB aktif edilir.
2. DNS üzerinde yeni bir A kaydı açılır
3. Exchange üzerinde cas array oluşturulur ve bu dns point edilir.
4. Varolan mailbox databaseler için yeni cas array point edilir.

Aslında bu apayrı bir makale konusu.Benim bu yazıda değinmek istediğim nokta ise farklı.

Diyelimki WNLB ile CASları HA yapmak istiyorsunuz.Bu durumda NLB üzerinde açmanız gereken portlar TCP 135 ve internal client ile CAS arasında dinamik olarak kullanılacak TCP 1024-65536 aralığıdır.

Bu bazı organizasyonlarda sıkıntı olabiliyor.CAS ile clientlar arasında bir firewall bulunuyorsa bu range için permit istemek zor olabilir.

İşte burada CAS ve mailbox-clientlar arasında kullanılan MAPI portunu statik hale getirebilirsiniz.Bunun için yapmanız gereken CAS üzerinde mailbox bağlantıları için ;

TCP/IP port değerini yukarıdaki gibi 55000 yada başka bir statik değere çekmeniz gereklidir.

Aynı şekilde clientlar üzerindeki directory access için içinde NSPI endpoint port konfigurasyonunu gerçekleştirmeniz gerekiyor.Bunun için Exchange Server üzerindeki Microsoft.exchange.addressbook.service.exe.config dosyasını editlemeniz gerekiyor.

Ardından mailbox ve CAS sunucularını yeniden başlatmanız yeterli olacaktır.

Exchange 2010 yada Exchange 2007 kurduğunuzda CAS üzerindeki IIS altında autodiscover isminde bir virtual directory otomatik olarak oluşmaktadır.Bu dizin sayesinde Microsoft Outlook clientlarınız üzerinde otomatik konfigurasyonları gerçekleştirebiliyorsunuz.Kullanıcı sadece domainde oturum açması yeterli.Eğer non-domain joined clientlarınız varsa bunlarda DNS üzerinden sorgu gerçekleştirerek CAS sunucuyu bulabiliyorlar.

Internalda herşey olması gerektiği gibi devam ediyor.Peki Autodiscover hizmetini internet üzerinde de vermek isterseniz neler yapmanız gerekli biraz buna değinelim.

1- IIS üzerinde Autodiscover servisini host edicek ikinci bir web site oluşturulması

Eğer halihazırda çalışan ve dışarıya hizmet veren oldukça yoğun ziyaretçi sayısına sahip bir websiteniz varsa,autodiscover servisini bu sitenin altında yayınlamak yerine ikinci bir web site üzerinde yayınlamak önerilen konfigurasyondur.Bunu gerçekleştirmek için New-AutoDiscoverVirtualDirectory komut satırını kullanabilirsiniz.

2- Geçerli bir SSL Sertifikası

Autodiscover servisinin sağlıklı çalışabilmesi için geçerli bir ssl sertifikasına ihtiyacınız var.Buradaki önemli nokta clientlarınız bu sertiika otoritesine mutlaka güvenmesi gerektiğidir.Özellikle Outlook Anywhere tarafında yaşanan sorunların başında kurulamayan bu güven ilişkisi gelir.Eğer localde bir CA oluşturup buradan sertifika çekecekseniz domaine dahil clientlar otomatik Enterprise CA’lere güvenirler.Non-domain joined clientlar için manuel güvenilirlik sertifikasını import edebilirsiniz.

3- SCP Objelerinin Update edilmesi

Bildiğiniz gibi SCP objeleri sadece internal clientlar için kullanılır.Active directory içerisinde yer alarak autodiscover servisinin çalışmasına yardımcı olurla.rYalnız eğer autodiscover servisi için ayrı bir web sitesi oluşturursanız ve internal clientlar aynı zamanda externaldanda bağlantı sağlayacaksa, o takdirde SCP objelerini şu CAS altındaki şu virtual directory’e yönlendirme yapacaksın şeklinde güncellemeniz gerekmektedir.Bunun için Publishing with Service Connection Points adresini inceleyebilirsiniz.

Exchange geçiş projelerinde dikkate almamız gereken ürünlerden biriside Blackberry Enterprise Server.Halihazırda çalışan Exchange ile sorunsuz devam eden BES, 2010 geçişi ile birlikte bir sıkıntı yaşayacakmı.Aslında burada konu BES danışmanlarını ilgilendiriyor.Ama Exchange tarafında da bizim yapmamız gereken birkaç önemli nokta var.Bildiğiniz gibi BES tarafında sadece bir mailbox yaratılır ve bu accountın tüm mailboxlar üzerinde yetkisi vardır.İlk başta bu hakları vermemiz gerekli.

Bunun dışında Exchange 2010 ile birlikte gelen Client Throttling Policy lerininde disable edilmesi gerekli.Tümüyle yapılması gerekenleri sıralarsak;

BESAdmin isminde bir mailbox oluşturduktan sonra Microsoft Exchange Management Shell üzerinde hakların verilmesi

Get-MailboxDatabase | Add-ADPermission -User “BESAdmin” -AccessRights ExtendedRight -ExtendedRights
Receive-As, ms-Exch-Store-Admin.
Add-RoleGroupMember “View-Only Organization Management” -Member “BESAdmin”
Add-ADPermission -InheritedObjectType User -InheritanceType Descendents -ExtendedRights Send-As -
User “BESAdmin” -Identity “CN=Users,DC=domain,DC=com”

Client Throttling belli bir account için disable edilmesi

New-ThrottlingPolicy BESPolicy.
Set-Mailbox “BESAdmin” -ThrottlingPolicy BESPolicy

Bu konfigurasyonlardan sonra BES danışmanı arkadaş kurduğu MAPI Client yazılımı ile Exchange’e bağlantı açmaya çalışacaktır.Aslında burada çok önemli bir nokta daha var.Bildiğiniz gibi CAS bağlantıları RPC üzerinden encrypt edilmiş bir şekilde kabul ediyor.Yalnız BES üzerinde kullanılan MAPI account’ın sll desteği yok.Bu yüzden aşağıdaki komut ile geçici bir süreliğine RPC üzerinden Encryptionı kapatmamız gerekli.

Set-RpcClientAccess ““Server Exchange_server_name ““EncryptionRequired $False

Bu komutu CAS üzerinde çalıştırmanız yeterli olucaktır.Ardından MAPI client üzerinden CAS’a bağlantıyı rahatlıkla sağlayabilirsiniz.

Exchange 2010 ile birlikte HA tarafında birçok yenilikle karşılaştık.En önemlisi artık Cluster yapısına dahil ettiğimiz sunucu üzerinde HUB ve CAS rollerini barındırabiliyoruz.Peki Load Balancing tarafında CAS rolüne sahip sunucu için ne gibi opsiyonlarımız var bunları biraz inceleyelim.

Hardware Load Balancing

Hub ve Cas sunucularınız için donanımsal bir load balancing çözümüne gitmek istiyorsanız yapınızın gerçekten buna ihtiyaç duyduğundan emin olmanız gerekiyor.Çünkü tüm opsiyonlar arasında maliyet bakımında en yüksek çözüm bu olacaktır.Microsoft’un önerdiği yapıda eğer array içerisinde 7’den fazla CAS/HUB sunucunuz var ise harware load balancer çözümünü kullanmanızdır.Böylece birçok esnek özelliğinden de faydalanarak client accessleri load balanced yapabilirsiniz.Herhangi bir fail durumunda hızlı bir şekilde array içerisindeki diğer CAS/HUB üzerinden devam edecektir.

DNS Round Robin

Maliyet bakımından en uygun çözüm.Tek yapmanız gereken DNS üzerinde iki adet host (A) kaydı açmak.Böylece ortada bir fail durumu yoksa DNS üzerinde varsayılanda gelen round robin özelliği sayesinde load balance yapabilirsiniz.Peki handikapları nelerdir? Çok basit, otomatik bir fail detection sistemi ne yazıkki mümkün değil.Sunuculardan birisi down olduğundan sistem yöneticisinin bunu farketmesi ve ilgili host(A) kaydını silmesi gerekli.Client tarafındaki ttl cache süresi dolduğunda diğer server üzerinden bağlantılar akmaya devam edecektir.

Windows Network Load Balancer

Hardware load balancer yerine Windows Load Balancer kullanarakda yapınızda CAS/HUB sunucuları için yük dağılımı çözümü gerçekleştirebilirsiniz.Windows Network Load Balancer ile 8 CAS sunucuya kadar desteğiniz mevcut.Buda binlerde kullanıcı demek.Peki maliyet açısından çok uygun bir yöntem olmasına rağmen handikapları nelerdir? Öncelikle CAS sunucunuz aynı zamanda bir DAG(Database Availability Gorpu) üyesi ise ne yazıkki NLB kullanamıyorsunuz.Bir diğer eksik nokta ise sadece source ip kriterine bağlı çalışması.Örneğin NAT üzerinden yüzlerce client bağlantısı geliyorsa NLB bunu tek bir ipden geliyormuş gibi algılayıp aynı CAS üzerine yönlendirecektir.

ISA/TMG Server

Windows network Load Balancer çözümünden biraz daha kapsamlı bir çözüm olarak karşımıza çıkıyor.Örneğin pre-authentication yapabilmesi.Ama maliyet açısından NLB’den daha yüksek maliyetli bir çözüm.Diğer bir eksik yönü ise sadece http trafiğini load balance edebilmesi.Bildiğiniz gibi Exchange 2010 da trafik dağılımı aşağıdaki gibi

• Outlook Web App (HTTP Traffic)
• Exchange Control Panel (HTTP Traffic)
• Exchange Web Services (HTTP Traffic)
• Exchange ActiveSync (HTTP Traffic)
• Autodiscover (HTTP Traffic)
• Offline Address Book (HTTP Traffic)
• Outlook Anywhere (HTTP Traffic)
• RPC Client Access (RPC  Traffic)

Bu sebeple son bağlantıda yük dağılımı gerçekleşmeyecektir.

AutoDiscover servisinde konfigurasyon değişiklikleri yaptıktan sonra aşağıdaki komut ile bağlantıyı test edebilirsiniz.

Test-OutlookWebServices -ClientAccessServer "CASServer01"

Exchange 2010 CAS rolündeki en önemli noktalardan birisi RPC üzerinden iletişimdir.Exchange 2003′de front end sunucular back end ile http üzerinden haberleşiyorlardı.Ancak Exchange 2010 CAS rolüne sahip sunucu Mailbox rolünü sahip sunucu ile RPC üzerinden haberleşiyor.Burada tümleşik gelen hoş bir öelliğimiz var.Proxying.

Exchange 2010 CAS sunucuları diğer CASlar için proxy görevi görebiliyor.Biraz daha açıklama gerekirse birden fazla sitedan oluşan bir yapımız var.Her site içerisinde de CAS sunucularımız.Ancak bu CASlardan sadece bir tanesi internet’e bakıyor.Bu durumda bu CAS üzerine gelen bağlantılar otomatik olarak ilgili site üzerindeki CAS sunucuya aktarılıyor.Buna kısaca CAS-CAS proxying diyoruz.

Aynı senaryo Exchange 2007 CAS olan ortamlarda da uygulanabilir.Böylece upgrade senaryolarında Exchange 2007 ve Exchange 2010 coexist şekilde çalışabiliyor belli bir süre boyunca.

CAS Proxying sırasında arka planda nelerin gerçekleştiğini bilmemiz bizim için önemli.Outlook Web App üzerinden bir bağlantı isteği geldiğinde sırasıyla;

- Bağlantıyı karşılayan CAS sunucusu Active Directory üzerinde bir sorgu göndererek kullanıcının mailbox location bilgisini ve Mailbox serverın versiyon bilgisini elde eder.
-Eğer hedef mail sunucu Exchange 2003 ise fakat kullanıcı /exchange ile bu directory’e ulaşmışsa otomatik olarak bu sunucuya proxy ediliyor.
-Eğer hedef mail sunucu Exchange 2010 ise ve farklı bir active directory altında yer alıyorsa otomatik olarak bu active directory site’ı üzerinde bulunan CAS sunucusuna istek proxy edilir.Yalnız burada CAS ‘ın InternalURL ve ExternalURL bilgileri kullanılır.Eğer externalurl bilgisi girilmiş ise client bu adrese,eğer girilmemiş ise client otomatik olarak internalurl adresine proxy edilir.

InternalURL değeri Exchange 2010 kurulumu sırasında otomatik olarak belirtilir ve mutlaka yapınıza göre değiştirmeniz gereken bir adrestir.ExternalURL ise kurulum sırasında opsiyonel olarak yada kurulumdan sonra konsol veya powershell ile set edilebilir.

Bildiğimiz gibi Exchange 2003 kurulumundan sonra owa clientlar mailboxlarına direk 80 üzerinden erişiyorlardı.Bunun sebebi varsayılanda bir sertifika gelmemesi.Exchange 2007′de ise bu durum değişti ve IIS üzerindeki Deafult Web site varsayılanda sertifikalı olarak gelmektedir.Yalnız 1 senelik varsayılan bu sertifika kullanıldığında büyük ihtimalle hata alacaksınız.Sebebi sertifikanın ismi ile owa’ya eriştiğiniz dns isminin farklı olması.

Localde bir CA’niz varsa basit bir şekilde IIS üzerinde yada exchange management shell kullanarak istediğiniz isimle sertifika çekebilirsiniz.Bu noktadan sonra client tarafı sertifika hatası almadan OWA’ya erişebilecektir.

Yalnız bu işlemden sonra ufak bir sıkıntı daha bizi bekliyor.dns ismi ile yeni bir sertifika oluşturduktan sonra Microsoft Outlook’u açtığımızda aşağıdaki gibi bir hatayla karşılaşırız.

“the name on the security certificate is invalid or does not match the name of the site”

Burada oluşturduğumuz sertifika ile Outlook’un bağlanmaya çalıştığı isim farklı çıkıyor.Çünkü Mapi clientlar Client Access Serverları autodiscovery servisi için kullanırlar ve açılışta bu bağlantıyı kontrol ederler.Aradığı isim ise direk CAS’ın fqdn’idir.E biz sertifikayı dışarıdan ulaşacağımız dns ismi ile oluşturduğumuz için direk isim hatasını alıyoruz.

Bu problemin önüne geçmek için aşağıdaki Exchange Management Shell komutlarını çalıştıralım.

Set-ClientAccessServer -Identity CAS1 -AutodiscoverServiceInternalUri https://mail.anilerduran.com/autodiscover/autodiscover.xml

Set-WebServicesVirtualDirectory -Identity “CAS1\EWS (Default Web Site)” -InternalUrl https://mail.anilerduran.com/ews/exchange.asmx

Set-OABVirtualDirectory -Identity “CAS1\oab (Default Web Site)” -InternalUrl https://mail.anilerduran.com/oab

Set-UMVirtualDirectory -Identity “CAS1\unifiedmessaging (Default Web Site)” -InternalUrl https://mail.anilerduran.com/unifiedmessaging/service.asmx

Bu komutlardaki CAS1 client access server’ınızın ismi.koyu renkli adresler ise daha önceden clientların dışarıdan owaya ulaşmaları için belirlediğiniz ve sertifikasını oluşturduğunuz adres.

Bu işlemden sonra CAS üzerinde iisreset komutuyla iis servisini yeniden başlatmanız yeter.Artık Outlook Mapi clientlarınız isimden dolayı gerçekleşen sertifika hatasını almayacaktır.