ÇözümPark Bilişim Portalı ve Microsoft Türkiye işbirliği ile sizlere tamamen uygulamalı tam günlük bir uygulamalı seminer ( workshop ) hazırladık.

19 Kasım Cumartesi tam gün olarak düzenlenecek olan seminer programı aşağıdaki gibidir.

09:00 – 10:00 Windows Server 8 Yenilikleri – Mesut ALADAĞ (MVP)

10:00 – 10:15 Çay Kahve Arası

10:15 – 11:15 Geleceği Konuşuyoruz: Windows Server 8 Hyper-V 3.0 – Serhat AKINCI (MVP)

11:15 – 11:30 Çay Kahve Arası

11:30 – 12:30 Geleceği Konuşuyoruz: System Center Virtual Machine Manager 2012 – Serhat AKINCI (MVP)

12:30 – 13:30 Öğle Yemeği

13:30 – 14:30 Windows Server 8 Active Directory Yenilikleri – Hakan UZUNER (MVP)

14:30 – 14:45 Çay Kahve Arası

14:45 – 15:45 System Center Configuration Manager 2012 Yenilikleri – Serkan UZUNER (MCT)

15:45 – 16:00 Çay Kahve Arası

16:00 – 17:00 System Center Data Protection Manager 2012 Yenilikleri – Fatih KARAALİOĞLU (MVP)

17:00 – 17:15 Çay Kahve Arası

17:15 – 18:15 System Center Operation Manager 2012 Yenilikleri – Serkan UZUNER (MCT)

Etkinliğe katılım sınırlı sayıda olacağından lütfen kayıt için info@cozumpark.com mail adresine kaydınızı yaptırın.

Katılım Şartları

Genel anlamda sizlerden herhangi bir şart beklememek ile beraber yüksek bir katılım talebi olduğu için öncelikli üyelerimizin kayıtlarını alacağız. Ayrıca bilgisayar ve danışmanlık firmalarının birden çok personel ile kayıt olmamalarını rica ederiz

http://www.idc-cema.com/?formid=eventreg&prd_id=40685&content_lang=TR

IDC IT Managers Forum 2011 The Smart IT Buyer Conference Tarih: 11 Ekim, 2011 Lokasyon: Ankara, Turkey Yer: Sheraton Hotel & Convention Center   IDC BT Müdürleri Forumu:Bilgi Teknolojilerinde Akılcı Seçimler, Bölgenin iş ve teknoloji alanındaki uzmanları bilgi teknolojilerinde nasıl akılcı seçimler yapılabileceğini tartışmak üzere biraraya geliyor. Sürekli değişen ekonomik koşullarda kurumlar temel yapılarını korumak, müşteri memnuniyetini üst seviyede tutmak ve rekabet avantajı yakalamak için akılcı seçimler yapmak zorundalar. Ne var ki yeni ekonomik gerçeklik harcamaları ve operasyonel masrafları kısmayı zorunlu kılarken işin hemen hemen her alanında büyük bir baskı oluşturmaktadır. Bu durum ise özellikle büyümeyi mümkün kılan operasyonel desteğin verilmesini zorlaştırmaktadır.   IDC, ICT’nin (Bilgi ve İletişim Teknolojilerinin) bilinçli kullanımı ile bu konuda karşılaşılan zorlukların minumuma indirelebileceğini önemle vurgulamaktadır. Bilgi yönetiminden BT dış kaynak kullanımına, iş zekasından sanallaştırmaya, yeşil BT’den VoIP ve tümleşik iletişime kadar bir çok konuda verimliliğin arttırılabileceği, maliyetlerin düşürelebileceği ve karlılığın daha üst seviyelerde tutulabileceği çözümler mevcuttur. Bilgi Teknolojilerinde Akılcı Seçimler için anahtar konular: Gün boyunca devam edecek etkinlikte bölgenin etkin düşünce liderlerinin iş ve teknoloji yöneticileri için önemli olan konularda yapacağı sunumlar aşağıdaki konuları içerecektir; İş ve BT Uyum Sanatı Belirsiz ortamlarda BT Müdürleri ne tür stratejiler uygulamalıdır? Bilgi teknolojileri ROI (yatırım geri dönüşü) ve uyum konularına nasıl odaklanmalılar? (başarı için stratejiler) Operasyonel verimliliği arttırmak, maliyetleri düşürmek, temel yapıyı korumak ve müşteri kaybını önlemek için BT nasıl aktifleştirilmelidir? BT ve İş Uyumunu teşvik eden teknolojiler nelerdir? Yönetilebilir Servisler Şirketiniz için Doğru Çözüm mü? Yönetilebilir Servisler ne demektir? Kuruma ne tür yararlar sağlar? Günümüze uygun mudur? Gelecekte ne tür gelişmeleri beraberinde getirecektir? SOA (Servis odaklı uygulamalar) ve BPM (İş süreç yönetimi): Dirençli Şirketler ve Sektör Bariyerleri SOA (Servis odaklı uygulamalar) ve BPM (İş süreç yönetimi) arasındaki yakınlaşma, yüksek düzeyde planlama ve modellemeden uygulama geliştirmeye geçmek için servis ve ürün sağlayıcılarını mevcut araçlarını genişletmenin yollarını aramaya yöneltmiştir. Kurumlar, sektörün bıraktığı bu yeni nesil ortaklık ve dinamik entegre edilmiş sistemlerin sorumluluğunu almaya hazır mıdır? Kurumlar, yetenek, davranış, yapı veya SOA ve BPM ihtiyaçlarını kapsayan taraflara mı daha yatkındırlar? İş Zekası Devrimi İş Zekası, 2009’da kullanıcılara veri ambarı, raporlama ve veri şeması araçlarını sunmaktan çok işinizi içerden para kazanarak nasıl ivmelendirebileceğinizi anlatan bir felsefeye dönüşmüştür. Bu oturum, temel anahtar sürücüler, kararlar ve İş Zekası çıktıları üzerine bir tartışma başlatmayı amaçlamaktadır. Veri Depolamanın Gelecek Evrimi IDC’nin inancına göre kullanıcı ve uygulamaların veri depolama ile girişeceği ilişki biçimi ve depolama sistemlerinin mimari yapısı yeni bir devrim niteliğindedir. Bu oturum, son kullanıcı taleplerinin sunucu ve depolama arasında nasıl bir ilişkiye neden olduğunun detaylarını anlatmayı amaçlamaktadır. Önceki nesillerin temel olarak veri objelerine odaklanmasının tersine bu durum yeni nesil depolama sistemlerinin gelişimine liderlik etmektedir. Güvenliğin İş Üzerine Etkisi - Bilgi Teknolojilerinde Güvenlik Yatırımlarında Geri Dönüşümün İspatı. -BT Güvenlik Harcamalarının Optimizasyonu. -Güvenlik İhlallerinin Finansal Etkileri -Yönetilebilir Güvenlik Servislerinin İş Avantajları IDC BT Müdürleri Forumu 2011 katılımcıların en iyi uygulamalar  ve en güvenilir teknolojiye dayanan stratejik BT kararlarını tartışabilecekleri geniş kapsamlı, güncel ve güvenilir bir değer sunmaktadır. Etkinliğin hedef kitlesi: -Büyük ve orta ölçekli üretim şirketleri -Sigorta, banka ve finans aracıları -Telekomünikasyon operatörleri -İş alanı ve strateji yöneticileri -E-ticaret ve medya pazarlama yöneticileri -CIO, CTO, CFO, CSO kıdemli yöneticiler Platinum Partner(s)   Platinum Co-Partner   Strategic Partner(s) Gold Partner(s) Technological Partner(s) Exhibition Partner(s) Media Partner(s)

Dil seçiniz Genel Açıklama Genel Bilgiler Sponsorlar Etkinlik Programı For more information about any of our events, please contact Zeynep Genç Conference Manager IDC MEA Turkey Liason Office   Nispetiye Mahallesi,  Cahit Aybar Sokak, Harp Akademileri Sitesi, D Blok Kat: 4 Daire:74  34340  Beşiktaş – İstanbul- Turkey Phone:  +90 212 3560678 Fax:      +90 212 3560286 www.idc-cema.com

Biz IT Birimleri yeniden yapılanma, yeni uygulamalar, mobilite, heterojenlik, dağınık sistemler, dış kaynak kullanımı, güvenlik, performans, bakım anlaşmaları ve en fazla bilinçsiz kullanıcılar gibi etmenlerle mücadele etmek zorundalar. Bu mücadelede bakım maaliyetleri, eksik envanter bilgileri gibi bir çok olumsuz sıkıntılar karşımıza çıkar.

http://www.cozumpark.com/blogs/donanm/archive/2008/11/29/_3101_ntel-vpro-teknolojisi.aspx

Intel Vpro teknolojisi ise Bu sıkıntıları minimize etme konusunda yardımcı oluyor. Bundan önceki makalelerimde vpro teknolojisini, SCS , SMS vs HP OOBM yazılımı ile lanse etmeye çalıştım. Bu makalemde ise system center ailesinden SCCM ile vpro teknolojisini destekleyen desktoplarımızdan nasıl yararlanacağımızdan bahsedeceğim.

Önceki aktivasyon aşamalarını hatırlayacak olursak, Bios a manual müdahele, usb key ile boot etmek gibi işlemleri göstermiştik.

http://www.cozumpark.com/blogs/donanm/archive/2008/11/30/vpro-aktivasyon-provision-manual-amt-konfigurasyonu.aspx

SCCM bunlara ek olarak provision(aktivasyon için kullanılan kelime) etmek için satın alınacak sertifika ile herşeyi arka planda nasıl yaptığını göreceğiz. Bu iş için alınmış private key i olan sertifikamız elimizde var aşamasından başlayacağım.

! Bu sertifika manual olarak internal CA dan üretilebilir ancak internal CA nın thumprint numarasını tüm BIOS lara import etmelisiniz. Unutulmamalıdır ki vpro destekleyen makinalarda verisign, godaddy gibi CA ların thumprint numarası BIOS larında kayıtlı. Dilenirse bununla ilgili özel bilgi verebilirim

Varolan Primary site üzerinde, SCCM SP1 yüklü makinamıza OOB role tanımlaması ile işleme başlıyoruz.

Var olan görevlerine ek olarak; Out Of Band service point role tanımlaması yapıyoruz

Site Settings-Component Configuration-Out Of Band Management özelliklerini yapılandırmamız gerekiyor.

Yapılandırmaya Active Directory içerisinde provison edilecek makinaların object yaratacağı OU, AMT BIOS lar için MEBx password, satın aldığımız sertifikamızı ve makinalarla CA arasındaki ilişki iiçin yaratılmış web server sertifkasını gösteriyoruz.

AMT Settings altında tanımlayacağımız user lar ile vpro makinalar üzerinde hangi yetkileri olacak belirliyoruz.

Componen Configuration- AMT Settings altında web arayüzünün aktif olup olmaması;

http://www.cozumpark.com/blogs/donanm/archive/2008/12/07/_3101_ntel-vpro-web-arayuzunun-acilmasi.aspx

SOL bağlantının yapılıp yapılmaması;

Makinamız kapalı bile olsa ping response verip vermemesi;

eski BIOS lar için WS-MAN kullanarak aktivasyon yapılabilmesi;

http://software.intel.com/en-us/articles/intel-ws-management-translator/

ayarlarını görebiliriz.

Buradaki işlemlerimiz bitti. Şimdi Collection larda AMT Client lara özel bir collection açalım. Query için resimdeki gibi değer yazmamız yeterli olacaktır.

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

Tüm makinalarımız All Systemsiçerisinde yer aldığına göre bu collection içerisinde ufak bir ayar yapalım. Bu ayar sayesinde SCCM collection içerisindeki tüm makinaları sorgulamaya başlayacak ve AMT destekli makinaları oluşturduğumuz AMT Systems collection içerisine atacak.

İşlem başlamadan önceki durumu görelim. Benim sistemimde 3 makina var ve AMT status ları henüz bilinmiyor.

İşlemi biraz hızlandıralım;

Bu işlemi yaptığımızda oluşan logları aşağıdaki linke attım;

http://rapidshare.com/files/390350820/sccmvprologs.rar

Log lardan da takip edeceğiniz gibi makinamız başarılı bir şekilde provision oldu. Artık SCCM üzerinden nasıl yöneteceğimize bakabileceğiz.

Provision olmuş makinamıza sağ tık – OOBM ile;

Discover Management Controllers: Herhangi bir sorun olduğunda yukarıda indirdiğiniz loglardaki tüm işlemlerin tekrar yapılması durumu olacaktır

Power Control: Makinamızın tüm power opsiyonları,

Out of Band Management Console: Tüm işlemleri kendine özel konsoldan yapabilmek için, devamında görebilirsiniz.

Açılan OOBM konsolunda neler yapabildiğimize bakalım;

Resimlerde gördükleriniz vpro teknolojisi ile yapabilklerimizden bazıları. Aslında SCCM in yapabildiklerine ek olarak yardımcı özellikler getirmiştir. Dilediğimiz zamanda makinaları açıp, FIX geçip, sonra tüm makinalarımızı kapatabiliriz. Genel amaç masabaşı ziyaretleri minimize etmek, zamandan ve maliyetten kazançtır.

Bir önceki makalede sizlerle SCCM query’ leri ile çalılma konusunda bir takım bilgiler vermeye çalışmıştım. Önceki makalede ağırlıklı olarak collection’ lar üzerinde durmuştuk. Yine query’ lerle çalışmaya devam edeceğim ancak bu sefer DCM ve Reporting kısımlarında da bir takım işler yapacağız ve bir parça troubleshooting yapacağız.

Bu makalede anlatacağım konular aslında bir ihtiyaçtan dolayı yapılmış çalışmaların özetidir. Muhtemelen böyle bir ihtiyaç birçok sistem yöneticisi için söz konusu olmuştur. İhtiyacımız şu idi; yine bir denetim döneminde tüm server’ ların lokal gruplarının üyeliklerini listelememiz gerekti. Bu liste üzerinden yapılacak kontrol ile gereksiz ve yetkisiz olarak yetkilendirilmiş tüm user ve grupları görebilecek ve gerekli düzenlemeyi yapabilecektik. Ve bunu bilgiyi/raporu SCCM üzerinden almak istedik.

