Install computer-targeted application during OS deployment via PowerShell and ConfigMgr 2012

A few months ago I did a blog post about installing user-targeted applications during operating system deployments via PowerShell and ConfigMgr. This time I will do a similar post, on request, about installing computer-targeted applications during operating system deployments. Yes, I know it might be worth a discussing about why someone is still using computer-targeted deployments, but that will not be a part of this blog post.

Script

A big part of this script, and by that also this post, might look familiar, as it’s based on the previous script for user-targeted applications. Just like with that previous script I will go through all the key steps of the script. The following five steps make sure that I only get the applications that are required for the computer. Also, in case there is nothing targeted a new variable will be created to prevent the Install Application step from starting.

Step 1 – Get the container node

The first step is to get the container node of the application deployment collections. This will be used to make sure that only (device-)collections used for application deployments will be queried. This information can be retrieved in WMI in the class SMS_ObjectContainerNode. This class shows the different folders in the console and its location. The property ObjectTypeName can be used to see the type of objects in the folder. In my case, I occasionally use identical folder names. So to get the container node information that I need, I use the following code snippet:

$ContainerNodeId = (Get-WmiObject -ComputerName $SiteServer ` -Class SMS_ObjectContainerNode ` -Namespace root/SMS/site_$SiteCode ` -Filter "Name='$Container' and ` ObjectTypeName='SMS_Collection_Device'").ContainerNodeId

Step 2 – Get the collections

The second step is to get the collections within the container with a specific collection member. This information can be retrieved in WMI via the classes SMS_ObjectContainerItem and SMS_FullCollectionMembership. This first class shows the relation between an container and the objects within an container and the second class shows the different collection members and their memberships. So to get the collections within the container and with a specific collection member, I need to join these two classes. To do this, I use the following code snippet:

$CollectionIds = (Get-WmiObject -ComputerName $SiteServer ` -Namespace root/SMS/site_$SiteCode -Query "SELECT fcm.* ` FROM SMS_FullCollectionMembership fcm, ` SMS_ObjectContainerItem oci ` WHERE oci.ContainerNodeID='$ContainerNodeId' ` AND fcm.Name='$ResourceName' ` AND fcm.CollectionID=oci.InstanceKey").CollectionId

Step 3 – Get the targeted applications

The third step is to get the applications that are targeted to the filtered collections. This makes sure that only applications deployed to collections, of which the device is a member, will be filtered. This information can be found in WMI in the class SMS_ApplicationAssignment. The property OfferTypeID can be used to see if the deployment is required or available and I only want to have the required applications. So this makes that I use the following code snippet:

$ApplicationNames = (Get-WmiObject -ComputerName $SiteServer ` -Class SMS_ApplicationAssignment ` -Namespace root/SMS/site_$SiteCode ` -Filter "TargetCollectionID='$CollectionId' and ` OfferTypeID='0'").ApplicationName

Step 4 – Create the task sequence variables

The fourth step is to create task sequence variables for the applications that have to be installed during the OS deployment. For every application I create a task sequence variable named APPIdXX with the value of the application. To achieve this I use the following code snippet:

foreach ($ApplicationName in $ApplicationNames) { $Id = "{0:D2}" -f $Count $AppId = "APPId$Id" $TSEnv.Value($AppId) = $ApplicationName $Count = $Count + 1 }

Step 5 – Create an extra task sequence variable

The fifth, and last, step is to create a task sequence variable in case there are no applications targeted to the computer. This variable can be used to skip the Install application step, to prevent it from failing. As a Install application step will fail when there is a base variable configured, but there are none supplied during the task sequence. To achieve this I use the following code snippet:

else { $TSEnv.Value("SkipApplications") = "True" break }

>> The complete script is available via download here on the TechNet Galleries! <<

Usage

Now download the PowerShell script via the link above and add the PowerShell script to an old-school Package, so it will be available for a task sequence. Then create a standard Install an existing image package task sequence. Now edit the task sequence and make sure the following steps are included:

  • InstCompTargAdd a step Run PowerShell Script with the following settings:
    • Package: <NameOfPackageThatContainsTheScript>
    • Script name: <NameOfTheScript>
    • Parameters: %_SMSTSMachineName%
      • Note: The script needs more input parameters, but I usually add those parameters directly in the script as they are “static” per environment.
    • PowerShell execution policy: Bypass
  • Add a step Install Application with the following settings:
    • Select Install applications according to dynamic variable list
    • Base variable name: APPId
    • Add Condition Task Sequence Variable SkipApplications not exists

Note: The computer account running the script needs read access to ConfigMgr. So in most cases this would mean that the Domain Computers need read access to ConfigMgr. This can be achieved via the build-in role of Read-only Analyst

Share

Unexpected results: Use role based administration to provide different access to specific applications in ConfigMgr 2012

This time I want to address a specific scenario around role based administration. This scenario will be focused on providing different levels of access, for a user, on different applications. I’ve seen this question on different forums over the last year(s) and also had this same question with a customer recently.

Scenario

This scenario is about a enterprise customer that uses ConfigMgr for managing their laptops. Nothing special, so far, not even the fact that they have around 100k laptops spread over the globe. What makes this customer special is the fact that they have a global IT department and a local IT department per country. The global IT department is responsible for making the generic applications available and the local IT department is responsible for making country specific applications available. Because of this, their requirement, for the local IT department(s), is to have read access to all global applications and full access to their own applications.

Solution

Actually the solution to this was a lot simpler then I initially thought. The only thing I could think about was that a user, or group, can only be configured once as a ConfigMgr user. Of course it’s very simple to work around this, by using security group(s), like every one should be in the first place. To solve this scenario, for one local IT department, we need the following:

  • Two AD security groups.
    • Both security groups contain the local IT department administrators;
  • Two Security Scopes;
    • One security scope will contain the global IT department applications;
    • One security scope will contain the local IT department applications;
  • Two Security Roles;
    • One security role will contain full access to applications (in this case the built-in role Application Administrator is sufficient).
    • One security role will contain read-only access to applications (in this case the built-in role Read-only Analyst is sufficient).

Now put this all together in Administration workspace, via Add User or Group on the Home tab in the Administrative Users node. Via the dialog box combine the AD security groups with the Security Roles and Security Scopes. For this last one make sure to select Only the instances of objects that are assigned to the specified security scopes or collections and select only the specific Security Scope. This should result in something like this:Overview

Result

After these configurations it’s time to look at the results of the configurations. I do have to say that I was quite surprised by a part of the result and also can’t explain it, yet. To provide a good overview of the results, I putted three default right-click menu’s, for applications, next to each other. On the left is the right-click menu of a user with only Application Administrator rights on applications. In the middle is the right-click menu of a user with only Read-only Analyst rights on applications. Last, but not least, on the right is the right-click menu of a user with Read-only Analyst rights on the specific application and Application Administrator rights on other applications. Besides the normal read-only access, the user suddenly also has the rights to move, deploy and distribute the application. I can’t explain this behavior, yet.

Application administrator Read-only analyst Read-only analyst (with Application administrator on other applications)
FullAdmin ReadOnly01 ReadOnly02
Share

Install User-targeted Applications during OS Deployment via PowerShell and ConfigMgr 2012

Let’s start my first post of this great new year with another nice PowerShell script. This post will be about deploying required user targeted applications, to the device of the primary user, during OS deployment. Yes, I know the setting of Pre-deploy software to the user’s primary device, but that doesn’t give enough control. After deployment, the device has to be completely ready for use.

A bit more than a year ago I already did a post about pre-provisioning user applications during OS deployment via Orchestrator and ConfigMgr 2012. This time I wanted to make less assumptions. I also wanted to be sure that a user is a member of a collection and what the application is that is deployed to the collection. I first tried to achieve this goal by adjusting my runbook in Orchestrator and I made it work (and it still works), but to make it work I had to use all custom PowerShell activities. This made me think why I still wanted this and I couldn’t come up with something better than “because I can”. So I decided to make one PowerShell script to find the applications and to create the task sequence variables.

Script

The main part of this script is gathering data and filtering it. In short I could say this script consists of five queries and an action. The following six steps make sure that I only get the applications, that are required for the primary user of the device, to be installed during the OS deployment.

Step 1 – Get the Primary User

The first step is to get the primary user of the device that’s being deployed. That information can be retrieved in WMI in the class SMS_UserMachineRelationship. This class shows the relationship of a user with a device, even when it’s only a suggestion yet. The properties of Sources and Types can be used to see how the primary user is defined and to see if it’s a suggestion or a “real” affinity. I know that, in my case, all the device affinities are administrator defined. So to get the user name of the primary user of a device I use the following code snippet (format is <Domain>\<User>:

$PrimaryUser = (Get-WmiObject -ComputerName $SiteServer ` -Class SMS_UserMachineRelationship ` -Namespace root\SMS\Site_$SiteCode ` -Filter "ResourceName='$ResourceName'").UniqueUserName

Step 2 – Get the Container Node

The second step is to get the container node of the application deployment collections. This will be used to make sure that only collections used for application deployments will be queried. This information can be retrieved in WMI in the class SMS_ObjectContainerNode. This class shows the different folders in the console and its location. The property ObjectTypeName can be used to see the type of objects in the folder. In my case, I occasionally use identical folder names. So to get the container node information that I need, I use the following code snippet:

$ContainerNodeId = (Get-WmiObject -ComputerName $SiteServer ` -Class SMS_ObjectContainerNode ` -Namespace root/SMS/site_$SiteCode ` -Filter "Name='$Container' and ` ObjectTypeName='SMS_Collection_User'").ContainerNodeId

Step 3 – Get the Collections

The third step is to get the collections within the container. This information can be retrieved in WMI in the class SMS_ObjectContainerItem. This class shows the relation between an container and the objects within an container. So to get the collections within the container I use the following code snippet:

$InstanceKeys = (Get-WmiObject -ComputerName $SiteServer ` -Class SMS_ObjectContainerItem ` -Namespace root/SMS/site_$SiteCode ` -Filter "ContainerNodeID='$ContainerNodeId'").InstanceKey

Step 4 – Filter the Collections

The fourth step is to filter the collections on a specific collection member. This will make sure that only collections used for application deployments AND with the specific collection member will be queried later on.  This information can be found in WMI in the class SMS_FullCollectionMembership. This class shows the different collection members and their memberships. The best thing, the property SMSID shows the collection member in exactly exactly the same format as I have the primary user of the device. So to filter the collections I use the following code snippet:

$CollectionId = (Get-WmiObject -ComputerName $SiteServer ` -Class SMS_FullCollectionMembership ` -Namespace root/SMS/site_$SiteCode ` | Where-Object {$_.CollectionID -eq $InstanceKey -and ` $_.SMSID -eq $PrimaryUser}).CollectionId

Note: For an unknown reason, to me, a normal filter did not work together with the property SMSID. That’s why I had to use an where-object statement.

Step 5 – Get the targeted Applications

The fifth step is to get the applications that are targeted to the filtered collection. This makes sure that only applications deployed to collections, of which the primary user of the device is a member, will be filtered. This information can be found in WMI in the class SMS_ApplicationAssignment. The property OfferTypeID can be used to see if the deployment is required or available. I only want to have the required applications. So this makes that I use the following code snippet:

$ApplicationNames = (Get-WmiObject -ComputerName $SiteServer ` -Class SMS_ApplicationAssignment ` -Namespace root/SMS/site_$SiteCode ` -Filter "TargetCollectionID='$CollectionId' and ` OfferTypeID='0'").ApplicationName

Step 6 – Create the Task Sequence Variables

The sixth, and last step, is to create task sequence variables for the applications that have to be installed during the OS deployment. For every application I create a task sequence variable named APPIdXX with the value of the application. To achieve this I use the following code snippet:

foreach ($ApplicationName in $ApplicationNames) { $Id = "{0:D2}" -f $Count $AppId = "APPId$Id" $TSEnv.Value($AppId) = $ApplicationName $Count = $Count + 1 }

Note: In the complete script I already created a variable $Count with the value 0 and an object named $TSEnv of Microsoft.SMS.TSEnvironment.

>> The complete script is available via download here on the TechNet Galleries! <<

Usage

Now download the PowerShell script via the link above and add the PowerShell script to an old-school Package, so it will be available for a task sequence. Then create a standard Install an existing image package task sequence. Now edit the task sequence and make sure the following steps are included:

  • imageAdd a step Run PowerShell Script with the following settings:
    • Package: <NameOfPackageThatContainsTheScript>
    • Script name: <NameOfTheScript>
    • Parameters: %_SMSTSMachineName%
      • Note: The script needs more input parameters, but I usually add those parameters directly in the script as they are “static” per environment.
    • PowerShell execution policy: Bypass
  • Add a step Install Application with the following settings:
    • Select Install applications according to dynamic variable list
    • Base variable name: APPId

Note: The computer account running the script needs read access to ConfigMgr. So in most cases this would mean that the Domain Computers need read access to ConfigMgr. This can be achieved via the build-in role of Read-only Analyst.

Share

Showing Dependent Applications in ConfigMgr 2012 via PowerShell

ShowApplDepeThis week I want to devote a blog post to finding dependent applications. Via the ConfigMgr Console it’s very easy to find the configured Dependencies of an Application, but what if I want to know which applications depend on a specific Application? Via the ConfigMgr Console this is not possible (out-of-the-box), but this doesn’t mean that the information is not accessible. In this blog post I will show where to find this information and I will show a complete script which will show the results in a nice form.

Solution

In WMI there is the class SMS_AppDependenceRelation. This class doesn’t contain any methods, but does contain a few interesting properties. These interesting properties are FromApplicationCIID, FromDeploymentTypeCIID, ToApplicationCIID and ToDeploymentTypeCIID. The properties mainly speak for themselves, they contain the CI IDs of the Applications and Deployment Types that depend on each other. The ConfigMgr Console shows the From-To relations and, in this post, I’m searching for the To-From relations. So to get the Applications that depend on a specific Application(CIID), I use the following code snippet:

$DependentApplications = Get-WmiObject -Class SMS_AppDependenceRelation ` -Namespace root/SMS/site_$($SiteCode) -ComputerName $SiteServer ` -Filter "ToApplicationCIID='$ApplicationCIID'"

Now that I know where to get the information, I need to be able to translate it to something readable. For that I will use the class SMS_ApplicationLatest for the Applications and the class SMS_DeploymentType for the Deployment Types and, in both cases, I locate the property LocalizedDisplayName to get a readable name. So to get, for example, the Application name, I use the following code snippet:

$ApplicationName = (Get-WmiObject -Class SMS_ApplicationLatest ` -Namespace root/SMS/site_$($SiteCode) -ComputerName $SiteServer ` -Filter "CI_ID='$ApplicationCIID'").LocalizedDisplayName

Result

ShowDepeApplv09The complete script will show the results of the dependent Applications in a nice form and is available via the TechNet Galleries. The nice thing about the form is that it can also be used as a right-click action. The usage of the script is with the article on the galleries. Please let me know what you think of the script.

>> Available via download here on the TechNet Galleries! <<

Share

Using Global Conditions to check the State of a Service with ConfigMgr 2012

This week my post will be about using a Global Condition to check the State of a service. I came to this, as I was once again deploying my UE-V Agent, like here, but this time via a normal Deployment. This installation will only run, without failure, when the Offline Files Service (CscService) is running. So a Requirement for the Deployment Type should be that the service is running. As I like to find ways to do things without the need of scripts/ scripting, I came to using a standard Global Condition.

Configuration

Now lets take a look at how we can configure a Global Condition, in such a way, that it checks for the State of a service. During the configuration steps I will use the Offline Files Service (CscService) as an example.

  • GlobCondStatServIn the Configuration Manager Console, navigate to Software Library > Overview > Application Management > Global Condition.
  • On the Home tab, click Create > Create Global Condition and the Create Global Condition –popup will show.
  • Now fill in the following information and click Ok.
    • Fill in as Name <aName>.
    • Select as Device type Windows.
    • Select as Condition type Setting.
    • Select as Setting type WQL query.
    • Select as Data type String.
    • Fill in as Namespace root\cimv2.
    • Fill in as Class Win32_Service.
    • Fill in as Property State.
    • Fill in as WQL query WHERE clause: Name=’CscService’.

After configuring the Global Condition, lets add it as a Requirement on a Deployment Type. During these configuration steps I will use the UE-V Agent as an example.

    • AddRequStatServIn the Configuration Manager Console, navigate to Software Library > Overview > Application Management > Applications.
    • Select the UE-V Agent Application and on the Deployment Types –tab double-click <aDeploymentType>.
    • On the Requirements –tab, click.Add… and the Create Requirement –popup will show.
    • Now fill in the following information and click Ok.
      • Select as Category: Custom.
      • Select as Condition: <aName>.
      • Select as Rule type: Value.
      • Select as Operator: Equals.
      • Fill in as Value: Running.

Result

As always, now it’s time to show the results. In this case I’m not going to show any log files, but I’m going to use the Simulate Deployment option. This option is specifically designed for testing the Requirements for an Application. I like to think that the best way to test a custom Requirement/ Global Condition is to test it with a wrong Value. The reason for that is that it will show the results of the Requirement in the Requirements Not Met –tab of the Deployment Status. In my case I tested it with the Value Stopping, while I knew that it was Running. See here the results of that test.AsseDetaStatServ

Share

Managing Approval Requests in ConfigMgr 2012

ApprRequThis week I want to devote a post to managing Approval Requests in ConfigMgr 2012. I’m not going to discuss whether the current model works, or not, I’m just going to say that in general it won’t work. The reason for that is simple, because it’s just one big list for everyone and every single Approval Request. To fill a small gap here, there is the Application Approval Workflow (solution accelerator), but for that also System Center 2012 – Service Manager and – Orchestrator are required. This just doesn’t fill the gap for everyone and/ or every company. So where does this leave us?

Approval Manager

ApprManaInstead of complaining about all this, something that’s in a humans’ nature to do, we can also look at the options that we do get. With ConfigMgr 2012 SP1 we’ve been given PowerShell Cmdlets for ConfigMgr 2012! Many has been written about that already, so here I’m just going to give an example of what can be done with it. What I did was, with some help of PrimalForms Communtiy Edition, create a basic form, with some buttons and a selection box, to manage Approval Requests. The basic idea behind it, is to give somebody a list with users and let him manage the Approval Requests for those users only. By default the form shows all the Approval Requests for a specific user and gives the option to only show the Approval Requests that are waiting for approval. Then the Approval Requests that are still waiting for approval can be either approved, or denied.

Code

Now lets take a look at the cmdlets used for creating a basic form like this. Besides the code used for creating the form, I used the following cmdlets for the actions specified with it. The first I needed to do, was to get a specific list of users. This can be achieved by using the Get-CMUser cmdlet, which can be used to retrieve user objects from a specific collection. As I only needed the SMSID property, I used the following command:

Get-CMUser -CollectionID $CollectionID | Select SMSID

The second thing I needed to do, was to get a list of Approval Requests for a specific user. This can be achieved by using the Get-CMApprovalRequest cmdlet, which can be used to retrieve a list of requests for a specific user. As I only wanted the Application, CurrentState and User properties, I used the following command:

Get-CMApprovalRequest -User $User | Select Application,CurrentState,User

A nice small follow up on this list is that it’s also very easy to create a list of Approval Requests with the state of Requested. This is an small and easy change, because an Approval Request knows the following 4 states:

  • 1 – Requested
  • 2 – Cancelled
  • 3 – Denied
  • 4 – Approved

So a list with only Approval Requests, with the state Requested, can be easily achieved with the following command (which is a small change, in query, from the general list):

Get-CMApprovalRequest -User $User | Select Application,CurrentState,User | Where CurrentState -eq 1

The third thing I needed to do, was to create an option to Approve an Approval Requests for a specific user. This can be achieved by using the Approve-CMApprovalRequest cmdlet, which can be used to approve a request for a specific application of a specific user. As it also needs a comment, I used the following command:

Approve-CMApprovalRequest -Application $ApplName -User $User -Comment "Request approved."

The fourth, and also last thing I needed to do, was to create an option to Deny an Approval Requests for a specific user. This can be achieved by using the Deny-CMApprovalRequest cmdlet, which can be used to deny a request for a specific application of a specific user. As it also needs a comment, I used the following command::

Deny-CMApprovalRequest -Application $ApplName -User $User -Comment "Request denied." 

Conclusion

This was my first real, but small, PowerShell project in ConfigMgr 2012 and I do have to say that I really like the power of it. It makes it very easy to automate console action. One thing that is important to note is, that it’s also via PowerShell not possible to do something with already approved, or denied Approval Requests.

In case someone wants to see/ have the complete code, I will upload it somewhere next week. For those, that can’t wait, don’t hesitate to contact me.

Share

Preventing initiation of available deployments on specific systems with ConfigMgr 2012

This week I want to devote a small post to a question that I read on windows-noob.com. The question came to the point whether, or not, it is possible to deploy applications via a task sequence, but only allow administrators to actually run it. This question triggered me to look a bit better into the different Client Settings and then specifically the setting of Install permissions. This setting gives us the possibility to prevent the initiation of available deployments via the Software Center and the Application Catalog on specific systems. So in this post I will show that setting by only allowing administrators to initiate available deployments.

Configuration

CompAgenInstPermNow lets start with the configuration, which is actually very easy, but like always it’s all about knowing that the possibility exists. The Install permissions –setting is another new (Computer) Client Setting under Computer Agent. This setting can be used to allow All users (default), Only administrators, Only administrators and primary users or No users to initiate available deployments on a specific system. 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 Computer Agent.
  • On the Computer Agent page, select next to Install permissions Only Administrators and click Ok.
  • 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 system(s). Normally I’m a huge fan of looking at the client logs for the results, but in this case the log files don’t “speak” as much as the real error messages. When a normal users now logs on to the system and tries to initiate an available deployment, the following error messages will appear.

Software Center Application Portal
SoftCentInstErro PortInstErro
Share

Troubleshooting Windows app package deployment on Windows 8 with ConfigMgr 2012

This week I was planning on doing a post about deploying a Windows app package (.appx) on Windows 8, until I saw that Keith Mayer already just posted a Step-by-Step for that. As that post is, from a ConfigMgr perspective, already very complete, I changed, from my original plan, to troubleshooting the deployment of a Windows app package (.appx) on Windows 8. The deployment of a Windows app package (.appx) on Windows 8 requires two specific settings and in this post I will describe those settings and the errors that will appear when these settings are forgotten.

Import the root certificate as a Trusted Root Certification Authority

The first setting is that the app package has to be signed with a certificate chain that can be validated by the local computer. In other words the root certificate has to be trusted by the local computer. When this is not configured correctly, both, the AppDiscovery.log and the AppEnforce.log, will show error 800B0109. The nice thing is that the AppEnforce.log will also implicate what the problem is, see this log snippet (followed by a picture of the complete error in the log):

In-line script returned error output: Add-AppxPackage : Deployment failed with HRESULT: 0x800B0109, A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider. (Exception from HRESULT: 0x800B0109) error 0x800B0109: The root certificate of the signature in the app package must be trusted.

AppEnfo800B0109

TrusRootCertPoli

The easiest way to correctly import the root certificate for all computers is by using Group Policies. To configure this follow the next steps:

  • Open the Group Policy Management Editor and navigate to Computer Configuration \ Policies \ Windows Settings \ Security Settings \ Public Key Policies.
  • Right-click Trusted Root Certification Authorities, select Import… and the Certificate Import Wizard will show.
    • On the Welcome page, click Next.
    • On the File to Import page, Browse to the certificate and click Next.
    • On the Certificate Store page, click Next.
    • On the Completion page, click Finish.

Allow all trusted apps to install

The second setting is that the local computer is allowed to install trusted app packages that do not originate from the Windows Store. When this is not configured correctly, both, the AppDiscovery.log and the AppEnforce.log, will show error 80073CFF. The nice thing is again that the AppEnforce.log will implicate what the problem is, even though it’s a bit more cryptic this time, see this log snippet (followed by a picture of the complete error in the log):

In-line script returned error output: Add-AppxPackage : Deployment failed with HRESULT: 0x80073CFF, To install this application you need either a Windows developer license or a sideloading-enabled system. (Exception from HRESULT: 0x80073CFF) Deployment of package bc25cdcc-f901-4f91-91a7-55a74a247376_1.0.0.0_neutral__tbz3402trp7yy failed because no valid license or sideloading policy could be applied. A developer license (http://go.microsoft.com/fwlink/?LinkId=233074) or enterprise sideloading configuration (http://go.microsoft.com/fwlink/?LinkId=231020) may be required.

AppEnfo80073CFF

AppPackDeplPoli

Also for allowing all trusted apps to install, the easiest way to correctly configure that for all computers is by using Group Policies. To configure this follow the next steps:

  • Open the Group Policy Management Editor and navigate to Computer Configuration \ Policies \ Administrative Templates \ Windows Components \ App Package Deployment.
  • Double-click Allow all trusted apps to install, select Enabled and click OK.

Note: Before the app package is a trusted app package, the (root) certificate, that is used for signing the app package, has to be trusted.

Share

Working with the restart behavior of Applications in ConfigMgr 2012

This week I will do a small post about working with the restart behavior of installations in combination with the Application Model in ConfigMgr 2012. In previous versions there was sometimes a need to use a batch file to catch some weird installation return codes. The nice thing about ConfigMgr 2012 is that it gives us a possibility to specify those return codes and to react on it. In the rest of this post I will show in three steps how to configure ConfigMgr 2012 to work with return (restart) codes.

Step 1: Return codes

RetuCodeRestThe first thing I always do is running the installation of an application a few times and see which return codes it gives me. Based on those experiences I create, if needed, some extra entries in the Return Codes –tab of the Properties of the Deployment Type. By default the following return codes are pre-defined:

  • 0 – Success (no reboot)
  • 1707 – Success (no reboot)
  • 3010 – Soft Reboot
  • 1641 – Hard Reboot
  • 1618 – Fast Retry

Step 2: Enforce specific behavior

UserExpeBehaThe second thing I do is determining how I think the client should react on the return codes. This can be configured, on the User Experience –tab of the Properties of the Deployment Type, by selecting one of values under Should Configuration Manager enforce specific behavior regardless of the application’s intended behavior?. The following options are available (including small explanation):

  • Determine behavior based on return codes – (Default) The client will perform any action needed based on the return code of the application.
    • Note: In this case a good configuration in the first step is very important.
  • No specific action – The client won’t perform any action.
    • Note: In this case it is possible to completely suppress a restart.
  • The software install program might force a device restart – The client is told that the installation will force a restart.
  • Configuration Manager client will force a mandatory device restart – The client will always perform a restart.

Step 3: Restart behavior

ClieRestSettThe third, and last, thing I do is more a general client setting. From the moment we decide to restart the device we should think about the configuration of the Computer Restart –settings in the Client Settings. The following Device Settings can be configured:

  • Display a temporary notification to the user that indicates the interval before the user is logged of or the computer restarts (minutes) – Default is 90 minutes.
  • Display a dialog box that the user cannot close, which displays the countdown interval before the user is logged of or the computer restarts (minutes) – Default is 15 minutes.

Conclusion

The combination of these three steps gives us a lot of options to work with the restart behavior of installations. In most cases the default configuration is perfect, but in some case some tuning is needed. For example, the installation of an application is not allowed at any time. This can be achieved by either configuring a custom return code in the first step, or by specifying No specific action in the second step.

Note: There are also Maintenance Windows and/ or Business Hours, that can influence the restart behavior. I didn’t mention them here, because, yes they can exist, but there should always be a moment that we “touch” a users’ device and this is about that moment.

Share

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

Share