Recently I’m more often confronted by customers who ask me a vital question using SCCM 2012 for content distribution. The question is: how about managing settings for an application or generic Windows configuration settings?
The easy answer is: it depends…
However, it doesn’t really help the customer that much.
Not only are customers confronted with diversity in their organizations, departments often require different settings for the same application or Windows environment.
Application packaging specialists are also confronted in the process as well since they need to do the application scripting. Environments who require different settings for the same application confronts them with the question how to provide the different settings to the end user. It may be clear that creating the same package multiple times to have the different settings inside the package is most likely NOT the right strategy. I strongly believe in the approach in keeping the custom part of any deployment of technology as little as possible, the more standard the technology the better its reusability. This gives the customer more freedom in upgrading the technologies to their needs.
Unfortunately, it happens quite often that organizations depend so much on this heavily customized technology that it will effectively prevent them from upgrading/migrating to something newer. I guess most of us saw organizations still use the aging Windows XP SP3 with Internet Explorer 6 because the organization’s core application can only run on Internet Explorer 6 and the company supporting this application is out of business or terminated the support for the application.
Other technologies exist such as GPO/GPP. However, having a lot of GPO/GPP objects can significantly slow down user experience due to slow logons. Managing these objects might require a lot of administrative effort on the Active Directory administrator. Scripts, registry files are possible but these cannot guarantee that they are properly deployed.
So, we can conclude that a suitable mechanism must be available that allows administrators to easily deploy, manage and modify settings for the applications they need to distribute in the IT environment.
SCCM 2012 provides a method to deploy these kind of settings by means of Configuration Items. In this blog, a few registry settings will be set and modified to demonstrate its usage.
The application in this example is Microsoft App-V 4.6 SP1 client. The application is deployed using a default silent setup using the following command: setup.exe /s /v/qn
The goal is to modify the client to run in standalone mode which can be achieved by modifying at least the following registry keys (some settings may differ to satisfy your needs):
A single Configuration Item is created which consists of three settings, one for each registry key.
For each setting, a compliance rule is created to check what the setting needs to be.
Remediation of noncompliant rules needs to be enabled to have the settings modified to meet the compliance rules set.
Once the Configuration Item has been created, it needs to be added to a Configuration Baseline. This baseline needs to be deployed to the collection that needs the settings.
It may be obvious that multiple Configuration Items for the same application can be deployed if organizations need different settings.
Modifying the Compliance Rules also allow administrators to change settings if requirements change or an unintentional mistake was made during packaging.
Once the settings have been deployed, Compliancy Reports become available to check if the targets are compliant.
As usual, make sure to test the Configuration Items to determine if the results are applied as expected before deploying them to any production environment.
More information is available at http://technet.microsoft.com/en-us/library/gg681958.aspx