December 14, 2024

Update VMware Windows Guest DNS and WINS through PowerCLI

I was really taken with Arnim van Lieshout’s post on running getting WMI from inside a guest through the PowerCLI, so I decided to play around a little bit with this.

The ability of the PowerCLI to use the Invoke-VMScript command is really a great addition to the set of tools the PowerCLI provides.

I typically only have Windows guests, minus a couple VMware appliances, so I decide to focus on how to leverage this functionality within Windows.  There are many articles out there on how to use netsh to update DNS and WINS settings.

A typical set of commands to update DNS and WINS look like this:

netsh interface ip set dns “Local Area Connection” static x.x.x.x
netsh interface ip add dns “Local Area Connection” x.x.x.y
netsh interface ip delete wins “Local Area Connection” x.x.x.a
netsh interface ip delete wins “Local Area Connection” x.x.x.b
netsh interface ip add wins “Local Area Connection” x.x.x.x
netsh interface ip add wins “Local Area Connection” x.x.x.y index=2

*** Where x.x.x.x is the new primary DNS/WINS, x.x.x.y is the new secondary DNS, x.x.x.a is the old primary WINS, and the old secondary WINS.

Not a difficult command, provided the guest’s network adapter is named the default of “Local Area Connection”.

Netsh can easily set a primary DNS and add a secondary DNS, which overwrites the current settings.  WINS on the other hand, can only have WINS addresses added or deleted.  So I chose to set the DNS, delete old WINS entries, and add new WINS entries.

My first attempt at creating this script looks like this:

$VIServer = Read-Host "Enter vCenter Server Name or IP: "
Connect-VIServer $VIServer

$HostCred = $Host.UI.PromptForCredential("Please enter credentials", "Enter ESX host credentials", "", "")
$GuestCred = $Host.UI.PromptForCredential("Please enter credentials", "Enter Guest credentials", "", "")
$PrimaryDNS = Read-Host "Primary DNS: "
$SecondaryDNS = Read-Host "Secondary DNS: "
$PrimaryOldWINS = Read-Host "Old Primary WINS: "
$SecondaryOldWINS = Read-Host "Old Secondary WINS: "
$PrimaryWINS = Read-Host "Primary WINS: "
$SecondaryWINS = Read-Host "Secondary WINS: "

get-vm |  %{ $_.Name; $_ | Invoke-VMScript -HostCredential $HostCred -GuestCredential $GuestCred -ScriptType "bat" -ScriptText "netsh interface ip set dns ""Local Area Connection"" static $PrimaryDNS" }
get-vm |  %{ $_.Name; $_ | Invoke-VMScript -HostCredential $HostCred -GuestCredential $GuestCred -ScriptType "bat" -ScriptText "netsh interface ip add dns ""Local Area Connection"" $SecondaryDNS" }
get-vm |  %{ $_.Name; $_ | Invoke-VMScript -HostCredential $HostCred -GuestCredential $GuestCred -ScriptType "bat" -ScriptText "netsh interface ip delete wins ""Local Area Connection"" $PrimaryOldWINS" }
get-vm |  %{ $_.Name; $_ | Invoke-VMScript -HostCredential $HostCred -GuestCredential $GuestCred -ScriptType "bat" -ScriptText "netsh interface ip delete wins ""Local Area Connection"" $SecondaryOldWINS" }
get-vm |  %{ $_.Name; $_ | Invoke-VMScript -HostCredential $HostCred -GuestCredential $GuestCred -ScriptType "bat" -ScriptText "netsh interface ip add wins ""Local Area Connection"" $PrimaryWINS" }
get-vm |  %{ $_.Name; $_ | Invoke-VMScript -HostCredential $HostCred -GuestCredential $GuestCred -ScriptType "bat" -ScriptText "netsh interface ip add wins ""Local Area Connection"" $SecondaryWINS index=2" }

It works, but it is a little ugly because it performs an action against a guest, then proceeds to the next, and so on.  When the first command is done, it loops through all the VM’s and performs the second command.  This isn’t really an efficient way of doing this.

So I pulled “&&” out of my old bag of DOS tricks to see if I could run multiple netsh commands simultaneous.

From inside a VM, I ran a combined netsh command, which looked something like this:

netsh interface ip set dns “Local Area Connection” static x.x.x.x && netsh interface ip add dns “Local Area Connection” x.x.x.y && netsh interface ip delete wins “Local Area Connection” x.x.x.a && netsh interface ip delete wins “Local Area Connection” x.x.x.b && netsh interface ip add wins “Local Area Connection” x.x.x.x && netsh interface ip add wins “Local Area Connection” x.x.x.y index=2

Success!

Now to incorporate this into my PowerCLI script.  Here’s what I came up with:

$VIServer = Read-Host "Enter vCenter Server Name or IP: "
Connect-VIServer $VIServer

$HostCred = $Host.UI.PromptForCredential("Please enter credentials", "Enter ESX host credentials", "", "")
$GuestCred = $Host.UI.PromptForCredential("Please enter credentials", "Enter Guest credentials", "", "")
$PrimaryDNS = Read-Host "Primary DNS: "
$SecondaryDNS = Read-Host "Secondary DNS: "
$PrimaryOldWINS = Read-Host "Old Primary WINS: "
$SecondaryOldWINS = Read-Host "Old Secondary WINS: "
$PrimaryWINS = Read-Host "Primary WINS: "
$SecondaryWINS = Read-Host "Secondary WINS: "

get-vm |  %{ $_.Name; $_ | Invoke-VMScript -HostCredential $HostCred -GuestCredential $GuestCred -ScriptType "bat" -ScriptText "netsh interface ip set dns ""Local Area Connection"" static $PrimaryDNS && netsh interface ip add dns ""Local Area Connection"" $SecondaryDNS && netsh interface ip delete wins ""Local Area Connection"" $PrimaryOldWINS && netsh interface ip delete wins ""Local Area Connection"" $SecondaryOldWins && netsh interface ip add wins ""Local Area Connection"" $PrimaryWINS && netsh interface ip add wins ""Local Area Connection"" $SecondaryWINS index=2" }

A much more efficient script, as it only initiates the netsh commands to the guest once per guest.  I can really use this on a project I will be implementing at some point in the future.

***Some things to note:

  • If there are any errors with WINS servers existing inside the guest (during the WINS removal piece), the DOS commands will bomb out.  This is just the nature of the beast when using DOS commands in this fashion.
  • This script assumes that the credentials for the Hosts is the same for all hosts.
  • This script assumes that the guest credentials are the same for all guests.
  • The guest has to be powered on with the VMware Tools running.

I have tested this on ESX 4.0 with Windows 2003 guests and have seen success.  Now off to test it against ESX 3.5 hosts and ESX 4.0 U1 hosts. I will also confirm that this does not work in Windows 2000 guests.  I have not tested this on Windows 2008/R2 guests.

Maybe I’ll put in some error checking into it, and possibly troubleshoot the Windows 2000 issue.

Hope it helps anyone out looking for a solution to this task.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.