A Hammer to Turn Screws

20161120_160743

Script: Check-Readiness.ps1

Purpose: Keeps me busy and away from drinking too much coffee.  Okay, seriously, it’s just another flavor of “check for Windows 10 upgrade readiness using PowerShell”. It can be used within SCCM or while standing naked in a WalMart, your choice.

<#
.DESCRIPTION
.PARAMETER SourcePath
Why didn't they use PARAMETRE, hmm? So American. Anyhow, SourcePath is wherever the Windows 10 media is located.
.PARAMETER OutputPath
If not "" then it will dump a file named <computer>-<result>.txt in that location.
.NOTES
I was only half awake when I wrote this. Use at your own risk.
#>
[CmdletBinding()]
param (
    [parameter(Mandatory=$True, HelpMessage="Path to setup.exe")]
    [ValidateNotNullOrEmpty()]
    [string] $SourcePath,
    [parameter(Mandatory=$False, HelpMessage="Path to dump output data")]
    [string] $OutputPath = ""
)
$setup = Join-Path -Path $SourcePath -ChildPath "setup.exe"
Write-Verbose "setup source is $setup"
if (!(Test-Path $setup)) {Write-Error "$setup not found"; break}
Write-Verbose "starting assessment"
$p = Start-Process -FilePath $setup -Wait -ArgumentList "/Auto Upgrade /Quiet /NoReboot /Compat ScanOnly" -PassThru
Write-Verbose "exit code: $($p.ExitCode)"
switch ($p.ExitCode) {
    -1047526896 { $result = "UpgradeReady"; break } 
    -1047526912 { $result = "SysReqtsFault"; break } 
    -1047526904 { $result = "CompatIssues"; break } 
    -1047526898 { $result = "InsuffDiskSpace"; break } 
    default { $result = "InvalidProductSku"; break }
}
if ($OutputPath -ne "") { 
    $filename = "$($env:COMPUTERNAME)-$result.txt"
    $filepath = Join-Path -Path $OutputPath -ChildPath $filename 
    $result | Out-File -FilePath $filepath -Append -NoClobber -Encoding Default
}
Write-Output $result

Shove it out as a Package, or make it a Script object you can spray all over helpless devices via Run Script.  Or run it directly (just add hot water and PSRemoting), or print it out, hang it on the wall, and laugh hysterically at it.  No matter what, it beats whatever your next staff meeting has to offer.

Cheers!

Advertisements

ConfigMgr Device Naming, Part 2: The Electric Boogaloo

 

1f3be4a21f5823b4516b458ba2f89a87--drink-coffee-coffee-cafe

So the previous blog post infuriated a few people, so I thought “I can do better than that. I can infuriate more people!” and came up with this:

I combined several PowerShell scripts, some oatmeal, hot water, chopped walnuts and a fresh cup of coffee into a single, mono-nuclear, monolithic uber-script that can be awoken (that’s a real word, I checked) from within a task sequence to rope the legs of the device, hold it down, and burn a new name on it.

You can view and laugh at it here.

Note: If you wish to ignore and infuriate people who strongly advise against using location names as part of device names, you will also want the associated “locations.txt” file to go with this steaming pile of electrons.  This is a poor man’s version of using an MDT CustomSettings.ini with DefaultGateway mappings, only poorer, and it hasn’t had anything to eat in a long, long time.

How to make this cat say “moo”…

  1. Drop the script files in a folder
    1. If you’re using location names, be sure to edit the locations.txt file to suit your environment.
  2. Create a new (or update an existing, your choice) Package in Configuration Manager.
  3. The Package contains source files, but has no Program entries, at least not for this script.
  4. Distribute that mess out into your unsuspecting environment.
  5. Add a task sequence step (Add > General > Run PowerShell Script)
    1. Insert somewhere above the “Apply Operating System” step
    2. Name: Set Computer Name
    3. Select the Package with the the script
    4. Script name: Set-ComputerName.ps1
    5. Parameters: (see notes)
    6. PowerShell execution policy: Bypass
  6. Click OK
  7. Deploy
  8. Run like hell

