Exchange Connector 3.0 RTM yapılandırılan bir Service Manager 2012 ile E-Posta İletilerinin İşlenmesi

Service Manager 2012 konsolu için bir Web arayüzü bulunmamaktadır. Bu alanda ürün geliştirmiş firmaların yazılımları Service Manager 2012 ile entegre edilerek kullanılabilir. Kullanıcılar her zaman Service Manager Konsoluna erişecek imkanı bulamayabilirler. Netice konsolun bir bilgisayarda yüklü ve Service Manager management server erişimin olması gerekecektir. Service Manager 2012 versiyonu ve Exchange Connector 3.0 RTM  Mobil cihazlardan yada Internet erişimi olan bir bilgisayardan Service Manager tarafından gönderilen mesajlar belirlenmiş ifadelerle cevaplanabilir. Bu şekilde  konsol üzerinden yapılan temel işlemler E-Posta iletileri ile de gerçekleştirilebilir. Bu şekilde daha esnek ve zamandan kazanarak süreçlerin ilerletilmesi yada işlemesi sağlanabilir.
Exchange Connector 3.0 RTM sadece System Center 2012 SP1 - Service Manager yada System Center 2012 SP1 - Service Manager Update Rollup 2 üzerinde konfigüre edilebilir.

Temelde Service Manager üzerinde gelen E-Posta iletilerinde bakılan kısım Subject/Konu bölümüdür. Eğer konu kısmında Çalışma Öğesi/WorkItem kimliği varsa, gelen mesajın içeriğinde (Body) [ ] içerisinde Exchange Connector ayarlarında yapılandırılan ifadeler aranır.
Kısaca konu kısmındaki [ ] içerisinde belirtilen Work Item ID dediğimiz bu kimlik üzerinden hangi çalışma öğesinde, body kısmında [ ] içinde belirtilen ifadeye göre ne yapılacağı belirtilmiş olunur.

Konu kısmında Öalışma Öğesi kimliği olan E-Posta Mesajlarının işlenmesi
Service Manager tarafından gönderilen mesajların konu kısmında çalışma öğesi kimliği [ ] içerisinde yazılır. Örnek olarak [IR203] gibi.

Konu kısmında [ ] içerisinde Çalışma Öğesi kimliği olan bir E-Posta Service Manager tarafından izlenen E-Posta adresine geldiğinde E-Posta Çalışma Öğesine log olarak kayıt edilir (Action Log).

Eğer Service Manager Exchange Connector tarafından izlenen E-Posta adresine konu kısmında herhangi bir çalışma öğesi numarası, kimliği bulunamazsa 
Yeni bir Çağrı açılır.
Konu -> Çağrı başlığı
E-Posta içeriği Body -> Çağrı açıklaması
Ekler -> Çağrıya dosya olarak - Releated Items
Gönderen -> Etkilenen kullanıcı
Kime ve Bilgi -> İlişkili Yapılandırma Öğesi - Releated Configuration Item
Oluşturan -> WorkFlow Acount olarak belirlenir.

WorkFlow ile bu gelen yeni çağrı ilgili gruplara atanabilir. Öncelik, etki,atanan kullanıcı belirlenebilir.Öncelik ve etki atanmayan yeniş çağrılar için bu alanlar Low / Düşük olarak belirlenir.

Eğer mesaj içeriğinde [ ] içinde önceden belirlenmiş ifadelere rastlanırsa buna göre hareket edilir.
Exchange Connector ile gelen ifadeler üzerinden gidilecek olursak

[Acknowledged] Çalışma öğesi için Set First Responce, belirtilen durumla ilgili bir hareketin, çalışmanın yapıldığı, yapılmaya başlandığı belirtilir. Zaman olarak First Responce Time değeri önceden belirlenmemişse E-Postanın işleme alındığı tarih belirlenir. Incident ve Service Request için kullanılır.

[Closed] ilgili çalışma öğesinin Service Manager Veritabanından raporlama Veritabanına (DataWareHouse) yine Service Manager üzerinde belirlenen süreler geçtiğinde aktarılması için kullanılır. Genel olarak çalışma öğeleri kapatılmaz. Çünkü kapatılan öğeler üzerinde işlem yapılamaz. Kısaca Close Service Manager yöneticileri  tarafından kontrollü olarak organizasyonun çalışma disiplinine çözümlenen, tamamlanan çağrılara genel olarak nasıl  geri dönüp bakmak, raporlamak istediği ile ilgilidir. E-Posta gönderen çalışma öğesini kapatan olarak belirlenir. Incident, Service Request ve Problem Management için kullanılır.

Service Manager kurulumunda gelen çalışma öğesi adlandırmasına göre

Olay - Incident  [IR...]
[Resolved] Çağrı çözümlenir. E-Posta gönderen çalışma çağrıyı çözümleyen olarak belirlenir. Çağrının loglarına olay kaydı düşülür. E-Posta içeriği Resolution Description / Çözümleme notu olarak eklenir.

Sorun - Problem [PR...]
Service Manager tarafındna gönderilen bir Problem ile ilgili E-Posta cevaplandığında, Exchange Connector Gelen E-Posta nın içeriğini, ilgili problem kaydının günlüklerine, eklerini dosya olarak ekler. To ve CC deki diğer E-Posta adreslerini Promlemle ile ilişkili yapılandırma öğesi olarak belirler.

