Ekim ayı Operations Manager ile ilgili yenilikler aşağıdaki gibidir:

• Güncellenen Yönetim Paketleri: Windows Server Operating System Management Pack, Active Directory Management Pack, ConfigMgr 2007 Management Pack
• OpsMgr 2007 R2 artık SQL 2008 R2 SP1′i destekliyor.
• Tim McFadden MP dosyalarını XML’e çevirmek için yeni ve çok kullanışlı bir araç yazdı.
• SQL Server PDW appliance cihazlarını monitor etmek için Microsoft SQL Server 2008 R2 Parallel Data Warehouse Appliance Management Pack yayınlandı.

SCOM 2012′de birçok yeni özellik geldi, her tarafında birkaç değişiklik veya en azından rötuş bulunmakta. Ancak ne yazık ki SCOM 2012′de ACS konusunda herhangi bir geliştirme veya yenilik gelmemekte.

Bunun sebebinin, Microsoft’un GRC tarafının artık apayrı bir ekip tarafından geliştirilmesi ve bu ekibin de BT ortamında denetleme süreçlerini Service Manager üzerinde geliştirdiğini, zaman içinde bu özelliğin tamamen SCOM’dan SCSM (Service Manager) ‘a alınacağı konusunda dedikodular var.

SCOM 2007 mimarinizi SCOM 2012′ye yükseltmeden önce tüm donanım ve yazılım ön koşullarını karşılamanız gerekmektedir. SCOM 2012′nin desteklenen konfigürasyonları için http://technet.microsoft.com/library/hh205990.aspx adresindeki makaleden faydalanabilirsiniz.

Mimarisinizi Operations Manager 2012′ye yükseltirken takip etmeniz gereken teknik dokümana http://technet.microsoft.com/en-us/library/hh205974.aspx adresinden erişilebilir. Aşağıdaki diyagram mimarinizi Operations Manager 2012′ye yükseltirken takip edebileceğiniz üst seviye bir iş akışı diyagramıdır.

Müşterilerimizde birçok zaman ürettiği bilgi ve hataları Windows Event Log’una yazmak yerine sistem üzerinde oluşturduğu bir dosyaya yazan bir BT bileşeni ile karşılaşıyoruz. Bu tip durumlar için Operations Manager’ın Log Dosyası’nın içeriğini okuyup, sizin verdiğiniz parametrelere göre uyarı veya hata üretme gibi bir özelliği var, bu özelliği de eminim birçoğunuz birçok defa kullanmıştır.

Bununla birlikte forumlarda bu konuda oldukça soru gelmesi sebebiyle bu konudaki püf noktaları yayınlamak istedim.

Öncelikle aşağıdaki noktalara dikkat etmekte fayda var:

Log dosyasını temizlemeyin

Operations Manager log dosyanızdaki “en son kontrol edilen satır” ı hatırlayacaktır. Örneğin, en son 120 numaralı satırda kaldıysa, bir sonraki kontrol zamanında 101. satırdan devam eder. Eğer log dosyasını silerseniz log dosyası 1. satırdan başlayacaktır ve SCOM, log dosyanız 120. satıra gelene kadar okumayacaktır.

Operations Manager will remember the last checked line within your log file. So in case that was in line 100, SCOM will start reading in line 101 the next time the workflow runs. If you decide to clear the log file and start filling it from line 1, SCOM will not proceed until line 101 is reached

Aynı log dosyasına yazıyorsa

Yeni log dosyası oluşturmuyorsa (sürekli aynı log dosyasına yazıyorsa), dosyanın boyutuna dikkat edin. Bunun için dosya boyutu belirli bir rakama ulaştığında SCOM’a uyarı oluşturtabilirsiniz.

Yeni dosya oluşturuyorsa

Belirli bir zamanda (günlük, haftalık vb) veya belirli bir dosya boyutuna ulaşıldığında otomatik olarak yeni dosya oluşturuyorsa (ki genelde bu tercih edilir) gerçek dosya isminin her zaman değişmek zorunda olduğunu unutmayın. Örneğin, güncel log dosyasının ismi uygulama_guncel.log iken eski log dosyalarını uygulama_<tarih>_<zaman>.log ya da benzer bir şekilde arşivliyor olabilir. Yeni oluşturulan dosyanın “Oluşturulma zamanı” etiketi eski dosyadan daha yeni olduğu sürece SCOM için problem olmaz, yeni dosyayı algılar ve devam eder.

Ancak, NTFS’te bir dosyayı sildiğinizde ve aynı dakika içinde aynı isimde yeni bir dosya oluşturduğunuzda yeni dosyanın “oluşturulma zamanı” eskisi ile aynı olacaktır ve SCOM da bu yeni dosyaya sanki içi temizlenmiş bir dosya olarak yaklaşacak ve birinci maddedeki (Log dosyasını temizlemeyin) problem ile karşılaşacaksınız.

Bu senaryoyu kolaylıkla test edebilirsiniz:

1. Bilgisayarınızda “dosya.txt” isminde bir dosya oluşturun.
2. Oluşturulma zamanına bakın.
3. En azından bir dakika bekleyin ve “şu anki zaman” ile “oluşturulma zamanını” aklınızda tutun.
4. Dosyayı silin.
5. Dosyayı sildikten sonraki 1 dakika içinde aynı isimde bir dosya oluşturun.
6. Dosyaının “oluşturulma” zamanına baktığınızda bir önce oluşturduğunuz dosya ile saniyesine kadar aynı olduğunu göreceksiniz.

Farklı bir senaryo olarak:

1. Bilgisayarınızda “dosya.txt” isminde bir dosya oluşturun.
2. Oluşturulma zamanına bakın.
3. En azından bir dakika bekleyin ve “şu anki zaman” ile “oluşturulma zamanını” aklınızda tutun.
4. Dosyayı silin.
5. Bir dakikadan daha uzun bir süre bekleyin.
5. Aynı isimde bir dosya oluşturun.
6. Dosyaının “oluşturulma” zamanına baktığınızda bir önce oluşturduğunuz dosya ile aynı olmadığın, güncel tarihi aldığını göreceksiniz.

Bunun sebebi, NTFS’in metadata’sının dakikada bir güncellenmesidir.

İlgili log dosyalarını oluşturan yazılımlar / donanımlar ise genelde eski log dosyasını arşivledikten sonra aynı dakika içinde yeni dosya oluşturular! SCOM ise bu dosyalara sanki dosyanın içi silinmiş gibi davranır.

Bu konuda bir geçiçi çözüm ararsanız: güncel log dosyasında da (mümkünse) tarih ve zaman kullanmak (jenerik bir isim kullanmamak) ve log dosyasını izlerken direk dosya ismi vermek yerine değişken kullanmak. Örneğin, log dosyanız uygulama_<tarih>_<zaman>.log ise iş akışını “uygulama_*_*.log” isimli dosyayı izlemek için oluşturabilirsiniz.

SCOM 2012 kurmadan önce göz önünde bulundurmanız önerilen birkaç önemli nokta:

• RMS (Root Manageme Server) Rolü artık yok. SCOM 2012′de tüm Yönetim Sunucuları (Management Servers) hemen hemen benzer özelliklere sahiptirler, eşittirler.  Tıpkı NT4 domainlerinden Windows 2000 ve sonrası forest’lara geçiş sırasında geriye dönük uyumluluk için PDC Emülatörü rolü oluşturulduysa buna benzer olarak SCOM 2012 için de PDC Emülatörü rolü oluşturulmuştur. RMS Emülatörü çalışmak için RMS’e ihtiyaç duyan eski yönetim paketlerinin SCOM 2012 ortamında da çalışmasına olanak tanır. Bu rol PowerShell kullanılarak taşınabilir veya yönetilebilir (set-scomrmsemulator , get-scomrmsemulator)
• Kaynak Havuzları (Resource Pools). Ağ cihazları ve Windows olmayan sunucuların hata durumunda failover’ı için artık kaynak havuzlarını kullanabiliriz. Burada aklınızda tutmanız gereken nokta Windows ajanları failover için kaynak havuzlarını kullanmazlar ve failover konusunda SCOM 2007′dek ile aynı davranışı sergilerler. Aynı zamanda bir diğer önemli nokta da, kaynak havuzlarının sadece Health Service’in fonksiyonu için geçerli olduğu SDK fonksiyonalitesi için geçerli olmadığıdır. Dolayısıyla kaynak havuzlarını OpsMgr konnektörleri veya raporlama için kullanamazsınız.
• Operations Manager Yönetim Grubu. Artık kurulum sırasında veya farklı bir noktada Operations Manager Yönetim Grubu sorulmamaktadır. Bunun yerine, kurulum sihirbazı otomatik olarak yerel sunucudaki “Administrators” grubunu Operations  Manager Administrators rolüne atamaktadır. Operations Manager kurulumunu, kuracağınız ilk yönetim sunucusunda Administrator yetkisine sahip bir kullanıcı ile çalıştırmanız gerekmektedir, bu sayede kurulum tamamlandığında operasyon konsolunu kullanabilirsiniz. Bu konuda doğru yaklaşım her yönetim sunucusunda global ve lokal seviyede bir OpsMgr Admins güvenlik grubu oluşturmak ve ilgili kullanıcıları global gruba ekleyip, gloabl grubu da lokal gruba eklemek, devamında ise operasyon konsolundan lokal gruba OpsMgr Admins rolü atamaktır.
• Raporlama. Raporlama artık ayrı bir kurulum değil, başlangıç kurulum sürecinin bir parçasıdır. Dolayısıyla, artık SCOM kurmak için Reporting’i de aynı zamanda kurmak zorundasınız.
• Full Text Search. Bu SQL Servisi artık birçok System Center ürününde standart gereksinim olarak istenilmektedir.

İlgili makale için http://support.microsoft.com/kb/2591380 adresini ziyaret edebilirsiniz.

İlgili haber için: http://blogs.technet.com/b/momteam/archive/2011/08/10/scom-2007-r2-and-sp1-now-supports-sql-server-2005-sp4.aspx

Değişiklikleri, düzeltilen alanları ve yönergeleri içeren makale:

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

Aşağıdaki adresten indirebilirsiniz:

http://www.microsoft.com/download/en/details.aspx?id=26938

OpsMgr 2007 R2 tümleşik güncellemelerinin (Cumulative Update) tamamının listelenebileceği adres:

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

——–

• Restarts of non-Operations Manager services when the agent is updated is resolved.
• UI hang caused by SDK locking.
• Web console is timing out while opening the left navigation tree.
• Reports - Drill-through fails due to rsParameterTypeMismatch in the EnterpriseManagementChartControl.
• Reports - Edit Schedule button is disabled with SQL Server 2008 R2.
• Reports - Scheduled Reports view for Windows Server 2003 and SQL SRS 2005 SP3 CU9 - returns System.IndexOutOfRangeException: Index was outside the bounds of the array.
• ACS - Event log message is truncated or corrupted in SCDW.
• ACS Filter fails for certain wildcard queries.
• ACS - Updated ACS reports
• Workflows - TCP Port Probe incorrectly reports negative ping latency.
• Workflows - MissingEvent Manual Reset Monitor does not work as expected.
• Workflows - Signed MPs cannot be imported when new attributes are added to existing classes.

Cumulative Update 5 for Operations Manager 2007 R2 resolves the following issues:

• Performance data for LVM managed partitions is not available
• Process monitor does not retain name if run via symbolic link
• AIX with large number of processes crashes with bad alloc

Cross Platform Cumulative Update 5 for Operations Manager 2007 R2 adds the following features:

• Support for Red Hat 6

Uzun süredir test ettiğimiz ve beklenen Operations Manager 2012 halka açık beta sürümü yayınlandı.

İndirmek için: http://www.microsoft.com/download/en/details.aspx?id=26804

Destek ve tartışma grupları için: http://social.technet.microsoft.com/Forums/en-US/category/systemcenteroperationsmanager

Operations Manager ilk çıktığında temel seviyede Microsoft ürünlerini izlemekteydi. 2007 versiyonu ile beraber Operations Manager, BT Hizmet Yönetimi ailesinin bir parçası olmaya aday, veri merkezinizdeki işinizi etkileyen tüm BT bileşenlerinin sağlığını birçok perspektiften izlemeye aday bir çözüm olarak piyasaya çıktı ve birçok büyük ölçekli kurumda kabul gördü.

2007 versiyonunda ağ izleme, uygulama izleme gibi birçok özellik vardı, R2 versiyonu ile Operations Manager artık sınırlarını net olarak Microsoft dünyasından büyük ölçekli bir kurumun veri merkezindeki tüm BT bileşenlerine doğru genişletti.

Bu sırada birçok kaliteli Microsoft İş Ortağı çok kaliteli yönetim paketleri yayınlayarak bu sınırları Oracle, IBM, HP, SAP gibi farklı üreticilerin ürünlerine doğru genişlettiler. Bu yönetim paketlerinin birçoğu o kadar kaliteliydi ki, ilgili üreticinin kendi uygulamasını izlesin diye ürettiği kendi yazılımından daha başarılı şekilde izlemeyi başardılar.

Operations Manager 2007 R2 ile beraber Microsoft’un daha da iyileştirme yapması gereken noktalar net olarak kendini belirli etmeye başladı ve Microsoft, Operations Manager 2012 ile beraber bu alanlardaki açıkları kapatmayı hedefleri.

Bu alanlardan en önemlilerinden biri ağ izleme idi. Microsoft SCOM 2012 ile beraber bu konuda birçok yenilik getirdi. Bir diğer alan ise .NET uygulama izleme konusundaydı. Bu noktada Microsoft, AVIcode’u satın alarak SCOM 2012′de ürünün içine dahil etme kararı aldı.

AVIcode

AVIcode, Microsoft satın almadan önce de Gartner tarafından .NET Uygulama İzleme konusunda dünya üzerindeki en başarılı yazılımdı. Oldukça detaylı ve kapasiteli olan yazılımın yaptığı iş “Çalışmak için sunum katmanı, veri tabanı katmanı, web sunucusu katmanı, ağ katmanı gibi birçok katmanın bir arada ve başarı ile çalışması gereken uygulamalarda hata anında hatanın izole edilmesi ve çözülmesi” olarak özetlenebilir. AVIcode’un en büyük avantajlarından biri, geliştirmiş olduğunuz .NET uygulamanızın son kullanıcı deneyimini kolaylıkla yakalayıp, son kullanıcıdan veri tabanına gidene kadar olan yolculuktaki tüm uğrak noktalarının performansını ve çıktılarını ayrı ayrı değerlendirip analiz edebilme yeteneğidir.

AVIcode, sunucu/bileşenleri, son kullanıcı , transaction gibi farklı perspektiflerden uygulamalarınızı izlerken, uygulamaların farklı katmanlarda çalışan bileşenlerin birbirlerine olan bağımlılıklarını da keşfedebilmekte, dolayısıyla uygulamanızı uçtan uca bir bütün olarak izleyebilmektedir.

Production ortamında uygulamalarınızı kod seviyesi hatalar, performans darboğazları, güvenlik ve bağlantı hataları gibi birçok perspektiften izleyebilir ve detaylandırılması çok kolay olan görsel grafik ve raporlarları kullanımınıza sunar. Production ortamlarında rahatlıkla kullanılabilir, çünkü AVIcode herhangi bir kod değişikliğine veya kodun yeniden derlenmesine ihtiyaç duymaz, aynı zamanda göz ardı edilebilir bir işlemci yükü ile çalışır.

AVIcode aynı zamanda Biztalk ve SharePoint çözümleri ile de entegre çalışabilirken Visual Studio Team System ile entegre çalışarak yazılımcıların en önemli araçları arasında yerini almaktadır.

Exchange Server 2010 Management Pack ve Korelasyon Motoru ile ilgili anlaşılması gereken önemli bir başka nokta da Korelasyon Motorunun var oluşunun Exchange Management Pack’i diğer Management Pack’lerden ayrılmasını sağlayan etkileridir.

Exchange Server 2010′da Korelasyon Motoru’nun var olması bu yönetim paketini diğer yönetim paketlerinden aşağıdaki noktalarda farklılaştırmaktadır:

• Exchange Server 2010 yönetim paketi motitörleri durum değişikliği uyarılarında (State Change Events) otomatik olarak uyarı göndermeye ayarlanmamıştır. Bunun sebebi, uyarının gönderilip gönderilmeyeceğine Korelasyon Motoru’nun karar vermesidir.
• Korelasyon Motoru servisi durdurulursa, Exchange Server 2010 Yönetim Paketi Operations Manager üzerinden Exchange ortamınızın sağlığı ile ilgili uyarı veremez. Bunun sebebi, normalde tüm monitör’lerin “otomatik uyarı gönder” modunun kapalı olması, uyarıyı Korelasyon Motoru’nun vermesinden dolayıdır. Korelasyon Motoru durdurulursa Korelasyon Motorunun çalışmadığına dair genel bir uyarı gelir.

Korelasyon Motoru’nun var olması, aşağıdaki noktalarda değişiklik yaratmamaktadır.

• Override’lar normal şekilde çalışmaktadır, diğer yönetim paketlerinde yaptığınız gibi monitörler ile ilgili parametrik değerleri değiştirebilir veya monitörleri devre dışı bırakabilirsiniz (disable).
• Bakım (maintenance) modunda olan monitörler Korelasyon Motoru tarafından göz ardı edilirler. Bakım modunda olan monitörler durum değişikliği uyarılarını oluşturmadıkları için Korelasyon Motoru’nun değerlendirmesine dahil olmazlar.
• Exchange Server 2010 Yönetim Paketine Per-monitor uyarı kuralları eklenmiştir. Uyarı kuralları ilgili monitörler için uyarı üretmese bile, per-monitor uyarı kuraları operatörlerin ilgili uyarı için kuruma özel notları “Company Knowledge” alanına girmesine izin verir.
• Diğer yönetim paketleri Korelasyon Motoru’nun varlığından etkilenmezler.

Sonuç olarak, akılda  tutulması gereken önemli bir nokta, uyarının algılanmasından konsola yansıtılmasına kadar olan süreçte, korelasyon tarafından müdahale edilerek iyileştirilen tek adımın “uyarı oluşturmak için durum değişikliğini izle” adımı olduğudur.

SCOM 2012 beta versiyonu ile beraber entegre edilmiş AVIcode’u da test etmeye başlayabilirsiniz.

AVIcode’un SCOM 2012 ile birleştirilmesi sonucu, eskiden AVIcode’da alışık olduğumuz detaylı, ince ayarlar gidip yerine daha az konfigürasyon seçeneği sunan, ancak bir o kadar da kullanımı kolaylaşmış bir ürün gelmiş.

Bu yeni AVIcode ile beraber, beta versiyonundaki ilk izlenimler aşağıdaki gibidir:

Windows uygulamaları

Beta versiyonunda ilk göze çarpan, eskiden AVIcode ile yapabildiğimiz Windows servis ve executable izleme özelliğinin olmadığı, sadece web uygulamalarının (+web servisleri) izlemesinin desteklendiğidir. Elbette bu özellik entegre edilmediği taktirde gerçek hayattaki birçok senaryonun hayata geçirilemeyeceği, masa üstü uygulamalarının, windows servisleri ve IIS üzerinden sunulmayan WCF’lerin izlenmesinin mümkün olamayacağı gerçeği de önemli bir nokta.

Aynı şablona birden fazla uygulama eklemek

Aynı şablona birden fazla uygulama ekleyebilirsiniz, bu sayede artık birçok uygulamayı bir anda izlemeye başlamak çok daha kolay.

Sunucu konfigürasyonu

AVIcode’un en can alıcı özelliklerinden biri olan sunucu tarafında yapılankonfigürasyon sayesinde fast SQL çağrıları, uygulamaların internal çağrıları gibi birçok detaylı nokta izlenebilmekteydi. Var olan durumda tek yapılabilen neyin izlenmesi ve neyin izlenmemesi gerektiğini belirtmekten ibaret. Bu, yönetim kolaylığı sağlarken uygulama geliştiriciler için .NET izleme özelliğini çok zayıf hale getirmekte.

Standalone versiyon

SCOM 2012 ile beraber AVIcode’un tek başına kurulabilen versiyonunu öldüreceklerini biliyorduk. .NET uygulama izleme özelliğinin de diğer tüm özellikler gibi sadece operasyon konsolundan yönetilmesi, yönetim ve operasyon açısından iyi bir yaklaşım olsa da, yazılımcıların birçoğunun Operations Manager bilmediğini (ve bilmek de istemeyeceğini) var saydığımızda büyük bir dez avantaj olabilir.

Kurulum

Microsoft’un en başarılı yaptığı işlerden biri olan “kolay ve sorunsuz kurulum” burada da kendini gösteriyor. AVIcode’un eski kurulumuna kadar çok daha kolay bir kurulum süreci bulunmakta.

• .NET izleme ajanı artık SCOM’un bir parçası olarak yaygınlaştırılmakta, ek bir konfigürasyon gerektirmemekte.
• AVIcode Advisor bileşeni SCOM Web Konsolu kurulumu ile beraber kurulmakta. Artık “App Advisor” olarak alınmakta ama aslında alıştığımız AVIcode Advisor uygulaması.
• İstemci tarafı izleme .NET uygulama izleme ile entegre edilmiş durumda, herhangi bir ek yönetim paketi veya ek kurulum gerektirmemekte.

Veri Analizi

Alışık olduğumuz AVIcode SEViewer uygulaması gizlenmiş durumda. Ancak, halen (eskiden olduğu gibi) SCOM alert context’e gidip “click here” yazan yere tıklayıp “App Diagnostics” web uygulamasını çalıştırabiliyoruz ve SEViewer’da eskiden gördüğümüz detay penceresinin aynısı açılıyor, ancak bu pencere SEViewer’dan geriye kalan tek fonksiyonalite; App Diagnostics ara yüzünde alışık olduğumuz gruplama veya filtreleme gibi SEViewer özellikleri artık bulunmamakta.

Veri Tabanı

.NET Monitoring için ayrı bir veri tabanı yok (ki bu güzel birşey). Tüm veri, Operations Manager veri tabanına entegre edilmiş durumda. .NET monitoring ile ilgili eklenen verilerin bakımının veya veri tabanı seviyesindeki ince ayarlarının nasıl yapılacağı ile ilgili bir bilgi ise henüz yayınlanmış durumda değil.

Bu özelliklerin bir çoğu RTM versiyona eklenebilir, değişebilir. Ancak şu anda ilk izlenimler bunlar.

Heterojen ortamlarda Opalis çok kullanışlı bir çözüm olarak uygulanmakta. Özellikle Microsoft çözümleri ile beraber SCOM’un UNIX/Linux monitoring özelliğini de kullananlar Opalis kullanmak istediklerinde birçok senaryoda UNIX/Linux sunucular ile ilgili bazı bilgilere göre (disk alanının dolu olması, işlemci performansı, boş bellek vs) otomatik iş akışları oluşturmak veya var olan iş akışlarında UNIX/Linux ile ilgili bazı bilgileri sorgulamak zorunda kalabiliyorlar.

Opalis’i bu tip iş akışları için de kullanabilirsiniz. Nasıl yapılabileceği ile ilgili http://blogs.technet.com/b/opalis/archive/2010/11/11/using-opalis-to-get-info-from-the-scx-cross-platform-agent.aspx adresinde detaylı bilgi mevcut.

Aklınıza takılan ya da uygularken sorun yaşadığınız taktirde benimle iletişime geçebilirsiniz.

Endüstrinin SOA tabanlı distributed application’lara doğru hızla ilerlemesi ile SCOM’daki Synthetic Application Monitoring özelliği daha da önemli hale geliyor. SCOM’un bu özelliği sayesinde “Web Site’ınız veya Web Servisiniz neden LOB uygulamanızın yavaş çalışmasına sebep oluyor?” sorusuna cevap vermek için detaylı ölçümler ve incelemelerde bulunbilirsiniz. Kullanıcıların bir LOB uygulaması ile etkileşimini birebir taklit ederek son kullanıcının benzer deneyim kalitesini yaşayıp yaşamadığını sürekli olarak kontrol edebilirsiniz.

Synthetic monitoring için takip etmenizde faydalı olabilecek tavsiyeleri aşağıdaki gibi özetledik:

• Yazılım geleştiricilerden ilgili uygulama ile ilgili performans eşik değerlerini alın ve operasyonel sonuçlar sağlayın.
• Kurumunuz için en önemli iş sorgularını içeren synthetic script’ler hazırlayın
• Kullanıcılarınızın bulunduğu tüm WAN bölgelerinden uygulamanızı düzenli olarak sorgulayın
• Synthetic sorgular ile oluşturduğunuz yükün sonuçlarını uygulamanızın performans sonuçlarını raporlamak için kullanın

Exchange 2010 Yönetim paketi ile birlikte correlation engine (korelasyon motoru) geldi. Korelasyon Motoru aslında Operations Manager SDK’sını kullanan bir Windows Servisidir ve temel görevi sağlık modelini değerlendirip durum değişikliği olaylarını işler. Sağlık modelini hafızada saklayarak ve sağlık durumu değişimi olaylarını işleyerek Korelasyon Motoru sistemin durumuna göre uyarı (alert) oluşturup oluşturmamaya karar verir.

Bir problem oluşması durumunda birçok Operations monitor’ü durum değiştirir (kırmızı-yeşil-sarı) ve bu durum değişiklikleri Root Management Server (RMS)’a yönlendirilir. RMS tarafından alınan uyarılar daha sonra Korelasyon Motoru’na gönderilir ve Korelasyon Motoru gerekli durumlarda RMS SDK’sını kullanarak uyarıyı işler ve uyarı konsolda gözükür. Yani aslında kısaca, Korelasyon Motoru, monitörlerin ürettiği hatalar ile konsol arasında durarak konsola yansıyan hataların niteliğini ve kalitesini kontrol eder.

Korelasyon Etkenleri

Korelasyon Motoru tarafından gerçekleştirilen görevler birçok etkeni baz alır.

Monitör Durum Değişikliği Olayları. Monitörler event log mesajı, performans sayaç eşik değerleri veya PowerShell task çıktıları gibi birçok noktadan bilgi toplarlar ve bir problem oluştuğunda veya çözüldüğünde (kırmızı dan yeşile veya yeşilden kırmızıya) veya ajanlar erişilemez olduğunda veya maintenance moda alındığında bu değişiklikleri durum değişikliği olayı olarak kayıt altına alırlar.

Tipik olarak, yeşilden kırmızıya durum değişikliği gerçekleştiğinde uyarı (alert) kuralları devreye girerler ve uyarı oluştururlar. Exchange Server 2010 Yönetim Paketi’nde, sürecin bu şekilde işlemediğini fark edersiniz, Exchange Server Korelasyon Motoru sayesinde bir sağlık durumu değişimi sonucunda otomatik olarak uyarılar üretilmez, Korelasyon Motoru duruma göre konsola yansıtılması gereken en uygun uyarıya karar verir.

Sağlık Modeli. Exchange Server 2010 sağlık modeli tarafından Operations Manager’a import edilen class hiyerarşisi çok büyük ve karmaşıktır. Class hiyerarşisi tüm sistemdeki bileşenlerin birbirine olan bağımlılıklarını tanımlayan class ilişkilerini içerir. Bu bileşen bağımlılıklarının tanımlanması ile beraber, Exchange Server 2010 yönetim paketi Exchange organizasyonunuzun sağlığını daha iyi yorumlar ve anlar. Örnek olarak, eğer Exchange Server 2010 Yönetim Paketi, Active Directory’nin temel fonksiyonlarının offline olduğunu fark ederse, aynı zamanda Exchange mesajlaşma mimarisinin de tam işlevli olarak çalışmadığını raporlayacaktır.

Zamanlama. Korelasyon Motoru 90 saniyelik aralıklarla çalışır. Birden fazla monitör için durum değişikliği olayları aynı anda gelirse, Korelasyon Motoru, ITIL’daki problem yönetimi sürecine benzer bir yaklaşım ile, gelen hatalarla ilgili farklı bir potansiyel hata gelecek mi diye bekler ve kök sebep analizi gerçekleştirir.

Korelasyon Algoritması

Korelasyon Motoru Sürecinin Gözden Geçirilmesi

1. İlk olarak Operations Manager SDK’sına bağlanarak sağlık modeli hiyerarşisi ve örnek (instance) sağlık durumunu alır (bu adım sadece servis başlangıcında veya oluşan hatalar bu gerektirdiğinde çalıştırılır)

2. Exchange Management pack’teki ilgili objeler ile ilgili sağlık değişim olayları ile ilgili Operations Manager sorgulanır.

3. Eğer yeni NSI (Non Service Impacting - Hizmeti Etkilemeyen) durum değişiklikleri ortaya çıkarılırsa bunlarla ilgili uyarı (alert) üretilir.

4. Anahtar Sağlık Göstergeç (Key Health Indicator - KHI) monitörleri değerlendirilir ve birbiri ile alakalı kırmızı durumdaki KHI zincirleri izole edilir. Bu zincirler bir objenin sağlıklı çalışması için bağımlı olduğu diğer varlıklarda hata olduğunu ve bu hatanın diğer bağımlı objeleri de etkilediğini gösterir. Bu bağımlılıkların analiz edilip anlaşılması en önemli adımlardan biridir.

5. KHI zincirindeki birbirini tetikleyen birçok hata arasından kök sebep bulunur ve bu kök sebeple ilgili hatalar konsola gönderilir.

6. 90 saniye beklenir ve yukarıdaki 2. adımdan itibaren süreç tekrar çalıştırılır.

Korelasyon Motoru Sürecini İlgilendiren Ek Bilgiler

• Eğer KHI zinciri hem “hata (error - kırmızı)” hem uyarı (warning - sarı)” monitörleri içeriyorsa, uyarı (alert), kök sebep monitörünün class’ından bağımsız olarak “hata” olarak gönderilir. Örnek olarak, eğer üst katmanda çalışan bir süreç kritik hata durumunu yakalamak için gerekli bir hata monitörü tanımladıysa ve bu hata monitörü bağımlılıklar göz önüne alındığında bir uyarı (warning) monitörü ile korale edildiyse, uyarı, bağımlılığı olan warning monitörü için üretilir, ancak uyarı yerine hata olarak gösterilir.
• Tüm class ilişkileri uyarı korelasyonu için kullanılmaz. Korelasyon Motoru tarafından kullanılan spesifik ilişkilendirme bilgiler için Ek-Class Hiyerarşisi dokümanından faydalanabilirsiniz.
• Korelasyon Motoru tarafından konsola gönderilen final uyarının Alert Context alanında KHI zinciri (adli monitörler de dahil olmak üzere) incelenebilir. Bu sayede ilgili uyarı için korale edilen monitörler incelenebilir ve bağımlı olan monitörlerden sağlanan uyarılar incelenerek spesifik hatalar ayıklanabilir.
• Sağlık modeli değerlendirilirken Maintenance (Bakım) modunda olan monitörler göz ardı edilir.

İndirmek için : http://www.microsoft.com/downloads/en/details.aspx?FamilyID=7150bfed-64a4-42a4-97a2-07048cca5d23

Birçoğumuzun SCOM çözümü ile ilgili hayali açılan uyarıların kurumunuz için gerçekten uyarı niteliğinde olduğu kalitede bir SCOM çözümüne sahip olmaktır. Bunun için ilk adım, birçoğumuzun önemsemediği yönetim paketlerinin dokümanlarını dikkatli okumaktır. Bu dokümanlarda yönetim paketindeki hangi kurallar ve monitor’lerin kurumunuz için özelleştirilmesi gerektiğini detaylı olarak belirtir. Devamında var olan uyarılar dinlenip zaman için override edilerek kurumunuza uygun hale getirilmelidir. Bu konu apayrı bir konu ve bununla ilgili Microsoft’un bir Solution Accelerator’u da mevcut.

Bunun ötesinde optimizasyon ve otomasyon için Opalis kullanılabilmektedir.

Kurumunuzda başarı ile geliştirdiğiniz ve optimize ettiğiniz (gelen kırmızı alert’ın kurumunuz için gerçekten bir kırmızı alert’i ifade ettiği) SCOM çözümünden belirli bir süre (genelde 6 ay kadar) sonra yapmanızı tavsiye edeceğim şey “TOP 10 alerts” raporu almaktır. Bu raporun sonucu olarak, kurumunuzda BT destek ekibinin en çok zaman harcadığı alert’leri ortaya çıkarabilirsiniz. Bir sonraki adım olarak, bu alert’leri çözmek için destek ekiplerinin nasıl bir yöntem izlediğini belirlemek ve bunu Opalis ile otomatikleştirmek işinizi kolaylaştıracak, insan hatasını azaltacak ve ilgili alert’lerin çözümü için gereken süreyi azaltarak destek ekibinize diğer alert’ler ile uğraşmak için zaman oluşturacaktır.

Örnek olarak birçok kurumun çok sık yaşadığı “Low disk space (Düşük disk alanı)” alert’ini ele alalım. Incident Management sürecinin amacı servis kesintisi olan sistemi en hızlı şekilde servis verebilir duruma getirmektir. Yani kısaca, bir sunucunun disk alanı yetersizse, “Neden yetersiz?” “Hangi uygulama en çok disk alanı harcıyor?” “Nerede hata yaptık?” gibi sorulara cevap aramadan önce ilk yapılması gereken şey yetersiz disk alanı problemini çözmektir. BT destek ekiplerinin incident management sürecinde yetersiz disk alanı problemini nasıl çözdüklerini incelediğimizde aldığımız cevap şu şekilde oluyor:

“Önce sunucuya login olup gerçekten disk alanı yetersizmi incelemek istiyoruz. Her ne kadar SCOM hata yapmasa da, birebir görmeyi her zaman tercih ediyoruz. Devamında uygulama sorumlusuna haber verip disk alanının neden yetersiz olduğunu araştırmadan ve kalıcı çözüm bulmadan önce hızla diskte yer açmamız gerekiyor. Bunun için de genelde TMP dosyalarını sıkıştırıyoruz ve dump file’lar varsa onları siliyoruz. Bu iki aksiyon genelde uygulama sahibine haber verip kalıcı çözüm için bize yeterli disk alanını kazandırıyor, ama yine de devamında yeterli disk alanının açılıp açılmadığını kontrol ediyoruz.”

Bu görevi otomatikleştirmek için Opalis’te aşağıdakine benzer bir iş akışı tasarlanabilir:

SCOM’dan alınan raporlar ve destek ekibindeki gerekli kişilerle toplantılardan sonra yukarıdakine benzer birçok tekrar eden problem ve rutin ilk müdahele senaryoları ortaya çıkacaktır. Bu senaryoları Opalis ile otomatikleştirerek ciddi oranda avantaj sağlayabilirsiniz.

Makalemin bu son bölümünde sizlere Bridgeways yönetim paketleri ile Microsoft dışındaki üreticilerin ürünlerinin nasıl izleneceğinden bahsedeceğim.

“Microsoft, kendi ürettiği işletim sistemleri ve ürünleri en iyi kendisi dinler ama Microsoft dışındaki işletim sistemi ve yazılımları aynı kalitede dinleyebilir mi?” sorusuna cevap olarak hazırladığım bu makale umarım faydalı olmuştur.

Bridgeways Management Pack’lerinin kullanılarak JBOSS, MySQL, Oracle gibi non-Microsoft çözümlerin de incelenmesi

Oracle SQL Traffic:

Oracle Table Scans:

Oracle Transactions Summary:

Oracle Active Sessions:

Oracle Tablespace Size:

Oracle Tablespace Usage:

Operations Manager 2007 R2 ile beraber Servis Seviyesi İzleme özelliği oldukça güçlendirildi. Bu özellik sayesinde ortamınızda oluşturduğunuz servis ağaçlarını hızlı bir kurulumla Sharepoint üzerinden sunabilmektesiniz.

Operations Managet 2007 R2 Service Level Tracking (SLT) özelliği ile UNIX / Linux servis ağacının servis seviyesinin Sharepoint ortamında izlenmesi

Oluşturulan Distributed Application’un %99 erişilebilirlik hedefine ulaşıp ulaşılmadığının Sharepoint ortamından izlenmesi:

Linux sunucuların mantıksal disklerinin Free space, read ve write değerlerinin hedeflenen kapasitede hizmet verip vermediğinin Sharepoint ortamından izlenmesi:

UNIX / Linux sunucu bileşenlerinin veya bu bileşenlerle oluşturulan servis ağacının erişilebilirlik ve  detaylı performans raporlarının oluşturulabilmesi

Operations Manager’ın bir diğer önemli özelliği ise kolay ve kullanışlı raporlama özellikleridir. Servis ağacının herhangi bir seviyesinden veya herhangi bir bileşenden erişilebilirlik, performans gibi birçok raporu kolaylıkla alabilirsiniz.

Unix sunucular üzerinde çalışan Oracle hizmetlerinin genel erişilebilirlik raporu:

Raporlar interaktiftir, istenilirse alt detaylara doğru inilip erişilebilirliği etkileyen bileşenlerin neler olduğu kolayca görülebilir:

Makalenin bu bölümünde kaldığımız yerden devam ediyoruz.

Daha önceki makalelerimizde UNIX / Linux sunucuların processor, disk ve memory perspektiflerinden nasıl izlendiği ile ilgili örnekler göstermiştik. Bu makalemizde UNIX / Linux işletim sistemine sahip sunucuların diğer açılardan incelenmesini inceleyeceğiz.

UNIX / Linux üzerinde çalışan bir veya daha fazla servisin çalışıp çalışmadığının izlenebilmesi

