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.

Advertisements

My Favorite Ignite 2017 Sessions

Just a heads-up: Not all of the sessions I attended or enjoyed most are posted yet.  And some sessions might not have been recorded (expo area mostly).  Also, some of the videos have flaky audio.  Enjoy!

[ PLACEHOLDER FOR ASK THE EXPERTS: WINDOWS 10 DEPLOYMENT AND SERVICING SESSION ]

[ PLACEHOLDER FOR BRANCH CACHE SESSION (when it becomes available) ]

[ PLACEHOLDER FOR EXPERT LEVEL WINDOWS DEPLOYMENT SESSION (when it becomes available) ]

SCCM, SQL, DBATools, and Coffee

Warning:  This article is predicated on (A) basic reader familiarity with System Center Configuration Manager and the SQL Server aspects, and (B) nothing better to do with your time.

Caveat/Disclaimer:  As with most of my blog meanderings, I post from the hip.  I fully understand that it exposes my ignorance at times, and that can be painful at times, but adds another avenue for me to learn and grow.

marie-wilson-cooking

I don’t recall exactly when I was turned onto Ola Hallengren, or Steve Thompson, but it’s been a few years, at least.  The same could be said for Kent Agerlund, Johan Arwidmark, Mike Niehaus, and others.  None of whom I’ve yet to meet in person, but maybe some day.  However, that point in time is when my Stevie Wonder approach to SQL “optimization” went from poking at crocodiles with a pair of chopsticks, to saying “A-Ha!  THAT’s how it’s supposed to work!

As a small testament to this, while at Ignite 2016, I waited in line for the SQL Server guy at his booth, like an 8 year old girl at a Justin Bieber autograph signing, just to get a chance to ask a question about how to “automate SQL tasks like maintenance plans, and jobs, etc.”.  The guy looked downward in deep thought, then looked back at me and said “Have you heard of Ola Hallengren?”  I said “Yes!” and he replied, “he’s your best bet right now.

Quite a lot has changed.

For some background, I was working on a small project for a customer at that time focusing on automated build-out of an SCCM site using PowerShell and BoxStarter.  I had a cute little gist script that I could invoke from the PowerShell console on the intended target machine (virtual machine), and it would go to work:

  • Install Windows Server roles and features
  • Install ADK 10
  • Install MDT 2013
  • Install SQL Server 2014
  • Adjust SQL memory allocations (min/max)
  • Install WSUS server role and features
  • Install Configuration Manager
  • Install ConfigMgr Toolkit 2012 R2
  • and so on.

Since it was first posted, it went through about a dozen iterative “improvements” (translation: breaking it and fixing and improving and breaking and fixing, and repeat).

The very first iteration included the base build settings as well, such as naming the computer, assigning a static IPv4 address, DNS servers and gateway, join to an AD domain, etc.  But I decided to pull that part out into a separate gist script.

The main thing about this experiment that consumed the most time for me was:

  1. On-the-fly .INI construction for the SQL automated install
  2. On-the-fly .INI construction for the SCCM install
  3. On-the-fly SQL memory allocation configuration

Aside from the hard-coding of content sources (not included on this list), item 2 drove me nuts because I didn’t realize the “SA expiration” date property was required in the .INI file.  The amount of coffee I consumed in that 12 hour window would change my enamel coloring forever.  Chicks dig scars though, right?  Whatever.

Then came item 3.  I settled on the following chunk of code, which works…

$SQLMemMin = 8192
$SQLMemMax = 8192
...
write-output "info: configuring SQL server memory limits..."
write-output "info: minimum = $SQLMemMin"
write-output "info: maximum = $SQLMemMax"
try {
  [System.Reflection.Assembly]::LoadWithPartialName('Microsoft.VisualBasic') | Out-Null
  [System.Reflection.Assembly]::LoadWithPartialName('Microsoft.SqlServer.SMO') | out-null
  $SQLMemory = New-Object ('Microsoft.SqlServer.Management.Smo.Server') ("(local)")
  $SQLMemory.Configuration.MinServerMemory.ConfigValue = $SQLMemMin
  $SQLMemory.Configuration.MaxServerMemory.ConfigValue = $SQLMemMax
  $SQLMemory.Configuration.Alter()
  write-output "info: SQL memory limits have been configured."
}
catch {
  write-output "error: failed to modify SQL memory limits. Continuing..."
}

But there’s a few problems, or potential problems, with this approach…

  1. It’s ugly (to me anyway)
  2. The min and max values are static
  3. If you change this to use a calculated/derived value (reading WMI values) and use the 80% allocation rule, and the VM has dynamic memory, it goes sideways.

Example:

$mem = $(Get-WmiObject -Class Win32_ComputerSystem).TotalPhysicalMemory
$tmem = [math]::Round($mem/1024/1024,0)
...

I know that option 2 assumes a “bad practice” (dynamic memory), but it happens in the real world and I wanted to “cover all bases” with this lab experiment.  The problem that it causes is that the values returned from a WMI query can fluctuate along with the host memory allocation status, so the 80% value can be way off at times.

