TR Exchange Blog

Exchange Admin Auditing

TR Exchange Support Team — Tue, 12 Feb 2013 14:09:00 GMT

Exchange 2010 öncesinde admin seviyesinde yapılan işlemlere karşı kim, ne zaman, ne yaptı sorularına cevap verecek bir fonksiyon bulunmuyordu (Admin seçiciliğini yapacak bir yol mevcut değil ve ancak tabiki tüm konfigürasyon değişiklikleri ve mailbox erişimleri değişik yollarla izlenebilir). Halbuki yapılan bir değişilik veya oluşturulan bir nesne Exchange’in işleyişini beklenmedik bir şekilde olumsuz yönde etkileyebilir. Admin Auditing hissedilen bu eksikliğe karşı sunulan bir yenilik oldu.

Admin Auditing Exchange 2010 SP1 ve sonrasında varsayılan olarak etkin gelmektedir. Varsayılan ayarlarında Get- , Search- ve Test- ile başlayan komutlar dışında kullanılan tüm komutlar
loglanır. Bu şekilde başlayan komutlar object’lerin değiştirilmesi için değil, görüntülenmesi için kullanıldıkları için loglama dışında bırakılmışlardır.

Admin yaptığı yönetimsel işlemler sırasında, işlemlerin loglandığına dair hiçbir ibare görmez. Audit loglar search edildiğinde yapılan değişiklikler raporlanır. Loglama arka planda bir cmdlet extension agent tarafından yapılır ve tüm Exchange 2010 sunucularda çalışır. Exchange 2007’de bu agent bulunmadığı için mix bir ortamda 2007 management tools kullanılarak yapılan değişiklikler loglanmayacaktır.

Admin Auditing Log konfigürasyonu organizasyonel bir değişiklik olduğu için yapılan bir değişikliğin tüm sunucularda etkin olması replikasyon süresine bağlıdır.

Aşağıdaki ekran görüntüsünde varsayılan AdminAuditLogConfig ayarlarını görebilirsiniz.

Şirketiniz için önem arzeden işlemlerin loglanmasını öneririz. Şimdi birlikte varsayılan ayarları değiştirerek loglama alanını daraltalım.

AdminAuditLogCmdlets: Kullanılan hangi cmdlet’lerin loglanacağını belirleyebildiğiniz bir parametredir. Örneğin içerisinde “virtual directory” geçen tüm cmdlet’lerin loglanmasını istiyorsak ve aynı zamanda new-mailbox komutunun loglanmasını istiyorsak konfigürasyonu aşağıdaki gibi yapabiliriz.

AdminAuditLogParametres: AdminAuditLogCmdlets ile belirlediğiniz cmdlet’lerin hangi parametreler ile birlikte çalıştırıldığında loglama yapılacağını belirtir. Aşağıdaki örneğimizde New-Mailbox cmdlet’inin Database, FirstName, LastName parametrelerinin loglanacağını belirtmiş oluyoruz.

AdminAuditLogAgeLimit: Varsayılan olarak loglar 90 gün saklandıktan sonra silinir. AdminAuditLogAgeLimit parametresi ile bu süreyi gün, saat, dakika ve hatta saniye belirterek değiştirebilirsiniz. Yazım format şu şekilde olmalıdır: dd.hh:mm:ss. Aşağıdaki komut ile süreyi 100 gün 12 saat 5 dakika ve 2 saniye olarak değiştirmiş olduk:

Set-AdminAuditLogConfig -AdminAuditLogAgeLimit 100.12:05:02

Bu parametre ile ilgili önemli bir uyarı AgeLimit’i varsayılan değerden daha düşük bir değere çektiğinizde belirttiğiniz değerden eski olan loglar silinecektir.
Örneğin bu değeri 0 yaptığınızda o zamana kadar loglanmış tüm girdiler silinir. Bu sebeple kime bu değeri değiştirme yetkisi verdiğinize dikkat etmelisiniz.

TestCmdletLoggingEnabled: Makalemizin başında Get-, Search- ve Test- ile başlayan cmdlet’lerin loglanmadığını belirtmiştik. Bu parametre ile Test- ile başlayan cmdlet’lerin loglanmasını sağlamış oluyoruz.

Set-AdminAuditLogConfig -TestCmdletLoggingEnabled $True

Audit loglarına nasıl ulaşabiliriz?

Farklı şekillerde erişmek mümkün. Bunlar Search-AdminAuditLog veya New-AdminAuditLogSearch cmdlet’lerini kullanmak veya logların tutulduğu mailbox’a erişmek olabilir.

SP1 sonrası yapılan değişiklikle administrator auditing loglarının tutulduğu gizli ve bu iş için atanmış bir mailbox mevcut. Bu mailbox’a erişim ise sadece ECP üzerinden sağlanabiliyor. Tüm organizasyona ait admin audit logları sadece bu mailboxda tutulur ve bu mailbox’ın yer aldığı database mount durumda değilken loglama mümkün olmaz.

Auditing’in ECP üzerindeki görüntüsü aşağıdaki gibidir. Buradan administrator audit loglarını xml formatında export edip, sonuçları belirlediğiniz bir user’a maille gönderebilirsiniz.

İkinci bir yöntem, Search-AdminAuditLog cmdlet’ini kullanarak kendi audit log analizlerinizi oluşturmak. Bu komutla belirleyebileceğiniz kriterler: Cmdlets, Parameters, EndDate, StartDate,
ObjectIDs, UserIDs Bu kriterlerden ObjectIDs ile özellikle belirli bir nesne üzerindeki değişikliklerin raporunu isteyebilirsiniz. UserIDs ile ise belli bir admin’in yaptığı değişiklikleri raporlama şansımız da var.

Aşağıdaki örnekte Administrator’ın belirli tarihler arasında yaptığı işlemleri görebilirsiniz.

Aşağıdaki örnekte New-Mailbox komutunun kimler tarafından ve hangi nesneler için çalıştırıldığını görebilirsiniz.

Son yöntemimiz, New-AdminAuditLogSearch cmdlet’i ile search işleminin yapılması. Search-AdminAuditLog cmdlet’inde kullanılan kriterler bu cmdlet için de geçerlidir, tek farkı sonuçları shell’de
göstermek yerine belirlediğiniz kişiye mail olarak, XML formatında gönderebilir (çünkü ilgili komut bir JOB olarak arka planda çalıştırılır ve çıktısı işlem bittikten sonar teslim edilir).

Aşağıdaki örnekte ise belirli tarihler arasında çalıştırılan New-Mailbox komutuna ait raporun sevgi@exchange2010.net adresine gönderimini sağlayabilirsiniz.

Sevgi Sifyan

Exchange 2010 SP1 için RU8, Exchange 2010 SP2 için RU5 v2 ve Exchange 2007 SP3 için RU9 11 Aralık 2012 de yayınlandı

TR Exchange Support Team — Tue, 12 Feb 2013 13:53:00 GMT

Exchange 2010 SP1 için Ru8, Exchange 2010 SP2 için Ru5 v2 ve Exchange 2007 SP3 için Ru9 11 Aralık 2012 de yayınlandı. Ilgili Exchange blog sayfası: http://blogs.technet.com/b/exchange/archive/2012/12/11/released-update-rollup-5-v2-for-exchange-2010-sp2-exchange-2010-sp1-ru8-and-exchange-2007-sp3-ru9.aspx

Exchange 2007 SP3 Ru9 ile gelen en önemli fix EdgeTransport.exe işleminin tekrarlanan toplantı isteğini işlerken crash etmesidir. Sunucu sadece bir defa oluşan ancak tekrarlanan toplantıyı işlerken bu problemi vermektedir. Bunun nedeni AppointmentReccurenceBlob özelliğinin bu tip toplantı istekleri için desteklenmemiş olmasıdır. Bu nedenle InvalidOperationException hatası alınarak EdgeTrasnport.exe crash ediyor.

Bu koşulda event loglara düşecek olası hatalar:

Time: Time

ID: 10003

Level: Error

Source: MSExchangeTransport

Machine: Computer

Message: The transport process failed during message processing with the following call stack: System.InvalidOperationException: Property AppointmentRecurrenceBlob is not permitted on meeting occurrences.

Time: Time

ID: 4999

Level: Error

Source: MSExchange Common

Machine: Computer

Message: Watson report about to be sent to dw20.exe for process id: Process ID, with parameters: E12, Build Type, Version Number, edgetransport, M.E.D.Storage, M.E.D.S.OccurrencePropertyBag.InternalSetValidatedStoreProperty, System.InvalidOperationException, XXXX, Version Number. ErrorReportingEnabled: False

Güncellemeyle ilgili daha detaylı bilgiye http://support.microsoft.com/kb/2748658 buradan ulaşabilirsiniz.

Exchange 2010 SP2 UR5 v2 ile de gelen önemli fixler var bunlardan sık karşılaştıklarımız şunlar;

Gönderici attığı epostanın bazı alıcılara iletilmesine rağmen iletim listesindeki herkes için iletilemedi (NDR) mesajını alması. Bunun nedeni Hub Transport sunucunun dışarıya email atılırken 3rd party smart-host ile route ederken Delivery Service Notification (DSN) tablosundan yanlış alıcıları eklemesidir. Detaylı bilgi için http://support.microsoft.com/kb/2748767

Microsoft Exchange Replication servisinin Exchange 2003 den Exchange 2010 a mailbox taşınırken aralıklarla crash etmesi. Bunun sebebi Excange 2010 CAS sunucunun tamamlanmış
taşıma talebini silerken o esnada olan taşıma işlemini düzgün işleyememesidir.

Event loglara düşebilecek olası hatalar:

Log Name: Application

Source: MSExchange Mailbox Replication

Date: Date

Event ID: 1121

Task Category: Request

Level: Error

Keywords: Classic

User: N/A

Computer: Computer

Description: The Microsoft Exchange Mailbox Replication service was unable to process a request due to an unexpected error.

Request GUID:GUID

Database GUID: GUID

Error: MapiExceptionNotFound: Unable to open entry ID. (hr=0x80004005, ec=-1601)

Log Name: Application

Source: MSExchange Common

Date: Date

Event ID: 4999

Task Category:General

Level: Error

Keywords: Classic

User: N/A

Computer: Computer

Description: Watson report about to be sent for process id: Process ID, with parameters: E12, Build Type,Version Number, MSExchangeMailboxReplication,
M.Exchange.MailboxReplicationService, M.E.M.MoveBaseJob.<BeginJob>b__c, System.NullReferenceException, XXX, Version Number.

ErrorReportingEnabled: True

Log Name: System

Source: Service Control Manager

Date: Date

Event ID: 7031

Task Category: None

Level: Error

Keywords: Classic

User: N/A

Computer: Computer

Description: The Microsoft Exchange Mailbox Replication service terminated unexpectedly. It has done this XX time (s). The following corrective action will be taken in XX
milliseconds: Restart the service.

Fix ile ilgili daha ayrıntılı bilgiye buradan ulaşabilirsiniz http://support.microsoft.com/kb/2727802.

Bir diğer önemli mesele Exchange 2010 Mailbox server Store.exe servisinin VSAPI (virus scanning API) tabanlı antivirus yazılımı kullanımı sonucunda crash etmesidir. Bunun sebebi Exchange sunucunun yanlışlıkla noktalı virgül işaretini bazı VSAPI 2.6 protokolünün kullandığı bazı property lere koymasıdır. Bu nedenle üstesinden gelinemeyen kural dışı bir durum oluşur ve store.exe crash eder.

Event loglara düşebilecek olası hatalar:

Log Name: Application

Source: Application Error

Date: Date

Event ID: 1000

Task Category: (100)

Level: Error

Keywords: Classic

User: N/A

Computer: Computer

Description:Faulting application store.exe, version Version, time stamp TimeStamp, faulting module mdbrest.dll, version Version, time stamp TimeStamp, exception code 0xc0000005, fault offset
Offset, process id ProcessID, application start time Time.

Fix in detaylarına buradan ulaşabilirsiniz http://support.microsoft.com/kb/2716145.

C. Sinem Tosun

GAL’de Kullanıcılarınızın Resimlerini Görüntüleyin

TR Exchange Support Team — Tue, 12 Feb 2013 13:15:00 GMT

