CMWT 2017.02.22.01 Posted

UPDATE: Build 2017.02.22.01 Posted

This is an interim update for specific files only:

  • global.asa (version stamp updated)
  • clients.asp (fixed default sort on computer name)
  • confirm.asp (fixed redirect URL bug)
  • reports.asp (fixed heading)
  • sqlrepdel.asp (added to fix missing delete/confirmation form)

If you don’t have CMWT installed, download the full installer and follow the instructions provided in the installation guide (under the “/docs” folder within the ZIP file):

If you have CMWT installed and just want to update to the newest build, just download the individual files which are newer than what you have, and copy them into the root directory where CMWT is configured:

Known Issues

  • The home page may show incorrect site summary information when CMWT is configured on a CAS host.  This will be fixed soon, but updates are still in testing.  Thanks to Larry for reporting this!
  • The Client Summary report (linked from Site Hierarchy) may show duplicate “No Client” rows.  This because it’s grouping by the Resource ID and it is splitting between those with a Resource ID and those without (unknown computers)

Please keep the feedback coming!



This is extracted from a real, actual conversation from this past week.  Names have been obfuscated to avoid being litigated and imprisonated, er, something like that.  Anyhow, grab your popcorn and enjoy!

Customer: “What are the new Dev and Test environments going to look like?”

Architect: “They will look exactly like the production environment, except that the domain names will end with ‘.dev’ and ‘.test'”

Customer: “But how will it be configured?”

Architect: “Exactly the same as the production environment, except that the domain names will end with ‘.dev’ and ‘.test'”

Customer: “Do you have an architectural diagram for each, so I can get a better idea of how they’re going to be configured?”

Architect: “Did you receive the design document for the production environment?”

Customer: “Yes.”

Architect: “Did you have a chance to look at the diagram in the design document?”

Customer: “Yes.”

Architect: “Dev and Test will be exactly the same.  Including the diagrams.  The only difference will be the domain suffixes.”

Customer: “I would still like to see a diagram to better understand.”

Approximately 30 seconds of complete silence…

Architect: (softly) “I’m not sure what you really need.”

Customer: “I would just feel better having a diagram.”

Architect: “Like the one shown in the production design document?”

Customer: “Yes! Exactly like that!”

Architect: “Dev and Test are identical.  Only the two domain names have different endings.”

Customer: “Ok. I understand.”

Architect: “Ok. That’s good.  Are there any other questions?”

Customer: “So, when do you think you could send me the diagrams for the Dev and Test environments?”

wash. rinse. repeat.

Consequences of Contemplating the Configuration of Configuration Controls


It’s time once again to share another random and stupid thought from an accumulated mass of thoughts accumulated from customer engagements.   In this case, it’s about the concept of “configuration management”.  And, no, I’m not even focusing on System Center Configuration Manager at this point.  This is much, much broader in scope.

If I don’t get the luxury of methodically peeling back the layers via discussion, then it often crashes the party sort of like this…

Me: “I see you have 75 scripts, 54 registry entries, and a bunch of outdated utilities embedded in your Windows image, and it’s adding an hour to your imaging process on average.

Customer: “Yeah.  We use those to configure stuff.

Me: “Stuff.  Yes….” (serious, solemn expression; slowly opens black binder, like Agent Smith while interrogating Neo)

Me: “After reviewing them, it seems that almost every single one is available using Group Policy, and these are domain-joined provisioning processes.”

Customer: “We tried Group Policy in 1992 and didn’t like it.  We tried Sriracha once as well, and didn’t like it either.

This is usually followed by a long, awkward silence, and the occasional throat-clearing noises. Someone’s accidentally plays a Justin Bieber ring tone, before being anxiously silenced.

Luckily, the majority of engagements are more positive.  Customers are often eager to ask about “better” or “easier” ways to pre-configure computers as they deliver (or replace) them in production.  Among the most common topics:

  • Windows 10 Start Menu
  • Windows 10 Task bar
  • Windows desktop settings
  • Explorer settings
  • Power management settings
  • Drive mappings
  • Printer mappings
  • Shortcuts
  • Scheduled Tasks

There are others, but these are some of the most common items brought into the discussion.

My usual response is as follows:

Baseline or Continuous Enforcement?

