Exchange 2010 ile birlikte gelen yeni özelliklerden bir taneside Shadow Redundancy.Kısaca ne olduğundan bahsedelim.

Aslında Exchange 2007′de karşımıza çıkan güzel bir özellik vardı.Transport Dumpster.Bu özellik sayesinde cluster ortamında Hub sunucusu mailleri cluster mailbox databaselere iletirken bunu belirli retention değerlerine göre transport dumpster havuzunda tutuyordu.Böylece bir fail durumunda cluster mailbox server yapıdaki tüm HUBlardan transport dumspter içeriğini isteyerek kaybı önlüyordu.Yalnız bu özellik sadece CCR tarafında gerçekleşiyor en önemliside iki transport server arasında (HUB-HUB / HUB-EDGE) bir geri dönüş ne yazıkki sağlamıyordu.

Shadow Redundancy ise transport dumpster’ın daha kapsamlısı diyebiliriz.Shadow Redundancy enable ettiğinizde neler olduğunu aşağıdaki figur üzerinden gidelim adım adım.

A ) Bir mapi yada mobile client mesaj gönderir ve bu mesaj mailbox server rolünü   tutun sunucu üzerinde tutulur.

B ) Klasik işleyiş burda da devam eder,mail submission servisi HUB sunucusunu uyararak yeni bir mail olduğunu bildirir.HUB bu maili kullanıcının outboxundan alarak kendi databaseine yazar.

C) Burdan sonra eğer alıcı aynı site içerisindeyse   mail gönderilir.

D)Eğer alıcı başka bir site üzerinde ise  HUB bunu başka bir transport servera atacaktır.Burada başka bir HUB sunucuda oalbilir yada yapıdaki EDGE sunuuda olabilir.

Shadow Redundancy için önemli olan transport serverların yani hopların bu özelliği desteklemesi.Hali hazırda sadece Echange 2010 sürümü bu özelliği desteklemektedir.Yani EDGE sunucuda 2010 ise aralarında Shadow Redundancy processini başlatacaklar.Bu process şöyle işlemektedir.

- HUB sunucu EDGE’e bir smtp sessionı başlatır.

-EDGE sunucu Shadow Redundancy desteklediği bilgisini geri dönüş yapar.

-HUB   bunu XSHADOW komutu ile cevaplar.

-HUB mesajı EDGE’ e gönderir.EDGE bu mesajın HUB tarafından shadowlandığına dair bir işaret koyar.

-HUB da aynı şekilde EDGE’i primary server olarak görür ve shadow kuyruğuna ekler.

Bu noktadan sonra HUB sunucu mesajı silmeyecektir.Ancak EDGE tarafından discard status mesajı gelirse,yani bir sonraki hopa başarılı şekilde ulaştırdım bilgisi ulaşırsa  ,o zaman bu mesajı kendi databaseinden silecektir.

Burada EDGE’in mesajı nereye gönderdiği önemli değil.Shadow Redundancy desteklemeyen bir sunucuyada gönderse o sunucudan onay bilgisini alır almaz , HUB sunucusuna discard status mesajını gönderir ve mesajı artık silebileceğini belirtir.

Eğer EDGE mesajı Shadow Redundancy destekleyen başka bir transport sunucuya atarsa yukarıdaki durum yanı şekilde EDGE ve bu sunucu arasındada gerçekleşir.

Dikkat ederseniz ortamdaki transport sunucularınızdan birisi down olduğunda yada siz bakım için offlinea aldığınızda üzerindeki mesajlar Shadow Redundancy sayesinde kaybolmuyor.Çünkü henüz mesajı iletmediği için bir önceki hop üzerinde zaten bu mesajlar tutuluyor.

Peki bu özelliği nasıl enable edeceğiz?

Grafiksel olarak Shadow Redundancy özelliğini yönetebileceğiniz bir arayüz yok.Bunun için shell komutlarını koşturmanız gerekli.

Set-TransportConfig -ShadowRedundancyEnabled $true

 komutu ile Shadow Redundancy enable edilrbilir.Aynı zamanda ilgimi çeken diğer bir güzel komutta shadow altında tutulan mailler için bir age sınırı belirtebilmeniz.Default gelen ayarlarda shadowda tutulan mailler   2 gün geçtikten sonra silinir.İsterseniz

Set-TransportConfig -ShadowMessageAutoDiscardInterval 04:00:00

gibi bir komutla bunu 4 saate çekebiliriz.

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.