Figure 1 shows an example using the -Interactive parameter.  Figure 2 shows an example of using the fully-automatic, belt-fed, multi-rotational, liquid-cooled location-based naming option, which implies the -InfuriatesTheShitOutOfSomeAdmins parameter.

set-name1Figure 1 – Comes before Figure 2 🙂

set-name2Figure 2 – Comes right after Figure 1

Notes:

  • The -Interactive [switch] parameter ignores all other parameters except -DefaultName.  This parameter displays a really fancy, super-complex, highly-sophisticated dialog form for entering the computer name.  It looks like this…
    set-name3
  • -DefaultName is a [string] parameter which is set to “” by default.  If a value is assigned, it overrides everything like a car crashing through a drug store front window at 50 mph.
    Example: -DefaultName “DOUCHEBAG”
  • -UseLocation is a [switch] parameter which references the default IP gateway, at the time of imaging, to determine the location code to add to the device name.  If no matching gateway is found, you can force a default using the -DefaultLocation parameter.  You can also use multiple location.txt files (with different filenames of course) by using the -LocationFile parameter.  This might be useful when you have a CAS environment and want to segregate different sub-groups of IP gateways for some crazy, glue-sniffing reason. The locations.txt file uses a strict format which took decades to refine:  GATEWAYADDRESS=FULLNAME,SHORTNAME
    Example: -UseLocation -DefaultLocation “LON” -LocationFile “en-gb.txt”
    Example: -UseLocation -DefaultLocation “CLT”
  • -UseHyphens is a [switch] parameter that will concatenate the sub-atomic naming particles into a cohesive pile of dung using 100% organic gluten-free hyphen characters.
    Example: (without) “D1234”
    Example: (with) “D-1234”
  • -SnMaxLen controls the maximum length of the BIOS serial number values to allow when concatenating the final name value.  In most cases, a serial number won’t cause a problem, but within some virtual environments, the serial number can be almost as long as a fillibuster speech on Capitol Hill.  The default is 8 characters.  The truncation is from the left, so this fetches the right-most characters.
    Example: -SnMaxLen 10
  • -Testing is a [switch] parameter for running the script outside of a task sequence for testing and validation only.  If you don’t use -Testing and not running within a task sequence session, it will throw some ugly red errors at you because it can’t invoke the Microsoft.SMS.TSEnvironment interface.  Can be combined with any or all other parameters.
    Example: -Testing
  • If you wish to change the “form factor” codes (“D”, “L”, etc.) you will need to edit the {switch} block code within function Get-FormFactorCode. Between lines 170 and 185 or so.

So, for those of you that find this useful: glad I could help in some small way.  For those who are even more angry: Decaf is on sale at Trader Joe’s this week.  Stock up.

😀

ConfigMgr – 2 Minute Microwave Style

Genesis – I posted a tweet about someone I know getting stressed at learning Configuration Manager in order to manage 50 Windows devices.  All desktops.  The background is basically that his company had planned on 1000 devices running Windows.  But the end-users, who wield more purchasing power, opted to buy mostly Macbooks.  So the total Windows device count was capped at 50, BUT…. they already approved the purchase of ConfigMgr.  It’s worth noting that the end-users also purchases JAMF (formerly Casper) and set it up in their own secret underground lab, complete with a diabolical German scientist in a white lab coat.  Ok.  That last part isn’t really true, but the JAMF part is true.

So, the “discussion” slid into “okay mr. smarty-pants skatter-turd-brainz, what would you want in a ‘perfect’ ConfigMgr world to address such a scenario?” (again, I’m paraphrasing a bit here)

MC DJam, aka DJammer, aka David the Master ConfigMaster Meister of ConfigMgr, popped some thermal verbals in front of the house and the room went Helen Keller (that means quiet and dark, but please don’t be offended, just stay with me I promise this will make sense soon…)

