Thwe original idea behind generating the report was to have the info come to me rather than logging into multiple servers and firing up the console multiple times (what can I say I’m lazy).

The report in the first version of the script was straighforward text. Recently I’ve been looking into and thinking about different ways to present the information in the report so I could just sort of glance at it and get the status. The disk related portion of the report wasn’t initially where I was focusing my attention. I was more interested in being able to get a quick idea of where we stood with the # of Recovery Points we were expecting to have.  An example of  one of the simple reports is below. From this we can see that we’re in pretty good shape with 100% valid RPs spanning about 24 days.

Starting Script at 04/30/2009 23:20:12

Replay Service is running

Server mailserver.company.com snapshots are being stored on R: and currently using 818.54GB. This is 99.98% of the used space(818.68GB) on the volume which is 1,360.22GB

The drive currently has 39.81% free space (e.g. 541.54GB)

Number of reported Recovery Points is 395 of these 395 are valid, and 0 are invalid (100.00%).
The valid RPs span 23.98 days

The most recent valid RP was taken 1 Minutes ago

The issue becomes less clear when invalid RPs occur for whatever reason. If I have 395 RPs and only 250 of the are valid is that a good or bad state? It’s not immediately clear but one can log in to the Replay server and get a better idea of how things stand. It might be the case where there was network issue during the day and instead of 96 RPs  (that’s an RP every 15 minutes * 24 hrs) for each of the last three days we’ve only gotten 40 RPs each of those days which while less than ideal might still be an okay state. Or it could be that there are several days for which we don’t have RPs.

I was trying to think of a way to visualize this information. Because of the retention schedule some days we’d expect a large number of RPs (~90) and some other days we’d expect to have just one.  I looked into the possibility of using sparklines even going so far as to download a C# based version of  a PHP based sparkline web service from Joe Gregorio.

I tried several different iterations of the script using sparklines trying to use the data I had in different ways (ex: use percentages of expected RPs, diffs between expected and actaul) but wasn’t able to find a good way to represent the state using those. In digging around I came across the Google Chart API and that looked at bar different ways of using bar graphs to represent the info I wanted.  Using either side-by-side bar graphs

overlapping ones with green and red where a lot of red would be a bad thing.

Either of these would have been an improvement over what I was getting in the text based report.  While trying to refine the overlaid version I came across an example in the Google documentation on line styles of  this graph:

Chart Data Line example from Google Chart API

This caught my eye as a possible solution to my problem about how to present this data because of the ability to show both sets of data overlaid on each other while still managing to keep both of them visible.

In my particular scenario the retention schedule is:

• RPs every 15  minutes which are kept for 4 days
• These roll up to hourly RPs which are kept for 5 days
• Hourly’s roll up to dailies which are kept for ~25 days

Our goal is to keep about 30 consecutive days worth of RPs on hand. When plotting out the # of expected RPs per day we get a graph that looks like the one below.

As one can see the number of Recovery Points per day decreases over time. When adding the line showing the number of actual RPs it can be hard to tell what the status is for the days where there’s only one RP per day. If things are going well the green bars will be obscured by the red line.

In the rare instance where we might be missing a few daily RPs the green bars do become somewhat visible as shown in the blue box below.

I experimented with a couple of different ways to try to make this more obvious including altering the width and height of the chart to make it more obvious. (see below). Using the Google Chart API one is limited to an image with 300000 pixels (500×600)

But for me persoanlly making the chart a lot bigger like  this seemed like it didn’t really add all that much to being able to see what was going on.  So I stuck with 600×250 for the graph.

It should also be noted that in the case where you aren’t taking snapshots every 15 minutes but evey 30 minutes or maybe even every hour it becomes easier to see missed daily RPs.  Here’s an example

After going through all of this with the RPs I almost as an afterhtought went back and added the logic to graph the disk usage data as well. It shows the size of the Replay archive data, the free space and other used space on the drive by generating something like this:

Here’s a “real-life”  example of the whole report.

The script is available here. If it’s of any use to you please drop me a line and let me know.

To use it rename it to something like ReplayReport.ps1. You’ll need to modify the variables at the beginning of the file:

• $ReportRecipients – array of recipient email addresses.
• $MailServer – The SMTP server to use to send the report out
• $ReportSender -Address the email should appear to come from.
• $replay_exe – Path to the Replayc.exe file. May differ on x64 vs x86  servers.
• $ExpectedRPCount – array containing the number of expected RPs for the last X days. Used to generate the graph of expected vs present RPs. (See Note below)

The script doesn’t take any arguments to run. I run it via a scheduled task on the replay server.

***************

In reference to $ExpectedRPCount the time of day that the report is run will affect how the first data point on the graph appears. RPs are tracked by the date that they were taken. If you run the script just before midnight there will obviously be a lot more RPs for “today” than if you run it at 1 am.

In poking around the install directory I came across the Replayc.exe command. Replayc is a command line utilty that offers information about the Replay server and a way to manually mount and dismount Recovery Points (RPs). After playing with it a little and being the very lazy person that I am  I decided to write a Powershell script to help give me a high level status overview of my servers.  The script runs on each server at about the same time (relative to me here in Oregon) every day and emails me the output. So instead of having to muck around in the console Ionly have to spend a few seconds each to make sure everything’s running properly.

