An Application Request with a lot of System Center Power via Orchestrator, ServiceMgr and ConfigMgr

As it Christmas, I wanted to do something special. That’s why dove into the world of ServiceMgr and came up with this long blog post about a combination of ConfigMgr, Orchestrator and ServiceMgr. This blog post will describe a configuration for a software request via the ServiceMgr Portal. I’m not going to say that I like the ServiceMgr Portal more than the Application Catalog of ConfigMgr, because I really don’t, but I do think it fits better within the processes of a company. Besides that, if it doesn’t fit, it can be customized.

High Level Overview

Like I stated the software request can be done via the ServiceMgr Portal. The portal will display applications that are imported, and after that filtered, via the ConfigMgr Connector. The user can request these applications via the portal. After the request is approved, an Orchestrator runbook will find the deployment collection in ConfigMgr, for the requested application, and will add the user to that collection.

ConfigMgr Assumptions

imageActually in this specific blog post there is not much to say about the configuration in ConfigMgr… There are only a few assumptions used to make everything work together:

  • The new application model is used.
  • The applications are deployed to users.
  • The users are added via direct membership rules to the collections.
  • There is only one deployment per application.

Note: This last assumption is a very important one, to make this blog post work. Of course it will also be possible to have multiple deployments, but in that case there has to be some filtering done via Orchestrator.

Orchestrator Runbook