Yes, I’ve had a few beers.  Full disclosure.  I had to switch to water and allow time for the electric shock paddles to bring my puny brain back online.  That was followed by a brief gasp,”oh shit?! what have I started now?”  Then some breathing exercises and knuckle crackings and now, back to the program…

So, Ryan Ephgrave (aka @EphingPosh) stepped in and dropped some mic bombs of his own.

And just like having kids, the whole thing got out ahead of me way too quick.

So, I agree with Ryan, who also added a few other suggestions like IIS logs, Chocolatey package deployments (dammit – I was hoping to beat him to that one).

So the main thing about this was that this person (no names) is entirely new to ConfigMgr.  Never seen it before, and only gets to spend a small portion of their daily/weekly time with it, due to concurrent job functions.  This is becoming more and more common everywhere I go, and I’ve blogged ad nauseum about it many times (e.g. “role compression”)

What do most small shop admins complain about?

  1. Inventory reporting
  2. Remote management tools
  3. Deploy applications
  4. Deploy updates
  5. Imaging
  6. Customizable / Extendable

These are the top (6) regardless of being ConfigMgr, LANdesk, Kace, Altiris, Solarwinds, or any other product.  All of them seem to handle most of the first 4 pretty well, with varying levels of learning and effort.  But Imaging is entirely more flexible and capable with ConfigMgr (or MDT) than any of the others I’ve seen (Acronis, Ghost, etc. etc. etc.)

ConfigMgr does an outstanding job of all 6 (even though I might bitch about number 6 in private sometimes, it is improving).  ConfigMgr is also old as dirt and battle-tested.  It scales to very large demands, and has a strong community base to back it up in all kinds of ways.  In some respects it reminds me of the years I spent with AutoCAD and Autodesk communities and the ecosystems that developed around that, but that’s another story for another time.

The challenge tends to come from just a few areas:

  1. Cost and Licensing – ConfigMgr is still aimed at medium-to-large scale customers.  The EA folks with Software Assurance, are most often interested and courted into buying it.  Some would disagree, but I set my beer mug down and calmly say “Walk into any major corporate IT office and ask who knows about ConfigMgr.  Then walk into a dentist office, car dealership, or small school system and ask that same question.”  I bet you get a different response.
  2. Complexity – ConfigMgr makes no bones about what it aims to do.  The product sprung from years of “Microsoft never lets me do what I want to manage my devices” (say that with a nasally whiny tone for optimum effect).  Microsoft responded “Here you go bitch.  A million miles of rope to hang yourself.  Enjoy!”  It’s an adjustable wrench filled with adjustable wrenches, because it was designed to be the go-to toolset for almost any environment.  And it’s still evolving today (faster than ever by the way)
  3. Administration – Anyone who’s worked with ConfigMgr knows it’s not really a “part-time” job.  But that’s okay.  It’s part of the “complexity” side-effect.  And rarely are two environments identical enough to make it cookie cutter.  That’s okay too.  Microsoft didn’t try to shoehorn us into “one way”, but said “here’s fifty ways, you choose“.  The more devices you manage with it, the more time and staff it often demands in order to do it justice.  I know plenty of environments that have scaled to the point of having dedicated staff for parts of it like App deployments, Patch Management, Imaging and even Reporting.

None of these are noted with the intention of being negative.  They are realities.  It’s like saying an NHRA dragster is loud and fast.  It’s supposed to be.

Now, add those three areas up and it makes that small office budget person lose control of their bowels and start munching bottles of Xanax.  So they start searching Google for “deploy apps to small office computers” or “patching small office computers cheap as hell” and things like that.

