Personal, Projects, Scripting, System Center, windows

And now for another stupid pet project

First, there was project number one. I called it “WWA”, which was a clever short name for “Windows Web Admin”. Even though I kept hearing it sounded like a name for a wrestling tournament.  Anyhow, it fell over and sank into a swamp.

Then there was project number two, or “AppAdmin”, which almost fell over and sank, but it was built inside a big shipyard, and they don’t let things sink there, so it floated for a while (I’m told it’s still afloat somehow).

Then, there was project number three, but I can’t state it’s name for legal reasons, or because I promised it might result in me delivering a flaming box of dog poo to a certain someone’s porch, after they ruined that project just as it was maturing, but that’s for another time and place.

Then there was project four, but I can’t talk about that one either, so I’ll skip to project five, CMWT.  But nobody cares about that one, so number six, was putting a hand-rubbed wax finish on someone else’s PowerShell script, and tossing it up on GitHub and PowerShell Gallery, along with projects seven, eight and nine.  And I’m surprised I still remember how to spell the number 8.  So anyhow…

Announcing SkatterTools

(imagine Morgan Freeman narrating from here on)

What is it?

Skatterbrainz Tools.  A really clever name.

It’s a portable web console app thing, for viewing and modifying things in your Active Directory and Configuration Manager environments, from the comfort of your beer-stained laptop.  Think of it like CMWT if it were (A) trying to copy the concept from Microsoft Windows Admin Center, and (B) didn’t require using a separate “server” or anything special**.  Yes, those are double-asterisks.  That means there’s some hidden footnote down below, but don’t look yet, I have to finish boring the shit out of you with this part first.

Why is it?

Because I needed a break from other things, like family matters during the holidays, a dog that loves chewing on furniture, and a 20 year old cat that wanders the house at 3am making really weird sounds.  And I just wanted to see if it was possible to…

  • Build a 100% web console UX to interface with AD and ConfigMgr using PowerShell
  • Not have to touch IIS or any web hosting mess
  • Make it customize-able, free, and open-source
  • Make it through the holidays once again

Where is it?

  • Like a lot of my stuff, it’s up on GitHub

What can it do?

  • View and cross-link:
    • AD users, computers, groups, sites, sitelinks, domain controllers, OUs
    • ConfigMgr users, devices, collections, applications, packages, boot images, task sequences, updates, and scripts
    • ConfigMgr site status, queries, discovery methods, certificates, Forest publishing, boundary groups and boundaries
    • Software inventory, software files
  • Manage:
    • Add/remove AD group members
    • View computers by AD user profile paths
    • Add/remove ConfigMgr collection members **
    • Those damned double-asterisks again, hmm.

Installation and Setup

  • Download PoSH Server here and install it (don’t worry, I checked it and it seems safe, you can trust me, I worked for the government once, sort of)
  • Download the GitHub repo (big green button – top right – zip option)
  • Extract the “poshserver” folder from the GitHub download into a local path like C:\ThisIsTheDumbestShitEver
  • Open the “config.txt” file and edit the settings to suit your needs
  • It is now ready to blow your mind, almost

Starting it Up

  • Add some gasoline and finely-crushed road flares, oh, wait, wrong stuff…
  • Create a desktop shortcut named “Start SkatterTools”…
Target: powershell.exe Start-PoshServer -HomeDirectory "c:\ThisIsTheDumbestShitEver" -CustomConfig "c:\ThisIsTheDumbestShitEver\sktools.ps1"
  • Create another desktop shortcut, named “Open SkatterTools” or “Coolest Shit Ever!”…
Target: http://localhost:8080/
  • Right-click the first shortcut, select “Run as Administrator”, and wait for it to open and say something like this…
  • Double-click the second shortcut and have your Kleenex box nearby
  • Click on one of the sidebar headings and watch the slick CSS stylings ooze all over your eyeballs and onto the floor.  Compliments of some sample code I found on W3Schools.  What a great site.

If you need to shut it down, just close the browser and close the PowerShell console.  There’s instructions on the PoSH Server site for how to configure it like a service, so it runs as a background job. You don’t have to do that though.

Is there any official support?

  • Are you kidding?
  • You can submit bug reports and enhancement requests using the “Issues” link on the GitHub repo.
  • Work comes first.  I have to keep my customers happy and my bills paid
  • I’m still adding things to it frequently, but work may cause some delays getting around to it
  • You can submit your own changes via GitHub (pull requests, etc.) or just submit Issues if you prefer

Is there a roadmap?  Where is it going next?

  • Real (stupid) men don’t use maps!  The journey is the dream, man.
  • Where are any of us really going?  You ever ask that question?
  • Don’t ask that question, it’s depressing.  Enjoy the now.
  • Seriously, yes, I have a metric butt-ton of things I plan to add or improve

Double Asterisk-o-rama

  • Double-asterisks denote two things here:
    • Features are not yet complete.  Things will change.  Oceans dry up. Mountains wear down. Regimes are toppled.  Keith Richards is forever.
    • This is free stuff, and it comes without any strings attached.  No warranties, or guarantees.  No promises (other than it might possibly entertain you if you’re bored), and poor you gets to assume any and all liability, risk and responsibility for anything bad if you use it improperly or in a production environment of some kind, or any environment where alleged (love that word) damages may have occurred or been coerced by tertiary incidental hereinafters forthwith and notwithstanding, that are void where prohibited, taxed or regulated. Batteries not included.
    • Whatever that means


Devices, Scripting, System Center, Technology, windows

ConfigMgr OSD Device Naming

For whatever reasons, this still seems to be an interesting and ongoing topic of discussion/debate/argument/angst/drinking, etc.  I’m talking about assigning names to computers while they’re being imaged or refreshed.  There are quite a few common scenarios, and an unknown variety of less-common scenarios, I’m sure.  Some embrace this and some despise it.  The views are all over the place it seems.  But regardless, as a consultant, I’m very often tasked with advising (okay: consulting) customers on options for either fully or partially automating the process.