“Global or Conditional?”

  • Baseline refers to a configuration that is established initially, but will allow users to modify afterwards.
  • Continuous Enforcement refers to a configuration that cannot be modified after it’s been established.
  • Global refers to a configuration that applies to all users without exception.
  • Conditional refers to a configuration that applies differently based on certain criteria.  Examples of this include group memberships, computer models, Active Directory sites, Windows version, and so on.


One common example is the Windows 10 Start Menu.  If you want to configure it via a Baseline approach, you can do that with MDT or SCCM or a script.  If you want to configure it via Continuous Enforcement, you (should) use Group Policy.

The only point I’m really trying to make is that it’s not enough ask WHAT needs to be configured, or even HOW to configure it.  You really need to ask WHY and WHEN.  Every time you reach for the mouse or keyboard, ask yourself “is this the best way to do this?

Analysis Time: GUI vs CLI, round 3

I did a round 1 several years ago, and I can’t remember when round 2 happened, so I played it safe by calling this round 3.  Anyhow, the point of this is what exactly?


The point is, I’m an emphatic proponent of anti-dogma.  It started as a child, when others would say to me “G.I. Joe cannot really fly.” and I set out to prove them wrong.  Then they said “Plastic model battleships can’t really do battle or explode and sink” and again, I proved them wrong (and a big thanks to the local fire department for helping to bring that sea battle to a safe close).

I just had my first cup of real coffee in 48 hours.  I can’t explain why.  I think I was having some sort of self-hatred phase or something.  So, I’m having what Leonard, in the movie Awakenings, would call a “moment of clarity”.  Or, maybe that was Jules in Pulp Fiction, anyhow…

In this case, it’s the dogma that CLI is inherently better than GUI.  It’s the same argument that one programming language is “the best”.  Or that only one kind of food is objectively “the best”.  To me that’s saying one tool in the entire hardware store is “the best”.  Being yet another kind of tool, as I’m often called, a CLI or GUI is “best” with regards to the context.

For scalable repetition, CLI is often the obvious choice.  And for single-instance scenarios, a GUI is often ideal.  But there’s that big middle ground, where the Red Bull drinkers debate the Supplement powder drinkers for world domination of the “my way is the only way” argument.  Those are indeed first world dilemmas.

First off, let’s keep things in perspective.  Just as the early-mid 1960’s were rife with the phrase, “it’s a man’s world“, and don’t hate me, I’m just offering an observation from watching Mad Men; 2017 is still a GUI world.  You can argue this if you want, but if CLI were truly the king of all that is software, you would NEVER see a packaged application installer with a GUI face, and your “smartphone” would only be a command prompt, and nothing more.  Touchscreens, video games, music production software, credit card swipers, ATMs, airline ticket kiosks, all are immersed in the GUI bathtub.

That said, CLI is obviously the king of process automation.  The efficiency comes in with zero-interaction operations.  Pre-configured parameters.  Even when a GUI is optimal for a given task, the trend today is to equip the GUI to save parameters to a file in order to leverage that captured parameter state for CLI repetition.

As one friend of mine would say “if you’re pulling one engine, you rent a hoist, and buy a case of beer.  If you’re pulling 1,000 engines, you get a loan and build an assembly line.

Let’s break the GUI down a bit.  One of the common points of debate is around item selection:  Radio buttons, check boxes, single and multi- select lists, dials, sliders, date pickers, range approximation, color pickers, and so on.

Much of the following is derived from a project I worked on back in college.  We were discussing the merits of CLI vs GUI and our professor said “prove it.  with numbers.”  So we consumed sufficient quantities of caffeine and sugar, and went to work.

If you use a stop watch, and compare two engineers, equally caffeinated and infused with sugary snacks, and have them execute the same tasks in both the GUI and CLI, excluding differences in relative typing speed/accuracy, or mouse control skills, the completion times will lean towards one or the other based on the circumstances:

Disclaimer: This is based on a “first run” scenario, where no preconfigured data is yet available or determined.

  • Check boxes.  If using “Select All” or “Select None” the difference is zero.  But sporadic, non-contiguous selections, are quicker by GUI clicks than by typing in non-contiguous names.  This is further differentiated by the relevance of string pattern consistency.  If RegEx or wildcards can be used, it can lean in the favor of CLI.  But if the selections provide no consistent patterns, the GUI will win hands down.
  • Radio buttons are a wash
  • Single-select lists are a wash if the list does not require scrolling in the GUI.  If the list requires scrolling, the CLI is faster.
  • Multi-select lists are only marginally quicker by GUI due to CLI having tab-completion.  This is predicated on a static set of options to select, which can be fed into an IntelliSense cache.
  • Sliders are faster via CLI (direct input)
  • Date selection is faster via CLI (direct input)
  • Calendar pickers are faster by CLI (direct input)
  • Color pickers will vary by pre-determined color values.  If you don’t know the color, but you are selecting by visual acuity only, the GUI is faster.  If you know the color name or code value, the CLI is faster.

The caveat from here on out is that once the GUI is used, if the inputs are captured, then the CLI steps in and knocks it out of the park.  This goes back to the repetition claim.

So, what does this really mean?  Aside from turning capable IT professionals into non-productive windbags (until the boss walks in), it means that anyone writing software that uses a GUI, and expects their product to be used repeatedly, should be building in a means to capture inputs to a file to facilitate reuse via CLI.  If they are not doing this, they can only fall into one of the following categories:

  • They’re stupid or lazy, or both
  • They don’t really care about customer satisfaction
  • They need to be beaten with a pepper spray can and tasered until the battery runs out

Until next time: happy CLI-ing.

Why SCCM Doesn’t Accidentally Image Machines

I’ve finally had enough.  Maybe it’s the result of hearing people just blindly repeat false garbage and claiming it as fact (I call it “phact” now).  But after hearing yet another so-called (another meme-ish aphorism du jour) engineer state to a group of other so-called engineers that “SCCM can ‘just randomly reimage computers'” because either:

A. They’ve seen it, or more often…

B. They heard a friend say they saw it happen.

Truth:  NO.  SCCM CANNOT RANDOMLY REIMAGE COMPUTERS.  IT DOES NOT.  IT WILL NOT.  IT CAN’T.  IT WON’T.  Stop saying stupid shit like this.

The real reason is that someone (aka a stupid idiot, yes, double redundancy intended) was poking around and made changes without knowing what they were doing.  That’s it.  I’ve seen “unintended” cases of SCCM involved with reimaging computers, but it was ALWAYS ALWAYS ALWAYS (and still is) due to human stupidity.

I’m probably missing a few steps here, in fact, yes, I see one right now:  The Task Sequence Deployment setting labelled “Make available to the following” from the Deployment Settings tab (e.g. “Only media and PXE” versus “Configuration Manager clients, media and PXE”, etc.)


In short, your resident idiot would have to target the wrong collection, OR, put the wrong machines into the targeted collection, OR, use the wrong deployment assignment setting, AND…

Have the machine on a subnet with access to PXE, AND boot to the network (boot config), AND press F12 before the boot time-out expires, AND (either) did not put a password on the Task Sequence deployment OR entered the password.  That’s a lot of “accidental” stuff to accidentally trip over by accident.  Maybe your admin needs a walker and a crash helmet.


10 Questions – Ben

Ben didn’t provide any identifying information, so that’s all I have.


[1] How did you get into a career in IT, and when?

To tell that story, you’d need to be frozen, launched into space, swing around a distant galaxy, and come back when you’ve only aged a year and I’m 50,000 years old.  Then I might be half-way through that story.  The rest of mankind would have died off from sheer boredom by then.

My body would be long gone by then as well, but my mouth would be preserved in a jar filled with some greenish liquid and a bunch of wires connected to a machine with little lights on it.  Bald-headed aliens would be trying to analyze this constantly moving creature and figure out what it wants.

Technically, I started in IT in 1974, but that was a project funded by NASA with our local elementary schools (I programmed a dot-matrix printout of the Pink Panther using COBOL along with 11 other kids in the 2nd grade)

Officially: 1996.  As a “CAD and Windows NT LAN Administrator” for a large defense company.  Weird title.  Weird job.

[2] What big things [in IT] do you see coming in the next 5 to 10 years?

Virtual displays.  Gradually getting rid of video screens, phones with screens and TVs.  Something thinner, lighter, and less stupid-looking than today’s VR goggles.  You’ll be able to share what you’re watching with selected people, like team-mode in video games.  You won’t need a desktop monitor, TV or conference room projectors anymore.