So, ConfigMgr already does the top 6 functions pretty darn well.  So what could be done to spin off a new sitcom version of this hit TV show for the younger generation?

  1. Simpler – It needs to be stupid-simple to install/deploy and manage.  This reaches into the UI as well.  Let’s face it, as much as I love the product, the console needs a makeover.  Simplify age-old cumbersome tasks like making queries and Collections, ADRs and so on.
  2. Lightweight – Less on-prem infrastructure requirements: DPs, MPs, SUPs, RPs, etc.  Move that into cloud roles if possible.
  3. Integrate/Refactor – Move anything which is mature (and I mean really mature) in Intune, out of ConfigMgr.  Get rid of Packages AND Applications, make a hybrid out of both.  Consider splitting some features off as premium add-ons or extensions, like Compliance Rules (or move that to Intune), OSD, Custom Reporting, Endpoint Protection, Metering, etc.
  4. Cheaper – Offer a per-node pricing model that scales down as well as up.  Users should be able to get onboard within the cost range of Office 365 models, or lower.

Basically, this sounds like Intune 3.0, which I’ve also blabbered about like some Kevin Kelly wanna-be futurist guy, but without the real ability to predict anything.

Some of the other responses on Twitter focused on ways to streamline the current “enterprise” realm, with things like automating many of the (currently) manual tasks involved with installation and initial configuration (SQL, AD, service accounts, IIS, WSUS, dependencies, etc. etc.), all of which are extremely valid points.  I’m still trying to focus on this “small shop” challenge though.

It’s really easy to stare at the ConfigMgr console and start extrapolating “what would the most basic features I could live with really come down to?” and end up picking the entire feature set in the end.  But pragmatically, it’s built to go 500 mph and slow down to push a baby stroller.  That’s a lot of range for a small shop to deal with, and they really shouldn’t.  That would be like complaining that the Gravedigger 4×4 monster truck makes for a terrible family vehicle, but it’s not supposed to be that.  And ConfigMgr really isn’t supposed to be the go-to solution for a group of 10-20 machines on a small budget.  Intune COULD be, but it’s still not there yet.  And even it is already wandering off the mud trail of simplicity.  It needs to be designed with a different mindset, but borrowing from the engine parts under the ConfigMgr hood.

Maybe, like how App-V was boiled down and strained into a bowl of Windows 10 component insertions for Office 365 enablement, and dayam that was a weird string of nouns and verbs, they could do something similar with a baked-in “device management client” in a future build of Windows 10.  Why not?  Why have to deploy anything?  They have the target product AND the management tool under the same umbrella (sort of, but I heard someone unnamed recently moved from the MDT world into the Windows 10 dev world, so I’m not that far off).

Does any of this make sense?  Let me know.

 

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)

ConfigMgr Script Deployments

Introduction

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.

Parameters

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.

Examples

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 = '\\CM01.contoso.com\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
GPUPDATE /FORCE
Write-Output 0

Modify Folder Permissions

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

Summary

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!

Discussion Points / FudgePop again

20160305_121835

So I had a nice discussion about this FudgePop thing, which is starting to sound like a marketing ploy.  But trust me, it’s only a project, nothing being marketed.  I’m not sure if I’ll add any more stuff to it unless I get really bored or some sort of revenue scheme hatches from it.  Again, that’s unlikely at this point.  As with CMWT, GPODoc, and CMBuild, these are just for fun and exercise.  I’m pretty sure some of you are tired of hearing about this thing with a childish name attached to it, and that’s fine. But keep in mind, the same could be said about the U.S. government, but I digress. 🙂

In case you can’t tell already, I’m slowly getting back to blogging after a brief hiatus.  I still don’t know where this is going to go, or for how long, etc.  One day at a time.

So, given that this is all open source and available on GitHub, here’s some thoughts for anyone feeling bored enough to fork or branch this for a future pull, or just to run off and get rich while I toil for table scraps, here’s some roadmap thoughts…

Mighta, Oughta, Woulda, Coulda, Shoulda…

Inventory

