Türkiye saat dilimi değişikliği ve yaz saati uygulaması iptali güncellemesi Exchange sunucular için yayınlandı



Exchange 2013 High Availability – II


Ilk makalede Multiple Databases Per Volume, Automatic Reseed ve Safety Net'den bahsetmistik. Burada ise Lagged Copy'deki gelismelerden ve Site Resilience'dan bahsedecegiz.

Lagged Copy'deki gelismeler

Yeni gelismelerle lagged copy'lerle çalismanin artik daha kolay oldugunu söyleyebiliriz. Örnegin 2 gün gecikmeli bir lagged copy'niz var. Safety Net ayarlari da varsayilan degerinde yani mesajlari 2 gün
tutacak sekilde konfigüre edilmis. Lagged copy'nin aktif hale getirilmesi gereken bir durumla karsilastiniz. Öncelikle bu kopya üzerindeki replication'i suspend ediyorsunuz ve her duruma karsi bir yere kopyasini aliyorsunuz. Gerekli
olan aralik disindaki tüm loglari siliyorsunuz ve database'i mount ediyorsunuz.Otomatik olarak Safety Net'den son iki güne ait mesajlarin deliver edilmesi istenecek ve sizin corruption'in yasandigi o noktayi tespit etmeniz gerekmemis
olacak.

Lagged copy'ler bazi durumlarla karsilastiklarinda artik kendileri otomatik log replay'i baslatabilirler.
Bunlar:

- Bos disk alani treshold'un altina düstügünde

- Fiziksel bir corruption yasadiklarinda ve page paching gerekli oldugunda

- Son 24 saat boyunca ortamda üçten az (aktif veya pasif) healthy kopya bulundugunda

Otomatik log replay özelligi varsayilanda devredisidir. Istenirse asagidaki komutla devreye alinabilir:

Set-DatabaseAvailabilityGroup "DAGName" –ReplayLagManagerEnabled $True

Site Resilince

Exchange 2010'da CAS ve Mailbox (DAG) yapilari birbirine daha siki bagliydi. Örnegin bir site'daki tüm CAS'lari kaybetmeniz durumunda veya DAG'inizin önemli bir bölümünü kaybettiyseniz datacenter switchover yapmaniz gerekirdi. Bu islemin takip edilmesi gereken belirli adimlari vardi, kötü olan kismi zaman aliyor olmasi ve admin müdahalesi gerektirmesi idi.

Exchange 2013'de CAS array'i kaybetmis olmaniz datacenter switchover yapmanizi gerektirmiyor. Uygun konfigürasyon ile failover client seviyesinde gerçekleserek, client'lar diger datacenter'a otomatik redirect edilir. Bu datacenter'da bulunan CAS, gelen client istekleri kullanicinin Mailbox server'ina proxying yaparak iletecektir. Dolayisi ile böyle bir senaryoda herhangi bir kesinti yasamadan çalismaya devam edeceksiniz. Bunun disinda Exchange servislerinde olusan bir probleme karsi service kendisini recover etmeye çalisacak ve siz diger sorunlarla, örnegin load balancer'inizda olusan bir problem varsa, ilgilenebileceksiniz.

Exchange 2010'da DAG üyelerinizi iki datacenter arasinda seçebiliyor ve witness server'i üçüncü bir datacenter'da tutabiliyordunuz. Ancak böyle bir konfigürasyonda bile admin müdahalesi olmadan datacenter'lar arasi failover yapamiyordunuz. Çünkü namespace'in Mailbox disindaki roller için manual olarak degistirilmesi gerekiyordu.

Exchange 2013'de namespace'in DAG'la birlikte tasinmasina gerek yok. Çünkü HTTP stack ayni FQDN için çok sayida IP adresini kabul edebilir. Eger ilk denedigi IP adresi fail olursa, listeden ikinci IP adresine erismeyi dener. Soft failure durumunda ise (yani session kurulduktan sonra baglantinin kopmasi) kullanicinin browser'ini refresh etmesi gerekir.

