Category Archives: System Center 2012 R2

Modern Style Visio Stencils for Operations Manager

I have created some more modern style Visio stencils for System Center. This time for Operations Manager!

You can download from here.

You can what they look like from here but download them, they’re free!

OpsMgr3

OpsMgr1

OpsMgr2

Advertisements

MDT and DaRT – Locking the Port Used for Remote Connections during OSD

The Microsoft Deployment Toolkit (MDT) brings a lot of functionality to operating system deployment (OSD) as I’m sure many of you are aware. One of the best features is the ability to incorporate the DaRT tools into the MDT boot WIM. This allows for deployment administrators to remotely connect to a device during OSD. This can be extremely useful in a situation where the device is not local to the admin.

Johan Arwidmark has a great post on how to integrate the tools into the MDT environment with ConfigMgr.

One of the issues with the default DaRT configuration is that the remote connections use a dynamic RPC port instead of a specific port during OSD. It is possible to lock down the port when using DaRT in its fully fledged mode however locking it down to a specific port during the OSD phase is not easy.

I’ve recently been working at a customer who have VERY strict firewall policies in place and would not allow dynamic RPC ports to be open from the ConfigMgr Primary Site Server VLAN to the client device VLAN. This led me to investigate how to lock the port used by DaRT during OSD for remote connections.

After trying several different options, including adding a customised DartConfig.dat file to the base Toolsx86.cab file, I was almost at the point of giving up, I didn’t.

Using the DaRT Recovery Image Wizard I created a DaRT image for Windows 8.1 Update and on the Remote Connection tab I enabled the option to Allow Remote Connections and specified a port to use, in this case 3389 as this was what the customer wanted to use:

AllowRemoteConnections

During the process I ticked the option to edit the image before the WIM was created:

EditImage

I then opened the location where the WIM contents were stored and navigated to the Windows\System32 folder to extract the customised DartConfig.dat file:

DartConfig

This file was then copied to a new folder where I’d created a folder structure Windows\System32:

CreateExtrasFolderStructure

I then finish the DaRT Recovery Image Wizard and started to create a new boot image in ConfigMgr using the “Create Boot Image using MDT” option. During the creation wizard I ticked the “Add extra files to the new boot image” option and pointed to the UNC path folder for the folder I had created above:

ExtrasFolder

This created the boot image and crucially overwrote the default DartConfig.dat file with the one I created earlier. This meant that for all Task Sequences using this boot image the customer would be able to connect to the device using the DaRT Remote Control option in MDT using port 3389 at all times.

OnPort3389

 

Scripting Shared Nothing Live Migration

UPDATE: 16th September 2016 – Link to download fixed.

I was working with a customer recently to replace their existing Windows Server 2012 Hyper-V clusters and System Center 2012 SP1 Virtual Machine Manager (VMM) installation with new Windows Server 2012 Hyper-V clusters and System Center 2012 R2 Virtual Machine Manager installation.

The customer was concerned about downtime for moving their Virtual Machines (VMs) from their existing clusters to the new ones.

We looked at the option of using Shared Nothing Live Migration (SNLM) to move VMs between the clusters which whilst an option wasn’t entirely realistic due to having in excess of 250 VMs and the names of the Logical Switches were different so each VM took some time to manually process, and being a manual repetitive task is prone to errors. The customer thought they’d have to go through migrating roles, moving CSVs and taking down VMs etc. Whilst that doesn’t sound too bad I wanted to offer a better option.

So looking at the options in PowerShell it was obvious that Move-VM was the cmdlet I wanted to use. Looking at the parameters I found -CompatibilityReport which “Specifies a compatibility report which includes any adjustments required for the move.” my first thought was where do I get one of those from?

After a bit of digging on the internet I discovered Compare-VM which creates a Microsoft.Virtualization.Powershell.CompatibilityReport.

The Compatibility Report fundamentally contains information on what would happen if, in this case, wanted to move a VM from one host to another.

So running:

Compare-VM <VMName> -DestinationHost <DestinationServer> -DestinationStoragePath <DestinationStoragePath> -IncludeStorage

gave me a Compatibility Report with some incompatibilities listed… Again after some digging I determined what these incompatibilities meant and how to resolve them.

I could then run a Compare-VM -CompatibilityReport <VMReport> which essentially says, “if I did this to the VM would it work now?” As long as you get no incompatibilities all is good!

Once that completed we could use the Move-VM –CompatibilityReport <VMReport> function to move a VM from one host to another…

Now whilst all these Compare-VMs are underway the source VM is quite happy existing and running as normal.

So where is this going? After discussions with the customer I expanded the PowerShell script to cope with multiple VMs, check for Pass Through Disks, remove VMs from clusters, etc.

The basics of the script are that it requires several parameters:

  • SourceCluster – where are the VMs to move?
  • DestinationServer – where do you want to move the VMs to? (optional, if this isn’t specified then a random member of the destination cluster is chosen for each VM to be moved)
  • DestinationCluster – what cluster do you want to move the VMs to?
  • SwitchToConnectTo – what is the name of the Virtual Switch to use on the destination server/cluster? For example if you VM/VMs are connected to a virutal switch called LogSwitch1 but your new cluster uses a virtual switch named LogicalSwitch1 you would specifiy LogicalSwitch1 for this parameter.
  • DestinationStoragePath – where do you want to put the VM’s storage on the destination cluster?
  • VMsToMove – this is a list of the VMs to be moved
  • LogPath – the path to a file you want to log the progress of the script to <optional>

Whilst this script may seem a little limited it managed to save the customer a great deal of time in migrating their VMs from their old Hyper-V clusters to their new ones. It can be extended to put in different Storage Paths for differenet VMs, different Virtual Switches etc.

Move-VMusingSNLM

Cisco UCS/FlexPod with Hyper-V 2012 R2

Over the past week or so I’ve had the pleasure of working on a green-field Hyper-V 2012 R2 installation on the Cisco UCS/FlexPod platform. This consists of:

  • Cisco UCS with B200-M3 Blades (24 of those)
  • Cisco Nexus 5500 switches (2 of)
  • NetApp FAS3250 (2 controllers)

Fundamentally it’s blade architecture but with added steroids.

The UCS platform makes applying service profiles to the blades very easy and most of all consistent. The biggest problem we had was temporarily disabling the multiple storage paths so when we doing bare metal deployment with Virtual Machine Manager 2012 R2 , WinPE would only see a single instance of each LUN.

Still that aside it worked very well an best of all we could use PowerShell to speak to the UCS to name the NICs in the Windows Server 2012 R2 Hyper-V host to match the names of the NICs in the service profile. No more having to figure out which one was which!

The main thing the platform is missing is consistent device naming (CDN), with that the deployments of the hosts would’ve been super quick. There’s a rumour that the CDN that would be presented would be the name of the NIC in the service profile that the host has, so for example if your service profile had a NIC called “HyperVMgmt” then that is what would be presented to WinPE during the deployment phase… That would certainly make things a lot easier!

It would be very useful if other manufacturers were to follow suit so you had the option to change the CDN that comes through from the hardware. Whilst in large deployments that may not make any sense but in a smaller environment where hosts are not deployed very often it could be very useful…

%d bloggers like this: