System center 1801 is here! 😀

18 months of support available for this release leading up to the LTSR version later this year, with 5 years of support.


Hyper-V – Don’t forget these simple administrative points! Part 1.


Thought i’d put together a quick guide of often forgotten/overlooked configuration items, which may seem to be benign, but can pop up at exactly the wrong time and bite you in the proverbial. Most of these config items I have seen over the years and still run in to them from time to time!

1. DO configure all your Hyper-V hosts as CORE

There is absolutely no good reason to install GUI/Desktop Experience. If you are still not sure on your powershell commands, then use ‘SCONFIG’ to get an initial IP address in, firewall rules open for remote management, join the domain.

As the old adage goes – practice makes perfect. None of us started out knowing powershell off the top of our heads, so roll up your sleeves and give it a try. Once you have used it for a while it’ll become second nature.

2. DO run AV on your Hyper-V hosts

The exclusions are well known – published on technet for all to use – HERE  There is nothing worse these days, than making it easy for malware to spread. Be mindful of lateral movement in your organisation – think of malware intrusion not as an ‘IF’ but as a ‘WHEN’. Plan ahead and don’t make things easy for them.

3. DO turn on local firewalls

Again, group policy makes it easy for domain machines to have common rule sets applied to them. Don’t open the gates, for the sake of a few mins configuration work

4. DO plan your Hyper-V deployment ahead of time

Bad configuration is often the cause of bad planning. Even if you are only deploying a few hosts in a small cluster, how you approach this should be exactly the same as if you were planning for 32 hosts. Draw up your design according to the requirements. Even if the requirements are on the slim side, document your process and decision making.

Try to think of scale, if the company grows, would it be easy to add another few hosts later on?

5. DO connect a pair of 1gb onboard NICs – for dedicated managament use

You’ve invested in 10GbE – you have a pair of NICs and you are going to use them. There’s usually 2 x 1gb NICs onboard, doing nothing. Configure them as your OS main management network. Don’t put a vSwitch on top, keep it simple and easy to reach. If you do encounter any vLAN/vSwitch/vAnything issues down the line – you’ll be glad you can still manage your server – without the need for clunky iLO/DRAC sessions.

6. DO check your cluster metrics!

It’s pretty smart, it’ll auto assign the networks, but it’s not infallable. Get powershell open and check them HERE. It might be an old article – but it is still relevant. Make sure your CSV traffic is going where you want it to go, in the event of a redirect – you dont want it going over the wrong network.


7. DO make the most of your Microsoft Licences!

So many people overlook system center, believing it to be a set of expensive management tools. If you have datacenter licensing, software assurance and the right CALs then you are set to use the full suite of products, plus some of the MDOP goodies that have been written for you.

I’m sure you are all familiar with the components now. Quite simply, Hyper-V without VMM is like toast without butter – dry and boring!

Take your time planning system center and the investment will pay dividends, alternatively, get a consultant in to do the leg work for you! 🙂 You can contact me on the site.

Part 2 here…




Configuring DPM Agents, Non-domain using Certificates

Hi All,

Lots of articles on this, Microsoft’s own documentation is far more detailed for 2012 R2 than it is for 2016. The concept remains the same.

My problems started as the cert authority (being comprised of an offline root CA and domain enterprise subordinate CA) forming the certificate chain, could not be contacted by agents on the other side of a firewall (without making swiss cheese of the firewall and allowing port 80 to the CRL distribution point, or standing up an alternative CRL location)

Follow the cert template setup guide here.

In the settings for the template, change the subject name handling to supply in the request. These certs are for non domain machines.


Make sure permissions to the template allow read & enroll. Then we can add the template to the CA for use and head for the MMC console + local computer cert snap-in on your DPM server.

Add the cert to your DPM server following the guide above, generate the BIN file, copy to the agent.

If your agent is behind a firewall, make sure to open the additional TCP 6076 port required for the certificate communication.

If your non-domain agent is unable to access the CRL distribution point (required for initial verification of the cert) then you will need to manually import the CRL files. Open explorer to your cert server \\yourcertserver\certenroll – here you will find your CRL files.

Import your CRL files (copied from the CA) using:

certutil -addstore CA “C:\CRLfolderpath\CRLfilename.CRL”

Remember to import the full chain of valid CRL files, once added in, run your DPM agent setup command – then you will have a BIN file with which to complete setup.


Bizarrely – Microsoft doesn’t support backup of machines in a “Perimiter Network” –

I’m not sure about anyone else, but I make extensive use of VLANs, which are subject to firewall rule sets and agents work fine in these scenarios. So why would a “perimiter network” be any different?

I suspect this is just noted as MS have not fully tested support of agents in this scenario, but I do not see any reason why it should not work.

However, follow best practice and remember that if backup of a system is essential, you are best sticking to the official supported guidelines 🙂

Deploying custom registry keys – to use with System Center

It can be useful to tattoo servers automatically on deployment with a custom reg – environment, service and component key set.


AssetName Environment Service Component

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.

#Set Variables
$ENV = $args[0]
$ENVVAL = $args[1]
$SERVAL = $args[2]
$COMVAL = $args[3]
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
# Import CSV file
$list = Import-Csv C:\temp\ServiceData\servicedata.csv
# Pipe variable contents and invoke script
$list | foreach-object{
$obj = $_
Invoke-Command -ComputerName $obj.AssetName -ScriptBlock $SCRIPT -ArgumentList $ENV,$obj.Environment,$obj.Service,$obj.Component
# End of Script

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:

 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, plus set scheduled maintenance mode in SCOM for these groups when they patch.

After all, you dont want to be dragged out of bed for a non-prod server going offline or a routine patch cycle.