Inventory collection and reporting would be fairly simple to add.  I already built a proof-of-concept branch to collect data and upload it to a SQL database in Azure.  Anyone can do that.  What I would do differently is store a local copy of the payload with a checksum, maybe store the checksum and timestamp in the Registry, along with a timestamp of “LastInventoryUpload”.  Then subsequent inventory cycles would compare the new output checksum against that previous and only upload if the values are different.  Sound familiar?

Offline Mode

Rather than reading the control XML in real-time on each execution cycle, it could download the latest version to a local cache.  Then continue to enforce that on subsequent execution cycles if there are no available Internet connections.

Smaller Stuff

Other suggestions for possible consideration:

  • Download caching for either (or both) the Files and Win32 Apps control groups (fairly simple)
  • Manage local Group Policy for workgroup computers (ideas) (somewhat complex and limited, but promising)
  • Add, modify local user accounts (easy)

What it can do now

As of build 1.0.16, FudgePop can do the following on remote computers which are configured with the agent service:

  • Chocolatey Packages
    • Install, Update, Remove
  • Win32 Application Packages
    • Install, Uninstall
  •  Files
    • Copy, Move, Rename, Delete, Download
  • Folders
    • Create, Delete, Empty
  • Windows Services
    • Modify/Configure, Start, Stop, Restart
  • Registry
    • Create, Delete (keys, values)
  • Permissions (ACLs)
    • Files/Folders: Modify
    • Registry: Not implemented
  • PowerShell Modules
    • Install, Update
  • Shortcuts
    • Create, Delete
  • AppX Applications
    • Remove
  • Windows Update
    • Force Scan/Download/Installation
  • Inventory
    • Basic HTML reporting
  • Targeting
    • Device = comma-delimited list of device names (NetBIOS names)
    • Collection = arbitrary name which is then assigned a comma-delimited list of device names.
    • Enable = true/false (per setting or group, or per control file)
    • Central authority = deploy changes from central XML file, even redirect to new XML files without touching remote device by hand.
  • Ingredients
    • PowerShell and XML, and a sprinkle of cloud storage (to host control files)
  • Tools
    • Visual Studio Code, Notepad++, Paint.Net (for the spiffy icon)

The Future

Who knows.  I don’t even know what my 401-k is doing tomorrow.

Rants about Configuration Manager and PowerShell

Note: Although I’m still on hiatus, I was reminded about a few blog posts sitting in my drafts queue that need to get posted before they get stale like me.  There may be a few more.  Until then – cheers!

How many times have you seen PowerShell code that looks similar to the following?

param (
  [parameter(Mandatory = $True, HelpMessage = "Site Server Name", ValueFromPipeline = $True)]
  [ValidateNotNullOrEmpty()]
  [string] $ServerName, 
  [parameter(Mandatory = $True, HelpMessage = "Site Code")]
  [ValidateNotNullOrEmpty()]
  [string] $SiteCode
)
Import-Module "$($ENV:SMS_ADMIN_UI_PATH)\..\ConfigurationManager.psd1" -Verbose:$False

Notice how this is expecting the user to (manually) provide the name of the server, the site code, and so on?  What bothers me most about this is that these two pieces of information are easy to obtain directly from the local computer.  Even when running on a workstation or member server which is not a ConfigMgr site system, you can easily obtain the site server name and the site code.  So why ask a user to key this in manually?

I’ve blogged about this general topic a few times before, but I still see most snippets posted online today doing this exact same approach to setting up the most basic, albeit “core” aspects, on which the rest of the script depends.  Bad idea!  So 1990’s.

Think of this in alternate contextual forms:

  • We expect to drop AD computers and users into Organizational Units (OUs) to automate Group Policy management processes.
  • We expect to drop ConfigMgr resources into Collections to automate policy and content deployment processes.
  • We expect to place AD domain controllers into Sites to automate replication optimization processes.
  • We expect to place AD users into security groups to automate permissions inheritance processes.
  • So why don’t we expect our scripts to drop into execution environments and inherit and automate processes as well?

