neilp - System Center Premier Field Engineer

System Center Orchestrator: Get Current Date / Time using the NOW() Variable and Automate Outlook Calendar Scheduling

2013-05-06T22:00:00Z

Hi Ho – Neil Peterson here, the in-laws have invaded my house, so I am coming to you today from the corner booth at my local coffee shop. I have a quick little treat this morning, nothing to complicated, but pretty cool and important never the less.

Quite recently I have begun work on some runbook automation that includes Outlook scheduling capabilities. In order to achieve this scheduling functionality, I need to get the current date and time (at each runbook execution time). For instance, as a runbook is executed, I want to send an Outlook calendar invite to a specified user for exactly two days from the time of runbook execution, thus the need for the current date and time. For comparison sake, if I were writing my automation in VBScript I might use the ‘Date’ function, or in C# the ‘DateTime.Now’ function, but what is the equivalent when working with an Orchestrator runbook? Quite certainly we could use a Run .NET script activity and enumerate this information using PowerShell, however there may be a better (more native) method for collecting this information.

In this blog posting I will be taking a quick look at the native Orchestrator NOW() variable. I will show how to use the variable, demonstrate some easy methods for modifying the captured time (now plus two days), and then finally show all of these activities in use when creating an Outlook calendar appointment. The components discussed in this posting can then be reused in pretty much any situation which requires any sort of scheduling, or runbook automation which revolves around knowledge of the current date and time.

The NOW() Variable:

Quite simply, a native 'special' variable exists in the Orchestrator design environment that when invoked will return the current date and time. This variable must be created before use. This is no different than creating any other ‘custom’ Orchestrator variable, however will have a value of ‘NOW()’, as can be seen in the below screen shot. Notice that while in this example the value is NOW(), I have given the variable a name of ‘Current Date and Time:’

For demonstration purposes, I will create a runbook that simply inserts a line into a text document. This text will be ‘The current date and time is’ and then the newly created NOW() variable. The complete runbook and the Insert Line activity configuration is shown below:

After executing the Runbook we can observe the expected output – simple and straight forward.

More information about the NOW() variable can be found here - http://technet.microsoft.com/en-us/library/hh440543.aspx .

Manipulating the Current Date and Time:

Let’s assume now that we have some automation which once executed needs the current time plus two days. So for instance, when the Runbook is executed, we would like to send a meeting invite for two days later. How can we take NOW() and add two days to the returned value? As it turns out, this is quite simple using the Format Date/Time activity, which is found under Utilities. With this activity, not only can we alter the format of the current date and time, but we can manipulate this date and time as well by incrementing any of the date time values (day, hour, etc.).

For this example, I will build off of the already demonstrated Runbook. I will add a ‘Format Date/Time’ activity and then another Insert Line activity. The end result should be two lines, one with the current date time, and one with the current date time + 2 days.

Before configuring the Format Date/Time activity, let’s examine the activities properties. What you will see is that we must specify an input format (that is the format the date time string is in when invoking this activity), and then an output format (that is the format we would like the activity to re-publish the date time string as). This will become very important as we begin to work with other components such as any Outlook Scheduling, as the NOW() variable and the expected date / time format when using the Exchange User Integration pack are not the same. Furthermore, notice here that the default input format does not match what was output by the NOW() variable (compare the format below to the output in the previous example). We will need to modify the Input format to match what the NOW() variable returns. More on formatting can be found here - http://technet.microsoft.com/en-us/library/hh206037.aspx .

The good news is that I have worked through properly formatting for both input and output (assuming you will be using Outlook integration). For the input format, when using the NOW() variable as our input, we will use: M/d/yyyy h:mm:s tt . For the output format when the desired destination is an activity from the Exchange User Integration Pack, we will use: yyyy-MM-ddTHH:mm:ss .

In addition to the formatting, you will also see in the below screen shot the time adjustment which will return a time of NOW() plus two days.

As shown in the screen shot of this second runbook example, we will now write two lines to a text document, one with the current date / time, and then one with the current date / time +2. Below is the insert line text from each insert line activity.

Current Date and time - notice that this is the 'format results without adjustment' which is native published data from the format Date / Time activity.

And finally below is the second insert line activity text (date/time + 2). Notice here that we are using the ‘Format Result’ published data, which includes the adjustment of 2 days.

After executing the Runbook, the output is as follows. Notice that the date / time + 2 is two days after the initial current date time.

Wrapping this up with actual scheduling:

My intention of this blog post was not to put much weight on the Outlook scheduling aspect of date / time, rather highlight how to use the NOW() variable. However, I do like to provide practical examples to accompany technical detail and theory. In this example I will quickly apply what has been discussed into an example which creates a simple calendar invite. Coming in the next week or so I will be releasing some example runbooks and a blog that will really use this scheduling capability in a very cool way.

This sample runbook does require the Exchange User Integration Pack (and an exchange environment). The solution consists of two Format Date / Time activates (one for the calendar invite start time, and one for the end time), and then an activity to create the calendar invite.

For the first date time we need NOW() plus two days.

