Register Now for Microsoft Management Summit 2012 Istanbul!

http://www.mms2012istanbul.com/Sayfalar/program.aspx

For the first two parts:

Part1: http://blogs.technet.com/b/meamcs/archive/2012/03/06/system-center-2012-orchestrator-runbook-basics.aspx

Part2: http://blogs.technet.com/b/meamcs/archive/2012/03/09/system-center-2012-orchestrator-runbook-activities.aspx

In RunBook Designer console, on the top bar you’ll notice three button:

Check Out: To be able to edit an existing RunBook, it must be checked out. Main purpose for that action is to prevent concurrent editing of same RunBook by different users.

If someone else is already editing RunBook, you will notice a pop-up window informing that someone is already editing RunBook.

Check In:After you finish your editing, you can Check In RunBook and so that all your changes will be committed. And also other users can then edit RunBook.

Undo Check Out: If you click Undo Check Out button when editing the RunBook, all changes you made are reverted.

Testing RunBooks

Before you run Runbooks, you can test it with RunBook Tester and also easily debug each activity or entire RunBook. This is especially helpful for troubleshooting issues. But don’t be confused about terms, RunBook Tester will apply each activity changes to your current environment, that means it will not use a demo or isolated env.

Please also note that tester runs in the currently logged user context. Orchestrator Service account will not be used for testing purposes. So it would be better to open RunBook Tester as Administrator with high-level security token.

When you click RunBook Tester from the toolbar, Tester starts and loads relevant RunBook

RunBook tester interface consists of five panes;

Run Time Properties:This is one of the mostly used pane. It displays resolved published data items. It’s important because if you use several published items for activities, you may want to see what data is carried between activities. Best way to see them in a clear way is RunBook Tester.

Design Time Properties: Displays design-time information for each activity. This is same with Activity details page.

Workspace: Displays active current Runbook. You can set a breakpoint for each activity.

Breakpoint will be marked with a red round on activity and tester will stop on it.

Log: Displays detailed information for each activity.

You can expand each entry to show details.

Resource Browser: Displays the counters, variables, computer groups and schedules.

You can predefine each of them and make available for all RunBooks.

Computers Groups and global items can be added within Connections Node.

Lets add a computer set to use it within activities.

Now you can use Computer Group within an activity;

This activity will be performed for all computers which members of previously created Computer Group.

Starting Test

You can start your test with different options;

Step Through: Runbook starts with first activity and after completion, it waits for your input. You can click Step button to move one step forward. So you can view design time properties for each activity easily.

Waits for my next click..

Starting RunBooks

To start a RunBook, firstly you must click Check In button to commit changes. Then just navigate related Runbook tab and click Run.

To stop, just click Stop button on the Toolbar. You can track activity’s success&failure progress on Log Pane;

All related events will be logged under Events Pane;

Also to track RunBook changes, In the RunBook Designer, select Audit History tab at the bottom and click individual items.

This is important if there are multiple Runbook designer users in your environment. You can track each Runbook change easily within Audit History.

Next part we’ll cover how to design basic and complex Runbooks.

This script creates a HTML Report showing Send as, Full Access and Send on Behalf Permissions information for each mailbox for your Exchange 2010 Organization, for a selected database or for a single user.

If your environment consist of Exchange Server 2010 and lots of complex mailbox/database permissions, just visit Technet Script Repository and give Serkan’s script a try.

http://gallery.technet.microsoft.com/scriptcenter/Generate-HTML-Report-for-da0f5132

http://blogs.msdn.com/b/jw_on_tech/archive/2012/03/13/why-i-left-google.aspx

http://blogs.technet.com/b/orchestrator/archive/2012/03/06/system-center-2012-orchestrator-runbook-basics.aspx

http://blogs.technet.com/b/servicemanager/archive/2012/03/01/collation-in-system-center-2012-service-manager.aspx

System Center Orchestrator 2012 which is a new member of System Center 2012 family and next version of Opalis, takes place at the center of Private Cloud scenarios. During automation of your dynamic datacenters, Orchestrator can move your operations one more step forward and can integrate with Microsoft and non-Microsoft solutions with just a few clicks.

Let me give you a few examples;

