March 2009 Blog Posts

Brendan has posted a great overview of the API changes in Power Pack 2. There’s a few in there I didn’t know about, and some that will come in really handy for the next version of WHS Disk Management.


Rather than describe each of these, I am going to let their names speak for them and what they can do:





But wait... there's more!


Back in Console land we've long had the ability to open an arbitrary Settings page (provided we know it's guid) or a URL on the client PC... did you know you can also select a specific console tab? With a few tweaks to IConsoleServices you can:


Each of the above methods rely on the new TabIdentifier attribute which can be used to decorate an IConsoleTab implementer so that other applications.

Very cool changes, and a big thank you to Brendan for calling these out.

Windows Home Server’s success as a platform depends entirely on the ecosystem that surrounds the product. That means the various hardware vendors, obviously, but it also means the software development community; both the big ISVs and as well as the single-developer shops cranking out Add-Ins in their free time.

In just about every major WHS update, Microsoft has extended the SDK for Windows Home Server. They may not update the SDK documentation, but there are almost always new bits of functionality or tweaks to existing capabilities. For example, Microsoft recently added support for programmatically changing Shared Folder permissions (see Part 3 of my WHS Add-In Tutorial), and we’ve seen the gradual clean-up of a bunch of existing methods in the main SDK (not having to call Init() on everything means less unhandled exceptions and less trips through the debugger, which makes everyone happier).

I really think that the Windows Home Server extensibility team “gets” the promise of the platform; the WHS SDK isn’t something they stuffed haphazardly into the product and then forgot about.

Now with Power Pack 2, we’ve been given even more toys to play with.


Programmatically changing disk location text

Based on feedback from various partners, Microsoft has added the ability to programmatically change the displayed value for the Location column on the Server Storage tab. You’re no longer stuck with “Internal (IDE)” or “SCSI”; you can set the value to any text string you like.

The method to change the value displayed in Location is exposed by the new IDiskInfo2 object. You can get at this new object using the standard WHSInfoClass.GetDiskInfo() method. In order to see the new IDiskInfo2 object in Visual Studio, you’ll need to grab a fresh set of Power Pack 2 assemblies from your server and change your project to reference the new files. And if you’re using ReSharper, you might need to kill the cache folder in the root of your project directory.

To set a new value for Location, just change the LocationDisplayName property for each disk.

WHSInfoClass info = new WHSInfoClass();

foreach (IDiskInfo2 iDisk in info.GetDiskInfo())
	iDisk.LocationDisplayName = "My new location (SATA)";

That’s it. Your disks will now all show “My new location (SATA)” under the Location column on the Server Storage tab.




If you want to ditch your custom location, just set LocationDisplayName to string.Empty and the Windows Home Server console will go back to using the default value for Location for that disk.

WHSInfoClass info = new WHSInfoClass();

foreach (IDiskInfo2 iDisk in info.GetDiskInfo())
	iDisk.LocationDisplayName = string.Empty;

This is great functionality if you’re an OEM building a custom Windows Home Server that has clearly labelled drive bays. Instead of “SCSI”, you can now set “Internal Drive 0 (SATA)” to make it easier for your users to identify which disk to pull.

The only question here is who’s going to volunteer to develop the first Add-In that lets us write custom values to LocationDisplayName?


End-User License Agreements for Add-Ins

The Windows Home Server developer guidelines state that the .msi package for an Add-In should be silent; a user shouldn’t be prompted for any information, and the install should complete without any input whatsoever. That presents a problem when a software developer wants to include a license agreement with their Add-In.

In Power Pack 2, Add-In developers now have the ability to include a custom EULA with their .msi file.

The process couldn’t be simpler, really; all you need to do is include an .rtf file with the same name as your Add-In .msi in the \Software\Add-Ins folder on the server, and the contents of that .rtf will be displayed as a license agreement during the Add-In install process.

If your Add-In is packaged as MyAddIn., for example, you’d name your license file MyAddIn. so that the WHS Console could display it.





I’m still debating how best to deploy a license file with an Add-In; normally, I just offer the basic .msi file for download. Users can then just drop the file directly into the \Software\Add-Ins folder, and install it. So packaging a license file with the Add-In is probably going to require pushing both the .rtf and .msi into an archive of some kind (.zip, .rar, etc.) and asking users to decompress the archive manually. Not a clean solution, in my opinion.

