Exchange 2007 yada 2010 kullanan yapılarda eğer birden fazla CAS sunucusu var ise, clientların bağlantı sağladıklarında hangi CAS üzerinden bağlantının açıldığını bilmek bazı sorun giderme aşamalarında önemli yardımcınız olabilir.Örneğin bir client owa ekranına bağlandığında arka tarafda hardware yada software load balancing yapılan CAS sunuculardan hangisine bağlantı açmış olabilir?

Bunu gerçekleştirmek için çok hoş bir yöntem bulunuyor.Default gelen owa logon sayfasının bir bölümüne CAS server ismini eklemeniz yeterli.Bunu her CAS için yaparsanız bağlantıyı kabul eden CAS’ı rahatlıkla ayırt edebilirsiniz.

Exchange 2010 için editlemeniz gereken kısım C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\Owa\auth klasörü içerisindeki logon.aspx dosyası.Bu dosyayı notepad ile açarak aşağıkida gibi sunucu isminizi ilgili bölüme ekleyin.

Bu işlemi kaydettikten sonra OWA2010 ekranına baktığınızda sunucu ismini rahatlıkla görebilirsiniz.

Isterseniz yazının rengini beyaz yaparak sadece CTRL A ile gözükmesini sağlayıp sadece belirli bir süre kendiniz kontrol için kullanabilirsiniz.Özellikle mail flow test aşamalarında bence çok işinize yarayacak bir ipucu.

Tüm yapıyı Exchange 2010′a taşıdığımızı düşünelim.Eğer yapınızda Outlook 2003 clientlar bulunuyorsa;

Cannot start Microsoft Office Outlook. Unable to open the Outlook window. The set of folders could not be opened.

Unable to open your default e-mail folders. The Microsoft Exchange Server computer is not available. Either there are network problems or the Microsoft Exchange Server computer is down for maintenance.

The connection to the Microsoft Exchange Server is unavailable. Outlook must be online or connected to complete this action.

Unable to open your default e-mail folders. The information store could not be opened.

Outlook could not log on. Check to make sure you are connected to the network and are using the proper server and mailbox name. The connection to the Microsoft Exchange Server is unavailable. Outlook must be online or connected to complete this action.

Aslında bu hataların sebebi Exchange 2010 ile birlikte CAS ile Mailbox arasındaki bağlantıların RPC üzerinden encrypt edilmiş bir şekilde gerçekleşmesidir.Outlook 2007 yada 2010 üzerinde zaten RPC default olarak şifrelenmiş gittiği için bir sıkıntı söz konusu değil.Ancak Outlook 2003 üzerinde

encryption bölümünün yukarıdaki gibi işaretli olması gerekmektedir.

Tabiki tüm clientlarınız outlook 2003 ise migration işleminden sonra tek tek profilleri dolaşmanız mümkün bir senaryo olmayacaktır.Bu yüzden diğer bir metod olarak geçici bir süre aşağıdaki komut ile CASlar üzerindeki encryptionu disable edebilirsiniz.

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

Exchange 2010 üzerinde CAS Array oluşturmayı düşünüyorsanız şu bilgiyi mutlaka göz önünde bulundurmanız gerekli.Aynı sunucu üzerinde NLB ve Failover Clustering kullanamıyorsunuz.Yani Bir sunucu üzerinde mailbox rolünü kurup bunu DAG üyesi yaptıysanız , aynı sunucuya CAS’da kurabilirsiniz ama bu CAS’ı NLB kullanarak CAS Array’ine alamazsınız.
Microsoft burada external bir load balancer kullanmanızı öneriyor.

Exchange 2010 üzerinde bulunan AutoDiscover servisi sayesinde;

-Microsoft Outlook 2007 yada daha üstü MAPI clientların otomatik konfigurasyonlarını gerçekleştirebilir,
-Microsoft Outlook 2007 yada daha üstü MAPI clientlar ile Exchange özelliklerine erişim verebilir,
-Mobile 6.1 ve daha üstü Mobile işletim sistemlerini aynı şekilde username-password ikilisi ile otomatik konfigure edebiliriz.

Yani kısacası domaindeki bir kullanıcının outlook konfigurasyonu sırasında aslında birşey yapmasına gerek kalmıyor.Domain username ve passwordu kullanılarak AutoDiscover servisi ile birlikte otomatik Outlook konfigurasyonu gerçekleşebiliyor.

Benim bu yazıda değinmek istediğim nokta farklı.Bir migration işlemi düşünelim.Yapınızda çalışan Exchange 2003 yada Exchange 2007 var ve siz Exchange 2010′a geçiş düşünüyorsunuz.Eğer forestınız aynı kalacak ise sıkıntılarınız oldukça az.Ama bu geçiş sırasında farklı bir forest kullanacaksanız o zaman birçok noktayı göz önünde bulundurmanız lazım.Bunlardan biriside geçiş işlemi boyunca her iki yapınında çalışır vaziyette olması.Yani siz kullanıcıların yarısını yeni yapıya geçirdiğinizde,eski yapıdakilerde yeni yapıdakilerde mail flow işleminde sıkıntı yaşamamaları gerekir.

Burada birçok kriter var aslında üzerinde düşünümesi gereken.Bunlardan biriside Autodiscover konfigurasyonu.Diyelimki bir kullanıcıyı ADMT ile diğer foresta aldınız.Aynı zamanda cross forest migration için Exchange üzerinde move-request komutunu kullandınız.Buraya kadar sıkıntı yok.Ama her iki taraftaki kullanıcılarında diğer CASlardaki Autodiscover servisine erişmesini istiyorsanız AutoDiscover için Multiple forest konfigurasyonu yapmanız gerekiyor.

Ancak bu sanıldığı kadar zor bir işlem değil.Tek yapmamız gereken kaynak forest üzerinde

$a = Get-Credential
Export-AutoDiscoverConfig -DomainController -TargetForestDomainController -TargetForestCredential $a -MultipleExchangeDeployments $true

komutlarını girmek.Bu komutlarla birlikte kaynak foresttaki CAS üzerindeki service pointler(SCP) hedef exchange için güncellenecektir.Böylece iki taraftaki clientlarada Autodiscover hizmeti verebilecektir.

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.