Personally, I approach all automation scenarios with the same view: Explain why you need it.  Very often, automation is simply taking over from a poorly designed manual process.  As an old colleague of mine once said (and I repeat ad nauseum) “If you automate a broken process, you can only get an automated broken process“.  It’s true.  If the customer is receptive to a discussion about alternatives, it always produces a more positive outcome.  So far, at least.

Anyhow, I wanted to lay out some common scenarios and examples for handling them.  These are based on the use of either Microsoft System Center Configuration Manager (aka ConfigMgr, aka SCCM), or Microsoft Deployment Toolkit (aka MDT).  I am by no means implying these are the ONLY way to accomplish each scenario.  They are provided simply as ONE way out of many, but which I’ve found offer the best benefit for the least effort and risk.  You are free to roll your eyes and call me a dumbass, that’s fine, because I plug my ears anyway.

Manual: Stick shift (The Exploding Space Shuttle Method)

This method requires a human to manually enter the desired name to assign to the device.  It’s the easiest/quickest method to implement.

For ConfigMgr environments, the quickest implementation is by assigning “OSDComputerName” Collection Variable to a device collection.  For bare metal (e.g. new) machines, that is often the “Unknown Computers” collection, but for refresh/reimage scenarios it’s whatever device collection is being targeted by the relevant task sequence.

Pro – easy, fast, cheap

Con – prone to human error

Fully-Automatic: Serial Number

Since Windows 10 still imposes a limit of 15 characters, with restrictions on certain alphanumeric characters, this method often includes some checking/filtering to insure that the process doesn’t swallow a grenade and make a mess.  This is less common today with physical machines, but often occurs with virtualized environments due to differing serial number formats.  This example uses the BIOS serial number as the machine name.  If the serial number is longer than 15 characters, only the last 15 characters are used.  So “CNU1234567891234” would become “NU1234567891234”.

