Posts Tagged ‘SCCM’

I thought I might do a quick blog about this particular tool that I have used a lot since upgrading to R2. I think it offers real value for the average Config Manager Administrator.

So you’ve just created that new Driver Package and have kicked off replication to all your Distribution Points, no doubt most have bandwidth throttling during business hours. Any idea how far its progressed? Nope. Any idea which DP’s have had content replicated and which ones haven’t? Not easily. Sound familiar? Want to test your OSD Task Sequence and at a glance see when the content is on the DP local to your Hyper V instance so you can start? This was one of many sources of frustration for me.


Well fear not, there is a new tool that comes with the latest Toolkit for Config Manager 2012 R2 which vastly improves on what I think it a pretty limited pane of information provided in the Console.

The latest toolkit is available here to download:

Once installed, open up the Distribution Point Job Queue Manager and we are met with the initial connection screen. Type in the Primary Site Server that your interested in and hit CONNECT, note you need to do this as an account with the ‘full administrator’ role assigned. I don’t bother typing the FQDN just the hostname.

Once connected you can start experiencing what its like to actually know what is happening with those DP’s of yours. No more opening up PkgXferMgr.log with CMTrace, which is what I was doing with 2012 Sp1 prior to the release of R2 and certainly no more hitting refresh on that console waiting for that yellow circle to turn green.


There are 3 others tabs which give you varying informational displays about the progress of your package or application distribution with a useful auto refresh function. If you are distributing a medium to large packages and its taking a while, the tool will give you the replication progress as a percentage. You can also change the order of each job if you want a package or application to replicate to one DP before another. This is particularly useful if for some reason a package starts replicating to a site with a slow link with only a small % of that available for Configuration Manager to use for distribution. It’s worth noting that Configuration Manager will remember which DP’s are fastest and then replicate content in that order – fastest to slowest in a classic DP structure.




I’m sure some of you are pretty happy with what’s in the console presently, however this tool has provided that increased level of awareness and time management that just wasn’t there for me due to the large number of DP’s I have with limited bandwidth.

Happy Replicating,

Cheers Damon


Recently our organisation decided to enable BitLocker protection for all of our new laptops. The idea was to provision the drive encryption as the laptops were built with our Configuration Manager 2012 R2 environment. The laptop models were the HP EliteBook 850 and the Elitebook 820.

A few steps were required to achieve this and some tweaking of the default steps in my Configuration Manager Task Sequence.

Now before you even start with BitLocker you need to ensure that your Active Directory environment meets a few prerequisites, for the purposes of this blog I’m assuming that this has been checked and is in place. Some documentation on this can be found here:

Step 1 – Enable the TPM

In order to enable BitLocker during a Configuration Manager Task Sequence we first need to enable the TPM (Trusted Platform Module) in the BIOS. Its worth noting that a lot of the newer devices such as Surface Pro’s come with UEFI where the TPM is already enabled, again my blog is dealing with BIOS as our new laptops don’t come out of the box with UEFI enabled.

To enable the TPM in the BIOS we also need to set a password and tweak a few of the other security settings associated with the TPM. Luckily there is a HP BIOS Configuration Utility which we can use as part of a Task Sequence that will set these options for us automatically! I’m using version of the HP BIOS Configuration Utility which you can download from

Extract the contents of sp49507 and create a package in your Config Manager instance. No program is required just the files as the Task Sequence is going to execute the utility.


We now need to create a file for the utility to use which contains the settings we want to change inside the BIOS. I have done this by copying the BiosConfigUtility.exe to my target laptop, then launching a command prompt as an administrator and executing the below command. You can then modify the text file to contain only the required settings to enable the TPM for your particular laptop. For my laptops these settings are shown as per below. Once you have the file trimmed down to what you require, rename it to .REPSET and copy it to your HP Bios Configuration Utility package source folder and update your distribution points.



Now we can update our Task Sequence with a step which executes the utility, this should be formatted as:

BiosConfigUtility.exe /SetConfig:%YOURSETTINGS.REPSET% /NewAdminPassword:%YOURPASSWORD%

I have created a group in my TS and have restricted the group to run only if the device is a laptop using the IsLaptop variable and have then created a step for each type of laptop model as each model has its own REPSET file with the settings required to activate the TPM.




Step 2 – Set BitLocker Steps in your Task Sequence

Now that we have turned on the TPM using the config utility provided by HP we can turn our attention to the BitLocker steps. I have modified mine slightly as I have used the integrated MDT Task Sequence and prefer the Configuration Manager Enable BitLocker step rather than the MDT step that is provided in the default TS. Why? It just seems to work better ūüôā

Disable the default MDT ‘Enable BitLocker’¬†step and then add the standard SCCM Enable BitLocker step. I have renamed mine to ‘Enable BitLocker for Laptops’ and moved my new step down the TS so that its one of the last to be actioned. I have done this as personally I have had performance issues with the hardware once encryption has started which slows down the TS steps.


Again I have restricted this step from running by using the IsLaptop variable. Your BitLocker drive encryption options will vary depending on how you are implementing it in your organisation. We have  just enabled the TPM and encrypted the drive, storing the recovery key in AD.


Step 3 – Test Your Task Sequence!

Now that we have our TPM being enabled automatically and our BitLocker steps in our Task Sequence as required, we can test everything to ensure it works.

I had to make one adjustment to my Active Directory permissions so that Configuration Manager could write the recovery key information, however this may not be required in other environments. Here is the blog about how to fix this should you run into the issue:

Happy BitLockering!


Recently I had to do a site restore on a very sick Config Manager Primary. The restore itself went very smoothly however a few minor issues have popped up since. One being a warning in my Component Status logs by the SMS_COLLECTION_EVALUATOR component.

The description of the warning stated that the:

Collection Evaluator failed to find collection “%”. Collection Evaluator received a .udc (update collection) or .adc (create collection) file for a collection that does not exist.

Possible cause: The collection was deleted shortly after being created or updated, but Database Notification Monitor and Collection Evaluator processed the create or update file out of sequence.


Inspecting the colleval.log file indicates a similar problem:


To understand the problem a little more I did some digging. Doing a Google search on the error yielding a reported solution:

The forum response states that you can browse to the inbox folder at \Program Files\Microsoft Configuration Manager\inboxes\¬†and remove the offending UDC_File’s that are instructing the SMS_COLLECTION_EVALUATOR thread to attempt to update the missing collections. Performing this action on my Primary site did indeed resolve the issue.


Digging a little further……

Looking at the dates on these files was interesting given that they were random over the course of a 3 month period. This coincided with my package conversion to applications where I was removing large numbers of device collections and creating new user based collections.

So it seems that the number of orphaned UDC_File’s grew slowly to the point were the warning count threshold was breached, thus my SMS_COLLECTION_EVALUATOR component changed its severity status from OK to Warning. It just so happened that my restore coincided with this milestone and I hadn’t noticed the component in that warning state prior to the site restore.


So what actions lead to these UDC_File’s hanging around every now and again once a collection is deleted?

Relating this back to the possible cause stated in the status message:

The collection was deleted shortly after being created or updated, but Database Notification Monitor and Collection Evaluator processed the create or update file out of sequence.

Well to be honest I’m not entirely sure and if anyone out there has a specific answer beyond this limited reason please let me know ūüôā It would be nice to be fully aware of how you can avoid this scenario (if at all) in future beyond the action of deleting these files.

I can say however that when you create a collection a UDC_File is generated in the inbox folder, its processed, then removed. Similarly when you delete a collection a UDC_File is created, processed and removed. If you monitor this folder, you can see the files in action as you create and delete collections.

There are some good practice steps to follow around collections that may assist. 

Incremental Updates on Collections

According to Microsoft you should not set this setting on large numbers of collections as it could result in delays in processing memberships of collections.  See this Technet link for best practices around the use of this setting:

You can use Powershell to turn off the incremental update setting on your collections if you think you have to many enabled. This blog explains the process and has the script to download:

Management of Collections

Technet link for maintenance of collections:

Cheers Damon

I think a lot of people look at UDI (User Driven Installation) Task Sequences as just that – an option for users in an organisation to perform actions associated with the deployment of an Operating System. Well that’s perfectly acceptable however when I first installed Configuration Manager 2012 in my lab I looked at the new UDI options and immediately saw a way of replacing my old HTA that I had with Configuration Manager 2007. I was fairly sure I could adapt the UDI Wizard to suit my deployment model taking full advantage of what the MDT team had already written. The following blog briefly describes what I have done with UDI in my organisation.

Implementing the out of box UDI solution is actually fairly straight forward.

  1. Integrate MDT with your Configuration Manager 2012 installation
  2. Create your MDT files package, I have done this with MDT 2012 Update 1
  3. Create a standard MDT client task sequence, this will automatically include the steps that call the UDI Wizard
  4. Test your Task Sequence to ensure that it works and calls the UDI Wizard as expected.

Once you have these basics configured you can then take a closer look at customising what built in panes the wizard presents and how that information is collected and used.

Its worth noting as this point that I haven’t had a need to create any custom panes which set variables. Having said that, you can do this and MDT 2013 includes the ability to create your own pages using a GUI which is a vast improvement on what was offered in MDT 2012 Update 1.

Using the UDI Wizard Designer, I have removed quite a few of the built in panes. This is because I have tailored it for my Service Desk technicians to use and rely on the other built in Task Sequence steps to set variables. I have modified the New Computer and Refresh page libraries and have a separate USMT scripted process for the replace scenario.


New Computer UDI Steps


Refresh Computer UDI Steps

I have created separate UDI XML files for each Operating System that I deploy or refresh so that I can control settings and what applications are installed. To call different UDI Wizard XML files, save your UDI XML template file with an appropriate name into your MDT Files package then modify the two UDI Wizard steps in the Task Sequence.



You can customise the default header image (as I have) so the UDI Wizard is customised to your organisation. To do this you will need to locate the UDI_Wizard_Banner.bmp file located in your MDT Files package. Modify both copies of this file within the \Tools\x86 and \Tools\x64 folders respectively. The image needs to be 759 x 69 pixels. Rename the old file to UDI_Wizard_Banner.original in case you wish to roll back. Once your changes are complete, update your Distribution Points.



Here are some screen captures on my New Computer UDI Wizard. You can use the wizard to add Organizational OU’s, a pre-populated Domain Name, Applications and other variable settings.


Collecting Computer and Network Settings


Application Selection and Installation


Summary Page

As the MDT Gather step runs before the UDI Wizard starts, you can also pre-populate other variables which will then automatically appear within the UDI panes. For example you may wish to run a separate script to generate a computer name, if this is run prior to the UDI Wizard running, it will be displayed in the pane that contains the field referencing that variable. Another good example of this is to pre-populate the domain join account username and password using CustomSettings.ini.


You can also use the UDI Wizard to present groupings of Applications which when selected will then be installed as part of the base variable COALESCEDAPPS during the Install Applications step of your TS . To correctly configure this for OSD you will need to create a collection within your Configuration Manager Console, then Deploy each Application to that collection that you want to make available during an OSD Task Sequence. The Deployment type needs to be set to available. Alternatively you can use an existing collection, if you have one setup, that already has your Applications deployed in this manner.

Note: If you rename an application in Configuration Manager 2012, you will have to update your UDI XML file, save and redistribute your MDT Files package.


When this has been completed you can use the UDI Wizard Designer to create your Software Groups. Ensure that you have set the Site Settings within the designer by selecting the Configuration Manager ribbon button. You will need to set your Site Server Name and the name of the Application Collection that you have created and deployed your Applications to otherwise your Applications will not appear when you try to search and add them.

Note: You need to tick the option “Allow this application to be installed from the Install Application task sequence action without being deployed” for each Application that you want to install as part of a TS



Using UDI as an alternative has allowed me to transition into Configuration Manager 2012 OSD easily, retiring my old HTA. I have been able to take advantage of the built in panes and were suitable, set and populate information automatically. With the new version of MDT 2013 around the corner, the new Custom Page Designer will no doubt add further options and capabilities in this area.

Hopefully this blog gives you some broad ideas around how you can implement UDI in your organisation and what is possible to achieve when using it.


Cheers Damon

The number one reason for update installation failures from Microsoft is because your computers are running an out of date WUA (Windows Update Agent) or its not configured correctly. So how can this occur when we have Config Manager managing our updates and deploying them? Well its because WSUS handles the updating of the WUA agent and its components, not Config Manager. Incorrect Group Policy settings can also cause problems.


A client running the internal SelfUpdate process

There are a number of blogs out there discussing how to correctly implement WSUS, Config Manager and Group Policy, in fact Jason Sandys presented on this at MMS this year (2013). This gives a great overview of how to implement Software Updates ensuring that your WUA updates itself also.

When I upgraded to Config Manager 2012 I experienced quite a few clients that had out of date WUA’s. I was completely oblivious to this, however I identified the issue when decommissioning my old Config Manager 2007 instance. I could see in the IIS logs that I had computers still trying to contact my old WSUS server to do a WUA version check even though these computers had the new 2012 Config Manager agent running on them. This indicated that a number of computers had issues with their settings relating to how they were contacting the new WSUS server. I knew that my Group Policy settings, WSUS and Config Manager Software Updates implementation were correct as the vast majority of my clients were updating and communicating correctly.

So how do we put some checks in place so we can identify those computers with out of date WUA versions and re-mediate them? Well, I have done the following, maybe you will find the following information useful.

According to Microsoft you can use this SQL query:

however you can’t run this from within the Config Manager Console, you get an error about the view being unavailable.


A work around for this is to use the following query which I obtained from a Technet discussion (credit to Jason Sandy’s and those who responded on this page). Go to Monitoring tab within your Configuration Manager Console and create a new query with the following syntax:

select rsys.Name, wua.Version from  SMS_R_System as rsys full join SMS_G_System_WINDOWSUPDATEAGENTVERSION as wua on wua.ResourceId = rsys.ResourceId

This will give you a view with results similar to the following:


When I initially ran this in my environment I then noticed a number of computers with out of date agents or no agent version at all even though they had the new 2012 client installed. This can mean that the Config Manager client has yet to run an inventory and upload the information, however in my case I could see that the inventory actions were running and had uploaded data. Subsequently I checked the WUAHandler.log on the problem computers and ran across two distinct issues.

Issue 1.

On some of the computers I could see that the WUAHAndler.log indicated that it was still pointed to the old WSUS server that no longer existed. I was seeing the following error in the WUAHandler.log

Its a WSUS Update Source type ({63897A13-E330-463A-B09E-101151D25935}), adding it.
Enabling WUA Managed server policy to use server: :8530″>:8530″>http:// :8530
Waiting for 2 mins for Group Policy to notify of WUA policy change…
Group policy settings were overwritten by a higher authority (Domain Controller) to: Server “>”>http:// and Policy ENABLED
Failed to Add Update Source for WUAgent of type (2) and id ({63897A13-E330-463A-B09E-101151D25935}). Error = 0x80040692.

For these instances I browsed to the c:\Windows\System32\GroupPolicy\Machine folder on the computer and manually removed the Registry.pol file. This file was then re-created by doing a gpupdate /force on the computer. Following this action, the WSUS server reference in the WUAHandler.log was corrected and the computer then started to communicate with the new WSUS server. So it would seem that this file was corrupted and was not being replaced by my updated Group Policy.

Note: This can also be caused by incorrect Group Policy settings which override any local WSUS server policy that the Configuration Manager client attempts to set so bare this in mind when troubleshooting this error.


Issue 2.

On the remaining computers I was seeing a search related error in the WUAHandler.log, subsequently inspecting the WindowsUpdate.log indicated an issue with the client being able to contact the new WSUS server:



