Maybe not.

There is another cmdlet called Get-NAVolSize. What is the difference between the results returned by the two comdlets? Get-NAVol will show you the total size without the snap reserve space. Get-NAVolSize returns the actual size of the volume, including the snap reserve. This isn’t well documented in the Get-Help for these cmdlets and took some experimentation for me to figure out.

Hopefully this helps anyone who is confused about finding different values in the two commands.

The script uses Get-NAVol to find the existing volume total size. It then calculates a auto-grow max size by multiplying the existing volume total size by 1.2, to give an auto-grow size of 20% greater, and storing that number in a variable. It then uses Set-NAVolAutosize to set the new size.

This sounds like it should work, but instead Set-NAVolAutosize throws errors:

Set-NaVolAutosize : Invalid size: 386547056640.0

Where did that decimal come from? Let’s take a look. First, let’s examine the volume total size returned by Get-NaVol.

$Volumes = Get-NAVol
$Volumes[0].totalsize

354334801920

$Volumess[0].totalsize | gm

TypeName: System.Decimal

$Volumes.totalsize * 1.2 | gm

TypeName: System.Decimal

Well, that shows where our decimal is coming from! What happens if we set a variable to the number reported as the total volume size (354334801920)?

$number = 354334801920
$number | gm

TypeName: System.Int64

Using set-navolautosize using the variable $number works. So, it would appear that the type System.Decimal is causing the problem. The solution? Explicitly cast the result of multiplying the total volume size by 1.2 as an Int64. The below assumes $volume is a variable holding a single object from Get-NAVol.

$NewAutoSize = [int64]($Volume.totalsize * 1.2)

This solved my problem.

In the next week or two I will publish the entire script to set new auto-grow sizes.

~Daniel

The first step is to collect what machines to audit. If you have the VMware tools installed and if all your VMs are Windows, it can be as easy as:

Connect-viserver <VCENTER>

$Servers = get-vm

The information we need is in the win32_diskpartition WMI namespace. The following collects the pertinent information for each server and puts the results in an array.

$Results = @()
$Errors = @()

foreach ($Server in $Servers) {   
    If (Test-Connection -computername $Server -quiet) {
        $DiskPartitions = get-wmiobject -query "Select systemname,blocksize,startingoffset,name,index from win32_diskpartition" -computername $server -ea SilentlyContinue
        if (!$?) {
            $errors += $Server
            Write-Host "Error: $Server — unable to bind to WMI." -foregroundcolor Red
        } Else {
            $Results += $DiskPartitions
        }
    } Else {
        $errors += $Server
        Write-Host "Error: $Server — unable to ping." -foregroundcolor Red
    }
}

First we initialize two arrays for results and errors. Then we enter a foreach loop. We use test-connection to make sure the server is pingable. If it is, we get our WMI information.

The if (!$?) is another error check. $? is a variable that is set true when the previous command executed successfully. If the previous command did not, it will be set false. “!” is an alias for not. So, essentially, we are checking to see if the last command failed. If it did, we write an error to the screen and add the server to our array of errors. If it succeeded, we add the WMI results to our results array.

The next step is to export our data. Generally, I find this to get the job done:

$Results | Select systemname,blocksize,startingoffset,name,index | export-csv “Results.csv” -notypeinformation
$errors | out-file "Failed.txt"

this will give you two files, one a csv of all the wmi information, the other a list of servers that we failed to collect information for.

Here are the links. Enjoy!

Use Asynchronous Event Handling in PowerShell

Manage Event Subscriptions with PowerShell

~DL

A quick and easy way to generate a report, just run the following from the root of the share:

get-childitem | where {$_.PsIsContainer} | %{get-childitem $_ -filter backup | where {$_.PsIsContainer}} | select fullname | out-file c:\Results.txt

So, what are we doing?

1. First, we use Get-ChildItem to give us all the items in the current directory. Note that gci, ls, and dir are aliases for Get-ChildItem and can be used interchangeably.
2. We then pass that to a Where-Object and filter for objects that are containers, which means directories. Note that we could have used the ? alias to further shorten the command.
3. We then pipe to a ForEach-Object loop. Within the loop, we do the following:
1. Use Get-ChildItem with the filter parameter to retrieve all objects named “backup”. So, we’ve taken each directory in the root of the share and are now get the contents of them, thereby going one level deep into the directory structure.
2. Use Where-Object to filter for only directories.
4. We use Select-Object to return the fullname property of all the returned objects. Fullname includes the path.
5. We then output to a text file with Out-File.

I’ve opted to do it all on the pipeline for several reasons. First and foremost, this is the sort of quick and dirty solution whose basic structure can be used to solve any number of problems on the fly. Second, if you have a large number of directories (or other objects if you modify this for something other than directory searches), it will be more memory efficient to pass each item down the pipeline as it becomes available than storing everything in variables in processing objects in bigger batches.

~Daniel

My coworker approached me looking for an easy way to see if there are any files in a given directory whose last modified time is older than a minute or two. Apparently, he has had some issues with voicemails being stuck in the queue and never being properly delivered.

I quickly threw this together and used it as an opportunity to discuss the difference between setting up a foreach loop and piping to foreach-object. It was also a good time to introduce the % and ? aliases, which are for foreach-object and where-object respectively.

As you may know, piping to foreach-object will send objects down the pipeline as they become available. Whereas as one would generally collect all the objects prior to entering a foreach loop. While this difference may not make an appreciable difference with a small number of objects, it can make a big difference in resource utilization with larger collections of objects.

Here’s the code:

$date = get-date

$path = “C:\temp”

get-childitem -path $path | ?{-not $_.psiscontainer} | %{If (($date – $_.LastWriteTime).totalminutes -gt 1) {DO SOMETHING}}

~Daniel

I’d recommend auditing your systems if you use mini-dumps as your default dump method. You can check the followig registry key to see its current location: HKLM\System\CurrentControlSet\Control\CrashControl\MinidumpDir

~D

One would then think it trivial to implement  a solution to leverage these cmdlets in the GroundWork monitoring environment. However, this has not been the case for my team.

The root of our problem is our desire to use the GDMA agent, which runs as a service on each monitored machine. The agent is currently 32 bit. Our Exchange 2007 environment is completely 64 bit, including all of the PoSH cmdlets for Exchange. I have not been able to find a way to force the 32 bit cmdlets to install on a 64 bit computer. so, when the agent launches PowerShell, is launches the 32 bit version, which is then unable to load the 64 bit Exchange snapin.

We’re pushing Groundwork for a 64 bit agent, which would resolve our issue. In the meantime, we’ve begun to implement a work-around. We’ve created a Windows 2003 32 bit GroundWork proxy and have installed the 32 bit Exchange 2007 tools on it. We can then have the proxy launch the cmdlets to check various exchange functions remotely and then pass the results to the Groundwork servers. It’s a less than ideal solution, but should work until GroundWork releases a 64 bit Windows agent.

If you have experienced a similar issue and have other workaround solutions, I’d be happy to hear about it.

~Daniel