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.


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.

The Ballad of Orchestrator

wpid-chinese-take-out.jpgIf I had a dollar for every time I’ve had a discussion with someone who works with Microsoft System Center, while I stare at the floor, wondering why they never bothered to have that weird reddish-brown stain removed, and it’s in their main lobby, as they describe the pain, and effort they endured to build some crazy semi-automated chain of mouse traps using a wheelbarrow full of third-party utilities, truckloads of scripting, and a few crates of some long-forgotten Windows CLI utilities, registry hacks and whatever, and after they were done, I’d be thinking to myself “that was one stupidly-long run-on sentence”, but I end up saying, “You know? You could’ve knocked that out in a lot less time using Orchestrator”, well, I’d be rich enough to not have time to write a blog.  I’d be too busy having my toenails custom painted while skydiving from my private jet onto the deck of my private yacht. Floating in the lagoon of my private island.  Okay, that’s a big stretch.


First off, 99.999999999% of the time, here’s what the response is, “What’s Orchestrator?”

(15 seconds of awkward silence ensues)

Whatever Microsoft has paid their marketing folks, I would like to officially ask for 10% of it, just for doing my part to inform their customers, “well, it’s this amazing virtual Lego kit that you can use to build just about anything. Oh, and by the way, you already paid for it.”  That might help pay a few bills at least.  I think that I’ve earned it.  Or I could be delusional too.

Anyhow, for those who still begin every explanation with “it was called Opalis, once…”, and have ripped open that Christmas box and put the batteries inside, you know what I’m talking about.  You also know the dreaded feeling of hearing someone say one of the following:

“They didn’t make any changes to it in System Center 2016”

“It’s dead, Jim.  Long live the cloud.”

Sad.  Truly sad. It never really had it’s glory day (imho).  Isolated moments of sheer awesomeness are to be found, for sure.  But on a ubiquitous (see?  you didn’t think I could whip out a big word like ubiquitous, did you?) and pervasive scale? No; not what it really deserved. It was that incredible 2nd string player, drafted in the 2nd round, that was capable of smashing records, but never got on the field, and now it’s hitting retirement age.

Not so fast.

Just like Arnold Schwarzenegger (I cheated on the spelling, I had to), it can still press a few hundred pounds while smiling.  Maybe while clenching a cigar in it’s mouth at the same time.

Some interesting use-cases I’ve seen in the past year or two…

  • The typical New-Hire / Employee-Term scenario runbooks, but with extensions for ordering facilities services (phone, desk, chair, whiteboard), telecom (phone), computer equipment (HR app checkbox for “mobile user” triggers order for laptop or tablet), and notifying front desk security personnel with employee photo.  And don’t forget the standard AD group memberships, attributes, and OU management stuff.
  • Monitoring file system folder where app-devs upload final code check-ins, read specific files to create SCCM applications, deployment types, detection methods, requirements, as well as distribute to certain DP groups, and deploy to Collections (with additional parameters)

There have been a few others.  Some were just discussions around “what if…”, which could have easily turned into more amazing concoctions, but I didn’t stick around long enough to find out if they did.

Alas, before I toss back a ceremonial shot (of something cheap, like me), I have to say I’ve spent some time with Azure Automation runbook authoring and I have to say, it’s very, very promising indeed.