Hizmet İsteği - Service Request [SR...]
Service Manager tarafından gönderilen bir Service Request ile ilgili E-Posta cevaplandığında, Exchange Connector Gelen E-Posta nın içeriğini, ilgili Service Request kaydının günlüklerine, eklerini dosya olarak ekler. To ve CC deki diğer E-Posta adreslerini Service Request ile ilişkili yapılandırma öğesi olarak belirler. Exchnage Connector kurulumunda belirlenen Şablon uygulanır. Bir Service Request içindeki Etkinlikler için E-Posta mesajı gelirse ve tüm etkinlikler bitirilmiş ise, Service Request durumu Tamamlandı olarak belirlenir.Service Request durumumu In Progress ten, Completed olarak belirlenir.

İçeriğinde hiç etkinlik olmayan Service Request Submitted durumundan Completed durumunda dönüşür.
In Progress durumunda olan bir Service request için E-Posta içeriğinde [Completed]  yada kurulumda hanfi ifade belirlenmişse, Service Manager tarafında işlem yapılmaz. Bu durumla ilgili log düşülür.

Değişiklik İsteği - Change Request [CR...]
Service Manager tarafından gönderilen bir Change Request ile ilgili E-Posta cevaplandığında, Exchange Connector gelen E-Posta nın içeriğini ilgili Change Request  aydının günlüklerine ekler. Eklerini dosya olarak ekler. To ve CC deki diğer E-Posta adreslerini Change Request ile ilişkili yapılandırma öğesi olarak belirler. eğer gelen mesjajın içeriğinde (Body) [Approved] yada [Rejected] veya kurulumda hangi ifade belirlenmişse, meajı gönderenin Onay etkinliklerindeki oylama durumu belirlenir.

Etkinlik - Activity
[RA...]
Service Manager tarafından gönderilen bir review Activity ile ilgili E-Posta cevaplandığında, Exchange Connector gelen e-Postanın içeriğinde [Approved] yada [Rejected] veya kurulumda hangi ifade belirlenmişse ona göre davranır. Gelen E-posta daki tanımlı ifadelere göre Review Activiry içindeki oylama durmunu gönderen kullanıcıya göre belirler. Gruplar için atanan Activity için gelen mesajlar dikkate alınmaz. Gelen E-Posta içinde onay ve red ifadeleri aynı zmanda varsa geçerli olarak Review Activity içindeki oylayan kişi için red etti cevabı belirlenir. Review Activity içindeki onay durumu, Onayı istenen kişi tarafından gönderilen ikinci bir e-Posta ile değiştirilebilir. Ekler review Activity ile ilişkilendirilir. Review Activity durumu In Progress olmadığı sürece gelen mesajlar dikkate alınmaz ve hato logu düşülür. To ve CC deki E-Posta adresleri Review Activiy le ilişkilendirilir.

[MA...]
Service Manager tarafından gönderilen bir Mauel Activity ile ilgili E-Posta cevaplandığında, Exchange Connector  Maanuel Activiy için Note lanına gönderilen son mesajın içeriğini 4000 karaktere kadar ekler. Gelen mesajın içeriğinde etkinliğin bitirildiğine dair Exchange Connector kurulumunda belirlenen ifade bulunursa etkinlik tamamlanır. Ekler, To ve CC deki adresler Manuel Activity ile ilişkilendirilir.

Service Manager üzerinde yetkileri belirlenmiş kullanıcılara bu aktiviteleri haber vermek için gönderilen mesajların konu kısmında, mesaja nasıl geri döneceklerini belirtebilirsiniz.

Yararlanılan Kaynak
http://www.microsoft.com/en-us/download/details.aspx?id=38791

Owa IIS Log dosyalarının Log Parser ile raporlanması


Kullanıcının bağlantı kayıtlarının listelenmesi
c:\Program Files (x86)\Log Parser 2.2>logparser -i:IISW3C "select date, time, c-ip FROM C:\inetpub\logs\LogFiles\W3SVC1\*.* where cs-username like 'kullaniciadi' " ​

Hatalı oturum açma kayıtlarının kullanıcı bazında listelenmesi, kullanıcı adı yada parola hatası
c:\Program Files (x86)\Log Parser 2.2>logparser -i:IISW3C "select date, time, s-ip, cs-method,s-port, cs-username, c-ip, sc-status, sc-substatus, sc-win32-status FROM C:\inetpub\logs\LogFiles\W3SVC1\*.* where sc-status=401 and cs-username='kullaniciadi'"
Oturum açma işlemi sırasında kullanıcı adı için 'domainadi\kullaniciadi', 'domainadi.local\kullaniciadi' olarak yazılmış olabilir.

Bu durumda
(cs-username='kullaniciadi or cs-username='domainadi\kullaniciadi) olarak komut içinde yazılabilir.

Hatalı oturum açma kayıtlarının listelenmesi özellikle E-Posta hesaplarının kitlenmesi  durumunda kaynağın belirlenmesi için faydalı olabilir.
c:\Program Files (x86)\Log Parser 2.2>logparser -i:IISW3C "select date, time, s-ip, cs-method,s-port, cs-username, c-ip, sc-status, sc-substatus, sc-win32-status, cs-(User-Agent) FROM C:\inetpub\logs\LogFiles\W3SVC1\*.* where sc-status=401"​

cs-(User-Agent) ile bağlantı yapılan yazılım tespit edilebilir. Örneğin parolasını yenilemiş bir kullanıcının sürekli hesabının kitlenmesi durumunda, mobil cihazında parolasını güncellemeyi unutması gibi. Aşağıdaki örnek Log kaydı görülebilir.


2013-02-14 07:14:36 172.1.1.1 OPTIONS   443    domainadi\kullaniciadi 10.10.10.10 401       1  

1326            Android/0.3

Hatalı oturum açma kayıtlarının tarih verilerek listelenmesi ve belirli isimdeki dosayaların içinde aranmasının sağlanması - 