And for examples sake, say we want the meeting invite to be four hours in length. So for the second Format Date / Time activity, I am taking the results of the first (NOW() plus two) and adding an extra four hours to that.

The end result of running both of these activities is two sets of dates / time: NOW() + 2 days, which will serve as the appointment start time, and then NOW() + 2 days 4 hours, which will serve as the appointment end time.

On the Create Exchange Item (Calendar Invite) activity we can observe the fruits of our work here.

Finally after runbook execution we can observe the results in Outlook. The sent time on the calendar invite represents when the runbook was executed NOW(), and then we can see that the invite is set to start two days after the sent time, and end four hours after that.

Click Image for Better View:

Closing:

I thought this was a cool exercise; the NOW() variable while not complicated, is not something that was obvious to me when beginning this exercise. To boot, the time spent working with date / time format manipulation was a good exercise onto its own. Stay tuned over the next few days / potential week or so, I will be posting a practical solution that uses the topics discussed here to aid in the scheduling of Operating System Deployments. Until then – tweet link is on the page, sign up for my twitter feed for notification of all new neilp activity, thanks for reading.

Building Intelligent Delay Within Orchestrator Runbook Solutions: Activity Looping

2013-04-18T00:44:00Z

Often times when automating a multi-step process, there is a need to build into this automation a certain amount of delay. For instance, if I have rebooted an application server, we not only need to wait for the OS to come back online, but also the application host services to come back online before adding the application server back into the host pool. This is to say, after rebooting the server; we need to delay before executing the next step in the process.

System Center Orchestrator comes with built in delay functionality through establishing a trigger delay on any activity link. When setting this delay the process will pause between activities for the specified time. This is great, however as Anders Bergstrom has pointed out both here, the trigger delay functionality is difficult to track, as the pause is subsurface or does not manifest itself in any viewable form. Anders further solves this shortcoming by using a custom activity for introducing delay into Rubook solutions.

I would like to expand on both triggered delays and customs activity based delays by introducing the concept of intelligent delays. As I create Runbook solutions, it is my goals to include as few as possible timed delays, instead, relying on intelligent delays. Taking the example as detailed above in which a server is rebooted, before moving on with the automation, the IIS service must be started. Simply using a timed delay here would be quite inefficient. Instead if we were to monitor the IIS service, looping on this monitor activity until the service has started, and only then moving onto the next automation step, we have introduced a controlled and intelligent delay.

This is but one simple example of using an Orchestrator activity to intelligently control delay. During this blog posting I will be detailing at a greater depth this example, as well as introducing two additional methods which include using WMI data and PowerShell as intelligent delay mechanisms.

Ultimately the benefits of using intelligent delays are as follows

Removing any inefficient guess work around timing
Greater control over delay mechanics - delay only when a delay is needed and for only as long as the delay is required
Greater reporting or visibility into the delay - we can track how many times a loop has triggered
Greater error control on the delay – we have the ability to exit if the delay loop has exceeded a determined threshold

Intelligent Delay on Service Status:

In this first example scenario we have a cluster node that has just been patched and rebooted (Runbook automation). Once ready, this cluster node needs to be joined back into the cluster. Before doing so we want to delay until the Windows Failover Cluster service has been started. In the below screen shot we have the sequence of activates to be executed, the Check Cluster Service (boxed in red) activity is our intelligent delay. This is simply a ‘Get Service Status’ activity found under the native monitoring activities.

Looking at the properties, no surprises here, we have a computer name that is passed in using published data, and then the service name, in this case ‘Cluster Service’.

Finally if I right click on the activity and select ‘Looping..’, we can see the ‘exit sequence’. So in this case the loop will exit when the Service status for the Cluster Service equal ‘Service Running’. Until a time at which the service is running, the activity will continue to loop – Intelligent Delay.

Ok, that example was kind of week on the wow factor, but demonstrates a very simple intelligent delay method which can be expanded well beyond server status using many of the native Orchestrator monitor activities. I will turn up the technological wiz bang in the next two examples.

Delay on WMI data:

For my next example, the scenario is that a computer has been added to a Configuration Manager collection, and is then targeted with a set of software updates. A policy refresh job is then executed against the computer. Any seasoned Configuration Manager engineer would agree that there is no prescribed time in which one could expect this policy refresh process to complete. Because of this, using a timed delay here would be wildly inefficient and ultimately cause unpredictable results at Runbook execution time (been there, done that).

To combat this need for a delay, however lack of predictable policy retrieval time, we can snoop WMI on the client for the arrival of the policy. Once WMI data has indicated that the policy has arrived we can move on with the next set of activates in the Runbook solution - Intelligent Delay.

In the below screen shot we can see the scenario as described above. The boxed in red activity ‘Check for Policy’ is serving as the Intelligent delay - this is a standard Query WMI activity.

Looking at the properties of this Query WMI activity, we have a basic WMI query. in this example we are returning all information about deployments applied to a computer via. Configuration Manager Policy. Basically, if the query returns a NULL value then the policy has not yet arrived and we would like to delay or loop. If the query returns anything other than NULL, the policy has arrived, and the delay will end (loop will exit).

