August 2010 Blog Posts

Big thanks to the WHS community for the great response to our CTP announcement for Blackbox. We’ve got our test team full for this initial round, but look out for more opportunities soon.

It’s that time again! Tentacle Software is looking for testers for our latest Windows Home Server Add-In, Blackbox for Windows Home Server.

Blackbox for Windows Home Server provides in-depth real-time monitoring of motherboard, disk, UPS, and graphics card hardware sensors. Administrators can define alerting rules to take actions when a sensor exceeds a specified threshold.

banner-blackbox-sensors 

banner-blackbox-rules

This is a preview release of Blackbox and is intended to showcase the major features that will be present in the release version, and to give our users the opportunity to provide input on the final feature-set.

Key features:

  • Real-time monitoring of supported hardware sensors
  • Administrator-defined rules to perform actions based on sensor states, including:
    • Log the alert to a file
    • Log the alert to the Event Log
    • Create a Windows Home Server health notification (that appears in the server health status window)
    • Set a fan speed
    • Change the system power state (shut down, suspend, hibernate, or restart)
  • PWM fan control

Blackbox requires the following platform:

  • Windows Home Server v1 operating system (“Vail” isn’t supported in this release)
  • Windows Home Server Power Pack 3 (installed automatically by Windows Update)
  • .NET Framework v3.5 SP1 (installed automatically by Windows Update)
  • A motherboard with supported hardware sensors (most ITE* chips, CPU thermal sensors, hard drive SMART sensors, and UPS battery sensors are supported)

If you’re interested in participating in the initial closed CTP, please get in touch (and when you fire off the message, please include the specs of your server). We’re looking for testers who are just as excited about Blackbox as we are, and who want to contribute to making Blackbox as awesome as it can be. Edit: We’ve got the first round of testing covered, but look out for more opportunities soon!

We’ve sent out copies of Blackbox to some of the major Windows Home Server community sites, and you can find preview articles from them here:

Last year, Nick from ASoft wrote a comprehensive set of documentation for WHS v1 Add-In development. He’s now released an updated version for “Vail”.

Version 1.1 of the WHS DevKit 2 has been published. This Kit is an all-in-one package on how to create/build/install and addin for Vail, so if you want to have a go at it take the kit and have fun!

This new version has been updated to support the latest version of Windows Home Server: build 7659.

You can find Nick’s documentation over at the ASoft Blog.

A while back I posted a guide on how to get WiX to automatically set the installation package’s version, and how to rename the output package to include the same version number.

The instructions still work great, but it all felt a bit too messy.

I’ve spent a bit of time with WiX 3.5 over the last few days (because only WiX 3.5 beta supports Visual Studio 2010), and I’ve been able to solve a few niggling issues with my previous installers. Cleaning up how I name the output package is one of those.

I’m still doing this for the version number of the installer, (where $(var.xx.TargetFileName) points to a Project Reference*):

<Product Id="some-guid-here"
       Name="Blackbox for Windows Home Server"
       Language="1033"
       Version="!(bind.FileVersion.$(var.HomeServerConsoleTab.Blackbox.TargetFileName))"
       Manufacturer="Tentacle Software Ltd."
       UpgradeCode="some-guid-here">

But I’m now using a different method to rename the actual output file to include the version number, and have that automatically update whenever the version of the project changes.

The basic issue was that I couldn’t work out how to make the WiX processors pick up changes to the OutputName property of the wixproj file, so I was left with running an action after the build to rename the output file to what I wanted.

The old and busted way:

<Target Name="AfterBuild">
  <GetAssemblyIdentity AssemblyFiles="..\HomeServerConsoleTab.DiskMgt\bin\$(Configuration)\HomeServerConsoleTab.DiskMgt.dll">
    <Output TaskParameter="Assemblies" ItemName="AssemblyVersion"/>
  </GetAssemblyIdentity>
  <Copy SourceFiles=".\bin\$(Configuration)\$(OutputName).msi" DestinationFiles=".\bin\$(Configuration)\WHSDiskManagement.%(AssemblyVersion.Version).msi" />
  <Delete Files=".\bin\$(Configuration)\$(OutputName).msi" />
</Target>

The new hotness:

<Target Name="BeforeBuild">
  <GetAssemblyIdentity AssemblyFiles="$(SolutionDir)HomeServerConsoleTab.Modus\bin\$(Platform)\$(Configuration)\HomeServerConsoleTab.Blackbox.dll">
    <Output TaskParameter="Assemblies" ItemName="AssemblyVersions" />
  </GetAssemblyIdentity>
  <CreateProperty Value="$(OutputName).%(AssemblyVersions.Version)">
    <Output TaskParameter="Value" PropertyName="TargetName"/>
  </CreateProperty>
  <CreateProperty Value="$(TargetName)$(TargetExt)">
    <Output TaskParameter="Value" PropertyName="TargetFileName"/>
  </CreateProperty>
  <CreateProperty Value="$(TargetDir)$(TargetFileName)">
    <Output TaskParameter="Value" PropertyName="TargetPath"/>
  </CreateProperty>
</Target>

You can see I’m still using GetAssemblyIdentity and pointing to the assembly whose version number I want to grab, but I’ve switched to a BeforeBuild action. That’s because I figured out I could explicitly change the command parameters that WiX was sending – specifically, the TargetName, TargetFileName, and TargetPath variables, which determine the final file name of the package.

In the example above, I’m taking the OutputName that I configured in the project properties (“TentacleSoftware.Blackbox” in this case), and appending the version number to it to create my new TargetName.

There’s a few more lines of XML there, but basically after we set the TargetName property we’re just rebuilding the TargetFileName and TargetPath properties to match.

Interestingly, my initial tests showed that I didn’t have to update anything except the TargetName – the TargetFileName and TargetPath were still the ‘incorrect’ values but the output file included the version number anyway – but to be on the safe side, I’ve chosen to rebuild all the Target* properties so that they’re valid.

That all feels lots cleaner to me. We’re actually setting the desired output name and letting WiX take care of the rest, rather than renaming files at the end.

*More about Project References, and why I should have been using them ages ago, soon.

The Home Server Show is the best podcast in the world because it’s about my favourite subject: Windows Home Server!

The boys have just recorded and released their 100th episode, and as part of the celebration we’re providing a super-secret coupon code to get 50% off Disk Management. We’ve also thrown five free licenses for Disk Management into the prize pool as well.

You’ll need to hit the Home Server Show site to get the code. Hurry, the special is only going to last one week!

The We Got Served forums have a dedicated board for user-submitted ideas for Windows Home Server Add-Ins. I like to know what users think WHS is missing, so I keep an eye out for any new posts.

Yesterday, Ron Levenberg posted an interesting request:

I would love to be able to get a daily e-mail that confirms to me that all my PCs connected to my home server have been backed up successfully and, if not, which PCs don't have current backups. It could be something like the Computers & Backups page data. I don't want to login to the server to verify this, and I certainly don't want to View Details for each PC to make sure all of yesterday's backups are good.

Because I thought this sounded like a great idea, I’ve baked a console application to do just that.

Windows Home Server Client Backup Notifier (what a name!) can be run from a command-line, or as a scheduled task, and emails you high-level information about the state of your client backups.

The output looks like this:

CLIENT1 (192.168.1.22) 
---------------------------------
Last Good Backup: 31/07/2010 2:58:01 p.m.
Last Backup Status: Complete
Current Health Status: Normal

CLIENT2 (192.168.1.23) 
---------------------------------
Last Good Backup: 1/08/2010 4:31:20 a.m.
Last Backup Status: Complete
Current Health Status: Normal

CLIENT3 (192.168.1.24) 
---------------------------------
Last Good Backup: 1/08/2010 6:11:19 a.m.
Last Backup Status: Complete
Current Health Status: Normal
Backup is running

I’ve tested the SMTP functionality with Google’s SMTP server, and with a ‘normal’, non-encrypted, SMTP server and it works great.

Download WhsClientBackupNotifier here.

I’m interested to know how many people find this useful. If you try it out, or if you encounter any bugs or issues, or want to offer a suggestion for improvement, get in touch.

Search

Site Sections

Recent Posts

Archives

Post Categories

WHS Add-In Tutorial

WHS Blogs

WHS Development