Reiterating one of the lectures from my CS days in college, “every program needs to start with stated assumptions“.  Other great bits of advice: “If it can be automated, then automate the shit out of it.”, and, “If you automate a broken process, you can only get an automated broken process.” (that was from a manager, not a professor, but still top of my list).  I could go on much longer, but maybe that would be best for an in-person discussion or speaking event.  God help you.

So, the questions should be:  what then are the expectations when executing a program (or script)?  I realize this is 100-level stuff right here, but so-often I see people dive into writing code before they pause to answer some basic questions about how it will be used.  The most basic questions should be…

Where will it be used?

When will it be used?

How will it be used?

and… Who, will use it?

Let’s define some base assumptions:

  • Where?  On the ConfigMgr site server (locally or via PSRemoting, WSMAN/Rexec/WinRS/PsExec, etc.)
  • When?  On demand, or via scheduled job
  • How?  PowerShell + ConfigMgr Admin Console framework
  • Who?  A user or process-owner account which has local Administrator rights

Assuming this is going to be invoked on a Central Administration Server (CAS) or Primary Site Server (PSS), we can also assume that the ConfigMgr admin console will be installed.  And along with that, it will have the PowerShell cmdlet library available as well.

In this scenario, we can easily obtain the name of the server, as well as the Configuration Manager site code.  There’s no need to ask a user to manually input this information, because, as we’ve seen many times, manual intervention causes cars to crash, trains to derail, and space shuttles to explode.  Humans are bad.

There are several ways to get the site server name (locally):

# environment
$ServerName = ($env:COMPUTERNAME+'.'+$env:USERDNSDOMAIN)

# WMI
$ServerName = Get-WmiObject -Class Win32_ComputerSystem | Foreach {$_.Name+'.'+$_.Domain}

# registry
$ServerName = (Get-Item -Path HKLM:SYSTEM\CurrentControlSet\Control\ComputerName\ComputerName).GetValue('ComputerName')

You get the idea.  The easiest (and fastest) may be the environment variable option.  So, we can also use this to set a default value even when using input parameters…

param (
  [parameter(Mandatory = $False, HelpMessage = "Site Server Name", ValueFromPipeline = $True)]
  [ValidateNotNullOrEmpty()]
  [string] $ServerName = $($env:COMPUTERNAME+'.'+$env:USERDNSDOMAIN)
)
Import-Module "$($ENV:SMS_ADMIN_UI_PATH)\..\ConfigurationManager.psd1" -Verbose:$False

We can also fetch the ConfigMgr Site Code using the Registry…

$SiteCode = (Get-Item -Path HKLM:\SOFTWARE\Microsoft\SMS\Identification).GetValue('Site Code')
$OldLoc = (Get-Location).Path
Set-Location "$($SiteCode):\" -Verbose:$False
...

So, that works fine when the assumption is that the script will be invoked directly on a ConfigMgr site server.

As a side note, there’s plenty of other useful information exposed in the Registry location HKLM:SOFTWARE\Microsoft\SMS

Going Remote

Now, let’s change the assumptions a bit.  Now the script will be invoked on a workstation, which is joined to the same AD domain as the ConfigMgr site.  Assuming the workstation is also a ConfigMgr client, and the desired Site Server is also the Management Point (MP) for this workstation, we can fetch the server name from the local machine as well, but it resides under the client Registry tree, rather than the site system Registry tree…

$mp = ((Get-Item -Path HKLM:SOFTWARE\Microsoft\CCMSetup).GetValue('LastValidMP') -split '//')[1]

Even if the MP is not the Primary we wish to connect to, we can use the MP information and perform additional queries against its Registry to “walk-up” the hierarchy to find the Primary we wish to connect with (if necessary).

Note: The actual value of “LastValidMP” is stored in URI format… example…

"http://cm01.contoso.com"

So if we split the string into a 2-element array on the instance of double slashes, we can then grab the index=1 value (2nd element), which is the FQDN of the MP.  You could also use .Substring() or .Replace() to manipulate the string in order to remove the http:// prefix.

