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

Preventing user-targeted applications and policies on specific systems with ConfigMgr 2012

This week I want to devote a small post to something very nice and, in some situations, very easy. Think about a situation where, in general, applications are user-targeted and only a few exceptions are system-targeted. Usually these targeted systems are then used specifically for that application. So these systems shouldn’t get all the applications (and settings) of every user that logs on, as it might screw-up the specific application. The nice thing is that ConfigMgr 2012, and especially SP1, has a solution for this! The solution is the new setting Enable user policy on clients.

Configuration

NoUserPoliciesNow lets start with the configuration, which is actually very easy. Like always it’s all about knowing that the possibility exists. This is another new Client Setting in ConfigMgr 2012, of which the values are renamed in SP1, named Enable user policy on clients. This setting can be used to enable or disable user policies. To configure this, follow the next steps:

  • In the Configuration Manager Console navigate to Administration > Overview > Client Settings.
  • On the Home tab, in the Create group, select Create Custom Client Device Settings and the Create Custom Client Device Settings –popup will show.
  • On the General page, fill in with Name <aName> and select Client Policy.
  • On the Client Policy page, select next to Enable user policy on client No and click Ok.
    • Note: In ConfigMgr 2012 RTM the possible values are True or False.
  • Select the new policy <aName> and on the Home tab, in the Client Settings group, select Deploy.
  • Select <aDeviceCollection> and click Ok.

Result

After the deployment of the new Client Settings it is time to take a look at the impact on targeted client(s). The best places to look at this are the log files. During a User Policy Retrieval & Evaluation Cycle the PolicyAgent.log will show that it will skip the request for user policy (see picture). PolicyAgent

Since ConfigMgr 2012 SP1 this will also disable the ability to install an application from the Application Catalog. In case somebody tries it anyway, the application installation will not start and the PolicySdk.log will show that the user policy is disabled (see picture).PolicySdk

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.

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

Deploying Remote Server Administration Tools for Windows 8 with ConfigMgr 2012

SerManTilThis week I want to devote a post to deploying the Remote Server Administration Tools (RSAT) for Windows 8 using ConfigMgr 2012. Even though the installer is only available as a Windows Update Standalone Installer, in my opinion it should be deployed using the application model in ConfigMgr 2012. This gives me the possibility to show some basics about the manual applications in ConfigMgr 2012 and more specifically, about the Detection Rules and the Requirements.

In a step-by-step way I will go through the wizards of creating and deploying an application. During this I will give some extra explanation with the step about the Detection Rule, as it has to be manually created and there are many options for that. RSAT for Windows 8 can be downloaded here: http://www.microsoft.com/en-us/download/details.aspx?id=28972

