November 2008 Blog Posts

I just processed another batch of community-created wireframes and added them to the WHS Disk Management site. They look great; thanks to everyone that's contributed so far.

I've also gone through and added screenshots for every wireframe. You can click the image link icon next to each wireframe to display a visualization before you download it.

If you've sent me a wireframe and it hasn't shown up yet, fire me an email reminder. Sometimes they get lost in my inbox.

Great stuff in here, so go patch.

Shared Folders and Server Storage

Issue 1

Before this update is installed, the ability to copy large files or folders from a home computer that is running Windows Vista to a shared folder on the home server is limited by the free space on the primary hard disk drive of the Windows Home Server-based system. After this update is installed, the file size is limited to the free space on the target hard disk drives that are connected to the home server.

Issue 2

Sometimes, Windows Home Server generates lots of notification messages about the files that are stored in shared folders. These notifications may cause high CPU utilization on the home server for applications that are accessing these files. This behavior causes slow performance on the home server. After this update is installed, applications such as the Microsoft Zune software, that may be running at the same time, no longer consume excessive processor resources.

Issue 3

Under certain conditions, Windows Home Server disables duplication on shared folders after a new user account is created. After this update is installed, creation of user accounts no longer affects the status of shared folder duplication.

I ran into a nasty bug with the latest alpha of WHS Disk Management 1.1; on non-English servers, the DiskManagement service failed to start. No meaningful error was generated, nothing got logged, and no matter what configuration options I changed, the service wouldn't start. Ever.

How's that for a bug?

Turns out, I was being bit by a localization issue. Who knew that the Authenticated Users group isn't actually named "Authenticated Users" on non-English servers?

Here's the fix. When passing your IDictionary of channel properties to the IpcChannel constructor, make sure you're getting the localized name of the role you're authorizing:

SecurityIdentifier sid = new SecurityIdentifier(WellKnownSidType.AuthenticatedUserSid, null);
NTAccount account = sid.Translate(typeof(NTAccount)) as NTAccount;

IDictionary channelProperties = new Hashtable();
channelProperties["portName"] = portName;
channelProperties["exclusiveAddressUse"] = false;
channelProperties["authorizedGroup"] = account.Value;
channelProperties["typeFilterLevel"] = System.Runtime.Serialization.Formatters.TypeFilterLevel.Full;

IpcChannel channel = new IpcChannel(channelProperties, null, null);

One of the questions I see quite often from beginning Add-In developers relates to saving settings for Add-Ins. What’s the best way, or the Microsoft-preferred way, of persisting settings between console sessions for my application?

The SDK isn’t very clear on this, and I haven’t seen anything official from Microsoft regarding best-practices or even recommendations.

Part of the answer comes from the built-in Windows Home Server Server Reinstallation recovery option. If your Home Server suffers a System disk failure, or operating system corruption, users are encouraged to boot from the Windows Home Server DVD and perform a reinstallation.

If the setup routine detects the presence of QSM disks in the server (that is, disks previously managed by Windows Home Server), it should prompt the user to perform a Server Reinstallation; this setup method preserves the existing Windows Home Server-managed data on your server and doesn’t repartition and format the ex-Storage Pool disks as a normal installation would.

The interesting thing about a Server Reinstallation is that it also preserves Windows Home Server Application Folders. From the Windows Home Server SDK:

Custom applications can use an application folder on the home server to store all of the application's necessary files. If a home server has application folders, you can access information about the folders through the API for Windows Home Server and then use that information in your custom application for Windows Home Server.

ISVs typically install files in the Program Files folder. This is still an option with Windows Home Server, but the Program Files folder is located on the system partition which has a limited size. You can use application folders for storing large amounts of data.

To me, an Application Folder sounds like the perfect place to store Add-In settings.

Application Folders reside on the D: partition, in D:\Folders. An Application Folder is named after its GUID (as in D:\Folders\{AD6D2DAD-BBCB-4C4D-878C-A8A19935FD0A}\ in the case of WHS Disk Management). It’s interesting to note that Microsoft uses Application Folders for storing the backup database and a copy of the Windows Home Server registry keys (for use during a Server Reinstallation).

The SDK covers finding and creating Application Folders pretty well, but here are some code snippets. Use your own GUID when doing this for production code.

Getting an existing Application Folder, and grabbing its file path:

WHSInfoClass info = new WHSInfoClass();
IApplicationFolder folder = info.GetApplicationFolder(new Guid("{DE49295C-B737-425e-B7F7-DC026E975F83}"));
string filePath = folder.Path;

Creating a new application folder:

WHSInfoClass info = new WHSInfoClass();
IApplicationFolder folder = info.CreateApplicationFolder(new Guid("{DE49295C-B737-425e-B7F7-DC026E975F83}"), "My App Folder");
string filePath = folder.Path;

With these two methods, you can use a bit of error-handling to catch an exception and create the Application Folder if it doesn’t exist. Writing to your new Application Folder is as easy as passing its Path to your file creation method.

But what about saving settings? I’m a big fan of using XML for settings in Windows Home Server Add-Ins. XML Serializations is fast and easy in the .NET framework, and outputs user-editable files (if required).

The first order of business is to create a settings class:

class Settings
    private int numberOfWidgets;
    private bool widgetsEnabled;

    public int NumberOfWidgets
        get { return numberOfWidgets; }
        set { numberOfWidgets = value; }

    public bool WidgetsEnabled
        get { return widgetsEnabled; }
        set { widgetsEnabled = value; }

Create a new instance of the class, and populate it with your widget settings:

Settings myAppSettings = new Settings();
myAppSettings.NumberOfWidgets = 24;
myAppSettings.WidgetsEnabled = true;

You can access your myAppSettings instance of the Settings class from elsewhere in your Add-In to determine which GUI elements to show or hide, for example.

When it comes time to persist your settings to disk, you can use XML Serialization and write a file to the location represented by the filePath string we retrieved earlier:

Stream XmlFileStream = new FileStream(filePath + @"\" + "settings.xml", FileMode.Create, FileAccess.ReadWrite);
XmlSerializer Serializer = new XmlSerializer(typeof(Settings));
XmlTextWriter Writer = new XmlTextWriter(XmlFileStream, Encoding.UTF8);
Writer.Formatting = Formatting.Indented;

Serializer.Serialize(Writer, myAppSettings);


Retrieving your saved settings next time your Add-In opens is just as straightforward:

Stream XmlFileStream = new FileStream(filePath + @"\" + "settings.xml", FileMode.Open);
XmlSerializer Serializer = new XmlSerializer(typeof(Settings));

myAppSettings = (Settings)Serializer.Deserialize(XmlFileStream);




Site Sections

Recent Posts


Post Categories

WHS Add-In Tutorial

WHS Blogs

WHS Development