We tattoo servers automatically on deployment with a custom reg – environment, service and component key set.
Unfortunately we had a bunch of legacy servers out there, with a flakey app containing this information centrally.
Not only did we want this information into SCSM, but also available for SCOM and SCCM to use for different purposes. So, armed with a CSV of data (in the format above) I needed to get this applied quickly to a few hundred VMs.
The script above sets variables for the reg path, then a script – which will be passed to the server remotely using invoke-command.
This script sets variables based on the command arguments received in the loop at lines 20+21. The CSV data is formatted as the above example table, so the command connects to the computer (defined as AssetName), sends the script (variable $script) and appends the reg path, Environment, Service & Component data as Argument positions 0,1,2&3.
At the other end, it runs the script passed, which in the example CSV above, line 1 would be:
$ENV = HKLM:\SOFTWARE\MYCompanyName
$ENVVAL = PROD
$SERVAL = WEB APP
$COMVAL = WFE
New-ItemProperty -Path $ENV -Name Environment -PropertyType String -Value $ENVVAL -Force
New-ItemProperty -Path $ENV -Name Service -PropertyType String -Value $SERVal -Force
New-ItemProperty -Path $ENV -Name Component -PropertyType String -Value $COMVal -Force
It will proceed to loop round and apply each server in turn. Yes, it’s raw and there’s no error handling there, but you could easily put a TRY/CATCH in there to verify the server can be contacted, plus you can output the results to a file etc…
Now, you can build out dynamically adjusting patch groups in SCCM – based on Environment & Service, gather data into SCSM for services and customise SCOM monitoring & alerting based on Environment.
After all, you dont want to be dragged out of bed for a non-prod server going offline.