Dale Fontenot: Blog Post: MMS BB51 session demo ? User Initiated Server Restart

Thursday, March 31, 2011

Blog Post: MMS BB51 session demo ? User Initiated Server Restart

I am going to document and publish all the Opalis demos that I did at MMS, providing a description of what the scenario was and details on how I built it. The idea is to help you understand the process we go through, and give you ideas. You will always need to work through your own process and add in more steps for your environment Smile

In this first demo, we did a simple scenario of allowing a non-administrative user to initiate a server restart, whilst capturing the event in Service Manager, taking a snapshot of the server prior and putting Operations Manager into maintenance mode during the restart.

The runbook for this demo looks like this:

Note that this is a demo runbook, and as such does not have all the error fail outs and best practices applied for designing runbooks. You should take a look at the work that Charles Joy has done to understand these aspects.

We are initiating this runbook from a Custom Start object. This is so that we can trigger this runbook manually for the demo, however it could also receive the required inputs from a previous segment of the process using the Trigger Policy activity.

The Custom Start activity is very simple, just asking for the name of the Server we want to restart:

Once we have this input, the first thing we are going to do is check that we have a unique name. To do this, we are going to ask VMM to return all server names that contain the string that we pass it. We could also at this point validate this in other ways if it was physical, or just use other methods like an AD lookup, ping test and so forth.

Once we have the results from VMM, we can use the Compare Values foundation activity to do a simple test.

If the count is 1, we know we have a unique name. Anything else and we either have an invalid name (i.e. a return of zero) or we have entered a name that that is not unique.

In the event that we do not get a return of 1, we fail out and send an e-mail to the user. Again, as this is a demo, I have hard coded some information, but you could pipe this in dynamically.

Now, if we did get a unique result we want to continue with the runbook. To ensure that we validate this, we need to edit the link after the Compare Values activity to only continue if the Comparison was True.

The next step in the runbook is to log an Incident in Service Manager to capture the information about the server restart request. To do this we use the Create Incident from Template activity.

We have selected the fields that we want to populate and then configured what information we want in those fields:

Now that we have the Incident logged, we can begin the restart process. First thing we do is put Operations Manager into maintenance mode for this server. We know we are going to make the server unavailable, we do not need to be alerted that this has happened.

Then we need to perform the snapshot. We already have all the information from VMM about which VM we want to snapshot so we can just subscribe to that Published Data.

And again, we use the same Published Data to shut down our server.

Now, we have to wait for the server to be shut down so we can start it back up again. You may ask why I shut it down and started again, as opposed to issuing a restart command. The answer is simple. There is no particular reason. Like most things in Opalis, there are many different ways to do something, and they all achieve the same outcome.