Yani artik namespace için Exchange 2010'da oldugu gibi single point of failure durumu yok. Buradaki en büyük zorluk da kullanicilara verdiginiz FQDN'in nereye gittigi ve gittigi adresi degistirmeniz durumunda DNS'de de degisiklik yapmaniz gerektigi, bununla birlikte DNS latency durumlarini yönetmeniz ve cache'in kullanici browser'inda 30 dk duruyor olmasi nedeni ile bunu da yönetebiliyor olmaniz.

Exchange 2013'de client'lariniz artik tek bir adrese gitmek durumunda degil. Exchange 2013'de client erisimlerinin tümü HTTP based oldugu için ve yukarida bahsettigimiz gibi HTTP client'larin birden fazla IP adresi kullanabilmesinden dolayi client side failover saglanmaktadir. DNS'inizde ayni FQDN için birden fazla IP adresi girebilirsiniz. Örnegin mail.contoso.com adresi için DNS'e girdiginiz dört farkli IP adresi (dört CAS) oldugunu düsünelim. Bu dört IP adresi client tarafindan güvenilir bir sekilde kullanilir. Client'in erismeye çalistigi IP adresi erisilemez olursa, yaklasik 20 sn sonra client listeden ikinci IP adresine erismeyi dener. Bu yüzden Client Access server array için VIP'ye erisilememesi durumunda recovery islemi client tarafli 21 sn içinde otomatik olarak yapilacaktir.

 

Sevgi Sifyan


Exchange 2013 Yeni Rol Mimarisi


Exchange 2007 ve Exchange 2010 da donanimsal kisitlamalar yüzünden Exchange'I 5 role ayrilmisti.

Bunlardan 3 tanesi zorunlu olmak üzere (*) su sekilde siralanirlar:

  1. Edge Transport
  2. Hub Transport (*)
  3. Mailbox (*)
  4. Client Access (*)
  5. Unified Messaging

Bu roller birbirlerine sikica baglidirlar. Ancak Exchange 2013 de sunucularin fiziksel perfromanslari (CPU) göz önüne alinarak rol sayisi ve rollerine birbilerine
bagliligini azaltmak için farkli bir mimari gelistirildi. Bu mimari iki temel blok üzerine insa edilmistir; Cas array ve Database Availability Group (DAG). Exchange 2013 CAS sunucu 3 bilesenden olusur, bunlar istemci protokolleri, SMTP ve UM arama yönlendirmesidir. CAS rölü temel anlamda sadece proxy islemi gören bir sunucu haline getirilmistir. Herhangi bir kullanici verisini tutmaz (veri dönüstürmesi yapmaz). Gelen istegi dogrular ve kullanicinin aktif veritabani hangi Mailbox sunucudaysa oraya yönlendirir. Mailbox sunucu artik tüm datanin tutuldugu ve islendigi sunucudur bu nedenle ilgili bütün bilesenleri ve protokolleri üzerinde tutar. Hiçbir istemci dogrudan Mailbox sunucuya baglanti gerçeklestirmez; tüm baglantilar CAS üzerinden RPC/HTTPS ile gelir.

 

 

Bu rol mimarisi ile kisaca neler kazandik:

  1. CAS artik sadece proxy islemi yaptigindan namespace/ek isimlendirmelerin sayisi azaldi
  2. Session stateless CAS tipimiz oldugu için Layer7 NLB ihtiyacimiz yerini çok daha ucuz Layer4 NLB lere birakabilecek. Bu ciddi bir maliyet avantaji getiriyor.
  3. Tüm verinin Mailbox sunucuda islenmesi rollerin ayni sürümlerinin olma zorunlulugunu kaldiriyor. Daha basit bir yapiya sahip oluyoruz, daha kolay planlanabilecek ve kolayca güncellenebilek.

 

C.Sinem Tosun


Exchange Admin Auditing


