XML and WMI

Let’s start with where it’s stored. In WMI it’s stored in the class SMS_AutoDeployment and then the property ContentTemplate. Here it’s stored in XML format, like this:

<?xml version="1.0" encoding="utf-16"?><ContentActionXML xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema"><PackageID>PTP00027</PackageID><ContentLocales><Locale>Locale:9</Locale><Locale>Locale:0</Locale></ContentLocales><ContentSources><Source Name="Internet" Order="1"/><Source Name="WSUS" Order="2"/><Source Name="UNC" Order="3" Location=""/></ContentSources></ContentActionXML>

PowerShell

Now let’s go to the cool part, how do to change the package id that’s in the ContentActionXML. Well it’s actually quite easy with common XML parsing. To get all ins-and-outs about that, read this great article on the Hey, Scripting Guy! Blog. The first I needed, was to get a direct instance of the specific Automatic Deployment Rule. For that I used the following command:

[wmi]$AutoDeployment = (Get-WmiObject -Class SMS_AutoDeployment -Namespace root/SMS/site_$($SiteCode) -ComputerName $SiteServer | Where-Object -FilterScript {$_.Name -eq $AutoDeploymentName}).__PATH

The second thing I needed to do, was to get the XML content of the ContentTemplate property. For that I used the following command:

[xml]$ContentTemplateXML = $AutoDeployment.ContentTemplate

The third thing I needed to do, was to write the new package id to the PackageId property the ContentActionXML.The nice thing here, is that the different parts of the XML content can now be accessed as properties. So I used the following command to change the package id:

$ContentTemplateXML.ContentActionXML.PackageId = $PackageId

The fourth thing I needed to do, was to write the XML content back to the ContentTemplate property. For that I used the following command:

$AutoDeployment.ContentTemplate = $ContentTemplateXML.OuterXML

The last thing was to save the changes to the Automatic Deployment Rule and for that I used the following command:

$AutoDeployment.Put()

Conclusion

It was actually quite simple to change the Deployment Package, which is linked to an Automatic Deployment Rule, even though it’s not possible via the console. To see if the changes applied, either run the Automatic Deployment Rule and check the ruleengine.log, or run the Get-CMSoftwareUpdateAutoDeploymentRule cmdlet. With the combination of ConfigMgr, WMI, XML and PowerShell, there is little that can’t be changed!

The complete code (and usage) is available via the TechNet Galleries.

Import Computer Form

This public version gives the user the possibility to perform the following actions, without the need of access to and/ or a locally installed ConfigMgr console:

• Fill in a Computer name.
• Fill in a MAC Address.
• Select an OS Deployment Collection.
• Import the Computer Information.
• Close the form.

Security Role

This time I won’t spent to much time on specifying which rights are necessary to Import Computer Information. The reason for that is simple, as it’s been very good explained in this post on the TechNet Blogs. 

Public Available

As of today my Import Computer Form is publicly available via the TechNet Galleries. Please let me know what you think of the tool.

Approval Manager

This updated version gives the user the possibility to perform the following actions, without the need of access to and/ or a locally installed ConfigMgr console:

• Select a User from the specified Collection.
• Show only Approval Requests, for the selected User, that are Pending Approval.
• (NEW!) Show an alert when new Approval Requests, are Pending Approval, for the Users of the specified Collection.
• Approve, the selected, Approval Request.
• Deny, the selected, Approval Request.
• Close the form.

Alerting

As mentioned, above, there is a new function to add some alerting. This function adds a timer that will check every hour for new Approval Requests, which are Pending Approval, for the Users of the specified Collection. This function can be enabled by using the new command line switch –EnableAlert.

Public Available

As of today the updated version of my Approval Manager is publicly available via the TechNet Galleries. Please let me know what you think of the tool (and specifically this update).

Approval Manager

This public version gives the user the possibility to perform the following actions, without the need of access to and/ or a locally installed ConfigMgr console:

• Select a User from the specified Collection.
• Show only Approval Request, for the selected User, that are Pending Approval.
• Approve, the selected, Approval Request.
• Deny, the selected, Approval Request.
• Close the form.

Security Role

In case the user, that is going to use the Approval Manager, only needs to approve, or deny, Approval Request, I would suggest to create a new Security Role. As the user that uses the Approval Manager only needs to have the following rights:

• Application – Read; Approve.
• Collection – Read; Read Resource.

Public Available

As of today my Approval Manager is publicly available via the TechNet Galleries. Please let me know what you think of the tool.

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.

• In 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.

• In 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.

Approval Manager

Instead 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.

Solution

In most cases it’s not possible, or allowed, to change the execution policy for PowerShell on the system. So just let the ConfigMgr client “manage it” and then the solution is actually very simple. In the Client Settings, under Computer Agent, there is an option to configure the PowerShell execution policy. The only pitfall in here is that it means something different then someone might think. These are the options:

• Bypass: The ConfigMgr client bypasses the PowerShell configuration on the local system so that unsigned scripts can run.
• Restricted (default in ConfigMgr 2012): The ConfigMgr client uses the current PowerShell configuration on the local system, which determines whether, or not, unsigned scripts can run.
• All Signed (default in ConfigMgr 2012 SP1):The ConfigMgr client runs scripts only if they are signed by a trusted publisher and applies independently from the current PowerShell configuration on the local system.