The biggest and most important part of this blog post is the configuration in Orchestrator. The runbook is the key to this software request, as it has to connect all the information. It will get the requested application, the requesting user and the collection to which the application is deployed and in the end it will add the user to the collection. So I will describe all the activities, step-by-step, that I used to make this work. As a prerequisite for the following steps, both the System Center Integration Pack for System Center 2012 Configuration Manager and the System Center Integration Pack for System Center 2012 Service Manager need to be registered and deployed.AddUserToCollecction

  1. Open the Orchestrator Runbook Designer, create a new runbook and name it Add User to Collection.
  2. Add an Initialize Data –activity and double-click it. In the Details Information click Add and a new parameter named Parameter 1 will be added. Now click Parameter 1, change the name to ActivityGUID, click Ok and click Finish.
  3. Add a Get Relationship –activity, name it Get App Relationship, link it with the previous activity and double-click it. In the Details Information fill in the following Properties and click Finish:
    1. Connection: Select the ServiceMgr connection. 
    2. Object Class: Select Runbook Automation Activity.
    3. Object Guid: Right-click and select Subscribe > Published Data. In the Published Data –popup, select with Activity Initialize Data, select ActivityGUID, and click Ok.
    4. Related Class: Select Package.
  4. Add a Get Object –activity, name it Get App Object, link it with the previous activity and double-click it. In the Details Information fill in the following Properties and Filters and click Finish:
    1. Connection: Select the ServiceMgr connection. 
    2. Class: Select Package.
    3. Filters: Click Add. In the Filter Settings –popup, fill in the following Settings and click Finish:
      1. Name: Select SC Object Guid.
      2. Relation: Select Equals.
      3. Value: Right-click and select Subscribe > Published Data. In the Published Data –popup, select with Activity Get App Relationship, select Related Object Guid, and click Ok.
  5. Add a Get Relationship –activity, name it Get Parent SR Relationship, link it with the previous activity and double-click it. In the Details Information fill in the following Properties and click Finish:
    1. Connection: Select the ServiceMgr connection. 
    2. Object Class: Select Runbook Automation Activity.
    3. Object Guid: Right-click and select Subscribe > Published Data. In the Published Data –popup, select with Activity Initialize Data, select ActivityGUID, and click Ok.
    4. Related Class: Select Service Request.
  6. Add a Get Object –activity, name it Get SR Object, link it with the previous activity and double-click it. In the Details Information fill in the following Properties and Filters and click Finish:
    1. Connection: Select the ServiceMgr connection. 
    2. Class: Select Service Request.
    3. Filters: Click Add. In the Filter Settings –popup, fill in the following Settings and click Finish:
      1. Name: Select SC Object Guid.
      2. Relation: Select Equals.
      3. Value: Right-click and select Subscribe > Published Data. In the Published Data –popup, select with Activity Get Parent SR Relationship, select Related Object Guid, and click Ok.
  7. Add a Get Relationship –activity, name it Get User Relationship, link it with the previous activity and double-click it. In the Details Information fill in the following Properties and click Finish:
    1. Connection: Select the ServiceMgr connection. 
    2. Object Class: Select Service Request.
    3. Object Guid: Right-click and select Subscribe > Published Data. In the Published Data –popup, select with Activity Get SR Object, select SC Object Guid, and click Ok.
    4. Related Class: Select Active Directory User.
  8. Add a Get Object –activity, name it Get User Object, link it with the previous activity and double-click it. In the Details Information fill in the following Properties and Filters and click Finish:
    1. Connection: Select the ServiceMgr connection. 
    2. Class: Select Active Directory User.
    3. Filters: Click Add. In the Filter Settings –popup, fill in the following Settings and click Finish:
      1. Name: Select SC Object Guid.
      2. Relation: Select Equals.
      3. Value: Right-click and select Subscribe > Published Data. In the Published Data –popup, select with Activity Get User Relationship, select Related Object Guid, and click Ok.
  9. Double-click the link between Get User Relationship and Get User Object. In the Exclude Filters click Add. Click Get User Relationship and select Relationship Class, click equals and select does not equals and then click value, type Affected User and click Finish.
  10. Add a Run .NET Script –activity, name it Get Collection, link it with the previous activity and double-click it. In the Details Information fill in the following Type and Script and click Published Data:
    1. Type: Select PowerShell.
    2. Script: Add the following script and on right-click on REPLACE and select Subscribe > Published Data. In the Published Data –popup, select with Activity Get App Object, select Display Name, and click Ok:
      $SiteCode = "<SiteCode>" $SiteServer = "<SiteServer>" $CollectionId = (Get-WmiObject -Class SMS_DeploymentSummary -Namespace root/SMS/site_$($SiteCode) -ComputerName $SiteServer -Filter "SoftwareName='{REPLACE}'").CollectionId

    3. In the Published Data click Add. In the Published Data –popup fill in the following information and click Ok, followed by Finish.
      1. Name: Type CollectionId.
      2. Type: Select String.
      3. Variable name: Type CollectionId.
  11. Add a Add Collection Rule –activity, link it with the previous activity and double-click it. In the Details Information fill in the following Properties and click Finish:
    1. Connection: Select the ConfigMgr connection. 
    2. Collection: Right-click and select Subscribe > Published Data. In the Published Data –popup, select with Activity Get Collection, select CollectionId, and click Ok.
    3. Collection Value Type: Select ID.
    4. Rule Name: Right-click and select Subscribe > Published Data. In the Published Data –popup, select with Activity Get User Object, select Domain and type a “\”. Then again right-click and select Subscribe > Published Data. In the Published Data –popup, select with Activity Get User Object, select User Name, and click Ok.
    5. Rule Type: Select Direct Rule.
    6. Rule Definition: Right-click and select Subscribe > Published Data. In the Published Data –popup, select with Activity Get User Object, select Domain and type a “\”. Then again right-click and select Subscribe > Published Data. In the Published Data –popup, select with Activity Get User Object, select User Name, and click Ok.
    7. Rule Definition Value Type: Select Resource Names.
  12. Save the runbook by clicking Check In.

ServiceMgr Runbook Automation Activity Template

Now it’s time to make it possible to use the just created runbook within ServiceMgr. To do that it is necessary to create a Runbook Automation Actiivty Template. I will describe the most important steps and settings that are needed to be done. The details can be filled with everyone’s own healthy creativity. A prerequisite for the following steps is a working Orchestrator connector which synced the just created runbook into ServiceMgr.

  1. Open the Service Manager Console, navigate to Library > Runbooks, select the just created runbook named Add User to Collection and click on the task Create Runbook Automation Activity Template.
  2. AddUseToColRunTemOn the Create Template –popup, fill in as name Add User to Collection – Runbook Template, select (or create) an unsealed management pack, that will be used to save the template, click Ok and the Runbook Activity Template: Add User to Collection Runbook Template will show.
  3. On the General tab, use your creativity to fill in some information and make sure that Is Ready For Automation is selected.
  4. On the Runbook tab, select the Add User to Collection –runbook and change the Parameter Mapping of ActivityGUID to Object > Id.
  5. In case your creativity wants you to add some information on the Configuration Items –tab, the Scheduling –tab, or the Related Items –tab, do that now and click Ok.

ServiceMgr Request Template