Exchange 2010 öncesinde admin seviyesinde yapilan islemlere karsi kim, ne zaman, ne yapti sorularina cevap verecek bir fonksiyon bulunmuyordu (Admin seçiciligini yapacak  bir yol mevcut degil ve ancak tabiki tüm konfigürasyon degisiklikleri ve mailbox erisimleri degisik yollarla izlenebilir). Halbuki yapilan bir degisilik veya olusturulan bir nesne Exchange'in isleyisini beklenmedik bir sekilde olumsuz yönde etkileyebilir. Admin Auditing hissedilen bu eksiklige karsi sunulan bir yenilik oldu.

Admin Auditing Exchange 2010 SP1 ve sonrasinda varsayilan olarak etkin gelmektedir. Varsayilan ayarlarinda Get- , Search- ve Test- ile baslayan komutlar disinda kullanilan tüm komutlar
loglanir. Bu sekilde baslayan komutlar object'lerin degistirilmesi için degil, görüntülenmesi için kullanildiklari için loglama disinda birakilmislardir.

Admin yaptigi yönetimsel islemler sirasinda, islemlerin loglandigina dair hiçbir ibare görmez. Audit loglar search edildiginde yapilan degisiklikler raporlanir. Loglama arka planda bir cmdlet extension agent tarafindan yapilir ve tüm Exchange 2010 sunucularda çalisir. Exchange 2007'de bu agent bulunmadigi için mix bir ortamda 2007 management tools kullanilarak yapilan degisiklikler loglanmayacaktir.

Admin Auditing Log konfigürasyonu organizasyonel bir degisiklik oldugu için yapilan bir degisikligin tüm sunucularda etkin olmasi replikasyon süresine baglidir.

Asagidaki ekran görüntüsünde varsayilan AdminAuditLogConfig ayarlarini görebilirsiniz.

Sirketiniz için önem arzeden islemlerin loglanmasini öneririz. Simdi birlikte varsayilan ayarlari degistirerek loglama alanini daraltalim.

AdminAuditLogCmdlets: Kullanilan hangi cmdlet'lerin loglanacagini belirleyebildiginiz bir parametredir. Örnegin içerisinde "virtual directory" geçen tüm cmdlet'lerin loglanmasini istiyorsak ve ayni zamanda new-mailbox komutunun loglanmasini istiyorsak konfigürasyonu asagidaki gibi yapabiliriz.

AdminAuditLogParametres: AdminAuditLogCmdlets ile belirlediginiz cmdlet'lerin hangi parametreler ile birlikte çalistirildiginda loglama yapilacagini belirtir. Asagidaki örnegimizde New-Mailbox cmdlet'inin Database, FirstName, LastName parametrelerinin loglanacagini belirtmis oluyoruz.

 

AdminAuditLogAgeLimit:  Varsayilan olarak loglar 90 gün saklandiktan sonra silinir. AdminAuditLogAgeLimit parametresi ile bu süreyi gün, saat, dakika ve hatta saniye belirterek degistirebilirsiniz. Yazim format su sekilde olmalidir: dd.hh:mm:ss. Asagidaki komut ile süreyi 100 gün 12 saat 5 dakika ve 2 saniye olarak degistirmis olduk:

Set-AdminAuditLogConfig -AdminAuditLogAgeLimit 100.12:05:02

Bu parametre ile ilgili önemli bir uyari AgeLimit'i varsayilan degerden daha düsük bir degere çektiginizde belirttiginiz degerden eski olan loglar silinecektir.
Örnegin bu degeri 0 yaptiginizda o zamana kadar loglanmis tüm girdiler silinir. Bu sebeple kime bu degeri degistirme yetkisi verdiginize dikkat etmelisiniz.

 

TestCmdletLoggingEnabled: Makalemizin basinda Get-, Search- ve Test- ile baslayan cmdlet'lerin loglanmadigini belirtmistik. Bu parametre ile Test- ile baslayan cmdlet'lerin loglanmasini saglamis oluyoruz.

 

Set-AdminAuditLogConfig -TestCmdletLoggingEnabled $True

Audit loglarina nasil ulasabiliriz?

Farkli sekillerde erismek mümkün. Bunlar Search-AdminAuditLog veya New-AdminAuditLogSearch cmdlet'lerini kullanmak veya loglarin tutuldugu mailbox'a erismek olabilir.