$mp = (Get-Item -Path HKLM:SOFTWARE\Microsoft\CCMSetup).GetValue('LastValidMP')
$mp = $mp.Substring(7)
# or
$mp = $mp.Replace('http://', '') # or -replace 'http://', ''

So, now we have the ConfigMgr site server (again, assuming this is a small site and the MP is the primary), we can still fetch the site code either from the local client environment, or from the remote registry.  Either will work…

$SiteCode = (Get-Item -Path HKLM:SOFTWARE\Microsoft\CCM\CcmEval).GetValue('LastSiteCode')

You may be thinking (or saying aloud) right about now “so what? what can I do with this from a workstation?”  Well, if the ConfigMgr Admin console is installed, you have access to the same PowerShell module that is available on the site server.  So, if you intend to run your script locally on a workstation (or member server) which has the ConfigMgr Admin console installed, you can automate the site server name, and site code parts of your script very easily…

$mp = ((Get-Item -Path HKLM:SOFTWARE\Microsoft\CCMSetup).GetValue('LastValidMP') -split '//')[1]
$SiteCode = (Get-Item -Path HKLM:SOFTWARE\Microsoft\CCM\CcmEval).GetValue('LastSiteCode')
Import-Module "$($ENV:SMS_ADMIN_UI_PATH)\..\ConfigurationManager.psd1" -Verbose:$False
$OldLoc = (Get-Location).Path
Set-Location "$($SiteCode):\" -Verbose:$False

Keep in mind that no matter where you execute your script code, it will only be able to access resources which are allowed for the user context under which it is running.  So, if you run the script under your own domain account, and that account has limited rights in ConfigMgr, it’s going to be limited in what it can do against the site system environment as well.  I know many of you will shake your heads when reading this, but it is very often overlooked.

Speaking of the ConfigMgr Registry (SMS) tree

Beneath the HKLM:SOFTWARE\Microsoft\SMS registry tree, there are plenty of other useful pieces of information.

  • Server
  • Full Version
  • Domain
  • Parent Site Code (useful for Secondary sites and CAS environments)
  • Parent Server (ditto)
  • Site Name
  • Installation Directory
  • DatabaseMachineName
  • DatabaseName

So, even if your script needs to make some database connections to SQL Server (ADO, etc.) you can fetch the site database server and site database name, to automate the connection setup and continue onward.

Okay, so now what?  Well, there’s more.  Another thing I see way too-often is reinventing the wheel.  And not just any wheel, but octagonal wheels.  Here’s a few examples, and corresponding suggestions to avoid unnecessary work:

  • Writing elaborate ACL manipulation code, or invoking a blob of .NET reflection mess.
  • Writing elaborate code to manipulate local user permisions, like “logon as a service”
    • Use the Carbon PowerShell module – done (thank you Rob!)
  • Writing elaborate code to query or manipulate SQL Server settings
    • Use dbatools or SQLServer PowerShell modules
    • You can configure server memory and recovery model settings this way also (example)
  • Writing elaborate code to check if script is being executed via “run as administrator”
  • Manually writing help documentation
    • Enforce consistent commenting
    • Use PlatyPs to generate markdown files automatically (thank you Kevin!)
  • And finally…

Some final bits of advice:  NEVER test your scripts on a live Configuration Manager environment.  If you don’t have a test environment, build one, and test everything there BEFORE introducing into the production environment.  Also, when you are testing scripts against Configuration Manager and/or SQL Server, always keep the Task Manager window open and watch the Performance tab closely.

Summary

Am I some sort of “expert” when it comes to PowerShell or Configuration Manager?  Only when I’m around people who can’t spell “computer” and they’re serving alcohol.   I’ve just spent too many years soaking up what others have shared.  You are free to disregard everything I’ve said.  In fact, in America, it’s expected. But that’s okay too.