After the Runbook Automation Activity is created, its is time to start using it within a request in ServiceMgr.

  1. In the Service Manager Console, navigate to Library > Templates and click on the task Create Template.
  2. ApplReqOn the Create Template –popup, fill in the following information click Ok and the Service Request Template will show.
    1. Name: Type Application Request – Request Template.
    2. Class: Select Service Request.
    3. Management pack: Select (or create) an unsealed management pack, that will be used to save the template.
  3. On the General tab, fill in as Title Application Request and use your creativity to fill in some more information.
  4. On the Activities tab, click Add (+) and in the Select Template –popup select Add User to Collection – Runbook Template. Now again use your creativity to add some more activities. For example, add an activity one for an approval.

ServiceMgr Request Offering

Now it’s time to start making this new Request Template available for the end-users. To do this, it is necessary to create a Request Offering. A prerequisite, for a Request Offering with a nice overview of applications, is a working ConfigMgr connector. To filter the imported applications I will use the Publish state of the imported Packages, so make sure that at least a few have Publish set to True

  1. In the Service Manager Console, navigate to Library > Service Catalog > Request Offerings and click on the task Create Request Offering and the Create Request Offering –wizard will show.
  2. On the Before You Begin page, click Next.
  3. On the General page, fill in the following information and click Next.
    1. Title: Type Application Request.
    2. Description: (Optional).
    3. Template name: Click Select Template and in the Select Template –popup select Application Request – Request Template.
    4. Management pack: Select (or create) an unsealed management pack, that will be used to save the template.
  4. On the User Prompts page, add as Form Instructions Please select and application, add at least the following prompt and click Next.
    1. User Prompts or Information: Type Application.
    2. Response Type: Select Required.
    3. Prompt Type: Select Query Results.
  5. ConfPromOn the Configure Prompts page, select Application and click Configure and the Configure Query Results –popup will show. Walk through the next steps and click Next.
    1. On the 1. Select Class page, select Package.
    2. On the 2. Configure Criteria (Optional) page, select Package > Publish and click Add Constraint.
    3. On the 3. Display Columns page, select Object > Display Name.
    4. On the 4. Options page, select Add user-select objects to template object as related items followed by Application Request – (Service Request), select Add user-selected objects to template object as affected configuration items followed by Add User to Collection – (Runbook Automation Activity) and click Ok.
  6. On the Map Prompts page, at least select Review Application Request – (Review Activity) followed by selecting Token: Portal User Name with Description and click Next.
  7. On the Knowledge Articles page, click Next.
  8. On the Publish page, select with Offering status Published and click Next.
  9. On the Summary page, click Create.
  10. On the Completion page, click Close.

Now the final action before the end-user can use this newly created request is adding the Request Offering to a Service Offering. A prerequisite for the following steps is that there is already a Service Offering created.

  1. In the Service Manager Console, navigate to Library > Service Catalog > Request Offerings > All Request Offerings, select the new Request Offering named Application Request and click on the task Add to Service Offering.
  2. On the Select objects –popup, select a Service Offering and click Ok.

The End Result

ApplReqPortNow it’s finally time to have look at the end result for the end-user. The end-user will go through a small form as shown here on the side. After the form is submitted, in my case, a Service Request will be started. That service request will first ask for an approval with a manager and after it’s been approved the runbook will start. The runbook will find the user, the application and the collection (to which the application is deployed) and in the end add the user to the collection. After the user is added to the collection it will get the application via ConfigMgr.

Share

An overview of my posts about ConfigMgr 2012 SP1

Let’s start my first post, of this new year, with an overview of my latest post about ConfigMgr 2012 Service Pack (SP) 1. Normally I’m not really the kind of person that looks back, but in this case it’s with a reason, as most of my posts where with pre-release versions of SP1. I also tried to sort all my posts per subject, even though sometimes there is some overlap. The following posts are all tested, this week, with the RTM version of SP1 and I can confirm that they are still working:

System Center Orchestrator

Windows Azure

Windows Intune

OS Deployment

Application Deployment

Client Settings

Share

Tweeting the deployment status of a system via Orchestrator and ConfigMgr 2012

Only a few days before Christmas I thought it would be fun to just create something extra cool for this weeks blog post. I thought about something that would be different, but also useful in some way. So I started thinking about how I would like to get my deployment status messages, as I like to start my deployments without checking them al the time, and I came to Twitter. I’ve got my tweets everywhere, on my phone, my tablet, my laptop, etc. So wouldn’t it be cool to get the deployment status messages on twitter?

Prerequisites

Now I decided that I want to show how to tweet the deployment status of a task sequence, there are two methods to do that and I will show them both. The first method is to use a Status Filter Rule and the second method is to use use the Task Sequence. For these methods, the following points are prerequisites:

  • The Microsoft Deployment Toolkit 2012 Update 1 –package is created.
  • The program SCOJobRunner is present on an accessible location for the Site server.
  • The Site server is member of the OrchestratorUser –group.
  • The Network Access Account is member of OrchestratorUser –group.
  • The Social Media Integration Pack, of VIAcode, is registered, deployed and configured.

Runbook

OrcRunBooTweLet’s start with configuring the runbook for tweeting the deployment status. To keep this runbook as general as possible, it will need two input parameters. In total this runbook contains two steps with the following configuration:

  • OrcRunBooIniDatDetAdd an Initialize Data –activity and double-click it. In the Details Information click Add and a new parameter named Parameter 1 will be added. Now click Parameter 1 and change the name to ComputerName. Repeat that action and rename Parameter 2 to Status, click Ok and click Finish.
  • Add a Tweet –activity, link it with the previous activity and double-click it. In the Details fill in the field, next to Text, the text to tweet and click Finish. OrcRunBooTweProIn this example I choose the line @pvanderwoude The deployment of ComputerName is Status!. To get this line in that field, follow the next steps:
    • Fill in the text “@pvanderwoude The deployment of “.
    • Right-click and select Subscribe > Published Data. In the Published Data –popup, select with Activity Initialize Data, select ComputerName and click Ok.
    • Fill in the text “ is “.
    • Right-click and select Subscribe > Published Data. In the Published Data –popup, select with Activity Initialize Data, select Status, and click Ok.
    • Fill in the text “!“. 

Method 1: Status Filter Rules

Now let’s start with the first method, which I also prefer, and that’s configuring the Status Filter Rules. These rules have to perform the tweet action after, either a successful, or a failed deployment of a task sequence. StaFilRulTweGenTo invoke the runbook as an action for the Status Filter Rules use the following configuration:

  • In the Configuration Manager Console, navigate to Administration > Overview > Site Configuration > Sites.
  • In the Home tab click Settings > Status Filter Rules, click Create and the Create Status Filter Rule Wizard will show.
  • On the General page fill in as Name <aName> and select the following criteria and click Next.
    • Select Source and then select Client.
    • Select Message ID and fill in 11171.
  • StaFilRulTweActOn the Actions page, select Run a program, fill in with Program <Dir>:\SCOJobRunner.exe -ID:”<aRunbookID>” -Webserver:”<aWebserver>” -Parameters:”ComputerName=%msgsys;Status=succeeded” and click Next.
  • On the Summary page, click Next.
  • On the Completion page, click Close.

This was the configuration for a Status Filter Rule with a successful deployment. To create a Status Filter Rule for a failed deployment repeat the steps from above and replace 11171 with 11170 and replace succeeded with failed.

Method 2: Task Sequence

Now let’s go to the second method and that’s configuring the Task Sequence. The task sequence will need some extra logics to see whether it failed or not. This means it needs the following three adjustments

  1. One to set a new variable, OSDDeploymentStatus with a default value of succeeded.
  2. One to change the value of the new variable, OSDDeploymentStatus, to a failed, but only if something in the previous part of the task sequence failed if needed
  3. One to invoke the just created runbook with as input the name of the system and the status of the deployment.

TSEdiTweSta01So to put these adjustments together to real configuration changes follow the next six steps:

  • Add a New Group, fill in <aGroupName> and select in the Options –tab Continue on error.
  • Add a Set Task Sequence Variable –step, set Task Sequence Variable to OSDDeploymentStatus and set Value to succeeded.
  • Add a New Group and fill in <aGroupName>.
  • TSEdiTweSta02Add a Set Task Sequence Variable –step, set Task Sequence Variable to OSDDeploymentStatus and set Value to failed. Then go to the Options –tab and click Add Condition > Task Sequence Variable. In the Task Sequence Variable –popup, fill in as Variable _SMSTSLastActionSucceeded, set as Condition equals, fill in as Value False and click Ok.
  • Add an Use Microsoft Deployment Toolkit Package –step and Browse to the Microsoft Deployment Toolkit 2012 Update 1 –package.
  • TSEdiTweSta03Add and Execute Runbook –step, fill in with Orchestrator Server <anOrchestratorServer> and Browse with Runbook to the just created runbook. Then select Specify explicit runbook parameters, fill in with ComputerName %_SMSTSMachineName%, fill in with Status %OSDDeploymentStatus% and select Wait for the runbook to finish before continuing.