SP1 sonrasi yapilan degisiklikle administrator auditing loglarinin tutuldugu gizli ve bu is için atanmis bir mailbox mevcut. Bu mailbox'a erisim ise sadece ECP üzerinden saglanabiliyor. Tüm organizasyona ait admin audit loglari sadece bu mailboxda tutulur ve bu mailbox'in yer aldigi database mount durumda degilken loglama mümkün olmaz.

Auditing'in ECP üzerindeki görüntüsü asagidaki gibidir. Buradan administrator audit loglarini xml formatinda export edip, sonuçlari belirlediginiz bir user'a maille gönderebilirsiniz.

 

 

Ikinci bir yöntem, Search-AdminAuditLog cmdlet'ini kullanarak kendi audit log analizlerinizi olusturmak. Bu komutla belirleyebileceginiz kriterler: Cmdlets, Parameters, EndDate, StartDate,
ObjectIDs, UserIDs Bu kriterlerden ObjectIDs ile özellikle belirli bir nesne üzerindeki degisikliklerin raporunu isteyebilirsiniz. UserIDs ile ise belli bir admin'in yaptigi degisiklikleri raporlama sansimiz da var.

 

Asagidaki örnekte Administrator'in belirli tarihler arasinda yaptigi islemleri görebilirsiniz.

Asagidaki örnekte New-Mailbox komutunun kimler tarafindan ve hangi nesneler için çalistirildigini görebilirsiniz.

Son yöntemimiz, New-AdminAuditLogSearch cmdlet'i ile search isleminin yapilmasi. Search-AdminAuditLog cmdlet'inde kullanilan kriterler bu cmdlet için de geçerlidir, tek farki sonuçlari shell'de
göstermek yerine belirlediginiz kisiye mail olarak, XML formatinda gönderebilir (çünkü ilgili komut bir JOB olarak arka planda çalistirilir ve çiktisi islem bittikten sonar teslim edilir).

Asagidaki örnekte ise belirli tarihler arasinda çalistirilan New-Mailbox komutuna ait raporun sevgi@exchange2010.net adresine gönderimini saglayabilirsiniz.

 

Sevgi Sifyan


Exchange Management Shell ile Public Folder Yönetimi


Public Folder'lar Exchange Server dünyamizda yogun olarak yönetimini yaptigimiz bilesendir. Public Folder'larun günlük yönetiminde Exchange Management Shell (EMS), kullanilmasi islerimizi biraz daha çabuklastirabilir düsüncesi ile asagida bazi ipuçlarini sizinle paylasacagim.

Bildiginiz gibi Public Folder'larin olusturulmasi için öncelikle organizasyonumuzda bir Public Folder (PF) veritabani'nin bulunmasi gerekmektedir. Peki simdi EMS ile bu nasil gerçeklestirilir buna bakalim.

New-PublicFolderDatabase

Bu cmdlet ile asagidaki gibi PF olusturulur.

New-PublicFolderDatabase –Name "PFDBName" –StorageGroup "Second Storage Group"

EMS üzerinde yukaridakikomut çalistirildiginda, database dismounted olarak olusur.

Bu PF Database'i mount etmek için ise asagidaki komut çalistirilir.

Mount-Database –Identity "PFDBName"

Su anda bos bir PF Database olusturmus olduk. Bu PF database'in bazi özelliklerini degistirmek istersek bunuda asagidaki cmdlet ile yapiyoruz.

Set-PublicFolderDatabase

Asagidaki örnek komut Retention ayarlarimizi düzenlemek içindir.

Set-PublicFolderDatabase -Identity "ServerName\PFDBName" -DeletedItemRetention 07.00:00:00 -RetainDeletedItemsUntilBackup $true -EventHistoryRetentionPeriod 14.00:00:00 -ItemRetentionPeriod unlimited

Asagidaki örnek komut ile de PF database içindeki tüm public folder'larin storage quota degerlerini set ediyoruz.