SCCM’ in kurulum ile beraber gelen raporlarına göz attık ve işimizi görecek hazır bir rapor bulamadık.

Hatta yeni bir rapor oluşturup query ile istediğimiz veriye ulaşmaya da çalıştık, ancak durum beklediğimizden de farklı idi. SCCM’in agent’lardan topladığı veri içerisinde bizim istediğimiz veriler bulunmamakta idi. Bildiğiniz gibi SCCM ağırlıklı olarak hardware ve software bilgilerini toplamaktadır.

Biraz araştırma yaptık, bir arkadaşımızın tecrübesinden yararlandık ve aşağıdaki link üzerinden yola çıktık;

http://myitforum.com/cs2/blogs/skissinger/archive/2010/04/25/report-on-all-members-of-all-local-groups.aspx

(Hakan UZUNER’ e teşekkürler)

Aslında bundan sonra anlatacaklarım link’ te bulunan bilgilerdir. Adım adım devam edersek ilk olarak Desired Configuration Management bölümünde bir tane configuration item oluşturacağız;

İlk ekranda bir isim belirliyoruz ve devam ediyoruz,

Herhangi bir object eklemeden devam ediyoruz,

Settings bölümünde bir script ekleyeceğiz,

Açılan pencerede script için bir isim giriyoruz, aşağıda linkini ve açık halde kodunu verdiğim script kodunuda script kısmına kopyalıyoruz.

http://myitforum.com/cs2/blogs/skissinger/LocalGroupMembersScriptDCMCITest.txt

on error resume next

‘Steps

‘enumerate from win32_group where localaccount=1

‘Read in the members of each local group returned

‘Add the returned information to a custom WMI namespace

‘sms-def.mof to pull that back.

Set fso = CreateObject(“Scripting.FileSystemObject“)

Set nwo = CreateObject(“Wscript.Network“)

Set sho = CreateObject(“Wscript.Shell“)

TempFolder = sho.ExpandEnvironmentStrings(“%temp%”)

strWindir = sho.ExpandEnvironmentStrings(“%windir%”)

strComputer = nwo.ComputerName

Dim wbemCimtypeSint16

Dim wbemCimtypeSint32

Dim wbemCimtypeReal32

Dim wbemCimtypeReal64

Dim wbemCimtypeString

Dim wbemCimtypeBoolean

Dim wbemCimtypeObject

Dim wbemCimtypeSint8

Dim wbemCimtypeUint8

Dim wbemCimtypeUint16

Dim wbemCimtypeUint32

Dim wbemCimtypeSint64

Dim wbemCimtypeUint64

Dim wbemCimtypeDateTime

Dim wbemCimtypeReference

Dim wbemCimtypeChar16

wbemCimtypeSint16 = 2

wbemCimtypeSint32 = 3

wbemCimtypeReal32 = 4

wbemCimtypeReal64 = 5

wbemCimtypeString = 8

wbemCimtypeBoolean = 11

wbemCimtypeObject = 13

wbemCimtypeSint8 = 16

wbemCimtypeUint8 = 17

wbemCimtypeUint16 = 18

wbemCimtypeUint32 = 19

wbemCimtypeSint64 = 20

wbemCimtypeUint64 = 21

wbemCimtypeDateTime = 101

wbemCimtypeReference = 102

wbemCimtypeChar16 = 103

‘ Remove classes

Set oLocation = CreateObject(“WbemScripting.SWbemLocator“)

‘===================

‘If this is a Domain Controller, bail!

‘===================

Set oWMI = GetObject(“winmgmts:” _

& “{impersonationLevel=impersonate}!\\.\root\cimv2″)

Set colComputer = oWMI.ExecQuery _

(“Select DomainRole from Win32_ComputerSystem”)

For Each oComputer in colComputer

 if (oComputer.DomainRole = 4 or oComputer.DomainRole = 5) then

   wscript.echo “DomainController, So I’m quitting!”

   ‘wscript.quit

Else

‘==================

‘If it is NOT a domain controller, then continue gathering info

‘and stuff it into WMI for later easy retrieval

‘==================

Set oServices = oLocation.ConnectServer(,”root\cimv2″)

set oNewObject = oServices.Get(“CM_LocalGroupMembers“)

oNewObject.Delete_

‘==================

‘Get the local Group Names

‘==================

Dim iGroups(300)

i=0

Set objWMIService = GetObject(“winmgmts:” _

        & “{impersonationLevel=impersonate}!\\.\root\cimv2″)

Set colGroup = objWMIService.ExecQuery(“select * from win32_group where localaccount=1″)

for each obj in colGroup

  igroups(i)=obj.Name

  i=i+1

next

‘===============

‘Get all of the names within each group

dim strLocal(300)

k=0

Set oLocation = CreateObject(“WbemScripting.SWbemLocator“)

Set oServices = oLocation.ConnectServer(, “root\cimv2″ )

‘group name, domain name, user or group

for j = 0 to i-1

squery = “select partcomponent from win32_groupuser where groupcomponent = “”\\\\” &_

 strComputer & “\\root\\cimv2:Win32_Group.Domain=\”"” & strComputer &_

“\”",Name=\”"” &igroups(j) & “\”"”"”

Set oInstances = oServices.ExecQuery(sQuery)

FOR EACH oObject in oInstances

  strLocal(k)=igroups(j) & “!” & oObject.PartComponent

  k=k+1

Next

next

‘==================

‘Drop that into a custom wmi Namespace

‘==================

‘ Create data class structure

Set oDataObject = oServices.Get

oDataObject.Path_.Class = “CM_LocalGroupMembers”

oDataObject.Properties_.add “Account” , wbemCimtypeString

oDataObject.Properties_(“Account”).Qualifiers_.add “key” , True

oDataObject.Properties_.add “Domain” , wbemCimtypeString

oDataObject.Properties_.add “Category” , wbemCimtypeString

oDataObject.Properties_.add “Type” , wbemCimtypeString

oDataObject.Properties_.add “Name” , wbemCimtypeString

oDataObject.Properties_(“Name”).Qualifiers_.add “key” , True

oDataObject.Put_

for m = 0 to k-1

Set oNewObject = oServices.Get(“CM_LocalGroupMembers” ).SpawnInstance_

str0 = Split(strLocal(m), “!”, -1, 1)

str1 = Split(str0(1), “,” , -1, 1)

str2 = Split(str1(0), “\” , -1, 1)

str4 = Split(str2(4), Chr(34), -1, 1)

‘ The Account name or Group Name is inside the quotes after the comma

str3 = Split(str1(1), Chr(34), -1, 1)

‘ if the wmi source name is the same as the domain name inside the quotes, it’ s a local account

‘ str2(2) is the wmi source name, str4(1) is the domain name inside the quotes.

If lcase(str2(2)) = lcase(str4(1)) Then

oNewObject.Type = “Local”

Else

oNewObject.Type = “Domain”

End If

oNewObject.Domain = str4(1)

oNewObject.Account = str3(1)

oNewObject.Name = str0(0)

Select Case lcase(str4(0))

  case “cimv2:win32_useraccount.domain=”

   oNewObject.Category = “UserAccount“

  Case “cimv2:win32_group.domain=”

   oNewObject.Category = “Group”

  Case “cimv2:win32_systemaccount.domain=”

   oNewObject.Category = “SystemAccount“

  case else

   oNewObject.Category = “unknown“

end select

oNewObject.Put_

Next

wscript.echo “ok”

 end if

Next

wscript.quit

Aynı pencerenin validation tabındaki ayarlarda resimdeki gibi olmalı,

Sonraki pencerede All Windows platforms olarak bıraktık, diğer pencereleri next ile geçerek bitiriyoruz. Configuration item yaratılmış oldu. Sonraki adım olarak bir DCM Baseline yaratmamız gerekli, eğer halihazırda kullandığınız bir Baseline var ise yapacağımız işlemlei onun üzerinde de yapabilirsiniz. Ben olmadığını farederek devam ediyorum;

Yine bir isim vererek devam ediyoruz, ben CI ile aynı ismi vermeyi tercih ettim,

“These applications and general configuration items are required and must be properly configured” kısmını tıklayarak oluşturduğumuz CI’ I seçiyoruz,

Sonraki ekranları next ile geçip işlemi tamamlıyoruz.

Baseline’ ıda oluşturduktan sonra sms_def.mof file’ ı notepad ile açıp dosyanın en sonuna aşağıda görülen mof pasajını eklememiz gerekiyor. Ancak bu işlemi yapmadan evvel mof dosyasının bir yedeğini almanız tavsiye edilir, çünkü mof dosyası tüm envanter bilgilerinin alındığı dosyadır.

//=====================Local Group Members, Includes Administrators
//Pre-requisite: recurring Advertisement, or Recurring DCM Baseline/CI
//====================================================================
#pragma deleteclass (“LocalGroupMembers“,NOFAIL)
[ SMS_Report     (TRUE),
  SMS_Group_Name ("LocalGroupMembers"),
  SMS_Class_ID   ("CUSTOM|LocalGroupMembers|1.0") ]
class cm_LocalGroupMembers : SMS_Class_Template
{
    [SMS_Report (TRUE), key ] string Account;
    [SMS_Report (TRUE)      ] string Category;
    [SMS_Report (TRUE)      ] string Domain;
    [SMS_Report (TRUE), key ] string Name;
    [SMS_Report (TRUE)      ] string Type;
};

Sonrasında bu dosyayı command promt’ fa compile etmemiz gerekiyor, bunun için ilgili klasöre gidip (dosyanın bulunduğu klasör) ve mofcomp komutu ile compile edilir.

Burada belirtmek istediğim bir kısım var, oluşturduğumuz baseline’ ın hangi collection için uygulanacağı ve schedule ayarı. Benim amacım sunucuların lokal gruplarındaki üyelikleri öğrenmek idi, bu yüzden tüm windows sunuculara uyguladım.

Oluşturduğumuz basline’ ın server’ larda uygulanıp uygulanmadığını Comtrol Panel içerisinde Configuration Manager içerisinde resimde gösterdiğim alandan kontrol edebilirsiniz. Bizim baseline’ ımız sunucuya ulaşmış ve compliant durumda.

Şu ana kadar yaptığımız işlemler ile sunucuların lokal grupları ile ilgili bir takım bilgileri SCCM database’ i içerisine almış olduk. Bundan sonra yapacağımız işlem Reporting altında custom report oluşturmak olacak. Böylece hedeflediğimiz veriyi tek bir rapor altında toplamış olacağız.

Bu işlem için Reporting>Reports altında yeni rapor oluşturmaya başlarız,

Rapora anlamlı bir isim verdikten sonra bir kategori seçeriz, yine anlamlı olmasında fayda var, bu rapor kullanıcılar ile alakalı bir sonuç döndüreceğinden ben Users kategorisini seçtim. Sonrasında Edit SQL statement kısmına tıklıyoruz,

Açılan pencerede aşağıda açık halini verdiğim query’ yi SQL Statement kısmına kopyalıyoruz.

declare @olddcm datetime

declare @oldhinv datetime

set @oldDCM=DATEADD(DAY,-3, getdate())

set @oldHinv=DATEADD(DAY,-3, getdate())

select sys1.netbios_name0

,lgm.name0 [Name of the local Group]

,lgm.account0 as [Account Contained within the Group]

, lgm.category0 [Account Type]

, lgm.domain0 [Domain for Account]

, lgm.type0 [Type of Account]

, case when ws.lasthwscan < @oldhinv then ‘Last Hinv might be out of date‘

 when cs.lastcompliancemessagetime < @olddcm then ‘CI evaluation might be out of date‘

 when ws.lasthwscan < cs.lastcompliancemessagetime then ‘CI evaluated since hinv, not necessarily unreliable‘

  else ‘Recent CI Eval, Hinv since CI Eval = Fairly Reliable‘

end as [Reliability of Information]

from

v_GS_localgroupmembers0 lgm

join v_GS_WORKSTATION_STATUS ws on ws.ResourceID=lgm.ResourceID

join v_R_System_Valid sys1 on sys1.ResourceID=lgm.ResourceID

left join v_CICurrentComplianceStatus cs on cs.ResourceID=lgm.ResourceID

left join v_LocalizedCIProperties_SiteLoc loc on loc.CI_ID=cs.CI_ID

where loc.DisplayName = ‘Local Group Members‘

order by sys1.netbios_name0, lgm.name0, lgm.account0

Yukarıdaki query kısmında bazı yerleri yeşil ile işaretledim, bu kısımlar ben daha evvel raporu oluştururken karşılaştığım problemlerden biri idi, case sensitive problemi, raporu çalıştırdığınız zaman aşağıda gördüğünüz hata geri dönmekteydi. Ben sıra ile yukarıdaki pencerede gördüğünüz views ve columns kısımlarını kontrol ederek database üzerindeki ile birebir aynı yaptım. Bir de yukarıda gördüğünüz gibi sarı ile işaretli bir alan daha var, buradaki kısım sizin baseline’ a verdiğiniz isim olmalı, boşluk dahil herhangi bir karakter farklı olur ise rapor hiçbirşey döndürmeyecektir.

Artık raporumuzu çalıştırıp dönen sonuca bakalım,

Evet sunuculardaki lokal gruplara üye tüm lokal kullanıcı, domain kullanıcısı, lokal grup veya domain grubu bilgilerini elde ettik. Bu raporu export butonuna basarak csv file olarak export edebiliriz. Csv file’ ıda excel ile birlikte açıp text to file işlemine tabi tutup, virgüllerle ayrılmış veriyi kolonlara dağıtarak üzerinde filter çalışması yapabiliriz. Buradanda yetkili olmaması gereken kullanıcıları kolaylıkla tespit edebiliriz.

Yukarıda rapor oluşturmak için kullandığımız query;

declare @olddcm datetime

declare @oldhinv datetime

set @oldDCM=DATEADD(DAY,-3, getdate())

set @oldHinv=DATEADD(DAY,-3, getdate())

select sys1.netbios_name0

,lgm.name0 [Name of the local Group]

,lgm.account0 as [Account Contained within the Group]

, lgm.category0 [Account Type]

, lgm.domain0 [Domain for Account]

, lgm.type0 [Type of Account]

