Are your names in sync? (Helpful Script of the Day)

Do you ever rename a server? Sure, in Windows that’s pretty easy. But having virtualized most of your servers, renaming brings along some new challenges.

When you first create a virtual machine, you enter a name for the machine. But that’s before you even started installing Windows on it. You might not even use the same names. Sure, the name in the VI Client is only a label and can easily be changed, even while the vm is running. So, no problems there? Look again. Have you ever tried browsing one of your datastores looking for the files that belong to some vm? Simple enough, as each vm gets its own folder, which is named after… the vm, obviously. But that folder is created when the vm is created. And when you rename the vm, guess what happens to the folder name: nothing.

Now, I don’t even want to begin to imagine the things that could go wrong when you’re browsing your datastores looking for those files, whether you are looking to copy them, remove them, … My advise would be to take a look at the vm settings, which lists the locations of the vmdk files ánd double-check the modified dates of the files you are touching to see whether they correspond to what you’d expect.

Although we should always keep checking and double-checking, it is still a good idea to try and keep your naming as consistent as possible. You never know whether somebody else will be checking as thoroughly as you are. And that’s where the Helpful Script of the Day comes in. This Powershell script, using the VI Toolkit, lists all your vm’s names, the windows host names (as reported back by the VMware Tools), plus the names of the folders and files this vm is using (for up to three disks). The output is sent to a csv file in a location you specify. I recommend opening it in Excel, which generates a nice tabular view and – if available in your version of Excel, using the feature Conditional Formatting to highlight duplicate values. All the values that are inconsistent should then stand out like a Dutchman in China.

Check-Names (Rename to .ps1)

 Any questions or remarks? Don’t hesitate to comment. I’ll be reading and trying to respond as soon as possible.

Enjoy!

Hugo

PS: I hit over 1000 visits this month, while the counter stuck at 130 just two months ago! I would like to thank you all for checking out my blog. Hope it’s proving useful to you.

»crosslinked«

Helpful scripts of the day: HTML Overview of VMs and Datastores

Today’s helpful scripts are ready to use scripts that generate an overview of your VM’s and your Datastores and save it to a HTML file. Great for reporting purposes. Easy to modify to meet your needs. Give them a try:

Get-DatastoreSizes (Rename to .ps1)

This one shows datastores with Used Space in GB, Free Space in GB and % Free Space.

Export-VMs (Rename to .ps1)

This one shows vm’s with OS Name, Total Disk Size in GB and Memory Size in GB.

Enjoy! 

Hugo

Helpful Function of the Day: Get-LocalAdmins

The following function uses the ADSI provider and some tricks to determine the members of the local Administrators group on any of your Windows Servers. Check it out:

function Get-LocalAdmins
{
param([string]$serverName)
 $ErrorActionPreference = “Stop”
 If ($serverName -eq “”)
 {
  Write-Host “Usage: Get-LocalAdmins “`
  -ForegroundColor yellow
 }
 Else
 {
 $Group = [ADSI]“WinNT://$serverName/Administrators”
 $Memberlist = @($Group.PSBase.Invoke(“Members”))
 $Members = $Memberlist |
  %{$_.GetType().InvokeMember(“Name”,’GetProperty’,$null,$_,$null)}
 Return $Members
 }
}

You use it simply by typing Get-LocalAdmins MYSERVER. Ain’t that neat?

Remote Registry with Powershell (PLUS: Create-ListBox function)

Until the powers of remoting arrive in Powershell v2, accessing a remote registry is a bit more cumbersome than a local registry. As you no doubt know, Powershell allows you to browse through the local registry as if it was a filesystem. The folling function should help you with accessing a remote registry:

function Enumerate-RemoteRegistryValues
{
 $ServerName = Read-Host “Server”
 $Hives = `
“ClassesRoot”,”CurrentConfig”,”CurrentUser”,`
“DynData”,”LocalMachine”,”PerformanceData”,”Users”
 $Hive = Create-ListBox -Items $Hives -Title “Select Registry Hive”`
 -Text “Select a remote registry hive to connect to:”
 $baseKeyName = Read-Host “Enter Key Name”
 $registry = [Microsoft.Win32.RegistryKey]::OpenRemoteBaseKey(`
[Microsoft.Win32.RegistryHive]::$Hive, $serverName)
 $baseKey = $registry.OpenSubKey($baseKeyName)
 $ValueNames = $baseKey.GetValueNames()
 $myCol = @()
 ForEach ($ValueName in $ValueNames)
 {
  $myObj = “” | Select Name, Value
  $myObj.Name = $ValueName
  $myObj.Value = $baseKey.GetValue($ValueName)
  $myCol += $myObj
 }
 return $myCol
}

Oh yeah!
One thing though. The real fanatics should have spotted it by now: The cmdlet Create-ListBox is not a native Powershell cmdlet. If fact, it is a function I created. It allows the user of the script to select a value from a collection of values using a sleek List Box. You should load this function before using the one above. Here’s how I did it: Continue reading

Gather NIC properties (including Speed and Duplex)

Gathering all sorts of server information with Powershell is rather easy, using the Get-WmiObject cmdlet.

In order to get NIC settings, the following little script returns a LOT of information:

$serverName = Read-Host “Enter server name”
$NicConfig = Get-WmiObject -Class Win32_NetworkAdapterConfiguration -ComputerName $serverName
$NicConfig | Format-List *

The one thing I was missing though, is the value of the NIC Speed and Duplex. So I started to dig into the registry and found a way to discover these values. Continue reading

To Disconnect(-VIServer) or not to Disconnect

With the release of VI Toolkit v1.0, the bèta-cmdlet Get-VIServer has been renamed to Connect-VIServer, which more accurately describes the action. The opposite action is now also available in the form of Disconnect-VIServer. Every script you start with Connect-VIServer should end with Disconnect-VIServer if you’d like to keep the amount of open sessions to your Virtual Center Server to a minimum. And you do if you like having any sort of performance from your VC Server.

Here’s three ways you can make sure you don’t end up with unnecessary sessions:

Continue reading

Virtual Center Server Settings revealed by Powershell (2)

VI Toolkit Product Manager Carter Shanklin pointed out in the VMware Communities that the script I posted yesterday can be significantly shortened. They have intrduced the shortcut:

Get-View ServiceInstance

So the script I posted yesterday can be reduced to:

$SI = Get-View ServiceInstance
$LicMan = Get-View $SI.Content.LicenseManager
$LicMan.Source.LicenseServer

Here’s another one for you to explore:

$OM = Get-View $SI.Content.Setting
$OM.Setting

…et voilà: SNMP and SMTP settings at your fingertips.

Enjoy!

Virtual Center Server Settings revealed by Powershell

I’ve got a powerfull snippet of code for you today! Sure, we’ve already had lot’s of fun using the VI Toolkit to find and manipulate all sort of settings. But do you know where to find the Virtual Center Server settings, which you access in the VI Client through the menu Administration -> VirtualCenter Management Server Configuration? You soon will!
Here’s an example that grabs the License Server setting for you:

$svcRef = new-object VMware.Vim.ManagedObjectReference
$svcRef.Type = “ServiceInstance”
$svcRef.Value = “ServiceInstance”
$serviceInstance = get-view $svcRef
$licRef = $serviceInstance.Content.LicenseManager
$LicMan = Get-View $licRef
$LicMan.Source.LicenseServer

Explore the $serviceInstance.Content property to get an idea for the other things you can access using this “trick”:

RootFolder
PropertyCollector
ViewManager
About
Setting
UserDirectory
SessionManager
AuthorizationManager
PerfManager
ScheduledTaskManager
AlarmManager
EventManager
TaskManager
ExtensionManager
CustomizationSpecManager
CustomFieldsManager
AccountManager
DiagnosticManager
LicenseManager
SearchIndex
FileManager
VirtualDiskManager
VirtualizationManager

Imagine all the possibilities! You can expect more useful scripts from me in the days to come, so stay tuned!

Powershell Oneliner #6

Today’s oneliner is an incredibly fast way to check the usage of your VMware datastores. You should first connect to Virtual Center in the following way:

$VC = Connect-VIServer “YourVCServerName”

Here comes the oneliner:

Get-Datastore | Sort-Object Name | %{Get-View $_.Id} | Format-Table @{Label=”Name”;Expression={$_.info.name}}, @{Label=”NumVMs”;Expression={$_.vm.length}}

Only interested in datastores that are not used? Use the Where-Object cmdlet:

Get-Datastore | Sort-Object Name | %{Get-View $_.Id} | Where {$_.vm.length -eq 0} | Format-Table @{Label=”Name”;Expression={$_.info.name}}, @{Label=”NumVMs”;Expression={$_.vm.length}}

But watch out! Consider a vm with a disk in datastore A and the vmx in datastore B. When you create a snapshot of the vm, the delta files of all disks will be stored with the vmx (in datastore B). The script (as does the VI Client) will show the vm to be not connected to datastore A!

Enjoy!