For these computers the problem lied with the machine proxy setting. This was shown when running netsh winhttp show proxy. This setting had been configured but then not removed as part of another internal process within our domain. To correct the communication problem I ran the following from an elevated command prompt then restarted the computer:


Allowing for inventory to be run on the re-mediated clients, the WUA version information then appeared in the SQL Query that I had configured in my environment. Checking the WindowsUpdate.log on those computers also indicated that the self update process was working.

I hope these two issues and their associated resolutions help you with your WUA version compliance when running Software Updates with Configuration Manager 2012!

Cheers Damon

I recently ran into an issue which involved the replacement of a server. I had been using it as a Configuration Manager 2012 SP1 Site System running the PXE Enabled Distribution Point and State Migration Point roles. It was servicing around 30 clients in a small office and the Server team had been gracious enough to give me a few days notice of the replacement. I scheduled the deinstall of the site components for Friday afternoon at 4pm however unbeknownst to me I wasn’t unable to fully remove the site.

Initially I had no problems, I removed the Distribution Point Role and also the State Migration Point role – reviewing the distmgr.log on my primary revealed that this progressed and completed.



Then I went to remove the site server itself which produced a nasty stop error¬†–¬†The server cannot be deleted because it contains the following site system roles:¬†component server.¬†So I was in a position were I had a server being replaced in a few hours with me being unable to fully deinstall the site server.

Now this may not pose a problem to most, however in my mind I was of the opinion that this wouldn’t be the best eventuality for the Configuration Manager environment if the server was replaced while the Primary was still processing the removal of the component server . So, a question arose how to remove the Site System? Well the log indicates that it would run a cleanup task in 60 minutes.

So thinking this through logically I restarted the SMS_SITE_COMPONENT_MANAGER service on the Primary. Hey presto! I was then able to remove the site system with the component server role no longer appearing.


Reviewing the sitecomp.log indicated that the degraded component was indentified and removed immediately without having to wait.


So recently I discovered that certain file extensions with my Windows 8 Enterprise deployments were associated by default with the new modern/metro applications. These included .jpg .bmp etc. Now for tablet users this may not pose a problem but for a Desktop Enterprise scenario it certainly raised some eyebrows with my end users who were consistently switching between the traditional desktop applications and the new modern applications when working.

To combat this change Microsoft have introduced a new way to set and manage these file type associations. You can no longer use a VB or Batch file to script these changes in the registry due to a security hash checking process built into Windows 8. We can now use the Dism utility to generate an XML answer file which we can then deploy and manage using Group Policy.

I recommend following these steps to configure and deploy your desired associations.

1. Deploy a copy of your current Windows 8 Enterprise WIM with your chosen deployment solution. Run up Default Programs under Control Panel and look at your current file type associations. Take note of which ones you want to alter and make your changes


2. Now we need to generate our XML file. Run an elevated command prompt and type Dism /Online /Export-DefaultAppAssociations:\\youshare\AppAssoc.xml This will output a file with all of your file types and their current associations.


3. Edit this file to include only the file associations that you wish to change. You can elect to keep the file intact in its entirety if you wish. Optionally you may wish to make copies of the file if you have different file association requirements for different business groups in your organisation which you can target using separate Group Policies.


4. Once you have this XML configured to your preference we can specify it in our Windows 8 Group Policy setting. Open up the Group Policy MMC on your Windows 8 environment (with RSAT installed) or Server 2012 instance and locate the policy Computer Configuration\Administrative Templates\Windows Components\File Explorer\Set a default associations configuration file Now specify the location of where you have stored the XML file. A possible option is to use a network share, or you may want to copy/inject the file locally to the Windows 8 Enterprise build as part of a Configuration Manager Task Sequence.



Hey presto! You now have a method of controlling and setting file associations in your organisation which is flexible enough to cater for the different scenarios you may find yourself having to manage – thanks to the Modern Desktop ūüôā

Technet Reference