, case when ws.lasthwscan < @oldhinv then ‘Last Hinv might be out of date‘

 when cs.lastcompliancemessagetime < @olddcm then ‘CI evaluation might be out of date‘

 when ws.lasthwscan < cs.lastcompliancemessagetime then ‘CI evaluated since hinv, not necessarily unreliable‘

  else ‘Recent CI Eval, Hinv since CI Eval = Fairly Reliable‘

end as [Reliability of Information]

from

v_gs_localgroupmembers0 lgm

join v_GS_WORKSTATION_STATUS ws on ws.ResourceID=lgm.ResourceID

join v_R_System_Valid sys1 on sys1.ResourceID=lgm.ResourceID

left join v_CICurrentComplianceStatus cs on cs.ResourceID=lgm.ResourceID

left join v_LocalizedCIProperties_SiteLoc loc on loc.CI_ID=cs.CI_ID

where loc.displayname = ‘Local Group Members‘

and lgm.type0 = ‘local‘

and lgm.category0 = ‘userAccount‘

and lgm.account0 not in (‘Administrator’,'Guest‘)

order by sys1.netbios_name0, lgm.name0, lgm.account0

Bu query kullanılarak oluşturulan rapor ise yukarıdaki çıktıyı vermektedir. Diğeri ile arasındaki fark bu raporda domain kullanıcıları ve grupları listede bulunmuyor. Genellikle ilk rapor daha kapsamlı veri içerdiği için tercih edilecektir. Ancak sisteminizde yüzlerce sunucu varsa, bunların içerisindeki tüm lokal gruplara üye tüm objeler için liste uzadıkça uzuyor ve 10000 satırın üzerinde veri geri dönecektir. Bu durumda da benim yaşadığım gibi raporun çalışması ile ilgili sorun yaşayacaksınızdır. Rapor bazen çalışacak ve görüntülenecek bazende görüntülenemeyecektir. Bu sorunun 2 nedeni olabiliyor, birincisi satır sayısı ikincisi ise sunucuda o andaki utilization. SCCM’ de görüntülenebilecek maximum satır ayarı yok ancak aşağıda verdiğim link uygulanırsa satır problemi yaşamayacaksınızdır;

http://scug.be/blogs/sccm/archive/2009/09/30/sccm-2007-reporting-how-to-change-the-maximum-rows-returned-in-the-values-list-that-is-default-set-to-1000-rows.aspx

Yapmanız gereken çok basit bir işlemdir. Registry açılır ve ilgili alan altında bir DWORD yaratılıp değerini istediğiniz gibi atamak.

Ve son bir troubleshooting bilgisi daha verelim. Sistem yöneticisi sizsiniz ve tabiki sisteminizdeki sunucuları biliyorsunuz. Ama fark ettiniz ki rapor içerisinde bazı sunucularınız yok, listede bulamadınız.

Derdini anlatan sistemler her zaman işimizi kolaylaştırmıştır. Yine SCCM içerisinde system status bölümündeki status message queries kısmında geliyoruz,

Tüm durum mesajlarını görüntüleyelim,

Ben 1 haftalık veriyi getirmesini istedim,

Gelen birçok veri içerisinden bizimle alakalı olanı çıkarmak için veriyi filtreliyoruz ve Desired Configuration Management ile ilgili veriyi süzüyoruz.

Listede göremediğimiz bir takım makineler ile ilgili hata alanlar olduğunu görüyoruz, bir tanesinin detayına baktığımız zaman sunucu üzerinde .Net Framework’ un kurulu olmadığını söylüyor bize. Bu bağımlılıktan dolayı DCM işini düzgün yapamıyor.

Toplamda kaç makinede .Net kurulumu olmadığını yine SCCM query’ leri ile çalışarak tespit edebilirsiniz. İlk makalemizde sizinle paylaştığım bilgileri kullanarak custom bir collection oluşturabilirsiniz. Query statement kısmına da aşağıdaki query’ yi yazabilirsiniz.

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_COMPUTER_SYSTEM on SMS_G_System_COMPUTER_SYSTEM.ResourceID = SMS_R_System.ResourceId where SMS_G_System_COMPUTER_SYSTEM.Name not in (select distinct SMS_G_System_COMPUTER_SYSTEM.Name from SMS_R_System inner join SMS_G_System_COMPUTER_SYSTEM on SMS_G_System_COMPUTER_SYSTEM.ResourceID = SMS_R_System.ResourceId inner join SMS_G_System_ADD_REMOVE_PROGRAMS on SMS_G_System_ADD_REMOVE_PROGRAMS.ResourceID = SMS_R_System.ResourceId where SMS_G_System_ADD_REMOVE_PROGRAMS.DisplayName like “%NET Framework%”)

Saygılar.

System Center ürün ailesi hayatımıza iyice yerleşmiş durumda. İçlerinden en çok kullanılan şüphesiz SCCM. Bunun da nedeni ürünün oldukça geniş kabiliyetleri olması. Bu ürün ile software deployment, patch management, operating system deployment ve hatta app-v ile entegrasyonu sayesinde (R2 ile birlikte gelen bir özellik) sanal uygulamaların dağıtımını SCCM yapımızın üzerinden gerçekleştirebiliyoruz. Ürünün kabiliyetleri bunlarla da sınırlı değil, hardware ve software ile ilgili asset management ve reporting kısmında çok detaylı raporlama yapılabiliyor. Desired Configuration Mamagement modülü ise bize standartlarımızı koruyabilecek imkânlar sunuyor. 

Bugün benim bahsetmek istediğim konu SCCM üzerinde query’ ler ile çalışmak olacak. SCCM, SQL veritabanını kullanmakta ve her türlü bilgiyi burada tutmaktadır ve SQL veritabanı üzerinde çok yoğun transaction gerçekleştirmektedir. SCCM yönetiminde mutlaka ihtiyacınız olacak kısımlardan biri collections kısmıdır. Bu kısımda kurulum ile birlikte gelen bir takım collection’ lar vardır.

Collection’ lar sizin makine parkurunuzdaki makineleri belirli özelliklerine göre ayrımanızı ve gruplamanızı sağlayan yapılardır. Bu gruplama işletim sistemi bazında olabilir, service pack seviyesinde olabilir, bilgisayarlar üzerine kurulu bir program baz alınarak yapılabileceği gibi kurulu olmayan bir programı sorgulayarak ta bir collection yaratılabilir. Bu collection’ lara göre de SCCM’ in ürün özelliklerini yönetiriz. Örneğin, yama yönetimimizi bu gruplara göre, software deployment’ ı yine bu grupları kullanarak yaparız.

Collection’ lar temelde 2 tip metod ile yaratılırlar. Birisi Direct metod, diğeri ise Query metodu ile. Direct metod statik bir gruplama yöntemidir. Collection’ı oluşturur ve istediğiniz makineleri bu collection’ a eklersiniz. Bu tip bir collection genellikle yama yönetiminde test grupları oluşturmak için kullanılır. Yani bir yamayı genele, tüm makine parkuruna uygulamadan evvel direct metod ile oluşturduğuğumuz bu collection’ lara uygulayarak test etmek amacı ile. Yine bu metodu query ile bir araya toplayamadığımız makineleri herhangi bir amaç için bir araya getirmek için kullanırız. Benim bahsetmek istediğim query ile bir collection nasıl oluşturulur kısmı olacak.

Query ile oluşturulan collection’ lar dynamic bir yapıda olurlar. Yani sizin girdiğiniz kriterlere uygun makineler bu collection’ lar içerisine otomatik olarak eklenir ve durumları değiştiğinde otomatik olarak çıkarlar. Bunun nedeni ise SCCM agent’ ları client bilgilerini database’ e ilk kez yaparken insert sonraki dönemlerde ise update mantığı ile eklerler. Yani siz bir query hazırladınız ve bu query size Windows Server 2003 ve Service Pack seviyesi SP1 olan makineleri getiriyor. Bu makinelerin içerisinde bir makinenin service pack seviyesi SP2 olduğunda bu listeden otomatik olarak çıkacaktır ve SP2 ile ilgili bir query ( yani collection) hazırlanmış ise o listeye girecektir.

Best practice olarak size default gelen query’ leri değiştirmek yerine, açacağınız bir collection altında kendi collection’ larınızı oluşturmanızı tavsiye edebilirim. Ben genelde bu collection grubuna “Custom Collections” ismini veririm.

Bu işlemi collections üzerinde new collection diyerek yapıyoruz,

“Membership Rules” penceresinde şu anda herhangi bir query oluşturmayacağım çünkü bu collection’ ı kendi oluşturacağım collection’ lar için bir bir store alanı gibi kullanacağım. Bu collection’ ı bir OU gibi düşünebilirsiniz.

Burada belirtmek istediğim önemli bir nokta var, “Dynamically add new resources” kısmını query metodu ile oluşturacağınız her collection için mutlaka işaretlemenizi tavsiye ederim. Bu collection için bir önemi yok ancak query ekleyeceğimiz collection’ larda önem arzetmekte.

Diğer tüm ekranları next ile geçip işlemi tamamlayabiliriz. Oluşturduğumuz collection’ ın listeye girdiğini göreceksiniz.

Bundan sonra oluşturacağınız tüm collection’ ları bu collection üzerine sağ tıklayıp yine new>collection şeklinde oluşturursak kendi oluşturduğumuz collection’ ları bir araya toplamış oluruz.

Şimdi bu yolla bir tane custom collection oluşturalım. Bu collection da bize tüm XP işletim sistemi kurulu makineleri getirsin.

İlk pencerede Collection’ a bir isim veririz ve devam ederiz;

Sonraki pencerede “Dynamically add new resources” kısmını işaretleyip query butonuna basarız;

Açılan pencerede query içinde bir isim veriyoruz, genelde collection ile aynı vermeniz önerilir, sonra “Edit query statement” kısmını tıklarız;

Query penceresinde query oluşturmak için 2 seçeneğimiz var, birincisi ve pratik olanı, internet’ ten kolayca bulabileceğimiz query cümleciklerini “show query language” kısmına girip copy-paste şeklinde yapıştırmaktır;

Ben google’ da “SCCM query statement for all XP operating systems” şeklinde bir arama yaptım ve aşağıdaki sorguyu temin ettim;

Select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from sms_r_system where OperatingSystemNameandVersion like ‘%Workstation 5.1%’

Sizde ihtiyacınız olan ne ise aradığınızda kolayca bulabileceksinizdir. Hatta öyleki SCCM query deposuna dönmüş bazı siteler dahi bulacaksınızdır.

Bulduğumuz sorguyu açılan pencereye kopyalayarak okey’ leyebiliriz.

Bundan sonraki pencereleri onaylayarak işlemi tamamlayabilirsiniz.

Oluşturduğumuz collection’ ı seçtiğinşz zaman makine parkurunuzdaki XP işletim sistemine sahip makineleri sağ tarafta liste halinde göreceksiniz;

Farzedelimki bize XP işletim sistemleri içerisinde sadece SP2 yüklü makineler lazım olsun. Şimdi bir örnek daha yapalım bu sefer query’yi oluşturduğumuz pencere içerisinde manuel olarak ta bir takım düzenlemeler yapalım.

Yine custom collections’ lar altında new collection ile işe başlıyoruz ve oluşturacağımız yeni collection’ a bir isim veriyoruz;

Yine aynı sıra ile devam ederek “edit query statement” kısmına giriyoruz;

Query’ mizi yine XP makineler ile ilgili şekillendireceğimiz için az önceki hazır query’ yi ekleyerek okeyliyorum ve bir önceki pencereye dönüyorum.

Bir önceki pencerede tekrar “Edit query statement” kısmını tıkladığımızda az önce kopyaladığımız SQL cümleceği ile ilgili olarak generel kısmında ve criteria kısmında bir takım bilgileri göreceğiz. Burada criteria kısmına geçiyoruz ve mevcut kriterlere service pack seviyesi ile ilgili bir kriter daha ekleyeceğiz;

Criteria kısmında mevcut kritere yeni kriter eklemek için aşağıda gösterilen butona tıklıyoruz ve sağ taraftaki pencere açılıyor;

Where kısmı ile sorgulayacağımız değerin yerini gösteriyoruz ve okeyliyoruz;

Sonrada sorgulayacağımız değeri seçip okeyliyoruz. Böylece mevcut kritere bir kriter daha eklemiş oluyoruz.

Burada dikkat etmemiz gereken kısım kriterin hangi operator ile eklendiği, burada aşağıda görüldüğü gibi “and” operatörü ile eklendi. Duruma göre bunu değiştirebiliriz. Yapmamız gereken üzerine tıklayıp operatör butonuna basmak. Bazı durumlarda or operatörüne de ihtiyaç duyabilirsiniz. Mesela bir bilgisayarda Add/Remove programs altında kurulu bir programı display name değeriyle sorgulamak istiyorsunuz ama bilgisayarlar üzerinde programın farklı versiyonları kurulu ve display name’ ide farklı, hepsini listelemek için or operatörü ile faklı isimlerden herhangi birini içeren tüm bilgisayarları listelemek için kullanılır.

Genelde office programlarını sorgulamak için kullanırız, çünkü office programlarının enterprise, standard gibi farklı versiyonları farklı display name’ lere sahiptir. Sorguda kullanılacak bir yöntemde karakter kullanmaktır. Örneğin value kısmına %Microsoft Office% değerini girersek girdiğimiz değerin başında ve sonunda ne olursa olsun farketmez anlamına gelecektir.

Son bir detay da collection limiting kısmıdır. Burası bu sorgunun çalışacağı alanı daraltmak için kullanılır. Örneğin biz XP SP2 sistemleri bu alanı kullanarak sadece tüm XP sistemleri içerisinden sorgulatabiliriz. Buda gereksiz utilization’ ı engeller. XP SP2 sistemleri bulmasını beklediğimiz bir sorguyu 2008 server’ larda da çalıştırmak mantıksız olacaktır. Bu kısım sonucu değil performansı etkileyecektir.

Yine geri kalan tüm pencereleri onaylayarak kapatıp işlemi tamamlıyoruz.

Yeni oluşturduğumuz collection’ ı seçtiğimizde yine sağ tarafta ilgili makineleri görüyoruz;

Bu veriyi de yama yönetiminde kullanarak bu makinelere SP3 yüklemesi yapabiliriz.

Şimdi ben daha evvel hazırladığım bazı query’ leri aşağıda sizinle paylaşmak isterim (aramakla uğraşmayalım);

All Windows 2000 Systems

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from sms_r_system where OperatingSystemNameandVersion like ‘%Workstation 5.0%’

All Windows XP Systems

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from sms_r_system where OperatingSystemNameandVersion like ‘%Workstation 5.1%’

All Windows XP 64 Bit Systems

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from sms_r_system where OperatingSystemNameandVersion like ‘%Workstation 5.2%’

All Windows Vista Systems

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from sms_r_system where OperatingSystemNameandVersion like ‘%Workstation 6.0%’

All Windows 7 Systems

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System where SMS_R_System.OperatingSystemNameandVersion like “Microsoft Windows NT Workstation 6.1″

All Windows 2000 Server Systems

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from sms_r_system where OperatingSystemNameandVersion like ‘%Server 5.0%’

All Windows 2003 Server Systems

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from sms_r_system where OperatingSystemNameandVersion like ‘%Server 5.2%’

All Windows 2008 Server Systems

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from sms_r_system where OperatingSystemNameandVersion like ‘%Server 6%’

All Windows 2008 Server R2 Systems

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from sms_r_system where OperatingSystemNameandVersion like ‘%Server 6.1%’

SQL Server 2005 Installed

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_INSTALLED_SOFTWARE on SMS_G_System_INSTALLED_SOFTWARE.ResourceID = SMS_R_System.ResourceId where SMS_G_System_INSTALLED_SOFTWARE.ProductName like “%SQL Server 2005%”

SQL Server 2008 Installed

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_INSTALLED_SOFTWARE on SMS_G_System_INSTALLED_SOFTWARE.ResourceId = SMS_R_System.ResourceId where SMS_G_System_INSTALLED_SOFTWARE.ProductName like “%SQL Server 2008%”

All Windows XP SP 3 Systems (There are 2 alternatives)

select distinct SMS_R_System.Name, SMS_G_System_OPERATING_SYSTEM.Caption, SMS_G_System_OPERATING_SYSTEM.CSDVersion from  SMS_R_System inner join SMS_G_System_OPERATING_SYSTEM on SMS_G_System_OPERATING_SYSTEM.ResourceID = SMS_R_System.ResourceId where SMS_G_System_OPERATING_SYSTEM.Caption like “Microsoft Windows XP%” and SMS_G_System_OPERATING_SYSTEM.CSDVersion = “Service Pack 3″

select SMS_R_SYSTEM.ResourceID, SMS_R_SYSTEM.ResourceType, SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier, SMS_R_SYSTEM.ResourceDomainORWorkgroup, SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_OPERATING_SYSTEM on SMS_G_System_OPERATING_SYSTEM.ResourceID = SMS_R_System.ResourceId where SMS_G_System_OPERATING_SYSTEM.Caption like “%Windows XP%” and SMS_G_System_OPERATING_SYSTEM.CSDVersion = “Service Pack 3″

All Windows XP SP 2 Systems (There are 2 alternatives)

select distinct SMS_R_System.Name, SMS_G_System_OPERATING_SYSTEM.Caption, SMS_G_System_OPERATING_SYSTEM.CSDVersion from  SMS_R_System inner join SMS_G_System_OPERATING_SYSTEM on SMS_G_System_OPERATING_SYSTEM.ResourceID = SMS_R_System.ResourceId where SMS_G_System_OPERATING_SYSTEM.Caption like “Microsoft Windows XP%” and SMS_G_System_OPERATING_SYSTEM.CSDVersion = “Service Pack 2″

select SMS_R_SYSTEM.ResourceID, SMS_R_SYSTEM.ResourceType, SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier, SMS_R_SYSTEM.ResourceDomainORWorkgroup, SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_OPERATING_SYSTEM on SMS_G_System_OPERATING_SYSTEM.ResourceID = SMS_R_System.ResourceId where SMS_G_System_OPERATING_SYSTEM.Caption like “%Windows XP%” and SMS_G_System_OPERATING_SYSTEM.CSDVersion = “Service Pack 2″

All Windows XP SP 1 Systems (There are 2 alternatives)

select distinct SMS_R_System.Name, SMS_G_System_OPERATING_SYSTEM.Caption, SMS_G_System_OPERATING_SYSTEM.CSDVersion from  SMS_R_System inner join SMS_G_System_OPERATING_SYSTEM on SMS_G_System_OPERATING_SYSTEM.ResourceID = SMS_R_System.ResourceId where SMS_G_System_OPERATING_SYSTEM.Caption like “Microsoft Windows XP%” and SMS_G_System_OPERATING_SYSTEM.CSDVersion = “Service Pack 1″

select SMS_R_SYSTEM.ResourceID, SMS_R_SYSTEM.ResourceType, SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier, SMS_R_SYSTEM.ResourceDomainORWorkgroup, SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_OPERATING_SYSTEM on SMS_G_System_OPERATING_SYSTEM.ResourceID = SMS_R_System.ResourceId where SMS_G_System_OPERATING_SYSTEM.Caption like “%Windows XP%” and SMS_G_System_OPERATING_SYSTEM.CSDVersion = “Service Pack 1″

X bir software‘ ün kurulu olmadığı sistemleri listeler (Örnek olarak Adobe Reader 8 girilmiş durumda, değiştirilerek kullanılabilir) 

select SMS_R_System.ResourceID,SMS_R_System.ResourceType,SMS_R_System.Name,SMS_R_System.SMSUniqueIdentifier,SMS_R_System.ResourceDomainORWorkgroup,SMS_R_System.Client from SMS_R_System inner join SMS_G_System_COMPUTER_SYSTEM on SMS_G_System_COMPUTER_SYSTEM.ResourceID = SMS_R_System.ResourceId where SMS_G_System_COMPUTER_SYSTEM.Name not in (select distinct SMS_G_System_COMPUTER_SYSTEM.Name from SMS_R_System inner join SMS_G_System_COMPUTER_SYSTEM on SMS_G_System_COMPUTER_SYSTEM.ResourceID = SMS_R_System.ResourceId inner join SMS_G_System_ADD_REMOVE_PROGRAMS on SMS_G_System_ADD_REMOVE_PROGRAMS.ResourceID = SMS_R_System.ResourceId where SMS_G_System_ADD_REMOVE_PROGRAMS.DisplayName like “%Adobe Reader 8%”)

All Windows Server 2003 SP 1 Systems

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_OPERATING_SYSTEM on SMS_G_System_OPERATING_SYSTEM.ResourceID = SMS_R_System.ResourceId where SMS_G_System_OPERATING_SYSTEM.Caption like “%Server 2003%” and SMS_G_System_OPERATING_SYSTEM.CSDVersion = “Service Pack 1″

All Windows Server 2003 SP 2 Systems

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_OPERATING_SYSTEM on SMS_G_System_OPERATING_SYSTEM.ResourceID = SMS_R_System.ResourceId where SMS_G_System_OPERATING_SYSTEM.Caption like “%Server 2003%” and SMS_G_System_OPERATING_SYSTEM.CSDVersion = “Service Pack 2″

All Windows Server 2008 SP 1 Systems

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_OPERATING_SYSTEM on SMS_G_System_OPERATING_SYSTEM.ResourceID = SMS_R_System.ResourceId where SMS_G_System_OPERATING_SYSTEM.Caption like “%Server 2008%” and SMS_G_System_OPERATING_SYSTEM.CSDVersion = “Service Pack 1″

All Office 2007 Installed Systems

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System inner join SMS_G_System_ADD_REMOVE_PROGRAMS on SMS_G_System_ADD_REMOVE_PROGRAMS.ResourceID = SMS_R_System.ResourceId where SMS_G_System_ADD_REMOVE_PROGRAMS.DisplayName = “Microsoft Office Professional Plus 2007″ or SMS_G_System_ADD_REMOVE_PROGRAMS.DisplayName = “Microsoft Office Enterprise 2007″ or SMS_G_System_ADD_REMOVE_PROGRAMS.DisplayName = “Microsoft Office Standard 2007″

All Windows Server 2000 SP1 Systems

select SMS_R_System.ResourceId, SMS_R_System.ResourceType, SMS_R_System.Name, SMS_R_System.SMSUniqueIdentifier, SMS_R_System.ResourceDomainORWorkgroup, SMS_R_System.Client from  SMS_R_System inner join SMS_G_System_OPERATING_SYSTEM on SMS_G_System_OPERATING_SYSTEM.ResourceId = SMS_R_System.ResourceId where SMS_R_System.OperatingSystemNameandVersion like “%Server 5.0%” and SMS_G_System_OPERATING_SYSTEM.CSDVersion = “Service Pack 1″

All Windows Server 2000 SP2 Systems

select SMS_R_System.ResourceId, SMS_R_System.ResourceType, SMS_R_System.Name, SMS_R_System.SMSUniqueIdentifier, SMS_R_System.ResourceDomainORWorkgroup, SMS_R_System.Client from  SMS_R_System inner join SMS_G_System_OPERATING_SYSTEM on SMS_G_System_OPERATING_SYSTEM.ResourceId = SMS_R_System.ResourceId where SMS_R_System.OperatingSystemNameandVersion like “%Server 5.0%” and SMS_G_System_OPERATING_SYSTEM.CSDVersion = “Service Pack 2″

All Windows Server 2000 SP3 Systems

select SMS_R_System.ResourceId, SMS_R_System.ResourceType, SMS_R_System.Name, SMS_R_System.SMSUniqueIdentifier, SMS_R_System.ResourceDomainORWorkgroup, SMS_R_System.Client from  SMS_R_System inner join SMS_G_System_OPERATING_SYSTEM on SMS_G_System_OPERATING_SYSTEM.ResourceId = SMS_R_System.ResourceId where SMS_R_System.OperatingSystemNameandVersion like “%Server 5.0%” and SMS_G_System_OPERATING_SYSTEM.CSDVersion = “Service Pack 3″

All Windows Server 2000 SP4 Systems

select SMS_R_System.ResourceId, SMS_R_System.ResourceType, SMS_R_System.Name, SMS_R_System.SMSUniqueIdentifier, SMS_R_System.ResourceDomainORWorkgroup, SMS_R_System.Client from  SMS_R_System inner join SMS_G_System_OPERATING_SYSTEM on SMS_G_System_OPERATING_SYSTEM.ResourceId = SMS_R_System.ResourceId where SMS_R_System.OperatingSystemNameandVersion like “%Server 5.0%” and SMS_G_System_OPERATING_SYSTEM.CSDVersion = “Service Pack 4″

Liste böyle uzayıp gidecektir J, son bir hatırlatma, query cümlesi tek parça halinde olmalı, aralarda birden fazla boşluk bulunmamalı, kısaca SQL syntax’ ına uygun olmalıdır.

Bir başka makelede sizlerle SCCM’ in SQL database’ inde bulunmayan bilgilere DCM kısmı ile nasıl bilgi eklenebileceğini ve yeni elde edilen bu bilgilerle reporting kısmında nasıl rapor oluşturulabileceğini paylaşmaya çalışacağım. (Tabi karşılaşılabilecek olası problemleri ve çözümlerini de ekleyeceğim)

Saygılar.

Runbook ve Runbook Automation (RBA) Nedir?

Bilgi Teknolojilerinde Runbook, sistem bileşenlerini içeren çeşitli prosedür ve operasyonların bir araya getirilerek oluşturulduğu rutin süreçlerdir. Bir iş akışı gibi, başlangıç, bitiş ve denetleme prosedürleri içerir. İlgili Runbook senaryoları oluşturulurken en uygun çözümleri içeren ve adım-adım ilerlenebilen karar ağaçlarından yararlanılır. Genelde işletmelerin BT departmanlarında ve Ağ Operasyon Merkezlerinde sistem yöneticilerine referans olması amacıyla kullanılır.

Runbook Automation (RBA) ise, bu sistem ve ağ operasyonlarına destek olan iş akışlarının uygulamalar sayesinde otomatize edilmesidir. Bir Runbook süreci içerisinde uygulamalar, veritabanları ve donanım gibi altyapı elementleriyle iletişime geçilebilir.RBA sistemi birden fazla sistem arasında entegrasyon sağlayabilir. Bu entegrasyon sırasında sadece basit bir connector gibi sistemler arasında veri aktarmaz aynı zamanda orkestrasyon sağlayabilir.

Microsoft System Center Orchestrator tahmin ettiğiniz gibi entegrasyon ve merkezi koordinasyon özellikleri olan bir Runbook Automation yazılımıdır. Databus sayesinde içerisindeki aktivitelerin birbirleriyle iletişim halinde kullanıldığı Runbook’lar oluşturularak operasyonel süreçlerin otomasyonu sağlanabilir. İlerleyen bölümde adım adım bir Runbook oluştururken konunun anlaşılacağına eminim.

kaynak :http://en.wikipedia.org/wiki/Run_book

SCORCH Runbook Designer

Orchestrator süreç tasarımları Runbook Designer arayüzünden yapılmaktadır. 4 ana bölümden oluşan arayüzde sol tarafta bulunan connections paneli ve sağ tarafta bulunan activities paneli ortadaki runbook tasarım çalışma alanına eşlik eder. En alt kısımda ise log ve olay günlükleri bulunur. Çalışma alanı dışında bütün panellerin yeri değiştirilebilir yada ayrı bir pencere olarak dışarı çıkarılabilir.

Bu panellerin ne işe yaradığına bir göz atalım:

İlk anda arayüze baktığınızda System Center ürün ailesinden aşina olduğumuz öğeler içermediğini düşünebilirsiniz. Burada ürünün çıkışının bir satın alma olduğunu ve aileye uyarlanmaya çalışıldığını hatırlamakta fayda var. SCORCH 2012’de beklenen yeni bir değişiklik olmayacak olsada bir sonraki sürüm için ribbon vb. gibi görsel uyumunda sağlanacağını söyleyebilirim.

SCORCH Standart Aktiviteler

Aktiviteler, Runbook dediğimiz operasyonel işlerin otomatize edildiği süreçleri oluşturan parçalardır. Hepsi tek başına ya bir eylem gerçekleştirir, ya bir bilgi sağlar yada izleme yaparak başka bir aktivitenin tetiklenmesine yardımcı olur. Şuan için bile azımsanmayacak sayıda(73) olan bu objeler, üçüncü parti Integration Pack(IP)’lere ihtiyaç duymadan birçok işin otomatize edilmesinde yeterli olabilir. Örnek vermek gerekirse, Powershell komutları çalıştırmaktan SQL sorguları yapmaya, çeşitli dosya, klasör ve text işlemlerinden web servisi kullanımına kadar birçok aktivite Orchestrator ile hali hazırda gerçekleştirilebilir. Bu çerçevede biraz düşündüğünüzde her üçüncü parti uygulama ve sistem için illa bir Integration Pack ve aktivitelere ihtiyacınız olmayacağını görebilirsiniz.

Mesela, powershell komutları kullanarak Exchange ortamında mailbox oluşturmaktan, varolan mailboxların boyutunu hesaplamaya kadar oldukça fazla işlem yapabilirsiniz. Fakat bu her işlem için bir aktivite ve Exchange IP’s olmasını gerektirmeyebilir; sadece Run.Net Script Objesi ile Exchange powershell komutlarını içeren cmdlet’ler kullanabilir ve bütün istediğiniz işleri şuanki durumda bile yaptırabilirsiniz.

Aynı şekilde, kurumunuza özel, veritabanına sahip uygulamalar için SQL sorguları sayesinde veri alıp ve gerektiğinde güncelleyerek, programlama ve karmaşık işlemlerle uğraşmadan basitçe bir entegrasyon sağlamış olabilirsiniz. Gene günümüzdeki birçok uygulamanın entregrasyon desteği için XML Web servisleri sağladığını düşünürsek, Orchestrator içinde kullanabileceğiniz Invoke Web Service ve Query XML gibi standart aktivilerle bile otomasyon süreçlerinizin kapsamını oldukça genişletebilirsiniz.

Peki standart aktiviteler bu kadar çokken, Integration Pack’lere neden gerek var? Tabi entegrasyon uğruna, Orchestrator’da kullanmak üzere her zaman powershell scriptlerle uğraşmak ve boyumuzu aşan SQL sorguları oluşturmaya çalışmak pratik olmayacaktır. Integration Pack aktiviteleri bu noktada işleri daha da kolaylaştırıyor. Runbook’ların daha basit ve kısa olmasını sağlarken süreç yaratma sürelerini haliyle kısaltıyor.

Otomasyon İçin Örnek Senaryo

Bir uygulamamız var ve günlük olarak sürekli log oluşturuyor. Belirli aralıklarla gerek disk alanı tükettiği için gerek arşivleme için bu log dosyalarını farklı bir alanda saklamamız gerekiyor. Bu işlem için, kısa süreliğine uygulamanın servisini durdurup logları dosya sunucusuna aktarmalı, sıkıştırıp işlem tarihine göre adlandırılarak zip dosyası haline getirilmeliyiz. Amacımız bu basit sürecin otomasyonunu yapmak olacak. Yazıda kısa gibi gözüken bu senaryoyu oluştururken neredeyse kompleks bir süreç için ihtiyaç olunan çoğu konuya da değineceğimi şimdiden belirteyim.

Düşününce çoğumuza tanıdık gelen, normalde kabaca 15dk manual çalışma ile haftada bir yapılabilecek bu işlem için hesaplandığında yılda 13 saat gerekmekte. Birde bu işlemin 10 sunucu için yapıldığını düşünün, düz hesap 130 adam saat yani yılda 3 hafta gibi büyük bir iş zamanı önemsiz görünen bu görev için harcanmakta. Bu işleri Orchestrator ile birkaç saat uğraşarak otomatiğe bağlayabiliriz ve sayesinde kazandığımız zamanı ise daha faydalı konular ayırabiliriz.

Dizayna başlamadan önce benim bir önerim, aklınızdaki senaryoyu kesinleştirmek adına visio gibi bir araçla sürecin akış diyagramını oluşturun. Taslak bile olsa bu diyagram ile Orchestrator da süreç tasarımını ve adımları çok daha hızlı yaptığınızı göreceksiniz.

Ayrıca bir senaryo için sadece tek bir çözüm yada dizayn olmadığını bilmelisiniz. En ideal yada hızlı sonuçlanacak akışları zamanla tecrübe edinerek oluşturabilirsiniz.

Runbook Dizayn Aşamaları

Runbook Designer’ı açalım. Orchestrator sunucuya bağlandıktan sonra Runbook klasörüne tıklayarak önce yeni klasör yaratın sonrasında ise içine yeni bir Runbook oluşturun. Klasörler düzeni sağlamaya yardımcı olur. Ayrıca süreçleri grupladığınız bu klasörler erişim izinleri tanımlarken de faydalı olacaktır.

Oluşturduğumuz klasör ve süreci yeniden adlandırarak anlaşılabilir bir hale getirelim. Kompleks senaryolar için aynı klasör içerisinde birden fazla runbook oluşturulması gerekebilir.

Sırada en önemli bileşenler olan aktiviteleri eklemek var. Sağ taraftaki bölümden farklı amaç ve görevleri olan objeleri sürükle-bırak metoduyla tasarım alanına taşıyacağız. Daha sonra bu aktivitelerin konfigürasyonlarını yaparak birbirlerini tetikleyecek ve veri iletecek şekilde bağlayacağız.

Bütün aktiviler hakkında bilgi olması açısından Orchestrator standart aktiviteler listesini içeren technet kütüphanesine bakabilirsiniz.

Ekleyeceğimiz objeler temelde aksiyon adımlarını belirleyecek. Senaryo kısmında amaçladığımız görevlere göre aşağıdaki bölümlerde bulunan objeleri resimdeki gibi yan yana ekleyelim. Yeniden adlandırabildiğimiz bu objeleri yapılandırma aşamasında düzenliyor olacağız.

System | Start/Stop Service
File Management | Move File
System | Start/Stop Service
Utilities | Format Date/Time
File Management | Compress File
File Management | Delete File
Email | Send Email

İlk eklediğimiz Start/Stop Service aktivitesine çift tıklayarak açalım. 4 adet sekmeden oluşan bir yapılandırma pencesi karşımıza gelecek. Burada aktiviteyle ilgili bütün ayarları yapacağız. Önce General bölümünden yeni bir isim verelim ve tercihe göre açıklama bölümünü dolduralım.

Details sekmesi çoğunlukla aktiviteler için gerekli bilgilerin girildiği alandır. Servis durdur/başlat aktivitesi için aksiyon seçeneğini, sunucu ve servis bilgilerini aşağıdaki gibi girebiliriz. Bu aşamada örnek olması için IIS servisini durduruyoruz.

Aktivitenin sekmelerinden biri de kimlik bilgilerinin girildiği alandır. Burada varsayılan olarak runbook sunucunun servisi için kullandığımız hesabı seçebilir yada yeni bir tanımlama yapabiliriz. İki durumda da bu hesabın hedef sunucuda gerekli izinlere ihtiyacı olacağını unutmayın.

Run Behaviour ise önemli bölümlerden biri. Bu aktivitede kullanmayacağız fakat ileri objelerde ne işe yaradığını anlatıyor olacağım. Aktivitenin yapılandırılmasını tamamladık. OK ile pencereyi kapatarak tasarım alanına dönelim.

Bu noktada yapılandırdığımız bir aktiviteyi sürecin devamlılığı için bir sonraki aktiviteye bağlayacağız (link). IIS Durdur objesine tıkladığınızda solunda ve sağında 2 adet üçgen işareti çıkacak. Bu üçgenlerden sağdakinin üzerine gelip basılı tutarak çektiğinizde aşağıdaki gibi bir kesik çizgi oluştuğunu göreceksiniz. Bu çizgiyi bağlamak istediğiniz diğer aktiviye doğru götürüp üzerine bıraktığınızda katı ve düz bir hat ile bağlanacaktır.

Senaryoyu basit tuttuğumuz için yazıda aktivitelerin dallara ayrılmadan, arka arkaya çalıştıkları bir süreç oluşturuyoruz.Normalde her aktivite aynı anda birden fazla aktiviteye bağlanabilmektedir. Örneğin, bir aktivitenin başarılı ve başarısız iki sonucuna göre 2 ayrı dala ve aktiviteye bağlayabiliriz.

Linkler sadece aktiviteleri bilinçsizce birbirine bağlamaz, ayrıca üzerlerinde filtreleme yaparak iletim koşullarını belirleyebilmenize olanak sağlar. Oluşturduğumuz akıllı link’e çift tıklayarak filtreleme ayarlarına ulaşabiliriz. Standart olarak her link aktivitenin başarılı sonuçlanmasıyla devamlılığı sağlamaktadır. Yani aşağıdaki gibi IIS Durdur objesi çalışıp başarı ile sonuçlandığında bir sonraki aktivite tetiklenecektir.

Filtreleme sayesinde seçenekler bizim elimizdedir. Databus yapısı aktiviteden gelen bütün bilgileri kullanabilir ve zengin koşullar oluşturmamıza yardım eder. Olumlu – olumsuz koşullar oluşturabilir, yada birden fazla şart ekleyerek (sadece mantıksal AND operatörü alır) tetiklemeye ince ayar çekebiliriz.

Örneğimizde şimdilik değişiklik yapmadan ilerleyebiliriz. Hoş bir ayrıntı ise Options sekmesinde, link çizgilerinin kalınlığının ve renginin belirlenebilmesi olmuş. Mesela, başarılı koşul linklerini yeşil, başarısızları kırmızı yaparak görsel okunabilirliği arttırabiliriz.

Diğer aktiviteyle devam edelim ve bağladığımız sıradaki Move File objesini yapılandıralım. Burada dosya taşıma işlemi yapacağımız kaynak ve hedef konumu gireceğiz. Benim senaryomda uzak sunucunun Log klasörü ve Orchestrator sunucu üzerindeki bir temp klasörünü yazıyorum. Temp klasörü seçmemin nedeni dosya sunucusuna göndermeden önce logları sıkıştırmak.

Bu objede olduğu gibi bazı aktiviteler çıktı olarak multi-value dediğimiz çoklu değerler içeren veriler üretebilir ve bunları geri döndürebilir. Move File aktivitesinde, belirttiğimiz klasördeki taşınan her dosya için ayrı bir değer üretilecektir. Multi-value yayımlanmış veriler bir sonraki aktiviteye aktarılırken, sırayla tek tek işlenirler. Bunun sonucu olarak tetiklenen aktivite her bir çıktı verisi için tekrar çalıştırılacaktır. Yani move file aktivitesinde taşınan her dosya için bir sonraki service start aktivitesi baştan çalıştırılacaktır. Bu senaryomuza uygun bir durum değildir. Bir sonraki obje text dosyasına satır ekleme gibi bir aktivite olsaydı, bir önceki aktiviteden geçen her dosya için bir kere çalıştırılması ve bu dosyalara textin eklenmesi mantıklı olurdu.

Sıklıkla karşılaşacağımız fakat her zaman istenmeyecek bu özel durumlar nedeniyle yayımlanan verinin davranış ayarlarında değişiklik yapmamız gerekiyor. Aktivitelerin yayımlanan veriye göre çalışma davranışı ( Run Behavior ) iki şekilde olmaktadır:

• Standart davranışta multi-value veriler anlattığım gibi çoklu tek çıktılar halinde aktarılırlar.
• Flatten (düzleştirilmiş) davranışla bu satır satır olan verilerin, tek bir çıktı olarak aktarılması sağlanır.

Flatten seçeneğini aktif hale getirdiğimiz move file aktivitesi artık bir sonraki objeyi sadece 1 kere tetikleyecektir. Aksi halde defalarca aynı IIS Başlat aktivitesi tetiklenecekti. Farkını deneyip görebilirsiniz.

Üçüncü aktiviteye geçtik ve sürecimizin son durumu aşağıdaki gibi görünüyor.

Sıradaki objeye ilk aktivitemiz olan IIS servis durdurma objesinden çokta farklı bir konfigürasyon yapmayacağız. Fakat bilgileri baştan girmek yerine, databus sayesinde IIS durdur aktivitesinde girilen değerlerin aktarılmasını sağlayacağız. Bunun için Computer textbox alanına sağ tuşla tıklayarak Subscribe > Returned Data’yı seçelim.

Yeri gelmişken yayımlanan/döndürülen veri ( Published/Returned Data ) kavramını biraz açalım. Çalışan her aktivite bir veri döndürerek sonuçlanır. Bu veriler her runbook için ayrı bir veri hattına (data bus) aktarılır. Bağlanan bütün aktiviler tarafından bu veriler konfigürasyon amacıyla kullanılabilir. Ayrıca aktiviteler arasındaki linklerde de kullanılarak koşul oluşturma ve karar verme yeteneğini sağlar.

Açılan Returned Data penceresinde önceki objelerden dönen veriler görülebilecektir. Bir aktivite sadece kendinden önceki objelerden dönen verileri kullanabilir. Aşağıda da IIS Durdur ve Log Taşı objelerini görüyoruz.

IIS Durdur aktivitesinden Service Computer verisini seçerek sunucu adını tekrar girmeden verinin aktarılmasını sağlayabiliriz.Bir obje konfigürasyonuna geri döndürülen veri eklendiğinde, aşağıdaki gibi bu değişkeni temsil eden link benzeri bir text eklenecektir.

Gerekli sunucu adı ve servis adı bilgilerini aktardığımızda aktivitenin görüntüsü aşağıdaki gibi olacaktır. Returned Data kullanımı Orchestrator’ı anlamlı kılan en önemli özelliklerinden biridir.

Sürecin 4. adımında kullanacağımız aktivite aksiyon yerine destekleyici bir görev görmekte. Format Date/Time aktivitesi bir sonraki yapılacak işlem için tarih bilgisi üretmemizi sağlayacak.

Bu aktiviteyi yapılandırırken değişkenlerden (Variable) yararlanacağız. Değişkenler önceden belirlediğimiz sabit bir değerin runbooklar içerisinde istenilen yerde kullanmasına olanak tanır. Örneğin dosya işlemleri için gereken bir klasör yolunu değişken olarak tanımlayarak istenilen yerde aktivite konfigürasyonuna ekleyebiliriz.

Sol taraftaki panelden variables klasöründe New Variable seçilerek değişken eklenebilir. Değişkenler sabittir fakat, geçerli zamanı aktaran ve değeri NOW() fonksiyonu olarak tanımlanan değişken istisnadır. Senaryomuzda arşiv dosyasını adlandırırken gereken tarih bilgisini aktarabilmek için Current Date adında güncel zaman değişkenini içeren bir öğeyi aşağıdaki gibi oluşturalım.

Aktivitede değişken kullanımı yayımlanan veri kullanımıyla aynıdır. Subscribe menüsünden Variable’ı tıklayarak ilgili öğeyi seçebiliriz.

Format Date/Time aktivitesinin amacı adından da anlaşıldığı gibi zaman değerinin formatını istenildiği gibi değiştirmektir. Input bölümüne değişkenden dönecek zamanın formatı, Output bölümüne ise dosya isminde kullanılmaya uygun biçimlendirilmiş değeri yazabiliriz. Aşağıdaki değerler kendini açıklamaktadır:

Devamındaki aktivitede temp klasörüne taşıdığımız Log dosyalarını arşivleyeceğiz.

Geri döndürülen verilerin kullanımını öğrendiğimize göre burada da rahatlıkla faydalanabiliriz. Dosyaların konumunu belirten Folder kısmına Log Taşı aktivitesinden dönen klasör bilgisini girelim. File kısmına ise, arşiv dosyasının adını ve konumunu gireceğiz fakat gördüğünüz gibi kısa ve dar textbox içerisinde çalışmak oldukça zor.

Bu kısıtlamadan kurtulmak için küçük bir özellik düşünülmüş. Genişletmek isteğiniz textbox’a sağ tuşla tıklayın ve Expand’ı seçerek ayrı ve büyütülebilir bir pencereden veri giriş yapın. Ben önceki aktivitelerden yayımlanan tarih format değerini ve işlemin yapıldığı sunucu ismini ekledim, arşiv dosyamızın adı amaca uygun olarak oluşturulacaktır.

Aksiyonun son adımına geliyoruz. 6. aşamada Orchestrator runbook sunucunun temp klasörünü temizlemek var.

Silinecek dosyaların klasör bilgisini önceki aktivitelerden alarak işimizi kolaylaştıralım.

Silinen birden fazla dosyadan gelecek multi-value veriler için tekrar aktivite sonucunu düzleştirmeliyiz. Böylece bu objenin konfigürasyonunu da tamamlıyoruz.

Geldik son aşama olan işlemlerin sonuçları için bilgilendirme mailinin gönderilmesine.

Send Email aktivitesi oldukça zengin seçeneklere sahip. Mail içeriğini istediğiniz gibi yayımlanan veriler aktararak düzenleyebilir, hatta dosya bile ekleyebilirsiniz.

SMTP sunucu, gönderen mail adresi, alıcı mail adresi ve kimlik doğrulama bilgilerini girdikten sonra aktivite mail gönderimine hazırdır.

Sonunda sürecimizi tamamladık. Fakat çalıştırmak için butonunun aktif olmadığını görüyoruz. Önce Check In yani bir çeşit kaydetme işlemi yaparak Runbook’u çalışabilir hale getirmeliyiz. Check In yapılan süreç üzerinde artık değişiklik yapılamaktadır. Bu mekanizmanın bir yararı da Check In yapılmamış runbook üzerinde sadece 1 kullanıcıya hak tanımasıdır.Böylelikle çok sayıda kullanıcının süreç üzerinde aynı anda habersiz bir şekilde çalışarak karşıklık yaratması engellenmiştir.

Süreci koşturmaya alternatif olarak Runbook Tester arayüzünü açarak, adım adım çalıştırıp deneyebiliriz fakat, makaleyi uzatmamak adına bu başka bir yazının konusu olacak.

Check In yapılan süreçler üzerinde değişilik yapılabilmesi için önce Check Out durumuna getirilmelidir. Ayrıca Undo Check Out özelliğiyle, süreci en son kaydedilmiş hale geri döndürebiliriz. Yinede Runbook editlerken dikkatli olmakta fayda var, ctrl+z nindurumu kurtaramadığını söyleyebilirim J

Run butonuna bastığımızda süreç aktif olarak çalışmaya başlayacaktır. Log dosyalarının kaynak sunucudan Runbook sunucuya taşındığını ardından da dosya sunucusuna arşivlendiğini linkteki videoda görebilirsiniz. Runbook_in_action.mp4

Süreç tamamlandığında Log History panelinden durumunu kontrol edebiliriz. Eğer bir aşamada hata oluştuysa burada kendini belli edecektir. Bizim durumumuzda 25 sn süren işlemin bütün aşamalarının düzgün işlediğini görüyoruz.

Hazırladığımız Runbook, Orchestration Web Console üzerinden de çalıştırılıp durumu canlı olarak izlenebilmektedir. Üzerinde daha sonra ayrıntılı konuşuyor olacağız.

Umarım keyif aldığınız ve yararlı bir yazı olmuştur. Süreçlere başlangıç yapabilmek için gereken birçok noktadan bahsetmeye çalıştım. Basit bir senaryo üzerinde çalışmış olsakta Orhcestrator’ın çoğu özelliğini kullanmış olduk. Son olarak özetlemek gerekirse, System Center Orchestrator 2012 hakkında bu yazıda aşağıdaki konularda bilgi bulabilirsiniz.

• Runbook Nedir?
• Örnek bir otomasyon senaryosu
• Orchestrator Runbook Designer arayüzü ve süreç oluşturma
• Çeşitli standart aktiviteler (Sistem ve dosya işlemleri, format date, mail gönderme ) ve konfigürasyonları
• Akıllı Aktivite Linkleri ve filtreleme ile koşul yaratma
• Aktivite çalışma davranışı (Run Behaviour), standart ve düzleştirilmiş(flatten) modlar
• Geri döndürülen / yayımlanan verilerin kullanımı (Returned/Published Data, Subscription)
• Değişken kullanımı (Variables) ve NOW() zaman fonksiyonu
• Textbox genişletme (Expand)
• Runbook Check In/Out işlemleri ve Çalıştırma (|>Run)
• Runbook Log ve Log History ile sürecin durumunu görüntüleme.

Planlama ve Kurulum Senaryoları

Orchestrator bileşenleri hakkında fikir sahibi olduğumuza göre işe ilk olarak ihtiyaçlarımızı belirlemekle başlayalım. Arkasından da buna bağlı olarak olası topolojileri ve senaryoları çıkarabiliriz. Bu adımda birkaç noktayı göz önünde bulundurmalısınız:

• Orchestrator’ı hangi amaçla kullanmak istiyorsunuz? (Operasyonel süreç otomasyonu, Cloud ?)
• Konuşlandıracağınız ortam türü ne olacak? (Production/test/development ?)
• Yedeklilik ve erişilebilirlik hangi seviyede olmalı?
• Kaç adet hedef sunucu ve sistem ile beraber çalışacaksınız ?
• Runbook (otomatize edilecek şüreç) sayısı ve kullanım alanları ne olabilir?
• Datastore (veritabanı) konuşlandırılması nasıl olmalı?

İlk etapta tahmin edilmesi zor durumlar olabileceği için bazı soruların cevabını belirlemekte sorun yaşayabilirsiniz. Ürünün yeni olması ve farklı bir konsept içermesi sebebiyle de bir tecrübe eksiliği olacaktır. Bu yüzden olduğunca örneklerle anlatarak tercihlerinizi desteklemeye çalışacağım.

Orchestrator’ı hangi amaçla kullanacağınız ve konuşlandıracağınız, yapacağınız yatırımın kapsamını ve alabileceğiniz riskleri belirlemeniz de faydalı olacaktır. Öte yandan yedeklilik, veritabanı, sunucu sayısı gibi değerler ayırabileceğiniz kaynakları ölçeklendirmekte yardımcı olabilir. Cevap verebildiğiniz kadar soruyu aklınızın bir köşesinde bulundurmaya çalışın.

Önce Orchestrator’dan canlı ortamda ve profesyonel şekilde yararlanmak istediğinizi baz alalım. Mesela veritabanını ayrı bir MSSQL sunucuda barındırmak Management sunucunun yükünü azaltacak ve veritabanı için sql pratiklerini uygulayabilmenizi sağlayacaktır. Ayıramadığınız durumlarda da en iyi seçim Management sunucu üzerinde konuşlandırmak olacaktır. Aynı senaryoda ayrı ve birden fazla Runbook Server kurup yedekliliği sağlayabilirsiniz. Orchestration konsolunu bir web uygulaması gibi düşünüp, fazla kaynak ayırmadan kendi başına bir sunucuya kurarak kullanabilirsiniz.

Başka bir senaryoda gene Runbook Server ve veritabanı sunucusunun ayrı ayrı olmasını tercih edebilir, Management ve Orchestration Web Konsolu ile beraber yedeklilik için 2. planda bir Runbook Server rolünü de aynı sunucuda bulundurarak konsolidasyon sağlayabilirsiniz.

Diğer bir senaryo, test yada geliştirme ortamı gibi düşünüp bütün bileşenlerin bir arada olduğu tek bir sunucu kurmak olabilir.Bu durumda da iş yükü fazla değilse yeterince verim alabilirsiniz.

Management Server

Management rolü üzerine konuşursak en son seçenek aktif bir Runbook server üzerinde olması gerektiği olacaktır. Kullanıcı runbook designer konsollarının management sunucuya bağlandığını düşünürsek, kritik görevler yürüten bir runbook sunucusu üzerinde sürekli olarak iş akışı oluşturma çalışmalarının yapılması rahatsız edici gelecektir.

Runbook Server

Süreç sayısı arttıkça yükü dağıtmak adına kurulum sonrası da dahil her zaman yeni Runbook sunucuları devreye alabilirsiniz.Unutmayın bütün yükü sırtlayan Runbook sunucularınız olacaktır. Orchestrator SCOM yada SCCM benzeri agentlar kullanmamaktadır. (Runbook failover ve yedeklilik konularına ayrıca aşağıda değineceğim.)

Veritabanı

Orchestrator sistemi, veritabanı online olmadan hiç hareket edemeyecektir, availability’sini arttırmak için bir MSSQL cluster kullanabilirsiniz. Replication, mirroring gibi SQL teknolojilerinin de kullanılabileceği yazılı olmasa da söylenenler arasında.Ayrıca her uygulama için tek tek SQL sunucu kurma lüksünüz olmadığını varsayarak başka uygulamalarla ortak güçlü bir SQL sunucuyu problem olmadan kullanabilirsiniz. Veritabanı boyutu konusunda kesin yargılara varmak zor diyebiliriz, en çok alankaplayan süreçlerin çalışma sırasında topladığı bilgiler ve oluşturduğu loglar olacaktır. Büyüme hızı da çalıştırdığınız runbook sayısına göre artabilir. Eski logların otomatik silinme aralığı ve günlük oluşturulan ortalama log boyutu arasında zamanla bir denge kurarsanız veritabanı boyutunu belirli eşik değerleri arasında tutabilirsiniz.

Kaynak Tüketimi

Kaynak tüketimi konusuna değinmeye çalışırsak, gözlemlerime dayanarak SQL sunucu üzerinde bir SCOM kadar yük oluşturmadığını fakat Runbook sunucularında iş akışlarına bağlı olarak memory ve cpu tüketiminin bekleneceğini söyleyebilirim. Değerler tamamen oluşturulan süreçlere bağlı olacağı için kesin değerler vermek oldukça zor.

Sanallaştırma

Sanallaştırma konusunda da bazı önerilerde bulunabilirim. Her zaman olduğu gibi veritabanı sunucusu için ihtiyaç duyulabilecek disk IO’su dikkate alınarak sanal yada fiziksel sunucu tercihi yapılmalı. Diğer roller içinse gerekli CPU ve memory desteğini sağlayabildikten sonra bu zamanda sanallaştırmamak için bir neden göremiyorum. Tabi felaket kurtarma gibi senaryolarında Orchestrator’dan yararlanacaksanız, sanal ortamdaki kesintilerde erişilemeyeceğini düşünerek fiziksel sunucularda konumlandırmayı değerlendirebilirsiniz.

Son olarak farklı senaryolarda yapılacak teknik kurulum işlemlerinin temelde bir farklılık göstermeyeceğini de hatırlatmak isterim.Seçiminiz ne olursa olsun kurulum ve yaygınlaştırma makalelerindeki adımlardan her türlü faydalanabileceğinizi düşünüyorum.

Örnek Topoloji

Bu bölümde senaryolar kısmında anlattığımı görsel olarak sunabilmek için bir örnek üzerinden gideceğim. İleri düzeyde bir veri merkezi ortamına kurulacağını varsayalım. Orchestrator server rolleri birden fazla sunucu üzerine dağıtılacak. Ayrı VLAN’lar bulunduğu için DMZ ve Intranet ağında en az birer adet Runbook Server kurulacak. Veri tabanı, ortamdaki System Center sunucuları için kullanılan ayrı bir MSSQL sunucuda bulunacak. Orchestration konsolu kendi başına bir web sunucudan hizmet verecek şekilde kurulacak. Bu doğrultuda, oluşturulabilecek yapıyı aşağıdaki gibi ifade edebiliriz:

Böyle bir Orchestrator yapısını oluşturabilmek için enaz 5 adet sunucuya ihtiyaç olacaktır.

Bu sunucuları aşağıdaki gibi özetleyebiliriz:

Sunucu Özellikleri ve Gereksinimler

Microsoft tarafından önerilen min. konfigürasyona bakarsak oldukça makul olduğunu göreceksiniz. Bütün sunucu türleri için aşağıdaki listeyi baz alabilirsiniz.

Benim önerim özellikle Runbook sunucularında minimun 2×2.00Ghz CPU ve 4GB memory kullanmanız yönünde. Diğer donanım özelliklerini ise siz belirleyebilirsiniz. Sanal sunucular tercih ettiğinizde gerektiğinde kaynak arttırımına gidebilirsiniz.

Disk boyutu seçimi yaparken, açıkçası göz önünde bulundurabileceğiniz tek konu, logların boyutu olacaktır. Varsayılan ayarlarıyla Runbook sunucular makul seviyelerde log üretmektedir. Fakat debug amacıyla loglama seviyesini arttırdığınızda özellikle anlık izleme yapan iş akşılarının günde 1GB’a yakın log ürettiğini görebilirsiniz.

Veritabanı için Windows Server 2008 R2 üzerine kurulmuş bir MS SQL Server 2008 R2 kullanabilirsiniz. Service packleri yüklediğinizden emin olun.

Bütün sunucuların güncelleştirmeleri yapılmış ve .Net Framework 3.5 SP1 ve 4.0 kurulu olmalı.

Orchestrator’ı domain ortamına dahil ederek kullanmanızı kesinlikle öneririm. Öteki türlü her bir iş akışında ve her bir obje için karşı sunucuda geçerli bir kullanıcı hesabı belirtmek zorunda kalacaksınız. Bu hesapların kontrolü ve audit edilmesi de oldukça zor olacaktır. Fakat DMZ ağı için workgroup da olan bir Runbook sunucu kullanmanız gerekebilir.

Remote bir SQL Sunucu kullanmayı tercih ettiğiniz takdirde, SQL servisinin 1433 tcp portu üzerinden hizmet verdiğinden ve SQL Instance bilgilerinden emin olun. Dikkat etmeniz gereken diğer noktaları kurulum hazırlık aşamasında bulabilirsiniz.

Not: Orchestrator 2012 için detaylı sistem gereksinimlerine buradan erişebilirsiniz.

Servis Kullanıcı Hesapları

Orchestrator ile kullanılacak servis hesapları hakkında da bir çalışma yapmalı ve tercihlerimizi belirlemeliyiz. Runbook sunucular çoğu aktiviteyi bu servis hesaplarını kullanarak yapmaktadır. Kolaya kaçıp domain admin gibi fazla yetkili hesaplar vermeyi tercih etmeyin. Fakat doğası gereği sunucuları kontrol etmesi gereken bu hesaplara fazla bir kısıtlama uygulamak da pratik olmayacaktır.

İlk olarak domainde bulunan 1 tane servis kullanıcısının aslında bütün işleri görebileceğini söyleyebilirim. Ama benim önerim Management sunucusu için 1 tane, ve Runbook Sunucu servisleri için enaz 1 tane domain kullanıcısı oluşturulması yönünde olacak. Runbook Sunucuların erişim alanlarını kısıtlamak, ayırmak ve güvenlik loglarında daha rahat takip edebilmek için her Runbook sunucu başına 1 tane servis kullanıcısı oluşturabilirsiniz. Böylece bu hesaplara belirlediğiniz sunucularda yetkiler vererek, Runbook sunucuların kapsamlarını belirleyebilirsiniz. Sunucu parkları geniş olanlar için faydalı olabilir. Workgroup ortamında olan Runbook sunucular içinse lokal hesaplar kullanmaktan başka çaremiz yok.

Bu kullanıcıların servis olarak kullanılabilmeleri için sunucularda Local Security Policy aracılığıyla Log on as a servicehaklarının verilmesi gerekiyor. Bunların dışında kısaca, bulundukları sunucularda local administrators grubuna eklemelisiniz.

SQL tarafında ise kurulum sırasında Management sunucusu bir veritabanı oluşturulacağı için servis kullanıcısına sysadminseviyesinde haklar verilmesine ihtiyaç var. Daha sonra Runbook sunucuları da veritabanına bağımlı çalışacakları için servis kullanıcıları bu oluşturulmuş veritabanında db_owner hakkına sahip olmalı. Veritabanı oluşturulduktan sonra sysadmin hakkına artık ihtiyaç olmayacaktır. Workgroup da bulunan Runbook sunucular için yapılması gereken ek bir işlem daha olacak.Windows authentication kullanılamayacağı için SQL sunucuya servis kullanıcı hesaplarıyla değil SQL kullanıcısıyla bağlanmaları gerekecek. Bu yüzde SQL kimlik doğrulamaya izin verilmeli ve 1 adet sql kullanıcı oluşturulup Orchestrator veritabanında db_owner hakkı verilmeli.

Runbook sunucuların hedef sistemlerde ve sunucularda işlemler gerçekleştirebilmeleri içinde haliyle izinlere ihtiyacı olacak.Yani kullanılan Runbook servis kullanıcılarına buralarda haklar atamanız gerekiyor. Local administrators grubu tercih edilebileceği gibi, izinler belirli işlemler için (örn: dosya, klasör) sadece ilgili hedeflere de verilebilir.

Son olarak Orchestrator yöneticileri olarak anılacak bir kullanıcı grubu oluşturmanız gerekiyor. Bu grubun üyelerine management sunucuya Runbook Designer ve Deployment Manager ile bağlabilmek için kurulum sırasında gerekli haklar tanımlanacak.

Yedeklilik ve Yüksek Erişilebilirlik Seçenekleri

IT otomasyon süreçleriyle ilgili yazılara geçmeden önce planlama ve kurulum konularında mümkün olduğunca çok noktaya değinmek istiyorum. Orchestrator altyapısı açısından yedeklilik ve yüksek erişilebilirlik seçenekleri de bunlardan biri. Otomatize edilen süreçlerin ne kadar kritik olabileceği düşünülürse sunucu yada servis bazlı hatalarda kesinti zamanının minimuma indirilmesi yani sürekliliğin sağlanması akla gelen ilk konu oluyor. Buna bağlı olarak bu yazıda Orchestrator bileşenlerinin ve en önemlisi süreçlerin erişilebilirliğini nasıl arttırabileceğimizden bahsedeceğim.

Orchestrator’ı yedeklilik açısından Aktif çalışan kısımlar ve diğer bileşenler olarak ikiye bölebiliriz. Aktif kısım yani Runbook sunucular yada Datastore tarafında yaşanan bir sorun sistemi olumsuz etkileyecek ve süreçlerin durmasına neden olacaktır. Management Sunucu, Orchestration web konsolu yada designer tarafında yaşanabilecek problemler sorumlu oldukları fonksiyonların kaybına yol açsa da, süreçlerin çalışmasına engel değildir.

Runbook Server

Runbook sunucular için Orchestrator içerisinde yerleşik bir failover mekanizması bulunur. Bu özellik basitçe, erişilemez duruma gelen bir runbook sunucu üzerinde çalışan süreçlerin otomatik olarak diğer bir sunucudan çalışmasını sağlar. Varsayılan olarak, kurulan ilk sunucuya süreçleri işleme rolü birincil olarak atanır. Daha sonra eklenen diğer sunucular sırayla Standby durumunda olacaklardır. Bu rollerin sırası istenirse designer konsolundan değiştirilebilir. Bu şekilde istemediğimiz bir davranış yani süreçlerin ilk kurulan management sunucusu üzerinden çalışması önlenebilecektir.

Runbook sunucular diğer runbook sunucuların ve süreçlerin varlığını takip eder. Management Sunucu üzerinde bulunan RunbookServerWatchDog servisi bu altyapıyı sağlamaktadır. Eğer bir runbook sunucu yada süreç 45 saniye içinde tespit edilemezse kayıp olarak değerlendirilir. Runbook servisinin durması yada donanım arızası gibi durumlar buna örnek olabilir. Devamında bu sunucu erişilebilir runbook sunucular listesinden çıkarılır ve üzerinde olan süreçler sırada bekleyen bir runbook sunucusunda çalıştırılır.

Ayrıca çok daha etkili bir yöntem, süreçlerin çalışması için istenilen runbook sunucuların manual seçilmesi olacaktır.Bu şekilde süreçleri istediğiniz gibi runbook sunuculara dağıtabilirsiniz. Birden fazla sunucuya atadığınızda da failover yeteneğinden faydalanabiliyor olacaksınız. Açıkçası bu yöntemin çok daha esnek ve verimli olduğunu söyleyebilirim.

Failover yapılan süreçler sunucu tekrar erişebilir olduğundan eski yerinde çalışmaya devam eder. Fakat izleme yapan bir süreç çalışma halinde olacağı için durdurulup başlatılana kadar belirlenmiş ilk sunucuya geri dönmeyecektir.

Normalde her Runbook sunucunun çalıştırabileceği maksimum süreç sayısı (varsayılan olarak 50) belirlenmiştir. Eğer bir Runbook sunucu bu limitini aştıysa, üzerine gelen yeni süreçleri otomatik olarak listede bir sonraki sunucuya aktaracaktır. Eğer diğer sunucununda kapasitesi doluysa, bir sonrakine aktarılır ve bu böyle devam eder. Bu şekilde runbook sunucular bir pool mantığıyla hizmet verir ve süreçlerin bekletilmemesini yani sürekli çalışır halde kalmasını garantiler.

Failover özelliğini faydalı olmakla beraber bir de risk barındırmaktadır. Çalışması sırasında sunucu hatası nedeniyle yarım kalan bir sürecin yeni bir runbook sunucudan baştan başlatılması sorunları da beraberinde getirebilir. Örneğin baştan başlayan bir sanal makina oluşturma süreci, biri yarım kalmış birden fazla sanal makina oluşmasına neden olabilir. Bu sorunu aşmak için failover yaptığımız süreçlere dikkat etmeli ve iş akışı dizaynlarını buna göre yapmalıyız.Kapsamlı olduğunu düşündüğüm bu konudaki ipuçlarını başka bir makalede paylaşıyor olacağım.

Son olarak runbook’lar için bir yedekleme yöntemi olarak import/export özelliğinin kullanılabileceğinin altını çizmekte fayda var. Bütün orchestrator sistemini kaybetseniz bile, import edebileceğiniz yedekteki runbook’lar sayesinde herşeyi baştan oluşturmak için gereken onlarca zahmetten kurtulabilirsiniz.

Datastore

Orchestrator’ dan bahsederken söylediğim gibi, veritabanı kesinlikle çalışır halde olmasını isteyeceğiniz bir bileşen olacaktır. Erişilebilirliğini arttırmak için en iyi yöntem bir MS SQL server cluster kullanmaktır. Cluster sizin için fazla lüks olacaksa veritabanı yedeklerini sık bir şekilde almanız felaket durumunda en az kayıpla kurtulmanıza yardımcı olabilir. Çünkü bütün runbook ve konfigürasyon bilgileri datastore içerisinde bulunmaktadır. Ayrıca Replication, mirroring gibi SQL teknolojilerinin desteklendiği yazılı olarak onaylanmasa da, forumlar ve toplantılarda söylenenler arasında.

Orchestration Console

Kritik olmayan bir bileşen olarak değerlendirebiliriz. Standart bir web uygulaması olarak değerlendirip yedeklilik için 2 farklı sunucuya kurabilirsiniz. Birini kaybettiğinizde diğerine girerek sürekliliği sağlayabilirsiniz. Daha profesyonel bir çözüm için bu 2 siteyi bir Network Load Balancer donanımının arkasında konumlandırarak erişilebilirliği arttırabilirsiniz.

Management Server

Yerleşik olarak bir failover yada high availability seçeneği bulunmayan Orchestrator management servisinin bir risk taşıdığını düşünebilirsiniz. Fakat önceden de konuştuğumuz gibi, Runbook sunucuların geçerli süreçleri management sunucusuna ihtiyaç olmadan yürütebildiğini hatırlamakta fayda var. Yani management servisi aslında kritik bir bileşen değildir, bu yüzden de bir yedeklilik desteği olması düşünülmemiştir. Felaket durumunda bütün veriler datastore da olacağı için kısa süre içerisinde yeniden kurularak kurtartılabilir. Bu süre zarfında tek kayıp yeni süreçler oluşturulması ya varolan süreçlere müdahale edilmesi sırasında yaşanacaktır.

Runbook Designer

Tipik bir son kullanıcı arayüzü olduğu için birden fazla konumda kurulu olması acil durumda işinize yarayabilir.

Umarım bunca laf kabalalığı arasında sizin için faydalı olacak bilgiler sağlayabilmişimdir. Ezbere kurulum yapmadan önce olabildiğince bilgi edinmek, ileride eksikleri fark edip sizi yapıyı tekrar oluşturmaya çalışma derdinden kurtarabilir.

2. Bölümde yapacaklarımız;

Açılış için Boot Image oluşturacağız,

Bunları görev sırası haline getirmemiz gerekiyor. ( Task Sequence ) ve OS deploying için yapılandırdığımız görev sırasını ( Task Sequence ) clientlara almaları için hazır olduğunun ilanını duyuracağız. ( Advertise Task Sequence )

SCCM Sp1 kurulduktan sonra iki adet Windows PE Boot Image kendisi oluşturur. Birisi 32 bit birisi 64 bittir. Resimde iki tane x86 gözükmekte altta kini dikkate almıyoruz. Biz 32 bit kurulum dağıtımı yapacağız.

Bu imajın path’i ; SCMM-Srv1\SMS-LAB\OSD\boot\i386\boot.wim

Şimdi Windows PE Boot Environment için Distribution Point ekleyeceğiz.

Not: Bu uygulamada kullanacağımız her servis için bir ” Distribution Point ” yani dağıtım noktası oluşturacağız ve aynı zamanda, içerisinde ki ayarları özelleştirdikten sonra dağıtım noktamızı update etmemiz gerekiyor.

Distribution Point e tıklayıp sağ üst köşeden ya da sağ tıklayarak yeni oluşturabiliyoruz.

Burada Distribution Point olarak hem Server’ı hem Server Share’ı (SMSPXEIMAGES) seçmemiz gerekiyor. Çünkü bu paketi SMSPXEIMAGES noktasına kopyalayacağız.

Distribution Point leri görebiliyoruz.

Şimdi, Operating System Images‘e sağ tıklayıp, ” Add Operating System Image “ diyoruz.

Daha önceden imajını SCCM üzerine aldığım ” Windows Vista ” nın içerisinde, Sources klasörü altında ki install.wim dosyasını gösteriyorum. .wim bir Windows imaj formatıdır. Burada dikkat edeceğimiz en önemli nokta UNC Path giriyor olmamız lazım.

İlerlediğimizde İşletim Sistemimizin ismini kendisi getiriyor. Tekrar ilerliyoruz

Operating System Image imizi başarıyla import ettik.

Şimdi oluşturduğumuz Operating System Image için Distribution Point ekleyeceğiz

Resimde gösterdiğim gibi sadece Server’ı ekliyoruz DP olarak.

Şimdi Operating System Install Package oluşturacağız. Bir alt menüde ki Operating System Install Package sağ tıklayıp –> Add Operating System Install Package diyoruz.

Burada yine UNC Path kullanacağız. Göstereceğimiz Windows Vista nın ana klasörüdür. Biraz önce eklediğimiz install.wim, işletim sisteminin ana klasörünün içinde yer alan yükleme bilgileriydi. Burada komplesini gösteriyoruz.

Installation paketimizin ismini, versiyonunu ve buna dair bir comment giriyoruz.

Operating System Install Package i başarıyla ekledik.

OS Install Package i SCCM üzerinden görüyoruz. Hemen buna DP ekliyoruz.

OS Install Package için Distribution Point i ekliyoruz.

Sıra geldi, oluşturduğumuz Windows Vista işletim sistemi paketi için ” Driver “ eklemeye.

Drivers menüsüne sağ tıklayıp Import diyoruz ve üstte ki ekran ile karşılaşıyoruz. Yine UNC Path olarak önceden oluşturduğumuz var olan sürücülerin yolunu gösteriyoruz.

İlerlediğimizde Driver klasörümüzün içinde ki sürücüleri görebiliyoruz. Benim ki sanal makine olduğu için onun driver larını gösterdim.

İlerledikten sonra Categories’e tıklayarak, varolan driverlar için bir kategori oluşturuyorum. Sonuçta birden fazla donanım olduğu için bunları karışmaması açısından filtrelemem gerekiyor.

Driver lar için bir kategori oluşturuyorum.

Bu driver ları Boot Image min içerisinde gömüyorum ve altta Update distribution point i işaretliyorum. Wizard bittikten sonra DP update edip driver ları içine gömecek

Wizard bittikten sonra, Drivers menüsünde eklediğim sürücüleri isim olarak görebiliyorum.

Şimdi bu driver lar için bir ” Driver Package “ oluşturacağım ve sürücüleri onun içerisine gömeceğim.

Drivers Package –> New –> Driver Package tıklıyorum ve üstteki ekran ile karşılaşıyoruz. Yine Driver larımı network path olarak belirtiyorum ve OK.

Tamamladıktan sonra, “Drivers” menüsüne geliyorum driverlarımı mouse ile hepsini seçip ( ben sadece VM Drivers seçiyorum, sizler Anakart, Network, VGA diye ayırabilirsiniz.) sağ tıklayıp –> Add or Remove Drivers to Packages tıklıyorum.

Burada amacım, seçtiğim driver ları daha önce oluşturduğum Driver Paketinin içerisinde gömmek. Yine Update distribution point when finished. işaretliyorum. Çünkü bunu yapmadan DP de güncelleştirmediği için yaptıklarım etkin olmuyor.

Drivers Packages içinde oluşturduğum, ” Virtual Machine Drivers “ paketim için Distribution Point ekliyorum.

Sıra geldi bu yaptıklarımızı Task Sequence e yani görev sıralamasına eklemek. Bunu da makalemizin 3. Bölümünde işleyeceğiz.

Makalemizin 2. Bölümünde neler yapmıştık hatırlayalım,

Client ın ön kuruluma başlaması için Windows PE Boot Environment Image oluşturmuştuk

Install.wim dosyasını göstererek Operating System Install Image oluşturduk ( Windows Vista )

Oluşturduğumuz OS Image ı , Operating System Package haline getirdik.

İçerisine Driverlarımızı, Windows Update, Software Update ve 3^rd yazılımlarımızı gömdük.

Sıra geldi bu yaptıklarımızı Task Sequence e yani görev sıralamasına eklemek.

Task Sequence, gelişmiş görev sıralamasıdır ve bu yeni bir özelliktir. 

Task Sequence menüsünden sağ click –> New – > Task Sequence diyoruz

Burada Build and Capture a refernce operating system image seçip ilerleyeceğiz.

TS ismini yazıyoruz, Boot Image gösteriyoruz ve devam ediyoruz

Burada OS package in içerisine gömülecek bilgiler var, İşetim sisteminin product key i , licensing mode, local admin hesabının olup olmayacağı gibi. Burayı kendimize göre düzenliyoruz.

Burada dağıtımı yapılacak işletim sistemini bir domain üyesi mi yoksa bir workgroup üyesi mi yapmak istediğimizi belirtebiliyoruz.

OS Deployment Package içerisine, daha önce Software tarafına eklediğimiz ” Configuration Manager Client Client ” paketini ekliyoruz.

Burada OS Deployment Package içerisine sadece Zorunlu olan software updates, bütün software updates ler yada herhangi birupdate koymadan devam edebiliyoruz.

Daha önce oluşturduğumuz bir Software Package yani yazılım paketi var ise, buraya ekleyerek OS Insallation Package içerisine gömebiliyoruz.

System Preparation ile bu nokta bir işimiz yok eğer sysprep tool içeren ConfigMgr paketimiz var ise onu seçiyoruz.

İmaj özellikleri kısmına yukarıda ki resimde görebildiğiniz üzere oluşturan, versiyon giriyoruz.

Operating System Image i belirteceğimiz bir Network Path e capture lıyoruz.Task Sequence ımız hazır. Burada da görebiliyoruz.

Buna sağ tık –> Properties deyip ufak bir inceleme yapalım.

Task Sequence editör dediğimizde burada diskleri ve portition lar tarafında işlemler yapabiliyoruz. Birkaç örnek vermek için  Volume ün sağ tarafında ki sarı güneş butonuna basalım.

Task Sequence editör dediğimizde burada diskleri ve portition lar tarafında işlemler yapabiliyoruz. Bu partition ları istediğimiz gibi bölebiliyoruz Quick format yada normal format attırabiliriz. Disk tiplerini ayarlayabiliriz, MBR, Basic, Dynamic disk gibi.

Partition Name verebiliriz.

File System olarak NTFS seçebiliriz.

Burda ilk oluştururken verdiğimiz typical ayarları tamamen customize hale getirebiliyoruz. Username, Licensing mode, Time zone ayarlayabiliyoruz.

Burada sadece en iyi eşlenen uyumlu sürücülerin yüklenmesini yada bütün uyumlu sürücülerin yüklenmesini sağlayabiliyoruz.

Bütün kategorilerde ki sürücüleri hesaba katarak buna dahil edebilir yada sadece belirteceğimiz kategorideki sürücüleri install edebiliriz.

Oluşturduğumuz Task Sequence ‘e sağ tıklayıp ” Advertise ” tıklayalım

Hangi Task Sequence ‘e Advertise yapacağımızı belirtiyoruz öncelikle. Browse deyip biraz önce oluşturduğumuz Task Sequence i seçelim.

Collection i ilk başta oluşturmuştuk. Advertise e sadece istediğimiz Collection ı üye yaparak onlara dağıtımı yapmak istiyoruz senaryomuzda.

Make this task sequence available to boot media and PXE seçeneğini işaretliyoruz. Bu durumda oluşturduğumuz bu Task Sequence, boot media ve PXE ile kurulumlarda erişilebilir olacak. Bu önemlidir.

OS Deployment için kurulum Advertisment ı yani ilanımızın ne zaman başlayacağını belirtiyoruz.

Mandatory assigments. yanında ki sarı güneş butonuna basarrak, as soon as posible seçiyoruz hemen başlatacağız çünkü ilanımızı.

Bu programın yeniden çalışma durum davranışı olarak Always rerun program yani her zaman programı yeniden çalıştır diyoruz. Öncelik High yani yüksek olsun.

Program çalışırken herhangi bir windows bakımını görmezden gel diyoruz. Ignore maintenance windows when……

Burada içeriğin nereden getireleceği sorusu var.

Ben erişimin direkt olarak local distribution point den sağlanıp içeriğin çalışan task sequence de belirtilen yerden almasını ancak bunları local e download etmesini istemiyorum.

Gerektiğinde local olmayan distribution point erişilebilir durumda ise uzak DP i kullan diye işaretliyorum.

Gerektiğinde korunmayan distribution point erişilebilirse, yine bunu kullan diyoruz.

Task Sequence işlemini göster diyorum.

Güvenlik erişimi için yetkilendirmeler.

Advertisment tamamlandı, yaptıklarımızın özeti karşımızda Close deyip kapatıyoruz bu ekranı.

Daha önce oluşturduğumuz Collection’a ( BUILD and CAPTURE VISTA) sağ tıklayıp özelliklerine girdiğimizde Advertisment ı görebilmemiz gerekiyor.

Configuration Manager da OS Deploying işlemlerimizi bitirdik. Şimdi, SCCM ile MDT (Microsoft Deployment Toolkit) entegrasyonu yapacağız.

Şimdi Task Sequence menüsüne gelip oluşturduğumuz Task Sequence bir defa tıklayıp sağ üst köşede işaretlediğim, ” Import Microsoft Deployment Task Sequence ” tıklıyoruz.

Burada daha önce yaptığımız ayarları kişiselleştirip kaydedeceğiz. Bunun sebebi ise daha sonra dağıtacağımız OS ler için hazır template oluşturmaktır.

Aynı yerde Create Task Sequence Media var buna tıklarsa, bir Boot Media oluşturabilir bunu CD/DVD yahut flash belleğe alıp çevrimdışı olarak clientımıza yükleyebiliriz. Buda SCCM ile gelen yeni bir özelliktir. WebCast imizde buna da değineceğiz.

MDT Task Template de Client Task Sequence seçiyoruz.

MDT Task Sequence ismi veriyoruz.

Buradaki ayarları kendimize göre düzenleyip, Operating System Image ayarlarını bir network path e capture lıyoruz.

Boot Image Package imizi seçiyoruz.  ( Windows PE Boot Environment for SCCM )

Yeni bir MDT package oluşturuyoruz bir network path üzerinde.

MDT kaynak dosyaları paketinin isim bilgilerini giriyoruz.

Daha önce oluşturduğumuz Operating System Image paketini gösteriyoruz.

ConfigMgr client paketini gösteriyoruz. Zaten daha önce oluşturmuştuk.

Daha önce indirip yüklediğimiz USMT ( User State Migration Tool ) u burda SCCM ile ilişkilendiriyoruz.

USMT301, USMT dosyalarının olduğu yerdir, USMT klasörü ise SCCM ile ilişkilendirdikten sonra gereken dosyaların kopyalandığı klasör. Yine burada ikisinide network path olarak gösterelim.

Biraz önce de belirttiğim gibi bunları yapmamızın amacı sonradan kullanıcı ve bilgisayar ayarlarını kaydedip istediğimiz ölçütlerde değiştirip tekrar OS Deployment da kullanmak.

MDT USMT Package bilgilerini buraya giriyoruz.

Bu yaptığımız spesifik ayarları paketin kullanması için kaydediyoruz. Bu paket CustomSettings.ini adı altında ve katılımsız yükleme dosyalarını MDTFiles altında kaydedecek. Bu bilgilere OS deployment task sequence ihtiyaç duyuyor.  Yine bu ayarları sonraları isteğimize gore değişerek sonar ki deployment larımızda kullanabiliriz.

MDT ayarlarımızı kaydederken bu ayarlara ilişkin bilgileri girmemiz gerekiyor.

Sysprep paketi kullanmadık zaten gereksinimizde yok. Burayı No sysprep package is required seçerek geçiyoruz.

Microsoft Deployment kit ve içinde ki tüm paketlerin (MDT Files, USMT files, Client Package ayarlarını SCCM için ilişkilendirdik burada o işlemin yapıldığını ve dosyaların gerekli yerlere kopyalandığını gösteriyor.

Task Sequence menüsüne girdiğimizde Microsoft Deployment Kit’i , Task Sequence için oluşturduğumuzu görüyoruz.

MDT Build Client TS’e sağ tıklayıp Edit diyelim.

MDT de bunu kaydettik ve gördüğünüz gibi tüm spesifik ayarlar bunun içerisinde. Eğer antivirüs olarak A ürününden vazgeçip B ürününü kullanacak isek buradan değiştirebiliyoruz ya da windows update i buradan çıkarabiliyoruz gibi bir çok spesifik user state ayarlarını burada değiştirebiliyor / ekleme yapabiliyoruz. Bu tarafı daha detaylı olarak WebCast imizde inceleyeceğiz.

Bu etabında sonunda geldik. Sıra geldi OS Deploying yapacağımız makinayı Collection ımıza eklemeye.

Operating System Deployment altında, ” Computer Association “  a sağ tıklayıp –> ” Import Computer Information “ diyoruz. Ya da resimde ki gibi…

Öncesinde eğer .csv file olarak makine bilgilerimiz kayıtlı ise, ” Import computers using a file ” diyoruz. Ben tek bilgisayar import edeceğimden, ” Import Single Computer “ diyorum.

Computer ismi, MAC adresi ve SMBIOS GUID bilgisini giriyoruz computer’a.

Eğer diğer collection larımızda hali hazırda clientlarımız var ise Search kısmından getirebiliriz.

Önizlememizi görüyoruz. Onaylıyor muyuz?

Evet –>

Sadece ” BUILD AND CAPTURE VISTA “ Collection ımıza ekliyoruz bilgisayarımızı. Çünkü sadece bu makineye komplike bir işletim sistemi dağıtımı yapacağız.

Onaylıyor muyuz ?

Next

BUILD and CAPTURE VISTA Collection a bilgisayarın eklenip eklenmediğini kontrol ediyoruz. Eklenmediyse 30 saniye kadar bekleyelim ve eklendiğini görelim üzerine sağ tık -> properties diyelim ve değerleri inceleyelim.

Collection ımıza Bilgisayarımızı ekleme etabını da tamamladık. Şimdi Client ımıza PXE nin cevap verdiğini ve Windows PE ile boot edip, kuruluma geçtiğini kontrol edelim.

Evet, PXE cevap verdi, SCCM Serverımız üzerinden Windows Deployment Services ile iletişime geçip kendine bir IP aldı, WDS sorgumuzu onayladı.

PXEboot dosyaları download edilip işleniyor.

Evet, Windows PE Boot da açıldı ve kurulum birazdan başlayacak. Hepimize kolay gelsin.