c:\Program Files (x86)\Log Parser 2.2>logparser -i:IISW3C "select date, time, s-ip, cs-method,s-port, cs-username, c-ip, sc-status, sc-substatus, sc-win32-status INTO c:\log.txt FROM C:\inetpub\logs\LogFiles\W3SVC1\u_ex12*.*  where sc-status=401 and cs-username='kullaniciadi' and (date>='2012-01-01'and date<='2012-01-01')"

IIS dosya adı biçimi

u_ex[yil][ay][gun].log

Hatalı oturum açma kayıtlarının tarih verilerek listelenmesi ve ayrı ayrı dosyaların içinde aranmasının sağlanması
c:\Program Files (x86)\Log Parser 2.2>logparser -i:IISW3C "select date, time, s-ip, cs-method,s-port, cs-username, c-ip, sc-status, sc-substatus, sc-win32-status INTO c:\log.txt FROM C:\inetpub\logs\LogFiles\W3SVC1\u_ex12.*, C:\netpub\logs\LogFiles\W3SVC1\u_ex1112*.* where sc-status=401 and cs-username='kullaniciadi'"

Syslog sunucusuna istenen IIS loglarının gönderilmesi
logparser -i:IISW3C "select * INTO @10.10.10.10 FROM C:\inetpub\logs\LogFiles\W3SVC1\*.* where cs-username like 'kullaniciadi'" -o:SYSLOG -hostname:10.10.10.10

Syslog sunucusuna belirtilen IIS log dosyalarının gönderilmesi

logparser -i:IISW3C "select * INTO @10.10.10.10 FROM C:\inetpub\logs\LogFiles\W3SVC1\u_ex1203*.*" -o:SYSLOG -hostname:10.10.10.10

Exchange Server 2010 log tutma ayarlarının yapılandırılması - Log Retentiton

Log Dosyalarının konum, boyut ve zaman aşımı sürelerinin görüntülenmesi

Exchange Server 2010 üzerinde çeşitli log dosyaları belirli olaylar gerçekleştiğinde üretilir. Bu log dosyalarının kurulumla beraber boyutu, konumu ve log dosyalarının durduğu klasör boyutu belirlenmiştir. Kimi kurumlar için bu değerlerin değiştirilmesi gerekecektir. Mesaj trafiği yoğun olan işletmelerde Log klasörünün boyutunun arttırılması yerinde olacaktır. Örneğin 1000 kullanıcı bir sistemde Message Tracking Log dosyalarının boyutu aylık 1 GB artabilir. Bununla beraber log dosyalarının zaman aşımı süresinin de belirlenmesi, Log dosyalarının büyüme oranı ile dengeli olarak verilmesi uygun olacaktır. Log dosyalarının 1 yıl tutulması istenen 1000 kullanıcılı bir yapıda Log klasör boyutunun 250 MB olması, 1 yıldan eski olmayan log dosyalarının silinmesine neden olabilir. Hafta içi bir güne ait üretilen toplam log dosyalarının toplam kapasitesi ile aylık  ve yıllık disk alan ihtiyacı kabaca hesaplanabilir.

Aşağıdaki komutla ilgili sunucuda ayrıntılı bilgiler alınabilir. Bu bilgiler içinde Log dosyaları, konum ve boyutları görülebilir.

Get-TransportServer sunucuadi | fl * |more

Yada sadece istenen log ayarları için aşağıdaki komutlar uygulanabilir.

Get-TransportServer sunucuadi | fl MessageTracking*

Get-TransportServer sunucuadi | fl ReceiveProtocol*

Get-TransportServer sunucuadi | fl SendProtocol*

Get-TransportServer sunucuadi | fl ConnectivityLog*

Tüm loğlar için aşağıdaki komut uygulanabilir.

Get-TransportServer sunucuadi | fl *log*trans              

Connectivity Log Dosyaları

Hubtransport yada Edge rolüne sahip sunucularda, mesajların iletilmesi esnasında sunucu bağlantı kayıtlarının tutulduğu log dosyalarıdır.

Hubtransport ve Edge rollleri ayrı sunucularda olan yapılarda, Hubtransport sunucular Mailbox ve Edge sunucular arasındaki iletim loglarını tutar. Edge sunucularda ise transport ve Internet üzerindeki diğer mail sunucular  ile kurulan bağlantıların logları tutulur.

Connectivity Log dosyalarının boyutu kurulumla beraber 10 MB olarak ayarlanır. Log dosyasının boyutu 10 MB a ulaştığında yeni bir log dosyası oluşturulur. Log klasörünün boyutu yada zaman aşımı süresi dolduğunda eski log dosyaları silinir.

Log dosyalarının boyutlarının değiştirilmesi için Transport, Edge ve MailBox rolüne sahip Exchange sunucularda aşağıdaki komut sunucu adı verilerek uygulanır.

HubTranspor yada Edge rolüne sahip sunucularda aşağıdaki komutlar Log klasör boyutu ayarlanabilir.

Set-TransportServer SunucuAdı  -ConnectivityLogMaxDirectorySize 4096MB

Message Tracking Log Dosyaları

Mesajların iletilmesindeki aşamaların kayıt altına alındığı dosyalardır. Bir mesajın Exchange organizasyonunu içindeki ve son olarak hedef posta sunucusuna teslim aşamalarındaki olaylar kayıt altına alınır. Bu şekilde mesajın iletilip iletilmediği yada iletim sorunlarında bilgi alınabilir.

Message Tracking Log dosyalarının boyutu kurulumla beraber 10 MB olarak ayarlanır. Log dosyasının boyutu 10 MB a ulaştığında yeni bir log dosyası oluşturulur. Log klasörünün boyutu yada zaman aşımı süresi dolduğunda eski log dosyaları silinir.