The script is available here and needs to be renamed appropriately.

When the script runs the email (HTML formatted)  I get is like the one below.  It tells me a number of things:

• The status of the Replay Server (running/not running)
• The name of the server that’s being protected
• How much disk space is available and being used for RPs for that protected server
• The size of the disk where those RPs are being stored
• The # of valid and invalid RPs
• The timespan between first and last valid RP
• Last time an RP occurred.

Example Email:

Starting Script at 04/30/2009 23:20:12

Replay Service is running

Server mailserver.company.com snapshots are being stored on R: and currently using 818.54GB. This is 99.98% of the used space(818.68GB) on the volume which is 1,360.22GB

The drive currently has 39.81% free space (e.g. 541.54GB)

Number of reported Recovery Points is 395 of these 395 are valid, and 0 are invalid (100.00%).
The valid RPs span 23.98 days

The most recent valid RP was taken 1 Minutes ago

So what it it turns out I was getting from the GetValue method was a sequence of 4 bytes as an array. This made me wonder what the heck was going on so I fired up RegEdit to take a look. The contents of the Data column looked okay but the Type was different, so I expanded the column to see what was different and discovered REG_DWORD_BIG_ENDIAN as a type. This was one I don’t recall having seen before.

TechNet has the following to say about DWORD and it’s brethren:

REG_DWORD
A 32-bit (4-byte) number. Boolean (”True” or “False”) values and many entries for device drivers and services use this data type. REG_DWORD data can be displayed and entered in hexadecimal or decimal format in the registry editor Regedit.exe. For an example, see the ActivityLogFlag entry.

REG_DWORD_BIG_ENDIAN
Same as REG_DWORD. A 32-bit number in which the most significant byte is displayed as the leftmost (or high-order) byte. This is the most common format for storing numbers in computers that are running Windows Server 2003.

REG_DWORD_LITTLE_ENDIAN
A 32-bit number in which the most significant byte is displayed as the rightmost (or low-order) byte. This is opposite of the order in which bytes are stored in the REG_DWORD and REG_DWORD_BIG_ENDIAN data types.

If you’re not paying attention it could be easy to miss the difference when using RegEedit since they appear almost identical to DWORD values. The only obvious difference is the “Type” field.

So in the example above GetValue returns different values for “PerfCtr2″ and “PerfCtr2 DWORD” which are nominally the same value (at least according to RegEdit).

To help me figure out how to get the info I was looking for I put together a test and created a couple of dummy registry keys with each of the types of reg keys and some examples.

If we try to see what Powershell tells us about each of these keys we see that for our BIG_ENDIAN friend GetValueKind returns “unknown.”

GetValue converts each byte to a decimal value. Our key REG_DWORD_BIG_ENDIAN (0xa1b2c3d4) can be expressed as 4 bytes “a1″ “b2″ “c3″ “d4″ which when converted become the values “161″ “178″ “195″ “212″. While this is mildly useful it doesn’t help us easily get the value we want 2712847316. While it is possible to get the right value by doing some math [ (byte1 * 256^3) + (byte2 * 256^2) + (byte3 * 256) + byte4 ] I thought my resulting attempts to write a snippet to do this were ugly since it doesn’t appear Powershell has any easy way to do exponentiation.

The third method was to write out the formula a little more explicitly so that (byte1 * 256^3) + (byte2 * 256^2) + (byte3 * 256^1) + (byte4 *256^0) becomes (byte1 * 16777216) + (byte2 * 65536) + (byte3 * 256) + byte4

I was curious though as to why it was we could get the individual bytes converted but there wasn’t (to me) an obvious way to do the whole value. I came across a mention of the Convert Class on MSDN which does make it possible. Convert class in the .Net framework. After playing around some I was able to come up with a different way using the Convert Class that to me seems a little cleaner. The Convert class has several overloaded methods. One version of the ToInt64 method converts a string version of a number into 64-bit signed integer. Either this or ToUInt32 will work for our purposes here. ToInt32 won’t work because of the value may incorrectly (for our purposed) return a negative (i.e. signed) integer. The call to the ToInt64 method requires an argument that specifies the base of the number the string represents (in this case hex= base 16). So in theory that would work if we were able to represent the bytes as a hex string.. i.e. 0xA1B2C3D4. That’s when I came across a VBScript to Powershell page describing converting numbers from decimal to hex that helped fill in the missing piece. Putting these two things together I was able to come up with a function to use in my script which seemed to work.

The operative word here was “seemed”. I noticed in testing that there were instances where I got a very wrong answer. As an example if the Registry value were (0xA102C4D4, or 2701312980 decimal) the function would return. 169001940 decimal as the value…I realized that in building $tmpString if the value of a particular byte was less than 16 it’d spit out a single character 0xC rather than 0×0C. This was fine if I was interested in the value of a single byte but when concatenating the values together makes for a big difference in the resulting value as 0xA102C3D4 would become 0xA12C3D4. The resolution for this was to change the format string to pad the value with a leading 0 if necessary. So $tmpString += “{0:X}” -f $byte became $tmpString += “{0:X2}” -f $byte.
So the final function I ended up using looks like this: