Operations Manager 2007 yedekleme stratejisinin en önemli noktalarından birisi Root Management Server anahtarının başarılı bir şekilde yedeklenmesidir. Özellikle Run As hesaplarında yapılan değişikliklerden sonra bu yedekleme işleminin tekrarlanması önerilir. Bildiğimiz gibi Management Group içerisindeki Run As hesapları bu anahtar içerisinde saklanmaktadır. GUI tabanlı yedekleme dışında komut satırı kullanılarak da hızlıca yedekleme işlemi gerçekleştirilebilir.

C:\Program Files\System Center Operations Manager 2007 > securestoragebackup backup D:\RMSBackup\01-01-2011\Backup.bin

Bu komut satırı sonrasında koruma parolası girilerek işlem tamamlanır.

SCOM 2007 R2 üzerinde Audit Collection Service aktif edildiğinde scom istemcilerinden security loglarını toplamaya başlayabilirsiniz. Ancak bir süre sonra oldukça fazla log oluştuğunu ve bunların arasında bir filtreleme yapamadığınızı fark edebilirsiniz.

Aslında bu noktada Audit Collector’un arka planından biraz bahsetmemiz gerekli. Audit Collector istemcilerden gelen tüm veriyi kuyruğa alıp, filtreleyip ardından ACS veritabanına yazan bileşendir. Arka planda AdtServer isimli bir servis çalıştırır ve %systemroot%\system32\security\Adtserver dizininde exe’si bulunmaktadır.  Bu dizindeki en önemli dosyalardan biri AcsConfig.XML’dir. Bu dosyanın içerisinde audit forwarderların son iletişim tarihleri ve gönderilen event sayıları gibi bilgiler bulunmaktadır.

Yukarıdaki soruna tekrardan gelecek olursak, toplanan Security loglar üzerinde filtreleme gerçekleştirmek yapılması gereken önemli bir adımdır. Çünkü varsayılanda ACS varolan tüm security loglarını hiçbir filtreleme gerçekleştirmeden toplamaktadır. Bu da machine account logon eventları ile birlikte içinden çıkılamaz sayıdaki loglara ulaşmanıza neden olabilir.

Filtreleme uygulamak için adtadmin.exe aracını kullanabilirsiniz. Aşağıdaki örnek filtre, sizin hazırlayacağınız filtreler için güzel bir başlangıç olacaktır.

adtadmin /setquery /collector:"collectorname" /query:"SELECT * FROM AdtsEvent WHERE NOT (((EventId=528 AND String01=’5′) OR (EventId=576 AND (String01=’SeChangeNotifyPrivilege’ OR HeaderDomain=’NT Authority’)) OR (EventId=538 OR EventId=566 OR EventId=672 OR EventId=680)))"

SCOM Gateway sunucusu için kurulumda az bilinen ancak çok faydalı bir parametre bulunuyor.Bu parametre sayesinde Gateway sunucusun yönettiği istemcilerden gelen raporlar management sunucusunda ayrı bir kategorizasyona sokulabilir.

Bildiğiniz gibi;

Microsoft.EnterpriseManagement.gatewayApprovalTool.exe

komut satırı aracının parametrelerini kullanarak Gateway sunucusunu Management Server üzerinde approve edebiliyorsunuz.Bu komut satırında /sitename=DMZBolge şeklinde parametre girdiğiniz takdirde, artık yeni oluşturduğunuz alert viewlerde “from a specific site” seçilerek yalnızca GW sunucusundan gelen istemci alertlerini görüntüleyebilirsiniz.

SCOM üzerine CU3 kurulumu yaptıktan sonra Active Alerts görünümünün boş gelmesi gibi bir problemle karşılaşabilirsiniz.Özellikle scope All Groups olarak işaretli ise bu sorun ortaya çıkıyor.

Bunun sebebi CU3 kurulumundan önce gerekli olan SQL Scriptlerinin çalıştırılmamasıdır.CU3 kurulumu öncesinde aşağıdaki scriptleri Operations Manager veritabanı ve Operations Manager DataWareHouse üzerinde koşturmanız gerekiyor.

“\SQLUpdate\CU3_DataWarehouse.sql”

“\SQLUpdate \CU3_Database.sql”

Bu manuel işlem sonrasında update kurulumunu tüm roller üzerinde gerçekleştirebilirsiniz.

Güncel bir SCOM versiyonunu kullandığınızda, yapınızda bulunan domaine dahil Windows-Based istemcilerden health bilgilerini sağlıklı şekilde almak dışında, un-trusted bir domainde bulunan, workgroup üzerinde çalışan istemcilerin de verilerini toplayabilirsiniz.

Varsayılanda SCOM, ilk kurulan Root Management Server yada daha sonra kurulan Management Server ile istemcilerinden mutual authentication gereksinimi sebebiyle Kerberos Auth ile veri akışını sağlar.İstemciler ve SCOM sunucusu aynı domainde olduğu sürece Kerberos Authentication bu mutual gereksinimi gayet güzel sağlamaktadır.Ancak kimi organizasyonlarda yönetilmesi gereken workgroup istemciler yada DMZ’de bulunan sunucularda SCOM agent’ı ile var olan servis ağacına katılmak istenebilir.

Bu noktada SCOM mimarisi sizden mutual authentication gereksinimini sürdürmektedir.Ancak aynı domain yapısında bulunulmadığı için bu gereksinim ancak certificate-based sağlanabilir.Bu takdirde Management sunucuların ve istemcilerin spesifik sertifikalara sahip olması gerekmektedir.Ancak bu nokta da karşınıza birçok senaryo çıkıyor.Birkaç tanesini inceleyelim.

Yukarıdaki mimaride, corp.local domain yapısında hali hazırda çalışan bir Root Management Server ve Management Server bulunmaktadır.Ancak contoso.local domain’de bulunan istemcilerden de sağlık bilgileri toplanmak isteniyor.Fakat bu iki domain arasında iki yönlü bir trust ilişkisi bulunmuyor.

Bu tip bir senaryoda contoso.local domain ortamına katacağınız bir gateway server ile, sadece gateway sunucusu ve management server sunucusu üzerinde sertifika bazlı authentication’ı aktif ederek iletişim sağlanabilir.

Gateway sunucusu, SCOM rollerinden birisidir.Domaine dahil olması gerekmeyen bu rol, untrusted istemcilerden sağlık bilgilerini toplayıp istenilen management sunucuya gönderir.Ayrıca Management Server’ın istemci datalarında gerçekleştirdiği sıkıştırma oranından daha fazla bir sıkıştırma gerçekleştirmektedir.Bu sebeple bazı senaryolarda, özellikle istemci sayısının fazla olduğu ve kerberos authenticaton’ın kullanılabildiği yapılarda dahi yük dağılımını sağlamak için Management Server yerine tercih edilebilir.

Yukarıdaki senaryoya tekrardan dönersek, görüldüğü gibi contoso.local domain ortamında istemciler ile Gateway sunucusu aynı domainde yer almaktadır.Bu sebeple, istemci-gateway arasında kerberos authentication var olduğundan, yalnızca Gateway ve Management Server arasında sertifika bazlı bir authentication gerçekleştirilmesi yeterli olacaktır.

Bir diğer senaryoda ise , uzak lokasyonda bulunan domain ortamı yalnızca Gateway sunucusunu barındırmakta, yönetilmesi gereken istemciler workgroup yada untrusted bir domain içerisinde bulunmaktadır.Bu yapıda sizin hem Gateway sunucusu ile Management Sunucusu arasında sertifika altyapısını oluşturmanız, hem de istemci-gateway sunucusu arasında sertifika altyapısını oluşturmanız gerekmektedir.

Bir diğer ve sık kullanılan senaryo ise, maliyet kazancı sağlamak amacıyla Gateway sunucusunun kullanılmaması ve istemcilerin tümü ile management sunucuya gerekli sertifikalar yüklenerek gerekli veri akışının sağlanmasıdır.

Bu noktada blogda yazdığım Neden Gateway Sunucusu Kullanmalıyım postundaki kriterleri dikkate almalı ve ona göre bu yapıyı elimine etmelisiniz.Artı taraf ise, Gateway sunucusunun lisanslamada bir Management Server gibi lisanslanması ve bu senaryoda bu maliyetin yok edilmesidir.

SCOM konsolu içerisinde Reporting Server’a bağlanırken kullanılan bağlantıyı SSL kullanması için zorlayabiliriz.Bunun için IIS üzerinde ssl’li web sitesi kullanmak için gerekli olan standart prosedürü kullanabilirsiniz.Yani ortamda online bir CA olmalı ve IIS içerisinde bu online CA’den bir sertifika isteğinde bulunmanız gerekiyor.Bu işlemlerden sonra ise gerekli düzenlemeyi Operations Console altında gerçekleştirmeniz lazım.Bunun için;

- SCOM konsolu altında Administration/Settings bölümünde Reporting‘e sağ tıklayarak Properties‘i seçin.Ardından açılan URL penceresinde https‘i seçip  sondaki :80 port numarasını :443 olarak editlemeniz yeterlidir.

İsterseniz birkaç adımda Operations Manager veritabanının gelen bağlantıları dinlediği port numarasını değiştirebilirsiniz.Bunun için;

- SQL Server Configuration Manager konsolunda SQL Server 2005 Network Configuration bölümünü genişleterek Protocols for kısmına tıklayın.

- Bu kısımda TCP/IP bölümüne sağ tıklayarak özelliklerine girin ve IP Addresses tabına geçin.

Bu bölümde gerekli konfigurasyonları yapabilirsiniz.Kısaca bilgi vermek gerekirse düzenlemeniz gereken alanlar TCP Dynamic Ports bölümleri.Eğer burada “0″ değeri verilmişse dinamik port kullanımı gerçekleşmektedir.Bu değeri silmelisiniz.