Linux /  Unix üzerinde çalışan servisleri tespit edip, istediğiniz sunucu veya bir sunucu grubu üzerindeki ortak bir servisin sağlık durumunu izleyebilir, sağlık durumu değiştiğinde (servis durduğunda) haberdar olabilirsiniz.

Oluşturulan bu servis objesini servis ağacı modelinize (Distributed Application) ekleyebilir, erişilebilirlik (availability) raporlarında kullanabilirsiniz.

UNIX / Linux sunucuların temel bileşenlerinin keşfedilmesi ve diyagram olarak görüntülenmesi

Operations Manager’ın bir diğer önemli ve kullanışlı özelliği ise altyapınızdaki istediğiniz bileşen veya bileşen grubunu diyagram görüntüsünde görsel olarak ifade edebilmesi ve bileşenler arasındaki ilişkiyi otomatik olarak kurabilmesidir. Bu özellik aynı şekilde UNIX/Linux bileşenleri için de kullanılabilmektedir:

UNIX / Linux sunucularının servis ağacında modellenebilmesi

Operations Manager kullanarak kullanıcılara sunduğunuz hizmetleri son kullanıcı perspektifinden veya veri merkezi perspektifinden modelleyebilirsiniz. Servis ağacı modellerini problem anında problemin kök sebebini bulmakta, altyapının genel olarak kuş bakışı görüntüsünü görmekte veya servis bazlı raporları almakta kullanabilirsiniz.

Makalenin bu bölümünde kaldığımız yerden devam ediyoruz.

Önceki makalelerde ön koşulların neler olması gerektiğini belirtmiştik. Bu makalede bahsettiğimiz özelliklerin hayata geçirilmiş hallerinden örnekler vereceğiz.

UNIX / Linux sunucuların işletim sistemi seviyesinde disk, processor, memory gibi temel bileşenlerinin izlenebilmesi

Ortamdaki Redhat, SunOS ve HP-UX sunucular Operations Manager 2007 R2 ajanı olarak yapılandırılmıştır. Bu işletim sistemleri disk, processor, memory gibi temel bileşenler perspektifinden izlenebilmektedir.

Administration -> Device Management -> Linux/Unix Servers bölümünde Non-Microsoft işletim sistemleri ve mimarilerine göre sınıflandırılmış olarak izlenen sunucular görülebilir:

Operations Manager 2007 R2 ile Linux / Unix sunucuları yönetirken aynı kolay kullanılabilir ara yüzü kullanırsınız.
Bir sunucu ile ilgili sağlık durumunu, o sunucu üzerinde izlenen temel öğeleri ağaç yapısında tek ekrandan izleyebileceğiniz “Health Explorer” Linux/Unix sunucular için de Windows sunucular gibi çalışmakta.

UNIX / Linux sunucuların performans sayaçlarının performans görünümünden incelenebilmesi, resim olarak export edilebilmesi

Herhangi bir sorun anında sorunu gidermek için performans sayaçlarının kullanımı çok önemlidir. Operations Manager 2007 R2, Linux / Unix sistemler üzerindeki tüm performans sayaçları bilgisini merkezi olarak depolar ve geçmişe doğru sizin belirleyeceğiniz zaman aralığı için görüntüler..

Processor Örnek sayaçlar:

Memory örnek sayaçlar:

Disk Örnek Sayaçlar:

Bu bölümde yazımızın kaldığı yerden devam ediyoruz.

Bu makaledeki ortamı kurmak için aşağıdaki yönetim paketleri kurulmuştur:

Microsoft Yönetim Paketleri

• Microsoft.AIX.5.3.mp
• Microsoft.AIX.6.1.mp
• Microsoft.AIX.Library.mp
• Microsoft.HPUX.11iv2.mp
• Microsoft.HPUX.11iv3.mp
• Microsoft.HPUX.Library.mp
• Microsoft.Linux.Library.mp
• Microsoft.Linux.RedHat.Library.mp
• Microsoft.Linux.RHEL.4.mp
• Microsoft.Linux.RHEL.5.mp
• Microsoft.Linux.SLES.10.mp
• Microsoft.Linux.SLES.9.mp
• Microsoft.Linux.SUSE.Library.mp
• Microsoft.Solaris.10.mp
• Microsoft.Solaris.8.mp
• Microsoft.Solaris.9.mp
• Microsoft.Solaris.Library.mp

Non-Microsoft Yönetim Paketleri

• Bridgeways Apache Management Pack
• Bridgeways Oracle Management Pack
• Bridgeways JBOSS Management Pack

Linux / UNIX Ajan Kurulumu

Operations Manager R2 ile UNIX / Linux tabanlı sunuculara ajan kurabilirsiniz. Windows dışındaki ortamlarda Kerberos kimlik doğrulaması mümkün olmayacağı için Operations Manager yönetim sunucusu ve Linux / UNIX tabanlı sunucu arasında sertifika tabanlı kimlik doğrulaması kullanılacaktır. Kullanılacak sertifikalar Operations Manager yönetim sunucusu tarafından imzlanmış olabileceği gibi 3. parti sertifikalar da kullanılabilir (gerekli değildir).

Ajan kurulumu için “Discovery Wizard” kullanabilir veya ajanı manual olarak kurabilirsiniz. Kurulum için Discovery Wizard kullandığınızda, Discovery Wizard aşağıdaki adımları gerçekleştirir:

SERTİFİKA İMZALAMA

Sertifika imzalama adımı aşağıdaki alt adımlardan oluşmaktadır:

1. OpsMgr yönetim sunucusunda çalıştırdığınız Discovery Wizard işlemi Linux / UNIX sunucu üzerinde self-signed bir sertifika oluşturur.
2. Yönetim sunucusu Linux / UNIX sunucusuna “get certificate” isteğinde bulunarak Linux / UNIX sunucunun ürettiği sertifikayı ister.
3. Linux / UNIX sunucusu sertifikayı OpsMgr yönetim sunucusuna gönderir.
4. OpsMgr yönetim sunucusu ilk defa bir Linux / UNIX sunucsu keşfettiği anda kendisina ait bir “anahtar ikilisi (key pair)” ve kendi sertifikasını oluşturur.
5. Kendi oluşturduğu sertifikayı kendi “trusted certificate store” ‘una kopyalar ve sertifikaya güvenir.
6. Linux / UNIX sunucudan aldığı sertifikayı kendi private key’i ile imzalar.
7. Bundan sonraki Linux / UNIX sunucularının sertifikalarını da aynı key ile imzalar, her keşifte tekrar sertifika oluşturulmaz.
8. OpsMgr yönetim sunucusu “put certificate” komutu çalıştırarak imzalanmış sertifikayı ilk oluşturan Linux / UNIX sunucusuna geri gönderir. Linux / UNIX
9. sunucusu WSMAN iletişim katmanı tekrar başlatılarak yeni oluşturulan sertifika aktif hale getirilir.
10. OpsMgr yönetim sunucusu Linux / UNIX sunucusundan kimlik doğrulaması talebinde bulunur. Linux / UNIX sunucusu sertifikayı kullanarak kendini tanıtır ve
11. OpsMgr yönetim sunucusu sertifikanın üzerindeki imzayı okuyarak sertifikanın güvenilir olduğunu doğrular.
12. OpsMgr yönetim sunucsuu Run As Profile ile daha önce tanımlanan kimlik bilgilerini kullanarak Linux / UNIX sunucusu üzerinde kimlik doğrulamasını gerçekleştirir.

LINUX / UNIX RUNAS PROFILE AYARLARI

Linux / UNIX sunucusu ilgili OpsMgr yönetim sunucusu tarafından keşfedildikten sonra ilgili yönetim paketi keşifleri ve iş akışları çalışmaya başlar. Çalışan iş akışlarının başarı ile tamamlanması için kimlik doğrulaması gereklidir. Bu kimlik bilgileri, bilgilerin hangi obje, class veya gruplara uygulanacağı ve hangi sunuculara dağıtılacakları ile ilgili ayarlar Run As Profile’larda belirtilir. Linux / UNIX yönetim paketleri kurulduğu zaman iki farklı Run As Profile oluşturulur:

• UNIX Action Account profile – Bu Run As profile ve ilgili Linux / UNIX kimlik bilgileri düşük güvenlik seviyesi gerektiren aktiviteler tarafından kullanılır.
• UNIX Privileged Account profile - Bu Run As profile ve ilgili Linux / UNIX kimlik bilgileri daha yüksek derecede yetki gerektiren aktiviteler için kullanılırlar, dolaısıyla ilgili Linux / UNIX sunucuları üzerinde daha yüksek yetki sahibi (superuser) olan bir hesaba ihtiyaç duyarlar. Bu hesap root hesabı olabilir.

Operations Manager 2007 R2 “Desteklenen Konfigürasyonlar (Supported Configurations)” güncellendi. Operations Manager 2007 R2 artık SQL Server 2008 SP2′yi aşağıda belirtilen roller için destekler durumda:

• Operations Manager database
• Data Warehouse database
• Audit Collections database
• Reporting (SQL Server 2008 SP2 ile beraber raporlar Operations Console’dan düzgün çalışacaktır, ancak direk olarak SQL Reporting Services’dan çalıştırılan raporlar düzgün gözükmeyebilir. Bu bilinen bir durumdur ve bir sonraki Cumulative Update ile düzeltilecektir)

Günümüzde teknolojinin doğru şekilde izlenmesi ve yönetilmesi her ölçekteki kurumun işinin başarısı ve performansı için önem taşımaktadır. Bununla birlikte, kritik iş bileşenlerinizin üzerinde çalıştığı bilişim altyapınızın sağlığının ve performansının uçtan uca izlenebilir olması servis seviyeniz için en önemli etkenlerden biridir.

Microsoft Operations Manager 2007 R2, Microsoft, UNIX ve Linux platformlarında koşan uygulamalarınız ve alt bileşenlerini tek bir konsoldan erişilebilirlik, performans, güvenlik ve konfigürasyon perspektiflerinden izleyebilmeniz için gereken çözümü sunmaktadır.

Heterojen Ortamların Yönetim Zorlukları

Yapılan araştırmalar büyük BT organizasyonlarının %86’sının heterojen ortamları olduğunu ve bu ortamlarda birçok farklı işletim sistemi bulunduğunu göstermektedir. Bununla birlikte bu sistemler birbirinden tamamen ayrı çalışmamakta, bu sistemler üzerinde çalışan uygulamalar altyapıdaki diğer sistemler üzerinde çalışan uygulamalar ile bir şekilde beraber çalışmaktadır.

Birbiri ile bağlı bileşenleri farklı katmanlarda (son kullanıcı açısından, uygulama katmanı, donanım katmanı, ağ katmanı vb) bir bütün olarak izlemek servis seviyesi yönetimi ve iş sistemleri yönetimi açısından çok büyük önem taşımaktadır.

Birden fazla platform ve teknolojiyi yönetmek için kullanılan ürünlerin ve konsolların farklı olması, birbiri ile başarı ile entegre olmaması beraberinde birçok riski getirmektedir. Bununla birlikte BT organizasyonları her geçen gün daha fazla daha kompleks ortamları ve daha fazla sayıda sunucuyu aynı hatta daha düşük kişi sayısı ile yönetmek zoruna kalmaktadır.

Operations Manager 2007 R2

Microsoft System Center Operations Manager 2007 R2, kurumunuzun ihtiyacı olan uçtan uca yönetim kabiliyetini kurumunuza kazandırarak BT ortamınızda tek bir konsoldan çok daha fazla kontrol sahibi olmanızı sağlar. Operations Manager binlerce sunucunun sağlığını tek bir konsoldan izleyip geriye yönelik raporlayabileceğiniz, kolay kullanılabilen bir ortam sunar.

Operations Manager 2007 ile Microsoft işletim sistemlerinin yanında HP-UX®, Sun Solaris™, Red Hat® Enterprise Linux®, SUSE® Linux Enterprise Server, and IBM AIX 5L® V5.3, Technology Level 6, SP5 (PowerPC) sunucu ortamlarını da izlemenize ve yönetmenize olanak sağlamaktadır.

Bu makalemde Operations Manager 2007 R2′nin aşağıdaki konularda kurumunuza nasıl çözüm sağlayabileceğini örneklerle ispatlamaya çalışacağım:

• Unix/Linux temel işletim sistemi bileşenlerinin izlenmesi. UNIX / Linux sunucuların işletim sistemi seviyesinde disk, processor, memory gibi temel bileşenlerinin izlenebilmesi
• Performans sayaçları. UNIX / Linux sunucuların performans sayaçlarının performans görünümünden incelenebilmesi, resim olarak export edilebilmesi
• Servislerin izlenmesi. UNIX / Linux üzerinde çalışan bir veya daha fazla servisin çalışıp çalışmadığının izlenebilmesi
• Diyagram görüntüleri. UNIX / Linux sunucuların temel bileşenlerinin keşfedilmesi ve diyagram olarak görüntülenmesi
• Servis ağacı modellenmesi. UNIX / Linux servis ağacında modellenebilmesi
  Merkezi Syslog sunucusu. Operations Manager 2007 R2’nin UNIX / Linux sunucuları için Syslog sunucusu olarak görev yapıp ilgili Syslog hatalarında uyarı üretebilmesi
• Oracle OleDB Data Source izlenmesi. Oracle sunucularındaki veri tabanlarına OleDB ile bağlantı kurup, bağlantı olup olmadığının, hızının ve sorgu performansının test edilebilmesi.
• Service Level Tracking. Operations Managet 2007 R2 Service Level Tracking (SLT) özelliği ile UNIX / Linux servis ağacının servis seviyesinin Sharepoint ortamında izlenmesi
• Visio Entegrasyonu. Microsoft Office Visio 2007 entegrasyonu ile çizilen diyagramlarda UNIX / Linux sunucular ve üzerindeki bileşenlerin anlık, canlı sağlık durumları ile modellenebilmesi
• Erişilebilirlik ve performans raporları. UNIX / Linux sunucu bileşenlerinin veya bu bileşenlerle oluşturulan servis ağacının erişilebilirlik ve  detaylı performans raporlarının oluşturulabilmesi
• Non-Microsoft uygulamaların izlenmesi. Bridgeways Management Pack’lerinin kullanılarak JBOSS, MySQL, Oracle gibi non-Microsoft çözümlerin de incelenmesi

Ön Koşullar

Linux / UNIX sunucuların izlenebilmesi için bir takım ön koşullar bulunmaktadır.

PORT İHTİYAÇLARI

Linux / UNIX sunucularına ajan kurulabilmesi ve sunucuların yönetilebilmesi için aşağıdaki portların yapılandırılması gerekmektedir:

• Port 1270 (inbound): Operations Manager sunucusunun bağlanıp izleme  ve yönetim görevlerini gerçekleştirmesi için.
• Port 22: SSH üzerinden ajan kurulumu için (eğer ajan kurulumu manual yapılacaksa bu porta gerek yoktur)

DESTEKLENEN PLATFORMLAR

Operations Manager 2007 R2 versiyonu ile Linux / UNIX sunuculara ajan kurulumu gerçekleştirilebilmekte bu sunucular izlenip yönetilebilmektedir.
Ajan kurulumu için Linux / UNIX sunucusunun aşağıdaki platform mimarilerinden biri olması gerekmektedir:

• HP-UX 11iv2 PA-RISC, HP-UX 11iv2 IA64, HP-UX 11iv3 PA-RISC, ve HP-UX 11iv3 IA64
• Sun Solaris 8,  9 (SPARC) ve Solaris 10 (SPARC and x86)
• Red Hat Enterprise Linux 4 (x86/x64) ve 5 (x86/x64) Server
• Novell SUSE Linux Enterprise Server 9 (x86), 10 SP1 (x86/x64)  ve 11 (x86/x64)
• IBM AIX v5.3 ve v6.1 (POWER)

UNIX / LINUX İŞLETİM SİSTEMİ PAKET ÖN KOŞULLARI

IBM AIX 5.3

IBM AIX 6.1

HP-UX 11i v2 IA 64

HP-UX 11i v2 PA-RISC

HP-UX 11i v3 PA-RISC

HP-UX 11i v3 IA64

Red Hat Enterprise Linux ES Release 4

Red Hat Enterprise Linux Server release 5.1 (Tikanga)

Solaris 8 SPARC

Solaris 9 SPARC

Solaris 10 SPARC

Solaris 10 x86

SUSE Linux Enterprise Server 9 (i586)

SUSE Linux Enterprise Server 10 SP1 (i586)

Yazımızın bir sonraki bölümünde Unix/Linux yönetim paketlerinin kurulumu ile devam edeceğiz.

Aşağıdaki tabloda AVIcode .NET yönetim paketi ve SCOM’un out-of-the-box izleme özelliklerinin karşılaştırması bulunmakta:

Yukarıdaki tablodan görülebileceği gibi AVIcode ve SCOM beraber kullanılarak BT, yazılım geliştirme ve destek birimleir arasındaki bilgi akışının ve bilgi boşluğunun azaltılması, aynı zamanda problemlerin fark edilmesi, eskale edilmesi ve düzeltilmesi konularında daha net, hızlı ve doğru adımlar atılması mümkün olabilmekte.

Devam eden yazılarımda AVIcode ile ilgili farklı senaryolar örnekleyeceğim.

Son zamanlarda birçok müşterimizde Operations Manager optimizasyonu yaparken birçok müşterimizden “SQL sunucusunun sürümü “desteklenen konfigürasyonlar” arasında bulunmasına rağmen kurulum sırasında SQL sunucumu bulamıyor” şeklinde feedback’ler alıyoruz. Böyle bir duruma rast geldiyseniz tipik bir SQL WMI provider problemi yaşıyor olabilirsiniz. Aslında SQL sunucunuzda problem olmamasına rağmen, WMI sağlayıcı arayüzü SQL’i keşfedemiyor olabilir.

Kurulum sırasında sihirbaz (birçok sorgulamada olduğu gibi) SQL sunucusunun sürümünü kontrol etmek için WMI kullanır ve SQL sunucunuzun kurulum ön koşullarını sağlayıp sağlamadığını kontrol eder. Hedef sunucuda SQL kurulu olduğuna ve SQL sürümünün Microsoft tarafından desteklendiğine eminseniz SQL Configuration Manager kullanarak SQL sunucunuza bağlanmaya çalışın. Eğer bahsettiğim problemi yaşıyorsanız şu hatayı alırsınız: “Cannot connect to WMI provider. You do not have permission or the server is unreachable. Not that you can only manage SQL Server 2005 and later servers with SQL Server Configuration Manager. Invalid class.”

 Bu sorunun çözümü için öncelikle administrator yetkisinde bir komut satırı çalıştırın ve aşağıdaki komutu yazın:

“mofcomp.exe “C:\Program Files (x86)\Microsoft SQL Server\100\Shared\sqlmgmproviderxpsp2up.mof”

