Updating SCVMM DHCP Server Agent for Update Rollup 3 with Powershell

I’ve been to a couple of customers in the past month who has applied Update Rollup 3 for System Center 2012 R2 Virtual Machine Manager, through WSUS, but didn’t read the fine print.


So I wrote a quick script to locate all Hyper-V Hosts with the old/incorrect version.

And the next step was obviously, how to update the agent on all the Hyper-V hosts remotely and automatically!
There are a couple of different ways to do this, let me go through a couple of them.

One of the easiest ways is to use Sysinternals PSExec, just run psexec against those servers and execute uninstall of the old and installation of the new agent. In my humble opinion, it’s too much manual work to do it this way with a lot of hosts. So I rather use Powershell.

Looking at the above Powershell example, you almost have a full script for doing the rest.
Have a look at this;

Word of warning, the above script should be considered a “proof of concept” or give you a rough idea of how to do it. I’ve run it once, and it did work so it will hopefully work for you too.

There is a minor problem with the above solution. That script will do something called a “double hop”. It’s when you run something on Computer A, which gets executed on Computer B which in turn tries to connect to Computer C and use the credentials provided in A. Two hops, aka double hop.
In the above script, it’s when it’s accessing the install files from a remote share.
And to solve that problem you have to enable something you might have heard about, called Kerberos Constraint Delegation on all Hyper-V hosts (or other servers you want to double hop via).
In most environments KCD is not enabled, so the above script would not work to 100%. In fact, the uninstall would work, but not the installation so would will end up with a server that’s missing the DHCP Agent.
In case you ran the script without reading this part or before adding KCD, I added a small safeguard against that by doing a Test-Path before uninstalling the agent which probably told you it failed.

My good friend and college Mikael Nyström wrote a great blog post here recently on how to rather utilize CredSSP instead of using KCD for tasks like this.

And here is a slightly modified script using CredSSP instead of KCD.

Word of warning, the above script should be considered a “proof of concept” or give you a rough idea of how to do it. I’ve run it once, and it did break anything in that environment, so it might work for you too.

Basically, the script will enable CredSSP on the computer you run it on, and allow the credentials to be used on all remote servers that’s part of your domain. It will then connect to all Hyper-V hosts known by SCVMM and enable those as Credential Receivers.
Following that part, it will once again connect to those servers and check if the SCVMM DHCP Agent is outdated and if it’s able to connect to the install location (SCVMM Servers C$ Share).
I made sure it verifies that it can connect to the install location before uninstalling the Agent. Because in case it can’t connect to SCVMM Server, I would rather have an old DHCP Agent, than no agent at all.
And finally, it’s uninstalling the old agent and installing the new one.

It’s also possible to use SCVMM’s Job function to schedule a job to be executed on all Hosts. But I’ll cover that in some future post.

Script for importing existing VMs into Azure Pack

As you start working with Azure Pack, you probably realize that you have a lot of existing VM’s that you would like to import into Azure Pack, and by that be able to use them just as you can handle all new ones?

All that’s needed for that, is to set the correct AzurePack user as the owner and SelfServicUuser on that Virtual Machine. And of course, have the machine in the correct “Cloud”.

Here is a small script which will help you out by;

  1. Asking in a Grid View, which Cloud you would like to import a machine in.
  2. Ask which user that should be the new owner of this VM.
  3. Let you pick, which VM from the Cloud you would like to import.

As we have multiple clouds, and users can have multiple subscriptions, I chose to make the script use GridView, to minimize the risk for human errors (typos).


Azure Pack: change Web Sites Default Domain DNS Suffix

To change the Default URL (DNS Suffix) for your Web Sites in Windows Azure Pack, follow these simple steps;

On the computer that is hosting the Web Sites Controller, run the following Windows PowerShell command:

Update (2014-07-14): It looks like the command above does not support -DnsSuffix anymore, but one of my readers has posted an alternative solution in the comments;

As an alternative you can use the following approach:

Check the change by using

And you’ll after that also have to do this:
On your SQL Server, open Management Studio.
In the Hosting Database admin.WebSystems table, change the
PublishingDns, FtpDns, and Subdomain to your desired URLs.

Restart your AzurePack servers to make the changes apply everywhere.

SCVMM : Automatic Baseline update script

SCVMM (System Center: Virtual Machine Manager) 2012 and 2012R2 can manage the patch compliance on your servers. That’s a great feature but normally involves some manual work as you have to add each update to the Baselines manually.

My colleague Mikael Nyström (MVP)  made a script to handle this automatically, which I’ve developed a bit further.

The script has a few Pre-Requisites;

  • A WSUS Server defined in SCVMM
  • Approved patches for “Windows Server 2012” and “Windows Server 2012 R2” in WSUS
  • Pre-Defined Baselines (you can use Add-Baseline to create them) with these names;
    • Security Updates
    • Critical Updates
    • Updates
    • Update Rollups

That’s it! You can now run the script and automatically import all matching updates.

The following actions will be performed;

  • Synchronize updates with WSUS
  • Check if there are any updates in the Baseline already
    • If the baseline is empty, import ALL matching updates
    • If the baseline is NOT empty, check the Newest 500 updates and import all matching updates
  • Remove inactive updates
  • Repeat for all Baselines
  • Start a compliance scan

The script will not initiate any remediation. And as the script normally only checks the newest 500 updates, it has to be run fairly regular. In my environment, 500 updates is about 1 month of updates. Though to be safe, run it once a week.