Setting the Client Status Settings for Client Activity based on AD logon

SCCM will mark a computer inactive if none of the activity checks happen

  • Client policy request
  • Heartbeat discovery
  • Hardware Inventory
  • Software Inventory
  • Status messages sent

See technet

The default settings are 7 days for each of these settings which can be fine for a lot of businesses. If there are many devices that don't often connect to the network if may look as if there is more client health issues than there really is. To get an idea of how many devices have been on the network within x amount of days you can run the following query in the SQL Management Studio:

select sys.Name0, ClientActiveStatus, ClientState, ClientStateDescription, LastOnline 
from v_CH_ClientSummary cli
join v_R_System sys on sys.ResourceID=cli.ResourceID
where DATEDIFF(d, LastOnline, GetDate()) < 7
order by LastOnline desc

This uses LastOnline (Connected to AD) to get a list of the last 7 days. Then all you need to do is modify the 7 in the query to higher values to get a number that represents a higher percentage of your fleet contacting the AD. It could be 14 days, 30 days.

This will change depending on VPN usage, Direct Access. Once you enable the Cloud Management Gateway this setting will need to be tweaked again not using this data as clients will request policy from the internet.


To configure these settings:

  1. In the Monitoring workspace, click Client Status, then, in the Home tab, in the Client Status group, click Client Status Settings.


SCCM Component Manager


SCCM Component manager is a quick way to start/stop/pause SCCM components that you would normally control using the Service Manager.

The reason the Service manager is so slow is because it has to connect to every site system's registry and gather information. SCCM Component manager only connects to the server that you select so it is much quicker. It does however require WinRM to be enabled as it uses it to run powershell commands on remote servers.

You can run the tool on it's own or you can enable some right click tools action.

To do this extract to C:\ then copy the two guid folders to C:\Program Files (x86)\Microsoft Configuration Manager\AdminConsole\XmlStorage\Extensions\Actions


I made the tool mainly to learn about powershell GUI creation,  if @nowmicro would like to add it to right click tools, feel free to re-brand, polish and do as you would like



If you want to learn about powershell gui creation please visit

Error message when no Asset Tag Detected

Set the computer name using the BIOS Asset Tag

If you are setting the Asset Tag the same name that the computer is, it makes sense to only have to input it once. I created a powershell script that will do the following:

If VM or Mac: Exit 0

If  computer exists in SCCM: Exit 0

If AssetTag Exists/Not empty: Set OSDComputerName to AssetTag, Exit 0

If AssetTag doesn't exist: Bring up an error message, Exit 1


Tested with HP and Dell machines.

Download Script

Update: Added optional script that uses the HP Ownership Tag

How to use:
Create a package for the script

Copy serviceUI.exe (From MDT Toolkit) to the same folder.

In the Task Sequence after initial format of the drive create a Run Command Line step using the package that you created

with the command: ServiceUI.exe -process:TSProgressUI.exe %SYSTEMROOT%\System32\WindowsPowerShell\v1.0\powershell.exe -NoProfile -WindowStyle Hidden -ExecutionPolicy Bypass -File AssetTag.ps1


Thanks Nickolaj and Dave Green for the initial form


Creating Collections to deploy ConfigMgr client updates (the easy way)


Get the Servicing Exstension from Microsoft NOW as it does all the work!!!

Once you have this, in the Admin node, there's a site servicing section -> client targeting. You click 'Create Query' and it makes a nice query for your collections.


Then you go about creating your collection.

Screenshot 2015-02-05 09.39.11

click next. Select Add Rule -> Query Rule


Click Import Query Statement and choose the nice query microsoft made for you.

Screenshot 2015-02-05 09.44.29

Deploy the cumulative update to the clients.



How To: Create Automatic Deployment Rules for Patch Tuesday Software Updates


Automatic deployment of updates is one of the best features of SCCM. Automation in general is awesome.

The best way to use Automatic deployment rules (ADR) is to have them run on Patch Tuesday which is the second Tuesday of the month when Microsoft releases their updates generally before 11:00 PST/PDT (I am Australian based so I set ADRs to run Wednesday Morning).

In this example I am deploying Windows 8.1 x64 critical, security and 'updates' updates.

1. Under the Software Library Node Software Updates click Automatic Deployment Rules then select 'Create Automatic Deployment Rule' from the Ribbon


2. In the Wizard name your ADR 'ADR: Windows 8.1 x64 Updates'


3. Click Browse and select your target collection

4. Change the Option to 'Create a new Software Update Group'. The other Option should really be called 'Wipe previous updates from Software Update Group' as that's what it does.

5. Click Next.

6. Ensure 'Automatically deploy all software updates found by this rule, and approve any license agreements. Also optionally enable the Wake-on-LAN tickbox.


7. Click Next

8.  Choose Date Released or Revised, set it to Last 3 weeks.


9. Choose Product, set it to 'Windows 8.1'

10. Choose Update Classification, set it to “Critical Updates” OR “Security Updates” OR

11. Choose Title, set it to 'x64'. This is to filter out x86 updates.

12. Click Preview, if you are doing this on Patch Tuesday you will see all the applicable updates that will be deployed. Otherwise you can change the date range for the example.


13. Click Next

14. Choose 'Run the rule on a schedule.


15. Click Customize and choose to run the rule every second Tuesday at the appropriate time depending what time zone you are in. Click OK (Not to important for the demo as you can run it manually)


16. Click Next

17. Customize the Deadline to 'As soon as possible'.


18. Click Next

19. Change the User Experience to 'Display in Software Center and show all notifications'


20. Tick 'Software Installation'.

21. Click Next.

22. Click Next.

23. Click Next

24. Choose Create a new deployment package.


25. Name it 'ADR: Windows 8.1 x64 Updates' and select a UNC share for storage of the software updates.

26. Add Distribution Points.


27. Click Next.

28. Click Next

29. Select desired languages, click Next


30. Click Next, then Close.

31. Right click on your newly created ADR and click 'Run Now'. You can monitor progress on the site server checking Program FilesMicrosoft Configuration ManagerLogsruleengine.log


32. Give it some time to download updates and distribute them then on the client machine run a machine policy update and verify updates install using Software Center



33. After having a play check out this post for some best practices to setting up all your Automatic Deployment Rules including Piloting your updates to a pilot group for 7 days.

34. Also check out this post to automate sending a report out on what updates are being deployed.




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.

Versioning and naming your base SOE .wim during OSD

If you replace the base wim (via build and capture) frequently it can be good to set versions and date the wim file that you import. It makes it easy to revert back if a change didn't go so well. Below are the steps in my build and capture to do versioning and work around a bug with naming your captured image.

1. At the top of my task sequence I set a task sequence variable SOEBaseVersion, each time I do a build and capture this is incremented.

Set SOEBaseVersion

2. After 'Setup Windows and Configuration Manager'  I have a 'Run Command Line' step with the following command so that we can utilize that value on deployed machines if ever needed:

cmd.exe /c reg add HKLMSoftwareSOE /v SOEBaseVersion /d "%SOEBaseVersion%"

Set SOE Reg


3. Next I run a vbscript to set the task sequence variable TSDate to the date in the format YYYYMMDD

Set env = CreateObject("Microsoft.SMS.TSEnvironment")
env("TSDate") = DatePart("yyyy",Date) & Right("0" & DatePart("m",Date), 2) & Right("0" & DatePart("d",Date), 2)

Screenshot 2014-10-22 16.21.49


4. In the 'Capture the Reference Machine' step I can then use the TSDate Variable to create a unique file name for the capture and also use the version field. There is a bug with the SCCM console as it doesn't use the Description field when importing, the next 2 steps resolve that.



5. Connect to OS Capture share.

Connect to share

6. Copy imagex to a package, then use it to run the following command line

imagex.exe /info R:\WIN81_x64_Base-%TSDate%.wim 1 "Windows 8.1 Enterprise" "WIN81 x64 - %TSDate%"

Set Image Description


7.  You can now import into SCCM with all the fields filled in correctly

Add Operating System Wizard