November, 2014

Troubleshooting Collection Queries

If you want to see what collections have bad queries use CEViewer.exe from the ConfigMgr 2012 R2 Toolkit, it is installed when you add the server tools.



Some things I have found about queries:

  • The OR operator can slow a query down alot when using it for 2 different attributes, just create 2 membership rules instead. The following changed the evaluation time from 1400 to 27 seconds. I still feel it's slow but doing more investigations


Changed to:
coll3 coll4 coll5

  • If you know what you are looking for exactly don't be lazy and use the like operator, use is equal to.
  • Don't edit queries with live deployments.

Create a compliance baseline to remove a folder


In this example we are killing the Silverlight start menu folder enabling us to use the Windows Updates while keeping the start menu clean.

Create the Configuration Item

1. In the console click Create Configuration Item

2. Name your configuration item, click 'This configuration item contains application settings' and click Next

Screenshot 2014-11-14 10.03.58

3. Select 'Always assume application is installed' and click Next

Screenshot 2014-11-14 10.05.15

4. Click New, Change the Setting type to 'Script'. Change the Data type to 'String'. Also name your Setting.

Screenshot 2014-11-14 10.29.17

5. Under Discovery Script click 'Add Script'

6. Ensure Script language is 'Windows Powershell' and paste the following

$false -eq (Test-Path "C:ProgramDataMicrosoftWindowsStart MenuProgramsMicrosoft Silverlight")

Screenshot 2014-11-14 10.32.38

7. Under Remediation Script click 'Add Script'

8. Ensure Script language is 'Windows Powershell' and paste the following

remove-item "C:ProgramDataMicrosoftWindowsStart MenuProgramsMicrosoft Silverlight" -recurse

Screenshot 2014-11-14 10.42.37

9. Click 'Ok',  then click the 'Compliance Rules' tab

10. Click 'New'

Screenshot 2014-11-14 10.47.35

11. Configure the Compliance rule: Set 'Rule type' to Value. Set the Value returned to equal 0. Click 'Run the specified remediation script when this setting is non complaint'.

Screenshot 2014-11-14 10.52.10

12. Click 'OK' then 'Next', 'Next' on the Wizard Screen.

13. Choose the OS Environments for compliance

Screenshot 2014-11-14 10.54.33

14. Click 'Next' until you finish the Wizard.

15. Under Configuration Baselines click 'Create Configuration Baseline' and add the configuration item we just created, then click 'OK'

Screenshot 2014-11-14 10.57.31


16. The Baseline is now ready to be deployed to your test collection!

Right click and select Deploy, Enable the remediation options and change the Schedule if needed.

Screenshot 2014-11-14 11.00.15



17. On your test machine, request a new machine policy, then click on the Components tab. Clicking Refresh should show the new baseline which you can then evaluate.


18. Within a minute the remediation runs and the folder disappears!


Optimize the 'build and capture' time and size (SCCM Build)



Inspired by Johan's post

I am probably one of the few that uses SCCM to capture base images. I use it because I create a thick image and it keeps the history of packages that it has installed meaning that newly imaged machines will know that they have already installed software x when they recieve it's required deployment.

Patch the install.wim

Patching the default Windows 7 install.wim so it doesn't need to install as many updates during OSD.

1. Download WSUS Offline Update from

2. Extract to C:wsusoffline and run UpdateGenerator.exe

3.  Choose Windows 7 x64 Global and click start.

WSUS Offline Update

4. Important: Delete KB2506143, KB2533552 and KB2819745 from C:wsusofflineclientw61-x64glb if they exist. They break the wim. If your company hasn't deployed IE11 also delete patches for it.

5. Extract a Win7 SP1 Enterprise ISO to 'C:OS Windows 7 SP1 x64'

6. Create the dir C:mount

7. Mount the wim -

dism /mount-wim /wimfile:"C:OS Windows 7 SP1 x64sourcesinstall.wim" /mountdir:C:mount /index:1


8. Patch the wim -

dism /image:C:mount /Add-Package /PackagePath:C:wsusofflineclientw61-x64glb

9. Commit/Close the wim -

dism /unmount-wim /mountdir:C:mount /commit

10. Copy the 'OS Windows 7 SP1 x64' folder to an unc share and import into SCCM under Operating System Installers.


Use Mikael Nystrom's Cleanup Script

1. Download via

2. Place in a UNC Share.

3. Copy ZTIUtility.vbs from MDT 2013 to the UNC Share.

4. Modify Action-CleanupBeforeSysprep.wsf second line to reference the ZTIUtility.vbs in the same folder

<script language="VBScript" src="ZTIUtility.vbs"/>

5. Create a package in SCCM.

6. Before the capture steps create a run command step surrounded by 2 reboots:

cscript.exe Action-CleanupBeforeSysprep.wsf using the package created and disable 64-bit file system redirection

TS Clean

The updated wim will have the patches required for this step.

Access the wim directly from the distribution point

For this to work you need to tick the checkbox on the OS Installer properties to copy to a share, then also the Access content directly in the task sequence Apply OS step.





Monitor KB2894518 for mutiple reboot updates

Create a separate deployment for these updates to a collection that excludes your capture VMs


Tweak your Virtual Machine

  • Don't use the Legacy Network adapter (Have had issues at capture stage)

Visit for VM tweaks

  • Use 2 vCPUs
  • Use a RAM Disk

Fix for customized Adobe CC Acrobat in base image not activated



If you put Adobe Acrobat in the base image using the steps from

Install Customization Wizard XI msi + mst then Install CC package msi and mst you may find it not activated.

To fix this during the OS Deployment add a run command line step to reinstall the CC package mst and mst.


acrobat step

A normal install program step fails....


KB: PXE boots using the wrong wim file.


If you happen to change the source name of a boot wim the pxe point may boot using the old file. To fix rename

<Drive Letter>RemoteInstallSMSImages<WIMPkgID>oldbootname.wim to oldbootname.wim.old

Next PXE boot it will then use the new boot.wim file.


Application Catalog logs


There are 2 operational logs for the App Catalog server side.

  • <Drive Letter>SMS_CCMCMApplicationCatalogLogsServicePortalWebSite.log
  • <Drive Letter>SMS_CCMCMApplicationCatalogSvcLogsServicePortalWebService.log



If the App catalog has an error message "Cannot Connect to the Application Server" this is referring the to the ServicePortalWebService.log.

So far I have only seen the error:

error: WriteHeadersCallback(WebExceptionStatus errorStatus, ConnectStream stream, Boolean async)

in the log ServicePortalWebSite.log

restarting the IIS service resolved this.