Result

As always, after all the configuring, it’s time to look at the results. Normally I like to show log files, or screenshots from console, or screenshots from the event viewer, but this time it’s time for something different. Specially for this post I created a new twitter account that, from now on, will show the deployment status of my lab systems. Those tweets are done by @MyTaskSequenceS and look like this:

TasSeqStaTwe

Share

New and Improved: Pre-provision user applications during OS deployment via Orchestrator and ConfigMgr 2012

Last week I did a post about pre-provisioning user applications, based on group membership, during OS deployment, which I already thought was pretty cool. I got some nice positive feedback on that post, including a comment of my very well respected colleague and ConfigMgr MVP Kim Oppalfens. He said, “Nice find, but what if you have twenty applications?”. Well, my idea of last week would mean two task sequence steps per applications, so that’s not really an option for a lot of applications… I had to come up with something better.

The biggest challenge about this is that Orchestrator can only return static variables, it’s not possible to return dynamically named variables from a runbook. This meant that the only option left, to really achieve my new goal, was to manually edit the ZTIExecuteRunbook.wsf –script from MDT to turn a static variable into multiple task sequence variables. So in rough lines my runbook has to return one string with all application groups and MDT has to turn it into multiple task sequence variables.

Prerequisites

The prerequisites are the same as last week, but to be complete I will sum them up again. This post is based on one basic functional requirement and that’s, that Active Directory (AD) –groups are used to determine whether a user gets and application or not. For the rest of the post the following technical requirements are prerequisites and not further described:

  • The Microsoft Deployment Toolkit 2012 Update 1 –package is created.
  • The Nework Access Account is member of OrchestratorUser –group.
    • Note: By default the Execute Runbook –step will use the credentials of the Network Access Account to connect with Orchestrator.
  • The Active Directory Integration Pack is registered, deployed and configured.
  • User device affinity is configured to Allow user device affinity with automatic approval in the PXE –tab of the Distribution Point Properties.

Runbook

OrcRunBooOveVieLike last week let’s start with configuring the runbook that, in this case, will check all the group memberships. The biggest challenge about this runbook was to find a good way to return the group memberships. The runbook, that I ended-up with, returns a comma separated string with all groups and contains five activities with the following configuration:

    • Add an Initialize Data –activity and double-click it. In the Details Information click Add and a new parameter named Parameter 1 will be added. Now click Parameter 1, change the name to UserName, click Ok and click Finish.
    • Add a Get User –activity, link it with the previous activity and double-click it. In the Filters click Add. In the Filter Settings –popup, select as Name Sam Account Name, select as Relation Equals, right-click the field next to Value and select Subscribe > Published Data. In the Published Data –popup, select with Activity Initialize Data, select UserName and click Ok, click again Ok and then click Finish.
    • Add a Get Organizational Unit –activity, link it with the previous activity and double-click it. In the Filters click Add. In the Filter Settings –popup, select as Name Organizational Unit, select as Relation Equals, set as Value <aOUName>, click Ok and then click Finish.
      • Note: This is an optional activity that I use for the next activity to only get specific groups used for application distribution. An other option might be to check on specific group names, or anything that makes the groups differ from other groups.
    • OrcGetGroProRunBehAdd a Get Group –activity, link it with the previous activity and double-click it. In the Properties click Optional Properties…. In the Add/Remove Property –popup select Search Root, click >> and click Ok. Right-click the field next to Search Root and select Subscribe > Published Data. In the Published Data –popup, select with Activity Get Organizational Unit, select Distinguished Name and click Ok. Then select Filters and click Add. In the Filter Settings –popup, select as Name Member, select as Relation Equals, right-click the field next to Value and select Subscribe > Published Data. In the Published Data –popup, select with Activity Get User, select Distinguished Name, click Ok and click again Ok. Then select Run Behavior, select Flatten and click Finish.
    • Add an Return Data –activity link it with the previous activity and double-click it. In the Details right-click the field next to APPId and select Subscribe > Published Data. In the Published Data –popup, select with Activity Get Group, select Sam Account Name, click Ok and click Finish.
      • Note: To get the APPId String in the Return Data –activity go to the Properties of the runbook and add it in the Returned Data. Also keep in mind that the runbook has to return APPId, to be functional, as the MDT –script (ZTIExecuteRunbook.wsf) will specifically check for that (see the next paragraph for an explanation).

