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

Continued from Part 1 – here.

8. DO use SCCM/WSUS for patching

For heavens sake, DON’T have firewall rules in your environment allowing all servers to talk outbound to the internet. WHEN they infiltrate your environment, you’ll have given them an easy exit with your data.

Block all internet bound traffic from your servers and monitor the blocking. Allow only key services and send them all via a proxy – by exception! Get WSUS to collect the patches you need and distribute them internally in a safe and controlled manner.

9. DO use VLANS on your Hyper-V switches – Get VMM to do the donkey work

Networks & IP pools in VMM are a wonderful thing. Set a VLAN, Static MAC and Static IP’s – all handled on build automatically. Make the most of this feature to keep tabs on your infrastructure. There’s no need to go back and forth to your IPAM tools for VM deployments.

Removing native networks and DHCP prevents a poorly configured VM from gaining access to anything it shouldn’t be talking to.

10. DON’T Mix and match CPU/Memory types in a cluster

Whilst it’s entirely possible to do so, you’ll end up compromising on performance of your VM’s. Everything will require CPU compatibility mode enabled (VM shutdown required to enable).

You will also be adding complexity to cluster capacity issues. Draining a host with 1tb of ram across a selection of 256gb hosts will be possible (provided no single VMs exist with memory assigned greater than 256gb), but sustaining node failures will become a complex calculation, rather than being able to tell at a glance.

If you are purchasing new nodes to expand your environment, then group them together and create a new cluster. Utilise live storage migrations between clusters – or – if using SMB3 storage, just simply live migrate the VM between clusters.

11. SQL per CPU host licencing on Hyper-V – beware!

Example: You have a Hyper-V cluster with 10 nodes, 2 processors per node (20 processors total) and you decide you want to use 2 nodes for SQL enterprise licensing on a per host CPU basis (4 CPU licences),

In short, a VM that has a licence covered by a host could potentially exist on any of the 10 nodes in your cluster. It does not matter about the settings on the VM defining the host it will reside on, it could be powered on, on any of the ten hosts and as such it is likely you would be seen to have fallen short of the required licences.

You would be best off removing 3 nodes from your existing cluster and creating a separate Hyper-V cluster dedicated for the SQL workloads and licences. Two nodes of running VM’s with a single empty host (which allows for a node failure/maintenance). This clearly shows your used hosts and your hot standby for a failure.

If in doubt – contact a licencing specialist company and get it checked and double checked. You do not want a bill in the post for the 8 remaining nodes ūüôā

12. DO configure everything in PowerShell and DO retain it elsewhere

There’s many ways to automate the build of your hosts, SCVMM/SCCM or third party products, even LUN cloning (if boot from SAN). However, if you are manually building for any reason at all, then prepare the config and retain it afterwards. If the worst occurs, you can be back up and running in no time at all.

13. DO have a separate VLAN and address range for your host networks and DO keep them in step!

Make life easier for yourself. If you have 10 nodes, get 10 concurrent IP addresses from each of the ranges you may require (Management, Cluster-HB, Live Migration etc…) and make them the same last octet. Example:

Node1:

  • Mgmt: 10.0.1.11
  • ClusterHB: 172.10.0.11
  • Live Migration: 192.168.8.11

Node2:

  • Mgmt: 10.0.1.12
  • ClusterHB: 172.10.0.12
  • Live Migration: 192.168.8.12

And so on…. this will make your life easier in the long run. Keep these subnets away from any other use – so when you grow, you have more concurrent IP’s available.

If you ever need to revisit and reconfigure anything remotely via powershell, complexity will be reduced.

14. DO standardise your naming convention and use scripting/deployment tools!

As per the above points, name your network adaptors the same on every node – example:

  • MGMT-Team-NIC1,¬†MGMT-Team-NIC2 –> MGMT-Team
  • LM-Team-NIC1, LM-Team-NI2 –> LM-Team
  • SMB-NIC1, SMB-NIC2
  • iSCSI-NIC1, iSCSI-NIC2

etc…

Again, when using PowerShell to build/configure it is easy to maintain convention and will save you countless config headaches over time.

Advertisements

Deploy DPM Remote Management Console 2016 + UR2

Unlike all the other system center products, which can normally accept a straight forward setup.exe /install /client and install silently – DPM is different (no shock there then!)

After a long search for documentation on the available install switches, it lead me to a blog post by Steve Buchanan which is for the 2012 console install.

So, 2016 follows the same principle, but for some very bizarre reason – source media contains:

2012 Console,

2012 SP1 Console,

2012 R2 Console and….

2016 Console.

The only command line for install –¬†Setup.exe /i /cc /client – installs all 4 versions – FAIL.

So, the only way round as far as I can see is to live with it and then remove the unnecessary components after install, then apply UR2.

Follow Steve’s post to getting it into config manager (i’m not rewriting his post) – in the source directory, add your source media,¬†a copy of the UR2 console patch (you can extract the file and grab the MSP – it’s called:¬†DPMMANAGEMENTSHELL2016-KB3209593.MSP ) and finally¬†a batch file for install and reference that instead.

so – your file layout should look something like this:

install-folder

In your batch file:

start /wait cmd /c “Setup.exe /i /cc /client”

start /wait cmd /c “msiexec.exe /x {DFF93860-2113-4207-A7AC-3901ABCE8002} /passive”

start /wait cmd /c “msiexec.exe /x {FF6E79E3-66E5-4079-BE10-2B9CFBE3B458} /passive”

start /wait cmd /c “msiexec.exe /x {88E17747-6E2C-48A0-88CC-396AC8D9C5BB} /passive”

start /wait cmd /c “msiexec.exe /f {BF23ED54-5484-4AC1-8EA7-6ACAFBBA6A45} /qn”

start /wait cmd /c “msiexec.exe /update DPMMANAGEMENTSHELL2016-KB3209593.MSP /qb”

So, we are installing all consoles, then removing 3 of 4 versions. This for me caused the 2016 console icons to go awry – so a quick repair of the 2016 one before finally installing the UR2 MSP.

Dont forget to reference Visual C++ 2008 Redist x64 in your dependencies list in SCCM – otherwise it won’t install ūüôā

Enjoy!

 

DPM 2016 agent installations – Making your life easier with SCCM

Take the pain away from manual deployment – grab the agent and put it into SCCM. The command lines for agent install (2016 UR2) are:

DPMAgentInstaller_KB3209593_AMD64.exe /q /IAcceptEULA

DPMAgentInstaller_KB3209593.exe /q /IAcceptEULA (for x86)

Just make sure all the agent pre-reqs are in place (WMF 4.0 for 2008 R2 etc…) and make the detection of those a pre-req for the SCCM deployment.

If you know what DPM server you are going to protect with – simply add the server name to the install above – that will open the ports and make the agent ready to be attached.

If you dont just yet – then run a second SCCM task to call a batch file running the setdpmserver.exe (in the DPM agent Bin directory) to configure the agent.

Run an “Application deployment type compliance details” report in SCCM, using your target collections, application, deployment type and status of “Success” to generate a CSV file of the installed agents.

Take the computer name column in excel, append your domain name (using concatenate) and put the resulting list into a .txt file (no headings or any other info required)

Open the DPM console – select Install, Attach Agents, click add from file and point to your txt file.

Output from SCCM report, manipulate and import in ~10 mins saving many hours of manual config.

Job Done!