Here we can see the Do Not Exit condition which is checking for empty or NULL policy (matches patter ^$) indicating that the specific policy has not yet been applied. The delay loop is configured to Exit when the WMI query returns 'success' and contains any data, indicating that policy has arrived.

In the previous WMI example we were simply looking for the existence of data in WMI. If the data does not exist, loop until it does – Inelegant Delay. This can just as easily be configured to look for specific data. So for instance, if I was looking to loop until the software update installation process had completed, instead of a select all statement, I would simply be returning a specific piece of data. In the below screen (another Query WMI Activity) I am returning EvaluationState, which will indicates progress into the software update installation.

With the WMI query results now loaded onto the Orchestrator databus, we can use these values in our conditional looping. In the example of evaluation state, there are several values that would indicate updates are in the process of being installed. I have each one of these defined as Do Not Exit criteria, or in other words if updates are being installed loop – Intelligent Delay. Finally there are several values that would indicate the installation process has been completed. Upon returning one of these, the loop ends, and the next action in the automation is executed.

Ill take a moment here just to clarify that both of these examples have focus on Configuration Manager and Software Updates. This process works with ANY data that can be sniffed from WMI.

Delay on PowerShell Published Data:

Finally I have an example of using data loaded onto the databus with a PowerShell script as the delay mechanism. The scenario is that we are draining all roles from a Windows Failover Cluster node. We would then like to perform maintenance on this node, however need to ensure that the drain has completed before starting any maintenance. Using PowerShell we can query the node for any hosted roles, gather a count of these roles, publishing this data to the Orchestrator databus. Once we have access to this data (count in this case) on the Orchestrator databus we will loop on the data until the value is empty (the cluster node has been drained of all roles).

In the below Runbook example, the ‘Wait for Drain to Complete’ activity is serving as our intelligent delay. This is a standard Run .NET Script activity executing a very simple PowerShell script – basically placing the count of cluster node roles into a variable $RoleCount.

Click Image to enlarge:

Our Do Not Exit loop criteria is set to loop (not exit) when RoleCount is any other value then NULL (does not match patter ^$). Basically if there is any role present on the node, loop – Intelligent Delay. The loop will exit once the RoleCount data is equal to NULL (matches pattern ^$) indicating that all roles have been drained from the cluster node.

Closing:

There you have it, pretty basic, however maybe not painfully obvious strategy for Intelligent Delay. While there may be a time and place for timed delays using either a link trigger delay or custom activity, it is my opinion that any opportunity to insert some intelligence into Runbook delay makes a smarter and more flexible Runbook execution experience.

As always, twitter subscripting link is on this page, check it out for updating on any new posting to technet.com/neilp.

neilp

MMS2013 Session Now on Channel 9 – Patching a Hyper-V Cluster with Orchestrator / Configuration Manager - Including Downloadable Runbook Exports!!!

2013-04-15T14:42:00Z

Good day all – if you were able to attend MMS2013 hope you had a great time, if not, no worries you are in luck. All MMS2013 sessions should now be available on Channel 9.

Check out my session ‘Complex Maintenance Using System Center 2012 Configuration Manager and Orchestrator: Patching a Cluster’ – http://channel9.msdn.com/Events/MMS/2013/UD-B341 .

