PowerShell shortcut properties

Assuming that your PowerShell installation is in the default location, you need to append the path to your script in the shortcut path like so:

%windir%\System32\WindowsPowerShell\v1.0\powershell.exe C:\Scripts\MyUsefulScript.ps1

If you are wanting to run a PowerCLI (VI Toolkit) script, you also need to add the following line:-

Add-PSSnapin VMware.VimAutomation.Core

…to your script, as the VMware Cmdlets are not loaded by default unless you run it from the VMware Toolkit Shortcut.

“The trust relationship between this workstation and the primary domain failed.”

The problem is detailed in this KB Article. What happens is that every 30 days (by default) the client initiates a computer password change on the domain controller. This computer password is used to authenticate the computer as the computer object in AD, and is distinct from the user’s password. When the non-persistent machine resets, the passwords go out of synchronization and domain authentication fails.

This can be fixed, as per Microsoft’s KB article, by disabling the client-initiated computer password changes; this can be done using Local or Group Policy, by script, or by directly editing the registry.

Using local, or group policy

Set the key shown below to Disabled

Using REGEDIT

Set the below value to 1

Using Windows shell script

 :: Set registry key to disable computer password expiry

REG ADD "HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters" /v DisablePasswordChange /t REG_DWORD /d 1 /f

If you’ve got access to the Domain Controller, you can also set a GPO so that Domain Controller: Refuse Machine Password Changes is Enabled. This is in Windows Settings à Securiy Settings à Local Policies à Security Options (the same location as the Domain Member: Disable Machine Account Password Changes).

Also, if you need to rejoin machines that have already fallen off the domain, you can miss the reboot after removing it from the domain, so:

1. Shut the machine down
2. Make the drives Persistent
3. Start the machine and log in
4. Remove the machine from the domain
5. Add the machine to the domain
6. Reboot
7. Shut-down and make Non-Peristent

Skipping the middle reboot saves a couple of minutes (which adds up if you have a lot to do). The above processes can also be scripted through the use of PowerCLI with Invoke-VMCommand and either NETDOM (for XP/Vista) or PowerShell for Windows 7.

At first, we manually changed these assignments using the Disk Management MMC before setting the drives to non-persistent. Lately, I’ve been using a DISKPART script, which speeds up the process, but still requires logging into each machine.

I saw Arnim van Lieshout’s post on Invoke-VMScript yesterday, and realised that this could be used to run the DISKPART script on multiple machines. In order to get the TXT file used by DISKPART onto the machine, I’m also using the Copy-VMGuestFile command found in PowerCLI 4.0 Update 1.

# Change drive letter assignment from D to Q

# Gets the specific VMs we're after as an object
$objVMs = Get-Folder "Sequencers" | Get-VM | Sort-Object Name

# Assign the command line required for DISKPART to a variable
$strScript = "IF EXIST D:\ DISKPART /S C:\DiskPart_Change_C_To_Q.txt"

# Loop through the VMs
ForEach ($objVM in $objVMs){
# Let the user know
Write-Host Copying file to $objVM
Copy-VMGuestFile -Source "C:\Tools\DiskPart_Change_C_To_Q.txt" -Destination "c:\" -LocalToGuest -VM $objVM -HostUser root -HostPassword password -GuestUser Administrator -GuestPassword password
Write-Host Changing disk partitions on $objVM
Invoke-VMScript $strScript -vm $objVM -HostUser root -HostPassword password -GuestUser Administrator -GuestPassword password -ScriptType "bat"
}</pre>
The TXT file contained the following:-
<pre>SELECT VOLUME 2
ASSIGN LETTER=Q

This requires root credentials for the host, and administrator rights on the target machine, but, as Arnim notes, will work in the absence of client network connectivity.

This is a bit of a hack,: leaving the TXT file behind on the C drive; using root credentials rather than an account with the least effective permissions; and having the script contain the credentials in plain-text. However, I’m enthusiastic about using this solution in a more structured way in future. I’m already thinking about using it to defragment and SDelete our thick-provisioned virtual machines before converting them to Thin provisioned disks.

To do this the machines need to be powered down. We had an imminent maintenance window, but it wouldn’t allow us the time to make this change manually (even if we wanted to), this necessitated some automation. Unfortunately I had no idea how to go about editing this setting using the PowerCLI, even after a little search through the VMware PowerCLI community.

This seemed like the perfect opportunity to try out Project Onyx.

Carter Shanklin’s video does a good job of explaining how to Onyx up and running, and it worked exactly as described (even on my Windows 7 machine).

1. Download the Onyx files and extract to a folder
2. Run the Onyx executable

1. Click the Connect button, and connect to your VirtualCenter server.
2. Once that’s launched, start vSphere client, but instead of connecting to your VirtualCenter server, connect to http://localhost:1545 (Carter actually says 1445 in the video, but you can see on screen that he’s using 1545). Use your normal credentials.
3. Ignore the warning about unencrypted traffic (as Carter explains, the unencrypted traffic is local-only, the network traffic is still encrypted)
4. Click the Start button on Onyx
5. In vSphere client make whatever changes it is that you’re wanting to record.
6. Click the Pause button on Onyx, and you’ll see in the window a script has been created.
7. Copy this into your favourite PowerShell editor, and modify until it’s suitable for your purposes.

The original capture from the Onyx Window

$spec = New-Object VMware.Vim.VirtualMachineConfigSpec
$spec.changeVersion = "2009-11-27T09:16:04.570821Z"
$spec.powerOpInfo = New-Object VMware.Vim.VirtualMachineDefaultPowerOpInfo
$spec.powerOpInfo.defaultPowerOffType = "soft"
$spec.powerOpInfo.defaultSuspendType = "hard"
$spec.powerOpInfo.defaultResetType = "soft"
$spec.powerOpInfo.standbyAction = "checkpoint"