Create Application

  • In the Configuration Manager Console, navigate to Software Library > Overview > Application Management > Applications, click Create > Create Application and the Create Application Wizard will show.
  • On the General page, select Manually specify the application information and click Next.
  • On the General page, fill in the information about the application and click Next.
    • Note: Check the box Allow this application to be installed from the Install Application task sequence action instead of deploying it manually to make it possible to use it in a task sequence.
  • On the Application Catalog page, fill in the information about the application and click Next.
  • On the Deployment Types page, click Add and the Create Deployment Type Wizard will show.
    • On the General page, select Manually specify the deployment type information and click Next.
    • On the General Information page, fill in the information about the deployment type and click Next.
    • On the Content page, browse to the Content location, use as Installation program wusa.exe Windows6.2-KB2693643-x64.msu /quiet /norestart, use as Uninstall Program wusa.exe /uninstall Windows6.2-KB2693643-x64.msu /quiet /norestart and click Next.
    • On the Detection Method page there are multiple option to check for the installation. the most important thing to remember for detection rules is to find something unique for that specific installation. Here I will give two good options for detecting RSAT for Windows 8:
      1. DetRuleRSATSelect Add Clause… and the Detection Rule popup will show (see picture). On the Detection Rule Popup, select as Setting Type File System, fill in as Path %WinDir%\System32\, fill in as File or folder name ServerManager.exe, select The file system setting must satisfy the following rule to indicate the presence of this application, select as Property Version, select as Operator Equals, fill in as Value 6.2.9200.16384 and click Ok.
      2. Select Use a custom script to detect the presence of this deployment type, ScrEdiVbsclick Edit and the Script Editor popup will show (see picture). On the Script Editor popup select as Script Type VBScript, use the follow script as Script Contents and click Ok.

        strComputer = “.”
        Set objWMIService = GetObject(“winmgmts:\\” & strComputer & “\root\CIMV2”)
        Set colItems = objWMIService.ExecQuery(“SELECT * FROM Win32_QuickFixEngineering WHERE HotFixID = ‘KB2693643′”)
        If colItems.Count = 0 Then
            Wscript.Quit(1)
        Else
            Wscript.StdOut.Write “The application is installed”
            Wscript.Quit(0)
        End If

    • Back on the Detection Method page click Next.
    • On the User Experience page, select the wanted experience settings and click Next.
      • Note: Select as Installation behavior Install for system if resource is device; otherwise install for user and select as Logon requirements Whether or not a user is logged on to make it possible to use it in a task sequence.
    • ReqRSATOn the Requirements page, click Add and the Create Requirement popup will show (see picture).
      • On the Create Requirement popup select as Categorie Device, select as Condition Operating System, select as Rule Type Value, select as Operator One of, select All Windows 8 (64-bit) and click Ok.
    • Back on the Requirements page click Next.
    • On the Dependencies page click Next.
    • On the Summery page click Next.
    • On the Completion page click Close.
  • Back on the Deployment Types page click Next.
    • Note: To also deploy the 32-bit version of the Remote Server Administration Tools repeat the Deployment Type steps and only change the logical things on the Content page and the Requirements page.
  • On the Summary page click Next.
  • On the Completion page click Close.

Deploy Application

  • In the Configuration Manager Console, navigate to Software Library > Overview > Application Management > Applications, select the new application, select Deployment > Deploy and the Deploy Software Wizard will show.
  • On the General page, Browse to a Collection and click Next.
  • On the Content page, Add a Distribution Point (Group) and click Next.
  • On the Deployment Settings page, select the needed deployment settings and click Next.
    • Note: Select as Purpose Optional to let the user decide and select as Purpose Required to make it mandatory.
  • On the Scheduling page, select the wanted schedule setting and click Next.
  • On the User Experience page, select the wanted experience settings and click Next.
  • On the Alerts Settings page, select the wanted alert settings and click Next.
  • On the Summary page click Next.
  • On the Completion page click Close.

Deploy App-V version of Office 2013 with ConfigMgr 2012

One of the new features coming with the Service Pack 1 release of ConfigMgr 2012 is the support for App-V 5. So what is a better way to try this feature then deploying the just released Microsoft Office 2013 Preview AppV packages in combination with the just released App-V 5.0 Beta 2 Desktop Client. But then the big question is, how can we deploy this? Well, I thought it was pretty straight forward, but there where a few caveats that everyone should know and pay attention to.

Challenge 1: App-V Package Name

The first thing I ran into was that I couldn’t import the Microsoft Office 2013 Preview App-V package in ConfigMgr. It appeared that the default configured Package Name was to long for a Deployment Type in ConfigMgr. To look at this default name use one of the following two methods:

  1. Browse through the App-V package, with something like 7-zip, and look in the AppxManifest.xml at the DisplayName.
  2. Open the App-V package with the Microsoft Application Virtualization Sequencer and look in the Properties tab at the Package Name.

Now to adjust the Package Name use the second method and also save the Application Virtualization file with a shorter name. That was one of the biggest hurdles, as by using the same file name with a different Package Name it was possible to import the package, but the Deployment would always fail with a vague error.

Challenge 2: EnablePackageScripts

The second thing I ran into was that, with the default installation of the App-V 5.0 Beta 2 Desktop Client, the installation of the Microsoft Office 2013 Preview package would still fail. It appeared that the default client installation doesn’t enable scripting on the client, while ConfigMgr uses PowerShell scripts/ command lines to add packages to the App-V client. So to allow this use one of the following three methods:

  1. Install the App-V 5.0 Beta 2 Desktop Client with the parameter ENABLEPACKAGESCRIPTS=1
  2. Use the command Powershell.exe Set-ExecutionPolicy ByPass; Import-Module AppvClient; Set-AppVClientConfiguration -EnablePackageScripts 1
  3. Change the key EnablePackageScripts in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppV\Client\Scripting to 1.

In my opinion is the first option the best option. As everything lately is powershell-minded, scripts should be enabled on the App-V 5.0 Beta 2 Desktop Client by default/ first installation.

Conclusion

OffProPluDepNow taking the two challenges and the prerequisites of the App-V 5.0 Beta Desktop Client into account, the dependency for my Microsoft Office 2013 Preview Deployment Type in ConfigMgr is the App-V 5.0 Beta Desktop Client and the dependencies for my App-V 5.0 Beta Desktop Client are PowerShell 3.0 and .NET Framework 4.0 (see picture). Also note that KB2533623 is also a prerequisite for the App-V 5.0 Beta Desktop Client, but as I don’t deploy that as an Application in ConfigMgr, I can’t configure it as a dependency. To be really sure whether it’s installed, or not, it could always be configured as a  requirement. I didn’t do that either as it’s part of my base image of Windows 7. Another note would be to configure the detection rules for both PowerShell 3.0 and .NET Framework 4.0 good, as in Windows 8 they are both installed by default.

Application Relationships in ConfigMgr 2012 (B2)

As we all know now for a while already, ConfigMgr 2012 (B2) has a new Application Model. The old fashion Packages are still possible, but there is nothing changed and no features added. They are just there to make a migration easier… Instead we’ve got Applications now, which make it easier to detect installed products, to create dependencies, to supersede, etc.. This post I want shine a light on the different relationships of an Application. ConfigMgr 2012 (B2) knows three different types of relationships for an Application:

  1. Dependencies
  2. Supersedence
  3. Global Conditions

Dependencies

DependenciesViewRelationshipLet’s start with the first relationship, dependencies. Dependencies make it easy to specify the software prerequisites of an Application. The cool thing is that this can be multiple things and it can even contain AND and OR statements. For example it’s possible to say that Adobe Reader 9.0 OR Adobe Reader X needs to be present. Besides that it’s also possible to define what needs to be done when neither of them is present. It’s possible to specify which version needs to be auto-installed, or it’s possible to just let it do nothing.

Also good to notice is that this can be done per Deployment Type. See as example the picture on the right. This picture shows the 7-Zip Application, which contains three Deployment Types. One x86 -version, one x64 -version and one App-V –version. This App-V version has as dependency that the App-V Desktop Client needs to be installed.

Supersedence

SupersedenceViewRelationshipThe second relationship is supersedence. Supersedence makes it easy for an administrator to create a relationship between two Applications and “declare” one Application newer than another previous Application. This is actually the same idea that is used with Software Updates already for years now. The supersedence –relationship needs to be specified on an Application –level, but the actions can be specified on a Deployment Type –level. This makes it possible to specify per Deployment Type what the new Deployment Type will be and whether the old version needs to be uninstalled, or that the new version will do an upgrade to the old version (default is upgrade). By specifying the uninstall option, the uninstall command of the superseded Application will be used.

See as example the picture above. This picture shows the new 7-Zip Application, which contains two Deployment Types. One x86 –version and one x64 –version. The x86 –version supersedes the x86 –version of the old Application and the x64 –version supersedes the x64 –version of the old Application.

Global Conditions

The third relationship is Global Conditions. Global Conditions are the most “variable” relationship, because these conditions can be almost everything. Actually Global Condition is, in my opinion, not even the correct term here, it should be Requirement Rules. The relation between these two is that a Global Condition has to be added to a Requirement Rule to be evaluated. Besides this a Global Condition can contain one or more System Attributes, which can be anything from WMI Queries until Registry Values.  The extra cool thing is that Global Conditions can be assigned per Deployment Type. This makes it possible to deploy multiple Deployment Types to the same (User) Collection, but only the one which has all requirements met will be truly deployed.

GlobalConditionsViewRelationshipSee as example the picture on the right. This picture shows the x64 –version Deployment Type of the 7-Zip Application, which contains three Requirement Rules. One for the required Free Disk Space, one for Desktop Type and one for Primary Device. In this case this means that there has to 100 Mb free disk space AND it has to be a x64 –system AND it has to be the users primary device.

Think of all the possibilities this will generate, like deploying the App-V –version Deployment Type only to non primary devices. There is a whole new world going open!