Log dosyalarının boyutlarının değiştirilmesi için Transport, Edge ve MailBox rolüne sahip Exchange sunucularda aşağıdaki komut sunucu adı verilerek uygulanır.

Set-TransportServer SunucuAdı -MessageTrackingLogMaxFileSize 30MB

Set-MailboxServer SunucuAdı -MessageTrackingLogMaxFileSize 30MB

Message Traking Log klasörünün boyutunun ayarlanması için aşağıdaki gibi komut Transport ve Mailbox rolüne sahip sunucularda verilebilir.

Set-TransportServer SunucuAdı  -MessageTrackingLogMaxDirectorySize 10240MB

Set-MailBoxServer SunucuAdı  -MessageTrackingLogMaxDirectorySize 10240MB

Klasör boyutunun ayarlanması tek başına yeterli olmayacaktır. Bu nedenle Log dosyalarının zaman aşımı süresinin ayarlanması gereklidir. Aşağıdaki komutlar ile Transport  ve Mailbox rolüne sahip sunucularda Message Tracking loğlarının zaman aşımı 1 yıl olarak ayarlanabilir.

Set-TransportServer SunucuAdı  -MessageTrackingLogMaxAge 365.00:00:00

Set-MailBoxServer SunucuAdı  -MessageTrackingLogMaxAge 365.00:00:00

Protocol log dosyaları

Protocol Log dosyalarının geçerli olarak boyutu 10 MB dır. Tüm Receive connector ve Send Connector için bu değer geçerlidir. Bu boyut aşıldığında yeni bir log dosyası oluşturulur.

Protocol Loglarının durduğu kalsör için Exchange tarafında bir limit ve zaman aşımı belirlenmiştir. Bu değerlere ulaşıldığında eski log dosyaları silinir.

Eğer log dosyalarının boyutları değiştirilmek istenirse Transport, Edge ve MailBox sunucuda, sunucusu adı verilerek aşağıdaki komutun ilgili log için verilmesi gerekir. Protocol Log için genel olarak Edge ve Hub Transport rolüne sahip sunucularda ayarlar yapılır. 

Set-TransportServer SunucuAdı -ReceiveProtocolLogMaxFileSize 30MB

Set-TransportServer SunucuAdı -SendProtocolLogMaxFileSize 30MB

Exchange Server tarafında log dosyalarının durduğu klasör boyutu kurulumla beraber 400 MB olarak belirlenir. Mail trafiği yoğun olan işletmelerde bu aşan yeterli olmayabilir. Log klasörünün boyutunun değiştirilmesi için aşağıdaki komut herbir Exchange Sunucuda uygulanır.

Set-TransportServer SunucuAdı -ReceiveProtocolLogMaxDirectorySize 10240MB

Set-TransportServer SunucuAdı -SendProtocolLogMaxDirectorySize 10240MB

Kurulumla beraber bu süre 30 gün olarak belirlenir. Bu süreyi değiştirmek için aşağıdaki komut her bir Exhange Sunucuda verilir. Örneğin bu loğların 1 yıl tutuması için aşağıdaki komut uygulanabilir. 00:00:00 değeri verilirse log dosyaları için zaman aşımı dikkate alınmaz. 24855.03:14:07 girilebilecek en yüksek değerdir.

Set-TransportServer SunucuAdı -ReceiveProtocolLogMaxAge 365.00:00:00

Set-TransportServer SunucuAdı -SendProtocolLogMaxAge 365.00:00:00

RoutingTable Log

Belirli sürelerle Exchange Server 2010 HUB ve Edge rolüne sahip sunucular tarafından, mesajların hedeflerine iletilmesi için organizasyon yapısındaki sunucu ve onların üzerlerindeki ayarların listesinin tutulduğu tutulduğu log dosyalarıdır. Örnek olarak iletilebilecek mesajın büyüklüğü, alıcı sayısı gibi.  Bu log dosyalarına bakılarak geriye dönük olarak sunucu topolojisindeki değişimler gözlemlenebilir.

IPv6 üzerine Notlar

IPv6 adresli Dosya Paylaşımlarına ve Internet Adreslerine Bağlanmak

IPv6 adresinde kullanılan “:” URI ve URL lerde kullanıldığından örneğin port numarası verilmesi gerektiğinde karışıklık ortaya çıkabilir. Bunun için IPv6 adresi köşeli parantez içinde yazılır. Örnek http://[fdcb:2d61:ca89:27fb::3]:8081

Windows işletim sistemlerinde UNC (Uniform Naming Convention) adreslerinde, kısaca bir sunucunun IPv6 adresi ile paylaşımlarına erişilmek istendiğinde “:” karakteri kullanılamaz. Bunun nedeni nu karakterin sunucu adreslerinde/isimlerinde SMB protokolünde kabul edilen karakterler içinde olmamasıdır. Bu nedenle Microsoft IPv6 için özel bir domain adı ayırmıştır ve Windows işletim sistemleri bu özel domain adını tanır..

Dosya paylaşımlarına bağlanılırken 

\\fdcb:2d61:ca89:27fb::3 

adresi yerine 

\\fdcb-2d61-ca89-27fb.ipv6-literal.net\c$ olarak yazılır. Microsoft işletim sistemlerinde ipv6-literal.net domain adı için dns sunucularına sorgu gönderilmez.

ipv6 dosya paylaşımına nasıl bağlanılır
ip6 dosya paylaşımına nasıl bağlanılır
ipv6 UNC URL

Exchange Server 2010 Global Address List ve Offline Address Book Elle Güncellenmesi

​

Global Addres Lists kullanılarak Offline Address Book oluşturulur. Geçerli olarak adres listeleri her gece saat 05:00 te Global Address Lists e bakılarak yapılır. Her 8 saatte bir CAS sunucular Offline Address Book üzerinde değişiklik varmı diye kontrol eder. Bu işlem Microsoft Exchange > Microsoft Exchange On-Premises > Organization Configuration > Mailbox > Offline Address Book tab sağ tuş ile açılan menüden Update seçilerek yapılabilir. ancak Global Address Lists üzerindeki değişikliklerin Offline Address Book a yansıması durumunda, güncellemeler alınabilir.  Bu sürenin beklenilmesi istenmiyorsa aşağıdaki 2 çözümden uygun olanı uygulanabilir.

1. Çözüm

Genel olarak kullanıcı özelliklerinde yapılan değişikliklerin güncellenmesi için uygulanır.

Exchange Power Shell içinde Önce Mailbox sonra CAS sunucularda aşağıdaki komut uygulanır.

Update-GlobalAddressList -Identity "Default Global Address List"

CAS sunucuda Exchange Management Console içinde

Microsoft Exchange > Microsoft Exchange On-Premises > Organization Configuration > Mailbox > Offline Address Book tab
sağ tuş Update seçilir. Bu işlem 10 dakika kadar sürebilir.

Güncelleme işleminin kontrolü için CAS rolüne sahip sunucuda aşağıdaki klasöre gidilir.

C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\OAB\<Address List ID>

.lzx​ uzantılı dosyaların değiştirilme tarihi en yeni olana bakılır. Eğer hala en güncel tarihli dosya işlemin yapıldığı tarihten eski ise  Microsoft Exchange File Distribution servisi CAS sunucularda yeniden başlatılır.

 

Tekrar güncelleme işlemimin kontrolü için .lzx dosyalarının bulunduğu aşağıdaki yoldaki klasöre gidilir. En güncel .lzx dosyasının  tarihine bakılır.

C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\OAB\<Address List ID>

 

 

2. Çözüm

Offline Global Address Lists güncellenmesi için tercih edilir. Yeni kullanıcının bilgilerinin listelerde güncelenmesi için.

Microsoft Exchange > Microsoft Exchange On-Premises > Organization Configuration > Mailbox > Offline Address Book tabına gidilir
sağ tuş ile açılan menüden  Update seçilir. Bu işlem 10 dakika kadar sürebilir.

 

Offline Address Book u oluşturan Mailbox sunucuyu öğrenmek için Offline Address Book üzerinde sağ tıklanır ve açılan menüden Properties seçilir. General sekmesinde Generation server kısmında Mailbox sunucu görülebilir. Offline Address Book u oluşturan Mailbox sunucuda

 

Microsoft Exchange System Attendant Service yeniden başlatılır.

 

Cas sunucularda MS Exchange File Distribution Service ve Background Intelligent Service yeniden başlatılır.

 

 

Microsoft Outlook 

Microsoft Outlook istemciler sonraki ilk bağlantı kurduklarında Address Book güncelemesini yapacaklardır. Güncellemelerin istemcilerde görüntülenmesi 5-15 dakika alabilir.

Eğer değişikiliklerin hemen görüntülenmesi istenirse Microsoft Outlook kapatılıp açılır.

Sen/Receive tabında Send/Receive Groups menüsü açlılır ve Download Address Book seçilir.

Ekrana gelen pencerede Download changes since last Send/Receive seçeneğinin işareti kaldırılır. Full Details seçili olarak OK butonuna tıklanır.

Bazı istemcilerde hala güncelleme olmadı ise,

Outlook kapatılır.

C:\users\username\appdata\local\microsoft\outlook klasörüne gidilir. OAB uzantılı dosyalar silinir. Outlook açılır ve tekrar Download Address Book seçilir.

 Offline Address Book Outlook içinden indirilir.

Change Domain Microsoft SQL Cluster - Microsoft Cluster Domain Değişikliği

MS Sql 2005 yüklü Windows Cluster Serivisinin bir domainden diğer yeni bir domain içine alınması

Microsoft Cluster servisi için Domain kurulumu gereklidir. Çoğu işletmede yapılandırılan domain içinde Cluster Servisi yapılandırılır. Bu durumda domain yapısının sağlıklı çalışması daha da önem kazanır. Ancak bazı nedenlerden dolayı Domain sorunlu yada çalışamaz hale gelebilir. Bu durumda Microsoft Cluster serivisinde sıkıntılar ortaya çıkabilir. Önerilen Cluster konfigürasyonunun yeniden, yeni kurulan domain için yapılandırılmasıdır. Cluster servisi yeni domaine taşınsa bile çalışmama olasılığı vardır. İşlemlere başlamadan önce herzamanki gibi Cluster servisi üzerinde çalıştırılan uygulamalrın, veri tabanlarının yedeğinin alınması, her ihtimale karşı eski domainde olan Cluster sunucuların her biri üzerinde System State Backup alınması önerilir. Ayrıca Cluster sunucularda yerel Administrator hesabının parolasının bilinmesi yada yeniden belirlenmesi, sunucuların domainden çıkarıldıktan sonra oturum açılabilmesi için gerekli olacaktır.

1.Adım

Öncelikle yeni domain içinde Cluster Servisi için gereli olan kullanıcının ve SQL Server kurulumunda belirlenmiş grupların oluşturulması gerekir. Bu grupların adlarını öğrenmek için StartàAdministrative Toos  à Cluster Administrator açılır. Cluster Administrator konsolunda Cluster adı üzerinde sağ tıklanır ve Properties seçilir.

 Ekrana gelen pencerede ilgili gruplar görülebilir.

Cluster servisi için gerekli kullanıcı ve gruplar Active Directory Users and Computers konsolu kullanılarak oluşturulur

  

2. Adım

Tüm Cluster üyesi sunucular üzerinde Cluster Service için Startup Type Manuel olarak belirlenmelidir.

3. Adım

Tüm Cluster üyesi suncular üzerindeki Cluster Service durdurulur.

4. Adım

Biri dışında tüm Cluster üyesi sunucular kapatılır.

5. Adım

Açık olan Cluster üyesi sunucu yeni domain e üye yapılır. Bunun için yeni kurulan Domain Controller IP adresi Cluster üyesi sunucuya DNS IP adresi olarak girilir. Sonra System Propeties à Computer Name à Change pencersine gidilir. Yeni domain adı yazılır ve OK butonuna tıklanır. Gerekli kullanıcı adı ve parola girildikten sonra sunucu kapatılıp açılır.

6. Adım

Kapatılıp açılan sunucu üzerinde Administrator ile login olunur.

Cluster service için oluşturulan kullanıcıya aşağıda belirtilen yetkileri kısıtlayan bir GPO yada Security Template uygulanmadığı kontrol edilmelidir. Bu hesabın sahip olması gereken yetkiler aşağıda belirtilmiştir. Ayrıca oluşturulan hesabın Cluster üyesi olan sunucularda yerel Administrators grubuna üye olması gerekir. Bu yetkiler Cluster servisi kurulumu sırasında kendiliğinden ilgili ullanıcıya verilir. Güvenlik açısından önerilmeyen bir diğer yol ise Domain Admins grubuna ilgili kullanıcıyı dahil etmek yada Domain Administrator parolasını uygulamak. Eğer Administrator parolası uygulanırsa, Administrator parolasının değiştirilmesi durumunda Cluster Servisi içinde parolaların güncellenmesi dikkate alınmalıdır.

Lock pages in memory.

Log on as a service.

Act as part of the operating system. (Windows 2000 and Windows Server 2003)

Back up files and directories.

Increase quotas.

Increase scheduling priority.

Load and unload device drivers.

Restore files and directories.

Adjust memory quotas for a process (WIndows Server 2003).

Cluster Service özelliklerinde Log On sekmesinde eski domain için belilenmiş kullanıcı adı ve parolası, yeni domain ve kullanıcı bilgilerine göre düzenlenir.

 Administrative Tools à Cluster Administrator konsolu açılır. İlgili Resource üzerinde sağ tıklanır ve açılan menüden Bring online komutu uygulanır ve hata olup olmadığı gözlemlenir. Event Viewer à System içindeki loglar kontrol edilir. Bu noktada duruma göre istenirse cluster üyesi sunucu eski domain e alınabilir. Ve işlem bırakılabilir.

Bu noktada Cluster Servisi başlamayabilir. 

Yukarıdaki gibi ekrana gelen hata mesajında Event Viewer içindeki loglar kontrol edilip ilgili izinlerin nerede eksik olduğu görülebilir. İzinlerin düzenlenmesi için Start à Run à secpol.msc yazilir ve OK butonuna tiklanir. Ekrane gelen Local Security Settings konsolunda Local Policies à User Rigts Assignments içindeki yukarıda da yazılan yetkilerin Cluster servisi için belirlenmiş olan hesabın olup olmadığı kontrol edilir ve eksik olanlarda eklenir..

Ayrıca SQL Server ile ilgili olan servislerdeki kullanıcı adı ve parolasının yeni domain e göre yeniden girilmesi gereklidir. Bu servisler SQL Server (MSSQLSERVER), SQL Server Agent (MSSQLSERVER), SQL Server Browser, SQL Server FullText Search (MSSQLSERVER). Event Viewer her hatadan sonra mutlaka kontrol edilmelidir.

Administrative Templates à Cluster Administrator konsolunda tüm Cluster Resource tanımlarının düzügün çalıştığı kontrol edilir.

Cluster Service için Startup type Automatic olarak belirlenir. Eğer ilk yapılandırılan sunucuda başarılı olunursa diğer sunucular da açılıp ilk sunucuda yapılan işlemler 5. Adımdan itibaren tekrarlanır.

Son olarak test için kaynaklar bir sunucudan diğerine taşınır. Bunun için Groups altındaki Cluster Group ve diğer başlıkların üzerinde sağ tıklanır ve açılan menüden Move Group seçilir. Bu işlemlerin sağlıklı yapıldığı gözlemlenir.

Uyarılar: Eğer SQL server 7.0 için bu işlem yapılacaksa önce SQL Server 7.0 cluster yapısından çıkarılmalıdır. Bu işlem yapıldıktan sonra SQL Cluster Failover Wizard kullanılarak yeniden konfigüre edilir. SQL Server 2000 için http://support.microsoft.com/kb/319016/ makalesine bakınız.

Bu konuyla ilgili olarak http://support.microsoft.com/kb/269196 adresinde bilgi bulabilirsiniz.


Windows Server 2008/2008R2 sistemlerde bu işlem desteklenmez. kısaca bu işlemler yapıldıktan sonra Cluster Servisi ve üzerindeki kaynaklar çalışmayabilir.

Windows Server 2008 R2 Hyper V Live Migration Ağ Yapılandırmaları

Genel Bilgiler


Windows Server 2008 R2 ile beraber gelen Hyper V üzerinde Ağ kartları için 3 tip iletişim kullanılabilir.

External
Aynı Hyper V Sunucu üzerinde bu ağa bağlı sanal sunucular birbirleri ile ve yerel ağdaki diğer sunucular ile iletişime geçebilir.

