Inventorying vSphere VMs with custom attributes

I'm somewhat new to working with VMware's vSphere and have been teaching it to myself through Powershell.  Powershell has the advantage of being able to explore objects without having to worry about accidentally clicking on something that could take the environment down.  To stay as safe as possible, I started out with exploring the Get commands, the most obvious being Get-VM.  My first script was as basic as they get.

Get-VM 'myvm' | Format-List *

This gave me a basic list of properties that I could view.  Now I needed a way to store that information in a report.

Get-VM 'myvm' | Select Name,NumCPU,MemoryMB,UsedSpaceGB,Notes | Export-CSV C:\myVMs.csv

My new CSV was a good start, but there was other information that I wanted to capture.  I started digging into the objects nested deep in the VM and started creating my own properties.  The one-liner started to stretch a bit far, so I cleaned it up by breaking the lines at the pipes.

Get-VM 'myvm' | 
Add-Member -Name "GuestOS" -Value {$this.ExtensionData.Guest.GuestFullName} -MemberType ScriptProperty -Passthru -Force | 
Add-Member -Name "VMToolsVer" -Value {$this.extensiondata.config.tools.toolsversion} -MemberType ScriptProperty -Passthru -Force | 
Select Name,NumCPU,MemoryMB,UsedSpaceGB,GuestOS,IPv4Address,Notes |
Export-Csv C:\myVMs.csv

Now we're getting somewhere.  Almost any information that was built into the vSphere console and viewable was in my grasp.  While I was searching the internet for more things I could add, I came across a post from @LucD22 about custom attributes.  There were a few posts about creating and setting custom attributes, but no easy way to retrieve them that I could find.  So I set out to write my own.  This was my first attempt at gathering the information.

Get-VM 'myvm' | Select Name,@{l="Contact";e={$_.customfields | ?{$_.key -eq 'Contact'} | select -ExpandProperty value}}

The more I learn about Powershell, the more I become a stickler for standardization and I didn't like the look of that hash table when I added it into my previous script; it cluttered my Select-Object statement and made it harder to read which attributes I was pulling.  Once I cleaned up the script, I turned it into a function and it was ready for production.  Below is the final version of the script with help included.

Function Get-VMReport {
<#
.SYNOPSIS
Retrieves virtual machines from VMware vCenter
.DESCRIPTION
Retrieves virtual machines from VMware vCenter and returns summary information
.EXAMPLE
.\Get-VMReport.ps1
This returns all virtual machines from all default vCenters
.EXAMPLE
.\Get-VMReport.ps1 -vCenter vCenter01 -Credential $Credential
This returns all virtual machines from vCenter01 using the credentials stored in $Credentials
.LINK
http://blog.richprescott.com
#>

[CmdletBinding()]
    Param(
    [String[]]$vCenter = 'MyvCenter',
    
    [Parameter(Mandatory=$true,ParameterSetName="RunAs")]
    [Alias("PSCredential")]
    [System.Management.Automation.PSCredential]$Credential
    )

Connect-VIServer -Server $vCenter -Credential $Credential | Out-Null
Get-VM | 
    Add-Member -Name "vCenter" -Value {$vCenter} -MemberType ScriptProperty -Passthru -Force | 
    Add-Member -Name "IPv4Address" -Value {$this.ExtensionData.Guest.IPAddress} -MemberType ScriptProperty -Passthru -Force | 
    Add-Member -Name "GuestOS" -Value {$this.ExtensionData.Guest.GuestFullName} -MemberType ScriptProperty -Passthru -Force | 
    Add-Member -Name "Datastore" -Value {Get-Datastore -VM $this} -MemberType ScriptProperty -Passthru -Force | 
    Add-Member -Name "VMToolsVer" -Value {$this.extensiondata.config.tools.toolsversion} -MemberType ScriptProperty -Passthru -Force | 
    Add-Member -Name "Contact" -Value {$this.customfields | ?{$_.key -eq 'Contact'} | select -ExpandProperty value} -MemberType ScriptProperty -Passthru -Force | 
    Select vCenter,Name,Contact,PowerState,VMToolsVer,GuestOS,numCPU,MemoryMB,Datastore,UsedSpaceGB,ProvisionedSpaceGB,IPv4Address,Notes
Disconnect-VIServer -Server $vCenter -confirm:$False | Out-Null
}
Get-VMReport | Export-Csv C:\Reports\vCenter.csv -NoTypeInformation

Arposh Client System Administration Tool (ACSA)

[Update] Arposh Windows System Administration tool 2.0 has been released and replaces the Arposh Client System Administration tool.

Download link:  Arposh Client System Administration

When I was first starting out in the help desk of a large company, everything was done by sneakernet.  I wanted a way to do things remotely to be more efficient, but was met with resistance by management who thought it was not 'improving customer service' because it lessened face time with the customers.  I tried explaining to my supervisor that the reason we have customers (i.e. the company's employees) is because they need to get their work done and they just want their computers to work.  Another hurdle that stood in the way is the retraining of the help desk staff in resolving issues remotely.  To solve the second issue, I decided that I needed a tool that brought the majority of the standard help desk applications to one place and made it easier to troubleshoot and fix issues.  The first issue resolved itself after management saw how quickly tickets were being resolved and how impressed the users were with the help desk's remote 'magic'.

The Arposh Client System Administration tool (ACSA) started out as a way to retrieve information from machines remotely.  When a user would call, you enter in the name of the computer they are using and it shows you basic information about the machine.  As the tool grew, it went from being only able to gather system info, to gathering local group information, installed software, startup items, running processes and viewing log files.  Now that the tool provided a plethora of information, there became a need to act on the information that was being gathered.  This led to being able to modify local admin groups, uninstalling software, removing startup items and killing processes on remote machines.

Since then, ACSA has grown to what you see below:



ACSA Requirements:
- Powershell v2
- Quest ActiveDirectory Tools for Powershell (http://www.quest.com/powershell)
- PSExec.exe (http://technet.microsoft.com/en-us/sysinternals/bb897553)
Optional: Trace32.exe (For tailing log files)

Usage: Run the ArposhCSA.ps1 script and type in a partial computer name to search for it in Active Directory.  This brings up a second form with a list of computers that match the search criteria and the users that are logged into them.  If you already know the name of the computer you would like to manage remotely, you can type that directly into the text box on the main form. 

Features:
  • Connects to currently logged-in domain on startup
  • Search for PC - Search Active Directory for computers matching the string in the textbox
  • System Info - Gathers info about PC, user session, make/model, hardware, OS, networking and McAfee
  • Local Admins - Enumerates local administrators and allows you to remove them
  • Applications - Enumerates installed software and allows you to uninstall
  • Startup Items - Enumerates startup items and allows you to remove them
  • Processes - Enumerates running processes and allows you to kill them
  • Remote Desktop - Remote desktop into computer
  • Remote Assistance - Initiate remote assistance session with remote computer
  • View C Drive - Opens explorer to the C drive of remote computer
  • Restart Computer - Restarts remote computer (Includes confirmation)
  • File Menu
    • Connect to domain... - Connect to a different domain
    • Find User in AD - Enter user's name, search for it in AD and output to Grid View
    • Find User on PC - Enter computer name, see who is logged into it and then search for that user in AD
  • View Menu
    • View McAfee AntiVirus logs
    • View WSUS logs
    • View Event Viewer
    • View Services
    • View Local Users/Groups
  • Quick Fix
    • Group Policy Update - Run 'gpupdate /force'
    • Lock Computer - Lock the remote computer
    • McAfee DAT Update - Updates DATS
    • Reader Fix IE Plugin - Update Reader's exe path in registry to fix IE plugin
    • Rename Computer - Renames remote computer and reboots it
    • WSUS - Detect - Run 'wuauclt /detectnow'
    • WSUS - Report - Run 'wuauclt /reportnow'
    • WSUS - Reset Client ID - Fixes an issue where computers do not show up in WSUS

Download link:  Arposh Client System Administration

In later posts, I will go into detail about how some of the functions in this tool work. Stay tuned! 

Disclaimer: This was the first GUI I wrote and some of the older code is not written with coding best practices in mind (clarity of variables, spacing, etc).  Be gentle.  As always, never run a script without knowing and understanding what it is capable of.  Just because it works in my environment, does not mean it will work in yours. Test, test, test.  Since you read the disclaimer, I'll also let you know that there are a few easter eggs hidden in the code that give extra functionality.  Cheers!

    Update: MDT 2012 Beta 1

    I recently posted about the release of MDT 2012 Beta 1 and wasn't too impressed with it. I have to say that my feelings are starting to change with two new blog posts from Michael Niehaus.


    The cross-platform support means that instead of having to use two separate boot methods (x86 vs x64) to deploy your operating systems, you can now just use the x86 CD or USB and your x64 task sequences will be available.  Two items to note:

    • Booting to an x64 environment and deploying x86 is still not supported.
    • Booting to an x86 environment to deploy an x64 image means that you will need to upload setup files for both instances of that OS (e.g. Win 7 SP1 - 6.1.7601.17514) x86 and x64.

    Now on the the good stuff...UEFI support. We've all grown to know and love the BIOS and have used it since the dawn of time (or so it seems).  UEFI is about to change all of that.  The BIOS has certain limitations that UEFI has been designed to eliminate.

    • 16-bit code (where most OSes are now 32-bit or 64-bit)
    • 1MB of addressable memory (regardless of how much the computer actually has)
    • Slower option ROM initialization
    • 2.2TB boot disk limitation (an MBR limitation)

    UEFI has been deployed in many of the newer hardware models, but has been set to 'Legacy BIOS' mode for backwards compatibility.  MDT 2012 will allow you to take advantage of 'native' UEFI, which addresses the issues listed above.  The first two changes that most IT pros will notice are the removal of the 2.2TB boot disk limitation and the improved boot times.  As the UEFI standard matures, we should see an even larger improvement in boot times, especially when matched with SSDs.

    For more information of the UEFI standards, visit http://www.uefi.org/specs/esp_registry.

    Add code snippets to Powershell ISE

    I have been looking for a user-friendly way to add code snippets to Powershell ISE to reduce typos and time spent copy/pasting.  Borrowing a page from Jeffery Hicks' blog, I took it a step further and used multi-line comments to add large code snippets to the ISE for creating new scripts.  As an example, I often write scripts that take advantage of the Quest ActiveRoles AD Management snapin.  The code below allows me to use ALT + F5 as a hotkey to insert this code into the ISE quickly and easily.


     $QADTools = @'
      function Add-QADTools
      {
      $Quest = Get-PSSnapin Quest.ActiveRoles.ADManagement -ErrorAction silentlycontinue
      if ($Quest)
        {
           Write-Debug "Quest.ActiveRoles.ADManagement Snapin loaded"
        }
      if (!$Quest)
        {
           Write-Debug "Loading Quest.ActiveRoles.ADManagement Snapin"
           Add-PSSnapin Quest.ActiveRoles.ADManagement
           if (!$?) {"Need to install AD Snapin from http://www.quest.com/powershell";exit}
        }
      }
      Add-QADTools
      '@
    
      $psISE.CurrentPowerShellTab.AddOnsMenu.Submenus.Add("Insert QAD Tools", `
    {$psise.CurrentFile.Editor.InsertText($QADTools)},"ALT+F5") | out-Null
    


    To implement this into the ISE, you will need to modify/create your Powershell ISE profile.  To find your user profile, you will need to browse to C:\Users\%USERNAME%\Documents\WindowsPowerShell\Microsoft.PowerShellISE_profile.ps1 and paste the above code into the .ps1 file.  This code will also add a new menu item to the Powershell ISE named 'Add-ons' with a menu item named 'Insert QAD Tools' as shown below.