Five Future ConfigMgr Usability Wins

By Nash Pherson  -

While we are waiting to see what will come out in Cumulative Update 1 for ConfigMgr 2012 R2, I thought I would write up some of the product improvements that I’ve been hoping to see for some time.  Many of these have been suggested before (even back in the CM07 and SMS days), but I thought I would open up new Microsoft Connect feedback and try to get the community involved.  The Product Team is actually really good about implementing the feedback they get if there is wide community support.  Read this article for information about how and why to give feedback on ConfigMgr.

I’ve helped a couple dozen organizations implement and maintain ConfigMgr 2012 since it was released.  However, I see the same challenges pop up over and over again with every customer.  And, if you look through the forums, you will see hundreds of people struggling with the same things.

Fixing these 5 challenges would be easy big wins for product usability

1. When people want to see what software is installed, they go to Software Inventory (which doesn’t inventory installed software, it inventories metadata about files)

Rename “Software Inventory” to “File Inventory” (or at least “Software File Inventory”).  This is a long overdue change that has hundreds and hundreds of forum posts to prove that the naming only creates confusion.  Heck, maybe even rename “Hardware Inventory” to “System Inventory”. This is a universal stumbling block for every employee at every ConfigMgr-using organization, and to have a “well that’s stupid” thought come up so often is just bad for the product.


2.  When people want to Deploy updates, they go to Deployment Packages (which aren’t deployable objects)

Rename “Deployment Packages” to “Content Packages” or “Update Content Packages”.  The ‘Deployment Package’ only exists to make sure that the content is put on the distribution point.  Since you can’t deploy a Deployment Package, how about we get the word Deployment out of the name?


3. When people build a Task Sequence, they include an Install Updates step (which doesn’t work)

Make it so that the Install Updates task sequence step works out-of-the-box by either removing the need for the “SMSMP=” client install property or adding it by default.


4. When people see a product listed in the Asset Intelligence node, they want to know which machines have it (but can’t get that info from there)

Double clicking on the product should bring up a scoped Device view to show which devices have it installed.  At the very least, link to the AI Report and pre-populate the product name. Since “µTorrent” always ends up on the top of the list, when the IT Manager opens up that node they want to know who is pirating movies at work right now… And there is no way to drill into the data they actually want from there.


5. When applying a Cumulative Update, people run the installer and think they are done (and miss the dozen other things they need to do to get client/site server/console updates deployed)

This is such a messy process that most customers I work with fail to actually get all of the steps completed consistently when doing a Cumulative Update to maintain their ConfigMgr environment.  So, I’ve got five separate suggestions for making things easier:

  1. Make the whole CU process supported through Microsoft Update like the other System Center Products.  Having to use SCUP to inject updates is a mess (and SCUP as a product is another challenge entirely). Client and Console updates could be just as easy as OpsMgr.
  2. Support the “Hotfix” folder in the Client install directory to make it easier to ensure new clients get the updates right away. The PATCH= property requires an absolute path, which is all but impossible to do in a Task Sequence or with Client Push, and just too difficult for most orgs to use effectively anywhere. Supporting the “Hotfix” folder would mean that clients get the right version bits right away without a lot of extra things that need to work.
  3. Make the “Automatic Upgrade” feature support Cumulative Updates.  Most people think it does already and don’t realize that they have to build collections, figure out the query rules, and deploy the packages/programs.
  4. Build Applications instead of Packages/Programs for client/server/console updates so we can rely on deployment type requirement rules for OS Architecture, the detection method for applicability, and to simply the collection queries we need to build for deployment.
  5. Ensure client version and console version get incremented when a CU is applied so it is easier to see who needs/has the update.  Right now, to get info for building a collection of devices that need a Console update you would have to use File Inventory for the console executable (which may or may not be in the default location), use Hardware Inventory for QFE’s (which is a horrible idea), or write a Compliance Item to look at the file.  But, if the product version were to go up when a CU is applied… you would just need good old Hardware Inventory data for Installed Software or Installed Applications.  Which happens to be where people look for ‘what version of the Console I have’.

So, if you want to see these improvements implemented, you need to register on the Microsoft Connect site and help vote them up.  If you have other ideas, get them into Microsoft Connect and don’t be surprised if they get implemented.

Thanks for your help!

All my best,




PS:  Thanks to all the awesome consultants who I asked to review this article for me:  Gerry Hampson, Johan Arwidmark, Jason Sandys, Kent Agerlund, Chris Nackers, Garth Jones, Robert Wakefield, Chris Muster, Jon Anderson, and Ryan Ephgrave.

PPS:  Thank you to all the awesome ConfigMgr Admins that actually go in and Vote Up the feedback entries on Microsoft Connect!


Written by , Posted .


  1. Chad Simmons

    Great list Nash!

Leave a Comment

You must be logged in to post a comment.