Internal
Aynı Hyper V Sunucu üzerinde bu ağa bağlı sanal sunucular birbirleri ile ve Hyper V Sunucu ile iletişime geçebilirler.

Private
Aynı Hyper V Sunucu üzerinde bu ağa bağlı sanal sunucular birbirleri ile  iletişime geçebilirler.


Wifi Win 2008 Hyper V de desteklenmez. Oluşturulan her yeni sanal ağ için (Virtual Network) Hyper V sunucu üzerinde bir ağ bağlantısı oluşturulur.

Windows Server 2008 R2 Hyper V de 2 tip ağ kartı desteklenir.
Network Adapter
Virtual Machine Driver yüklenir. Hyper V Integration service bu Driver ile gelir.

Legacy Network Adapter
Integration Service kullanılmadığı zaman sanal işletim sistemleri tarafından genel olarak bu bu driver kullanılır. PXE ile boot imkanı sağlar.

Sanal sunucuların ağ iletişimi
Sanal sunucudan paket, sunucunun sanal ağ kartından (Virtual Network Adapter), bu kartın sanal olaral bağlandığı Porta gönderilir. Bu port External, Internal yada Private olarak tanımlanmış sanal ağdır. Virtual Network oluşturulduğunda Hyper V sanal ağ kartı fiziksel ağ kartı ile ilişkilendirilir. Aynı sanal ağ içinde olan sanal sunucular birbirleri ile iletişime geçmek istediğinde paketler dış ağa gönderilmeden hedef sanal sunucuya iletilir. Sonrasında bu ağlara tanımlanmış fiziksel ağ kartına ilgili paket iletilir. Fiziksel ağ kartından da Fiziksel Switch e paket gönderilir.

Mac Adresleri
Sanal sunucular Dinamik ve Static Mac adresleri ile konfigüre edilebilir. Geçerli olarak sanal sunuculara Dinamik Mac adresi atanır. Aynı ağda olan Hyper V hostlar üzerinde oluşturulan sanal sunucuların Mac adresleri nadiren de olasa çalışabilir. Mac adres havuzu Hyper V sunucunun IP adresine göre belirlenir. İlk 6 karakter Microsoft için ayrılmıştır. Sonraki 6 karakter Hyper V sunucunun IP adresine göre belirlenir. Mac adresi havuzu Virtual Network Manager ile belirlenebilir.. Sanal suncular çalışırken Mac adresi havuzu değiştirilirse, dinamik mac adresi alan sunucular bu değişiklikten etkilenmez.

VLAN
Hyper V sunucu üzerinde her bir Virtual Network adapter için ayrı Vlan belirlenebilir. Kısaca herbir Sanal sunucu için ayrı Vlan sanal sunucu özelliklerinde ayarlanabilie. Bu yapılandırma için Fiziksel ağ kartının Vlan desteğinin olması ve Vlan ID ye sahip paketleri iletebilmesi gerekir.

2 şekilde Vlan iletişimi konfigüre edilebilir.

Access Mode
Hyper V sunucunun fiziksel ağa bağlı olduğu switch üzerindeki port bu şekilde konfigüre edilirse, bu fiziksel ağa ile ilişkili virtual network, sadece bu porta atanmış Vlan a üye sunucular ile iletişime geçebilir.

Trunk Mode
Fiziksel ağ kartı ile, fiziksel ağ üzerinde birden çok Vlan ID ye sahip paketler iletilebilir. Fiziksel ağ kartının bağlı olduğu Switch üzerindeki port Trunk olarak konfigüre edilir. Sanal sunucuların Virtual Network ayarlarında ilgili Vlan ID yazılır. Bu şekilde aynı hyper V sunucu üzerinde farklı Vlan ID ile sanal sunucular çalıştırılabilir.

Live Migration
Hyper V üzerinde Sanal sunular için, Cluster iletişimi, CSV (Cluster Shared Volume), Live Migration, iSCSI ve Yönetim için ayrı ağların/kartlarının kullanılması önerilir. Tabii ki her bir trafik türü için ayrı bir ağ kartı ayrılması mümkün olmayabilir. Genel olarak Sanal sunucu ağı için 1 ağ/ağ kartı, Cluster iletişimi ve CSV için 1 ağ/ağ kartı ve Live Migration ve yönetim için 1 ağ/ağ kartı ayrılabilir. Tabii burada iSCSI ile yapılan bağlantılar içinde ayrıca bir ağ kartı kullanılmalıdır.Burada ağ kartlarında oluşabilecek sorunlara karşı Team konfigürasyonları da düşünülecektir. Ancak Team konfigürasyonlarında sanal sunucular üzerinde yapılan NLB yapılandırmalarında sorunlar oluşabilir. Ağları ayırırken Vlan yada farklı Network ID ler üzerinden ağların  yapılandırılması gerekir. Bu şekilde ilgili trafiğin, ilgili ağ kartından yönlendirilmesi sağlanabilir.

Live Migration yapılabilmesi için aşağıdaki sıralanan gerekliliklerin sağlanması gerekir.
Hyper V sunucuların ilgili ağ kartlarının aynı ağ içinde olması,
Paylaşılmış Disk Ünitesi/Diskler,
Aynı CPU mimarisine sahip Hyper V sunucular, Intel-Intel, Amd-Amd,
Windows Server 2008 R2 Ent, Datacenter ve Hyper V 2008 R2 sürümleri arasında yapılabilir.
CSV ağı için adanmış, konfigüre edilmiş ağ kartında Client for Microsoft Networks ve File and Printer Sharing protokollerinin açık aktif olması.