• You can trigger Orchestrator workflows through an incident management system such as Service Manager 2012.
• Periodic installation processes can be automated. For example during installation you can take actions on active directory, stop load balancer pools, check service status etc.
• Active directory operational tasks such as user create, user delete, group create, change memberships etc. can be moved to the orchestrator RunBooks.
• You can monitor SCOM alerts and trigger custom RunBooks. For example when a virtual machine run out of disk, SCOM generates an alert and orchestrator can assign additional disk through triggered RunBook.

In this blog post series we’ll cover of how to design RunBooks from basic to complex. And at end of the series you will understand what Orchestrator 2012 can do and how can you integrate it into your current environment.

For the first part “RunBook Basics” I’ll mention basic RunBooks concept and activities that resides within RunBooks.

A RunBook consists of automated tasks and process steps. Also each automated step within RunBooks is called activities.

Here is the very basic RunBook design;

That RunBook reads a static text file and maps each line to the server names then restarts a service for each remote server automatically.

Before going into the RunBook creation details, let’s look at the RunBook properties.

Right click a previously created RunBook and click Properties.

GENERAL:

On the General tab, you can customize name and description fields. Name is an important field because if you decide to import your RunBooks into the Service Manager as activities, you will recognize each RunBook with its name. (Yes you can import your RunBooks into the Service Manager!)

Also on general tab, you can set a schedule to allow RunBook runs only on dates and times you specify.

RUNBOOK SERVERS:

Each RunBook needs a RunBook server to run. In case of requirement High Availability , you must add additional RunBook Servers. For each RunBook, primary and standby RunBook Servers can be set.

Failure of primary RunBook server will trigger standby RunBook server to act as primary.

To set Primary and Standby RunBook Server for RunBooks, click Add and specify your RunBook servers.

LOGGING:

In this section you can choose more logging options to store in Orchestrator Database and show up within Orchestrator Console.

I’ll talk about in more details in future posts.

EVENT NOTIFICATION

On event notification tab, additional log file can be generated when a RunBook fails to run or run for more than specified seconds. Related log files can be viewed with Designer Console or Web Console.

JOB CONCURRENCY

One of the most critical option is Job Concurrency. Even you configure this setting for one single RunBook, in fact it has impact on overall Orchestrator RunBook Servers. Main purpose is specifying concurrent jobs for this RunBook. A RunBook server can have maximum 50 concurrent jobs. So that if you need more than this limit you must deploy additional RunBook servers.

RETURNED DATA

If you finalize your activities with “Return Data” activity, this RunBook can carry out defined data to the other RunBooks.

In this blog post we cover basic RunBook concept. For the next parts we’ll drive in more detail about designing and deploying RunBooks over multiple RunBook servers.

http://blogs.technet.com/b/orchestrator/archive/2012/03/06/system-center-2012-orchestrator-runbook-basics.aspx

http://blogs.technet.com/b/servicemanager/archive/2012/03/01/collation-in-system-center-2012-service-manager.aspx

Birkaç örnek vermek gerekirse;

• Service Manager ya da herhangi bir çağrı yönetimi uygulamanızda açılan çağırılara göre tanımladığınız akışların tetiklenmesini sağlayabilirsiniz.
• Belirli periyodlar ile gelen kurulum taleplerini, tüm detayları ile birlikte otomatize edebilirsiniz. Örneğin her ay web sunucularınız üzerinde güncellenmiş msi paketlerinin kurulumları planlanmıştır. Ancak bu kurulum sırasında active directory üzerinde, load balancer üzerinde, web.config dosyalarında değişiklikler insan eli ile ve onay mekanizmaları kullanılarak gerçekleştiriliyor. İşte bu noktada kurulum çağırılarını Service Manager üzerinden açtırıp geri kalan tüm aksiyonları orchestrator’un gerçekleştirmesini sağlayabilirsiniz. Kurulum öncesi hazırlıkları gerçekleştirir, router yada load balancer üzerinde gerekli aksiyonları alır, servis durumlarını kontrol eder, kurulumları bitirir ve herhangi bir adımda problem çıktığında bunu size geri bildirim ve özelleştirilmiş mesajlar ile iletir.
• Active Directory üzerinde kullanıcı açma, üyelik değiştirme, grup oluşturma gibi operasyonel işlerinizi Orchestrator’a aktarabilirsiniz.
• SCOM tarafından üretilen alert’leri yakalayarak özelleştirişmiş akışların tetiklenmesini sağlayabilirsiniz.
• Private Cloud sanal ortamınızda bulunan tüm sanallaştırma mimarisini yönetebilirsiniz. Örneğin SCOM ile izlediğiniz Hyper-V sunucularınızda bir performans problemi yaşandığında Orchestrator’un gerekli aksiyonu otomatik almasını sağlayabilirsiniz. Ya da sunucular üzerinde disklerde bir problem çıktığında Orchestrator yeni bir LUN dedike edebilir.