Regardless, forget all that blabber about static values and dynamic tragedy.  There’s a better way.  A MUCH better way.  Enter DBATools.  DBATools was the brainchild of Chrissy LeMaire, which is another name to add to any list that has Ola’s name on it. (side note: read Chrissy’s creds, pretty f-ing impressive). There are other routes to this as well, but I’ve found this one to be most user friendly for my needs. (Feel free to post better suggestions below, I welcome feedback!)

Install-Module dbatools
$sqlHost = "cm01.contoso.com"
$sqlmem = Test-DbaMaxMemory -SqlServer $sqlHost
if ($sqlmem.SqlMaxMB -gt $sqlmem.RecommendedMB) {
  Set-DbaMaxMemory -SqlServer $sqlHost -MaxMB $sqlmem.RecommendedMB
}

This is ONLY AN EXAMPLE, and contains an obvious flaw: I’m not injecting an explicit 80% derived value for the -MaxMB parameter.  However, this can be accomplished (assuming dynamic memory is not enabled) as follows…

Install-Module dbatools
$sqlHost = "cm01.contoso.com"
$sqlmem = Test-DbaMaxMemory -SqlServer $sqlHost
$totalMem = $sqlmem.TotalMB
$newMax = $totalMem * 0.8
if ($sqlmem.SqlMaxMB -ne $newMax) {
  Set-DbaMaxMemory -SqlServer $sqlHost -MaxMB $newMax
}

Here’s the code execution results from my lab…

sqlmemory2

You might have surmised that this was executed on a machine which has dynamic memory enabled, which is correct.  The Hyper-V guest VM configuration is questionable…

hyperv_setup1.png

This is one of the reasons I opted for static values in the original script.

Thoughts / Conclusions

Some possible workarounds for this mess would be trying to detect dynamic memory (from within the guest machine) which might be difficult, or insist on a declarative static memory assignment.

Another twist to all of this, and one reason I kind of shelved the whole experiment, was a conversation with other engineers regarding the use of other automation/sequencing tools like PowerShell DSC, Ansible, and Terraform.

The final takeaway of this is to try and revisit any projects/code which are still in use, to apply newer approaches when it makes sense.  If that means shorter code, improved security and performance, more capabilities, greater abstraction/generalization (for reuse), or whatever, it’s good to bring newer ideas to bear on older tools.  In this example, it was just replacing a big chunk of raw .NET reflection code with cleaner and more efficient PowerShell module code.  Backing out 10,000 feet, the entire gist could be replaced with something more efficient.

More Information

DBATools – twitterslackyoutubegithub

Ola Hallengren – web  (Ola doesn’t tweet much, yet)

My Twitter list of super awesometacular increditastical techno-uber genius folks – HERE

Back to my coffee.  I hope you enjoyed reading this!  Please post comments, thoughts, criticisms, stupid jokes, or winning lottery numbers below.  If nothing else, please rate this article using the stars above? – Thank you!

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!

6 Things to Avoid when Building an SCCM Site System

MFfn7

These are based on actual, real, true events, which I’ve been asked to help resolve in some capacity over the past three weeks:

  1. Do not let someone create your VM using an unknown template which contains leftover remnants of a previous SCCM site installation, and dozens of unknown changes for which the site admin has no knowledge what happened.
  2. Do not let someone create your VM and join it to an AD domain under an OU with a bunch of linked GPO’s which are undocumented.
  3. Do not let your boss approve another department’s request to take ownership of your SCCM SQL Server instance without prior discussion or them being advised as to what SCCM is.
  4. Do not let another engineer start building the site before you’ve provided him/her with the design document.  Especially when it includes Intune integration and they go ahead and set Intune as it’s own MDM authority, without discussing anything with you in advance.
  5. Do not recommend an SCCM site installation to a customer after a sales person insisted it was the “perfect fit” for their 10 desktop computers, when all they wanted was to manage software updates.
  6. Do not recommend to a customer that they’re fine with allowing their Primary site server VM, running on a Hyper-V failover cluster, to fail over another node, on another cluster, on another continent.

CMWT 2017.01.02.01 (interim)

Not a ZIP download yet.  Just raw files posted in the CMWT GitHub repo for now.

wonka2

Additions

  • Reports: Device Logins
  • Software: OS Images
  • Software: Automatic Deployments
  • Software: Deployment Summary: All and Brief (2 views)
  • Site: Windows Store for Business configurations

Bug Fixes

  • AD User / referenced a 404 link
  • Cleaned up function CMWT_AutoLink()

Thank you for the feedback!  Please keep it coming!

(the answer to the question is: because it works just fine)

SCCM Query: Devices by IP Gateway

stupid-people-188

While working on a project involving IP subnet reassignments and SCCM site boundaries, and factoring in the HW inventory scan cycles, with the nature of roaming vs. fixed device types, along with the phase of the moon, current stock market index, the daylight saving time offset, the menstrual cycles of our local male politicians, and my dog’s sleep patterns, I found this to be somewhat useful in tracking down stray devices.

SELECT DISTINCT [DefaultIPGateway0], COUNT(*) AS QTY
FROM [dbo].[v_GS_NETWORK_ADAPTER_CONFIGURATION]
WHERE [IPEnabled0]=1
GROUP BY DefaultIPGateway0
ORDER BY QTY DESC