Set-PublicFolderDatabase -Identity PFDBName -IssueWarningQuota 2000MB -QuotaNotificationSchedule "Sun.3:00 AM-Sun.3:15 AM, Tue.3:00 AM-Tue.3:15 AM, Thu.3:00 AM-Thu.3:15 AM"

Ikinci olarak olusturdugumuz PF database içerisine Public Folderlarin nasil olustuguna bakalim.

New-PublicFolder –Name "PFName"

Public Folder'lar içerisinde bir de mail enabled public folderlar bulunmaktadir. Burada iki farkli cmdlet kullaniyoruz.

Set-PublicFolder (Mail enabled degil)

Set-MailPublicFolder (Mail enabled)

Asagidaki birkaç örnekte Public Folder'larin nasil düzenlendigini göreceksiniz.

Set-PublicFolder -Identity "\test" -UseDatabaseQuotaDefaults: $False

Set-PublicFolder -Identity "\test\deneme" -StorageQuota 10MB

Peki bu asamada bir public folder nasil mail enabled yapilir.

Enable-MailPublicFolder –Identity "\test"

Bu mail enable public folder'in özellikleri asagida görüldügü gibi degistirilebilir.

Set-MailPublicFolder -Identity "\test" -PrimarySmtpAddress test@test.test

Set-MailPublicFolder -Identity "\test" -SendStorageQuota 200MB

Son olarak Pulic Folder'larin özelliklerinin görüntülenmesinin nasil yapilacagina deginecegim.

Get-PublicFolder

Tüm sistem folder'larinin görüntülenmesi için:

Get-PublicFolder -Identity \NON_IPM_SUBTREE -Recurse | Format-List Name

Public Folder'lar ile ilgili yukarida verdigim bilgilerin faydali olacagini umarak diger bir konuda görüsmek üzere diyorum.

Volkan Günaydin


Exchange Server 2007 Autodiscover servisine özet bir bakış


Exchange Server 2007 ile birlikte gelen önemli özelliklerden biriside Autodiscover servisidir. Bu servisin amaci, client'in otomatik olarak tüm ayarlarinin saglanmasidir. Bu özelligin çalismasi için Microsoft Office Outlook 2007 versiyonu gerekmektedir. Autodiscover servisi, e-mail adress ve password kullanimi ile client'a, iç agdan ve dis agdan yapilacak baglantilarda gerekli baglanti adreslerini (oab,ews vb..), kullanici mailbox bilgisini ve outlook anywhere ayarlarini gönderir.

Tüm bu özellikleri saglayan Exchange Server 2007 rolü, Client Access Server (CAS) rolüdür. CAS server ilk kuruldugunda, IIS üzerindeki default web site içerisinde, Autodiscover adinda bir virtual directory olusur. Ayrica, Service Connection Point (SCP) adinda bir de Active Directory objeside, CAS server kurulumu ile birlikte gelir. Bu SCP objesi, forest bazinda tüm yetkili Autodiscover service URL'lerini içerir.

Autodiscover servisi kendine gelen istekleri Outlook Provider'a gönderir. Outlook Provider üzerinde 3 konfigurasyon ayari bulunmaktadir. Bunlar,

WEB: Bu ayar, kullanicinin Outlook Web Access için kullanacagi en iyi URL'yi içerir.

EXCH: Exchange RPC protokolünün referans ayarlari için kullanilir. Exchange servislerinin iç URL'leri ve port ayarlari için kullanilmaktadir.

EXPR: Outlook Aynwhere tarafindan kullanilan Exchange HTTP protokolü ayarlari için kullanilir. Exchange server'a internet üzerinden erisen kullanicilarin, external URL'lerini ayarlamak için kullanilir.

Set-OutlookProvider cmdlet ile ilgili degisiklikler yapilabilir.

Örnegin, en çok karsilasilan sorunlardan birisi wildcard sertifika kullaniminda yasanmaktadir. Internet üzerinden yapilan outlook anywhere baglantisinda, client asagidaki hatayi alabilir.

autodiscover

