Hello and welcome to my System Center blog. These days it seems everyone has a blog, so why should you read mine? I have been working with System Center for four years and I have learned everything I know exclusively from following other peoples blogs and of course hands on experience with the product. My intent is to publish blogs as a sort of note book for myself and to help others so they can solve problems faster than it may have taken me.
Earlier this year I discovered System Center Orchestrator and it has easily become my favorite product in the System Center Suite. Formally Opalis, Microsoft purchased the product and re-branded it under System Center as Orchestrator. Why do I love Orchestrator so much? Because, if you haven’t been able to create a solution in Orchestrator, then you haven’t tried hard enough.. With the System Center Integration Packs, you can automate many tasks in every section of System Center, but it goes so far beyond that. There are of course other integration packs that it comes with for things like monitoring services and servers, restarting both as needed, Active Directory and Exchange integration and if there isn’t an Activity or Integration Pack, there is PowerShell integration.
So for this blog post I have a runbook that will restart a server and check for if a service is running upon reboot and send emails to a distribution group. Here is the runbook in completion.
First we have Initialize Data, every orchestrator runbook starts with Initialize Data or a Monitor. For Initialize Data we have two Parameters, ServerName and ServiceName, we will use these later in the runbook. These parameters can be manually entered, or received from a Service Request from the Service Manager Self-Service Portal.
Next we reboot the server, grab the Restart Activity from System in the Activities pane and connect Initialize Data to it. Once open, right click in the computer properties and select Subscribe to Published Data, from Initialize Data select ServerName.
Now, we get to the really cool logic in Orchestrator which is the Link Logic. From the screenshot below you see we now have two paths, server restarted successfully or it failed, color coded for good or bad respectively. Side note, I like to color code and label my links so anyone can take a quick look at the logic involved in my Runbooks.
To create the link logic right click on the link and you get something that looks like this. By default the logic is that the previous activity was successful.
This is fine for the successfully restarted path, but for the failed to restart path, click on success and select failed. The failed path will now look like this.
For the failure path I have chosen to email a distribution group should the server not come back, if you are using Operations Manager you can generate a SCOM Alert, or you could also log it in a database from within the runbook.
Next grab the Get Computer/IP Status activity from the Activities pane under Monitoring. Connect the successful path to it from Restart Computer and set its properties by subscribing to published data “Computer from Restart Server.”
You may notice from the runbook screenshot that there is an arrow from the Wait for Post activity pointing back to itself. We have a loop for this activity to force it to wait until the server has rebooted. To do this, right click on the activity and select looping. These are the settings.
What the Get Computer/IP Status activity does is ping the selected computer. So with the added looping of the activity we make the runbook wait until the server has actually restarted. Once that happens it will then move on to the next activity. In the next activity we have another Get Computer/IP (Wait for Post) and have it do the opposite behavior, which is ping the computer and exit when it is ping-able.
Both of the Get Computer/IP activities point to a failure email should something go wrong with the server during the reboot.
Next we connect the Wait for Post activity to Get Service Status, open the activity and subscribe to published data from Initialize Data ServiceName.
Now we have some more really cool logic.
If the Get Service Status returns success the runbook will send an all clear email. We check for that by telling the link to only allow this path if the service is running.
However, if the status from Get Service Status contains “stop” the runbook will try to restart that service.
We then have the runbook attempt to restart the service by getting the Restart Service acvtivity and setting it by subscribing to published data.
We then use the same link logic from Get Service Status to determine if further action needs to be taken, sent via email or if the service was able to be successfully started.
All in all this is a pretty simple runbook, but it can easily be modified to fit whatever the needs are. You could add runbook automation activity and have this as a service request from your Self-Service Portal in Service Manager, you could have it scheduled if you need to schedule a restart, the beauty is in the flexibility in Orchestrator.
Here is a link to the runbook on my Onedrive.
Hi, I’m Billy York. I’m a Consultant at Microsoft, former Cloud and Datacenter Management MVP, specializing in monitoring and automation. Here you’ll find posts about AzureMonitor, LogAnalytics, System Center Operations Manager, Powershell, Hyper-V, Azure Automation, Azure Governance and other Microsoft related technologies.