OCS 2007 R2′den sonraki ürünün yeni ismi olan Lync Server 2010 için uçtan uca yönetim paketi Microsoft tarafından yayınlandı. Bu yönetim paketi ile birlikte dağıtık Lync Server mimarinizde synthetic transaction özelliğini kullanabileceksiniz. Aynı zamanda çok başarılı olay ve peformans yönetimi özellikleri mevcut.

Yönetim paketini http://pinpoint.microsoft.com/en-us/applications/lync-server-2010-monitoring-management-pack-12884908254 adresinden indirebilirsiniz.

Microsoft’un sunduğu bulut hizmetlerinden biri olarak adlandırılan Atlanta projesi hayata geçti. Projenin temel hedefleri aşağıdaki gibi özetlenebilir:

• Microsoft’un kurumunuza sunacağı bulut hizmeti ile altyapınızdaki SQL sunucuların konfigürasyonlarının sürekli olarak Microsoft’un önerdiği standartlarda yapılandırıldığından ve çalıştığından emin olabilirsiniz
• Sürekli olarak gerçekleşen proaktif konfigürasyon taraması ile SQL mimarinizin erişilebilirliğini arttırabilirsiniz.
• Açılan çağrılarda çözüm süreleriniz düşecektir, çünkü SQL sunucunuzun konfigürasyon değişikliği takibi Microsof tarafından yapılacaktır

Konu ile ilgil daha detaylı bilgi için http://www.microsoft.com/systemcenter/en/us/atlanta.aspx adresini ziyaret ediniz.

Yayınlanmıştır. Özellikle UNIX/Linux ortamlarını izleyenlerin incelemesini öneririm: http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=4a41a8be-0a37-4bd2-b5b1-026468b317fb

.NET uygulaması performans izleme ve iyileştirme konusunda bilinen en iyi firmalardan biri olan AVICode, Microsoft tarafından satın alındı. AVICode kullanarak:

• Son kullanıcıların uygulamanın performans ve kalitesini nasıl deneyimlediklerini anlayabilirsiniz
• İşiniz ile ilgili kritik işlemleri takip edebilirsiniz
• Servis ağacındaki işletim sistemi ve donanım modellerini uygulama seviyesine taşıyabilirsiniz

Konu ile ilgili detaylı bilgi için : http://blogs.technet.com/b/systemcenter/archive/2010/10/06/microsoft-acquires-avicode.aspx

Bu günlerde sıkça sorulardan biri de “System Center Service Manager (SCSM) çözümünü neden diğer System Center ürünleri ile beraber kullanmalyım?” sorusu oluyor. System Center Operations Manager (SCOM) artık hemen hemen bütün büyük ölçekli kurumların BT altyapılarında o ya da bu şekilde var olan bir çözüm. Kimi kurumlar altyapılarını uçtan uca SCOM ile izlerken kimi kurumlar SCOM’u farklı monitoring araçları ile beraber kullanmayı tercih ediyorlar.

Aynı zamanda birçok kurumda BT destek süreçlerinde basit de olsa incident management, problem management ve en azından kritik seviyedeği değişiklikler için change management süreçleri bulunmakta. Bu süreçleri son kullanıcıya sunmak için ve aynı zamanda arka planda yönetmek için farklı üreticilerin Service Management yazılımları mevcut (Microsoft’un ilgili çözümü System Center Service Manager’dır).

Bu çözümlerin tamamı ITIL tabanlı bir BT hizmet yönetimi (ITSM) mimarisi oluşturmak için çok önemli teknoloji gereksinimleridir. Servis yönetimi tarafında (süreçleri yöneten) kullandığınız ürünün arka plandaki diğer yönetim ürünleri ile entegre olması başarılı bir ITSM ortamı için gereklidir. Bunun neden önemli olduğu ile ilgili birçok sebep sayılabilir, ben bunlardan bir tanesini bu makalem ile birlikte size anlatmak istiyorum: “tüm ürünlerin keşfettiği CI’ların ön tarafta CMDB içerisinde saklanıp, ilişkilendirilip, ifade edilmesinin önemi”.

BT ortamınızda birçok noktada CI’lar bulunur. CI’lar (Configuration Item) altyapınızdaki BT bileşenleridir (bir disk, veri tabanı, sunucu, sunucunun memory’si, printer’lar, kullanıcılar, hatta BT ile ilgili dokümanlar CI’lara örnektir). Örnek olarak, Active Directory, kullanıcı, bilgisayar ve printer’lar gibi objeleri oluşturup kendi veri tabanında saklarken Operations Manager, yönetim paketlerinden gelen Discovery rule’lar (Keşfetme kuralları) ile izlediği BT bileşenlerini kendi veritabanında saklar. Aynı zamanda Configuration Manager da altyapınızdaki BT bileşenlerini oldukça detaylı olarak keşfeder ve yönetir. Problem nerede ortaya çıkar? Siz bu yazılımları ön tarafta bir hizmet yönetimi yazılımı ile entegre etmek istediğinizde, ön taraftaki yazılımın Active Directory, SCOM, SCCM gibi yazılımların keşfettiği objeleri kendi konfigürasyon veritabanına (CMDB) CI’lar olarak eklemesi ve birbiri ile ilişkilendirmesi çok önemlidir. Eğer tüm ortamınız aynı üreticinin ürettiği yönetim yazılımlarından oluşuyorsa işiniz kolaydır. Örneğin, Microsoft ürünlerinden oluşan bir mimari aşağıdaki gibi entegre edilebilir:

System Center Service Manager (SCSM) kullanarak, herhangi ek bir ürün kurmanız gerekmeksizin:

• Active Directory’deki keşfedilen objeleri CMDB’ye CI olarak senkronize edebilirsiniz
• SCOM tarafından yönetilmek üzere keşfedilmiş tüm objeleri CI olarak senkronize edebilirsiniz
• SCCM tarafından yönetilmek üzere keşfedilmiş tüm objeleri CI olarak senkronize edebilirsiniz

Aynı zamanda SCOM tarafından üretilen Alert’leri çift taraflı senkronize edebilir, kullanıcılardan ve operatörlerden gelen yazılım kurulumu, konfigürasyon değişikliği ve konfigürasyon standardizasyonu takibi gibi iş emirlerini SCCM aracılığı ile merkezi olarak yapabilirsiniz.

Alert’lerin Incident’a dönüşme süreci çok önemli bir süreçtir. Alert’i üreten sistem (bu örnekte SCOM) ve ilgili alert’leri incident’a çeviren sistemin (bu örnekte SCSM) olay ile ilgili sadece olayın başlığı ve konusunu alırsa aşağıdaki özelliklerden yoksun kalırsınız:

• BT hizmet yönetimi mimarinizde “Hangi BT bileşenlerin en çok hatayı alıyor?” “İyileştirmem gereken en problemli BT bileşenim hangisidir?” “Hangi kullanıcılardan en fazla şikayet geliyor” gibi raporları alamazsınız.
• SCOM tarafından yönetim paketi içinde hemen hemen her problem için bir “sebep olasılıkları ve çözüm önerisi” bilgisi gelir, hizmet yönetimi tarafında bu bilgiden eksik kalırsınız.
• Incident’ları aynı CI’lar veya aynı uygulamaya / donanıma ait CI’lar bazında gruplayamadığınızdan başarılı bir Problem Yönetimi süreci uygulayamazsınız.

Bu örnekler çoğaltılabilir. Dolayısıyla bizim size önerimiz ya uçtan uca aynı üreticinin yönetim ürünleriniz kullanmanız, veya farklı üreticinin ürünlerini kullanıyorsanız ürünleri Opalis veya benzeri bir entegrasyon ürünü ile entegre etmeniz yönünde olacaktır.

Windows Server 2008 için Active Directory Management Pack’indeki bazı Event Log rule’larının doğru çalışmadığı, sonuç olarak alert üretilmediği ortaya çıktı. Bu hatanın sebebi yönetim paketinin Windows Server 2003′teki eski olay kaynaklarını (event source) kullanması olarak belirlendi. Örneğin, Windows Server 2003′te “PublisherName” değeri yerine Windows Server 2008′de “EventSourceName” değeri okunmalı, ancak bu değer eski halinde sorgulanıyor.

Bu sorun 6.0.7065.0 versiyonlu yönetim paketi için geçerli, bir sonraki sürümde düzeltilmek üzere ürün grubuna feedback verildi.

Windows Security log aslında birçok saldırıyı ve güvenlik ihlalini çok kolayca yakalayabileceğiniz bir kaynaktır.Ancak birçoğumuz security log’u yorumlamayı bilmediğimiz için logdaki değerleri çoğu zaman anlayamayız. Operations Manager 2007 ile birlikte Windows Security log’daki event’ler için alert ürettirebiliyorsunuz (Bunun için ACS’e gerek yok).

Bir alert generating rule yaratıp log olarak security log’u belirtip istediğiniz parametrelere uyan event’ler için alert oluşturabilirsiniz. Elbette burada önemli olan hangi event’in ne anlama geldiğini bilmenizdir. Bunun için iyi bir kaynak http://www.microsoft.com/downloads/details.aspx?FamilyId=95A85136-F08F-4B20-942F-DC9CE56BCD1A&displaylang=en adresindeki “The Security Monitoring and Attack Detection Planning Guide” dokümanıdır. Farklı kaynaklar da mevcuttur.

Bu dokümanda Chapter 4′teki Detect Policy Violations ve Identify External Attacks bölümlerinde aşağıdaki durumlarda nasıl event’ler kaydedildiğini belirtir:

- Dosya yetkilerinin değiştirilmesi takibi
- Şifre resetleme takibi
- Kullanıcı hesabı silme, oluşturma takibi
- Kullanıcıları gruplara ekleme / çıkarma takibi
- Yetki dışıdnaki hesapları kullanma girişimi takibi
- Servis hesabı yetkilerini kullanarak interaktif logon takibi
- Yetki dışındaki uygulamaları çalıştırma takibi
- Yetki dışındaki kaynaklara erişim takibi
- Yetki dışındaki dosyalara zarar verme takibi
- Yetki dışındaki sistemlerden ortama login olma takibi
- Kullanıcıların şifrelerini tahmin etme takibi
- Arkada iz bırakmamak için logu doldurma takibi
- Active Directory güven ilişkisi takibi
- Güvenlik politikasına yetki dışında değişiklik takibi
- Rootkit veya trojan kurulum takibi

Aynı zamanda isterseniz Operations Manager 2007 R2 ACS ile güvenlik loglarını merkezi olarak toplarken, Audit Collector seviyesinde filtrelemeler uygulayarak sadece yukarıda belirttiğim event’lerin toplanmasını sağlayabilirsiniz.

Bunun yanında ACS çözümü geliştirirken noise filtering guide’larından faydalanmayı unutmayın, yoksa OpsMgr Audit DB’niz gereksiz (makine$ kimlik doğrulamaları vb) bilgiler ile dolacaktır.

Not: Security log ile daha birçok şeyi izleyebilirsiniz, Active Directory üzerinde gerçekleştirilen tüm operasyonları, File Server üzerindeki dosya operasyonları gibi. Bu post’ta sadece güvenlik ihlali ile ilgili bölümlerden kısaca bahsettim.

SCCM Reporting Dashboard’ın release edildiğini biliyorsunuz ancak birçoğunuz dashboard’ın SCOM verisini görüntülemek için de kullanılabileceğini bilmeyebilirsiniz. Operations Manager konusunda uzman arkadaşlardan biri http://www.scom2k7.com/how-to-create-a-custom-scom-dashboard-to-show-key-management-group-information/ adresinde bu konuyu detaylı olarak incelemiş, merak edenlere tavsiye ederim. Makaledeki adımları uygulayarak aşağıdaki gibi grafikler elde etmeniz mümkün:

Operations Manager, agentlarda Health Service’i memory’de “healthservice.exe” olarak çalıştırır. Internal olmayan işlemler için (Management Pack’lerden gelen workflow’ları çalıştırmak, performans datası toplamak vb) HealthService.exe MonitoringHost.exe isimli instance’lar oluşturur. MonitoringHost.exe performans datası toplayabilir veya Cscript.exe vasıtası ile agent kurulu bilgisayar üzerinde script çalıştırarak birçok monitoring işlemi gerçekleştirebilir.

Bu script’ler bazı durumlarda çalışamaz ve hata verir ve Operations Manager Console’unda script hataları görmeye başlarsınız.

Management Pack Güncellemeleri veya Yapılandırılması
Öncelikl Operations Manager Management Group’unuza import ettiğiniz Management Pack’lerin son versiyonlarını kurmalı ve beraberinde gelen dokümana göre detaylı olarak yapılandırmalısınz. Bununla birlike arama motorlarından genel bir arama yapıp Mangement Pack ile ilgili olası bug’ları temizlmelisiniz. Yapılandırılmamış, import edildiği şekilde bırakılmış Management Pack’lerdeki birçok script hata verebilir.

Antivirüs
Bu hataların birçoğunu, agent kurulu makinelerde Operations Manager script’lernin bulunduğu klasörü (Örn: “C:\Program Files\System Center Operations Manager 2007\Health Service State\Health Service Store)  antivirüs veya uygulama seviyesi güvenlik sağlayan yazılımınızdan exclude ederek giderebilirsiniz.

Windows Server 2003 WMI Güncellemesi
Bununla birlikte http://support.microsoft.com/kb/933061 maklesinde bulunan güncellemeyi x86 veya x64 Windows Server 2003 SP1 veya Sp2′lerinize yüklerseniz Windows Server 2003 üzerinde WMI’ın çalışması ile ilgili birçok hatayı giderecektir.

WMI Buffer’ının Arttırılması
WMI servisinin belirli bir buffer boyutu vardır.Çalıştırılan WMI Script’leri bu buffer’ı doldurursa WMI, servisine “sleep delay” inject ederek yeni objeleri kabul etmemeye başlayabilir. Operations Manger ajanı kurulacak bilgisayarlarda bu buffer’ın registry’den arttırılması önerilir:
“HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WBEM\CIMOM\Low Threshold On Events (B)” değerini 35000000 yapın (default olarak 10000000)
”HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WBEM\CIMOM\High Threshold On Events (B)” değerini 70000000 yapın (default olarak 20000000)

Windows Scripting Host (CScript) versiyonunun yükseltilmesi
http://support.microsoft.com/kb/955360 adresindeki güncellemeyi yükleyerek CScript’in versiyonunu 5.7′ye yükseltin. Bu güncelleme script’lerin çalışırken çok fazla CPU harcaması, script timeout ve eşzamanlı çalışan scriptlerin sebep olduğu hataları gidermektedir. Windows Server 2003 SP1 ve SP2′ye (x86, x64) uygulanır. DNS, DHCP ve Domain Controller’lar için çok faydalı bir hotfix’tir. Aynı zamanda doğası gereği fazla işlemci gücü kullanan VBScript’lerin kaynak kullanımını da azaltır.

Operations Manager 2007 R2 ile bildiğiniz gibi artık UNIX/Linux platformlarını (Crossplatform) da dinleyebiliyorsunuz.

Crossplatform ajan kurulumlarında problem yaşadığınız zaman eğer iyi bir UNIX/Linux admin değilseniz çoğu zaman kısa bir hata mesajı ile bilgilendirilirsiniz ve olayın detayına inemeyebilirsiniz.

Crossplatform ajan kurulumlarında detaylı loglama ve bilgilenme için birden fazla yöntem bulunmakta.

Operations Manager Modül Loglamasının aktif hale getirlmesi

Bu log tipinin aktif hale getirilmesi genelde keşif (discovery) ile ilgili hataların giderilmesinde faydalıdır. Loglar ajanın UNIX/Linux sunucuya gönderimi, kurulumu ve sertifika imzalama ile ilgili detayları kaydeder. Discovery wizard ile ilgili yaşadığınız bir problemi gidermek istiyorsanız bu logların aktif hale getirilmesi faydalı olacaktır.

Aktif hale getirmek için C:\Windows\Temp klasörü altında EnableOpsMgrModuleLogging isminde bir dosya oluşturun (uzantısı yok, içinde birşey yazmayacak, sadece dosya ismi olacak). Bunun için isterseniz COPY /Y NUL %windir%\TEMP\EnableOpsMgrModuleLogging komutunu da kullanabilirsiniz.

Bu dosyanın oluşturulmasından sonra Operations Manager SSH ve sertifika akivitelerini \Temp klasörüne loglamaya başlaycaktır. SSH modülleri ile ilgili scriptler .log dosyasına loglayacaklardır. Diğer modüllerin kendi logları oluşacaktır.

Debugview kullanılması

http://go.microsoft.com/fwlink/?Linkid=129486 adresinden Debugview’i indiin ve ajan kurulumunu başlattığınız Management Server üzerine çalıştırın ve discovery wizard’ı başlatın. Debugview uygulaması detaylı loglar ekranında göstermeye başlayacaktır.

UNIX/Linux ajanının detaylı loglamsını aktif hale getirmek

Bu loglar UNIX/Linux ajan aksiyonlarını kaydeder. Operations Manager’a döndürülen veri ile ilgili bir problem yaşıyorsanız bu logu aktif hale getirebilirsiniz (bu log çok nadiren kullanılır).

Logu aktif hale getirmek için UNIX/Linux sunucsuna oturum açın. scxadmin -log-set all verbose komutunu çalıştırın. Loglar /var/opt/microsoft/scx/log klasöründe oluşturulacaktı.

Operations Manager detaylı izleme
Bu metot Operations Manager’ın ajandan veri toplarken kullandığı Windows Remote Management (WinRM) sorgularını görmenizi sağlar. WinRM bağlantısı ile ilgili bir problem olduğundan şüpheleniyorsanız bu log sorun giderme il ilgili detaylı bilgi sağlayacaktır.

WinRM olaylarını takip etmek için:
1. UNIX/Linux ajanını izleyen Management Server’da komut satırı (cmd) çalıştırın.
2. Aşağıdaki komutları komut satırında çalıştırın:
a.cd C:\Program Files\System Center Operations Manager 2007\tools
b.StopTracing.cmd
c.StartTracing.cmd VER
3.Aldığınız hataya sebep olan davranışı tekrarlayın (arkada detaylı olarak loglanacak)
4.Aşağıdaki komutları komut satırında çalıştırın:
a.StopTracing.cmd
b.FormatTracing.cmd
5.TracingGuidsNative.log dosyasında WSMAN ile ilgli girdileri inceleyin

Unix/Linux ortamına kurulan ajanlar genelde sorunsuz keşfediliyor ve kuruluyor. Ancak bazı durumlarda ufak tefek sorunları gidermeniz gerekiyor. Bu sorunlar çoğu zaman internette search ettiğinizde karşınıza cevapları çıkan cinsten problemler oluyor (Not Enough Entropy hatsı gibi…) Bu hatalar dışında çok spesifik hatalar yaşadığınızda yukarıdaki loglar hayat kurtarabiliyor.