# Set-ComputerNameAutoSN.ps1
$snmax = 15
$csn = (Get-WmiObject -Class Win32_SystemEnclosure).SerialNumber
if ($csn.Count -gt 1) { $csn = $csn[0] }
if ($csn.Length -gt $snmax) {
  $csn = $csn.Substring($csn.Length - $snmax)
try {
  $tsenv = New-Object -ComObject Microsoft.SMS.TSEnvironment
  $tsenv.Value("OSDComputerName") = $csn
  Write-Output 0
catch {
  Write-Output "not running in a task sequence environment"

Note: You might be wondering why the “if ($csn.Count -gt 1)…” stuff.  That’s in case the device is sitting in a dock or connected via an e-dock or dongle, which often causes WMI queries to return an array instead of a single integer for things like ChassisTypes and so on.  Checking the count of values assigned to the variable allows for retrieving just the first element in the array.

Full-Automatic: Form-Factor + Serial Number

This is a variation on the preceding example, whereby a prefix (or sometimes a suffix) is added to the name to identify a general form, such as “D” for desktop, and “L” for laptop, and so on.  This example would take a ChassisType value of 3 and the last 10 characters (arbitrary, not required) of the Serial Number of “CNU1234567891234” and concatenate these into “D4567891234”

# Set-ComputerNameAutoFormSN.ps1
$snmax = 10
$csn = (Get-WmiObject -Class Win32_SystemEnclosure).SerialNumber
$cff = (Get-WmiObject -Class Win32_SystemEnclosure).ChassisTypes
if ($csn.Count -gt 1) { $csn = $csn[0] }
if ($cff.Count -gt 1) { $cff = $cff[0] }
if ($csn.Length -gt $snmax) {
  $csn = $csn.Substring($csn.Length - $snmax)
switch ($cff) {
   3 { $ff = 'D'; break }
   4 { $ff = 'D'; break }
   5 { $ff = 'D'; break }
   6 { $ff = 'D'; break }
   7 { $ff = 'D'; break }
   8 { $ff = 'L'; break }
   9 { $ff = 'L'; break }
  10 { $ff = 'L'; break }
  11 { $ff = 'L'; break }
  14 { $ff = 'L'; break }
  default { $ff = 'X'; break }
$newname = $ff+'-'+$csn
try {
  $tsenv = New-Object -ComObject Microsoft.SMS.TSEnvironment
  $tsenv.Value("OSDComputerName") = $newname
  Write-Output 0
catch {
  Write-Output "you forgot to flush the toilet"

Semi-Automatic: Location Code + Form Factor + Serial Number

This one is based on a scenario where all devices are imaged at a single location, and shipped out to other locations, whereby the customer wishes to place the AD computer account into an associated location-based Organizational Unit (OU) during the imaging process.  This can be done using User-Driven Interface (UDI) forms, or by script.  I prefer script because I’m more comfortable with it and there are far fewer moving parts to contend with.  That said, there are several ways to do this:

Option 1 – SCCM Collection Variable

A collection variable can be assigned to the target collection in order to prompt for a location identifier.  This could be a number, a name, or an abbreviation, it doesn’t really matter since it’s just a textbox form input.

Option 2 – MDT / SCCM Task Sequence Script

Some flavors of this involve copying the ServiceUI.exe component from the MDT installation into the script package, so that ServiceUI.exe can be invoked to suppress the task sequence progress UI and allow custom script GUI forms to display properly.  I did it this way for a long time, until I ran across this really nice script from John Warnken *here*.  After some (minor) tweaking it can easily be adapted to almost any need.  The example below prompts the technician for a 3-character Location Code and then concatenates the device name using [Location]+[FormFactor]+[SerialNumber] up to 15 characters, so the [SerialNumber] value is truncated to the last 10 characters (max).

Displays a gui prompt for a computername usable in a SCCM OSD Task Sequence. 
.PARAMETER testing 
The is a switch parameter that is used to test the script outside of a SCCM Task Sequence. 
If this -testing is used the script will not load the OSD objects that are only present while a task sequence is running. 
instead it will use write-output to display the selection. 
powershell -executionpolicy Bypass -file .\Set-ComputerNameLocationPrompt.ps1 
powershell -file .\Set-ComputerNameLocationPrompt.ps1 -testing 
This is a very simple version of a OSD prompt for a computername. You can add extra validation to the computer name, for example a regular expression test 
to ensure it meets standard form used in your environment. Addtional form object can be added to other options that you may want to set 
task sequence variables for. Also as a simple example, I just added the xaml for the wpf form as a variable in the script. You have the option of storing it in 
a external file if your form gets complex.

Jonathan Warnken - jon.warnken (at) gmail (dot) com
Skatterbrainz - @skatterbrainzz
    [switch] $Testing
$snmax = 10
  # this section provides the gluten-free, high-protein alternative to ServiceUI.exe
  $tsenv = New-Object -COMObject Microsoft.SMS.TSEnvironment  
  $tsui  = New-Object -COMObject Microsoft.SMS.TSProgressUI  
  $OSDComputername = $tsenv.Value("OSDComputername")

# query machine serial number and chassis type from WMI
$csn = Get-WmiObject -Class Win32_SystemEnclosure | Select-Object -ExpandProperty SerialNumber
$cff = Get-WmiObject -Class Win32_SystemEnclosure | Select-Object -ExpandProperty ChassisTypes

# check if return values are an array and if true, then only use the first element
if ($csn.Count -gt 1) { $csn = $csn[0] }
if ($cff.Count -gt 1) { $cff = $cff[0] }

# if serial number is longer than 10 chars, get last 10 chars only
if ($csn.Length -gt $snmax) {
  $csn = $csn.Substring($csn.Length - $snmax)
# derive form factor code from chassis type code
switch ($cff) {
   3 { $ff = 'D'; break }
   4 { $ff = 'D'; break }
   5 { $ff = 'D'; break }
   6 { $ff = 'D'; break }
   7 { $ff = 'D'; break }
   8 { $ff = 'L'; break }
   9 { $ff = 'L'; break }
  10 { $ff = 'L'; break }
  11 { $ff = 'L'; break }
  14 { $ff = 'L'; break }
  default { $ff = 'X'; break }
[xml]$XAML = @' 
  Title="SCCM OSD Computername" Height="154" Width="425" Topmost="True" WindowStyle="ToolWindow"> 
    <Label Name="Computername_label" Content="Location:" HorizontalAlignment="Left" Height="27" Margin="0,10,0,0" VerticalAlignment="Top" Width="241"/> 
    <TextBox Name="LocationCode_text" HorizontalAlignment="Left" Height="27" Margin="146,10,0,0" TextWrapping="Wrap" Text=" " VerticalAlignment="Top" Width="220"/> 
    <Button Name="Continue_button" Content="Continue" HorizontalAlignment="Left" Margin="201,62,0,0" VerticalAlignment="Top" Width="75"/> 
#Read XAML 
$reader=(New-Object System.Xml.XmlNodeReader $xaml) 
$Form=[Windows.Markup.XamlReader]::Load( $reader )

# add form objects as script variables 
$xaml.SelectNodes("//*[@Name]") | %{Set-Variable -Name ($_.Name) -Value $Form.FindName($_.Name)}

# set the default value for the form textbox
$LocationCode_text.Text = 'STL'

# assign event handler to the "Continue" button
  $Script:LocationCode = $LocationCode_text.Text.ToString()
# display the form for user input
$Form.ShowDialog() | Out-Null

# after form is closed, concatenate computer name from input values and other variables
$computername = $Script:LocationCode+$ff+$csn

if (!$Testing) {
  $tsenv.Value("OSDComputername") = $computername 
  Write-Output " OSDComputername set to $($tsenv.value("OSDComputername"))" 
else { 
  Write-Output " OSDComputername would be set to $computername" 

Pro – works with PXE and offline media

Con – some scripting and testing required

Fully Automatic: Location Code + Form Factor + Serial Number

This method relies on something available from the environment upon which to determine the “location”.  For MDT this is often using the CustomSettings.ini with the IP Gateway address.  Using a logical if/then you can construct a logic mapping of IP gateway = Location or location Code.

Option 1 – MDT Deployment Share Configuration

This one uses a CustomSettings.ini which reads the IPv4 Gateway address and the Serial Number to concatenate the resultant device name.  For a better example of this and a much, much better explanation by the one-and-only Mikael Nystrom, please read this first.

Priority=Init, ByDesktop, ByLaptop, DefaultGateway, Default 
Properties=ComputerLocationName, ComputerTypeName, ComputerSerialNumber









Using this sample INI configuration, a laptop device with Serial Number “CNU1234567891234” connected to IP gateway would end up with an assigned name of “NYCL4567891234”.  If the DefaultGateway is not defined in the list, it will default to location code “XXX”.  If the form factor cannot determine Desktop or Laptop it will default to “X”.  So, using the same serial number value it would end up as “XXXX4567891234”.

Option 2 – SCCM Task Sequence

This example adapts the semi-automatic example above, but replaces the GUI prompt with a check for the IP gateway.

# Set-ComputerNameAutoLocIPFormFactorSN.ps1
$csn = (Get-WmiObject -Class Win32_SystemEnclosure).SerialNumber
$cff = (Get-WmiObject -Class Win32_SystemEnclosure).ChassisTypes
if ($csn.Count -gt 1) { $csn = $csn[0] }
if ($cff.Count -gt 1) { $cff = $cff[0] }
if ($csn.Length -gt 15) {
  $csn = $csn.Substring($csn.Length - 15)
$gwa = (Get-WmiObject -Class Win32_NetworkAdapterConfiguration | Where {$_.IPEnabled -eq $True}).DefaultIPGateway
switch ($gwa) {
  '' {
    $location = 'Norfolk'
    $loccode = 'NOR'
  '' {
    $location = 'Chicago'
    $loccode = 'CHI'
  default {
    $location = 'NewYork'
    $loccode = 'NYC'
switch ($cff) {
   3 { $ff = 'D'; break }
   4 { $ff = 'D'; break }
   5 { $ff = 'D'; break }
   6 { $ff = 'D'; break }
   7 { $ff = 'D'; break }
   8 { $ff = 'L'; break }
   9 { $ff = 'L'; break }
  10 { $ff = 'L'; break }
  11 { $ff = 'L'; break }
  14 { $ff = 'L'; break }
  default { $ff = 'X'; break }
$newName = $loccode+$ff+$csn
try {
  $tsenv = New-Object -ComObject Microsoft.SMS.TSEnvironment
  $tsenv.Value("OSDComputerName") = $newName
  Write-Output 0
catch {
  Write-Output "not running in a task sequence environment"

Option 3 – SCCM Task Sequence + Collection Variable

This example came from a project where the customer had created a device collection for each branch location, which had a Collection Variable “DeviceLoc” assigned, and having deployed a refresh task sequence to each.  So in this scenario, they wanted to merge the script with the collection variable to derive the new name.  Is this ideal?  Not for most people, but due to time constraints it had to work.

$csn = (Get-WmiObject -Class Win32_SystemEnclosure).SerialNumber
$cff = (Get-WmiObject -Class Win32_SystemEnclosure).ChassisTypes
if ($csn.Count -gt 1) { $csn = $csn[0] }
if ($cff.Count -gt 1) { $cff = $cff[0] }
if ($csn.Length -gt 15) {
  $csn = $csn.Substring($csn.Length - 15)
$gwa = (Get-WmiObject -Class Win32_NetworkAdapterConfiguration | Where {$_.IPEnabled -eq $True}).DefaultIPGateway
switch ($gwa) {
  '' {
    $location = 'Norfolk'
    $loccode = 'NOR'
  '' {
    $location = 'Chicago'
    $loccode = 'CHI'
  default {
    $location = 'NewYork'
    $loccode = 'NYC'
switch ($cff) {
   3 { $ff = 'D'; break }
   4 { $ff = 'D'; break }
   5 { $ff = 'D'; break }
   6 { $ff = 'D'; break }
   7 { $ff = 'D'; break }
   8 { $ff = 'L'; break }
   9 { $ff = 'L'; break }
  10 { $ff = 'L'; break }
  11 { $ff = 'L'; break }
  14 { $ff = 'L'; break }
  default { $ff = 'X'; $ousub = ''; break }
try {
  $tsenv = New-Object -ComObject Microsoft.SMS.TSEnvironment
  $loc = $tsenv.Value("DeviceLoc")
  if ([string]::IsNullOrEmpty($loc)) {
    $newName = 'CRP'+$ff+$csn
  else {
    $newName = $loc+$ff+$csn
  $tsenv.Value("OSDComputerName") = $newName
  Write-Output 0
catch {
  Write-Output "not running in a task sequence environment"

Conclusion / Summary

This is only a small sample of all the variations and scenarios many of us encounter.  Other variants include setting the Organizational Unit (OU) path, adding the device to domain security groups, and so on.  I would like to thank John Warnken for the script code he posted on TechNet, which makes it so much easier to deal with the progress bar UI when using custom forms.

I’d also like to say that you shouldn’t look at these and think you need to immediately put them into use.  Test labs are one thing.  But production requires serious review and planning to determine what really makes the most sense.  For example, a lot of customers I work with have persistently used a location code for device names, but when they really assess the business environment, they find many devices roam to different locations, or don’t really stay in any “official” location (home, hotel, on the road, etc.)  And when pressed to explain how the location code provides real value, many don’t have a rationale besides, “it’s how we’ve always done it”.  So think it through.  Ask if you really need to do something like this and if so, why.  Then work on the how aspects.

Do you have other/better examples you’d like to share?  Post a comment below.  Thank you for reading!


Windows 10 Soup Sandwiches

Version 2.1 (I lost Version 1.0 somehow, from the old blog, but it was focused on Windows 7, 8.1 anyway)

An ad hoc collection of wine-infused recipes to help smoosh Windows 10 like a ball of clay, or like a soggy sandwich.

Disable Windows Firewall (MDT, SCCM)

Disable Windows Firewall (GPO)

Disable Windows Defender (GPO)

Deploy .NET Framework 3.5 with Feature on Demand (GPO)

Enable Controlled Folder Access (GPO)

Create Shortcuts on Desktop, Start Menu (GPO)

Disable IPv6 (GPO)

Configure, Start, Stop Windows Services (GPO)

Block and Disable Cortana (GPO)

Set default Web Browser (GPO)

Waste Time Customizing the Start Menu and Taskbar (GPO, Script, MDT, SCCM)

Configure OEM Support info and Company Logo on Support page (GPO)

Block Windows Store and Store Apps (GPO)

Remove Store Apps during Imaging (MDT, SCCM, etc.)

Remove OneDrive from File Explorer (GPO)

Show File Extensions in File Explorer (GPO)

Show Hidden Folders and Files in File Explorer (GPO)

Show File Explorer Menu Bar (GPO)

Expand to Current Folder in File Explorer (GPO)

Customize and Push BGInfo to Desktops (script)

Customize and Push BGInfo to Desktops (GPO)

Destroy and Annihilate SMBv1 by any means necessary

TLS Configuration Guidelines (hotfix, registry, GPO)

Create and Configure a Group Policy Central Store

Updates 2.1

Add Domain User to Local Administrators Group (GPO)

Add Domain Users to Remote Desktop Users on Servers (GPO)

Modify Registry Key Permissions on Domain Computers (GPO)

Create Scheduled Tasks using Group Policy (script, GPO)

Configure PowerShell Settings using Group Policy (GPO)

Prompt for Computer Name / OSD Variable in Task Sequence (script)

Mass Upgrade Windows 10 using PowerShell (script)

Replicate MDT Boot Images to multiple WDS/PXE servers (script)

Set Google Chrome as Default Browser (GPO)

More to be added (version will be updated too)

Scripting, System Center, Technology

ConfigMgr Script Deployments


The following caffeine-induced mess was the result of a quick demo session conducted with a customer about the use of the new “Scripts” feature in Configuration Manager 1710+.  There are other examples floating about the Internet which are equally good, if not better, but just finished unpacking, doing laundry, walking the dog, and needed something to do.

What is it?

The new “Scripts” feature allows you to perform “real-time” execution of PowerShell scripts against a Device Collection or individual members of a Device Collection.  It is worth noting that you cannot deploy to individual Devices from within the Devices node of the console, it only works from within, and beneath, the Device Collections node.  The script is executed on the client remotely, so the shell context is local to the remote client.  This means if you instruct the code to look at C:, it will be looking for C: on the remote device(s).

What Can You Use This For?

The answer to this question depends on your intentions and personality.  If you’re an eager workaholic, the sky is the limit.  If you’re a diabolical evil bastard with malicious thoughts, the sky is also the limit.  Is this potentially dangerous?  Yes.  But EVERYTHING in life is potentially dangerous, even brushing your teeth and going for a walk.  So weigh your risks and proceed accordingly.  I’ve provided a few examples below to illustrate some possible use cases.  Read the disclaimer before attempting to use any of them.

Preliminary Stuff

The first thing you need is to have Configuration Manager 1710 or later.  The second thing you need is to check the box to “Consent to use Pre-Release features” (Administration / Site Configuration / Sites / Hierarchy Settings / General tab).  The third thing you need (for testing anyway) is to un-check the box right below it that says “Do not allow script authors to approve their own scripts”.  If you do not un-check that option, you will be able to create script items, but you won’t be able to deploy them.

The next step is to enable the pre-release feature “Create and run scripts”:  Administration / Updates and Servicing / Features.  Right-click “Create and run scripts” and select “Turn on”. Once you’ve enabled the feature, the first time at least, you may need to close and re-open the console.  This is not always the case it seems, but I have seen this most of the time.

The Process

Create the Script

Once everything is enabled and ready to go, you should be ready to destroy, I mean, ready to begin.

  1. Select “Software Library”
  2. Select “Scripts”
  3. Select “Create Script” on the ribbon menu at top-left (or right-click and choose “Create Script”)
  4. Provide a Name
  5. Import or Paste the script code (only PowerShell is supported as of now)
  6. Tip: Make sure your script code returns an exit code of some sort to indicate success/fail to ConfigMgr (example: Write-Output 0)
  7. Click Next, Next, and Close

Approve the Script

  1. Right-click on the Script item
  2. Select Approve/Deny
  3. Click Next (I still don’t know why, but you have to, at least for now)
  4. Choose “Approve” or “Deny” and enter an “Approver comment”
    NOTE: Many organizations have procedures that require documenting approval authorization directly on the change items involved with a given change.  And to change that would require changing the way you manage change, which would require change management to effect the change and change the way you’re changing things.
  5. Click Next, Next and Close

Deploy the Script

  1. Select Assets and Compliance
  2. Select Device Collections
  3. Navigate to an appropriate device collection
    1. To deploy the script to all members, right-click on the Collection and select “Run Script”
    2. To deploy the script to individual members, select ‘Show Members’, right-click on each member (resource) and select “Run Script”
  4. Choose the approved Script from the library listbox, and click Next
  5. Click Next again (safety switch, good idea!)
  6. Watch the green bar thing slide across the progress banner a few times
  7. When it’s done, review the pretty Bar Chart.

    Select the “Bar Chart” drop-down to change reports to “Pie Chart” or “Data Table” display.
  8. Change the “Script Output” selection to “Script Exit Code” to view results by exit code values.


You can include parameter inputs within a script by including the param(…) block at the very top.  As soon as you type in param ( and then enter a variable name, like $MyParam, you should notice the ‘Script Parameters’ node appear in the left-hand panel below “Script”.  Remember to close the parentheses on param ().  This adds a new set of options that you’ll see when you click Next in the Create Script form.

This allows you to make scripts more flexible at runtime, so you can provide specific inputs as needed, rather than making a bunch of duplicate scripts with only minor variations between them.


So, here are just a few basic examples for using this feature.  You can obviously apply more brain juice to this and concoct way-more amazing awesomeness than this stuff, but here’s a taste.  These are provided “as-is” without any warranty or guarantee of fitness or function for any purposes whatsoever.  The author assumes no liability or responsibility for use,  or derivative use, of any kind in any environment on any planet in any universe for any reason whatsoever, notwithstanding, hereinafter, forthwith, batteries not included, actual results may vary, void where prohibited or taxed, past results do not indicate future performance.

Collect Client Log Files

# Collect-ClientLogs.ps1
# Modify $TargetPath to suit your needs
$SourcePath = 'C:\Windows\CCM\Logs'
$TargetPath = '\\\ClientLogs$\'+$($env:COMPUTERNAME)
if (!(Test-Path $TargetPath)) { mkdir $TargetPath }
robocopy $SourcePath $TargetPath *.log /R:2 /W:2 /XO /MT:16
if (Test-Path $TargetPath) {
  Write-Output 0
else {
  Write-Output -1

Refresh Group Policy

# Refresh-GroupPolicy.ps1
Write-Output 0

Modify Folder Permissions

# Set-FolderPermissions.ps1
param (
  [string] $FolderPath
if (Test-Path $FolderPath) {
  ICACLS "$FolderPath" /grant 'USERS:(OI)(CI)(M)' /T /C /Q
  Write-Output 0
else {
  Write-Output -1


If you haven’t looked into this feature yet, I strongly recommend you give it a try IN A TESTING ENVIRONMENT.

How’s my driving?

Did I miss anything?  Did you find any bugs?  Let me know!

Thank you for reading!

Personal, Projects, Scripting, System Center, Technology

Random Thoughts and Stuff

While packing for travel I was having a conversation around the “state of IT” with a friend. So I figured (A) it might be worth jotting down some of the key points, and (B) do it before I fly out, in case some underpaid mechanic forgets to tighten that one bolt that holds the engine onto the wing.  Actually, who am I kidding, that mechanic probably earns more than I do.  Anyhow…

this is rambling, so drink plenty of medication and smoke your wine before continuing.

(travel-packing sidenote: Oreo is 15 years old, and like most humans, used to hate my guts.  Eventually, as daughter number 3 moved out, and I became her sole source of attention and food, she has become my friend.  She follows me around all day.  Every time she sees my suitcase out the night before I travel, she does this.  I’ll need to go over that ball cap with a ball of tape in the morning.)

The Future of SCCM and MDT and EMS

This is admittedly a Microsoft-centric topic. The discussion mentioned above was about “how long” will SCCM and MDT be “of interest” to consumers?  Obviously, I do not own a real crystal ball.  I only have a Dollar Tree knock-off, and I don’t have access to real business data, therefore I rely upon what scientists often refer to as ‘shit talking‘.

I’ll admit, after day 1 at MS Ignite this year, I was feeling the angst.  For example, while riding the bus back from the conference center to the hotel, staring out the window, I kept thinking “why, why, why did I leave app-dev to move into this infrastructure rat race?!  wtf was I thinking?!” and “I hope my dog isn’t chewing up my last pair of flip flops right now.”  It really felt like the job market for anyone walking around a typical IT shop today, would be dried up to around 10% of that volume within 5 years.  And who really knows?  It could go in any direction.  I think everyone is in agreement that there is already a major tectonic shift in play, with traditional operations moving into software-defined operations.  The thought of learning things like JSON, Git, VSTS, on top of PowerShell and Azure, is adding wrinkles to quite a few faces I see.

The mere mention of “new certs” is probably having a measurable effect on the sales of alcohol, tobacco and firearms, which should keep these guys employed for a long time.  For many I’ve known over the years, the feeling is like being shoved onto a rollercoaster by your drunk buddies, against your will, and now you’re approaching the top of the first peak in the run.

After 3 more days, and soaking up session content, food, beer, and more importantly: engaging vendors in deep discussions out on the expo floor, my initial expectations of SCCM/MDT doom were relaxed quite a bit.  Mainly out of realizing the following points:

  • The majority of imaging work I see being done at most mid-sized and large customers is refresh of existing hardware.  The mix of new vs. reuse is cyclical at most larger shops, due to budget cycles and SLA’s about hardware refresh programs.  So at various times in a given year, there’s more new imaging, but for the remainder of the year it seems to be more refresh/reuse.
  • Most of the (above) people I’ve spoken with are very interested in AutoPilot, but quite a few hadn’t yet been allowed access to the preview at the time I spoke with them (I think most are now seeing it in their portals)
  • In-place upgrades are still a minority (far too low in my opinion)
  • The description of “automatic redeployment” got their attention, but most are still tied to the comfort of a “clean wipe and load” for various reasons.
  • Ultimately: Regardless of what anyone says, things which “work” have a very VERY tough time dying in the IT world.  Hence why so many machines still run XP.  I’d also wager my tombstone that Windows 7 will easy to find running on machines in 2027.  That’s because I’m planning to be cremated on a Walmart grill.  But that’s beside the point.

The weeks after Ignite I’ve made it a point to casually interview my customers to get a feel for where they see the biggest and most immediate changes coming.  It’s a delicate thing to ask, since it can easily smell like a sales pitch.  Sales pitches have a distinct odor that is often confused with bus station toilets or dead cows laying in the sun.  However, most of them are well aware of my dislike for sales people in general (some of my friends are in sales, so there are exceptions).

  • The biggest hurdles they have today are keeping up with device models and drivers, patching, moving to some new system for IT operations (ticketing, change mgt, etc.), and endless training of each new-hire who is replacing three who just left.  See what I did there?
  • The single biggest complaint about imaging in general revolves around drivers.
  • There’s still quite a bit of frustration and confusion I hear around Intune capabilities.  Some is related to Intune agent vs. agentless, management; Some is around app deployment capabilities; Some is inventory reporting.

Windows 10

I still spend way too much time explaining Windows 10 servicing models and the naming convention.  They were just starting to grasp CB, and CBB, but now “Semi-Annual” and “Semi-Annual Targeted” are leaving them in one of two modes: pissed off or chuckling.  The most common response I hear from the former is around the constant renaming of things in general.  “Active, Live, Visual, and now CBB, then Semi Annual Targeted, WUS, then WSUS”, and so on.  Their words, not mine.

I’m always surprised to find so many shops still heavily invested in MDT and doing very well with it.  The other interesting thing is that the majority of them assume they’re doing everything wrong and are panicked when I arrive that I’ll redline their papers.  In fact, most of them are doing very well.  They’ve read the blogs, the tweets, bought the books, watched the videos, done the TechNet labs, and so on.  A few have been lucky enough to attend training and/or conferences as well, but that’s a very small percentage.

The pace at which organizations are getting their Windows 10 rollouts moving is gaining speed and volume.  However, the Office aspect has thrown a wrench into quite a few (see below)


This reminded me of a discussion I had at Ignite with the Office team on the expo floor.  It was around the issue of third-party extensions (add-ons) for Office, and how many are produced by small shops which do not stay current with Office versions.  The result I’ve continued to see is a fair amount of shops who can’t upgrade Office until the third-party vendor puts out an update or a new version.  Then there’s the cost factor (is it free or not?).  In many of those cases, the hold-up triggered the IT department to wait on other projects such as Windows 10.

The number of Access applications interfering with Office upgrades has dropped significantly for me in the past 3 years.  Not just the projects I’m working on, but also from reports I get from other engineers and customers.  That’s a good thing.

Controls vs. Controls

I’m still seeing a continued reliance on inefficient control mechanisms with regards to device and user configuration management.  Way too much effort put into the imaging side, and not enough on the environment side.  Way too much on the “nice to have” side, vs. the “gotta have” side.  Not enough attention is being paid to ‘baseline’ and ‘continuous’ control models, and when to use which one, and how best to apply tools for each.  For example, hours and hours spent on wallpaper, shortcuts, and folders in the imaging process, being manually adjusted with each update cycle, rather than letting Group Policy Preferences step in and mop that shit up with one hand.

I’ve had fairly good results convincing customers to drop the continuous meddling with reference images, instead, (at least trying to)…

  • Change the data storage process to keep users from storing anything valuable on their device
  • Remove as many non-critical configuration controls as possible
  • Move continuous controls to the environment (GPO)
  • Move baseline controls to the environment wherever possible (GPP)
  • Move remaining baseline controls to task sequence steps

There are obviously exceptions that require mucking with the install.wim to make a new .wim, but I’m finding that’s only REALLY necessary in a small percentage of the time.  The vast majority of controls I see are voluntary and serve little functional or operational benefit.  Things like hiding Edge, Forcing IE, hiding Cortana, forcing Start Menu and Taskbar items, etc.  Just educate users to avoid them.  Treat them like adults and who knows, maybe they’ll stop urinating on your office chair.  Try it and see.  The worst you’ll get is whining (you get that anyway), but the best (and most likely) outcome is less work for you and less risk of something breaking.

Role and Salary Compression

It not only continues to thrive, it seems to be accelerating its pace.  Almost every customer I meet tells me how they’re expected to do more with fewer people, less training, less budget, and shorter time constraints.  Most haven’t had a significant raise in a long time.  This seems more prevalent at companies which are publicly-traded than those which are not, but it affects both.  Personally, I see a correlation with public organizations and cost reduction priorities over innovation and revenue increase.  Then again, I have no formal training in such matters, so again, I’m probably talking shit.  Again.


Speaking of Intune.  I’ve been spending more time with it this past week, along with Azure AD, and AzureADPreview powershell module.  I’ve always like the concept of what Intune and EMS are aimed at. The mechanics are still frustrating to me however.  There are plenty of design quirks that drive me batshit crazy.  Like devices / all devices vs. Azure AD devices, and the differences in how provisioning an app for iOS or Android and Windows, from the Windows Store no less.  As Ricky Bobby would say, “it’s mind-bottling”.

Then again, I’m not at all a fan of the “blade” UI paradigm.  The Blade model is (in my humble, semi-professional, almost coherent opinion) marginally efficient for direct touchscreen use, but for mouse and keyboard it blows chunks of post-Chipotle residuals.  I’m sure that will infuriate some of you.  But that’s just how I feel.  Drop-down menus, panels, heck, even ribbons, are more efficient in terms of hand and finger interaction (mouse, touchpad) for operations involving closely related tasks (settings, options, etc.)  Ask yourself if moving ConfigMgr to a blade UI would make it better?  Or Office?  If you think so, try switching to another brand of model glue.

Back to Intune.  I would really look forward to seeing it mature.  Especially in areas like agent vs. agentless device management (it’s very confusing right now, and the differences are weird), AutoPilot, Redeployment/Reset, and expanding the features for deploying applications, remote management (TeamViewer, etc.), and GPO-to-MDM migration.  I’m thinking Windows desktops and laptops of course (if you hadn’t already figured that out).  Phones are great, but nobody, who isn’t masochistic, is going to write a major app using their phone most of the time.  Auto-correct and latent-rich touch screen typing, would cause most PowerShell, C# or Ruby code writers to massage their head with a running chainsaw.

I think I digressed a bit.  sorry about that.

Other Stuff

I’ve spent some after-hours time keeping my brain occupied with scripting and app-dev projects.  I’ve been doing Windows 10, Windows Server 2016, MDT and SCCM lab builds and demos for months, along with real implementation projects, and starting to burn out on it all.  I needed a break, so I’ve managed to get a few things done and few in the pipeline:

I ran across a couple of (seem to be) abandoned Git projects focused on DSC for building ConfigMgr sites, but none of them appear to be factored into a template construct.  Meaning?  That they’re still built on specific parameters, or require extensive customization for various roles, configurations, environments.  I’m still poking at them and forked one to see what I can make it do.  In the meantime, I’m moving ahead with CM_BUILD and CM_SITECONFIG being merged into a new CMBuild PowerShell module.  So far so good.  And when that’s done, I’ll go back to see what I can in that regard with DSC and applying that towards Azure VM extensions.

I’ve come to realize that there’s 4 basic types of southern dialect in America:  Fast, Slow, Twangy and Crooked Jaw.  Think about it, and you’ll see that’s true.

The shortest distance between two points is often the most expensive.

If you never fail, you’re not trying hard enough.

If you fail most of the time, you’re probably in the wrong career path.

I’m on travel next week.  Expect more of the same stupid tweets about mundane stuff.  If you tire of me, unfollow me.  I don’t mind.  It’s just Twitter after all.  I will do my best to keep my camera ready for anything interesting.  I need to watch some air crash documentaries now, to get my mind relaxed for tomorrow.

Personal, Projects, Scripting, Technology


Pardon the headline and semi-questionable graphic, but it’s all I had to work with on short notice.

As a result of way too much caffeine, tempered with a sudden burst of alcohol and intense, yet clueless conversation with a colleague, the following hair-brained idea sprang up. This required immediate action, because, stupid ideas have to be enacted quickly in order to produce rapid failures and immediate lessons-learned…

Idea: What if you could manage remote, non-domain-joined, Windows 10 computers from a web page control mechanism, for “free”, where the local user has NO local admin rights, to do things like run scripts, deploy or remove applications, etc.?

What if? Aye?

So, Chocolatey came to mind. Partly because I was eating something with chocolate in it, but mostly because I love the Chocolatey PowerShell packaging paradigm potential, and that’s a heavy string of “P”‘s in one sentence.  Anyhow, it felt like one of those sudden Raspberry Pi project urges that I had to get out of my system, so I could move on to more important things, like figuring out what to eat.


  1. The machine would need to be configured at least once by someone with local admin rights.
  2. The machine would need to be connected to the Internet in order to receive updated instructions
  3. The admin needs a little knowledge of technical things, like proper coffee consumption, shit-talking and locating clean restrooms

Outline of Stupid Idea

  1. Drop the FudgePack script into a folder on the device (e.g. C:\ProgramData\FudgePack, file is Invoke-FudgePack.ps1)
  2. Create a Scheduled Task to run under the local NT Authority\SYSTEM account
    1. Task should only run if a network connection is active
    2. Task should only run as often as you would need for immediacy
    3. User (device owner) should be able to invoke Task interactively if needed.
  3. Host the control data somewhere on the Internet where the script can access it

Procedure for Stupid Idea

  1. Here’s the FudgePack app control XML file.  Make a copy and edit to suit your needs.
  2. Here’s the FudgePack PowerShell script.  Douse it in gasoline and set on fire if you want.
  3. Here’s an example Scheduled Task job file to edit, import, point at, and laugh.

Setting up and Testing the Stupid Idea

  1. Copy the appcontrol.xml file somewhere accessible to the device you wish to test it on (local drive, UNC share on the network, web location like GitHub, etc.)
  2. Edit the appcontrol.xml file to suit your needs (devicename, list of Chocolatey packages, runtime date/time values, etc.)
  3. Invoke the script under the SYSTEM account context (you can use PsExec.exe or a Scheduled Task to do this)
  4. Once you get it working as desired, create a scheduled task to run as often as you like
  5. Send me a box filled with cash – ok, just kidding.  but seriously, if you want to, that’s ok too.

More Stupid Caveats

  1. It’s quite possible in this day and age, that someone else has done this, and likely done a better job of it than I have.  That’s okay too.  I searched around and didn’t find anything like this, but my search abilities could quite possibly suck.  So, if someone else has already posted an idea identical to this, I will gladly set this aside to try theirs.  After all, it’s about solving a problem, not wasting a sunny, beautiful Saturday behind a keyboard.


Scripting, Technology

Random Notes from This Week

Warning: Skattered thoughts ensue.

Checking Memory

Calculating total system memory within a virtual machine session might seem like a rather mundane task.  But during a recent troubleshooting call with a customer, I ran across something I had forgotten: Physical machine properties are stored in WMI differently depending upon the context.  Note that running these on an actual physical machine, a virtual machine with static memory allocation, and a virtual machine with dynamic memory allocation, will often yield different results.

Win32_ComputerSystem (TotalPhysicalMemory)

[math]::Round(((Get-WmiObject -Class Win32_ComputerSystem | 
  Select-Object -ExpandProperty TotalPhysicalMemory) | 
    Measure-Object -Sum).Sum/1GB,0)

This returned 4 (GB) from 4,319,100,928

Win32_PhysicalMemory (Capacity)

Using Win32_PhysicalMemory / Capacity returns a different result.

[math]::Round(((Get-WmiObject -Class Win32_PhysicalMemory | 
  Select-Object -ExpandProperty Capacity) | 
    Measure-Object -Sum).Sum/1GB,0)

This returned 16 (GB) from the sum of 17,179,869,184 (13,019,119,616 + 4,160,749,568).


PowerShell, CSV and sparse Label Names

Some of the biggest headaches in IT, besides people, are caused by imposing human habits on technical processes.  For example, insisting on embedded spaces in LDAP names, CSV column headings and SQL table columns.  Just stop it!  Say no to spaces.  The only space we need is the one between our ears, and usually when driving.  However, we don’t always have the luxury of dictating “best practices”, instead, we have to adapt.  So, I had a colleague suffering with a CSV file that a customer provided with column names like “Last Name”, “Dept Number”, and so on.  Why they couldn’t use “LastName”, “LName”, or even “LN”, who knows, but it was “Last Name”.

$csvdata = Import-Csv "C:\Program Files (x86)\Microsoft Visual Studio 14.0\DesignTools\SampleData\en\SampleStrings.csv"
PS C:\> $csvdata[0]
Name : Aaberg, Jesper
Phone Number : (111) 555-0100
Email Address :
Website URL :
Address : 4567 Main St., Buffalo, NY 98052
Company Name : A. Datum Corporation
Date : November 5, 2003
Time : 8:20:14 AM
Price : $100
Colors : #FF8DD3C7

PS C:\> $csvdata[0]."Email Address" 

PS C:\> $csvdata | Where-Object {$_."Email Address" -like '*fabrikam*'} | 
  Select-Object -ExpandProperty "Email Address"

Thankfully, PowerShell is somewhat forgiving in this regard and allows you to adapt to such challenges easily.  A very small feature but very helpful as well.

Searching for Apps: Slow vs. Fast

Searching for installed software is usually pretty simple.  However, using WMI to query the class Win32_Product often becomes much slower due to overhead incurred by the Windows background refresh.  If you run a query for “SQL Server Management Studio” on a Windows server or client, regardless of the amount of memory, processor power, or disk performance, if these are all equal, WMI will be much slower than searching the registry or file system.  Case in point (using PowerShell for example purposes only):

Get-WmiObject -Class Win32_Product | 
  Where-Object {$_.Name -eq 'SQL Server Management Studio'}

When you run this, if you watch Task Manager at the same time, you may notice WmiPrvSE.exe and dwm.exe spin up more memory until the query is completed.  However, if you search the registry, which may not always be possible for every situation, the performance is typically much better (faster):

Get-ChildItem -Path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\ -Recurse | 
  Where-Object {$_.GetValue('DisplayName') -eq 'SQL Server Management Studio'}

Another option is to query the file system, which in this example is looking for a specific file and specific version:

$file = "C:\program files\Microsoft SQL Server\140\Tools\Binn\ManagementStudio\Microsoft.SqlServer.Configuration.SString.dll"
if (Test-Path $file) { 
  (Get-Item -Path $file).VersionInfo.FileVersion 

Running these three statements on my HP Elitebook 9470m with 16 GB memory and a Samsung 500 GB 850 EVO SSD the results end up with the following average execution times:

  • WMI: 20 seconds
  • Registry: 0.98 seconds
  • File System: 0.13 seconds

The point here isn’t that you should avoid WMI, or anything like that.  It’s just that we should always consider other options to insure we’re choosing the right approach for each situation.  For example, if you really need to invoke the .Uninstall() method, then your options may narrow somewhat.

For a handful of targeted queries it may not matter to you which of these (or others) makes the most sense.  But when querying 5,000, 10,000 or 100,000 machines across a WAN, without the aid of a dedicated inventory product, the choice may have a significant impact.