$_this = Get-View -Id 'VirtualMachine-vm-1074'
$_this.ReconfigVM_Task($spec)

A second capture changing the setting back to isolate the exact line that makes the changes

$spec = New-Object VMware.Vim.VirtualMachineConfigSpec
$spec.changeVersion = "2009-11-27T09:16:33.872017Z"
$spec.powerOpInfo = New-Object VMware.Vim.VirtualMachineDefaultPowerOpInfo
$spec.powerOpInfo.defaultPowerOffType = "soft"
$spec.powerOpInfo.defaultSuspendType = "hard"
$spec.powerOpInfo.defaultResetType = "soft"
$spec.powerOpInfo.standbyAction = "powerOnSuspend"

$_this = Get-View -Id 'VirtualMachine-vm-1074'
$_this.ReconfigVM_Task($spec)

And a finished script, which will run it against all machines in a specified blue folder comment/uncomment one of the $specVM.powerOpInfo.standbyAction lines to choose which option you want.

$objVMs = Get-Folder "Folder Name" | Get-VM
ForEach ($objVM in $objVMs){
	$specVM = New-Object VMware.Vim.VirtualMachineConfigSpec
	$specVM.powerOpInfo = New-Object VMware.Vim.VirtualMachineDefaultPowerOpInfo
	$specVM.powerOpInfo.standbyAction = "checkpoint" 			# Put the guest OS into StandBy Mode and leave the Virtual Machine powered On
	#$specVM.powerOpInfo.standbyAction = "powerOnSuspend" 		# Suspend the Virtual Machine
	$viewVM = Get-View -Id $objVM.Id
	$viewVM.ReconfigVM_Task($specVM)
}

I was actually surprised at how easy this was; and I think it’s going to make me a bit more adventurous with what I attempt to do via the PowerCLI.

The following enhancements have been made to ESX (from the release notes):-

VMware View 4.0 support – This release adds support for VMware View 4.0, a solution built specifically for delivering desktops as a managed service from the protocol to the platform.

Windows 7 and Windows 2008 R2 support –This release adds support for 32-bit and 64-bit versions of Windows 7 as well as 64-bit Windows 2008 R2 as guest OS platforms. In addition, the vSphere Client is now supported and can be installed on a Windows 7 platform. For a complete list of supported guest operating systems with this release, see the VMware Compatibility Guide.

Enhanced Clustering Support for Microsoft Windows – Microsoft Cluster Server (MSCS) for Windows 2000 and 2003 and Windows Server 2008 Failover Clustering is now supported on an VMware High Availability (HA) and Dynamic Resource Scheduler (DRS) cluster in a limited configuration. HA and DRS functionality can be effectively disabled for individual MSCS virtual machines as opposed to disabling HA and DRS on the entire ESX/ESXi host. Refer to the Setup for Failover Clustering and Microsoft Cluster Service guide for additional configuration guidelines.

Enhanced VMware Paravirtualized SCSI Support – Support for boot disk devices attached to a Paravirtualized SCSI ( PVSCSI) adapter has been added for Windows 2003 and 2008 guest operating systems. Floppy disk images are also available containing the driver for use during the Windows installation by selecting F6 to install additional drivers during setup. Floppy images can be found in the /vmimages/floppies/ folder.

Improved vNetwork Distributed Switch Performance – Several performance and usability issues have been resolved resulting in the following:

• Improved performance when making configuration changes to a vNetwork Distributed Switch (vDS) instance when the ESX/ESXi host is under a heavy load
• Improved performance when adding or removing an ESX/ESXi host to or from a vDS instance

Increase in vCPU per Core Limit – The limit on vCPUs per core has been increased from 20 to 25. This change raises the supported limit only. It does not include any additional performance optimizations. Raising the limit allows users more flexibility to configure systems based on specific workloads and to get the most advantage from increasingly faster processors. The achievable number of vCPUs per core depends on the workload and specifics of the hardware. For more information see the Performance Best Practices for VMware vSphere 4.0 guide.

Enablement of Intel Xeon Processor 3400 Series – Support for the Xeon processor 3400 series has been added. For a complete list of supported third party hardware and devices, see the VMware Compatibility Guide.

vCenter 4.0 has also been updated, and now has full compatibility with Windows 7 x86 and x64 versions. Saving the various hacks that were necessary to get it working.

Also, the PowerCLI has been updated, and can be found here. There are 68 new CMDLETS, which Alan Renouf does a great job of explaining. I’m especially looking forward to trying out Get\Set-CustomAttribute (no more manipulation of the View object), Move-VMTemplate (no more converting templates to machines), and Get\Set-VMQuestion (for those times when the datastores run out of space for the REDO files necessitated by Non-Persistent disks).

I’m looking forward to investigating the new PowerCLI functionality, and I’m also looking forward to not needing to  manually customise the dozen or so Windows 7 guests I’m deploying next week!

Downloading this at the moment, although I don’t suspect I’ll have time to look at it for a while.

Hugo Peeter’s has written a script to add VMX location as a Custom Attribute:

Add Vmx Path to VI Client using Powershell | PeetersOnline.nl.

[F]ind the offending snapshot, find the person who created it, get their email address from AD and send them an email reminding them of their mortal sin.

Our IndependentNonPersistent drives here prevent us from using snapshots, but I’m working on a “utilisation checking” script, that should help us cull some neglected machines and I might integrate some of Al’s AD interrogation into that.

Virtu-Al » PowerCLI: SnapReminder.

They seem to be picking the best scripts from the regular contributors to the forums, so it’s a good place to have a look for examples. They’re rated by users, and tend to be slightly better documented than the ones posted in the forums (which tend to be appended and amended as the thread progresses).

Definitely worth checking out.