[3] What’s the weirdest thing you’ve seen?

Have you ever sat in an Emergency Room at 2:00 AM on a Saturday night?

[4] What do you think about self-driving vehicles?

Great idea.  They can’t happen soon enough.

[5] Most recent interesting experience?

Walking around downtown Atlanta in September, 2016, at 2:30 AM during the Microsoft Ignite conference.  I handed out leftover vendor t-shirts to some homeless guys and had a really interesting conversation with a Vietnam war veteran.  I’m pretty sure he didn’t recall any of that the next day. (I still laugh at the thought of a bunch of passed out street folks wearing brand new IT vendor t-shirts and ball caps)

[6] Favorite places you’ve visited?

Lots of cities and a few beaches, mountains, etc. from Virginia, to New York, California, Colorado, Oregon, and Georgia.  Trader Joe’s, IKEA, and any Lowe’s or Home Depot when I have a new project going on. (Sam Ash music stores in NYC are incredible)

[7] Hobbies?

Just two kinds: those I can afford, and those I cannot.  In the first group: walking, jogging, mountain biking, eating, drinking, talking smack, and making funny faces.  I have a few others like gardening and pretending I can sing while driving alone.

[8] Favorite Food and Drink?

Indian or Thai (or Bangladeshi).  Beer: Belgian Dark Ales are my favorite.  Wine: Merlot or Malbec.  Aside from that: Tropical Smoothie Cafe “Get up and Goji” is really good.  Cereal (Super Nutty Toffey Crunch, from Trader Joe’s)

[9] Favorite bloggers or sources of Tech Info?

Oh boy.  Just search on “sccm”, “mdt”, “orchestrator”, “sql server”, “azure” or “powershell” and the top 10 hits on any of those are where I hit most.  I still keep my eyes on the CAD/CAM world (check out Ralph Grabowski), since I cut my teeth there for almost 20 years (yes, I still miss writing design automation code in LISP).  My Twitter feed is a big source for daily info ingestion.

[10] If you weren’t working in IT, what do you think you’d be doing?

5-10, with good behavior (possibly).

Top 10 Tech Issues for Last Month


1 – SCCM Site Boundaries Stayed at the Bar too long.  Got in a fight with some angry UFC folks and wound up in the ER with tubes going in all sides.

Doctor writes in patient record: “Be sure to talk with your Network engineers to insure they are staying on top of their end.  No messing around with overlapping subnets, or laughing hysterically at the need to maintain AD sites and services.  Then be sure to actually heed the information they provide you and build your site boundaries to correctly match the environment.”

2 – Don’t forget about a Fallback Status Point

3 – Don’t forget to mention the FSP in the client push settings

4 – Don’t forget to include the appropriate accounts, and account permissions, for the client push installation account.  Especially when dealing with AD Forest Trusts and machines on both sides of the trust.

5 – Coffee.  Never never never forget about the coffee.  RedBull/Monster, etc. are okay, but real men chew their coffee whole, worry about the liquid part later.  Bonus: If you can manage to push the grinds through a tube, then injection may be your best bet.

6 – Get outdoors.  Staring at the screen for too long leads to glazing over, which leads to missing obvious things.

7 – Primal scream therapy.  It’s still allowed.  Practice it often, in random locations.  In the middle of a staff meeting.  In an elevator.  Standing in line at the deli. Whatever.  It can be very refreshing.

8 – SCCM Backups should be targeted to a different location than the SCCM drive itself.  And make sure there’s an offline backup process for double-protection.  If someone else manages the virtual hosting environment, and storage, talk to them about their backup processes to find a solution to fit everyone’s needs.

9 – Active Directory.  Do not ignore it.  If you don’t regularly check on DNS and DHCP configurations (and health), start doing it now.  Keep the accounts clean.  Devices that don’t exist, should be vaporized with extreme anger and a twitching eyelid.

10 – Always focus on the process first.  Then worry about the tools and methods.  Quite often, the best tools are a whiteboard and a cup of coffee (see item 5).  90% of my engagements end up chopping out a ton of unnecessary work just by standing back to take a fresh look at how things are done.