Bu makale serimizde ise Orchestrator üzerinde basitten başlayarak complex’e doğru nasıl iş akışlarI (Runbook) oluşturabileceğimize değineceğiz. Böylece siz de Orchestrator’un yapabildiklerini her bölümde daha iyi kavrayarak ortamınıza entegre edebileceksiniz.

İlk bölümümüzde temel Runbook konseptinden ve runbooklar içerisinde yer alan aktivitlerden bahsedeceğiz.

Runbook otomatikleştirilmiş görevler ya da işlemler için adımları içerir. Her bir runbook içerisindeki adımlara ise aktiviteler denmektedir.

Orchestrator içerisinde oluşturulan basit bir Runbook aşağıda gösterilmektedir.

Görüldüğü gibi Runbook tanımlanmış aktiviteleri gerçekleştiren, bunu gerçekleştirirken aynı zamanda verileri kullanan ve diğer yandan veriyi diğer aktivitelerin kullanması için taşıyan akışlardır.

Yukarıda görülen örnek runbook ile bir text dosyasının içeriği okunarak sunucu isimleri map edilir ve bu sunuculardaki Dhcp Client servisi yeniden başlatılır.

Runbook oluşturma detaylarına girmeden önce aktiviteleri içeren RunBookların temel özelliklerini inceleyelim.

GENERAL:

General sekmesinde runbook için gerekli olan isim ve tanımlama bilgisi girilebilir. Bunun yanında ilgili runbook’un çalışması için bir schedule tarihi belirlenebilir. Bu noktada girilen isim önemlidir çünkü Service Manager entegrasyonu ile ilgili Runbookları Service Manager aktivitesi olarak import ettiğinizde bu isimleri görüyor olacaksınız.

RUNBOOK SERVERS:

Herhangi bir Runbook’un çalışması için bir Runbook sunucuya ihtiyaç vardır. Orchestrator sunucunuzda Runbooklar kritik öneme sahip ise yüksek erişebilirlik çözümlerini planlamanız gerekmektedir. Herhangi bir runbook için primary ve standby runbooklar belirlenebilir. Böylece runbook sunucuda bir problem olduğunda standby runbook sunucusu ilgili runbook’u çalıştırmaya devam edebilir.

Bu işlem için Add butonuna basarak Primary ve Standby runbook sunucuları eklenebilir.

LOGGING:

Bu bölümde daha sonrasında konsol içerisinde görüntülenmesi için veritabanı içerisinde saklamak istediğiniz ekstra verileri seçebilirsiniz.

Bu noktada bahsedilen Published Data kavramını detaylı olarak ilerleyen bölümlerde inceleyeceğiz.

EVENT NOTIFICATION

Bu bölümde herhangi bir Runbook belirli bir süre çalışmadığında ya da çalışma başarısız olduğunda bir log üretmesi sağlanabilir. İlgili mesaj Designer Console yada Web Console üzerinde log sekmesinde görüntülenebilir.

JOB CONCURRENCY

En önemli özelliklerden bir tanesi Jıb Concurrency’dir. Bu ayar tek bir Runbook için veriliyor olsa da temel amaç sizin Runbook sunucunuzun aynı anda kaç farklı Runbook çalıştırabileceğini ve ne kadar isteği karşılayabileceğini belirtir. Bir Runbook server aynı anda 50 işi çalıştırabilir. Bu sebeple bu sayının üzerinde bir değer verirseniz fazladan Runbook Server’ı ortamınıza katmanız gerekmektedir.

RETURNED DATA

Eğer Runbook içerisindeki aktiviteleri “Return Data” aktivitisi ile bitirirseniz bu Runbook’un tanımlanmış bilgileri aktarmasını sağlayabilirsiniz.

Bu noktada tanımlanan veriler Runbook çalışmayı bitirdiğinde döndürülür ve diğer runbookları çağırmak için kullanılabilir.