During this session, I detail a sample Orchestrator / Configuration Manager Solution which is used to gracefully apply updates to a Windows Failover cluster. In this session, I demonstrate this live against a 2 node Hyper-V cluster (hosting 20 VM's, Live migration and all).

Finally if you like what you see, I have made the Runbooks available at the following location – http://gallery.technet.microsoft.com/Cluster-Patching-Runbooks-5bda907a

Enjoy – and as always, you can subscribe to my twitter feed using the button found on the upper right hand section of this page.

neilp

Come Check Out My MMS 2013 Sessions

2013-03-28T18:16:00Z

MMS 2013 is right around the corner. While at the conference, I will be delivering one session and appearing as a guest in a second one. In each session I will be demonstrating solutions based on the interaction between System Center 2012 Configuration Manager SP1 and System Center 2012 Orchestrator SP1. Come check them out and feel free to grab me before, afterwards, or at any point during MMS 2013 for an introduction.

UD-B341: Wednesday April 10: 4:30 – 5:45 PM

Complex Maintenance Using System Center 2012 Configuration Manager and Orchestrator: Patching a Cluster

During this session, learn how the integration of Configuration Manager and Orchestrator can make the task of applying software updates or service packs to complex systems, an automated, predictable, and stress-free activity. You will have the opportunity to explore complete Runbook examples, automation scripts, and end-to-end demonstration of a complex yet automated maintenance cycle. Be prepared to view script samples and discuss the process at a technical level. The goal of this session is to arm you with the knowledge you need in order to position Configuration Manager and Orchestrator as a flexible maintenance solution that is able to handle the most complex system configurations.

UD-B306: Thursday April 11 12:00 – 1:15 PM

Notes From the Field: Complex and Massive Configuration Manager Migrations

Find out what it takes to migrate a massive complex environment. This session will focus on the challenges of managing and moving an environment consisting of over 120,000 globally dispersed clients from Configuration Manager 2007 to System Center 2012 Configuration Manager SP1. We will discuss the planning process, the required pre–migration work and finally the migration implementation.

Also be sure to catch come of these other sessions being delivered by Premier Field engineers - http://blogs.technet.com/b/mspfe/archive/2013/03/08/going-to-mms-2013-check-out-these-sessions-delivered-by-microsoft-premier-field-engineers.aspx

See You There.

neilp

Determine if CU1 has been applied to a 2012 Configuration Manager 2012 SP1 Site, Admin Console, and Client - Where's the Versioning?

2013-03-28T04:29:00Z

With System Center 2012 Configuration Manager SP1 CU1 deployments starting to roll, I have received a few inquiries into how to determine if CU1 has been appropriately applied. As a cumulative update is not a major update, the version of your Configuration Manager Site will not be incriminated. That said, both the Configuration Manager Administration Console and the Configuration Manager client do receive an increment in version number. In this quick Wednesday evening blog posting I will be detailing methods by which to determine if your site servers, administration consoles, and clients have received the CU1 update.

Site Server:

What we will notice here, is that once the CU1 update has been applied to a site, the site version remains at 5.00.7804.1000 or that of SP1. This is the same version number that was present prior to the CU1 installation.

A simple way to verify the application of CU1 is to snoop the following registry location:

HKLM\SOFTWARE\Microsoft\SMS\Setup

Here we can find a Key name CULevel with a value of the CU applied which will indicate the CU level, in this case CU1.

Click Image for better view:

For reference, here is the same Key from a site in which CU1 has not been deployed.

Console:

Once the console has been upgraded you will find that in Programs and Features the console is still listed at 5.00.7804.1000 or SP1 prior to CU1.

Click Image for better view:

When checking out ‘About Configuration Manager’ however, you will find that the console version has been incremented to Version 5.0.7804.1202 (SP1 CU1).

Furthermore the file Microsoft.ConfigurationManagement.exe found in the AdminConsole\bin folder will be versioned to 5.0.7804.1202 (SP1 CU1).

Click Image for Better view:

Inventory data (software) on this file is going to be a decent indicator of console versioning if using a collection query to upgrade a set of deployed console.

Client:

Finally the client is straight forward, once upgraded, the client version will be incremented to 5.00.7804.1202 or that of SP1 CU1.

Client versioning as seen in the console.

Click Image for Better View:

A simple collection query will produce all clients that have not received the update, which you can then use for deployment targeting (taking into account x86, x64).

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.ClientVersion < "5.00.7804.1202"

Closing:

Hope this quick post on CU1 versioning has been helpful, as always feedback is welcome, subscribe to my twitter feed using the button found on this page, see you at MMS 2013!!

Determine if a Configuration Manager Distribution Point is a Distribution Point Group Member – PowerShell

2013-03-25T19:59:40Z

As I am working with the 2012 Configuration Manager SP1 (and CU1) PowerShell CMDLETs, the potential for automation around both the management and deployment spaces of Configuration Manager are expanding. That said, I have run against a few automation solution requirements that could not be met using the native PowerShell CMLETs. No worries though – WMI can still pull through when needed.

In my most current project I’ve had the need to determine wither or not a particular Distribution Point is already a member of a particular distribution point group. While we have been provided with a handful of CMDLETs that had looked promising (Get-CMDistributionPoint and Get-CMDistributionPointGroup), neither of these appear to provide the data I need. In this quick blog posting I will be sharing the PowerShell script I am using to determine DP group membership.

Backstory:

Before sharing the script, here is the backstory for context sake. I am working on a series of Orchestrator Runbooks that will fully deploy a Configuration Manager distribution point. When creating Orchestrator Runbook solutions, I make every effort to included Runbook resiliency. That is, before performing any automated action I want to ensure that this action has not already been performed. In this case, before adding a Distribution Point to a Distribution Point Group, I want to ensure that it is not already a member of this group- simple as that. Building in this type of control adds quite a bit of benefit to Runbook automation such as

Potential reduction in error due to repeated work.
Potential reduction in need for error control.
Most importantly if a Runbook solution is restarted for any reason mid-way, this resiliency will ensure that all completed automation will not be re-run or duplicated, while any non-completed automation is then completed.

Script:

This script was thrown together pretty quickly and could probably stand some scrubbing, but works great as is. Also to note, the Get-WmiObject CMDLET supports the use of a -Credential parameter. This can be used when needing to supply alternate credentials.

$DP = "<Enter DP Name>"
$DPGroup = "<Enter DP Group Name>"
$SiteCode = "<Enter Site Code>"
$PrimarySS = "<Enter Primary Site Server Name>"

$NS = "root\sms\site_" + $SiteCode

$wmi = Get-WmiObject -Class SMS_DPGroupInfo -Filter "Name = '$DPGroup'" -ComputerName $PrimarySS -Namespace $NS
$gid = $wmi.GroupID
$NAL = Get-WmiObject -Class "SMS_DPGroupMembers" -Filter "GroupID= '$gid'" -ComputerName $PrimarySS -Namespace $NS | Select DPNALPath

foreach ($item in $NAL) {

    If ($item -like "*" + $DP + "*") {
    $result = "True"
    }

}

Orchestrator Use:

So, to use in Orchestrator, the script has been dropped into a Run .NET activity, the $result variable is specified as published data, and then this published data is used in link logic. So if the value of $result is “True” the runbook as pictured below completes after the "Check DP Group for DP" activity. If the value is not “True” then the activity to add the Distribution Point to the Distribution Point Group is run.

Script as used in Run .NET Activity. Notice here that I have included the use of alternate credentials.

Example of Published Data:

Example of Link Logic:

Closing:

Quick post here! I hope that you find this script to be helpful when approaching your own Configuration Manager infrastructural automation projects.

At Long Last - Add-CMDistributionPoint PowerShell CMDLET included in Configuration Manager SP1 CU1

2013-03-23T17:42:00Z

Whoo - long time no blog. I am still around and kicking, just been occupied with a new baby (New-CMFreak), a new home, and wrapping up presentations for MMS. My hope is to kick this blog back into gear over the next month. Stay tuned for what I hope will be an exciting series of blog postings on ready to use Runbooks that will aid in migration from Configuration Manager 2007 to 2012, and then also a series of blogs detailing my first foray into Hyper-V Clustering and System Center Virtual Machine manager (including details on how I have configured my lab).

However, for today I am excited to get this one down. Last night as I was wrapping up the day, winding down with a quick view of my Twitter feed, I noticed that System Center 2012 Configuration Manager SP1 CU1 had been released. I have anxiously been anticipating this release with the one hope that it would include a PowerShell CMDLET for deploying distribution points. This functionality does not exist pre-CU1. Fortunately, after reviewing the documentation, my hopes had been met, the Add-DistributionPoint CMDLET had made the cut.

In this blog post I will be taking a quick look at new CMDLET - Add-CMDistributionPoint.

Adding the new CMDLETS:

One thing that was not obvious when installing CU1 is that the actual CU1 install itself will not make the CMDLETS available in the ConfigurationManager PowerShell module. What you will notice is that when installing CU1 you will be prompted to create several package including an update package for the Configuration Manager Console. Included in this package is the PowerShell module updates.

Screen Shot of the CU1 installation Deployment Assistance Options:

Which yields the following packages:

Screen Shot of my CM Console Post CU1 installation:

So, in order to use the new PowerShell CMDLETs, we need to first install CU1, and then deploy (or install) the console update onto the system from which we will be working with the PowerShell.

Add-CMDistributionPoint

I will admit, it is with mixed emotions that I begin working with this CMDLET. Here is the back story, I am working on an extremely large 2012 Configuration Manager SP1 migration in which we will be deploying upwards of 500 new distribution points. Early on in the process, I had proposed that we use System Center Orchestrator to automate the deployment of these distribution points. Short story even shorter – I spent many hours just last week putting together PowerShell that will deploy a distribution point, which I could then use in my Orchestrator solution. Needless to say, I no longer need the script. However all is not lost; this was a great exercise into both PowerShell and some of the subsurface components of Configuration Manager.

Onto the goodness – first things first let’s check out the help file for the CMDLET.

Get-Help Add-CMDistributionPoint

Whoo that is allot of options, however never fear they are for the most part self-explanatory. What you notice is that only a few of these are required, the remainder are for “fine-tuned” configuration. The list of required parameters is

-SiteSystemServerName
-SiteCode
-MinimumFreespaceMB
-CertificateExperationTimeUtc

One thing you may also notice though is that we must specify a Site System Server Name. This indicates that a site system must be first added to the Configuration Manager environment before we can use this CMDLET to install the Distribution Point role (which makes sense). If you want to automate the addition of the site system server prior to adding the DP role, we can use New-CMSiteSystemServer CMDLET.

Once the site system has been added to the Configuration Manager environment we can then use Add-CMDistributionPoint to add the DP role. For my example the command will be

Add-CMDistributionPoint –SiteSystemServerName “SCO5.TWOCHUTES.COM” –SiteCode P01 –MinimumFreeSpaceMB 5000 –CertificateExpirationTimeUtc “Saturday, March 21, 2015 9:47:22 AM”

NOTE: The example shown here assumes that IIS has been configured on the target distribution point. The Add-CMDistributionPoint CMDLET includes an –InstallInternetServer parameter which will install and configure IIS in the event that this is needed on the target distribution point.

And as can be seen in the following screen shots, the DP role has been added and configured thusly.

Closing

Pretty cool – hats off to the Configuration Manager Product team for the addition of this CMDLET. This will make the automated deployment of 2012 Configuration Manager SP1 environments much more simple. Stay tuned and I will be posing an Orchestrator Runbook solution that deploys Distribution Points end-to-end which will include the use of this PowerShell CMDLET.

System Center 2012 Configuration Manager: Determine Reboot Pending State Using WMI / PowerShell / Orchestrator Runbook

2013-02-12T17:15:00Z

While recently working on a Runbook solution for patching Windows Failover Clusters, I ran into the need of detecting if the Software Update installation process had placed the target system into a reboot pending state. After doing some research, I found many ‘loose’ methods for reboot detection, however nothing concrete. That is, until I happened upon a new WMI Class of the CCM_ClientSDK namespace named CCM_ClientUtilities. This little gem was waiting at idle capable of providing reboot pending information. In this post I will be quickly taking a look at the CCM_ClientUtilities class and discussing how to use this class for pending reboot detection in your PowerShell / Orchestrator automation solutions.

Before Getting Started:

Before jumping into the guts and glory of CCM_ClientUtilities, maybe I should lay out the situation in which we may need this pending reboot information. For sure, if a Configuration Manager delivered update requires a reboot, shouldn't we just let Configuration Manager handle the reboot, thus no detection needed? While in many circumstances I would agree with this notion, I have found that when automating process around the installation of updates, when a reboot is not required, there is not a good trigger mechanism indicating that it is ok to advance to the next automated task. Thus, if we pause after update installation, and then check for reboot applicability, we can then either reboot the system before carrying on with the remaining process, or skip a reboot (when one is not needed) and move onto the remaining process items.

CCM_ClientUtilities:

So check it out, below is a graphical representation of the namespace ROOT\ccm\ClientSDK, the class CCM_ClientUtilities, and the Class Method DetermineifRebootPending.

Click Image for better view:

We can invoke this method using any number of WMI interfaces; however for the sake of establishing building blocks towards orchestrator Runbook automation I will be using PowerShell.

PowerShell:

The following PowerShell script first returns the CCM_ClientUtilitiis class object and then executes the DetermineIfRebootPending method, placing the results into a variable $results. I’ve then displayed the results using Write-Host.

$reboot = [wmiclass]"\\<Computer Name>\root\ccm\ClientSDK:CCM_ClientUtilities"

$result = $reboot.DetermineIfRebootPending() | Select RebootPending

Write-Host $result

Pretty simple - lets place this into Orchestrator.

Orchestrator Runbook Use:

For sample sake I am going to provide here a very simple example of this script in use. We will enter a Computer Name into the Initialize Data activity, run the script basically as detailed above, and then perform some link logic against the returned (Published) data from the Run .NET Script activity. If the returned data indicates a reboot is necessary we will do so and then proceeded on with the Runbook (indicated by the Continue Workflow activity). If a reboot is not needed we will jump straight to the Continue Workflow activity.

Sample Runbook (Click image for better view):

Run .NET Script Activity PowerShell (Click image for better view):

Published Data from Run .NET Script Activity (Click Image for better view):

Link Logic when a reboot is required (Click image for better view):

Link Logic when no reboot is required (Click image for better view):

Finally for some practical context, here is an example of a real world Runbook in which this reboot detection logic is used. This Runbook is part of a series of Runbooks that applies software updates to a Windows Failover Cluster (more on this later this week).

Sample Runbook (Click image for better view):

Conclusion:

Simple, quick post here. Just wanted to demonstrate the use of this cool new System Center 2012 Configuration Manager WMI trick. In this post we have looked at some PowerShell that allows us to use the CCM_ClientUtilities class to determine is a Reboot is pending on a system due to Configuration Manager activities. We have then seen how to further use this PowerShell in our Orchestrator Runbook solutions.

Configuration Manager PowerShell Tuesdays: Creating and Distributing a Package / Program:

2013-01-15T10:28:00Z

I have long been a crusty old VBScript kind of guy, that just the way it is. I’ve been knocking out ‘short’ 300 line scripts for 10 plus years. In that time I have also gone through a few epic multi thousand line monstrosity scripts,,,, now that’s living. Many years ago at the Microsoft Management Summit (maybe 2008 or 2009) I was given a PowerShell book inside the attendee bag. Then and there I decided to take the leap from my precious wscript.exe to this new-fangled PowerShell thing…… It didn’t happen……. I fell back to the comforts of VBScript year after year. I am here to say now that I think I have crossed the threshold – PowerShell has found its way to the front of my scripting activities and has been paramount in the automation work that I have completed over the last twelve months.

With this blog post I hope to kick off an extended multi post look into some of the many PowerShell CMDLETS included with System Center 2012 Configuration Manager. In addition to examining the CMDLETS themselves, I will be punting in a few posts that should tie multiple pieces of Configuration Manager PowerShell automation into larger Runbook Automation solutions, so look out for those as well.

As reference, I have also completed two blog postings on running Configuration Manager PowerShell CMDLETS outside of a Configuration Manager console initiated PowerShell session, more specifically from System Center Orchestrator. These may be useful when approaching Configuration Manager automation.

In this particular posting, I will be taking a quick look at the following four CMDLETS

New-CMPackage
Set-CMPackage
New-CMProgram
Start-CMContentDistribution

There is not much to cover at any extreme depth with the execution of these four CMDLETS, they are fairly straight forward. Nevertheless this article will be a great kick off point and should set the rhythm for many more to follow.

New-CMPackage:

This CMDLET quite simply creates a Configuration Manager Package. The Get-Help file for this CMDLET includes the following syntax.

New-CMPackage -Name <string> [-Description <string>] [-Manufacturer <string>] [-Language <string>] [-Version <string>] [-Path <string>] [-WhatIf] [-Confirm] [<CommonParameters>]

For my example I will be running

New-CMPackage –Name “7ZIP – PS Created” –Path “\\twocmsp1\c$\Packages\Software Distribution\7ZIP”

As can be seen in the console, the results match the executed PowerShell cmd.

Ok Cool, but what about the other package configuration options such as distribution priority, I do not see a way to configure these using the New-CMPackage CMDLET? Correct, it does not appear all configurations of a package can be set when initially creating the package, however loping in the Set-CMPackage CMDLET extends the configuration capability.

Set-CMPackage:

This CMDLET configures an existing Configuration Manager Package. The Get Help file for this CMDLET includes the following syntax. I’ve trimmed this down to only one of the returned sets of syntax. There are three mostly identical, one each for Package ID, Package Name, and Package Input Object.

Set-CMPackage -Name <string> [-SecuredScopeNames <string>] [-NewName <string>] [-Version <string>] [-Manufacturer <string>] [-Language <string>] [-Description <string>] [-Path <string>] [-ForcedDisconnectDelay <int>] [-ForcedDisconnectEnabled <bool>] [-ForcedDisconnectNumberRetries <int>] [-MifFileName <string>] [-MifName <string>] [-MifPublisher <string>] [-MifVersion <string>] [-DistributionPriority <Priorities> {High | Normal | Low}] [-ShareName <string>] [-ShareType <ShareTypes> {ShareCommon | ShareSpecific}] [-WhatIf] [-Confirm] [<CommonParameters>]

For my example I will be running:

Set-CMPackage -Name "7ZIP - PS Created" -DistributionPriority High

Which results in the following changes made on the package:

New-CMProgram:

With a package created, we will need a Program. The Get-Help file for the New-CMProgram CMDLET includes the following syntax. This is for a standard program only, the help file also includes some syntax for a device program. Use Get-Help New-CMProgram to see all syntax.

New-CMProgram -PackageName <string> -StandardProgramName <string> -CommandLine <string> [-RunType <RunType> {Normal | Minimized | Maximized | Hidden}] [-ProgramRunType <ProgramRunType> {OnlyWhenUserIsLoggedOn | WhetherOrNotUserIsLoggedOn | OnlyWhenNoUserIsLoggedOn}] [-RunMode <RunModeType> {RunWithUserRights | RunWithAdministrativeRights}] [-UserInteraction <bool>] [-Reconnect <bool>] [-DriveMode <DriveModeType> {RenameWithUnc | RequiresDriveLetter | RequiresSpecificDriveLetter}] [-DiskSpaceUnit <DiskSpaceUnitType> {KB | MB | GB}] [-DriveLetter <string>] [-WorkingDirectory <string>] [-DiskSpaceRequirement <string>] [-Duration <int>] [-WhatIf] [-Confirm] [<CommonParameters>]

For my example I will be running:

New-CMProgram -PackageName "7ZIP - PS Created" -StandardProgramName "7ZIP - Program" -CommandLine "msiexec.exe /I 7z920.msi /quiet /norestart"

The results are much to be expected.

Take note of the standard Environment settings when no options have been specified with the New-CMProgram CMDLET.

If desired, additional configuration can be made at creation time. For instance if adding the -ProgramRunType and -RunMode parameter when running the New-CMProgram CMDLET, such as

New-CMProgram -PackageName "7ZIP - PS Created" -StandardProgramName "7ZIP - Program: -CommandLine "msiexec.exe /I 7z920.msi /quiet /norestart" -ProgramRunType WhetherOrNotUserIsLoggedOn -RunMode RunWithAdministrativeRights"

The results are as follows:

Start-CMContentDistribution:

All right - we have a package and a program created. Next step is to distribute this bad boy to a single distribution point or distribution point group. No worries, we have an CMDLET for that. The Get-Help file for Stat-CMContentDistribution includes the following. NOTE: this is the output for only a standard package, there are unique commands for driver packages, operating system images, etc. however they are mostly similar to what is shown below. Run Get-Help Start-CMContentDistribution for a full listing.

Start-CMContentDistribution -DeploymentPackageName <string[]> [-CollectionName <string>] [-DistributionPointName <string>] [-DistributionPointGroupName <string>] [-WhatIf] [-Confirm] [<CommonParameters>]

For my example I will be executing

Start-CMContentDistribution -PackageName "7ZIP - PS Created" -DistributionPointGroupName TWOCMSP1

Once completed we can observe on the distribution point groups properties that the package has in deed been distributed.

Conclusion:

Very straight foreword stuff here. As seen, through a series of just a few Configuration Manager CMDLETS we can easily create a Package, Program, and distribute the package to a group of distribution points.

Configuration Manager SP1 PowerShell in Orchestrator Part 2: The Rest of the Story

2013-01-11T14:35:00Z

Well I thought I was Mr. Smarty Pants and had the whole ‘running 2012 Configuration Manager cmdlets from an Orchestrator Run .Net Script activity’ figured out (as documented in this post). As it turns out, there is bit more to the story. Everything documented in the initial post is valid, however as I found out today there is an additional step that needs to be taken in order to load data from the executed Configuration Manager PowerShell CMDLETS onto the Orchestrator data bus. So let’s just consider this post two in the series.

In this post I will be detailing the steps needed in order to load a Configuration Manager CMDLET generated data set from an Orchestrator Run .NET Script activity onto the Orchestrator data bus.

Last time on as the scripts churn:

As seen before, in order to Run a Configuration Manager PowerShell cmdlet in the Orchestrator Run .NET Script activity, the script must be capsulated in

$VAR = Powershell {

}

The details of why can be found here.

In the following example I am importing the Configuration Manager PowerShell module, changing to the appropriate PSDrive, and the running the Start-ContentDistribution CMDLET which will distribute content to a Distribution Point. This works great, but as can be seen, I am not attempting to pass any data back onto the Orchestrator data bus.

Click image for a better view:

The issue encountered trying to publish data:

So going with my newly gained wisdom, today I attempted to execute the following script / Run .NET Script activity. This script once again imports the Configuration Manger PowerShell module, changes to the appropriate PSDrive, and then runs the Get-CMDevice cmdlet, placing the results in a variable $isActive. This is all encapsulated in the appropriate code allowing the Configuration Manager script to be run from the Orchestrator activity.

Click image for a better view:

I then have defined Published data that would return the set of data to the Orchestrator data bus.

What I was expecting to see returned was a list of computers (more specifically the active state for a list of computers), however nothing was returned. After some picking around my guess was that the invoked PowerShell 3.0 session does not natively ‘pass’ data back to the calling session which would account for the lack of a returned data set.

And the Fix:

After coming to grips with the fact that I am a mere tourist when it comes to PowerShell development, I turned back to Karl Prosser’s Blog on the various PowerShell issues with the Run. Net Script activity. Sure enough I found what I needed.

Karl Prosser post - Live PowerShell with Karl Prosser

As seen in Karl’s blog, in order to load the returned data set onto the Orchestrator data bus, it must also be ‘passed’ from the invoked 3.0 PowerShell session back into the invoking Run .Net Script 2.0 session. This is quite simple to do. Essentially we will be creating a new object, and the bringing that data back into the calling process, and then targeting it as published data.

In the below example the custom object is created with the new-object cmd, a property is then declared (isActive) and given a value that is the returned data set of the Get-CMDevice cmd. Once the invoked PowerShell 3.0 session is completed, we can then declare a variable ($Active), and give it a value of the returned object property. This variable can then be specified as returned data and used at any point in our Orchestrator Runbook.

Click image for a better view:

And the Published Data.

Here is the script in text form for copy and paste purposes.

$VAR = Powershell {

import-module ($Env:SMS_ADMIN_UI_PATH.Substring(0,$Env:SMS_ADMIN_UI_PATH.Length-5) + '\ConfigurationManager.psd1')

$PSD = Get-PSDrive -PSProvider CMSite

CD "$($PSD):"

new-object pscustomobject -property @{

isActive = Get-CMDevice -Name <computerName> | Select IsActive

}

$Active = $VAR.isActive

Simple Runbook Use / Example:

A very simple example of this process in action could be something like the following. You would like to gather a list of Computers from Active Directory, run the Configuration Manager Get-CMDevice CMDLET for each computer determining if the computer is Active or Inactive, and then finally take some sort of action against those that are inactive (send an email in this case). Mind you this is just a very simple example intended to demonstrated the publishing and re-use of CM PowerShell generated data. There is a TON you could do with CM, PowerShell, and Orchestrator together.

To begin with I've place thee activities in the Runbook, the first being Get Computer from the active directory integration pack, second a Run .NET Script, and third a Send Email activity.

Get Computer is configured to pull back all servers.

The Run .NET Script is basically executing Get-CMDevice - Name <Computer Returned from AD> | Select ClinetActiveStatus. Also included in the PowerShell is all of the necessary additional items discussed in this blog. I am also publishing the contents of the $Active variable.

Click image for a better view:

On the link between the Run .NET Script activity and the Send Email activity is the following logic - Active = @{ClientActiveStatus = 0}. This is the first use of the published data returned from the PowerShell execution. In this case, the Runbook will only progress onto the Send Email activity for any computer that has been detected as being inactive with the Get-CMDevice CMDLET.

Click image for a better view:

And finally, very simple, I am sending an email which includes the computer name for each computer found as inactive.

Conclusion:

Well I think I have it this time, or at least making progress. In this blog posting we have extended on simply running Configuration Manager PowerShell cmdlets from an Orchestrator Run .NET Script activity to also passing data from the Configuration Manager PowerShell script onto the Orchestrator data bus. I've given a very simple example here, but make no mistake there is allot of power and automation to be had with the union of Configuration Manager PowerShell CMDLETS and System Center Orchestrator. Hopefully this post has been helpful in getting you on your way to Orchestrator / Configuration Manager PowerShell automation.