The easiest way to configure this, for the Configuration Baseline, is to 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 PowerShell execution policy Bypass 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

As always, now it’s time to take a look at the result. In this case it would be easy to just show a good result of the deployment of the Configuration Baseline, but I want to show some more. I want to show the result of the deployment of the new Client Settings. Normally, the best places to look at the results are the log files. In this case, there is no log file that shows the current setting of the PowerShell execution policy. So the best place to look at that is the old-school Policy Spy. In this case it will show PowerShellExecutionPolicy = 1 as a setting under, Machine \ CCM_ClientAgentConfig. The meaning of the different possible values are:

• 0 = All signed
• 1 = ByPass
• 2 = Restricted

More information: http://technet.microsoft.com/en-us/library/gg682067.aspx#BKMK_ComputerAgentDeviceSettings

Configuration

Now 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

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.

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.

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.

Configuration

The most important part to quickly catch Active Directory Group Membership changes, is a good configuration. For that two configurations are very important, the Active Directory Group Discovery and the collection settings. To show how, and how fast, it works, I will show it with my Microsoft Office 2013 Security Group and that means the following configuration:

• First thing is to enable delta discovery. To configure the delta discovery navigate to Administration > Overview > Hierarchy Configuration > Discovery Methods. Now double-click Active Directory Group Discovery to open the Active Directory Grou Discovery Properties and go to the Polling Shedule –tab. Select Enable delta discovery and leave the Delta discovery interval (minutes) default.
• Note: Delta discovery does NOT work for deleted objects from the Active Directory.
• Second thing is to configure the collection query and to enable incremental updates on the collection. To configure the incremental updates navigate to the collection Properties and then the Membership Rules –tab. Now select Enable Use incremental updates for this collection and add a Query Rule for the members of the Microsoft Office 2013 Security Group. For that add the following query:

  select SMS_R_USER.ResourceID,SMS_R_USER.ResourceType,SMS_R_USER.Name,SMS_R_USER.UniqueUserName,SMS_R_USER.WindowsNTDomain from SMS_R_User where SMS_R_User.UserGroupName = "PETERTEST\\Microsoft Office 2013"

• Note: To change the interval for incremental updates take a look at this post.
  

Result

Now making a change to the group membership of the Microsoft Office 2013 Security Group will trigger the following reaction. The first thing that happens, within 5 minutes, is that the Active Directory Group Discovery will start to run. This can be followed in the adsgdis.log and looks like this: 

One of the things that this log shows, is that a Data Discovery Record (DDR) was written for group ‘PETERTEST\Microsoft Office 2013’. This DDR looks like this:

 |  FV°     <User Group>
BEGIN_PROPERTY
<8><Unique Usergroup Name><19><32><PETERTEST\Microsoft Office 2013>
END_PROPERTY
BEGIN_PROPERTY
<0><Usergroup Name><19><32><Microsoft Office 2013>
END_PROPERTY
BEGIN_PROPERTY
<17><Active Directory Organizational Unit><19><64>
BEGIN_ARRAY_VALUES
<PETERTEST.LOCAL/PETERTEST><PETERTEST.LOCAL/PETERTEST/GROUPS><PETERTEST.LOCAL/PETERTEST/GROUPS/APPLICATION>
END_ARRAY_VALUES
END_PROPERTY
BEGIN_PROPERTY
<17><Active Directory Container Name><19><64>
BEGIN_ARRAY_VALUES

END_ARRAY_VALUES
END_PROPERTY
BEGIN_PROPERTY
<0><Windows NT Domain><19><32><PETERTEST>
END_PROPERTY
BEGIN_PROPERTY
<0><AD Domain Name><19><32><PETERTEST.LOCAL>
END_PROPERTY
BEGIN_PROPERTY
<0><SID><19><64><S-1-5-21-3410556430-1908461509-240868779-1127>
END_PROPERTY
BEGIN_PROPERTY
<0><Object GUID><3><16><0x03E526344A6AEC4889CDCC6DC07A26DE>
END_PROPERTY
BEGIN_PROPERTY
<0><Group Type><8><4><-2147483646>
END_PROPERTY
AGENTINFO<SMS_AD_SECURITY_GROUP_DISCOVERY_AGENT><PTP><02/23/2013 20:35:01>
FEOF
  FV

After this DDR is processed into the database the next (incremental) collection evaluation will pick up the new member of the Microsoft Office 2013 Security Group as a new member of the collection (PTP00000B). This can be followed in the colleval.log and looks like this:

As my log files show, this whole process took less then a minute. So when a user is added right before the delta discovery starts it can be within a minute that the user is part of the collection. In the most extreme situation when a user is added right after the delta discovery had run and then, when the delta discovery finally runs again, it runs so long that the incremental collection update didn’t pick up the change yet, it takes up two full cycles of, in this sample, 5 minutes. So, also the long answer is between 1 till 10 minutes.