Note: I have not included details on the scripts used for the processes in the post. I will update the post shortly with information about those scripts.
Back in the days when I spent a lot of time managing MOM 2005, and SCOM 2007 deployments, I came across a product from a company called Opalis that focused on data center automation. I found this product to be a very powerful addition to any Microsoft environment as it allowed normal every day admins to write complex automation tasks. I was pleasantly surprised when Microsoft decided to purchase Opalis back in 2009. It’s nice to see the results of the purchase come to fruition with System Center Orchestrator 2012. The release candidate was made available for download last week and I decided to take it for a test drive.
Note: This blog post was written while System Center Orchestrator (SCO) 2012 was still in prelease (Release Candidate). All screen shots and descriptions are of the release candidate of SCO 2012 and not final RTM version. This blog post does not cover installing, configuring, or maintaining SCO 2012 outside the scope of Lync Server Maintenance. If you’re interested in reading a couple of good intro blog posts on SCO check out Stefan Koell’s posts on System Center Central
I decided it would be fun to see if I could use SCO to automate some common maintenance tasks required when administrating a Lync Server 2010 infrastructure. Specifically I thought it would be interesting to see if SCO could manage the windows update process for Lync servers. With any enterprise telephony environment, you want to make sure maintenance does not impact users while they are in the middle of phone calls. Lync Server 2010 provides the ability for administrators to gracefully “drain” a front-end when maintenance is required. This allows an administrator block new connections to a front-end without interrupting existing calls taking place on that server. After current calls are completed, the server can then be taken down for maintenance. The problem is that this typically has to be done manually, or a lot of scripting is involved to try and automate it. Even with scripting, validation of the various steps can get tricky. This is where System Center Orchestrator (SCO) 2010 delivers some exciting capabilities. Using SCO we can automate and mange the entire update process AND validate each step is successful before moving to the next. In the following example we will walk through a simple update process using SCO 2010. The first thing we need to do is break down our Windows Update install process into logical steps. I’ve listed these below:
1. Define Windows Update Schedule (Usually done on weekends during evening hours).
2. Initiate draining on the first Front-End to be updated.
3. Verify draining was successful and wait for all existing calls to end.
4. If drain was successful, begin installing Windows Updates.
5. After updates install successfully, reboot the server.
I’ve somewhat simplified the process. Additional steps may be required in production environments but this should be enough for you to get the idea.
Great now we’ve got our steps and can start building our automation process, but before we do that it would probably be a good idea to understand a few SCO concepts and terms.
- Runbook – The Runbook is the collection of steps
- Runbook Server – This is the server that performs the tasks in the Runbook.
- Runbook Designer – Used to create and manage Runbooks.
- Schedules – Schedules are used to start automation processes at specified days and times.
- Activities – Activities are the actions performed within a Runbook.
The following steps walk you through the process of setting up the Lync Server Windows Update Runbook example.
1. To start creating our Runbook for the Windows Update process, open the Runbook designer at Start –> All Programs –> Microsoft System Center 2010 –> Orchestrator –> Runbook Designer.
2. After Runbook designer opens, expand the Global Settings node in the left pane, then select the Schedules node. Right click the Schedules node and choose New –> Schedule. This will allow you to set the days of the week, or the days of the month you want the process to run. Don’t worry about the fact that time is not an option here, we will set that within the process. In our example we will set our update schedule for the last Saturday of every month. On the Hours setting ensure permitted is set to all hours on Saturday.
3. Next we need to create our Runbook. To create a new Runbook, right click on the Runbooks node and choose New –> Runbook.
4. In the Runbook you can add the different activities you want to occur. These activities can be anything from ending processes, to rebooting servers. Below is the visual representation of the update process inside the Runbook.
Now that you can see the process visually, let’s discuss each activity a little more in-depth. Activities are displayed in the right pane and can be dragged and dropped into the Runbook the middle pane.
5. Using the Monitor Date/Time activity along with the Check Schedule activity, we can set the start date and time for the process. First create a Monitor Date/Time activity to start the process. Set the Interval to the time you want the monitor to run. In our example we will instruct the Monitor to run every day at 2:00AM.
Next we create a Check Schedule activity as the next step in the process. Select the Monthly Patch Schedule that was setup in step 2. This will tell the Runbook, that when the previous monitor runs at 2AM every day, check to see if the current day matches days configured in the Monthly Patch Schedule. If this returns true, the next step will execute.
6. We are now ready to drain the Lync front end that we want to patch. For simplicity I only have a single server that needs updates installed. To perform the drain, I wrote a PowerShell script that will be saved in a scripts directory on the Lync server. To run the script, create a new “Run Program” activity. Within the activity call the PowerShell executable with the –Command parameter calling the .PS1 script. Note you will need to be sure to import the Lync module as part of your script. You also want to include verification that all calls have ended and no users are connected to the server, before proceeding to the next step.
6. Next we need to perform the Windows Update activity. In this example I customized A sample Windows update VB script from MSDN to download and install updates. The sample script can be found here – Searching, Downloading, and Installing Specific Updates. We again need to save this script on the Lync server and call it with a Run Program activity.
7. Now we just simply add a Restart System activity and tell it to restart the front end that we just updated.
8. Finally you may want to create an activity to email the admin if the drain or windows update activities fail. This will ensure administrators are aware when things don’t go as planned.
So there you have it…obviously there are many other options you can use to create this Runbook specific to your environment. Download the SCO RC for yourself and begin adding automation to your maintenance and IT operational processes. As a bonus..If you use SCOM 2007 R2, you may want to add an activity to put the Lync Server into maintenance mode. Luckily there is a SCO integration pack (IP) for SCOM. You can simply import the IP and add maintenance mode activities as seen in the screen shot below.