Bu sorunun giderilmesi için Outlook profil ayarlarinda, Connection bölümünde msstd:* seklinde tanimlama yapildiginda sorun giderilir. Bununla birlikte çok fazla kullanici da bu ayarin yapilmasi bu sekilde mümkün degildir. Exchange Management Shell üzerinde asagidaki komut kullanilarak tüm clientlarin bu ayari almasi saglanabilir.

Set-OutlookProvider –Identitiy EXPR –CertPrincipalName msstd:*.domain.com

Outlook 2007 clientlar, her outlook açildiginda, her exchange baglantisi kesintiye ugradiginda ve belirli araliklarla Autodiscover servisine baglanti kurarlar. Eger outlook client 60 dakika sonra tekrar baglanti kuramaz ise 5 dakika araliklar ile tekrar baglanti kurmayi dener.

Bazi durumlarda Outlook ile Autodiscover servisi arasinda sorun yasanabilir ve bir çok fonksiyon dogru çalismayabilir. Bu gibi durumlarda Outlook üzerinde asagidaki ayar ile Autodiscover servisinin kullanilmasi tetiklenir.

Outlook 2007 üzerinde, Tools ve sonra Account Settings seçilir. E-mail account penceresinde, E-mail tabi seçilir ve Repair tiklanir.

Autodiscover servisinin iç URL bilgisini degistirmek için Set-ClientAccessServer cmdlet'i kullanilir.

Set-ClientAccessServer –Identity <CASserveradi> -AutodiscoverServiceInternalUri https://autodiscover.domain.com/autodiscover/autodiscover.xml

Outlook Anywhere dis host adinin, autodiscover servisi için ayarlamada kullanilacak cmdlet asagidaki gibidir.

Enable-OutlookAnywhere –Server Serveradi –ExternalHostname "mail.domain.com" –ExternalAuthenticationMethod "Basic" –SSLOffloading:$False

Offline Adres defterinin dis URL'sinin autodiscover servisi için set edilmesinde ise asagidaki cmdlet kullanilir.

Set-OABVirtualDirectory –identity "serveradi\OAB (Default Web Site)" –externalurl https://mail.domain.com/OAB -RequireSSL:$true

Autodiscover servisi, Exchange Server 2007 ile birlikte gelen ve özellikle düzgün bir sekilde konfigüre edildiginde, sistem yöneticilerinin isini çok kolaylastiracak bir özelliktir. Burada her sistemin kendine özgü sartlarinin gerektirdigi durumlar gözönüne alinarak gerekli düzenlemelerin yapilmasi önemlidir. Bu konuda çok daha fazla bilgi için https://technet.microsoft.com üzerinde Autodiscover için arama yaptiginizda detayli bilgiye erisebilirsiniz.

Volkan Günaydin


Exchange Server 2010 Client Access Server


 

Exchange Server 2010 ile ilgili mimari açidan en büyük degisikliklerden birisi de, CAS (Client Access Server) adini verdigimiz sunucu rolünündedir. Exchange Server 2010'da MAPI ve Dizin Hizmetleri CAS sunuculari üzerinden verilmektedir. Bu hizmetin adi RPC Client Access hizmetidir.

RPC hizmeti

Bunun anlami aslinda artik MAPI istemcilerinin, Mailbox sunucu'ya direkt olarak baglanmamalaridir. Yani, MAPI clientlar önce CAS sunucuya baglanirlar ve buradan da Active Directory ve Mailbox sunucuya baglanti gerçeklestirilir. Dizin hizmetleri için, Outlook istemcisi CAS sunucu üzerindeki NSPI endpoint baglantisi ve ardindan da NSPI'da Active Directory sürücüsü ile AD 'ye baglanir. Bu aslinda Exchange Server 2007 de bildigimiz RPC over HTTPs baglantisina çok benzerdir.

Bu baglanti çesidinin (MAPI in the middle tier) bazi avantajlari bulunmaktadir. Örnegin, failoverlarda client tarafinda çok daha kisa sürelerde unresponsive durum yasanmasini saglayacaktir. Ayrica, Exchange Server 2007'de bir mailbox sunucu 64000 baglantiya izin verirken, Exchange Server 2010'da bu sayi 250000 RPC baglantisidir.