Öneri ve bilgi olarakta
Aynı anda Hyper V cluster yapısındaki sunucu sayısının yarısı kadar Live Migration işlemi yapılabilir.
Adanmış ağ kartı (önerilir).

Hyper V Ağ kart sayısına göre trafik yönetimi önerileri

Hyper V Cluster için 1 Gb hıza sahip ağ kartları ve iSCSI kullanılmayan mimarilerde en az 2 ağ kartı olmalıdır.

Hyper V Cluster için 1 Gb hıza sahip ağ kartları ve iSCSI kullanılan mimarilerde en az 3 ağ kartı olmalıdır.

Hyper V Cluster için 10 Gb hıza sahip ağ kartları ve iSCSI kullanılan mimarilerde en az 2 ağ kartı olmalıdır.


1 Gb Hıza sahip Ağ Kartları olan yapılarda

2 Ağ kartı olan bir sunucuda FC Disk yapısında
1 ağ kartı Sanal sunucu iletişimi, Yönetim ve Cluster iletişimi için yedek olarak
1 ağ kartı CSV, Live Migration ve Cluster iletişimi

3 Ağ kartı olan bir sunucuda FC Disk yapısında
1 ağ kartı Sanal sunucu iletişimi ve Yönetim
1 ağ kartı CSV ve Cluster iletişimi
1 ağ kartı LM ve Cluster iletişimi için yedek olarak


3 Ağ kartı olan ve iSCSI ile disk erişimi yapılandırılmış bir Hyper V Cluster yapısında
1 ağ kartı iSCSI iletişimi için

1 ağ kartı Sanal sunucu iletişimi, Yönetim ve Cluster iletişimi için yedek olarak
1 ağ kartı CSV, Live Migration ve Cluster iletişimi

4 ağ kartı olan bir sunucuda FC Disk yapısında
2 ağ kartı Sanal sunucu iletişimi için
1 ağ kartı Live Migration, Yönetim ve Cluster iletşimi için yedek olarak
1 ağ kartı Cluster iletişimi ve CSV trafiği için yapılandırılabilir.

4 ağ kartı olan ve iSCSI ile disk erişimi yapılandırılmış bir Hyper V Cluster yapısında
2 ağ kartı iSCSI MPIO yapılandırılarak farklı Network ID ler ile
1 ağ kartı Live Migration, Yönetim ve Cluster iletşimi için yedek olarak
1 ağ kartı Cluster iletişimi ve CSV trafiği için yapılandırılabilir.


10 Gb hıza sahip Ağ Kartları olan yapılarda

2 Ağ kartı olan bir sunucuda FC Disk yapısında
1 ağ kartı Sanal sunucu iletişimi, Yönetim ve Cluster iletişimi için yedek olarak
1 ağ kartı CSV, Live Migration ve Cluster iletişimi


2 Ağ kartı olan ve iSCSI ile disk erişimi yapılandırılmış bir Hyper V Cluster yapısında

1 ağ kartı Sanal sunucu iletişimi, Yönetim ve Cluster iletişimi için yedek olarak
1 ağ kartı CSV, Live Migration, Cluster iletişimi, iSCSI

1 Gb ve 10 Gb ağ kartı olan sunucularda genel olarak 1 Gb olan ağ kartı yönetim için kullanılabilir. Ayrıca Cluster iletişimi için metric değeri ayarlanarak yedekde tutulabilir.

Cluster iletişimi (HeartBit), Sanal Sunucu ve iSCSI iletişimi için kullanılan ağda/ağ kartlarından ayrı bir ağ/ağ kartı üzerinden iletilmelidir.

Cluster, Live Migration ve CSV Trafiğinin istenen ağ kartlarından iletilmesinin sağlanması

Hyper V Cluster yapısındaki herhangi bir sunucuda Windows PowerShell Modules açılır ve aşağıdaki komut uygulanır.

get-clusternetwork | fl *

Ekrana gelen çıktıda Gateway IP adresi girilmemiş ağ kartlarının metric değeri 1000 ile başlar ve sırasıyla 100 arttırılarak gösterilir. GW IP adresi girilmiş ağ kartlarının metric değeri 10000 ile başlar ve sırasıyla 100 arttırılarak gösterilir. Metric değerlerine göre Cluster ve CSV trafiğinin hangi ağ kartlarından öncelik sırasına
iletileceği belirlenir.

netFT.sys metric değeri en düşük olan ağ kartını Cluster iletişimi için kullanır.  Bu şekilde Cluster iletişimi (Heartbeat) ve CSV trafiği için hangi ağ kartının öncelikli olarak kullanılacağı görülebilir.

aşağıdaki komutla metric değeri değiştirilerek istenen ağ/ağ kartı Cluster iletişimi ve CSV için öncelikli olarak belirlenebilir.
(get-clusternetwork "Private2").Metric=1000

Live Migration için de metric değeri ikinci en düşük ağ kartı kullanılır. Live Migration için kullanılacak ağ/ağ kartı FailOver Cluster manager ile değiştirilebilir. Bunun için FailoverCluster manager konsolu açılır. Cluster adı altında Service and applications genişletilir. Burada herhangi bir sanal sunucu üzerinde tıklanır. Summary yada yandaki kısımda Virtual Machine başlığı altında ilgili sanal sunucu adı üzerinde sağ tıklanır ve Properties seçilir. Ekrana gelen pencerede Network for Live Migration tabında hangi ağ/ağ kartlarının Live Migration için kullanılacağı yada kullanılmayacağı belirlenebilir.

Ayrınlı bilgi için:
http://www.microsoft.com/download/en/confirmation.aspx?id=9843
http://technet.microsoft.com/en-us/library/dd446679(v=ws.10).aspx