Bu hafta DELL Operations Manager 2007 Management Pack’ini yeniledi.

Gerçekten ciddi yenilikler içeren bu Management Pack’i http://support.us.dell.com/support/downloads/format.aspx?releaseid=R237719 adresinden indirebilirsiniz.

Feature highlights of this Dell Server Management Pack Suite v4.0 (A00) :
- Improvements in scalability and performance over the previous releases by including:
        * Server Scalable MP (for managing large enterprise environments)�
        * Server Detailed MP (addon MP that provides detailed instance level monitoring)
- Performance and Power monitoring and OpenManage 6.1 support for Dell Server MPs
- DRAC and CMC MPs to monitor Dell Remote Access Controllers and Chassis Management Controllers
- Override utility to enable Informational alerts for managed Dell Servers

Operations Manager 2007 R2 ile Oracle sunucularınız üzerinde bulunan veri tabanlarına OLEDB ile bağlantı kurulup kurulamadığını, bağlantının belirli zamanda kurulabildiğini veya belirli sorguların çalıştırılabildiğini test etmeniz için Ole DB Data Source template’lerini kullanabilirsiniz.
Template’i oluşturmak için “Authoring / Ole DB Data Source” kısmında yeni bir bağlantı oluşturmalısınız:

Yeni OleDB Source oluşturmak istediğinizde provider’lar arasında Oracle OleDB Provider olmadığını göreceksiniz. Oracle provider’ı gelmesi için Oracle Client yüklemeniz gerekiyor (Oracle client’ı Oracle’ın web sitesinden indirebilirsiniz). Ancak tüm client’ı yüklemenize gerek yok, sadece Windows Intefrace’ler arasından OleDB Provider yüklemeniz yeterli olacaktır.

Provider’ı yükledikten sonra Oracle OleDB provider drop-down list’te gelecektir:

Devamında server ve database’ı belirtmeniz gerekiyor. Eğer yalnızca bağlantıyı test edecekseniz herhangi bir sorgu yazmanız gerekmez. Eğer belirli bir sorgu çalıştırmasını ve bu sorgunun ne kadar zamanda geleceğini de  test etmek istiyorsanız sorguyu da belirtmelisiniz.

Connection string içinde Oracle database’e bağlanırken kullanılacak kullanıcı adı ve parolayı da belirtmelisiniz. Best Practice olarak buraya cleartext olarak kullanıcı adı / şifre yazmanız önerilmez. Bunun için bir basic Runas Account oluşturup “Oracle OleDB Check OLE DB Simple Authentication Profile” Runas Profile’ına atamanız ve “Use Simple Authentication Runas Profile…” seçeneğini işaretlemeniz önerilir.

Birçoğumuz OpsMgr sunucularımızı farklı sebeplerden dolayı zaman zaman kapatmak, reboot etmek zorunda kalabiliyoruz. Bununla birlikte donanım veya yazılım arızaları sonucunda sunucu rollerinden bir veya daha fazlası işlevsiz duruma gelebiliyor. Bu yazımda sizlere OpsMgr 2007 sunucu rollerinde olası bir kesintinin etkilerinden bahsedeceğim.

Root Management Server (RMS)

Bildiğiniz gibi her OpsMgr 2007 Management Group’ta sadece bir adet RMS bulunuyor. Bu sebepten dolayı “ikinci bir RMS kurup riski dağıtayım” gibi bir yaklaşım ne yazık ki mümkün olmuyor. RMS’i kesintilerden korumanın en doğru yolu ise clustered bir ortama kurmak.

RMS sunucunuz işleviz hale geldiğinde:

• Ortamdaki konsollar (ve web konsol) çalışmaz, çünkü ortamdaki management server’lar arasında sadece RMS veri tabanından veri okuyabilir.
• Management group’un konfigürasyonunu değiştirmeniz için gereken servisler sadece RMS üzerinde çalıştığı için management group’un konfigürasyonunu değiştiremezsiniz.
• Ortamınızda birden fazla management group varsa, diğer management grouplar ile bağlantınız kesilir.
• Operations Manager ortamınızı yönetmek ile ilgili herhangi bir görev gerçekleştiremezsiniz.
• Connector’leriniz çalışmaz.

Eğer ortamınızdaki agent’lar RMS sunucunuza bağlıysa (farklı bir management server’a bağlı değilse) o zaman aynı zamanda bir sonraki başlıkta belirteceğim Management Server etkilerini de hissedeceksiniz demektir.

Management Server (MS)

Yüksek performans gerektiren ve çok sayıda bilgisayar ve cihazın izlendiği ortamlarda OpsMgr agnet’larının RMS’e bağlanması önerilmez, farklı bir Management Server(MS) kullanılması önerilir. RMS’in aksine, ortamda birden fazla MS bulunabilir ve bir MS işlevsiz hale geldiğinde üzerindeki agent’ların farklı bir MS’e otomatik olarak devredilmesini sağlayabilirsiniz. Dolayısıyla MS’ların yüksek erişilebilirliği, ortama birden fazla MS kurularak sağlanabilir.

MS sunucunuz işlevsiz hale geldiğinde:

• Veriler agent kurulu bilgisayarlarda birikirler ve MS işlevsiz olduğu sürece veri tabanına yazılamazlar.
• Agentless bilgisayarlar yönetilemez.
• Gateway sunucular agent’lardan MS’a veri gönderemez.

OperationsManager Veritabanı

OperationsManager veritabanı failover cluster’a kurularak veya SQL Log Shipping yöntemi ile yüksek erişilebilir hale getirilebilir. Failover cluster yöntemi ile yüksek erişilebilirliği sağlanmış bir OperationsManager veritabanının node’larından biri çalıştığı sürece erişilebilirlik problemi olmayacaktır. Eğer veritabanını korumak için Log shipping kullanıyorsanız veritabanı hedef sunucuda veritabanını oluşturana kadar servis performansı düşebilir, veritabanını oluşturmanız belirli bir sürenin üzerine çıkarsa (Management Server cache’i dolarsa) veri kaybı olabilir.

OperationsManager veritabanı işlevsiz hale geldiğinde:

• Management Server’lar agent’lardan gelen verileri cache’lerinde tutmaya başlarlar. Management Server üzerinde Powershell’den “Get-ManagementServer” komutunu çalıştırırsanız Management Server’ınızın ne kadar veri cache’leyebileceğini görürsünüz (defaule 100MB). Bu değeri yine powershell ile arttırabilirsiniz.
• Datawarehouse’unuzun ve Reporting sunucularınızın sorunsuz çalıştığını düşünürsek, raporlara ulaşabilirsiniz, ancak güncel verileri göremezsiniz.
• Yönetimsel herhangi bir görev gerçekleştiremezsiniz (obje oluşturma, yetkilendirme vb)
• Konsollar çalışmaz

Audit Collection (ACS) Database

ACS veritabanınız işlevsiz hale geldiğinde:

• Güvenlik olayları agent yüklü bilgisayarlarda birikir ve bir süre sonra performans sıkıntısı yaratmaya başlar.
• Datawarehouse’unuzun ve Reporting sunucularınızın sorunsuz çalıştığını düşünürsek, ACS raporlarına ulaşabilirsiniz, ancak güncel verileri göremezsiniz.

UNIX/Linux sunuculara Operations Manager 2007 R2 Cross Platform agent’ları kurarken bazı hatalarla karşılaşabiliyorsunuz. Bu hataların birçoğu openssl gibi ön koşulların sağlanmaması ile ilgili oluyor. Sıklıkla karşılaşılan hatalardan bir diğeri entropy ismi verilen sertifika üretilirken kullanılan random data havuzunun yeterli olmamasından dolayı gerçekleşiyor. OpsMgr’ın 256K entrophy’e ihtiyacı var. Entrophy değerini arttırmak için “dd if=/dev/urandom of=~/.rnd bs=1 count=1024″ komutunu çalıştırabilirsiniz. Çıkan diğer hatalar genelde sertifika imzalama veya SSH portu gibi çeşitli noktalardan olabiliyor.

Anlaşılabileceği gibi UNIX/Linux dünyasının kendine özel hataları ve sorun giderme yöntemleri var. Bununla birlikte varsayılan ayarlarla OpsMgr bir UNIX/Linux sunucusuna agent kurarken ufak birkaç bilgi dışında loglama yapmaz.

Hata Loglama

UNIX/Linux agent kurulumları sırasında loglamayı aktif hale getirmek için birçok dokümanda yazılmayan bir yöntem var: “%windir%/temp” klasöründe “EnableOpsMgrModuleLogging” isimli bir dosya oluşturun. Dosyanın herhangi bir uzantısı olmasın. UNIX/Linux agent kurulurken OpsMgr bu dosyanın varlığını algılayacak ve aynı klasörde kurulumun her adımı ile ilgili ayrı ayrı dosyalar oluşturarak detaylı loglama gerçekleştirecektir.

Operations Manager 2007 R2 yarın (22 Mayıs 2009)’da RTM oluyor.

Bildiğiniz gibi Microsof Engyro connector’lerini satın aldı ve interop solutions ismi altında R2′de ücretsiz sunuyor. Connector’lerin RTM olması ise 1-1,5 ay kadar sonra gerçekleşecek.

System Center Operations Manager ürün grubundan Rob Kuehfus’un geliştirdiği notifikasyon test aracı OpsMgr’deki notifikasyon kanalları ve subscription’larını test etmek için kullanabileceğiniz güzel bir araç. Bu aracı kullanarak email (SMTP), Instant Message (IM) veya SMS kanallarını test edebilirsiniz. Bu araçla aynı zaman OpsMgr’de subscription’ları test etmek için test alertleri oluşturabilirsiniz.

Bu araç OpsMgr’nin tüm versiyonlarında çalışmaktadır.

Bu aracı kullandığınız işletim sisteminde UAC açıksa “Run as administrator” ile çalıştırmayı unutmayın

Notifikasyon Test Aracı

System Center Operations Manager ortamında önemli ihtiyaçlardan biri de e-mail ve benzeri uyarıların tetiklenip tetiklenmediğini ve uyarının kime gittiğini öğrenmektir. Bu özellik OM 2007 SP1′de yok, ne yazık ki OM 2007 R2 ile beraber de bu önemli özellik gelmiyor.

Aşağıdaki linkteki aracı kullanarak, komut uyarı kanalı (command notification channel) ve komut satırından çalışan bir uygulama ile belirli kriterlere uyan herhangi bir uyarının (alert) geçmişini görebilirsiniz.

Tek yapmanız gereken ilgili command notification’un subscription’un bir parçası olduğuna emin olmak ve notification run as account ve profile’ını yapılandırmak.

Aşağıdaki linkten kurulum ve dokümantasyon indirilebilir:

UpdateNotificationHistory.zip

http://edge.technet.com/Media/Visio-Integration-with-Operations-Manager-R2/

http://www.microsoft.com/downloads/details.aspx?FamilyID=dc17e093-bdd7-4cb3-9981-853776ed90be&displaylang=en

The Visio Add-in for System Center Operations Manager 2007 R2 combines the strengths of two applications widely used in enterprise IT to simplify the creation of customized graphical dashboards showing the health of an environment. Examples of such diagrams include showing objects by geography overlaid on a map, by location in a datacenter or building, by role in a logical view of an application or by topology for complex distributed applications such as Exchange or Active Directory.
Features include:

• Visio diagrams exported from System Center Operations Manager 2007 R2 (release candidate) show automatically live health state on the exported objects in Visio.
• Easily create new Visio diagrams and link shapes to any managed object (computer, database, web site, perspective etc.) to show the current health state
• Automatically link entire existing Visio diagrams to the computer and network devices managed by Operations Manager by matching computer names or IP addresses
• Auto-refresh of health state in Visio diagram - use with Visio’s full screen view to create dashboard views suitable for use as a summary display in a datacenter control room
• Predefined data graphics to allow user to toggle from Operations Manager health icons to shape color for health state

More info is available at http://blogs.technet.com/momteam/archive/2009/04/24/visio-add-in-for-operations-manager-2007-r2-beta-released.aspx

Operations Manager 2007′de en önemli olaylardan biri alert optimizasyonudur.

Bu konuda çok şey yazılabilir. Ancak bu yazımda sizlere izlemeniz gereken alert management sürecinden ufak bir kısım aktarmak istiyorum.

Geliştirdiğimiz OpsMgr çözümlerinde genelde izlenmesini tavsiye ettiğimiz Critical Alert Management süreci aşağıdaki gibidir:

A: Alert belirli bir event log’dan dolayı üretiliyordur. Ancak alert’in üretildiği event log datası sizin için birşey ifade etmiyor olabilir. Bu durumda ilgili alert’i disable edebilirsiniz veya kurumunuzun ihtiyacına göre özelleştirebilirsiniz.
B: Alert üretilmesi için belirli bir eşik değeri vardır. Bu eşik değerleri belirlenirken ya Microsoft, müşterilerinin geneli için bir “best practice” değer düşünmüştür veya ortamınızı bir süre dinleyip otomatik olarak size uygun eşik değeri oluşturabilen baseline monitor tipini uygun görmüştür. Bu tip alert’lere bir örnek hemen hemen tüm müşterilerde optimize etmemiz gereken DNS Management Pack’indeki “DNS Resolution Time Alert” değeridir. Bu değer Microsoft tarafından 1sn olarak belirlense de birçok DNS sunucusunda 2-2,5 saniye civarındadır. Bununla birlikte eşik değerlerini değiştirirken kafanıza göre değil, yine OpsMgr’den çıkan raporlara göre yapmalısınız. Örneğin, DNS Resolution Time Alert değerinin sizin için ortalama ne olduğunu incelemeniz için “Microsoft Windows DNS Server -> Microsoft Windows DNS 2003 -> Performance -> Local Resolution Time” performans counter’ından faydalanmak akıllıca olacaktır. İlgili performans view’ler, raporlar ile size uygun değeri bulup, monitor / rule’u optimize etmelisiniz.
C: Çok sık rastladığımız bir dğer optimize edilmesi gereken alert tipi ise kapasite ile ilgili alert’lerdir. Bu alertlerin de durumu B tipi alertlerle benzerdir. Örneğin, Windows Server (BaseOS) Management Pack’inde disk kapasitesi %10′un altına düştüğünde warning üretir. Örneğin, 8TB’lık bir diskin %10 boş alanı olması her durumda warning olmayabilir. Veya bazı ortamlar için processor interrupt değeri %10 değil %15 olarak set edilebilir.
D: En sık rastlanan optimizasyon gereksinimlerinden biri ise gelen alert’in kritiklik değeridir. Birçok kurum için birçok alert kritik olarak açılabilir, ancak warning veya information olabilir. Örneğin SQL autoshrink / autoclose flag’lar sizin için critical değil warning olabilir. Bu durumda alert’lerin seviyelerini override ederek değiştirmelisiniz.

Operations Manager 2007 projeleri tamamlandıktan sonra, üretilen kritik hataların gerçekten sizin için kritik bir hata anlamını taşıyacak şekilde optimize edilmesi orta/orta-büyük ölçekli bir servis ağacı modelinde 1-6 ay arası sürecektir. Bu süreci kısaltmanın en doğru yolu alert optimizasyon yöntemini doğru belirlemektir. Eğer doğru danışmanlık firması ile çalışırsanız OpsMgr projenizin biryerlerinde Alert optimizasyonu yöntemleri için doğru tecrübeyi de kurumunuza aktaracaktır.

Ortam optimize hale geldikten bir sonraki adımınız ise Operations Manager 2007 Service Level Tracking olarak bilinen servis seviyeleerini dashboard ortamından (Sharepoint) izlemek olacaktır. Bu konuda yakın zamanda bir makale yazacağım.

Microsoft ürünlerinin yerelleştirilmesi konusunda Sitebuilders community grubunda devam eden “Microsoft ürünlerini Türkçe’leştirmeli mi?” başlıklı bir tartışma hakkında yorumlarımı blog’umdan da paylaşmak istedim.

Türkçe olması bence de doğru.

Fransa, Japonya gibi ülkeler yerel dilleri olmadan birçok ürünü ülkeye dahi sokmuyorlar.

Bunun yanında, Microsoft’un ürün yaşam döngüsü artık çok hızlandı. Kurumlar daha bir çözümü yaygınlaştırmadan yeni versiyon hatta 2 yeni versiyon atlıyor.

Bu hızlı güncellemelerin avantajları çok. Özellikle rakip ürünlerin her geçen ay yeni özellikleri yaygınlaştırdıkları günümüz koşullarında lokmaları bölerek hazmetmek (Major versiyon + R2 versiyon gibi) oldukça büyük esneklik ve rekabet gücü sağlıyor.

Bununla beraber ürünlerin son versiyonlarının sağladığı performans, stabilite, özellik ve prestijden doğan katmadeğeri yakalamayı hedefleyen firmaların da güçlü bir “Service Transition” süreçlerine ihtiyacı var. Çünkü BT ortamlarında en riskli aksiyon değişiklik yönetimidir.

Bu güncellemelerin bir dez avantajı da test ve yerelleştirme problemleri. Microsoft şu anda bir projenin ortalama %40 ‘lık zamanını test sürecinde harcıyor. Devam eden yüzlerce proje ile birlikte yerelleştirme için ciddi kaynak ayırmak gerekiyor.

Bu sebepten dolayı tüm ürünlerin yerelleştirmeleri senkronize gidemeyebiliyor, hatta bazı ürünler için hiç yerelleştirme olmayabiliyor.

Görüşüm Türkçe’ye tam destek. Ancak bir gerçeği unutmamak lazım: günümüzde BT’nin dili İngilizce’dir. İngilizce’den kaçmak bilişimde mümkün değil. Çünkü ürünü Türkçe kursanız dokümanalar İngilizce. Dokümanları Türkçe’leştirseniz dünyadaki bilginin çoğu ingilizce.

Operations Manager 2007 veritabanı bileşenlerini oluştururken DBCreateWizard.exe aracını mı kullanmalı yoksa SetupOM.exe ile standart kurulum sırasında veritabanını da mı oluşturmalı sorusunun cevabı çoğu zaman net değildir.

MOM 2005 zamanında ortamda Active/Active cluster’lar olduğunda veya SQL DBA’leri MSI tabanlı setup dosyasını SQL sunucularda çalıştırmak istemedikleri zaman Onepoint veritabanını oluşturmak için DBCreate sihirbazını kullanırdık. DB Create sihirbazı SQL Server üzerine binary dosyalar kopyalamadığı için genelde yüksek güvenlik ve hassasiyet istiyen ortamlar için tercih edilirdi. Ancak bu metodu bilen veya uygulayan oldukça azdı.

Operations Manager 2007′de ise DBCreate Wizard’ının kullanılması gerektiği senaryolar çok net belirli değildi. Microsoft’tan Kevin Hollman’ın kendi blog’unda oluşturduğu bir makale ile bu konu açıklık kazandı.

DB Create sihirbazı OpsMgr CD’sinde \SupportTools klasöründe bulunmaktadır. Çalışmak için herhani ek bir dosyaya ihtiyacı yok, aynı zamanda “kuruluma” da ihtiyacı yok. Sadece SQL DB sunucusuna kopyalıyorsunuz ve sihirbazı çalıştırıyorsunuz. Detaylar için : http://support.microsoft.com/kb/938997/en-us

“Operations Manager Deployment Guide” dokümanında veritabanını Active/Passive cluster’da oluştururken DBCreateWizard kullanılmasını öneriyorlar (Bu bir zorunluluk değil, sadece öneri. Active Node’da SetupOM.exe çalıştırarak da yapabilirsiniz). Temel olarak, Microsoft’un önerisi OpsDB rolü için dedike bir SQL sunucunuz var ise (sunucunun üzerinde başka herhangi bir OpsMgr rolü olmayacaksa) Operational Database’i oluşturmak için DBCreateWizard kullanmalısınız. Bunun sebebi, SetupOM.exe’nin veritabanı sunucusunda bazı ek registry değerleri oluşturması ve OpsMgr perspektifinden sunucuya güncellemelerin uygulanma yönetminin değişmesidir. Bu aracı kullanmanın bir diğer gerekliliği de, SQL DBA ekibiniz SQL server/cluster’larda MSI tabanlı bir kurulumu çalıştırmanıza izin vermemeleri olabilir.

Aşağıda DBCreateWizard aracının kullanılması ile ilgili bazı senaryolara değineceğim:

1. Aynı sunucuda paylaşılan roller:Bu senaryoda tek bir sunucuda SQL Server 2005 üzerinde Operational Database rolü ve RMS rolü bulunur. Bu durumda SetupOM.exe’yi çalıştırıp, Management Group oluştururken veritabanını da oluşturmanız önerilir. İsterseniz DBCreateWizard’da kullanabilirsiniz, ancak bu senaryoda herhangi bir katmadeğeri yoktur ve kuruluma gereksiz bir adım eklersiniz.
2. Ayrı Roller:Dedike SQL sunucusu (ServerA) ve dedike RMS (ServerB). Bu senaryoda veritabanını oluşturmak için SetupOM.exe yerine DBCreateWizard kullanılması önerilir. Bununla beraber her ikisinin de kullanımı teknik olarak desteklenir.
3. Ayrı Roller - clustered DB:SQL için dedike bir cluster (A/P veya A/A veya multi-instance veya multi-node olabilir, fark etmez) Bu senaryoda SetupOM.exe yerine DBCreateWizard kullanımı önerilir. Microsoft bu senaryoda DBCreateWizard kullanmanızı öneriyor bununla beraber bu bir zorunluluk değil, veritabanını yaratacağınız SQL instance’ının sahibi olan herhangi bir Node’da SetupOM ile Operational DB’yi yaratabilirsiniz.
4. Yüksek güvenlik ihtiyacı olan veritabanı ortamları:Genelde banka ve benzeri kritik ve konsolide veri tabanı sistemlerinin bulunduğu ortamlarda veritabanı yöneticileri uygulamanız için boş bir veritabanı oluşturur ve sadece veritabanı için gerektiği kadar yetki oluşturur. Bir veri tabanı oluşturmak için setup çalıştırmak istemez. Hele SQL sunucuları üzerinde bazı araçlar kullanarak veritabanı oluşturmanıza hiç izin vermezler. Eğer veritabanı uygulamanın kendisinin kurulumu ile beraber oluşturuluyorsa veritabanı oluşturulmasının uzaktan gerçekleşmesini kesinlikle tercih ederler. Ne yazık ki MOM 2005 ve OpsMgr 2007 bu tip ortamlardaki veritabanı yöneticilerinin istedikleri kurulum tiplerini desteklemez. OpsMgr veritabanı bileşenini oluşturmak için veritabanı sunucusunda/node’unda ilgili aracı çalıştırmak zorunda. Bununla beraber test ortamında DBCreateWizard ile veritabanı oluşturulup detach edilebilir ve SQL ekibine teslim edilerek production ortamına taşınabilir. Ancak bu yöntem ile ilgili Microsoft detaylı testler gerçekleştirmiş durumda değil. Bununla beraber SQL ortamlarını sıkı kurallarla yöneten bir DBA ekibi için DBCreateWizard yine de en uygun yöntem olarak karşımıza çıkıyor. Bununla beraber RMS setup’ı çalıştırmak için SA yetkisine ihtiyaç bulunmaktadır. Kurulum tamamlandıktan sonra yüksek yetkiler geri alınabilir.
5. Aynı SQL instance’ında birden fazla Operational Database:Eğer birden fazla Management Group’unuz varsa bu senaryo mümkündür. Bununla beraber birden fazla Operational DB demek orta ve büyük ortamlar için gerçekten yüksek I/O anlamına gelebilir, dolayısıyla production ortamlarda (eğer ortam çok küçük değilse) önerilmez. Management Group’ların biri için Operational DB’yi kurduktan sonra ikinci Management Group için Operational DB kurmak istediğinizde size var olan DB’yi onarmak veya tamir etmek opsiyonlarını sunacaktır. Bu durumda DBCreateWizard ile ikinci veritabanını oluşturabilirsiniz.

Ortamınızdaki clustered çözümleri monitor etmek için Operations Manager 2007 ile kullandığınız Cluster Management Pack’in stabilitesini arttıran ufak ama önemli bir güncelleme yayınlandı.

Bu güncelleme ile birlikte:

• Clustered resource’ların durumunu sorgulayan workflow’larda iyileştirme gerçekleşti
• İlgili workflow’ların çalışma aralığı ile ilgili optimizasyon ve nasıl override edileceği ile ilgili doküman güncellemesi gerçekleşti
• Dokümantasyona her cluster başına clustered resource’ların (200) ve resource group’ların (100) izlenmesi ile ilgili bilgi eklendi.
• Bunların dışında birçok önemli dokümantasyon güncellenmesi gerçekleşti

http://www.microsoft.com/downloads/details.aspx?FamilyId=AC7F42F5-33E9-453D-A923-171C8E1E8E55&displaylang=en&displaylang=en

ITIL süreçleri aslında bilişim ile ilgili geliştirilmiş tecrübeler ve alınan dersler bütünü olmasına rağmen aslında standardizasyon ve kontrollü iyileştirme ihtiyacı olan tüm deneyimlerde kullanılabilir.

Apollo 13 felaketini bir çoğunuz biliyorsunuzdur. Ay yüzeyine inip incelemeler yapmak üzere uzaya gönderilen Apollo 13′te ortaya çıkan sorunlardan sonra görev ay yüzeyini incelemekten üç astronotun hayatını kurtarmaya dönüşmüştü. Peşi sıra olan onlarca olayı ve problemi NASA operasyon ekibi, ITIL benzeri bir süreç kullanarak başarı şekilde yönettiler ve üç astronotun hayatını kurtardılar. (ITIL Foundation eğitimlerinden sonra verdiğimiz Apollo simülasyon oyununun da amacı zaten teorik ITIL süreçlerini deneyimlemek ve hayata geçirmek)

Bir çoğunuzun “ITIL bilişim dışında nasıl kullanır?” diye sorduğunu duyabiliyorum.

Bu makalemde sizlere ITIL’ı özel hayatınızı yoluna sokmak ve düzeltmek için nasıl kullanabileceğinizi anlatacağım!!!

Incident Management (Olay Yönetimi): ITIL’daki operasyonel süreçlerin en önemlilerinden biridir. Bu sürecin temel hedefi gelen olayları en hızlı şekilde çözmek ve memnuniyet sağlamaktır. Olayların kök sebepleri ile ilgilenmez. Olay geldiğinde sadece karşısındakini memnun etmeye ve olayı çözmeye hedeflenir. Hiçbir zaman olay kaydı açan ve olayı size yansıtan kişinin üzerine gidilmez, tek hedef olaydır, olay çözümlenmeli ve servis seviyesi sağlanmalıdır. İlişkinizde anlık bir problem yaşadığınızda yapmanız gereken de aynen budur. Olayı kişiselleştirmeden, karşınızdaki insana memnun olacağı cevapları olabildiğince vermek. Tansiyonu biran önce düşürmek. Belki çoğu zaman alttan alan olmak. Ama sonuçta olayın etkisi büyümeden tansiyonu düşürmek.

Problem Management (Problem Yönetimi): ITIL’daki problem yönetimi süreci tekrar eden olayların kök sebebini bulmayı hedefler. Kök sebep bulunmalıdır ki sürekli olarak aynı olaylar yaşanmasın. Olaylar için kalıcı çözümler burada üretilir. Bazen de proaktif olarak olaylar olmadan önce öngürülebilir. Özel hayatınızda tekrar eden ve sürekli olay yönetimi ile çözdüğünüz olaylar sıklaşmaya başladığında Problem Yönetimi’ne geçmelisiniz! Tekrar eden problemlerin kök sebebini bulmak için doğru adımları atmalı, sık sık canınızı sıkmaya başlayan olayları sona erdirmelisiniz. Hatayı çoğu zaman kendi sunduklarınızda arayıp sunduklarınızdan karşınızdaki kişinin (ITIL’da müşterinizin) algıladığını, nasıl faydalandığını iyi anlamalısınız.

İş ihtiyaçları, strateji ve tasarım. ITIL’da birçok sürecin başlangıcı iş ihtiyacıdır. İşin ihtiyacı olmayan çözümler, değişiklikler, tasarımlar gerçekleştirilmez. Özel hayatınızda da başlangıç noktanız karşılıklı beklentileri doğru belirlemek olmalıdır. Aslında beklentileri karşılayamayacağınızı ancak elinizden geleni yapacağınızı düşünüyorsanız yanılıyorsunuz. Beklentileri karşılamak üzerine kurulmayan bir ilişki mutlaka bir yerlerde problem yaşayacaktır! Tıpkı iş ihtiyacından yola çıkılmadan  tasarlanan servisler ve stratejinin bir süre sonra işinizi engelleyen temel faktörün ta kendisi olduğu gibi.

Konfigürasyon yönetimi / Değişiklik Yönetimi: ITIL’da konfigürasyon yönetiminin en önemli sebeplerinden biri değişiklikleri doğru yönetmek ve destek süreçlerini daha verimli hale getirmektir. Konfigürasyon yönetimi süreci tüm süreçlerde bulunan bilginin merkezi olarak depolandığı, ham verinin bilgiye dönüştürüldüğü kaynaktır. Sahip olduğunuz değerlerin envanteri de burada tutulur. ITIL’da, altyapıdaki herhangi bir bileşen değiştirileceği zaman mutlaka bir onay mekanizmasından geçmelidir. Ufak ve standart olan değişiklikler onay mekanizmasından geçmiştir ve direk olarak uygulanabilir. Değişikliğin etkisi ne kadar büyükse o kadar dikkatli değerlendirmek gerekmektedir. Özel hayatınızda da durum aynen budur. Öncelikle varlıklarınız açık bir şekilde listelenir. Bu varlıklar üzerinde gerçekleştirilecek ufak değişiklikler (satın alacağınız yeni bir elbise, arabanızı yıkatmanız) için hesap vermezsiniz. Ancak hayatınızdaki bileşenler ile ilgili gerçekleştireceğiniz değişiklikler mutlaka onaydan geçmelidir! Bu herhangi bir değişiklik olabilir. Upuzun saçlarınızı kısacık kestirirken bir değişiklik yönetimi sürecine tabi olmalısınız. Arabanızı değiştirmek istiyorsanız bu iş dönüşünde tek başınıza yapabileceğiniz birşey değildir. Bazı değişiklikler için CAB (Change Advisory Board) toplanır, akıl danışılır. Elinizde son kalan birikiminizi kriz ortamında yatırıma dönüştürecekseniz güvendiğiniz büyükleriniz ile bir araya gelip fikir birliği yaparsınız. Ve önemli olan ancak acil olması gereken değişiklikler vardır. Bu değişiklikler için her zaman fikrine güvendiğiniz, bir cep telefonu ile size akıl verecek birileri her zaman vardır. Eğer değişiklikleri ilişkiyi yaşayan taraflar birbirlerinden onay almadan yapmaya başlarlarsa bu ileride çıkacak büyük sorunların işaretçisidir. Değişiklik yönetimi sıkıcıdır. Kafanıza göre değişiklik yapmak varken birilerine danışmak her zaman canınızı sıkar. Ancak daha büyük problemleri engellemek için bu gereklidir!!!

Demand / Capacity Management (Talep / Kapasite Yönetimi): ITIL’da var olan çok hassas bir dengedir. Kapasite süreci “servis tasarımı” sürecine dahildir. İş ihtiyaçlarından ve stratejilerinden aldıkları inputlarla kapasiteyi belirler ve tasarlarlar. Talep yönetimi ise Service Strategy sürecinin görevidir. Talep yönetimi sürecinin görevi müşteriden gelen talebin kapasitenin çok altında veya üstünde değil kapasiteyi verimli kullanacak şekidle tutmaktır. Talep yönetimi süreci müşteriden gelen talepleri yönetemezse iki olaydan biri olur, ya atıl kapasite ile zarar edersiniz, veya kapasite üstü kullanımdan müşteri memnuniyetiniz düşer, para ve prestij kaybedersiniz. Gerçek hayattaki ilişkilerinizde de durum aynen böyledir. Öncelikle kapasite metriklerinizi iyi değerlendirmeniz gerekmektedir. Satın alabileceğiniz araba, oturduğunuz ev ve diğer şartlar çok net ve tanımlı olmalıdır. Ve ilişki süresince talepleri her zaman dengelemeniz gerekmektedir. Araba kapıda dururken otobüs kullanmamanız gerekir. Ufak bir çiçek alarak sevdiğiniz insanı memnun edebilecek ve servis seviyesini tutturabilecekken bu konuda gol yemek kapasiteyi boşa harcayıp müşteri memnuniyetsizliği yaratmaktan başka nedir?! Aynı zamanda kapasitenizin üzerinde talepleri de baştan engellemelisiniz. Önemli bir kapasite ihtiyacı doğuracak talepler gelmeden önce mutlaka önlem almalısınız, yoksa kapasite yönetimi süreciniz ciddi sıkıntıya girecektir! Hesapta olmayan ani harcamalara dikkat! Hele bu harcamaları tetikleyecek yan faktörlere daha da dikkat!

Stability / Responsiveness (Stabilite / Duyarlılık) Dengesi: ITIL’da bir diğer dikkat etmeniz gereken denge de stabilite duyarlılık dengesidir. Stabilite önemlidir. Sunduğunuz servislerin istikrarını belirler. Duyarlılık da önemlidir, servisleri müşteriden gelen talepler ölçüsünde esnetebilmeli ve değiştirebilmelisiniz. Ancak her iki yönün de fazlası zarar verecektir. Çok fazla stabilite müşterinin isteklerini göz ardı etmek demektir. Çok fazla duyarlılık ise altyapınızın istikrarını etkileyecektir. Özel hayatınızda da eşinizin isteklerine karşı duyarlı ve değişime açık olmalısınız. Ancak çok değişime açık olmak sizi karaktersiz bir insan yapıverir! Ancak çok katı olursanız bir süre sonra eşiniz “benim isteklerimle ilgilenmiyor” cümlesiyle başlayan ve sonu hiç de iyi olmayan bir sürece girebilir!

Sonuç

Evet. Bu yazımda sizlere ITIL’ın aslında sadece bilişim süreçlerini daha iyi yönetmek için değil, sunulan ve alınan herhangi bir değerin var olduğu yerde uygulanabilecek bir tecrübeler bütünü olduğunu biraz olsun göstermek istedim. Bunu yaparken de açıkçası ITIL’daki süreçlerin bazıları hakkında farkındalık yaratmayı da hedefledim.

Umarım faydalanmışsınızdır.

IBM,  Operations Manager 2007 SP1 ve R2 için güncel Management Pack yayınladı.

System x Sunucular, Blade  ve BladeCenter Chasis altyapılarını tek bir Management Pack ile yönetebilirsiniz.

Yeni (v2.1) Management Pack ve dokümantasyon için:
http://www.ibm.com/systems/management/director/partners/microsoft/

• System Center Operations Manager 2007 SP1 Internet Information Services 7.0 Monitoring support
• Microsoft Office SharePoint Server 2007 Management Pack for System Center Operations Manager 2007
• Microsoft SharePoint Services 3.0 Management Pack for System Center Operations Manager 2007

ITIL ile meşgul olan arkadaşlar çok iyi bilirler ki ITIL yaşayan bir süreçtir. Hiçbir kurum “mükemmel” ITIL süreçlerine sahip olamaz. ITIL planlanması, uygulanması ve devamında ölçümlenip iyileştirilmesi gereken ve bu döngüyü işiniz yaşadıkça korumanız gereken bir değerdir.

Günümüzde ise birçok kurum çok büyük paralar harcayıp onbinlerce sayfa kağıttan oluşan süreçleri hazırlattıktan sonra ne yazık ki bunu hayata geçiremiyorlar. Hayata geçirebilenlerin çoğu ise bu süreci iyileştiremedikleri için zaman içinde ITIL ya kullanılmaz hale geliyor veya amacının tersine işleyen, işleri standartlaştıracağına karmaşıklaştıran bir etken haline dönüşüyor.

Süreç oluşturmak ITIL’ın en kolay kısmıdır. Çünkü süreç oluştururken iyi bir danışman firma ile çalışırsanız ve o firmaya kurumunuzdaki ilgili departmanlardaki en iyi çalışanlarla beraber ITIL süreçlerini geliştirme fırsatı verirseniz hızlı ve başarılı şekilde ITIL süreçleriniz oluşturulur. Devamında gelen teknoloji ve mimari kısmını da doğru danışmanlık firmaları ile gerçekleştirebilirsiniz. ITIL ve benzeri süreçleri oturturken en zorlanacağınız kısım ise, en az düşünülen “insan” faktörüdür.

İnsanlar doğası gereği inanacakları bir sebep olmadan değişmek istemez.

Bugüne kadar gerçekleştirilen ITIL projelerinin “başarısız” olarak nitelendirilmesine sebep olan en yüksek değerdeki 10 hatayı size özetlemek istedim, umarım işinize yarar:

Hata-1

Vizyon eksikliği. Etrafta bir ITIL furyası başlamıştır, ancak hiçkimsenin aslında ne olduğundan haberi yoktur ve sorulara net cevap verebilen yoktur.

Öneri
ITIL projesi için planlarınızın ve konsantrasyonunuzu açıkça ve net olarak belirleyin. Açık ve net bir vizyon aynı zamanda ITIL süreçlerini uygulama girişiminiz için ivmenizi kaybetmenizi de engelleyecektir.

Hata-2

Şirketin en tepesinden taahhüt almamız gerekmez. ITIL projesini orta seviye yöneticilerle geliştirebiliriz.

Öneri
ITIL projelerinin başarılı olması için yönetimden bir destekleyiciniz olması şarttır, özellikle zaman, bütçe ve kaynak ihtiyaçlarınızın arttığı anlarda. ITIL sindirilmesi zor süreçler bütünüdür, kendiniz dahi tam olarak ne olduğunu anlayamadığınız bir değeri yönetime satmanız zor olabilir. Yönetimde etkili olan bir destekçi çok işinize yarayacaktır.

Hata-3

Olurluk incelemesine ihtiyacımız yok. ITIL’ın neden önemli olduğunu ve niçin yaptığımızı biliyoruz.

Öneri
Projenin sponsorlarına ITIL’ın kuruma katacağı iş faydalarını çok net belirtmelisiniz. Aşağıdaki bileşenlerden oluşan proje kontrol listesi oluşturun:

• Maliyeti net olarak hesaplayın. “ITIL’ı uygulamanın belirli bir başlangıç maliyeti olacağının farkındayız, ama bu maliyet bana neler kazandıracak?”
• Kapsamı belirleyin ve doğrulayın. Kapsam çok net olmalı.
• Başarı kriterlerini ve faydaları belirleyin. Uygulayacağınız çözümün başarısını belirleyin ve hedeflerinize nasıl ulaşacağınız konusunda açık olun. Faydaları net olarak ortaya koymak ihtiyacınız olan kaynağa ulaşmanızı kolaylaştıracaktır.

Hata-4

Baz çizgisi oluşturmamıza, var olan durumun resmini çekmemize gerek yok. Hemen işe koyulalım.

Öneri
Geliştirmeyi hedeflediğiniz noktaları net olarak belirleyin. Hedefleriniz olsun ve baz çizgisi oluşturmak için bilinen metotlardan faydalanın (kurum olgunluk değerlendirmesi, değişiklik hazırlık değerlendirmesi vb)

Hata-5

ITIL stratejik bir proje değildir, var olan kaynakları kullanarak geliştirebiliriz.

Öneri
Bir proje planı oluşturun ve projeyi geliştirmek için en deneyimli ve başarılı kaynakları belirleyin, boş zamanı olan insanları değil! Üst düzey yönetici bir destekçi, finansör, süreç sahipleri, süreç yöneticisi, proje yöneticisi, süreç danışmanı, süreç takım üyeleri gibi kişilerden oluşan bir rüya takımı oluşturun.

Hata-6

İletişim stratejisine ihtiyacımız yok. Birkaç başlangıç toplantısı ve birkaç e-mail ile işe başlayabiliriz.

Öneri
Açık bir iletişim stratejisi oluşturmak size yönetime “neden” “ne zaman” ve “niçin” sorularını ITIL perspektifinden cevaplamak için yardımcı olacaktır. Farklı iletişim yolları kullanın. Birçok kişi standart e-mail yerine interaktif, yüz yüze iletişim kurmaktan hoşlanır (Web meeting, videolar vb). İletişim ve pazarlama departmanından iletişim stratejisi oluşturmak için destek alın. Kurumun farklı kademesindeki insanlar için (üst düzey yöneticiler, orta düzey yöneticiler vb) için farklı iletişim yöntemleri ve mesajları oluşturun. Tutarlı bir mesajınız olsun ve tüm iletişimlerde aynı mesajı vermeye çalışın. Birebir, interaktif iletişimle daha fazla kullanıcının geri beslemesine ulaşabilirsiniz.

Hata-7

Genel süreç stratejisine ihtiyacımız yok. Farklı ekipler farklı süreçleri farklı zamanlarda geliştirsinler, süreçleri birleştirme konusuna daha sonra bakarız.

Öneri
Doküman kontrolü için merkezi bir yapı oluşturun ve tüm süreçler için ortak şablonlar oluşturun. İstikrarlı olun. Tüm süreçlerinizi “entegrasyonu” göz önünde bulundurarak tasarlayın.

Hata-8

ITIL projesi için bir yazılım bulduk. Önce bu yazılımı oturtalım, sonra onun etrafına ITIL süreçlerini geliştiririz.

Öneri
ITIL çözümünü geliştirmek için yeterli zamanı ayırın. ITIL için araçlar ararken aracın desteklediği ITIL versiyonundan ve aracı üreten firmanın tavsiyelerinden  çok sizin süreç ve planınızı göz önünde bulundurun.

Hata-9

Tüm ITIL süreçlerini en ufak detayına kadar planlayalım, kapsam belirlemek için aylar ayıralım. Şu işi bir kerede mükemmel olarak bitirelim!

Öneri
Çiğneyebileceğinizden daha büyük lokma yemeyin. Continual Service Improvement süreci yeni ITIL’ın büyük bir parçasını oluşturuyor ve bu süreç size kurumunuzda uyguladığınız ITIL’ın hiçbir zaman “mükemmel” olamayacağını çünkü iş ihtiyaçlarınızın sürekli değiştiğini, ITIL süreçlerinizin de sürekli olarak iyileşmesi gerektiğini söylüyor. Ayrıca bir anda mükemmele ulaşmanız gerekmiyor.

Hata-10

ITIL’a fazla bir direnç beklemiyoruz. Kurum çalışanlarımıza neler yapmaları gerektiğini söyleyeceğiz ve onlar da yapacaklar!

Öneri
İnsanoğlu her zaman değişime dirençlidir ve değişmek için bir sebep arar. ITIL’ın etkileyeceği kişilere bu değişimin sonucunda neler elde edeceklerini çok iyi anlatın. ITIL ile sadece süreçleri ve teknolojiyi değiştirmiyorsunuz, insanları ve kültürü değiştiriyorsunuz!

ITIL süreçlerinizi tasarlarken, özellikle operasyonel süreçlerde dikkat etmeniz gereken bir diğer nokta stabilite ve duyarlılık dengesidir.

ITIL Service Operation’un başlıca görevlerinden biri operasyonel perspektiften BT altyapısının stabil ve erişilebilir olmasını sağlamaktır.

Bunun yanında Service Operation iş ve BT ihtiyaçlarının sürekli gelişim ve değişim içinde olduğunu da göz önünde bulundurmalıdır ve bu konuda duyarlı (Responsive) olup bu ihtiyaçlara hızlıca cevap verebilmelidir.

Stabilite ve duyarlılığın oranı ise çok önemlidir. Stabilite’ye ağırlık veren bir BT organizasyonu zaman içinde iş ihtiyaçlarını karşılayamaz olur ve kendi içinde kusursuz çalışsa dahi müşteri memnuniyetsizliği oluşmaya başlar. Stabilite’den öndün vererek müşterilerden gelen tüm isteklere uyum sağlamaya çalışan operasyon ise BT servislerinin kalitesini sağlayamaz hale gelir ve yine müşteri memnuniyetsizliği ile karşılaşır.

Sunulan servislerin müşteri ihtiyaçlarına göre optimize edebilmesi ve gerekli noktalarda değiştirilebilmesi ancak strateji, değişiklik, konfigürasyon yönetimi gibi süreçlerin de işin içine dahil olması ile mümkün olabilmektedir.

Bazen ufak sanılan bir müşteri ihtiyacı değişimi tüm servis stratejinizi yeniden tasarlamanızı gerektirebilir, bazen çok büyük etkisi olacağı düşünlen ihtiyaç değişiklikleri aslında ufak optimizasyonlarla operasyona entegre edilebilmektedir.

Unutmamak gereken önemli noktalardan biri de, Service Operation süreçleri tüm ITIL servislerinizin realize olduğu, müşteriyle etkileşim içinde olduğunuz süreçlerdir  ve müşteri memnuniyetine direk etkisi vardır.

• Fixed performance issues caused by excessive CPU utilization and script timeouts from Windows Management Instrumentation (WMI) queries in the following management pack discoveries: Discover SQL Server 2005 Database Engines (Windows Server), Discover SQL Server 2005 Reporting Services (Windows Server), Discover SQL Server 2005 Analysis Services (Windows Server), Discover SQL Server 2008 Database Engines (Windows Server), Discover SQL Server 2008 Reporting Services (Windows Server), Discover SQL Server 2008 Analysis Services (Windows Server).
• Fixed an issue where SQL Server 2005 and SQL Server 2008 Analysis Services and Reporting Services discoveries were not reliably discovering these objects on instances of SQL Server that did not have the Database Engine installed.
• Removed the hard-coded exception in rules and monitors that prevented the monitoring of the System, Temp, and Master databases.
• Improved the means by which database discoveries recognize auto growth enabled settings.
• Database discoveries now recognize both “KB” and “%” growth settings; previously the database discoveries recognized only the “KB” growth setting.
• Corrected typographical errors in product knowledge and improved the quality of the text.

BT Servis Yönetimi yaşam döngüsünün tüm fazlarındaki en çok karıştırılan noktalardan biri BT nin son kullanıcılar (yani müşteri / iş) tarafından görünen “BT servisleri” perspektifi ile BT organizasyonunun içeriden gördüğü “bir takım teknoloji bileşenleri” perspektifidir.

• BT’nin dışarıdan görünüşü son kullanıcıların ve müşterilerin deneyimledikleri kadarıyla tanımlanır. Son kullanıcılar servisleri kullanırken arka planda ilgili servisleri yönetmek veya tasarlamak için hangi teknolojilerin kullanıldığını her zaman anlamazlar, ki zaten merak da etmezler :-) Son kullanıcının her zaman önemsediği nokta servislerin ihtiyaçlar ve anlaşmalar çerçevesinde sunulmasıdır.
• BT’nin içeriden (sistemi yöneten veya tasarlayan kişilerin perspektifinden) görünüşü ise farklı BT bileşenler, teknolojileri ve sistemlerinin birleşimidir. BT sistemleri karmaşık ve çok çeşitlidir, dolayısıyla teknoloji birçok farklı ekip veya departman tarafından yönetilebilir. Her birim kendi sorumluluğu dahilindeki sistemler ile ilgili performans ve erişilebilirlik değerlerini sağlamaya yoğunlaşmışlardır.

Servisleri sunarken her iki perspektif de gereklidir. Sadece iş ihtiyaçlarına odaklanan ancak bu ihtiyaçları nasıl sağlayacağını yeterince tasarlamayan birimler tutamayacakları sözleri vermek zorunda kalırlar. Sadece iç teknik bileşenlere yoğunlaşan ve son kullanıcılara hangi servisleri sunacaklarını düşünmeyen birimler düşük katmadeğer sağlayan yüksek maliyetli sistemlere sahip olacaklardır.

İç ve dış perspektifler arasındaki potansiyel rol çakışması genelde kurumun yapısı, yönetim kültürü, geçmişi gibi birçok değişkenin sonucu olarak ortaya çıkar. Bu tip durumlarda dengeyi sağlamak oldukça güçleşir, birçok kurum dengeyi sağlayamaz ve iki taraftan birine daha fazla ağırlık vermek zorunda kalır.

ITIL V3’ün Service Strategy bölümünde ele alınan Fayda VS Garanti konusu aslında günümüzde birçok işletme için çok önem arz eden bir konu.

Özellikle bankalar, büyük telekomünikasyon kurumları gibi, kendi BT altyapılarını kendileri yöneten kurumların her an karşı karşıya oldukları bir risk.

Fayda (Utility), kısaca sizin (BT organizasyonu) müşterinize (iç firma veya dış firma olabilir) sunduğunuz BT servisleri ile sağladığınız kazanımlar veya azalttığınız kısıtlamalar olarak ölçülür.

Garanti (Warranty) ise sunduğunuz servislerin kalitesini (kapasite, erişilebilirlik, güvenlik vb) sağlamayı kapsar.

Özellikle kendi firmasına BT hizmeti veren organizasyonlarda bu dengenin çok iyi korunamadığını görüyoruz. Örneğin, bazı firmalar SCOM, SCCM, Exchange gibi ne kadar müşterinin ihtiyacı olan / olmayan servis varsa ortama kazandırıyorlar, fakat bu servislerin operasyon ve standardizasyon kısmını hesaplamıyorlar. Sadece tasarımı gerçekleştirip (ki tasarımları da çoğu zaman profesyonel bir firma ile beraber gerçekleştirmiyorlar, ortaya endüstri standartlarına uygun tasarımlar çıkmıyor) servisi sunuyorlar. Bir süre sonra kullanıcılar bu servislere alışıyor ve günlük operasyonlarına dahil ediyor. Bu noktaya kadar “Fayda” olumlu.

Ancak kurumlar ortama kazandırdıkları servisler ile beraber bu servislerin erişilebilirlik, güvenlik, yönetim prosedürleri ve operasyonel standartları gibi öğeleri konumlandırmadıkları için bir süre sonra müşteri memnuniyeti düşmeye başlıyor ve son kullanıcılardan şikayetler almaya başlıyorsunuz. Yani Garanti (Warranty) konusunda sıkıntılar başlıyor.

Veya bunun tam tersi geçerli olabiliyor. Bazı kurumlar (Türkiye’de az olan bir durum :)) erişilebilirlik, güvenlik, prosedür gibi servisi garantileyen faktörleri o kadar önceliklendiriyorlar ve bu faktörlere o kadar fazla kaynak ayırıyorlar ki, işin ihtiyacı olan servisler ortama kazandırılmakta geç kalınıyor ve “fayda (utility)” düşük oluyor.

Proje geliştiren ve operasyonu gerçekleştiren departmanların farklı olduğu kurumlarda ise genelde projeyi geliştiren departmanlar bir danışman firma veya ürünü geliştiren firma (Microsoft, HP vb) ile çalışıyorlar ve servisleri hızlı bir şekilde altyapılarına kazandırıyorlar. Ancak bu servisler operasyona indirilirken çoğu zaman sorun yaşanılıyor.

Ne yapmalı?

• Öncelikle herhangi bir servisi ortama kazandırmadan önce o servisin sağladığı faydaların işe etkisini ölçümlemelisiniz. Ortamdaki çözümleri “merak ettiğiniz” veya “popüler olduğu” için değil, gerçekten işinizin ihtiyacı olduğu için geliştirmelisiniz.
• Çözümü geliştirirken tasarımın doğru yapıldığına emin olmalısınız. Çözümü geliştirirken müşterinizin ihtiyacı olan erişilebilirlik, performans, güvenlik gibi öğeleri göz önünde bulundurmalısınız. BU noktada profesyonel bir firmadan destek alınabilir.
• Geliştirilen çözüm ile beraber ITIL perspektifindeki operasyonel süreçleri de geliştirip çözümü müşteriye eğitimiyle, desteğiyle, değişiklik yönetimiyle, kapasite yönetimiyle uçtan uca indirmelisiniz.
• Müşteriniz kendi iç firmanız olabilir, yine de bütçeleme ve hesap yapmak zorundasınız. Müşteriye fatura kesmek veya kesmemek opsiyonel olabilir ancak sunduğunuz servislerin başlangıç ve sürekli maliyetlerini hesaplamamamak genel yapılan bir hatadır.

Article ID : 969597
Last Review : March 27, 2009
Revision : 1.0
Source: Microsoft Support

Symptom

You may experience very high CPU utilization on Cluster servers after installing the Cluster Management Pack Update 6.0.6505.0 for SCOM 2007. Regardless of the number of Processors (Cores), the load is evenly distributed, with no particular process identified as solely responsible for this high CPU usage.

Usually the Cluster Service (clussvc) and Resource Monitor (resrcmon) processes are identified as top CPU users.

This effect has been noticed especially on Cluster servers with a large (60+) number of resources.
Cause
The issue is caused by a problem in the WMI polling mechanism of the Resource State Monitor.

Resolution

Note The following processes are only appropriate when using the Cluster Management Pack referenced earlier.

To workaround this issue, you can implement one of the following options:

Option #1: Override the default frequency of the Resource State Monitor:
1. Open the Manager Console.
2. Choose Authoring -> Management Pack Objects -> Monitors.
3. Type Resource State Monitor in the Look for field, click Find now.
4. Right-click on the Resource State Monitor, choose Overrides: Override For all objects of type: Cluster Resource.
5. Put a check in the box beside WMI Poll Interval and increase the value under Override Setting.

Option #2: Disable the Resource State Monitor on the cluster nodes
1. Open the Manager Console.
2. Choose Authoring -> Management Pack Objects -> Monitors.
3. Type Resource State Monitor in the Look for field, click Find now.
4. Right-click on the Resource State Monitor, choose Overrides -> Disable the monitor.

*** The agents on the cluster nodes will now be made aware of this configuration change ***

Var olan bir Run As account’ında  değişiklik gerçekleştirilirken Distribution (dağıtım) ayarları “More Secure” olarak seçildiğinde ve kimlik ayarlarının dağıtılacağı bilgisayarlar seçildiğinde, değişiklik uygulandığında seçilen bilgisayarlar yok oluyor.

Not: Bu hotfix sadece OpsMgr 2007 RC R2 versiyonu için geçerlidir.

https://connect.microsoft.com/Downloads/DownloadDetails.aspx?SiteID=446&DownloadID=17439

Operations Manager ortamınızı RC versiyonuna yükseltirken Microsoft aşağıdaki yükseltme yolunu destekliyor:

Yükseltmeden önce

Ortamınızı yükseltmeden önce aşağıdaki adımları tamamlamanız önerilmektedir:

Yükseltme sırası

Ortamınızı aşağıdaki sırada yükseltmeniz önerilmektedir:

From: Justin Incarnato [mailto:justini@microsoft.com]
Sent: Thursday, March 26, 2009 4:42 AM
Subject: System Center Operations Manager 2007 R2 Release Candidate - Now Available [MVP]
Importance: High

MVPs, go get it!

 

We are very excited to announce the System Center Operations Manger 2007 R2 Release Candidate now available on connect!

Operations Manager 2007 R2 Release Candidate

 

Operations Manager 2007 R2 introduces key new and enhanced functionality, including:

Enhanced application performance and availability across heterogeneous platforms

· Delivers monitoring across Windows, Linux and Unix servers–all through a single console
· Extends end to end monitoring of distributed applications to any workload running on Windows, Unix and Linux platforms
· Maximize availability of virtual workloads with integration with System Center Virtual Machine Manager 2008

 

Improved management of applications in the data center

· Delivers on the scale requirements of URL monitoring of your business
· Meet agreed service levels with enhanced reporting showing application performance and availability
· More efficient problem identification and action to resolve issues

 

Increased speed of access to information and functionality to drive management

· Faster load times for views and results
· Improved and simplified management pack authoring experience

 

For those who are evaluating the Beta release, this Release Candidate offers a number of enhancements over the Operations Manager R2 Beta, including:

· New Power Management MP template (Monitored system must be Windows Server 2008 R2 or Win7)
· Updated branding across all User Interfaces
· Improved trace configuration tools on the CD to help support issues escalated to Customer Support (where applicable)
· Improved Run As Account Distribution Configuration
· Ability to run inline tasks for non-Microsoft servers
· Support for upgrade from Beta deployments to the Release Candidate
· New and updated documentation, including the Usage Guide, Design Guide, Deployment Guide, Upgrade Guide, Security Guide and Operations Guide

 

In addition to the build, we are providing the Release Notes as well as other key documentation including:

· Operations Manager 2007 Supported Configurations

· Operations Manager 2007 R2 RC Design Guide

· Operations Manager 2007 R2 RC Deployment Guide

· Reporting Deployment and Usage Troubleshooting

· Operations Manager 2007 R2 RC Upgrade Guide

· Operations Manager 2007 R2 RC Security Guide

· Operations Manager 2007 R2 RC Operations Guide

· Operations Manager 2007 R2 RC Usage Guide

· Operations Manager Management Pack Guide for Operations Manager 2007 R2

Operations Manager 2007 R2 Release Candidate Release Notes

Operations Manager 2007 R2 Release Candidate Documentation

 

We would also like to provide you access to the Service Level Dashboard 2.0 Beta for Operations Manager 2007 R2, available here:

Service Level Dashboard v2 Beta for Operations Manager 2007 R2

 

Lastly, Please post your RC feedback/bugs/suggestions here:

https://connect.microsoft.com/feedback/CreateFeedbackForm.aspx?FeedbackFormConfigurationID=1872&FeedbackType=1&SiteID=446

Thanks,

Justin

Bu Cuma (27.03.2009) itiribariyle Operations Manager 2007 R2 RC release ediliyor.

RC versiyonu ile birlikte gelen yeniliklerden biri de bir süredir ürün grubu ile test ettiğimiz Visio entegrasyonu.

Visio entergrasyonu için Visio add-in’ini yüklemeniz gerekmekte. Bu add-in R2’nin şu anki beta versiyonunda bulunmuyor, RC versiyonu ile birlikte test edebilirsiniz.

Distributed Application’ınızı .VDX uzantılı Visio dosyası olarak export ettikten sonra bu dosyayı Visio ortamında açıyorsunuz.

Add-in ile beraber Visio’ya “Operations Manager” isimli bir menü ekleniyor.

Configure butonu ile birlikte Visio’ya OpsMgr RMS sunucunuzu tanıtmanız gerekiyor:

Distributed Application’unuzu Visio ortamına import ettiğinizde herhangi bir Visio diyagramı gibi görünse de, objelerin sağlık durumlarını isterseniz manuel olarak menüden “Refresh”  diyerek veya belirli aralıklarda otomatik olarak güncelleyebilirsiniz.

Aynı zamanda farklı veri kaynaklarından veri linkleme gibi birçok farklı özellik de kullanmanız mümkün.

Ufak ama oldukça güzel bir özellik olan Visio entegrasyonunu Operations Manager 2007 R2 RC ile beraber denemeye başlayabilirsiniz.

 Geliştirdiğiniz Operations Manager 2007 çözümlerinizde kullanabileceğiniz faydalı 3rd party Management Pack’lerin kısa bir listesini oluşturdum:

Operations Manager 2007 konsolunuzla herhangi bir haritayı (dünya haritası, sistem odanızın kabinet şeması vb) birleştirip hem izleme hem raporlama anlamında Operations Manager’a oldukça etkili bir özellik eklemek isterseniz Live Maps v3 uygulamasını kullanabilirsiniz.

Operations Manager 2007 ortamında, dünya haritasında kurumunuzun lokasyonlarının ifade edildiğini düşünün, haritalara tıklayarak Türkiye haritası, İstanbul haritası, binanızın kat şeması ve sunucu kabinetine kadar inebildiğiniz bir görsel ortam hayal edin.

Live Maps uygulamasının 3 haritaya kadar sınırlı ücretsiz versiyonunu  http://www.savision.com/news?code=freeversion adresinden indirebilirsiniz.

OpsMgr 2007 Product grup ile bugüne kadar OpsMgr ile en sık kullanılan Mobil SMS çözümleri & cihazları hakkında bir fikir alışverişinde bulunduk.

Çıkan sonuçları sizlerle paylaşmak istedim (projelerinizde referans olarak kullanmanız için):

• http://www.alarmpoint.com/ (Operations Manager 2007 için connector kısa sure içinde public oluyor, isterseniz şu anda rory.mccaw@infrontconsulting.com adresine mail atarak edinebilirsiniz)
• http://www.sysman.no/
• http://www.mir3.com/Products/inEnterprise/inEnterprise.php
• http://www.multitech.com/PRODUCTS/Families/MultiModemGPRS
• Siemens TC 35 http://www.d-d-s.nl/foto-siemens/Datasheet_TC35i_Terminal.pdf  & Derdack Messagemaster http://www.derdack.com/files/ea2007_opsmgr2007_en.pdf

Bildiğiniz gibi bir diğer opsiyon da web üzerinden gönderilebilecek toplu SMS satın alıp, telefon numarası ve mesaj parametrelerini kullanarak bu servis üzerinden SMS atabilecek bir .exe yazıp bu exe’yi command Notification Channel olarak kullanmak, ancak internet erişiminin kesildiği durumlarda bu çözüm işe yaramayacaktır.

Bildiğiniz gibi Operations Manager 2007 için var olan Exchange Management Pack’i aslında Exchange 2003’ten çevrilmiş bir management pack idi.

Ürün grubu bir süredir Native Exchange 2007 management pack geliştiriyor.

Management Pack şu anda beta versiyonda, isteyenler mpcc@microsoft.com adresine mail göndererek Management Pack’i edinebilir ve deneyebilirler (kurmadan önce kurulum notlarını mutlaka okuyun).

2003’ten çevrilen Exch management pack’inde 2400 alert generating rule vardı, yeni MP’de bu %65 oranında azaltılarak 850’ye düşürüldü. Exchange team’in Exch 14 için geliştirdiği Key Health Indicator çalışması Exch 2007 için de uygulanıyor, ve bu sayede MP’in kalitesi düşürülmeden bu rakamlar daha da aşağıya çekilecek.

Yeni MP ile ilgili aşağıdaki harika özellikler gelecek (bu özelliklerin bir kısmı şu anki sizlerin indirebileceği public beta’da yok, R2 RC versiyondan birkaç hafta sonra QFE olarak eklenecek):

• CAS, Hub, MBX gibi rollerin her biri için ayrı MP modulleri geliştirildi
• Mail flow ve Client Access Server Synthetic Transaction’ları template olarak eklenecek (şu an beta testlerini yapıyoruz, Nisan sonu gibi QFE olarak eklenecek)
• R2’deki SLM raporlarına entegre edilecek ve “Mail 15 dakika içinde deliver edilmezse” gibi hedefler konulabilecek
• Exchange Server için geliştirilmiş birçok task MP ile beraber geliyor
• Alert noise reduction için “consecutive samples” gibi algoritmalar yeni MP için de kullanılacak
• Replikasyon izlenebilecek
• Birden fazla Exchange organizasyonu izlenebilecek

Kurulum hakkında destek veya diğer sorularınız için bana mail ile ulaşabilirsiniz.

Bugüne kadar gerçekleştirilen Operations Manager projelerinin bence “başarısız” olarak nitelendirilmesi ve kurumlar tarafından sahiplenilmemesinin en büyük sebeplerinden biri olarak gerçekleştirilen Operations Manager projelerinde “Alert tuning” dediğimiz olaya yeterince zaman ayrılmaması olduğunu düşünüyorum.

Özetle, zaman içinde Operations Manager ortamınızı öyle bir hale getirmelisiniz ki, konsolda “kırmızı” bir alert gördüğünüzde gerçekten önlem almanız gerektiğini anlamalısınız. Eğer konsolda haftalar öncesine ait yüzlerce alert varsa gerçekleştirdiğiniz Operations Manager projesi hedefe ulaşmamış demektir.

Bunun için Operations Manager 2005’e “Alert Tuning Solution Accelerator”  vardı (Webde arayıp kolaylıkla bulabilirsiniz), 2007 versiyonu çıkmadı diye biliyorum ama yaklaşım olarak işinize yarayabilir. Konu kısaca Operations Manager bileşenlerinin kurumunuzun ihtiyaçlarına göre özelleştirilmesi veya devreden çıkarılması. Alert optimizasyonunu istediğiniz noktaya getirdiğinizde, ikinci olarak servis modellemesi önem kazanıyor.

Şirketinizin BT servis modelini doğru şekilde Operations Manager’da oluşturmanızı ve availability raporlarınızı bu servis modellerinden almanızı öneririm. Sonuçta karşınıza “Genel servis erişilebilirliğim : %96,50, bunun alt kırılımları: %91,x – abc servisi, % 98,x cde servisi” gibi raporlar alabiliyor olmanız gerekiyor. Drilldown ile en alt bileşenlere kadar inebilirsiniz.

Sevis modelini oluştururken elinizden geldiğince altyapınızı uçtan uca izlemenizi öneririm. Yani veri merkezinizden son kullanıcılara gidene kadar tüm bileşenleri izleyip, erişilebilirlik oranınızı da son kullanıcı perspektifinden hesaplamanız en doğrusu olacaktır.

Kurumunuzda gerçekleştireceğiniz yeni donanım yatırımlarınızı Operations Manager 2007’den alacağınız memory, processor gibi temel raporlar ölçüsünde ön görmenizi ve gerçekleştirmenizi öneririm.

Unutmamanız gereken bir diğer nokta, Operations Manager sadece ortamdaki sorunlar ile ilgili bilgi veren bir çözüm değildir, doğru kullanıldığında aynı zamanda ortamda iyi yaptığınız işleri ve iş yükünüzü ispatlamanızın çok doğru bir yöntemidir.

Aynı zamanda ACS çözümü geliştirip kullanmanızı öneririm. Hiç olmazsa, security log üzerinden en azından kullanıcı hesabı yaratma, değiştirme, şifre değiştirme gibi kritik olayları (Security log / Account Management / 624, 628, 630, 632, 633 gibi eventler) Alert Generating Rule lar ile dinleyebilirsiniz (bunun için ACS’e gerek yoktur).

Son olarak, kurumunuzdaki Windows tabanlı olmayan bileşenleri de 3rd party Management Pack’ler kullanarak uçtan uca servis modelinize ekleyebilirsiniz. Daha önce proje geliştirdiğimiz 3 farklı müşteride SAP, Oracle, AS400, VMWare, Cisco, Linux/Unix gibi birçok platform ve uygulamayı Operations Manager ile izledik. Bu bileşenleri Operations Manager ile izlemenin bir diğer avantajı ise, performance view gibi özellikleri bu tip non-windows bileşenlerde kullanabilmek ve bu bileşenleri de Distributed Application mimarinize dahil edip, BT altyapınızı uçtan uca izleyebilmeniz, herhangi bir problem durumunda etki analizini daha sağlıklı gerçekleştirebilmeniz, sorunların kök sebeplerini daha hızlı ve etkin ortaya çıkartabilmenizdir.

Özetle,

• Eğer konsolda kırmızı bir uyarı gördüğünüzde panik olmuyorsanız
• Kurumunuz için çok kritik olan bir serviste merkezi bir kesinti olduğunda cep telefonunuza kadar uyarılar gelmiyorsa
• Donanım yatırımlarınızı gerçekleştirirken Operations Manager raporlarını kullanmıyorsanız
• BT departmanınızın başarısını ve servislerinizin erişilebilirlik seviyelerini ölçümlerken Operations Manager raporlarını kullanamıyorsanız
• Sorun anında, herkes panik halde etrafta koşturuyorsa, birkaç mouse klik ile sorunun kök sebebini görsel olarak ortaya koyamıyorsanız
• Şirketinizin en görünür yerinde bir projektör veya büyük bir monitörde servis ağacınızın gerçek zamanlı modeli yansıtılmamışsa

 Başarısız bir Operations Manager projesi gerçekleştirmişsiniz demektir :)

ACS (Audit Collection Services) Operations Manager 2007 ile beraber gelen ve şüphesiz güvenlik denetimi ve raporlaması yapmak isteyen, özellikle IT denetimlerine tabi olan kurumların işlerini çok kolaylaştıran çözümdür.

ACS sayesinde aşağıdaki örnek sorulara ve çok daha fazlasına cevap vereceğiniz analiz raporları veya verilerine birkaç dakika içinde ulaşabilirsiniz:

• Belirtilen sunucuya son 3 gün içinde kimler oturum açmış?
• Belirtilen sunucuda son 7 gün içinde “alpero” kullanıcısı hangi yazılımları çalıştırmış?
• “alpero” kullanıcısı son 1 aydır hangi sunuculara oturum açmış?
• Son 1 haftadır Active Directory üzerinde kimler yönetimsel görevler (kullanıcı hesabı oluşturmak, silmek, şifre resetlemek gibi) gerçekleştirmiş?

ACS sayesinde aynı zamanda sizin aklınıza soru olarak gelmeyecek fakat güvenlik tehdidi oluşturabilecek konuları da raporlayabilirsiniz. Aynı zamanda adli konular için delil niteliği taşıyan raporlar üretebilirsiniz.

Bununla beraber, Operations Manager 2007 ortamında ACS özelliğini aktif hale getirmeden önce veri depolama kapasitesinin ve optimizasyonun çok iyi tasarlanması gerekmekte. Aksi taktirde ACS veritabanınız çok kısa süre içinde saklayamayacağınız veya raporlayamayacağınız büyüklükte veriler ile dolabilir.

Peki, ACS çözümünü altyapıya uygularken ne gibi optimizasyon seçenekleri mevcut?

AUDIT POLICY

ACS raporları istemciler ve sunucular üzerindeki security event log’larının merkezi veritabanına toplanıp yorumlanması sonucunda oluşturulur. Bu perspektiften bakıldığında ACS veritabanında oluşacak verilerin kaplayacağı alan ve ihtiyaç duyacağı donanım kaynağı, ACS ajanları üzerinde aktif hale getirilecek Audit Policy’ler ile doğru orantılıdır. İhtiyacınız olmayan Audit Policy’leri devreden çıkararak ACS optimizasyonunda ilk adımı atabilirsiniz.

ACS COLLECTION FİLTRELERİ

ACS veritabanından elde edeceğiniz ilk raporların çoğu zaman raporların işinize yaramayacak, gereksiz bilgiler ile dolduğunu göreceksiniz (Group Policy kontrolü yapmak için oturum açan ve kapatan bilgisayarların COMPUTER$ şeklindeki hesapları gibi…). Bu kirliliği engellemek için ACS Collection Filtrelerini kullanmanız gerekmekte. Bu konu ne yazık ki Microsoft tarafından çok iyi dokümante edilmemiş konulardan biridir. Fakat Microsoft’un özellikle ACS konusunda oldukça başarılı çözümler geliştiren Secure Vantage firmasının ürettiği “ACS Noise Filter Guide” bu iş için çok güzel ve anlaşılabilir bir dokümandır. Aynı zamanda yine Secure Vantage firmasının ürettiği ACS Resource Kit içinde gelen “Noise Filter Starting Kit” ile var olan filtreleri inceleyebilir, yeni filtreleri kolaylıkla uygulayabilirsiniz.

ACS Veri Tabanının Optimizasyonu

ACS veritabanındaki veriler günlük olarak SQL partition’larına ayrılır. Her gece 01:00’da çalışan bir görev sonucunda yeni bir partition oluşturulur ve o günün ACS verileri aynı günün partition’una kaydedilir.

Bazı kurumlar, ACS’i kısa dönemli güvenlik olaylarının sorgulanması için kullanırken geçmiş veriler (Örn: Son 1 yılın güvenlik raporları) için 3rd party arşivleme çözümleri kullanmakta. ACS veritabanında geriye doğru sadece ihtiyacınız kadar günkü verileri saklamak performansı arttırıcı tasarım kararları arasındadır.

Bunun için SQL dtconfig tablosundaki “number of partitions” değerini değiştirmek yeterli olacaktır.

ACS Optimizasyonu ve Planlaması hakkında daha detaylı bilgi için aşağıdaki linklerden faydalanabilirsiniz:

• ACS Performance & Scalability Guide
• Security Monitoring and Attack Detection Planning Guide
• ACS Administration : AdtAdmin.exe

Operations Manager 2007 ilk tanıtımlarından bu yana “uçtan uca servis yönetimi” vizyonu ile karşımıza çıkmış bir çözümdür. Elbette, kritik BT servislerinizi uçtan uca yönetmek için çoğu zaman altyapınızdaki Windows sunucuları yönetmekten çok daha fazlasını yapmanız gerekmekte. Örneğin altyapınızdaki network cihazlarını ve non-windows (Unix, Linux vb.) işletim sistemlerini de aynı çatı altında izleyebilmek gerekmekte.

Operations Manager 2007 ile beraber buna getirilen bazı hazır ve ücretli çözümler bulunmaktaydı. Örneğin, non-windows sunucular için, Operations Manager 2007′yi bir Syslog sunucusu gibi gösterip syslog mesajlarını Operations Manager 2007′den yorumlayabiliyordunuz. Veya bir network cihazını SNMP ile ekleyip ilgili SNMP OID’lerini manuel olarak yapılandırarak dinleyebiliyordunuz. Bununla beraber gerçekten etkili bir çözüm için Microsoft iş ortaklarının geliştirdiği ve çoğu ücretli olan Management Pack’leri kullanmanız gerekmekteydi.

Microsoft bu vizyonu bir adım öteye taşıdı. Network cihazlarının yönetilmesi ile ilgili çözümü EMC’nin “SMARTS” çözümünü Operations Manager 2007 R2′ye entegre ederek sunacak (SMARTS konusuna farklı bir yazımda değineceğim). Bunun yanında non-Winodws işletim sistemlerinin (HP-UX, IBM-AIX, Solaris gibi)izlenmesi için “Operations Manager 2007 Cross Platform and Interop Solutions” çözümünü geliştirdi. Bu çözümün beta versiyonunu Microsoft Connect sitesinden indirip deneyebilirsiniz.

Operations Manager 2007′ye yeni eklenecek olan bu özellikler ile beraber network cihazlarınız, non-Windows işletim sistemleri ve bu işletim sistemleri üzerinde koşan uygulamalarınız ile ilgili uyarıları Operations Manager konsolundan görebilecek, uyarılar ile ilgili e-posta, SMS, IM gibi yöntemlerle haberdar olabilecek, Performance View ile performans counter’larını inceleyebilecek, bu cihaz ve işletim sistemlerini Distributed Application’larınıza dahil edebilecek ve raporlarınıza dahil edebileceksiniz.

Microsoft System Center ürün ailesi ile ITIL süreçlerini doküman üzerinde kalan ve uygulanması zor politika ve prosedür olmaktan çıkarıp, uygulanabilir hale getirecek çözümü sunacağını belirtmişti. Çözümün her geçen gün olgunlaştığını, Service Desk yazılımının da gelmesi ile beraber entegrasyonun tamamlanacağını hesaba katarsak Microsoft yakında bu açığı tamamlayacak gibi gözüküyor.