Burada acaba hangi Outlook clientlar Exchange Server 2010 CAS'a baglanti yapabilir sorusu akliniza geliyor ise cevap Outlook 2003 den itibaren hepsi (Outlook 2003,2007,2010). Burada dikkat edilmesi gereken bir nokta ise, Outlook 2003 clientlarin RPC baglantilarinda encryption kullanmalaridir. Çünkü CAS üzerinde default olarak RPC baglantilari için encryption gereklidir. Bunu asagidaki komutu çalistirarak görebilirsiniz.

Get-RpcClientAccess |fl

Burada Encryption Reuired True olarak gözükecektir. Outlook 2007 ve Outlook 2010 clientlarda böyle bir problem bulunmamaktadir (By default encryption enable'dir).

encryption settings

Simdi söyle bir senaryo düsünelim:

Ortaminizda Outlook 2003 clientlar var ve siz Exchange Server 2010 upgrade yaptiniz. Tüm profiller yeniden mi düzenlenecek?

Burada,

Set-RpcClientAccess –Server <CAS SUNUCU ADI> -EncryptionRequired $False

komutu ile Outlook 2003 clientlarin baglantisini gerçeklestirebilirsiniz. Konu ile ilgili çok fazla detay olan makaleyi asagida ekliyorum. Bu makaleye çok fazla ihtiyaç duyulacagini düsünüyorum.

https://support.microsoft.com/kb/2006508 (Outlook connection issues with Exchange 2010 mailboxes due to RPC encryption requirement)

Burda önemli olan bir nokta ise: Eger public folder kullaniyor iseniz, bu ayari ayni zamanda Mailbox sunucu üzerinde de yapmaniz gerekmektedir. Çünkü public folder erisimi direkt olarak mailbox sunucu üzerindeki RPC Client Access servisi üzerinden yapilmaktadir.

Bir sonraki makalede yeni CAS sunucumuzun diger özelliklerine bakiyor olacagiz.

Volkan Günaydin


Exchange Server 2010 'da -Configurationonly parametresi nerede ?


Exchange Server 2007 üzerinde felaket (disaster) senaryolarindan dönüste en çok kullanilan Exchange Management Shelll cmdlet'i move-mailbox ile kullanilan –configurationonly parametresi idi. Bu parametre ile tamamen yok olmus bir database'in kullanicilarinin baska bir yeni açilmis database üzerinde tasinmalari saglanabiliyordu.

Burada fiziksel bir move islemi olmamakta, sadece mailboxlarin yeni lokasyonlari belirtilmektedir. Bu parametre ayrica Exchange Server 2007 ile birlikte gelen "Database Portability" sayesinde, elimizde "clean shutdown" seklinde olan bir mailbox store database'in baska bir server üzerinde mount edilmesi sonrasinda, Outlook'larin açildiklarinda bu yeni sunucuyu kullanabilmelerini sagliyordu.

Bu özellikle bilgi islem tarafinda yapilan SLA (Service Level Agreement) anlasmalarinda belirtilen sürelere riayet edilmesini kolaylastiran bir özellik olmasi açisindan da önemlidir.

Exchange Server 2010'a geldigimizde artik move-mailbox cmdlet'inin yerini new-moverequest cmdlet'i aldi. Bununla birlikte, bu cmdlet parametreleri arasinda -configurationonly parametresi bulunmamaktadir. Elbette Exchange Server ürün ekibi böyle önemli bir özelligi devre disi birakacak degillerdi. Exchange Server 2010 üzerinde yukarida anlattigimiz özelligi asagida gösterdigim sekilde kullanabilirsiniz.

Örnek durum:

Tüm mailboxlar DB1 adli database'de iken bunlari DB2'ye tasimak istiyorsunuz.

Get-Mailbox –Database DB1 | Set-Mailbox -Database DB2

Yukarida verdigim örnek disinda ihtiyaciniza göre, farkli senaryolar için set-mailbox cmdlet'ini kullanabilirsiniz.

 

Volkan Günaydin