No inventoried software found in Asset Intelligence

When looking in Asset Intelligence - Inventoried Software, by default there is no software found. It will display "No items found" in most environments. When you want to have all software collected here, specific configuration is needed. This must be done on the Hardware Inventory part, because software is collected by WMI these days.

Trick is, the default setting in Hardware Inventory on the necessary classes is not activated. The class you need for installed applications is named InstalledSoftware and for executables InstalledExecutable. Just open Default Client Settings (or Custom Settings when there is another policy created for clients), select Hardware Inventory, Set Classes, and select both classes here.

Furthermore there is a change needed on the Asset Intelligence part. Rightclick on Asset Intelligence (Assets and Compliance) for that, select Edit Inventory Classes, and select both classes again.

And yes, there will be a warning mentioning this will be increasing computer resources during Hardware Inventory :-)

When the clients get the client policy changes, software will be found en displayed in the ConfigMgr console.

Very handy if you ask me!

Source: blog.hosebei.ch 

Stop a hung service during Cumulative Update installation

Today I started a Cumulative Update 3 installation, which is the most recent one on ConfigMgr 2012 R2. As always (?) a reboot is needed before installation is started. This will be mentioned in the prerequisites wizard. After reboot however, installation hung on the first step. Stopping services.. This on the Windows Management Instrumentation (WMI) service. Let's have a look how to stop this service manually.

First have a look in the Services console for the service name. In this case the service is called WinMgmt. Then open a Command Prompt and type in the following command:
-sc queryex [servicename]
Replace [servicename] with the services registry name.

After running the query the PID is showed, which is 836 in my case. Type in the following command to stop it definitely:
-taskkill /f /pid [PID]
Replace [PID] with the number showed before.

This will forcefully kill the hung service! After that installation can be continued as expected.

Chassis Types and query-based Collections (part 2)

Last month I published a blogpost about WMI queries on PCSystemType. This blogpost can be found here: How to add devices to different OU’s during deployment. This can be used during a task sequence deployment to decide if the system is a desktop or laptop (for example). This time I want to create collections on PCSystemType. Because this can't be found in a collection query (no PCSystemType there) you can use the following configuration.
 
A good way to target systems in queries and collections is by Chassis Type. When using a query rule on collections, use these values:

Choose System Enclosure - Chassis Types in the query

 

Choose a value based on the Chassis Type (see list below)

 
Let's have a look at the possibilities: 

• 1 Other (Virtual Machine)
• 2 Unknown
• 3 Desktop (Virtual machines as well)
• 4 Low Profile Desktop
• 5 Pizza Box
• 6 Mini Tower
• 7 Tower
• 8 Portable (Laptop or Notebook)
• 9 Laptop (Not as popular)
• 10 Notebook (Popular)
• 11 Hand Held
• 12 Docking Station (Laptop or Notebook)
• 13 All in One (Apple Inc.)
• 14 Sub Notebook
• 15 Space-Saving (Thin Client)
• 16 Lunch Box
• 17 Main System Chassis (Physical Server)
• 18 Expansion Chassis
• 19 Sub Chassis
• 20 Bus Expansion Chassis
• 21 Peripheral Chassis (Laptop or Notebook)
• 22 Storage Chassis
• 23 Rack Mount Chassis (Physical Server)
• 24 Sealed-Case PC

 
To see which device you are using, use the following query: wmic systemenclosure get chassistypes. Because I have the choice between 1, 3, 10 and 15 (for example) this should be Other, Desktop, Notebook and Space-Saving (Thin Client).

Let's use query-based Collections in ConfigMgr as much as possible!

More blogposts on this topic:
How to add devices to different OU’s during deployment

How to add devices to different OU’s during deployment

In ConfigMgr it's possible to use a WMI query for Hardware vendor, type or model or part of computername (for example). In my situation I want to use a single task sequence for both desktop and laptop/ notebook deployments. This because to select different OU's during deployment. Let's have a look how to do that.
 
Within MDT you can use a variable like IsLaptop equals “True” or IsDesktop equals “True”. Within ConfigMgr I never used these before (while they are supported as well). There is another method however, besides of using part of computername. In this case you can run a WMI query to detect the hardware type.

My preferred method is as follows:
SELECT * FROM Win32_ComputerSystem WHERE PCSystemType = 1
SELECT * FROM Win32_ComputerSystem WHERE PCSystemType = 2
Example: 1 is for desktops and 2 is for laptops/notebooks.

If you want to combine multiple types, then use an "If statement" to the task sequence step, and specify multiple WMI queries. When using a single task sequence for both desktops and laptops/notebooks, use "Apply Network Settings" twice, with both a different WMI query.

When looking for more hardware types, use the following table:

• 0 (0×0) Unspecified
• 1 (0×1) Desktop
• 2 (0×2) Mobile (Laptop/Notebook)
• 3 (0×3) Workstation
• 4 (0×4) Enterprise Server
• 5 (0×5) Small Office / Home Office Server
• 6 (0×6) Appliance PC
• 7 (0×7) Performance Server
• 8 (0×8) Maximum

 
Hope it helps!

More blogposts on this topic:
Chassis Types and query-based Collections (part 2)

SCCM 2012 Agent and high CPU utilization

When using Automatic Deployment Rules (ADR) in ConfigMgr 2012 you have a choice at "Each time the rule runs and finds new updates" on the General tab. The choice is about "Add to an existing Software Update Group" and "Create a new Software Update Group". An Software Update Group will be named SUG from now on.

Not sure why this choice can be made, but with monthly Windows updates it can be handy to create a new SUG every month. That way you know which updates are deployed every month. When using an ADR for Endpoint Protection (SCEP) definition updates it's recommended to use an existing SUG. Otherwise every 8 hours or day (as configured) a new SUG will be created. The old SUGs will be kept with expired definition updates in it. Not that it's not a good configuration, but WBEM cannot deal with lots of SUGs, with expired definition updates in it.

Here's the trick. When having lots of SUGs, with expired definition updates in it make WBEM run wild and unstable. WBEM is a sub component of WMI, which in turn is contained in svchost.exe. To stop this, remove all software update deployments especially those for Endpoint Protection; the WBEM should calm down in an hour or so. If the WBEM repository is corrupt, it may take hours for WBEM to calm down. WBEM needs to detect the corruption and run a repair. Deleting the WBEM repository should be avoided.

Looking on MS TechNet I found the following post: SCCM 2012 Agent and high CPU utilization. Deleting the SUGs indeed did the trick in my case. It seems to be a known Microsoft bug and may be solved later.