Signing ALL Power Shell Scripts within a Folder

Joel Bennett has a great post on automatically signing scripts. There is some good information there. However, I like to keep things simple. Joel’s post pretty much ties into his Authenticode Script Module. He ties all this together using the PowerShell Growl module.

Again, lots of good cool stuff, but I like to keep it plain and simple. I’m not a huge coder. I don’t have a large collection of PowerShell scripts that need to be signed. It doesn’t take all that long for me to sign all my scripts once in a while by running a single PowerShell script.

Here’s a script I’ve put together that automatically signs only the scripts at the root of my PowerShell scripts directory on my local computer. This script only signs scripts that are unsigned. The script can be easily modified to do all scripts using Get-ChildItem with a -recurse switch.

to test the script, just add the -whatif switch to the end of the line starting with Set-AuthenticodeSignature.

$ScriptsPath = "C:\scripts\POSH\*.ps1"
$Cert = @(Get-ChildItem cert:\CurrentUser\My -codesigning)[0]</pre>
ForEach($file in Get-ChildItem $ScriptsPath where-object {!($_.psiscontainer)}){
if (Get-AuthenticodeSignature $file Where-Object {$_.Status -ne "Valid" -and $_.StatusMessage -ne $invalidForm}) {
Set-AuthenticodeSignature $file $Cert

PowerShell with VMware – TEAC Firmware Issues

My company has been investing resources in moving toward VMware. It has been a very good learning experience and a huge eye-opener into the world of virtualization. We have been re-using existing systems and implementing them into a decent sized VMware farm.

Early on, we began experiencing periodic guest disconnect issues. 99% of our guests are all Windows operating systems. Since we are still early in the implementation of this project we have not implemented our preferred backup solution (VCB). So, we continue to back up many guests via NetBackup. We attributed the cause of the disconnect issues to backup jobs causing bottle necks.

Our internal customers would call and describe the symptom where their remote desktop sessions would timeout, then a few seconds later, reconnect. SQL queries would time out as well. Again, because this was early in our implementation of VMware, we assumed it was a limited issue and attributed it to conflicts with backups. Only a select few guests experienced this peculiar problem.

A good number of weeks went by and we had over 10 hosts up and running with guest vm’s. We continued to receive periodic complaints about one guest. But, we received no other complaints. Recently, we re-used some more of our existing hardware and implemented another host for our developer workstations. Even though our performance data with Veeam failed to show any week spots, we once again began to receive complaints of this mysterious disconnect issue. We quickly were able to determine that the complaints were about guest vm’s on the most recently implemented host.

Diagnosing the problem was quite a chore. After combing through the host logs using vCenter, we found a few things which, at first, we attributed to flaky firmware on the HP DL360 G5 or perhaps just flaky hardware.

However, one VMware Communities post was frequently returned on Google when using search strings pulled from our logs:;jsessionid=7260A1B75C79C9A64D75AD043B0E2C79

At first glance, our thought was, ”how in the world could CD/DVD Rom firmware cause disconnects?” It didn’t make sense. Additionally, the post was about Dell hardware; our hardware is HP. I was in the midst of trying to figure out some of the SCSI error codes I was seeing in the VMKernel log file. I then found the following article:

After discussing this article with our senior engineer, we thought we’d take a closer look and compare current host against the original host which was having disconnect issues with remote desktop. After reviewing the log files again, we found a line in the error log which raised our eyebrows.

Nov 5 15:37:06 sx4vm001 vmkernel: 0:08:11:01.657 cpu3:4196)WARNING: ScsiPath: 4969: Set retry timeout for failed TaskMgmt abort for CmdSN 0x0, status Failure, path vmhba1:C0:T0:L0

My senior engineer was the person who recently built that host and knew that since the data stores on this host are all iSCSI; hba1 was some other hardware. We looked closer in vCenter and voila. Hba1 was an HP TEAC DVD-ROM drive.

So, we look on the host where the original complains came from during the initial implementation to see if the same condition was true. Voila, hba1 was an HP TEAC DVD-ROM drive. So, we took a leap of faith and made the connection between the last article at the TEAC firmware issue.

As a test, we left two guests alone. On two other guests, we altered the CD/DVD media settings. We disconnected the guest media and changed the device type to client connected. All evening and into the next day, we had no additional complaints.

I then decided to do some quick PowerShell scripting. I already had been writing a script for another VMware task. (I will elaborate on that script in a future blog post).

The beauty of PowerShell is you can quickly make your code re-usable. All I had to do was make two small modifications to an existing script and I was able to change the properties of ALL of my guests in vCenter. I did a bit of housework on it and what appears below is the final script.

You’ll notice I’ve included a function in this small script. This is because it’s a common function from a function library I dot souce in my PowerShell profile.ps1.

So, this is the simple script I quickly through together:

function Test-VIMSnapin { 
if ((Get-PSSnapin -Name VMware.VimAutomation.Core -ErrorAction Stop) -eq $null){ 
Add-PSSnapin VMware.VimAutomation.Core 
$VCServer = Connect-VIServer ""</pre>
$VirtualMachines = Get-VM

foreach ($vm in $VirtualMachines) {
$vm | Get-CDDrive | Set-CDDrive -Connected:$false -NoMedia -Confirm:$false | Out-Null
start-sleep -milliseconds 500

# Disconnected from vCenter
Disconnect-VIServer $VCServer -Confirm:$False

Write-Host "ERROR: script execution was terminated.`n" $_.Exception.Message
Disconnect-VIServer $VCServer -Confirm:$False