Bu değeri sildikten sonra ise IP1 , IP2 ve IPALL için spesifik bir port üzerinden listening işlemini gerçekleştirmek için TCP Port bölümüne istediğiniz port numarasını girebilirsiniz.Varsayılan olarak gördüğünüz gibi bu port 1433′dür.Bu işlemden sonra SQL Server Browser servisini yeniden başlatın.

Aynı ayarı dbo.MT_ManagementGroup tablosunun içerisinde de gerçekleştirmeniz gerekli.Bunun için SQL Server Management Studio içerisinde OperationsManager veritabanını genişletip tabloların altında dbo.MT_ManagementGroup‘a sağ tıklayarak Open Table demelisiniz.Ardından ilk satıra computer\INSTANCE1, port şeklinde giriş yapmanız yeterlidir.Port değeri yukarıda belirttiğiniz port değeri olmalıdır.

Son olarak Root Management Server üzerinde bir ayar yapmanız gerekiyor.Regedit üzerinde
HKEY_LOCAL_MACHINE/ SOFTWARE/Microsoft/Microsoft Operations Manager/3.0/Setup altında DatabaseServerName‘e sağ tıklayarak modify dedikten sonra
“computer_name”\”instance”, “port number”

şeklinde giriş yapabilirsiniz.

Uzun zamandır aşağıdaki gibi bir tablo arıyordum.Eğer yapınızdaki System Center Operations Manager componentleri network üzerinde dağıtık ise,firewall arkasında yada DMZ içerisinde yer alıyorsa  , iletişimin sağlıklı gerçekleşebilmesi için ilgili portların konfigure edilmesi gerekmektedir.SCOM componenti ve kullandığı port bilgisini aşağıdaki tabloda bulabilirsiniz.

Microsoft System Center yönetim ailesi ile ilgilenenler için bir haberim var.

http://www.ms-systemcenter.org/  adresini alarak anilerduran.com üzerindeki System Center kategorisine yönlendirdim.Bu linki kullanarak   blog üzerinde sadece SYSTEM CENTER ailesi ile ilgili yazılara ulaşabilme şansınız var.

Önümüzdeki günlerde System Center Mobile Device Manager ve diğer system center ürünleri ile ilgili makalelere bu link üzerinden ulaşabilirsiniz.

Fallback Status Point hakkında SCCM kategorisinde daha önce konuşmuştuk.FSP konfigurasyonu için ön gereksinimleri ve kurulum sonrası kontrol için log dosyaları dizinlerini aşağıda bulabilirsiniz.

Windows 2003 Gereksinimleri:

• IIS with BITS Server Extensions  

Win2008 Gereksinimleri:

• Web Server (IIS) (Role)
• IIS 6 Management Compatibility – IIS 6 Metabase and IIS 6 WMI Compatibility (Role Services for Web Server)
• BITS Server Extensions (Feature)

Fallback Status Point ile ilgili kurulum kontrolleri için;

Log dosyaları:

• fspmsi.log (SMS_CCM\Logs folder)
• smsfspsetup.log (<InstallationPath>\LOGS folder)

Fallback status point site system log dosyaları:

• fspisapi.log (SMS_CCM\Logs folder)
• fspmgr.log (<InstallationPath>\Logs folder)

 Geçtiğimiz hafta içerisinde

-70-652 TS: Windows Server Virtualization, Configuring
-70-401 TS: Microsoft System Center Configuration Manager 2007, Configuring

 
sertifikasyon sınavlarını tamamladım.Henüz pek popüler olmayan sınavlar.Açıkcası virtualization sınavı zor olur diye beklerken SCCM sınavı biraz daha zorladı diyebilirim.

70-652 içerisinde özellikle SCVMM üzerine oldukça soru vardı.Aynı zamanda Hyper-v mimarisinden de güzel sorular bulunuyor.Fakat en azından konsolu kurcalamış biri için açıkcası pek zorlamayacak bir sınav diyebilirim.
SCCM sınavında ise OSD yani işletim sistemi dağıtımı üzerine fazlaca bir yoğunluk gördüm.Ve sorularda adeta özenle seçilmiş gibilerdi

Güzel olan tarafı system center ailesi sertifikasyonlarında SCCM,SCOM ve SCVMM için TS sertifikası gereksinimleri sadece birer sınav.Birkaç gün içerisinde SCOM ve SCVMM tarafınıda tamamlayıp içerik hakkında girmek isteyen arkadaşlar için bilgilendirme yapacağım.

Windows 2003 ve Windows 2008 için Scheduled Task Management paketi indirilebilir durumda.Bu paketle birlikte zamanlanmış görevleri monitor edebilme şansınız var.Aşağıdaki linkten ulaşabilirsiniz.

Download Windows Scheduled Task Management Pack (sealed) 1.1.0.10