Teknolojinin hayatımıza bu kadar işlediği günümüzde insanların birbirleri ile olan iletişiminde ses ve görüntünün yeri vazgeçilmez. Exchange 2010 ve Outlook 2010 olan bir ortamda çalışanlarınızın resimlerini mailleşirken görmesi güzel olmaz mı? Evet diyorsanız birlikte nasıl yapıldığını görelim...

İlk olarak resimleri tutan attribute’un (thumbnailPhoto) replication’a tabi tutulması için aşağıdaki ayarların yapılması gerekiyor.

Schema Management Konsolunu açmak için schmmgmt.dll dosyasını register edelim:

Regsvr32.exe schmmgmt.dll

Artık MMC consolunda Add/Remove Snap-in dediğimizde Active Directory Schema’yı görüntüleyebiliriz.

Attributes altında thumbnailPhoto’yu bularak “Replicate this attribute to the Global Catalog” seçeneğini işaretleyelim.

İkinci işlem resimlerin belirli standartlara uygun hazırlanması ve Import-RecipientDataProperty cmdlet’ini kullanarak upload edilmesi.

thumbnailPhoto attribute’u 100 KB’a kadar olan resimlere izin verirken Import-RecipientDataProperty ile maksimum 10 KB’lık resimleri upload edebiliriz. Dolayısı ile kullanacağımız resimlerin size’ının 10 KB’ı geçmemesine dikkat etmeliyiz. Ayrıca komutun desteklediği format jpeg olduğundan, resimlerin bu formatta kaydedilmesi şart. (Eklenen her resmin active directory database'inin büyüklüğünü etkilediğini ve dolayısı ile replication trafiğini/backup-restore sürelerini temelde etkileyeceğini unutmamalıyız)

Örneğimizde test kullanıcısına C:\Temp\Pictures altında tuttuğum fixitman.jpg dosyasını yükleyeceğim:

Import-RecipientDataProperty -Identity test -Picture -FileData ([Byte[]]$(Get-Content -Path "C:\Temp\Pictures\fixitman.jpg" -Encoding Byte -ReadCount 0))

Test kullanıcısına mail atmak istediğimde contact kartında artık yüklediğimiz resmi görebiliriz.

Test kullanıcısının thumbnailPhoto attribute’una Active Directory Users and Computers’den baktığınızda içeriğinin diğer kullanıcılarda olduğu gibi boş olmadığını görebiliriz.

Cached mode ve OAB kullanıcıları için bir hatırlatma...Yüklemiş olduğumuz resimler GAL’de tutulur ve varsayılanda OAB güncellemesi yapsanız da localde tutulmaz. Çünkü Offline Address Book
ayarlarında ThumbnailPhoto atttribute’unun değeri varsayılanda Indicator’dır ve bu ayar resimleri göstermek için GAL’ı işaret eder, oab dosyasında böyle bir data yer almaz. ThumbnailPhoto atttribute’unun değerini Value’ya değiştirerek, OAB güncellemesi yaptığınızda tüm Active Directory kullanıcı resimleri oab dosyasında yer alacaktır.

Kullanıcı sayısı ve resimlerin boyutunu düşündüğünüzde ortamınızda performans sorunlarına neden olabilir, bu sebeple değeri değiştirmeden önce dikkatli davranmak gerekir. İlgili attribute’un value olarak değişitirlmesi için öncelikle değer kaldırmalı, ardından Value olarak set edilmesi gerekir.

Değeri kaldırmak için:

$attributes = (Get-OfflineAddressBook "Default Offline Address Book").ConfiguredAttributes

$attributes.Remove("thumbnailphoto,Indicator")

Set-OfflineAddressBook "Default Offline Address Book" -ConfiguredAttributes $attributes

Value olarak set etmek için:

$attributes.Add("thumbnailphoto,Value")

Set-OfflineAddressBook "Default Offline Address Book" -ConfiguredAttributes $attributes

Sevgi Sifyan

Exchange 2013 Yeni Rol Mimarisi

TR Exchange Support Team — Tue, 12 Feb 2013 12:51:00 GMT

Exchange 2007 ve Exchange 2010 da donanımsal kısıtlamalar yüzünden Exchange'I 5 role ayrılmıştı.

Bunlardan 3 tanesi zorunlu olmak üzere (*) şu şekilde sıralanırlar:

Edge Transport
Hub Transport (*)
Mailbox (*)
Client Access (*)
Unified Messaging

Bu roller birbirlerine sıkıca bağlıdırlar. Ancak Exchange 2013 de sunucuların fiziksel perfromansları (CPU) göz önüne alınarak rol sayısı ve rollerine birbilerine
bağlılığını azaltmak için farklı bir mimari geliştirildi. Bu mimari iki temel blok üzerine inşa edilmiştir; Cas array ve Database Availability Group (DAG). Exchange 2013 CAS sunucu 3 bileşenden oluşur, bunlar istemci protokolleri, SMTP ve UM arama yönlendirmesidir. CAS rölü temel anlamda sadece proxy işlemi gören bir sunucu haline getirilmiştir. Herhangi bir kullanıcı verisini tutmaz (veri dönüştürmesi yapmaz). Gelen isteği doğrular ve kullanıcının aktif veritabanı hangi Mailbox sunucudaysa oraya yönlendirir. Mailbox sunucu artık tüm datanın tutulduğu ve işlendiği sunucudur bu nedenle ilgili bütün bileşenleri ve protokolleri üzerinde tutar. Hiçbir istemci doğrudan Mailbox sunucuya bağlantı gerçekleştirmez; tüm bağlantılar CAS üzerinden RPC/HTTPS ile gelir.

Bu rol mimarisi ile kısaca neler kazandık:

CAS artık sadece proxy işlemi yaptığından namespace/ek isimlendirmelerin sayısı azaldı
Session stateless CAS tipimiz olduğu için Layer7 NLB ihtiyacımız yerini çok daha ucuz Layer4 NLB lere bırakabilecek. Bu ciddi bir maliyet avantajı getiriyor.
Tüm verinin Mailbox sunucuda işlenmesi rollerin aynı sürümlerinin olma zorunluluğunu kaldırıyor. Daha basit bir yapıya sahip oluyoruz, daha kolay planlanabilecek ve kolayca güncellenebilek.

C.Sinem Tosun

Direct Booking’e karşı Auto Accept Agent

TR Exchange Support Team — Wed, 29 Aug 2012 19:25:00 GMT

Exchange Resource Mailbox kavramı ile özdeşleşen Room Mailbox’lar şirketlerde oldukça yoğun kullanılan ve iş akışında önemli roller üstlenen bir özelliktir. Geçtiğimiz haftalarda room mailbox’larla epey bir haşır neşir olduğum için bu konuda kısa bir makale yazmak istedim. Direct booking nedir? Auto accept agent’dan farkı nedir? Hangisini kullanmak daha avantajlıdır? Her ortamda kullanılabilir mi? gibi sorulara cevap bulabileceğinizi umduğum bir yazı olacak. Bir Outlook teknolojisi olan direct booking, resource mailbox’ın direk olarak rezerve edilmesine dayanır. Organizatörün kullandığı Outlook bu noktada yapılan tüm işlemlerden sorumludur; toplantı saatlerindeki çakışmadan tutun ilgili isteğin resorce mailbox’ın takvimine işlenmesine kadar. Bu teknoloji artık Outlook tarafında vazgeçilmeye çalışılan bir teknoloji ve Outlook 2010’da registry’de bir değişiklik yapmadığınız sürece desteklenmemektedir.

Direct booking için gerçekleştirilmesi gereken adımlar:

Organizatörün resource mailbox üzerinde en az Editor hakkının olması gerekmektedir.

Resource mailbox’ın gelen toplantı isteklerine otomatik olarak kabul veya çakışma durumunda red olarak dönmesi için ilgili resource mailbox’ı Outlook’da açın ve File>>Options>>Calendar>>Resource Scheduling altında yer alan iki checkbox’ı işaretleyin.

Organizatörün resource mailbox’ı ilgili toplantı isteğinde“Resources” alanında belitmesi gerekir, “Required” veya “Optional” bunun için yeterli gelmeyecektir.

Outlook 2010 kullanıyorsanız ve direct booking ile çalışmak istiyorsanız registry’de aşağıdaki makalede belirtilen registry değişikliği yapılmalı:

Direct Booking does not successfully book a resource in Outlook 2010

Exchange 2003 SP1’den bu yana kullanabileceğiniz Auto Accept Agent ise Direct Booking’in yerine geçmiş durumda. Bu agent resource mailbox’ın free/busy bilgisini değil bizzat calendar schedule durumunu kontrol ederek toplantı isteklerini kabul eder veya reddeder. Böylece free/busy bilgisinin güncellenmesinde yaşanan bir gecikmede
Auto Accept Agent durumdan etkilenmeyecektir. Ayrıca işlemlerin server-side yapılması önemli bir avantaj sunar.

Exchange 2007 ve 2010’da ise daha mailbox oluşturulurken “Room Mailbox” seçimini yaparak diğer mailbox’lardan farklı attribute’lara sahip farklı türde bir mailbox oluşturmuş oluyoruz. Böyle bir mailbox’a ait user, interactive logon’a engel olmak için disable edilir ve user account password’ü otomatik olarak Exchange tarafından belirlenir. Set-CalendarProcessing ve Set-MalboxCalendarSettings (Exchange 2007’de) komutları resource mailbox ayarlarını yapmak için kullanabileceğimiz bazı komutlardır. Örneğin direct booking’de olduğu gibi toplantı isteklerinin otomatik cevabı için aşağıdaki gibi auto accept agent’ın enable edilmesi gerekir:

Set-CalendarProcessing “Room Mailbox” -AutomateProcessing AutoAccept

Exchange 2010’da resource mailbox ve Set-CalendarProcessing komutu ayrıntılı ele alınması gereken bir konu olduğu için daha fazla detaya inmeyeceğim. Ancak merak edenler için aşağıdaki technet sayfasını incelemelerini öneririm.

http://technet.microsoft.com/en-us/library/dd335046.aspx

Sevgi Sifyan

Exchange 2010 Service Pack 2 Update Rollup 4 ve birkaç önemli düzeltme

TR Exchange Support Team — Tue, 28 Aug 2012 07:12:00 GMT

Exchange 2010 Service Pack 2 için Update Rollup 4, 13 Ağustos 2012 tarihinde yayınlandı.
Bu güncellemeyle ilgili detaylı bilgilere http://support.microsoft.com/kb/2706690 adresinden ulaşabilir ve http://www.microsoft.com/en-us/download/details.aspx?id=30478 adresinden ise bu güncellemeyi indirebilirsiniz.

Yapılan düzeltmeler arasında önemli gördüklerimiz aşağıdaki gibidir:

Microsoft Exchange Server WebReady doküman görüntüleme özelliğindeki güvenlik açığı, uzaktan kod çalıştırılmasına neden olabilir. 2740358

Exchange 2010 mesajları Journal Mailbox’a aktarılmıyor. 2686540

EdgeTransport.exe prosesi sürekli olarak crash oluyor. 2709935

Üzerinde tam erişim hakkı olunmasına rağmen kullanıcının free/busy bilgisi görüntülenemiyor. 2701162
Exchange Server 2010 ve 2003’ün birlikte bulunduğu bir ortamda, eğer konu kısmında iki nokta üst üste “:” bulunuyorsa, mesajı bir mailbox’tan farklı bir mailbox’a aktardığınızda konu kısmında bulunan bilgilerin bir bölümü siliniyor. 2724188

Notlar:

Eğer Forefront Protection for Exchange kullanıyorsanız, kurulumdan önce ForeFront’u fscutility /disable komutuyla devre dışı bırakmalı, kurulum bittikten sonra da fscutility /enable komutuyla tekrar devreye almalısınız.
Kurulum sonrasında Exchange’in kritik servisleri tekrar başlatılacaktır.

Burak Petekkaya

OWA’ya bağlanırken IIS header bilgilerini saklamak

TR Exchange Support Team — Mon, 02 Jul 2012 18:45:00 GMT

*** Bu makalede anlatılan tüm yöntemler sistemleriniz üzerinde çok gerekmedikçe ve test edilmedikçe uygulanmamalıdır ***

*** Exchange üzerinde servis kesintisine yol açabilir ***

Exchange birçok son kullanıcı bağlantısını IIS üzerinden gerçekleştirir. Örneğin RPC over HTTP, ActiveSync, AutoDiscover gibi…HTTP request (istemciden sunucuya doğru yapılır)/response (sunucudan istemciye doğru yapılır) olarak çalışan ve 80 portunu kullanan
protokoldür. HTTP'nin SSL ile kullanıldığı koşul (HTTPS / 443 portu) gerçek güvenliği sağlar, bunun dışında HTTP şifre ve veri aktarmak için malesef güvenli değildir. Senaryomuzda sunucu Exchange ve istemci (Browser Internet Explorer) örneğin OWA ya bağlanan kullanıcı olabilir.

Exchange CAS (Client Access Server) rolünün üzerinde çalıştığı IIS, bir istemciye cevap verirken bazı header bilgilerini de gönderir. Örneğin;

Bu bilgiler sniffler'lar ve/veya network trafik yakalama yazılımları ile kolayca elde edilebilir. Yukarıda "Server:" ve "X-AspNet-Version:" gibi bilgiler açıkça görünüyor. Bunlar sniff edildiğinde sunucu hakkında bilgiler verir. Bu bilgiler güvenlik anlamında kiritk kabul edilir ancak eğer güvenlik yamalarını zamanında yüklüyor ve ataklara karşı tedbirler alıyorsanız (firewall / ids - ips vb) içiniz rahat uygulamalarınızı dış dünyaya açmanızda bir mahzur yok.

Bu bilgileri saklamanın iki yöntemi var. İlk olarak, X-AspNet-Version bilgisini şu şekilde gizleyeceğiz. Exchange kurulum dosyaları altında, ..\ V14\ClientAccess\Owa içerisindeki web.config dosyasına enableVersionHeader değeri “False” olarak
eklenir.

Sniffer ile tekrar baktığımızda:

Sıra "Server:" bilgisini saklamaya geldi. Bunun için iki farklı IIS versiyonu için farklı yöntemler var. IIS 7.x için URLRewrite uygulamasını IIS’e kurarak yeni bir Outbound kural yazılır.

Aşağıda bu kuralın ayrıntılarını görebilirsiniz.

Sniffer ile tekrar kontrol ettiğimizde "Server:" ’ın value değerini aldığını görüyoruz.

Exchange 2003'te IIS 6.x için ise URLScan uygulamasını kullanmamız gerekiyor.

URLScan kurulduktan sonra, URLScan dosyasında URLScan.ini’yi notepad ile açarak

RemoveServerHeader değerini 1 yaptığımızda, artık server bilgisi görünmeyecektir.

http://support.microsoft.com/kb/823175

http://technet.microsoft.com/en-us/library/aa995856(v=EXCHG.65).aspx

C. Sinem Tosun

VSS yedekleme testi nasıl yapılır

TR Exchange Support Team — Mon, 02 Jul 2012 06:24:00 GMT

Exchange üzerinde bulunan verilerin yedeklenmesi (backup) ve geri yüklenmesi (restore) başlıbaşına çok önemli bir konudur. Bir yedeğin sağlıklı alınması kadar restore işleminin başarılı bir biçimde yapılabilmesi de test edilmesi gereken önemli bir işlem. Exchange desteği olan (aware) diye adlandırdığımız yazılımlar exchange writer'ları kullanarak VSS teknolojisi ile yedek alırlar.

Yedekleme esnasında karşılaşılan sorunların büyük bölümünün nedeni, yazılımların uyumsuzluğu ya da bu yazılımlardaki yanlış bir ayar olabilmektedir. Bunun tespiti için, yani yedek alma sırasında sorunun VSS Writer’dan mı, disk sisteminden mi ve/veya yedekleme yazılımından mı kaynaklandığını anlayabilmek için Betest aracını kullanabilirsiniz.

BETEST, Windows SDK yada Volume Shadow Copy Service SDK 7.2 (sonraki versiyonlarda mevcut) içerisinde bulunan yardımcı bir araçtır. Aracı kolaylıkla bulabilir ve kurabilirsiniz. Kurulum işlemini exchange sunucunuza yada herhangi bir windows sunucuya yapmanızı önermeyiz. Bir desktop makinaya kurulum yapıldıktan sonra ilgili kütüphaneden BETEST aracı test yapılacak ortama taşınıp ve test yapılabilir.

Betest ile ilgili hatırlatmak istediğimiz önemli nokta, bu yazılımın sadece test amaçlı kullanılmasıdır. Bu programı hiçbir zaman normal bir yedekleme yazılımının ikamesi olarak kullanmayın. DPM gibi bir yedekleme yazılımınız yoksa Exchange Server yedekleri için Windows Server Backup’ı da kullanabilirsiniz

Betest ile yedekleme yapmak için uygulamanız gereken adımlar:

Volume Shadow Copy Service SDK 7.2’yi aşağıdaki web adresinden indirip kurulumunu gerçekleştirin.

http://www.microsoft.com/downloads/details.aspx?FamilyID=0b4f56e4-0ccc-4626-826a-ed2c4c95c871&displaylang=en

İşleme başlamadan önce, Exchange Writer’larının durumunu kontrol etmek gerekecektir. Bunun için komut satırında “VSSadmin list writers” komutunu çalıştırın. Eğer komutu çalıştırdığınız sunucuda sadece aktif durumda veritabanı varsa,
Microsoft Exchange Writer’ın listelendiğini göreceksiniz:

Pasif kopya da bulunuyorsa, Microsoft Exchange Replica Writer’da ayrıca listelenecektir.

Listelenen writerlar ile ilgili özellikle dikkat edilmesi gereken iki bilgi, State ve Last error durumlarıdır. Bunların sırasıyla Stable ve No error olmaları gerekmektedir.

Eğer bu writerlardan bir tanesi Failed olmuş ise, Information Store ya da Replication Servisini yeniden başlatarak, State’in Stable duruma geçmesini sağlayabilirsiniz. Information Store’un yeniden başlatılmasının kullanıcıların mailbox bağlantılarını kesintiye uğratacağı unutulmamalıdır.

Bu adımda, Betest’in yedekleme konfigürasyonunu alacağı Components.txt dosyasını oluşturacağız. Bunun için öncelikle Notepad programını açın.

Components.txt içerisindeki konfigürasyon dosyasının genel formatı aşağıdaki gibidir. Bunu alacağımız veritabanına uygun olarak değiştireceğiz.

"<WriterId>":
"<component-logical-path>" {"target" # "new
target", ...}, ..."<component-logical-path>" :
'"<subcomponent-logical-path>,...";

WriterId, Vssadmin list writers komutuyla gördüğümüz Writer Id’nin karşısındaki guid değeridir.

Geri kalan bölümlere ise, yedeği alınacak veritabanının mantıksal lokasyonu ve GUID’i girilmektedir. Yedeğini alacağınız veritabanının GUID’ini aşağıdaki komutla Exchange Management Shell üzerinden öğrenebilirsiniz:

Get-mailboxdatabase “database--ismi” | fl guid

Aşağıda, aktif bir veritabanı için oluşturulan Components.txt dosyası görülmektedir.

"{76fe1ac4-15f7-4bcd-987e-8e1acb462fb7}":"Microsoft Exchange Server\Microsoft Information Store\Mailbox1\a03774fa-434a-49cd-8f99-79d932f5be71";

Yukarıda, "{76fe..." Writer’ın idsi, "mailbox1" sunucunun ismi, "a0377..." veritabanının GUID numarasıdır. Eğer veritabanı pasif kopya ise, Microsoft Information Store’dan sonar birde Replica eklenmelidir:

"{76fe1ac4-15f7-4bcd-987e-8e1acb462fb7}":"Microsoft Exchange Server\Microsoft Information Store\Replica\Mailbox1\a03774fa-434a-49cd-8f99-79d932f5be71";

Yedekleme testini, aynı anda birden fazla veritabanı için yapmak isteyebilirsiniz. Bunun içinde, her bir veritabanının mantıksal path bilgisini, tırnak içerisinde ve virgülle ayırarak eklemeniz gerekmektedir:

"{76fe1ac4-15f7-4bcd-987e-8e1acb462fb7}":"Microsoft Exchange Server\Microsoft Information Store\Replica\MailboxSunucu\5df67a32-5f44-4585-ad0e-962b70f399d3","Microsoft Exchange Server\Microsoft
Information Store\Replica\MailboxSunucu\35e64d4a-7c6b-41f8-a720-068d2798b908","Microsoft Exchange Server\Microsoft Information Store\Replica\MailboxSunucu\5afe57ab-c14d-4bf9-8a69-78691fad5a33";

Dosya içeriğini yukarıda belirtildiği şekilde hazırladıktan sonra bunu Components.txt adıyla, C:\Program Files (x86)\Microsoft\VSSSDK72\TestApps\betest\obj\amd64 klasörü altına kaydedin.

Komut satırında betest’in kurulum klasörüne geçin. Betest, varsayılan olarak aşağıdaki lokasyonda bulunur:

C:\Program Files (x86)\Microsoft\VSSSDK72\TestApps\betest\obj\amd64

Aşağıdaki komutu çalıştırın

BETEST.exe /B /E /T 1 /S output.XML /C components.txt /D c:\betest > output.txt

Yukarıda komutta "c:\betest" yedeklerin oluşturulacağı path, output.txt ise yedekleme durumunun görüleceği ve yedekleme işlemi bittiğinde oluşacak olan log dosyasıdır. Sarıyla işaretlenen lokasyonu
istediğiniz gibi değiştirebilirsiniz. Aşağıdaki resimde, Betest tarafından yedeği alınan veritabanı için oluşturulmuş klasörler görülmektedir.

Yedeğin alınması sırasında hatayla karşılaşılması halinde, sorunun Exchange Writer’dan kaynaklandığı söylenebilir. İşlem sonucunda oluşan Output.txt dosyasını, inceleme yapılması için Microsoft Teknik Destek Merkezine iletebilirsiniz.

Burak Petekkaya

Exchange 2007 Service Pack 3 Update Rollup 7

TR Exchange Support Team — Tue, 22 May 2012 10:47:00 GMT

Exchange 2007 Service Pack 3 için Update Rollup 7, 16 Nisan 2012 tarihinde yayınlandı. Bu güncellemeyle ilgili detaylı bilgilere http://support.microsoft.com/kb/2655203 adresinden ulaşabilirsiniz. http://www.microsoft.com/downloads/details.aspx?FamilyID=51d1079c-b5e2-418d-9431-0e556917c5de adresinden ise bu güncellemeyi indirebilirsiniz.

Yapılan düzeltmeler arasında önemli gördüklerimiz aşağıdaki gibidir:

Mailbox için oluşturulan sunucu temelli kurallar, ilgili mailbox Exchange Server 2007’den Exchange Server 2010’a taşınıp, sonrasında 2007’ye geri taşındıktan sonra çalışmıyor. 2654700

Mailbox’lar başka bir veritabanı ya da farklı bir sunucudaki veritabanına taşındığında, bu işlem başarılı bir şekilde tamamlanamıyor. Taşıma sırasında mailbox sunucuda %100 CPU kullanımı olduğu görülüyor. 2677583

MSExchangePOP3 servisi crash oluyor. 2677979

Public Folder’da bulunan boş bir PR_URL_NAME öğesi, Exchange Server 2007 ve Exchange Server 2010 bulunan bir ortamda replike edildiğinde Store.exe crash oluyor. 2682570

Microsoft Exchange Replication servisi Active Directory ile iletişim kurduğunda, eğer active directory LDAP_PARAM_ERROR değerini gönderdiyse MSExchangeRepl.exe prosesi crash oluyor. 2694267

Exchange Server 2007 ve Exchange Server 2010’un birlikte bulunduğu ortamda, başka bir mailbox üzerinde Full Access hakkı olan bir kullanıcı, Outlook Web Application kullanarak bu mailbox’ı açamıyor. 2694274

Notlar:

Eğer Forefront Protection for Exchange kullanıyorsanız, kurulumdan önce ForeFront’u fscutility /disable komutuyla devre dışı bırakmalı, kurulum bittikten sonra da fscutility /enable komutuyla tekrar devreye almalısınız.

Kurulum sonrasında Exchange’in kritik servisleri tekrar başlatılacaktır.

Burak Petekkaya

Forest’lar arası Mailbox Move işlemi nasıl yapılır? – 2

TR Exchange Support Team — Mon, 14 May 2012 11:09:00 GMT

Makalenin ilk bölümünü buradan okuyabilirsiniz.

Bir önceki blog'da kaldığımız yer: "Prepare-MoveRequest.ps1 script’i ile tüm kullanıcıları veya belli bir OU altındaki kullanıcıları toplu olarak nasıl migrate ederim?" idi.

Toplu olarak mail-enabled user oluşturmak için source forest kullanıcıları csv formatında bir dosyaya export edip bu csv’yi kullanacağız.

Bunun için csvde aracını kullanarak belirli bir OU altındaki user’ları aşağıdaki gibi bir komutla export ettikten sonra Excel içerisinden dosyayı düzenlemeniz yeterli. Dosyada bizim için gerekli olan tek sütun Proxy Addresses sütunu olacak.

Csvde –f C:\Temp\MyUsers.csv –s Mtravel-DC.margiestravel.com –d “OU=My Users,DC=Margiestravel,DC=com”

Csvde ile neler yapılabileceği konusunda aşağıdaki linki inceleyebilirsiniz.

http://technet.microsoft.com/en-us/library/cc787549(v=WS.10).aspx

Hazırlamış olduğumuz csv dosyasının nihai hali:

İlgili csv dosyasını Temp klasörü altına kopyaladıktan sonra aşağıdaki komutu çalıştırdığımızda dosya içerisindeki tüm user’lar move mailbox işlemi için hazırlanmış oluyor.

Import-Csv C:\Temp\MyUsers.csv | Prepare-MoveRequest.ps1 -RemoteForestDomainController MTravel-DC.margiestravel.com -RemoteForestCredential $RemoteCredentials LocalForestDomainController Exch2k10-DC.Exchange2010.net -LocalForestCredential $LocalCredentials -TargetMailUserOU "Migrated from E2K3"

*Scriptte -LocalForestDomainController parametresi zorunlu olmayan bir parametre, ancak birden fazla DC’niz varsa kullanmanızı öneririz.

**Scriptle ilgili değinilmesi gereken diğer bir parametre, -UseLocalObject parametresi. Kullanıcılarınızı target forest'ta önceden farklı yöntemlerle oluşturmuş iseniz bu parametreyi kullanmalısınız. Script target domainde aynı kullanıcı mevcut ise, sadece ilgili attribute’ları var olan kullanıcının üzerine yazarak onu mail-enabled user haline getiriyor.

Prepare-MoveRequest.ps1ile kullanıcıların sadece bazı attribute’larının target forest'a kopyalandığını unutmayın, bu işlemin ardından kullanıcılarımın mailbox’ları move edilmeye hazır hale getirilmiş oluyor. Ancak migrate edilen kullanıcıların Prepare-MoveRequest.ps1 ile kopyalanmayan attribute’ları bulunmakta ve bunun için de ADMT’yi kullanarak migration işlemini tamamlamalıyız.

Aslında ADMT’yi kullanmadan şu anda mailbox-move işlemine geçebiliriz ve bir sorun da yaşamayız. Yalnız source forest’ta kullanıcıların halen erişmesi gereken kaynaklar varsa veya kullanıcı parolalarının da migrate edilmesini istiyorsanız ADMT kullanmalısınız. ADMT ile migration başlıbaşına ayrı bir konu olduğu için nasıl yapıldığı konusunda aşağıdaki dökümanı inceleyebilirsiniz.

Active Directory Migration Tool (ADMT)
Guide: Migrating and Restructuring Active Directory Domains

Migration sırasında dikkat edilmesi gereken noktalardan biri, target forest'ta kullanıcılarımız zaten var olduğu için “Migrate and merge conflicting objects” seçeneğini işaretlemek.Böylece conflict durumunda kullanıcıların gerekli attribute’ları ADMT tarafından update edilecektir.

Migration sonrası User1’in SIDHistory attribute’u artık boş değil. Aynı zamanda her iki domaindeki User1’in SID’lerini kontrol ettiğinizde aynı SID’lere sahip olduğunu göreceksiniz.

Son aşamamız kullanıcıların mailbox’larını taşımak. New-MoveRequest komutunu aşağıdaki parametrelerle kullandığımda User1’e ait mailbox 2010 ortamına taşınacaktır.

New-MoveRequest -Identity User1@margiestravel.com -RemoteLegacy -TargetDatabase "Mailbox Database 0744752288" -RemoteGlobalCatalog “MTravel-DC.margiestravel.com” -RemoteCredential $RemoteCredentials –TargetDeliveryDomain “Exchange2010.net”

Taşınan mailbox’ı yeni domainde açtığımızda artık @exchange2010.net SMTP adresini aldığını ve tüm maillerinin sorunsuz taşındığını doğrulayabiliriz.

Burada New-MoveRequest komutuna ait bazı parametrelerden biraz bahsedelim:

-RemoteLegacy: Source forest’da Exchange 2010 bulunmadığını (2003 veya 2007 olabilir) ifade eder ve bu parameter ardından bir değer girmek gerekmiyor. Eğer source forest bir 2010 sunucu içeriyorsa bu parameter kullanılmamalı.

-Outbound: Bu parameter işlemin forest’lar arası yapıldığını ve komutun çalıştığı ortamın source forest olduğunu ifade eder.

-Remote: Bu da Outbound switch’ı gibi move işleminin forest’lar arası olduğunu, ancak komutun çalıştığı ortamın target forest olduğunu ifade eder. Bu sebeple de Outbound ve Remote switch’leri aynı anda kullanılamaz.

Biz komutta RemoteLegacy parametresini kullandığımız için Outbound ve Remote parametrelerine ihtiyaç duymadık.

New-MoveRequest komutunu migrate edilmiş tüm kullanıcılar için nasıl çalıştırabilirim?

PrepareMoveRequest.ps1 scriptini tüm kullanıcılar için çalıştırırken kullandığımız csv dosyasını umarım silmemişsinizdir. Çünkü aynı dosyayı kullanarak kullanıcıların mailboxlarını da toplu halde taşıyacağız.

Import-Csv C:\Temp\MyUsers.csv | New-MoveRequest -RemoteLegacy -TargetDatabase "Mailbox Database 0744752288" -RemoteGlobalCatalog “MTravel-DC.margiestravel.com” -RemoteCredential $RemoteCredentials –TargetDeliveryDomain “Exchange2010.net”

Tüm mailbox’lar taşındıktan sonra EMC’da “Move Request” altında Completed durumda remote move request raporları görmelisiniz. Aşağıdaki komut ile tamamlanmış istek raporlarını kolayca temizleyebilirsiniz.

Get-MoveRequest -MoveStatus Completed | Remove-MoveRequest

Her versiyonda sistem yöneticilerinin işlerini biraz daha kolaylaştıracak yenilikler sunan Microsoft Exchange, bir sonraki sürümde bize daha ne avantajlar sunacak hep beraber göreceğiz.

Sevgi Sifyan

Exchange 2010 Service Pack 2 Update Rollup 2 ile gelen birkaç önemli düzeltme

TR Exchange Support Team — Fri, 11 May 2012 11:45:00 GMT

Exchange 2010 Service Pack 2 için yayınlanan Update Rollup 2’de (KB2661854), aşağıdaki sorunlar için önemli düzeltmeler yapılmıştır:

Internet’e bağlı olmayan bir Exchange Server 2007’ye proxy’lik yapan Exchange Server 2010’a Service Pack 2 Update Rollup 1 yüklendikten sonra, Outlook Web Application’a giriş yapan kullanıcı, “an exception thrown in the proxy” hatasıyla karşılaşıyor. KB2696913

Kullanıcı, OWA ya da EWS’i kullanan bir uygulama aracılığıyla recurring takvim öğesi açtığında, Exchange Server 2010 Client Access Server’larda bulunan MSExchangeServicesAppPool’un kullandığı W3wp.exe prosesi, CPU kaynaklarının tümünü kullanıyor. Bu sorun ortaya çıktığında, OWA ve EWS uygulaması Exchange Server 2010 sunucularına bağlanamıyorlar. KB2688667

Gönderilmiş Öğeler ’de bulunan mesajlar aynı PR_INTERNET_MESSAGE_ID’ye sahipler. Bu sorun aşağıdaki üç farklı durumdan birinde ortaya çıkmaktadır KB2592398:

Senaryo 1

Yeni bir mesaj oluşturdunuz ve bu mesajı Outlook Template dosyası olarak kaydettiniz.
Outlook Template dosyasını açtınız ve email olarak gönderdiniz.
Aynı template dosyasından tekrar email gönderdiniz.

Senaryo 2

Outlook ile email gönderdiniz.
Sent Items’da bulunan mesajı açıp bunu tekrar gönderdiniz.

Senaryo 3

Yeni bir mesaj oluşturup bunu Drafts klasörüne kaydettiniz.
Bu mesajı farklı bir klasöre kopyaladınız.
Her iki mesajı da gönderdiniz.

Bu senaryoların herhangi birinin gerçekleşmesi durumunda, Sent Items’daki iki mesaj da MFCMapi ile incelendiğinde, PR_INTERNET_MESSAGE_ID değerinin ikisi içinde aynı olduğu görülmekte. Ayrıca bu durumdan dolayı, gönderilen ikinci mesaj alıcılara ulaşmamakta ve bununla ilgili NDR gönderilmemekte.

Belli bir mailbox’ın Microsoft Outlook for MAC 2011’le erişimi, Set-CasMailbox ya da Set-OrganizationConfig komutlarıyla EwsAllowMacOutlook parametresi false yapılması suretiyle engellenmesine rağmen, bu kullanıcının login olabildiği görülüyor. KB2630808

Aşağıdaki senaryo dahilinde, bazı mobile cizhalardan mailbox’a erişilemiyor. KB2661277:

Trust kurulmuş iki Exchange Server 2010 forest’ı var.
Exchange Management Console ya da Exchange Management Shell aracılığıyla, Microsoft Server ActiveSync Virtual directory içerisinde ExternalURL ‘de adres konfigürasyonu yapılmış.
Kullanıcı uzak forest’da bulunuyor ve cihazın Exchange ActiveSync (EAS) versiyonu 12.1’den eski.
Exchange Server 2010 Client Access Server http 451 redirect cevabı gönderiyor. İlgili cihaz, http 451 redirect cevabını tanımadığı için yönlendirme başarılı olmuyor.

Aşağıdaki senaryoda, oluşturulan contact’ın isim bölümü Address Book’da boş olarak görünüyor. KB2678414:

Outlook online olarak kullanılıyor.
Public folder ya da mailbox’ta yeni bir contact oluşturuluyor.
Full Name bölümü boş bırakılıp, sadece Company bölümüne isim giriliyor.
Address Book açılıp buradan Contacts seçiliyor.

Önemli değişiklikler oldukça değinmeye çalışacağız.

Burak Petekkaya

Forest’lar arası Mailbox Move işlemi nasıl yapılır?

TR Exchange Support Team — Fri, 11 May 2012 11:26:00 GMT

Exchange 2003 /2007 veya 2010’da duran organizasyonunuzu değişik nedenlerden dolayı farklı bir organizasyona taşımak zorunda kalabilirsiniz. Böyle bir durumda Exchange 2010 bize Cross-Forest Move Request özelliği sayesinde iki farklı organizasyon arasında mailbox move işlemi yapmamıza olanak sağlamaktadır.

Forestlar arası migration işlemi için ortamın en az Exchange 2003 SP2 seviyesinde olması gerekmektedir.

Bu makalede Exchange 2003 ortamından 2010 ortamına mailbox migration işleminin nasıl yapıldığını göreceğiz. Öncelikle test yapımızdan bahsedelim:

Source domain: Exchange 2003 – Margiestravel.com

Target domain: Exchange 2010 – Exchange2010.net

Bu makalede Exchange 2003 domain’indeki My Users OU’su içerisindeki User1, User2 ve User3 kullanıcılarını Exchange 2010’da Migrated from e2k10 OU’suna mailboxları ile birlikte taşıyacağız.

Taşınacak kullanıcıların mailbox ve item adetleri Exchange System Manager üzerinden;

Yapılması gereken ilk işlem source domain’de bulunan kullanıcıların mail-enabled user olarak, gerekli attribute’ları da içeren bir şekilde target domainde yaratılması. İki yöntem kullanılabilir:

1- ILM (Microsoft Identity Lifecycle Manager) kullanarak forest’lar arası Galsync yapmak.

2- AD tool’ları ve bir script vasıtası ile user’ların yaratılması ve mail-enabled user olarak işaretlenmeleri.

Biz bu makalede ikinci yöntemi kullanacağız. Bunun için ilk olarak Exchange kurulumu ile gelen bir script ve ADMT aracını kullanarak kullanıcıları SID’leri ile birlikte target domain’e migrate edeceğiz.

Migration işlemi için iki domain arasında iki yönlü trust kurulması ve domain’ler arası isim çözümlemesinde sorun olmaması gerekiyor. Trust ve DNS forwarding konusunda aşağıdaki makaleyi referans alabilirsiniz:

http://technet.microsoft.com/en-us/library/cc778851(v=WS.10).aspx

http://technet.microsoft.com/en-us/library/cc773370(v=ws.10).aspx

Bundan sonraki işlem Exchange 2003’deki mailbox-enabled user’ların Active Directory ve mailbox attribute’larını Exchange 2010 ortamına kopyalayıp, orada da bu user’ların oluşmasını sağlamak.
Bunun için Exchange kurulumu ile gelen Prepare-MoveRequest.ps1 script’ini çalıştırmak gerekiyor.

Script’I target forest’ta çalıştırmak gerekiyor. Script source ve target forest’daki organizational admin credentiallarına gereksinim duyduğu için öncelikle Get-Credential ile username/password bilgilerini geçici olarak tanımlamamız gerekiyor.

2010 domain’i için gerekli credentialları $LocalCredentials olarak tanımladık, credentialların domain\username şeklinde, domain adı ile birlikte girilmesi gerekmektedir:

2003 domain’i için gerekli credentialları $RemoteCredentials olarak tanımladık:

Exchange 2003 domainindeki (Margiestravel.com) User1’i, diğer domaine gerekli attribute’ları ile kopyalayıp Exchange 2010 domaininde (Exchange2010.net) "Migrated from E2K3" OU’su altına migrate edelim.

*Komutu Exchange 2010 domaininde çalıştırdığımız için komutta geçen RemoteForest 2003 domainini, LocalForest ise Exchange 2010 domainine işaret etmektedir.

**Script, default Scripts klasörü altında yer aldığı için (C:\Program Files\Microsoft\Exchange Server\V14\Scripts) EMS’de bu lokasyondan komutu çalıştırmayı unutmayın.

Prepare-MoveRequest.ps1 -Identity User1@Margiestravel.com -RemoteForestDomainController MTravel-DC.margiestravel.com -RemoteForestCredential $RemoteCredentials -LocalForestDomainController Exch2k10-DC.Exchange2010.net -LocalForestCredential $LocalCredentials -TargetMailUserOU "Migrated from E2K3"

Target forest’ta “Migrated from E2K3” OU’suna baktığımızda User1’in bazı attribute’lar ile birlikte disabled olarak geldiğini görebilirsiniz: Taşınan attribute'lar ; legacyExchangeDN, mail, mailnickname, msExchmailboxGuid, proxyAddresses, X500, targetAddress, userAccountControl, userprincipalName

EMC’dan baktığınızda ise mail-enabled user olarak object yaratılmış durumda. Henüz mailbox-enabled user değil. Attribute’lardan SIDHistory’e baktığınızda bu alanın boş olduğunu göreceksiniz, çünkü bahsi geçen script SID’leri migrate edemez, sadece mailbox move işlemini yapabilmek için gerekli olan attribute’ları migrate eder. SID History’nin ADMT ile migration sonrası geldiğini göreceğiz.

Peki bu script ile tüm kullanıcıları veya belli bir OU altındaki kullanıcıları toplu olarak nasıl migrate ederim?

Makalemize devam edeceğiz..

Sevgi Sifyan

Alternatif bir mobil cihaz erişimi

TR Exchange Support Team — Thu, 10 May 2012 06:54:00 GMT

EAS (Exchange ActiveSync) mobil cihazlardan mailboxlara istenildiği zaman ve istenildiği yerden ulaşılmasına imkan veren bir iletişim protokolüdür.

Bu protokol cihazlarda direct push teknolojisini kullanır ve mailbox ile cihaz arasında sync işlemini yapar. Direct Push (over-the-air) encrypted HTTPs bağlantısı kurar böylece sunucu ve mobil cihaz arasında email ve diğer verileri sync eder. Daha ayrıntılı bilgi için buraya gözatabilirsiniz.

Microsoft-Server-ActiveSync virtual directory'si Client Access sunucu rolünde kurulmuş Web Server (IIS) rolüyle görülebilir. Bu klasörün içerisinde bulunan XML/XSD şemasıyla handshake işlemi gerçekleşecektir. İlgili fonksiyon dosyaları C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\sync\Xsd\v14.1
altından görülebilir.

Exchange 2007 ve Exchange 2010 versiyonlarında Activesync protokolü varsayılan olarak etkin halde gelir. Bu ayar sistem yöneticileri tarafından kaldırılabilir.

Kullanıcılar mobil cihazlarından EAS dışında EWS (Exchange Web Services) kullanarak ta mailboxlarına erişilebilirler. Client Access sunucu rolü ile EWS etkinleşmektedir. EWS ile EAS 'ın çalışma yöntemleri birbirinden farklıdır. EWS XML tabanlı bir protokoldür ve SOAP standartlarında hazırlanmış veri paketleriyle HTTPs protokolü aracılığıyla işlem yapar. Daha ayrıntılı bilgi için buraya bakabilirsiniz.

Nasıl ki EAS devre dışı bırakılabiliyorsa EWS kullanımı da Exchange 2010 da devre dışı bırakılabilir. Ancak bu Exchange 2007 de mümkün değildir. Devre dışı bırakmak için aşağıdaki komut kullanılabilir.

Bu nedenle EWS kullanarak sync yapan cihazlara sistem yöneticileri dikkat etmelidirler. Bazı mobil cihazlar ve yine bazı uygulamalar kullanılarak EAS etkisiz hale gelse bile, eposta alıp atmaya devam eder.

Uygulamanın EAS in etkisiz hale gelmesi durumunda EWS kullanarak epostaları indirmeyi başarır. EWS kullanırken de indirmeyi MSRPC kullanarak yaptığını
görebiliriz.

Bu uygulama Outlook Anywhere kullanarak EWS ile MSRPC gönderir ve verileri çeker. Bunun için EAS ın etkisiz hale geldiğini düşünmek yeterli değildir.

Örnek bir IIS logu:

1269 2011-06-01 06:47:09 172.10.10.10 POST /Microsoft-Server-ActiveSync/default.eas User=domain%5Ctest-user1&Cmd=FolderSync&DeviceId=615352495048485148515548545350&DeviceType=xxx&Log=Error:UserHasBeenDisabled_ 443 domain\test-user1 212.212.212.10 yyy(MSRPC)/6.5.0002 403 0 0 0

000547 2011-06-10 00:00:23 172.20.20.20 POST /ews/exchange.asmx SoapAction=GetEvents ;Version=0;RpcC=0;RpcL=0;LdapC=3;LdapL=0; 443 domain\test-user1 2.212.212.72 MSRPC 200 0 0 234

Bunu engellemek için ISA/TMG sunucuda /ews/* in publish edildiği kural üzerinde HTTP filtering yapılarak uygulamanın imzasını engelleyebiliriz.

ISA/TMG üzerinde /ews/* publish edilen kural üzerinde sağ tıklayarak “Configure HTTP” seçip “Signatures” alanında “Response Body” “GetItem” şeklinde filtreleme yaptığımızda ilgili uygulamanın eposta alıp verme işleminin durması sağlanır.

ISA Server 2004 Filtering ile ilgili buradan daha ayrıntılı bilgiye ulaşabilirsiniz.

C. Sinem Tosun

Outlook 2010 ile gelen yeniliklerden birkaçı

TR Exchange Support Team — Fri, 04 Feb 2011 16:06:00 GMT

Outlook 2010 office ürün ailesinin yeni bir üyesi. Ürünle birlikte aşağıdaki değişiklikler ve yenilikler bizleri etkileyecek. Tabiki bunlara ilave edecek birkaç özelliğin daha olduğunu belirtmeme gerek yok.

1- Offline Store / Personal Folder's gibi değişiklik isimler yerine artık OST / PST file’larının her ikisine birden Outlook Data File diyoruz. Bu bir teminolojik değişiklik.

2- PST file’ların manual oluşturulma yeri artık; “My Documents\Outlook Files”. Ancak yeni profile oluşturmada “pop3 hariç” diğer konfigürasyon modellerinde eski yer hala kullanılmaya devam edecek “%localappdata%\Microsoft\Outlook”.

3- Her PST oluşturulmasında outlook bize PST tipini sorardı, artık bu seçenek iptal edildi ve her yeni PST oluşturulması by default Unicode PST oluşuyor. Ancak ANSI pst’de hala oluşturulabilir.

4- Outlook 2010’da maximum PST file size’ı 50GByte olarak belirlendi. Ancak tabiki bu değer ilgili registry key ile yükseltilebilir. Değer eski outlook versiyonunda 20GByte idi. bknz. KB: 832925

5- PST yönetimi ile ilgili bir kısım geliştirmeler mevcut, örneğin account’lar arası item kopyalamanın ve/veya file system’e kopyalamayı engellemeler gibi.

Belikde PST yönetimi için birkaç kritik registry keyden bahsetmek gerek.

DisablePST --- ile kullanıcının PST eklemesini engelleyebiliyoruz

PSTDisableGrow ---- ile PST’lere ulaşılmasını ancak içine mail taşınmasını engellemiş oluyoruz.

DisableCrossAccountCopy --- Account’lar arası mail taşınmasını engeller.

6- Belkide en önemli değişiklik, PST file’ların network share üzerinde tutulması artık destekleniyor.

7- OST dosyaları yani "Cached Mode" artık terminal server’lar üzerinde yine desteklenir durumda.

8- Yine önemli bir değişiklik aynı outlook profile’da birden fazla exchange account ayarlanabilir olması. Ancak tabiki aynı anda en fazla bir account primary olabilir. Herbir account’a ait veriler farklı bir .OST dosyasında tutulur. Ayrıca her iki account’unda aynı özellikte olması gerekiyor (cached yada online)

Office Communication Server 2007 R2 ve Exchange Server 2010 Outlook Web App Bağlantısı

TR Exchange Support Team — Thu, 05 Aug 2010 14:36:00 GMT

Exchange Server 2010 ile birlikte gelen yeni özelliklerden birisi de, Outlook Web App içerisinden yapılabilen OCS bağlantısıdır. Bu sayede Office Communicator üzerinde bulunan kullanıcı listenize ulaşabilir, mevcudiyet bilgisini görünteleyebilir ve anlık mesajlaşma yapabilirsiniz.

Bu bağlantının gerçekleştirilebilmesi için en az Office Communicator Server 2007 R2 olmalıdır. Exchange Server 2010 ve OCS arasındaki bağlantı için aşağıdaki Dll’lerin Client Access Server üzerinde bulunması gerekmektedir. Bu dosyalar Exchange Server 2010 ile birlikte gelmemekle beraber http://go.microsoft.com/fwlink/?LinkID=135129 adresinden temin edilebilir (msi paketi).

CWA DLL

OCS DLL

SIP DLL

Outlook Web App üzerinden OCS kullanımında bazı sınırlamalar mevcuttur. Örneğin, chat sırasında dosya alma ve gönderme yapamazsınız ve ses ve görüntü paylaşımı için Office Communicator’a ihtiyaç bulunmaktadır.

Nasıl yapılandırılır ?

Exchange Server 2010 ve OCS 2007 R2 arasındaki bağlantı için aşağıdaki 3 adımın gerçekleştirilmesi gerekmektedir.

1. OCS 2007 R2’nin hazırlanması.

2. Exchange Server 2010 Client Access Server’ın yapılandırılması.

3. OCS 2007 R2 kullanıcı yapılandırılması.

1. OCS 2007 R2’nin hazırlanması.

Buradaki ilk adım OCS 2007 R2 server ile Exchange Server 2010 OWA IM entegrasyonu arasında trust kurulmasıdır. Bunun için OCS 2007 R2 üzerinde server isminin özelliklerinde Front End Properties bölümüne girilir ve burada Host Authorization bölümünde Exchange Server 2010 CAS server’ın FQDN ve IP bilgisi eklenir. Burada yapılması gereken bir nokta Throttle As Server ve Treat As Authenticated kutularının işaretlenmesidir. Eğer bir NLB yapısından bağlanılıyor ise burada virtual isminde eklenmesi CAS sunucu üzerinde yapılacak bağlantının başarılı olması açısından önemlidir.

2. Exchange Server 2010 Client Access Server’ın yapılandırılması.

Exchange Server 2010 Client Access Server üzerinde ise Web.Config dosyasında ilgili bağlantı için bazı değişikliklerin ve eklemelerin yapılması gerekmektedir. Burada gerekli bileşenler:

a. Exchange Server 2010 ve OCS 2007 R2 arasındaki iletişim için gerekli sertifika.

b. IM entegrasyonu aktif edilmesi

c. IIS restart edilmesi.

a. Exchange Server 2010 ve OCS 2007 R2 arasındaki iletişim için gerekli sertifika.

Sertifika bilgisi olarak Issuer ve Serial Number gerekmektedir. Bu bilgileri get-exchangeCertificate | fl ile alabilirsiniz.

b. IM entegrasyonu aktif edilmesi

http://go.microsoft.com/fwlink/?LinkID=135129 adresinden indirilen msi dosyası kurulur. Kurulum ardından vcredit_x64.exe, UcmaRedist.msi ve CWAOWASSP.msi çalıştırılır.

Web.config dosyası içerisinde ise aşağıdaki değişiklikler yapılır.

Bu bölümlere gerekli bilgiler çift tırnak içerisinde yazılır ve kaydedilir.

Ardından OWAVirtualDirectory üzerinde InstantMessaging enable edilmelidir.

Set-OwaVirtualDirectory –identity “<servername>\owa (Default Web Site)” –InstantMessagingType:ocs –InstantMessagingEnabled:$true

Bu aşamadan sonra Web.Config dosyasındaki yapılan değişikliğin aktif olması için IIS restart edilmesi gerekmektedir.

Eğer sertifika Serial Number ile ilgili bir yanlışlık yapmadı iseniz, Outlook Web App üzerinden OCS bağlantınız artık çalışıyor.

Kullanıcıların bu özelliği kullanmaları için gerekli yetkilendirmelerini ise Segmentation ile yapabilirsiniz. Segmentation ile ilgili detaylı bilgiler diğer bir blog içerisinde olacaktır.

Volkan Günaydın

Exchange Server 2010’da Active Sync Problemi

TR Exchange Support Team — Fri, 12 Mar 2010 13:58:00 GMT

Exchange Server 2010’nun yaygın bir şekilde kullanılmaya başlanmasına paralel olarak çok az da olsa problemler gelmekte ve onların bazılarının çözümlerini burada vermeye devam ediyoruz. Bu makalede mobil iletişimi etkileyen bir problem ve çözümünü veriyor olacağız. Microsoft ActiveSync Push teknolojisi ile mailler aynı anda mobil cihazınıza gelmektedirler. Çoğu kişinin bildiğinin tersine, ActiveSync’i Exchange üzerinde etkin hale getirmek çok kolaydır.

Aşağıdaki senaryomuzda Exchange Server 2010 kullanıyorsunuz ve event viewer’da aşağıdakine benzer bir hata alıyorsunuz.

An exception occurred and was handled by Exchange ActiveSync. This may have been caused by an outdated or corrupted Exchange ActiveSync device partnership. This can occur if a user tries to modify the same item from multiple computers. If this is the case, Exchange ActiveSync will re-create the partnership with the device. Items will be updated at the next synchronization.

URL=/Microsoft-Server-ActiveSync/default.eas?User=TEST&DeviceId=xxx&DeviceType=TEST&Cmd=FolderSync

--- Exception start ---

Exception type: Microsoft.Exchange.AirSync.AirSyncPermanentException

Exception message: The device container ExchangeActiveSyncDevices for the user ‘TEST' in Active Directory couldn't be created.

Exception level: 0

HttpStatusCode: 500

AirSyncStatusCode: 111

XmlResponse:

This request does not contain a WBXML response.

Exception stack trace: at Microsoft.Exchange.AirSync.ADDeviceManager.CreateActiveSyncDeviceContainer(Boolean retryIfFailed)

at Microsoft.Exchange.AirSync.ADDeviceManager.CreateActiveSyncDevice(GlobalInfo globalInfo, ExDateTime syncStorageCreationTime, Boolean retryIfFailed)

at Microsoft.Exchange.AirSync.Command.UpdateADDevice(GlobalInfo globalInfo)

at Microsoft.Exchange.AirSync.Command.WorkerThread()

--- Exception end ---.

Bu event sonrasında mobil cihaz şifre sormaya devam eder ve ne yazıkki foldersync aşaması geçilemez.

Burada yapılabilecek şeylerden birisi ise, ilgili kullanıcının Active Directory Users and Computers’de Güvenlik ile ilgili özelliklerinin kontrol edilmesidir.

Bunun için öncelikle view bölümünden, “Advanced Features” özelliği açılır.

Ardından ise aşağıdaki bölümün işaretli olup olmadığı kontrol edilir.

Eğer “Include inheritable permissions from this object’s parent” işaretli değil ise işaretlenmelidir.

Bir başka konuda görüşmek üzere, hoşçakalın.

Volkan Günaydın

Exchange Server 2010 'da -Configurationonly parametresi nerede ?

TR Exchange Support Team — Wed, 03 Mar 2010 14:36:00 GMT

Exchange Server 2007 üzerinde felaket (disaster) senaryolarından dönüşte en çok kullanılan Exchange Management Shelll cmdlet’i move-mailbox ile kullanılan –configurationonly parametresi idi. Bu parametre ile tamamen yok olmuş bir database’in kullanıcılarının başka bir yeni açılmış database üzerinde taşınmaları sağlanabiliyordu.

Burada fiziksel bir move işlemi olmamakta, sadece mailboxların yeni lokasyonları belirtilmektedir. Bu parametre ayrıca Exchange Server 2007 ile birlikte gelen “Database Portability” sayesinde, elimizde “clean shutdown” şeklinde olan bir mailbox store database’in başka bir server üzerinde mount edilmesi sonrasında, Outlook’ların açıldıklarında bu yeni sunucuyu kullanabilmelerini sağlıyordu.

Bu özellikle bilgi işlem tarafında yapılan SLA (Service Level Agreement) anlaşmalarında belirtilen sürelere riayet edilmesini kolaylaştıran bir özellik olması açısından da önemlidir.

Exchange Server 2010’a geldiğimizde artık move-mailbox cmdlet’inin yerini new-moverequest cmdlet’i aldı. Bununla birlikte, bu cmdlet parametreleri arasında -configurationonly parametresi bulunmamaktadır. Elbette Exchange Server ürün ekibi böyle önemli bir özelliği devre dışı bırakacak değillerdi. Exchange Server 2010 üzerinde yukarıda anlattığımız özelliği aşağıda gösterdiğim şekilde kullanabilirsiniz.

Örnek durum:

Tüm mailboxlar DB1 adlı database’de iken bunları DB2’ye taşımak istiyorsunuz.

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

Yukarıda verdiğim örnek dışında ihtiyacınıza göre, farklı senaryolar için set-mailbox cmdlet’ini kullanabilirsiniz.

Volkan Günaydın

Exchange Server 2010 ’da Exchange Management Console ve Exchange Management Shell açılamaması problemi

TR Exchange Support Team — Thu, 25 Feb 2010 14:31:00 GMT

Exchange Server 2010 release olmasının ardından yaygın bir biçimde kullanılmaya başlandı ve çok olumlu geri dönüşler almaya başladık. Bu makalede bazı sistem adminlerimizin karşılaştığı Exchange Management Console ve Exchange Management Shell açılırken alınan hataların nasıl düzeltilebileceği ile ilgili detayları veriyor olacağım.

Exchange Management Console yada Exchange Management Shell açmaya çalıştınız ve aşağıdakine benzer bir hata aldınız.

Connecting to remote server failed with the error message: The WinRM client received an HTTP status code of 502 from remote WS-Management service. For more information, see the about_Remote_Troubleshooting Help topic. It was running the command 'Discover-ExchangeServer -UseWIA $true -SuppressError $true'

Bu hatada aslında bize ipucu veren bölüm HTTP 502 statüs kodunun alınmasıdır. Burada winhttp proxy ile ilgili bir durum olduğunu gösteriyor.

Windows Server 2008’de winhttp düzenlemeleri netsh komutu ile yapılmaktadır.

Netsh winhttp show proxy

Bu komut ile işletim sisteminin kullandığı bir winhttp proxy olup olmadığını görebiliriz.

Ayrıca,

HKEY_LOCAL_MACHINE SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Connections WinHttpSettings

Registry key üzerinde de bu proxy adresini görebiliriz.

Burada mevcut EMC ve EMS açılmama problemini gidermek için, proxy adresini kaldırmamız gerekmektedir.

Aşağıdaki komut ile bunu kaldırabiliriz.

Netsh winhttp reset proxy

Bu komutun ardından, EMC yada EMS tekrar açılmaya çalışıldığında, başarılı bir şekilde açıldığını göreceksiniz.

Exchange Server 2010 ile ilgili ilginç sorunlar ve çözümleri olduğunda, burada paylaşmaya devam edeceğiz.

Volkan Günaydın

Exchange Management Shell ile Public Folder Yönetimi

TR Exchange Support Team — Thu, 28 Jan 2010 06:59:00 GMT

Public Folder’lar Exchange Server dünyamızda yoğun olarak yönetimini yaptığımız bileşendir. Public Folder’larun günlük yönetiminde Exchange Management Shell (EMS), kullanılması işlerimizi biraz daha çabuklaştırabilir düşüncesi ile aşağıda bazı ipuçlarını sizinle paylaşacağım.

Bildiğiniz gibi Public Folder’ların oluşturulması için öncelikle organizasyonumuzda bir Public Folder (PF) veritabanı’nın bulunması gerekmektedir. Peki şimdi EMS ile bu nasıl gerçekleştirilir buna bakalım.

New-PublicFolderDatabase

Bu cmdlet ile aşağıdaki gibi PF oluşturulur.

New-PublicFolderDatabase –Name “PFDBName” –StorageGroup “Second Storage Group”

EMS üzerinde yukarıdakikomut çalıştırıldığında, database dismounted olarak oluşur.

Bu PF Database’i mount etmek için ise aşağıdaki komut çalıştırılır.

Mount-Database –Identity “PFDBName”

Şu anda boş bir PF Database oluşturmuş olduk. Bu PF database’in bazı özelliklerini değiştirmek istersek bunuda aşağıdaki cmdlet ile yapıyoruz.

Set-PublicFolderDatabase

Aşağıdaki örnek komut Retention ayarlarımızı düzenlemek içindir.

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

Aşağıdaki örnek komut ile de PF database içindeki tüm public folder’ların storage quota değerlerini 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"

İkinci olarak oluşturduğumuz PF database içerisine Public Folderların nasıl oluştuğuna bakalım.

New-PublicFolder –Name “PFName”

Public Folder’lar içerisinde bir de mail enabled public folderlar bulunmaktadır. Burada iki farklı cmdlet kullanıyoruz.

Set-PublicFolder (Mail enabled değil)

Set-MailPublicFolder (Mail enabled)

Aşağıdaki birkaç örnekte Public Folder’ların nasıl düzenlendiğini göreceksiniz.

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

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

Peki bu aşamada bir public folder nasıl mail enabled yapılır.

Enable-MailPublicFolder –Identity “\test”

Bu mail enable public folder’ın özellikleri aşağıda görüldüğü gibi değiştirilebilir.

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

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

Son olarak Pulic Folder’ların özelliklerinin görüntülenmesinin nasıl yapılacağına değineceğim.

Get-PublicFolder

Tüm sistem folder’larının görüntülenmesi için:

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

Public Folder’lar ile ilgili yukarıda verdiğim bilgilerin faydalı olacağını umarak diğer bir konuda görüşmek üzere diyorum.

Volkan Günaydın

Exchange 2010 ve Powershell 2.0 ile uzaktan yönetim

TR Exchange Support Team — Fri, 15 Jan 2010 14:29:00 GMT

Birarada derli toplu uzak bağlantının anlatıldığı bir exchange 2010 guide yada powershell kaynağı bulamadım ve bu nedenle bu konu üzerine bir makale yazmak istedim. Exchange 2010 diğer exchange server versiyonları gibi uzaktan yönetilebilir ancak önemli bir farkla..

Exchange 2010 yönetimi Powershell 2.0 üzerine bina edilen ve winRM ile desteklenen bir yapıya sahip. Bu iki component sayesinde powershell ve winrm yüklü bir makinadan exchange 2010 ile ilgili hiçbirşey kurmadan server yönetilebilir.

Powershell (PS) ve WinRM windows 7 ve Windows 2008 R2 ile birlikte geliyor ancak diğer windows versiyonlarına ayrıca kurulması gerekiyor.

Powershell, bits ve WinRM'in oluşturduğu bütünlüğe artık windows management framework (WMF) diyoruz.

https://connect.microsoft.com/windowsmanagement/Downloads

Not: PS 1.0 ve PS 2.0 aynı makinada birlikte olamaz.

Örneğin WMF yüklü bir windows7 üzerinden powershell çalıştırıldıktan sonra aşağıdaki işlemler yapılarak Exchange 2010 bağlantı sağlanarak yönetim ger��ekleştirilebilir.

Eğer farklı bir domain'de ve/veya yetkisiz bir kullanıcı ile bağlanmayı deniyorsak öncelikle yetkili kullanıcı haline gelmeliyiz. Bunun için yetkili kullanıcı credential'ları collect edilir.

Remote olarak bağlanacak username ve password girilir. Username girilirken "domain\username" formatı yada UPN logon formatı kullanılabilir. Bağlantı yapacak user'ın remote shell bağlantı izni bulunmalı. Bunu Get-User command let ile görebiliriz.

Yukarıdaki örnekte administrator kullanıcısının RemotePowerShellEnabled = TRUE olduğu görülüyor... Yani gerekli iznimiz var...

Çalışmayı yapacağımız makinada exchange script'lerin çalışması için local güvenlik policy'imizi default Restricted 'tan Unrestricted 'a çevirebiliriz. Ancak güvenlik ile ilgili önemli bir konu olduğunu ve operasyon sonrasında kapatmanızda fayda bulunduğunu hatırlatmalıyım.

Not: execusiton policy'i default değerine almak için ; "Set-ExecutionPolicy Restricted" uygulanmalı...

Yukarıda aldığımız credential ile session açıyoruz..

Bazı durumlarda HTTPS bağlantı zorunlu olabilir böyle durumlarda server'ın üzerindeki iis sertifikası client tarafında da trusted olmalı ayrıca tarih ve isim bilgisi doğru olmalıdır.

Yukarıda Sami adlı server'a bağlantı yapılmaktadır. Açtığımız connection session'ı import etmek geriye kalıyor.

Powershell ISE arayüzünden aynı görüntü ve import anı...

Komut çıktısı...

Böylece tüm exchange management yüzlerce cmd-let ve script local ps'mizden çalıştırılabilecektir.

Farklı bir exchange command ISE ekranında.

Bağlantıda sorun olması durumda aşağıdaki komut ile detaylı bir yardım klavuzuna ulaşabilirsiniz..

Get-Help about_remote_troubleshooting

Örneğin; Eğer timeout alıyorsanız ve server performansınızdan endişeliyseniz timeout süresini arttırmak isteyebilirsiniz.. Bunun için; "New-PSSessionOption -OperationTimeOut 100000" 100 sn olarak set etmiş olduk.

Peki ya disconnect;

Mevcut session'ları listelemek için;

Get-PSSession command-let kullanılabilir

İlgili session'ı kapatmak için;

Remove-PSSession $ connection / Id

denilmesi yeterlidir...

Umarım işinize yarar bir makale olmuştur..

Kubilay Ekici

Exchange Server 2010 Client Access Server

TR Exchange Support Team — Mon, 11 Jan 2010 15:09:00 GMT

Exchange Server 2010 ile ilgili mimari açıdan en büyük değişikliklerden birisi de, CAS (Client Access Server) adını verdiğimiz sunucu rolünündedir. Exchange Server 2010’da MAPI ve Dizin Hizmetleri CAS sunucuları üzerinden verilmektedir. Bu hizmetin adı RPC Client Access hizmetidir.

Bunun anlamı aslında artık MAPI istemcilerinin, Mailbox sunucu’ya direkt olarak bağlanmamalarıdır. Yani, MAPI clientlar önce CAS sunucuya bağlanırlar ve buradan da Active Directory ve Mailbox sunucuya bağlantı gerçekleştirilir. Dizin hizmetleri için, Outlook istemcisi CAS sunucu üzerindeki NSPI endpoint bağlantısı ve ardından da NSPI’da Active Directory sürücüsü ile AD ‘ye bağlanır. Bu aslında Exchange Server 2007 de bildiğimiz RPC over HTTPs bağlantısına çok benzerdir.

Bu bağlantı çeşidinin (MAPI in the middle tier) bazı avantajları bulunmaktadır. Örneğin, failoverlarda client tarafında çok daha kısa sürelerde unresponsive durum yaşanmasını sağlayacaktır. Ayrıca, Exchange Server 2007’de bir mailbox sunucu 64000 bağlantıya izin verirken, Exchange Server 2010’da bu sayı 250000 RPC bağlantısıdır.

Burada acaba hangi Outlook clientlar Exchange Server 2010 CAS’a bağlantı yapabilir sorusu aklınıza geliyor ise cevap Outlook 2003 den itibaren hepsi (Outlook 2003,2007,2010). Burada dikkat edilmesi gereken bir nokta ise, Outlook 2003 clientların RPC bağlantılarında encryption kullanmalarıdır. Çünkü CAS üzerinde default olarak RPC bağlantıları için encryption gereklidir. Bunu aşağıdaki komutu çalıştırarak görebilirsiniz.

Get-RpcClientAccess |fl

Burada Encryption Reuired True olarak gözükecektir. Outlook 2007 ve Outlook 2010 clientlarda böyle bir problem bulunmamaktadır (By default encryption enable’dır).

Şimdi şöyle bir senaryo düşünelim:

Ortamınızda Outlook 2003 clientlar var ve siz Exchange Server 2010 upgrade yaptınız. Tüm profiller yeniden mi düzenlenecek?

Burada,

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

komutu ile Outlook 2003 clientların bağlantısını gerçekleştirebilirsiniz. Konu ile ilgili çok fazla detay olan makaleyi aşağıda ekliyorum. Bu makaleye çok fazla ihtiyaç duyulacağını düşünüyorum.

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

Burda önemli olan bir nokta ise: Eğer public folder kullanıyor iseniz, bu ayarı aynı zamanda Mailbox sunucu üzerinde de yapmanız gerekmektedir. Çünkü public folder erişimi direkt olarak mailbox sunucu üzerindeki RPC Client Access servisi üzerinden yapılmaktadır.

Bir sonraki makalede yeni CAS sunucumuzun diğer özelliklerine bakıyor olacağız.

Volkan Günaydın

Exchange 2007 service pack 2’nin getirdiği audit özellikleri

TR Exchange Support Team — Thu, 10 Sep 2009 15:12:00 GMT

Audit güvenlik ihtiyaçları nedeniyle giderek artan bir oranda ihtiyaç haline geliyor. Bu anlamda exchange server üzerinde bulunan mailbox'ların güvenliği ve izlenmeside önemli.

Kim kimin adına mail gönderebiliyor, kimler kimlerin maillerini görebiliyor vb sorular giderek daha sık sorulmaya başlandı.

Exchange 2007 service pack 2 ile yeni auditing özellikleri gelmektedir. Bu özellikler ile exchange auditing eksikliğini gidermiş oluyor ve böylece store içerindeki hareketi loglayabiliyoruz.

Yeni diyebileceğimiz audit'i kısaca dört başlık altında toplayabiliriz.

Folder Access --- Herhangi bir folder’a erişim durumunda

Message Access --- Bir mesajın açılması durumunda

Extended Send As --- Mailbox enabled user’ın mesaj göndermesi durumunda

Extended Send On Behalf Of --- Mailbox enabled user için On Behalf Of kullanımı durmunda

Loglama sağlamaktadırlar..

Bu loglar için yeni bir event log tipi oluşturuyoruz ve logları "Exchange Auditing" adlı event log biriminde biriktiriyoruz. Tabi butip eventlerin sayısı çok fazla olabileceği ve bu veriler kaybedilmek istenmeyeceği için ihtiyaçlarımıza göre özellikle event file büyüklüğüne dikkat etmek gerek.

Aşağıda 4 değişik eventten birer örnek ve kısa açıklamalar var.

Folder Access:

Event ID 10100 Veli Ali’nin Outbox’ını açmış. Her folder için ayrı ayrı event düşürülebildiğinden çok net olarak erişimin nereye yapıldığını anlayabiliyoruz.

Böylece eski 1016 eski tip event arayışına gerek kalmıyor.

Message Access:

Veli Ali’nin mailbox’ındaki 30***EAD@e2k7-dc.e12.local message id’li mesajı ADI ve IP’si belirli client’tan outlook.exe’yi açmış.

Not: Mesaj silmeler özel bir event ile takip edilmez sadece access event’i yazılır.

Send As:

Aşağıdaki eventte Veli, Ali adına mail göndermiş yine client adı,ip’si ve message ID net olarak anlaşılıyor.

Hangi mesajı gönderdiğini hangi client’ı kullandığını ve ip’sinin o anda ne olduğunu yine event’ten ek olarak edinebiliyoruz.

Send On Behalf Of:

Veli Ali adına yetkili kılınmış ancak send-as değil send on behalf. Bunuda aşağıdaki event’ten anlıyoruz.

Service Pack 2 release edildi.

Download:

http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=4c4bd2a3-5e50-42b0-8bbb-2cc9afe3216a

Release Notes:

http://www.microsoft.com/downloads/details.aspx?FamilyID=ee7829a3-0ae8-44de-822c-908cd1034523&displaylang=en

Kubilay

Exchange 2007 autodiscover servisi - 1

TR Exchange Support Team — Tue, 21 Jul 2009 14:14:00 GMT

Autodiscovery servisi outlook 2007 client'lar için otomatik profile konfigürasyonu ve offline address book gibi client bağlantılarında ihtiyaç duyulan ek URL'leri sağlayan servisin adıdır. Bir windows servisi olarak çalışmaz ancak Client Access Server (CAS) rolünün bir alt fonksiyonu olarak exchange 2007 ile birlikte gelir.

Exchange 2007 kurulduğunda self signed sertifika edinir. Bu nedenle autodiscover dış bağlantıda çalışmaz ve exchange üzerinde ek konfigürasyona ihtiyaç duyulur. İç networkten ise kurulum sonrasında küçük eksiklikler ile de olsa genellikle çalışacaktır. Bunun nedeni şirket içi bağlantılarda autodiscover erişiminin Service Connection Point (SCP) üzerinden yapılabilmesidir.

Dış bağlantının doğru biçimde çalışabilmesi için tıpkı Outlook Anywhere'de olduğu gibi sertifika hatasının hiçbir şekilde bulunmaması gerekir. Bu nedenle CAS server'lara doğru biçimde internal yada external CA 'den alınmış sertifikalar kurulmalıdır. Sertifikaların trusted bir publisher'dan sağlanması, isminin doğru olması ve tarih aralığının geçerli olması zorunlu kurallardır. Bunlardan özellikle isimlendirme genellikle karşımıza çıkan temel hata olarak kendini gösteriyor. Örneğin; contoso.com autodiscover servisini kullanmak istesin. Bu durumda contoso.com sertifikasının en azından contoso.com yada autodiscover.contoso.com adınıda subject yada subject alternative name olarak içermesi gerekiyor.

Sertifikanın subject alternative name kısmının içermesi gereken / önerilen temel örnek isimler şunlardır;

webmail.contoso.com -----------> owa erişimi için gereken isim.

contoso.com -----> zorunlu değildir, autodiscover için kullanılabilir.

autodiscover.contoso.com -----> autodiscover servisi için gerekli ve zorunlu eğer contoso.com adı yoksa...

smtp.contoso.com ----> zorunlu değil, eğer Transport servisi farklı bir IP'den ve TLS tabanlı hizmet verecekse (HUB transport özellikle aynı server'da hizmet veriyorsa ve TLS kullanılacaksa düşünülmeli)

pop.contoso.com ----> zorunlu değil, eğer pop bağlantı için özel bir CAS kullanılacaksa

imap.contoso.com ----> zorunlu değil, eğer imap bağlantı için özel bir CAS kullanılacaksa

casservername ----> zorunlu değil eklenebilir netbios name

casservername2 ----> zorunlu değil eklenebilir netbios name

casservername.contoso.local ---> Internal OAB vb. bağlantılarda gereken iç isim

casservername2.contoso.local -----> Internal OAB vb. bağlantılarda gereken iç isim

Not: Birçok sertifika sağlayıcı 40 ismi tek bir sertifikada verebiliyor. Zaman içerisinde bu sertifikaları yenisini almadan update ederek yeni isim ekleyebiliyoruz. Eğer isimlendirme çok karışık bir durum ortaya çıkarıyorsa veya bizim için problem oluyorsa (internal name registered değilse ve başka bir sahibi varsa ) " * " wildcard sertifikayıda gözardı etmemeliyiz. Örneğin; *.contoso.com gibi tek bir isim işimizi görecektir.

Bu isimlerden özellikle autodiscover.contoso.com ismi üzerinde durmak gerekiyor. By default outlook 2007 açıldığında active directory üzerinden connection (SCP) sağlayarak autodiscover URL bilgisini bulur..

Fakat şirket dışında yada active directory bağlantısı olmayan / sağlanamayan durumlarda outlook ikinci denemeyi autodiscover.contoso.com olarak yapacak ve böylece servis bilgilerini edinecektir. (autodiscover adı değiştirilebilir) Bu durum aşağıdaki figür ile temsil ediliyor...

Outlook 2007 açıldığında aşağıdaki URL'leri sırası ile deneyecektir...

https://contoso.com/autodiscover/autodiscover.xml

https://autodiscover.contoso.com/autodiscover/autodiscover.xml

Not: SCP exchange'e özel bir kavram değildir. İstenildiğinde özel uygulamalar için SCP kayıtları oluşturulabilir. Active directory'de ilgili server objesinde yeralır.

http://msdn.microsoft.com/en-us/library/ms677638(VS.85).aspx

Yukarıdanda anlaşıldığı üzere https gerekli ve zorunlu, bu nedenle dorğu sertifikayı edinmeliyiz. Bunun için exchange client access server (CAS) üzerinde aşağıdaki adımları atarak işe başlayabiliriz.

1- İlk adımımız sertifika isteğini oluşturmak olmalıdır. Bunun için aşağıdaki işlem yapılmalı ve New-ExchangeCertificate komutu kullanılmalıdır.

Bu işlem ile local sertifika store'da ilgili istek oluşur ve buna bağlı bir dosyada diske yazılır. İlgili istek dosyası C:\certREQ.txt dosysıdır. Yukarıdaki komutta -domainname ile tüm adlar belirtilmelidir. PrivateKeyExportable true dşye belirtilmeli böylece sertifkanın server'lar arasında export edilerek taşınabilmesine izin verilmelidir.Ayrıca bazı uygulamalar (özelikle mobile) subjectname'de geçen adın public URL olmasını zorunlu tutarlar. Bu nedenle CN=webmail.corpnet.com kullanılmıştır.

Yukarıdaki komut sadece sertifika isteğini oluşturmamızı sağlıyor, sertifika almış olmuyoruz.

2- İkinci adım olarak bu dosyayı (c:\certREQ.txt) sertifika sağlayıcımıza göndererek sertifikamızı ediniyoruz. Aşağıda kendi sertifika sunucumuzdan sertifka edinme adımlarını yazmaya çalıştım.

I. İlgili istek dosyasını sertifika sunucumuza kopyalıyoruz.

II. http://CAserver/certsrv ile sertifka sunucumuza bağlanıyoruz.

III. "Select a certificate" seçeneğini kullanarak, "Advanced certificate request" 'i seçiyoruz.

IV. "Submit a certificate request..." seçilir.

V. Request file içeriği "Saved request" alanına kopyalanır ve "Web Server" sertifika template olarak seçilir.

VI. Submit butonuna tıklanarak sertifika isteği girilimiş olunur.

VII. Sertifika save edilerek CAS server'lara taşınır.

Not: Yukarıdaki işlemler ile elde edilecek .P7B uzantılı dosya isteğin yapıldığı makinaya import edildikten sonra private key exportable olarak görülecektir.

Not: Import işlemi için enaz CAS,HUB yada UM rolü ilgili makinada yüklü olmalıdır.

3- İlgili sertifikayı exchange server'a kopyaladık ve sıra import işine geldi. Bunun için aşağıdaki komut çalıştırılır.

Import işlemi sonrasında private key'in exportable olduğu aşağıdaki sertifikanın anahtar resminden anlaşılabilir.

4- Artık sıra ilgili sertifikayı Enable etmeye geldi. Bunun için Enable-ExchangeCertificate komutunu kullanmalıyız. Enable ile hangi servisler için ilgili sertifikanın etkin olacağını belirtebiliriz. Bunlar kısaca SMTP,IMAP,POP3,UM ve IIS olabilir.

Eğer IIS için import ettiysek ilgili sertifika IIS içerisinden de görülebilicektir.

Tüm bu işlemlerden sonra bir "IISRESET /noforce" yapmak faydalı olacaktır.

Bir sonraki makalede gerekli url set değişikliklerine değineceğim.

Kubilay Ekici

Exchange Server 2007 Autodiscover servisine özet bir bakış

TR Exchange Support Team — Tue, 21 Jul 2009 11:36:00 GMT

Exchange Server 2007 ile birlikte gelen önemli özelliklerden biriside Autodiscover servisidir. Bu servisin amacı, client’ın otomatik olarak tüm ayarlarının sağlanmasıdır. Bu özelliğin çalışması için Microsoft Office Outlook 2007 versiyonu gerekmektedir. Autodiscover servisi, e-mail adress ve password kullanımı ile client’a, iç ağdan ve dış ağdan yapılacak bağlantılarda gerekli bağlantı adreslerini (oab,ews vb..), kullanıcı mailbox bilgisini ve outlook anywhere ayarlarını gönderir.

Tüm bu özellikleri sağlayan Exchange Server 2007 rolü, Client Access Server (CAS) rolüdür. CAS server ilk kurulduğunda, IIS üzerindeki default web site içerisinde, Autodiscover adında bir virtual directory oluşur. Ayrıca, Service Connection Point (SCP) adında bir de Active Directory objeside, CAS server kurulumu ile birlikte gelir. Bu SCP objesi, forest bazında tüm yetkili Autodiscover service URL’lerini içerir.

Autodiscover servisi kendine gelen istekleri Outlook Provider’a gönderir. Outlook Provider üzerinde 3 konfigurasyon ayarı bulunmaktadır. Bunlar,

WEB: Bu ayar, kullanıcının Outlook Web Access için kullanacağı en iyi URL’yi içerir.

EXCH: Exchange RPC protokolünün referans ayarları için kullanılır. Exchange servislerinin iç URL’leri ve port ayarları için kullanılmaktadır.

EXPR: Outlook Aynwhere tarafından kullanılan Exchange HTTP protokolü ayarları için kullanılır. Exchange server’a internet üzerinden erişen kullanıcıların, external URL’lerini ayarlamak için kullanılır.

Set-OutlookProvider cmdlet ile ilgili değişiklikler yapılabilir.

Örneğin, en çok karşılaşılan sorunlardan birisi wildcard sertifika kullanımında yaşanmaktadır. Internet üzerinden yapılan outlook anywhere bağlantısında, client aşağıdaki hatayı alabilir.

Bu sorunun giderilmesi için Outlook profil ayarlarında, Connection bölümünde msstd:* şeklinde tanımlama yapıldığında sorun giderilir. Bununla birlikte çok fazla kullanıcı da bu ayarın yapılması bu şekilde mümkün değildir. Exchange Management Shell üzerinde aşağıdaki komut kullanılarak tüm clientların bu ayarı alması sağlanabilir.

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

Outlook 2007 clientlar, her outlook açıldığında, her exchange bağlantısı kesintiye uğradığında ve belirli aralıklarla Autodiscover servisine bağlantı kurarlar. Eğer outlook client 60 dakika sonra tekrar bağlantı kuramaz ise 5 dakika aralıklar ile tekrar bağlantı kurmayı dener.

Bazı durumlarda Outlook ile Autodiscover servisi arasında sorun yaşanabilir ve bir çok fonksiyon doğru çalışmayabilir. Bu gibi durumlarda Outlook üzerinde aşağıdaki ayar ile Autodiscover servisinin kullanılması tetiklenir.

Outlook 2007 üzerinde, Tools ve sonra Account Settings seçilir. E-mail account penceresinde, E-mail tabı seçilir ve Repair tıklanır.

Autodiscover servisinin iç URL bilgisini değiştirmek için Set-ClientAccessServer cmdlet’i kullanılır.

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

Outlook Anywhere dış host adının, autodiscover servisi için ayarlamada kullanılacak cmdlet aşağıdaki gibidir.

Enable-OutlookAnywhere –Server Serveradı –ExternalHostname “mail.domain.com” –ExternalAuthenticationMethod “Basic” –SSLOffloading:$False

Offline Adres defterinin dış URL’sinin autodiscover servisi için set edilmesinde ise aşağıdaki cmdlet kullanılır.

Set-OABVirtualDirectory –identity “serveradı\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 şekilde konfigüre edildiğinde, sistem yöneticilerinin işini çok kolaylaştıracak bir özelliktir. Burada her sistemin kendine özgü şartlarının gerektirdiği durumlar gözönüne alınarak gerekli düzenlemelerin yapılması önemlidir. Bu konuda çok daha fazla bilgi için http://technet.microsoft.com üzerinde Autodiscover için arama yaptığınızda detaylı bilgiye erişebilirsiniz.

Volkan Günaydın

Exchange 2007’de TELNET ile IMAP bağlantısı nasıl yapılır?

TR Exchange Support Team — Wed, 03 Jun 2009 07:15:00 GMT

IMAP yani Internet Message Access Protocol ile Exchange Server 2007 üzerindeki bir mailbox bağlantısı, telnet komutları ile gerçekleştirilebilmektedir.

Burada Client Access Server rolü üzerinde olan Exchange 2007 sunucusu üzerinde telnet komutları çalıştırılmalıdır.

Öncelikle, IMAP4 sanal sunucusunu plain text logon türü için ayarlayacağız. Bunun için, Exchange Management Shell üzerinde aşağıdaki komut çalıştırılır.

Set-ImapSettings –LoginType “plaintextlogin”

Ardından yine Management Shell üzerinden Telnet ile IMAP oturumu açılır.

Telnet CAS IP Adresi 143

Eğer IMAP4 servisiniz düzgün bir şekilde çalışıyor ise aşağıdaki gibi bir mesaj almalısınız:

Bu aşamadan sonra bir mailbox’a login olmak için aşağıdaki komutu çalıştırın.

? LOGIN Domainİsmi/Loginİsmi Password

Bu komut sonrasında eğer user bilgileri doğru girildi ise şu çıktıyı almalısınız:

Tüm klasörleri listelemek için:

? LIST “” “*”

komutu çalıştırılır.

İstediğimiz mailbox klasörünü açmak için ise:

? Select ilgiliKlasörİsmi

Bu komut eğer başarılı bir şekilde çalışır ise, şuna benzer bir çıktı alırsınız.

Burada bir mesajı okumak için aşağıdaki komutlardan birisi çalıştırılır.

? FETCH mesajnumarası All

? FETCH mesajnumarası Body

IMAP oturumunu sonlandırmak için aşağıdaki komut kullanılır.

? LOGOUT

Bu komut sonrasında aşağıdaki gibi bir mesaj ile oturum sonlanır.

Volkan Günaydın