MDT

Now let’s take a look at the MDT –script (ZTIExecuteRunbook.wsf) that is used to execute a runbook via a task sequence. By default this script will just get the returned data from the runbook and make it into a task sequence variable, via this line of code:

oEnvironment.Item(sName) = sValue

As I wanted to keep the default behavior of the script, I adjusted the script to check for a specific name (APPId) in the returned data of the runbook. When the script finds it, the script will cut its comma separated value into pieces and create a new task sequence variable for every piece. These variables are based on the task sequence base variable (see the next paragraph) and can be used, in the task sequence, to install applications according to a dynamic variable list. This all means that I replaced the previous line of code for the following code snippet (don’t forget to update the Distribution Points after updating the script!):

If StrComp(sName, "APPId") = 0 Then
    aAppGroups = Split(sValue,",")
    For i = 0 To UBound(aAppGroups)
        sValue = aAppGroups(i)
        If Len(i)=1 Then
            sAppId = "0" & i+1
        Else
            sAppId = i+1
        End If
        sAppName = sName & sAppId
        oEnvironment.Item(sAppName) = sValue
    Next
Else
    oEnvironment.Item(sName) = sValue
End If

Download the modified script here: ZTIExecuteRunbook.wsf

Task Sequence

Now let’s start with configuring the task sequence. The task sequence needs three adjustments (five steps), one to set the User Device Affinity, one to execute the runbook and one to install the applications based on a base variable. For these adjustments follow the next steps:

    • Add a Set Task Sequence Variable –step, set Task Sequence Variable to SMSTSAssignUsersMode and set Value to Auto.
    • Add a Set Task Sequence Variable –step, set Task Sequence Variable to SMSTSUdaUsers and set Value to <DomainName>\%PrimaryUser%.
      • Note: PrimaryUser is a variable that I use to set the primary user for a device (User Device Affinity) and to find the group memberships. There are many methods to set this variable and during this testing I used a computer variable for that.
    • TSEdiCheGroMemAdd an Use Microsoft Deployment Toolkit Package –step and Browse to the Microsoft Deployment Toolkit 2012 Update 1 –package.
    • Add and Execute Runbook –step, fill in with Orchestrator Server <anOrchestratorServer> and Browse with Runbook to the just created runbook. Then select Specify explicit runbook parameters, fill in with UserName %PrimaryUser%, and select Wait for the runbook to finish before continuing.
    • TSEdiInsUseAppAdd an Install Application –step, select Install applications according to dynamic variable list, fill in with Base variable name APPId and click Ok.
      • Note: APPId is the variable that is returned by the runbook of the previous step. After the modifications to the ZTIExecuteRunbook –script it captures that variable and turns it’s value into multiple task sequence variables. Those variables now all contain the base variable name plus a number suffix starting at 01.

Result

Like last week, after all the configuring it’s now time to take a look at what the results are when the task sequence is done. This time I will show the results of how the application groups are passed on from the runbook to the task sequence. The first picture shows the application groups in the Output Parameters of the runbook in the Orchestrator Console. Then the second picture shows how the Execute Runbook –step (ZTIExecuteRunbook.log) processes the multiple groups into multiple task sequence variables and at last the third picture shows how the Install Application –step (SMSTS.log) processes the task sequence variables into applications that have to be installed.OrcAPPOutPutParZTIExeRunBooAPPLogSMSTSAPPIdLog

Note

In case the name of the groups are not equal to the applications, that need to be installed, and it’s not possible to easily extract the application name from the group name, then it might be necessary to use a Map Published Data –activity in the runbook. This way it can easily turn a group name into an application name, but the biggest down-side is that it will be a static list.then.

To end this post, I would like to thank my colleague Bart Timmermans for helping me better understand the (un-)logics of Orchestrator.

Share

Pre-provision user applications, based on group membership, during OS deployment via Orchestrator and ConfigMgr 2012

This week it’s time for another, in my opinion, very cool post with the combination of Orchestrator and ConfigMgr 2012 (and MDT 2012 Update 1). In this post I want to use the user, set with User Device Affinity, to pre-provision applications, based on group membership, on a device during the initial deployment of the device. Out-of-the-box User Device Affinity can be used to pre-deploy user-targeted application to a device and it can be set during the deployment of a device. This way it will start receiving applications very quick after the deployment.

Basically I’m going to show in this post how to set User Device Affinity via a task sequence and how to use that username to install only specific applications for that user during the deployment of the device.

Prerequisites

This post is based on one basic functional requirement and that’s, that Active Directory (AD) –groups are used to determine whether a user gets and application or not. For the rest of the post the following technical requirements are prerequisites and not further described:

  • The Microsoft Deployment Toolkit 2012 Update 1 –package is created.
  • The Nework Access Account is member of OrchestratorUser –group.
    • Note: By default the Execute Runbook –step will use the credentials of the Network Access Account to connect with Orchestrator.
  • The Active Directory Integration Pack is registered, deployed and configured.
  • User device affinity is configured to Allow user device affinity with automatic approval in the PXE –tab of the Distribution Point Properties.

Runbook

OrcInsAppLet’s start with configuring the runbook that will check the group membership. The best thing about this runbook is that it doesn’t require any programming skills, just some logics which can be “clicked together”. This runbook contains five activities with the following configuration:

    • Add an Initialize Data –activity and double-click it. In the Details Information click Add and a new parameter named Parameter 1 will be added. Now click Parameter 1 and change the name to GroupName. Repeat that action and rename Parameter 2 to UserName, click Ok and click Finish.
    • Add a Get User –activity, link it with the previous activity and double-click it. In the Filters click Add. In the Filter Settings –popup, select as Name Sam Account Name, select as Relation Equals, right-click the field next to Value and select Subscribe > Published Data. In the Published Data –popup, select with Activity Initialize Data, select UserName and click Ok, click again Ok and then click Finish.
    • Add a Get Group –activity, link it with the previous activity and double-click it. In the Filters click Add. In the Filter Settings –popup, select as Name Sam Account Name, select as Relation Equals, right-click the field next to Value and select Subscribe > Published Data. In the Published Data –popup, select with Activity Initialize Data, select GroupName and click Ok. Click another time Add. This time in the Filter Settings –popup, select as Name Member, select as Relation Equals, right-click the field next to Value and select Subscribe > Published Data. In the Published Data –popup, select with Activity Get User, select Distinguished Name, and click Ok and the click Finish.
    • Add an Return Data –activity link it with the previous activity and double-click the link. In the Include click Get Group and change it to Count. Then click value and set Count equals to 1. Now double-click the new activity, set InstallApp to TRUE and click Finish. Repeat these actions, but the use for Count equals 0 and for InstallApp False.
      • Note: To get the InstallApp String in the Return Data –activity go to the Properties of the runbook and add it in the Returned Data.

Task Sequence

Now let’s start with configuring the task sequence. The task sequence needs two adjustments (five steps), one to set the User Device Affinity and one to execute the runbook. For these adjustments follow the next steps:

    • TSEdiVarAdd a Set Task Sequence Variable –step, set Task Sequence Variable to SMSTSAssignUsersMode and set Value to Auto.
    • Add a Set Task Sequence Variable –step, set Task Sequence Variable to SMSTSUdaUsers and set Value to <DomainName>\%PrimaryUser%.
      • Note: PrimaryUser is a variable that I use to set the primary user for a device (User Device Affinity) and to find the group memberships. There are many methods to set this variable and during this testing I used a computer variable for that.
    • TSEdiRunBooAdd an Use Microsoft Deployment Toolkit Package –step and Browse to the Microsoft Deployment Toolkit 2012 Update 1 –package.
    • Add and Execute Runbook –step, fill in with Orchestrator Server <anOrchestratorServer> and Browse with Runbook to the just created runbook. Then select Specify explicit runbook parameters, fill in with GroupName <anApplicationGroupName>, fill in with UserName %PrimaryUser% and click Ok.
    • TSEdiOptAdd an Install Application –step, select Install the following applications and select New (yellow start). In the Select the application to install –popup select the application that belong the <anApplicationGroupName> and click Ok. Go to the Options –tab and click Add Condition > Task Sequence Variable. In the Task Sequence Variable –popup, fill in as Variable InstallApp, set as Condition equals, fill in as Value True and click Ok.
      • Note: InstallApp is a variable that is returned by the runbook of the previous step. That step is so cool that it captures that variable and turns it into a task sequence variable.

Result

EdiPriUseAfter all the configuring, it’s now time to take a look at what the results are when the task sequence is done. As always there are lot’s of place to show the success of the different actions, so I had to pick a few. I tried to pick those that tell the most information from a picture.

The first result is of setting the primary user during the task sequence. In the Edit Primary User –popup it will show that with Primary Users a user is set with the Affinity Type of OSD Defined.

The second results are of the success of finding the user in the group. It show the Output Parameters of the runbook in the Orchestrator Console and under there the Execute Runbook –step (ZTIExecuteRunbook.log) processing the variable and its value.OrcOutPutParZTIExeRunBooLog

Share

Using the power of Orchestrator to move a computer to a different OU via ConfigMgr 2012

The power of Orchestrator 2012 to automate actions is getting bigger and bigger, as the community for it grows and by that the number of Integration Packs (IPs). Of course there are also IPs for ConfigMgr, from both Microsoft itself and the community (via CodePlex). Besides that there wasn’t a real integration between ConfigMgr and Orchestrator, yet, but with MDT 2012 Update 1 a really nice new cool feature was introduced. This feature is the Execute Runbook –step during a Task Sequence. It gives anyone, with or without real programming skills, more robust options during a Task Sequence, as long as an IP exist for the action anyone wants to perform. Just remember, lots of these IPs are created by the community. So deliver useful feedback on them, or even better add your own actions, or IPs.

Prerequisites

In this post I want to show this new feature by creating a runbook for, an often requested script, or step, to move a(n existing) computer to a different OU. For the rest of the post the following points are prerequisites:

  • A Microsoft Deployment Toolkit 2012 Update 1 –package. This package contains the necessary scripts to execute a runbook during a task sequence.
  • The Nework Access Account needs to be “Orchestrator User”. By default the Execute Runbook –step will use the credentials of the Network Access Account to connect with Orchestrator.
  • Register, Deploy and Configure the Active Directory IP from Ryan Andorfer. I used this one, because it was easy to set up and, even more important, it works (even with Orchestrator 2012 SP1 BETA)!
  • The account used in the Connection Credentials needs to be at least member of the Account Operators –group in the Active Directory (AD). Otherwise it can’t move an object in the AD.

Runbook

RunBooMovCom

Let’s start with configuring this nice and basic runbook. This runbook will contain three steps with the following configuration:

  • Add an Initialize Data –activity and double-click it. In the Details Information click Add and a new parameter named Parameter 1 will be added. Now click Parameter 1 and change the name to ComputerName click Ok and click Finish.
  • Add a Get Object DistinguishedName –activity, link it with the previous activity and double-click it. In the Properties, fill in with DomainName <aDomainName> and fill in with Object Class computer. Then right-click the field next to Object Name select Subscribe > Published Data. In the Published Data –popup, select with Activity Initialize Data, select ComputerName, click Ok and then click Finish.
  • Add a Move AD Object –activity, link it with the previous activity and double-click it. In the Properties right-click the field next to Source Object LDAP Path select Subscribe > Published Data. In the Published Data –popup, select with Activity Get Object DistinguishedName, select Object_LDAP_Path and click Ok Then fill in with Destination Container OU LDAP Path <aOULDAPPath> and click Finish.
    • Note: Of course the Destination Container OU LDAP Path can also be (partly) filled with a Published Data. This basic sample is just to show the possibilities.

Task Sequence

TasSeqEdiMovComNow let’s start with the configuring the task sequence. To execute the runbook from the task sequence add the following steps and configuration:

  • Add an Use Microsoft Deployment Toolkit Package –step and Browse to the Microsoft Deployment Toolkit 2012 Update 1 –package.
  • Add and Execute Runbook –step, fill in with Orchestrator Server <aOrchestratorServer> and Browse with Runbook to the just created runbook. Then select Specify explicit runbook parameters, fill in with ComputerName %_SMSTSMachineName% and click Ok.
    • Note: By doing this the ComputerName –parameter from the Initialize Data –activity will be set to the computer name of the system running the task sequence.

Result

The default ConfigMgr task sequences are not able to move a computer object to an OU when it already exist in the AD. Running this task sequence will now result in the computer object being moved to the OU specified in the Move AD Object –activity, even when the computer object already existed in the AD. There are multiple places to look for the results of this action. Think about the log files (smsts.log and ZTIExecuteRunbook.log), the AD and the Orchestration Console. Of this last option I’ll show the results here:ActDetMovCom

Share