Just How Big Is My Volume? NetApp and Powershell

It would at first appear easy to determine how big your NetApp volume is in PowerShell. There is a cmdlet called Get-NAVol and it has a property called TotalSize. Easy, right?

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.

NetApp and PoSH: Caveats with Get-NaVol and Set-NAVolAutosize

While working on a script to set the auto-grow max sizes on a given NetApp head (which I will post more about soon), I ran into the following problem.

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

Audit for Disk Offset

Unaligned disks, particularly in a consolidated VM environment, can result in some serious storage performance problems. So, how about we query all our Windows VMs for their existing offset values?

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.

Asynchronous Event Handling in PowerShell

I had never even considered using PowerShell to handle asynchronous events. Technet’s Hey Scripting Guy is running a series of excerpts from Windows Powershell in Action by Bruce Payette. I’m fairly certain this is from the second edition of the book.I’ve read parts of the first edition and found it to be very well written, concise, and easy to follow. Based on the first edition, I’d highly recommend the book. In fact, I think it’s time to add the second edition to my Amazon cart.

Here are the links. Enjoy!

Use Asynchronous Event Handling in PowerShell

Manage Event Subscriptions with PowerShell

 

~DL

Use PowerShell to Search for a Directory One Level Deep

This is a fairly simple on-liner. Assume you have a user home directories share wherein each user has a unique sub directory. There is a process that backs up to each users home directory when they upgrade to new computer. The backup directory is simply named backup. You need to find which users have lingering backup directories (perhaps they were never deleted).

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

Monitoring for Undelivered UM voicemail with PowerShell

Just a quick one.

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

PowerGUI PKI Management

I found this PowerPack for Enterprise PKI Management using PowerGUI the other day here at Dmitri Sotnikov’s blog. After poking around a bit, it appears to have a lot of cool functionality. I highly recommend checking it out if you do any PKI work.

Windows Minidump (Small Memory Dump)

More than once I have been asked to help identify why a mini-dump file was not produced after a system blue screen. More often than not, it is because the mini-dump file location has not been properly configured. By default, Windows will specify something like %systemroot%/minidump. The problem is, this directory does not exist. The dump process will not create a directory at time of write. So, you either need to create the directory or change the dump location. Usually, I just place it on the root of the boot volume.

 

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

Exchange 2007 Monitoring with GroundWork and PowerShell

Many of you may already know that Exchange 2007 makes most, if not all, of Exchange administrative functions available through PowerShell cmdlets. Many of these cmdlets lend themselves to monitoring the environment. for example, it is quite easy to use PoSH to check the CCR and SCR health.

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

AD Security and PowerShell with PowerGUI Webinar/Webcast

I ran across the following upcoming webcast on Dmitry Sotnikov’s blog in his post Windows & AD Security Webcast. In short, it appears to be a webcast focusing on finding dormant accounts in AD using a PowerPack developed for PowerGUI. While that in of itself is a somewhat specific task, I’m sure the PowerPack and webcast will cover topics that can be applied more broadly. If you are unable to attend the webcast it looks as if a recording will be made available. The webcast will be given by Randy Franklin Smith of Ultimate Windows Security and is sponsored by Quest. Register here: http://www.ultimatewindowssecurity.com/webinars/register.aspx?id=97