Still, having the option to display a EULA is invaluable when you’re talking about a commercial Add-In.


Carpe SDK

There you have it, some shiny new things in Power Pack 2 for us developers to play with. Who says the media guys are the only ones who have any fun?

Surprise! It’s Power Pack 2!

Also, after a bit of back and forth, WHS is now available for those with a TechNet or MSDN subscription to download. We even have an official announcement this time. I’m off to grab my keys before it gets pulled again…

Maybe a long-awaited, and much asked for, feature of WHS Disk Management 1.1? I guess we’ll find out soon.



Further to my previous post, Microsoft has informed us that WHS showed up prematurely on TechNet and MSDN due to internal testing processes; we weren’t supposed to have seen it. I guess that just shows how keen we are to have Windows Home Server available for all TechNet and MSDN subscribers!

Look for an announcement from Microsoft in the near future on TechNet/MSDN availability.

Finally, WHS is available on TechNet and MSDN for subscribers!

A big thanks to the WHS team at Microsoft for pushing this through (I heard that it was quite the task). Looks like TechNet and MSDN get two retail keys each, so that’s four full retail installs total if you have both subscriptions.

This will definitely open WHS up to the wider Microsoft developer community, and that can only be a great thing.

Thanks to Alex for the tip.

Err… or not. After seeing some forum reports that the download was removed, I checked this morning; looks like Microsoft have indeed removed WHS from the download list. The product keys I claimed also aren’t visible.

Seeing what I can find out from Microsoft now.

Brendan Grant from the Microsoft Windows Home Server team has posted an excellent walk-through on configuring your custom WHS web application to leverage the existing WHS forms-based authentication provider.

Lets take a look at the web.config (c:\Inetpub\remote\web.config) from a Home Server sitting under my desk at work:

<?xml version="1.0"?>
        <machineKey validationKey="<key removed for length>"
   decryptionKey="<key removed for length>"
   validation="SHA1" decryption="AES" />
        <authentication mode="Forms">
            <forms name="RemotePortalAuth" loginUrl="logon.aspx" protection="All" path="/" timeout="12000" requireSSL="false"/>
            <deny users="?"/>
            <allow users="*"/>
        <httpRuntime maxRequestLength="2097151" executionTimeout="86400"/>
        <customErrors mode="On" defaultRedirect="error.aspx"/>
        <trace enabled="false" requestLimit="100" pageOutput="false" traceMode="SortByTime" localOnly="false"/>
        <sessionState mode="InProc" cookieless="false" timeout="20"/>
        <globalization requestEncoding="utf-8" responseEncoding="utf-8"/>

In order for our own web application to use the same authentication back end and cookie as the existing Windows Home Server Remote Access web page, we need to copy two sections of the above file to the web.config file being used by our own custom app, specifically the machineKey, and authentication key tags.

It’s always a good idea to give your users a consistent experience; leveraging the existing authentication model enables single sign-on between your application and the rest of the Remote Access infrastructure.

I’m excited.

We’ve seen some awesome and shiny new functionality over the last few days. Most of it is under NDA, and could potentially remain that way for a long time yet. There’s some great stuff coming down the pipeline, revolutionary stuff, and I can’t wait to get my hands on it.

But trust me when I say this: I’m more excited about the discussions we’ve had with the Windows Home Server team than the actual technology demonstrations I’ve watched.

Let me share a little secret here. When you and a couple of fellow community developers sit down in a room with 15 members of the WHS extensibility team for a “chat”, and they all break out paper and pen and stare at you expectantly, that’s very, very intimidating.

But they listened, and I really felt like we were heard. We all got a strong impression that Microsoft wants to do right by the community and grow the 3rd-party developer ecosystem around the WHS platform.

And that can only mean good things for all of us.

And last but not least, with much gratitude to fellow WHS MVP Yoshihro Okabe, we have probably the coolest MVP swag ever. Allow me to present the newest Windows Home Server MVP:




Big thanks to Microsoft for getting us all together in one place, and running everything like clockwork. Napoleon could have used your event managers during that whole Russian thing.

I couldn’t resist posting this one.

funny pictures of cats with captions


Site Sections

Recent Posts


Post Categories

WHS Add-In Tutorial

WHS Blogs

WHS Development