This is an article in a continuing series on the new Application model in SCCM 2012. You can find a high level overview of applications and how they differ from packages here: SCCM 2012: Applications vs. Packages – (windowsmanagementexperts.com)
Requirements allow administrators to target applications to users or devices that meet a certain setof conditions. The application model in SCCM 2012 expands greatly on the available requirements for packages. Now, administrators can target applications based on a wide variety of pre-defined rules. This part in the series will focus on the three categories of requirements: user, device, and custom.
You can add requirements to your application by opening the “Deployment Type” that needs a requirement and going to the “Requirements” tab. From here, you select “Add” and the category of the requirement. Multiple requirements can be added to one application.
User Requirements
There is one condition when selecting the user category – Primary device. For those new to SCCM 2012, the system assigns a computer to a user (known as Primary device) based on a time length that is set in the device client settings. This time-length can be set to whatever the administrator feels is appropriate. I have mine set to 8 hours (one working day) in a 14 day span (two working weeks).
This condition allows you to ensure that an end user can only install the application on their primary device. This can help a lot with licensing, because you can guaranteed that a user will not be able to walk around an organization and install a licensed program on multiple computers.
The converse is also true; you can set it where a user cannot install a given application on their primary device. I am not really sure why this would be necessary, but it is an option.
Device Requirements
Device requirements is exactly what it says – the administrator can base application installs on device information. Options include number of processors, memory amount, hard drive space requirements, etc. Any of these options come with logical operators so that targeting is simple.
This is also where administrators now set operating system requirements. This helps to ensure that end users are not trying to install 64-bit applications on 32-bit machines, and also that applications that require Windows 7 are not being installed on Windows XP. This condition works exactly the same way as it does with packages.
Two new options here are “Active Directory site” and “Organizational Unit”. Both of these options can be used to deploy an application to devices in a particular department without having to build a collection in SCCM for them. If your AD is already set up for department-based OU’s, there is no need to build a collection to deploy the application too. The administrator can simply define one of these conditions and be done.
Also, if you have multiple sites, applications can be required to be in one site or another using the “Configuration Manager site” condition. The “Operator” option allows the administrator to define an allowed group of sites, or a disallowed group of sites.
Custom Requirements
The custom category can cover anything that the user or device categories do not. There are options for file system, scripts, and SQL queries, just to name a few. As said in previous parts of this series, please always pay attention to the check-boxes talking about associating the requirement with a 64-bit application.
The four most useful custom conditions are file system, registry key / value, SQL query, and script. The file system condition can be used to detect if files or folders are / are not present. The application install can then be based on this. The same applies for the registry. This can be especially helpful with deploying application updates or add-ons where a base application is needed. The administrator can use these settings to define the rules by which these updates or add-ons are installed.
SQL queries can also be very helpful. The ability to query a SQL database opens up almost endless possibilities for application management. One such option is to create an application database for managing license numbers and which users should be able to install certain applications to keep within license agreements. It could also be used to query help-desk systems to see if an application is needed somewhere.
Finally, scripts can cover any other holes in requirements. You can load other libraries on the system to test for things, use WMI to test conditions, or anything else that is doable with a script. When you select Script, you are given the option to add one. From here, there are three scripting languages available: Jscript, Windows Powershell, and VBScript. From there, you can type your script in the box, or you can click “Open” and select a script that you already have prepared.
Summary
Exploring all of the new Requirement conditions in SCCM 2012 can really help with application deployment. Administrators can further ensure applications are only being installed on devices that need them and can adequately run them. If an application does not meet the defined requirements, it will show up the deployment reports for the application. This allows the administrator to see exactly why an application isn’t suited for installation on a particular device. In the context of IT migration services, properly defined requirement conditions become even more critical. As organizations transition systems, applications, and devices to new environments, ensuring compatibility and readiness helps prevent deployment failures and post-migration disruptions. Leveraging these controls allows IT teams to execute migrations more efficiently while maintaining stability across the environment.
