Some old foggies in the computing industry (myself included) remember a time when being called “skuzzy” was a complement because we thought the speaker was referring to SCSI, or the Small Computer System Interface which for a time dominated much of the high end desktop and server market for connecting hard drives, optical drives, scanners and countless other devices.
Today it really lost ground to improved versions of IDE, SATA, USB, and IEEE-1394 on the average desktop, laptop and server, but still exists in many high end servers and is still well supported in Windows and is even seen in many people’s Home Server Consoles which may identify internal SATA drives as SCSI:
The answer to this comes from Henry Gabryjelski, a patent agent at Microsoft:
The reason requires a trip through the history of Windows NT storage (stop reading anytime).
Short answer: You’re using a 3rd party driver to control the SATA adapter, which reports itself as a “SCSI” controller.
Long answer:
ATA miniports in Windows (until Vista) had no capability to support more than one outstanding request at a time. This is because ATA devices were originally able to handle only a single request at a time. Although native command queuing (NCQ -- multiple outstanding requests) was added to Parallel ATA (PATA), the implementations were so ... diverse ... that supporting them was not possible for Microsoft, thus no support added.
Of course, vendors thought that NCQ was the best thing since sliced bread, since it improved performance of the drives. Therefore, they used another driver model, that of the SCSI miniport driver, to control their hardware. It provided the ability to have multiple outstanding requests, therefore enabling NCQ. Due to the different means of reporting device IDs between SCSI and ATA, however, there were some oddities that resulted. One of these oddities is that the drive is reported as “SCSI”. Another oddity is that the SCSI INQUIRY data may not fully match the ATA IDENTIFY DATA, since the identifier fields have different fields of different lengths.
So, you have a 3rd party SATA controller driver, and thus see “SCSI” even though it’s really SATA.
There’s one question answered, only another now remains: “Why on earth does a patent agent know such things?” The answer to that is far simpler: Henry is a former Windows Storage Driver Developer.
At times life can be pretty complicated... backing up your home PCs and safeguarding your family files shouldn’t be, and when designing Windows Home Server the conscious decision was made to try to limit the number of configuration knobs and simply the information given so that in the end managing the server and knowing the general health of your home network would be pretty easy, even from a distance.
Instead of requiring an administrator to login daily or check their email to find out of anything had gone wrong, we bubble up a general health state which will alert not only the server administrator to potential problems, but also anyone else in the house.
The most commonly seen is through a notification icon that sits next to the clock of each client PC:
Within the console we also display the same value:
This same can be seen on the front of many OEM built Home Servers such as on the HP MediaSmart EX485:
and the Acer Aspire easyStore AH340-UA230N:
With the above one can simply say “ahhh green” (or blue) and know that all is well in the home... at least with regards to ones data
All of these work great... but require you to either be running the client tray app (with the “Display Network Health Notifications” option checked), be logged into the Home Server Console or be within visual range of ones Home Server.
Did you know you can use this same information in your own applications?
Unfortunately there is no quick and easy GetHealthState() method within the Windows Home Server SDK, instead the value is determined by going through each outstanding Notification and determining if any exist that are marked as a Warning or Error... and if so we consider the overall state to be same as the most severe, non-suppressed notification.
Over on MSDN there exists a bit of sample code that demonstrates how to do this on demand, though with a few minor tweaks you can turn it into something more asynchronous that will alert you as to when the health has changed:
public class HealthChangedEventArgs : EventArgs
{
public HealthState CurrentHealth { get; private set; }
public HealthChangedEventArgs(HealthState health)
{
this.CurrentHealth = health;
}
}
public event EventHandler<HealthChangedEventArgs> HealthChanged;
protected void OnHealthChanged(object sender, HealthChangedEventArgs e)
{
EventHandler<HealthChangedEventArgs> temp = HealthChanged;
if (temp != null)
{
temp(sender, e);
}
}
HealthState lastState;
And then update the NotificationChanged function ever so slightly:
1: public void NotificationChanged(string UniqueID, WHS_Notification_Type Type, WHS_Notification_Severity Severity, int IsSuppressed, string textHeader, string textDescription, string helpFilename, string helpSection, string helpLinkText)
2: {
3: NotificationItem item = new NotificationItem(UniqueID, Severity, IsSuppressed, textHeader, textDescription, helpFilename, helpSection, helpLinkText);
4:
5: //if an add, add/overwrite item to existing list
6: if (Type == WHS_Notification_Type.WHS_NOTIFICATION_ADD)
7: {
8: notificationItems[item.UniqueID] = item;
9: }
10: else if (Type == WHS_Notification_Type.WHS_NOTIFICATION_REMOVE)
11: {
12: //If remove, if item exists remove it
13: if (notificationItems.ContainsKey(item.UniqueID))
14: {
15: notificationItems.Remove(item.UniqueID);
16: }
17: }
18:
19: //Get current health, if different than last, raise event of new state
20: HealthState currentState = GetHealthState();
21: if (currentState != lastState)
22: {
23: lastState = currentState;
24: OnHealthChanged(this, new HealthChangedEventArgs(currentState));
25: }
26: }
It’s just that simple.
Best of all... this code can be run on the server or on any client PC that is joined to a Windows Home Server and where both are running and communicating, recently MVP Donovan West recently released his first add-in, @WHSTweet which publishes your health to twitter for remote monitoring using this same information.
Next week I’ll show another simple way you can take this information and leverage it to find out your general health from afar...ish.
I just saw the following referenced in an internal discussion list and given it’s public info, had to share this deal listed on Ben’s Bargains:
Deal: 2-Pack Seagate Barracuda 7200.11 1.5TB 32MB Drive $200 at Dell Home Coupons
Dell Home has the 2-Pack Seagate Barracuda 7200.11 ST31500341AS 1.5TB SATA 3.0Gb/s Hard Drive for $270 - $70 off coupon code P0HD43$HB$DLDR [Exp 5/26, 1500] = $200 with free shipping. Features a rotational speed of 7200RPM and 32MB Cache. Here's Seagate's site pimping this drive. [Compare]
My poor little Home Server at home *only* has 5.91 TB of disk space... a pair of these will surely give me a little more room to grow :)
This for a drive that currently runs $129.99 on NewEgg.
Since releasing Power Pack 2 last month I've been contacted by a few users who were not automatically upgraded to Power Pack 2 despite having Windows Update enabled, even where and clicking the Update Now button doesn't find or install it:
The ultimate cause has been that while they were running Power Pack 1, they were running an pre-release version and Windows Update is generally not used to update beta software.
Based on talking with these users, as well as a quick look some build numbers from the Customer Experience Improvement Program it's clear that there are are enough users out there running pre-release versions of Power Pack 1 (and even some running Power Pack 2) that a blog post is warranted to remind everyone to make sure they know which version they are running and how to uninstall the beta version (if applicable).
It's important to make sure that, not just so you don't risk hitting bugs that may have been fixed by the final release, but also because running pre-release software limits which feature and bug updates to Windows Home Server may be received, items such as KB950193, KB961030, and others (while running the beta versions you should still be receiving updates to the underlying Windows Server 2003 operating system).
Checking the build number
In order to check the build number of our Windows Home Server:
- Launch the Home Server Console and login
- Click on the Settings button
- Select the Resources tab
A fully up-to-date (as of the time of this writing) Home Server will report the following versions in the Resources page:
Windows Home Server Console: 6.0.2030.0
Windows Home Server Backup & Restore: 6.0.2030.0
Windows Home Server Drive Extender: 6.0.2030.0
Windows Home Server Remote Access: 6.0.2030.0
Windows Home Server Storage Manager: 6.0.2030.0
Or visually:
Of the long version numbers, it is the 2030 portion we care about the most in this context as it denotes the build number.
A pre-release version would report something to the effect of:
Windows Home Server Console: 6.0.1771.0
Windows Home Server Backup & Restore: 6.0.1771.0
Windows Home Server Drive Extender: 6.0.1771.0
Windows Home Server Remote Access: 6.0.1771.0
Windows Home Server Storage Manager: 6.0.1771.0
Or visually:
The build number of the final version of Power Pack 1 is 1800... so we'll need to remove 1771 before we install it.
How do we uninstall it?
- Log into your Windows Home Server with Remote Desktop
- Click on the Start button and navigate to Control Panel -> Add or Remove Programs
- Make sure that the Show updates check box is checked
- Locate and click on the entry PRERELEASE Windows Home Server Power Pack 1(KB944298):
- Press it's Remove button
- Click the Next button to begin the removal
- Accept any prompts confirming removal
- Wait for removal to complete
- Click Finish button to restart server
If you are dealing with a pre-release version of Power Pack 2, follow the above instructions for it instead.
Once the pre-release version has been removed, the built in update mechanism can be used to update the box, either by waiting for Windows Update to do it on it's own, or manually.
In the above example, after rebooting th0 box the server identifies itself with the following versions:
Windows Home Server Console: 6.0.1500.6
Windows Home Server Backup & Restore: 6.0.1500.6
Windows Home Server Drive Extender: 6.0.1500.6
Windows Home Server Remote Access: 6.0.1500.6
Windows Home Server Storage Manager: 6.0.1500.6
And visually:
Now we can go back to the General settings tab and click the Update Now button to begin installing Power Pack 1:
Unfortunately you can't directly upgrade from build 1500 (RTM build) to 2030 (Power Pack 2), instead you must first upgrade to Power Pack 1, and then you can go to Power Pack 2.
For those curious as to which version numbers correspond with various releases, take a look at this excellent wiki entry on MediaSmartServer.net.
Wrapping it up
If you are one of those users willing to run beta software, it's important that you know just which build you are running and remember to remove it when the final version comes out... even if you are more than happy with the beta version.
Granted there may be functionality in that old version that is preferred over the final one, sticking with the pre-release software can be risky as it almost certainly contains bugs that have since been fixed, but also may limit your ability to receive future Windows Home Server updates.
Editors Note: No actual Home Servers were harmed in the production of this blog post
Pssst, I've got a not so little secret for you.
No, it's not that the English version of Power Pack 2 went live on Windows Update yesterday.
It's not even that Windows Home Server has at long last reached MSDN and TechNet.
What could be bigger than either of those?
How about the fact that there are quite a few new APIs in Power Pack 2, things that are easy to miss if you aren't in the habit of examining every single new binary that comes as part of a QFE or Power Pack or scouring the Windows Home Server SDK portal for changes (though I am a fan of both).
These new APIs ultimately come in two flavors... some changes are things that have been shipping as part of previous QFE's for quite a few months, while others are things that are new in Power Pack 2... in either case all are now officially documented on MSDN.
What are they?
Microsoft.HomeServer.SDK.Interop.v1.dll
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!
HomeServerExt.dll
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.
While many of the first set of APIs will likely be very useful to 3rd party developers, these last bits were added primarily with OEMs in mind who desired a way to be able to easily guide a user through setting up of their new Windows Home Server.
Add-in EULAs
For an add-in to be installed via the Windows Home Server Console it must support 'silent' installation which prevents it from using the normal MSI mechanisms for popping a EULA in the face of a user and recurring their consent before continuing.
For companies targeting Windows Home Server with products that required a EULA, they would often require that the user log into their server with Remote Desktop and manually kick off a normal MSI. This work around works, but isn't the best user experience and as a result we had some OEMs and others asking for some ability to pop a EULA at install time.
With Power Pack 2 installed, a developer or company can include a EULA with their installer and when the user goes to install it via the console, they will be prompted for their agreement:
What does it take for a developer to use this?
Assuming that you have an add-in named... MyAddin.msi located in the \\servername\Software\Add-Ins\ directory, then a developer need only include a file named MyAddin.rtf as well, and if this file is present then we will pop the EULA dialog, if not things will work as they previously have.
Have you looked on Windows Update lately? No? You should... at least if you are a running an English version of Windows Home Server.
Why so? This morning we just released Power Pack 2 to Windows Update!
What do you need to get it? Just make sure automatic updates are enabled and you'll get it automatically tonight, otherwise you can manually run Windows Update from the console and after a reboot you'll have installed and ready:
No... Power Pack 2 does not include Windows Media Center... but with this update, computers that are running Windows Media Center can now connect to your home server to save and play content that is stored in shared folders!
For more details on what Power Pack 2 includes, see the release notes, the main Windows Home Server blog as well on We Got Served, MSWHS, MediaSmartServer.net and countless other sites.
Enjoy!
Commenter JohnCz recently suggested:
Perhaps one day we'll see WHS OEMs offer a free netbook with WHS purchase. Or perhaps a WHS bundled with an extender is on the horizon.
While I can’t say when or if either will happen (partially due to pesky little NDAs, but mostly because I don’t know), it should be noted that from a marketing perspective something similar is already happening. Recently our friends at Acer recently launched the Acer easyStore H340 in Japan and as part of their retail strategy there are selling it alongside one of their netbook models:
Here’s hoping we’ll see similar display setups if/when the H340 comes stateside.
An often asked question by some of the more advanced users of Windows Home Server has been "Why doesn't it include built in support for hosting my own email on it?"
The are two primary reasons, the most important being the fact that most users simply didn't want it.
Back in 2004 or so when the skunkworks project that eventually became Windows Home Server first was getting rolling, various studies were performed to best understand what users really wanted and expected from a Home Server.
Of those users with broadband internet connections (the target market for Windows Home Server) 86% were already "very satisfied" with their existing email which is pretty significant considering that when you broke down what services respondents were using, about ~50% of those using their provided ISP account, while another ~50% another uses one of the major web mail providers (Hotmail, Gmail, etc). Note that these two groups are not mutually exclusive as there company email and existing vanity domain based email and there still exists plenty of room for overlap.
Back then For those who want email on their own vanity domain one would have to contract with a company for web hosting and get the email included or use a straight email provider, both of which would likely cost them a few bucks per month. If they wanted a more advanced mail server (like Exchange) they would likely pay significantly more.
Now though, with services like Windows Live Admin Center (formerly known as Windows Live Custom Domains)... you can use Hotmail and all of the spam fighting and organizational tools it provides for free as the back-end for your own custom domain, all you have to do is provide the domain name and an MX record... which is a good thing if your home network ever goes down.
Practically speaking... consider this hypothetical case:
Imagine you have a house/apartment fire and on your way out, after making sure the kids and spouse are out the door ahead of you, and that the dog and cat are safe, you stop to grab your Windows Home Server knowing that even if the desktops and laptops go, you'll have all of the files and backups you need... what then?
Even if your home isn't a complete loss, you may not be able to setup your email serving Windows Home Server there again right away due to the possibility of water damage or electrical issues. Where do you run your server in the mean time? The in laws house? The hotel room? Tethered to your cell phone?
These are the kinds of issues that the average data center and/or enterprise has to think about in order to provide a given level of reliability and is not something a Home Server owner, even an advanced one should have to think about to ensure that they can keep sending and receiving email.
This is part of why the Azure Services Platform and related Live Services are so interesting to watch as time goes on as it simplifies so much of the complexity behind having multiple data center class reliability and availability and while there certainly are aspects of a product like Windows Home Server that could take advantage of 'cloud services', it is unlikely that that it will ever be fully replaced by such a platform.
Lets face it, services like Live Mesh is great... but it *only* gives you 5 gigs in the cloud for free. Why be limited to 5 gigs when I can have 5 TB on my Home Server for just a few dollars more and possibly replicate a subset of those files (my most important ones) to the cloud?
Above I said there were two reasons... the second is that there is already a Microsoft server product which is almost as easy to use as Windows Home Server and provides email... it's called Windows Small Business Server 2008 which not only has email through Exchange, but SharePoint, Forefront, SQL Server, WSUS and far far more and is intended those customers and businesses who want the kind of on premises services like email, which as I said is less the case with Windows Home Server users.
Sure SBS 2008, it doesn't do everything Windows Home Server can... sometimes though two boxes/products/services/etc are required instead of one, just as we've seen with Windows Home Server's 10 PC and 10 user limit.
One of the major advantages Windows Home Server has over much of it’s competition (external hard drives, generic network attached storage devices, secondary PCs) is that it’s a full Windows Server under the hood and comes along with the ability to host almost any sort of web page or application you care to deploy to it, including those based on ASP.NET.
With your server hosting all of your content at https://smithfamily.homeserver.com, there exists the need to control access, something Windows Home Server does on it's own through it's remote access web site which uses the underlying Windows accounts. 3rd party developers can leverage Windows or Forms based authentication in their own web applications... however in doing so they are normally responsible for handling authentication... did you know developers you can use the same login page that already ships on Windows Home Server in their own applications?
Why so? The authentication system built in to ASP.NET can be used to offload some of the work of determining if a user is authenticated and what to do with them if they are not (amongst many other things)... these settings, like most other ASP.NET settings in the web.config file within a web application's directory and when the correct sections of config are copied between applications, single sign-on is the result.
Before we go any further, if you do not already know how to use Forms based authentication in ASP.NET I would highly suggest taking a quick read of what it can do for you and how.
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"?>
<configuration>
<system.web>
<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"/>
</authentication>
<authorization>
<deny users="?"/>
<allow users="*"/>
</authorization>
<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"/>
</system.web>
</configuration>
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.
The authentication key specifies not only what kind of authentication to use (forms), but what the name of the resulting authentication cookie will be (RemotePortalAuth) and where to send browsers who are not authenticated (login.aspx) while the machineKey defines the encryption keys to use
Before hitting save on my updated web.config file, I will need to tweak it slightly, changing the loginUrl property to point to the logon page that exists in a directory different than where the new web app is running:
<machineKey validationKey="<key removed for length>"
decryptionKey="<key removed for length>"
validation="SHA1" decryption="AES" />
<authentication mode="Forms">
<forms name="RemotePortalAuth" loginUrl="../remote/logon.aspx" protection="All" path="/" timeout="12000" requireSSL="false"/>
</authentication>
What I described above is the manual process behind such a process, it would be the responsibility of an installer of a web site to open the existing web.config file, grab the needed bits and insert it into it's own web.config, which given only involves a bit of xml can be a simple process.
What does this give us? If I installed a web application that lives in the virtual directory SingleSignOnExample on my Home Server and navigated to:
https://smithfamily.homeserver.com/SingleSignOnExample/Default.aspx
Unless I was already logged into the remote access web page, I'd be automatically redirected to:
https://smithfamily.homeserver.com/remote/logon.aspx?ReturnUrl=%2fSingleSignOnExample%2fDefault.aspx
Which would allow me to login with my existing credentials, and then be redirected back to the original URL:
https://smithfamily.homeserver.com/SingleSignOnExample/Default.aspx
After this is all said and done, it may be good to have ones installer also edit the server's websites.xml file to advertise the new web application to existing users of the remote access web site.
What follows is probably common knowledge, however given the fact that I didn’t learn either until after joining Microsoft I feel I need to share the wonders of local drive sharing in Remote Desktop for the one or two folks who do not yet know.
Take your normal XP, 2003, Vista, Windows 7 Remote Desktop client:
(showing XP as an example)
Click on the Options button and then select the Local Resources Tab:
Next click the More button under Local devices and resources, then expand the Drives list:
The above allows you to share local (or locally mapped) drives to the PC you are going to connect to with full read/write access.
If I enable all of the drives... when I login to my Windows Home Server machine I’ll see something like this in My Computer:
(note in the above only C & D are physical drives, the rest are mapped network drives)
So I have access to the drives via My Computer and that’s neat... but it gets better, there exists a virtual computer named tsclient that contains all of the above folders, folders that I can use to map drives against:
Why is this useful? When testing new builds of something on a target PC, no longer do I need to first copy the new version to a temp location and then again to another location and then move to my RDP window and copy it again... I can do a single copy operation from the source location on my development PC.
More so if I have all of my coding work in a drive with an unusual letter that isn’t likely to exist on the target machine (say Q:), I can map the my \\tsclient\Q\ share back to Q: on the target machine... this way if when debugging, my debugger will more easily be able to find the sources based on what is contained in my symbols (they are already pointing to Q: aren’t they?).
Sure the above is probably common knowledge, but I didn’t learn it until over the summer, more shameful though was that I only accidently discovered (last week) that most recent versions of MSTSC allow you to do copy and paste file transfers.
I've seen a little talk here and there about just how much storage you can have in your Windows Home Server's storage pool... and an often tossed around number is 16TB... a limit and a number that is a bit of a myth. The actual number is more theoretical and much higher, and this despite this blog post from Windows Home Server product planner Todd Headrick who indicated that as of November 2008:
- The largest number of hard drives currently attached to a home server is 27, there are lots and lots of people with more than 10 hard drives attached to their home servers
- The largest amount of available disk space that we have seen (so far) is: 22.06 terabytes
- The largest amount of used disk space that we have seen (so far) is: 19.32 terabytes
Still not convinced? With the help of Hyper-V I created a Windows Home Server virtual machine (an unsupported, but useful for testing scenario) and added a few hard drives to it. How many? 16 x 2 terabyte drives (the largest Hyper-V UI supports creating):
But where does that 16TB number come from?
NTFS supports 2^32 - 1 clusters, coupled with the (default) 4k cluster size we use on Windows Home Server, the math comes out to 17,592,186,040,320 bytes... or a hair under 16 terabytes.
At first glance this possible limitation makes sense as Windows Home Server’s Drive Extender does make a whole bunch of disk volumes appear to be a single one... remember though that it does that magic not through making multiple NTFS volumes into one logical volume (as is the case with Windows spanned volumes), but by doing read/write redirection to the actual volume that the file or folder exists on.
So rest assured, if you do have enough large hard drives hard drives collecting dust, you can add them to your Windows Home Server and end up with a system that has more available storage than just 16 terabytes... provided the disks are large enough of course.
Granted it'll probably be a little while before very many people see that for themselves, but before that there are two practical limits that will be hit first.
(For more information on Drive Extender, please see the Windows Home Server Technical Brief for Drive Extender)
MBR & 2 TiB
Since the dawn of the IBM-PC and the PC-BIOS, PC disks, both hard and soft have used the Master Boot Record format to define the partitions of the disk, and like so many things defined long ago and served us well, they are no longer adequate for some of the systems we see today.
MBR has a built in limit... 2^32 logical blocks × 512 bytes per block... 2,199,023,255,552 bytes... or 2 terabytes. This means that if tomorrow you happen to add a hypothetical 3 terabyte hard drive into your Windows Home Server, we will only be able to format and use the first 2 terabytes for you... not unlike the old ATA limit where only 28-bits were used for the sector number, resulting in a limit of 128 GiB, something that was later resolved in the ATA/ATAPI-6 spec which uses 48-bit logical block addressing.
What's the answer? GUID Partition Table is the new standard for laying out partition information on hard disks, and as time goes on will ultimately replace MBR on PC’s and servers... unfortunately today while Windows Server 2003 supports reading and writing from GPT formatted disks, Windows Home Server’s Drive Extender does not.
This is a limitation we are aware of and will be addressed sometime in the future, be it in a future minor update, Power Pack or new version of the product.
Fortunately for all involved, such hard drives are not on the market at present and likely will not be until the fall at least (my guess based on the time between the first 1.5’s hitting the market and the recent 2.0’s)
For note GPT increases the bits used to address logical blocks on the hard drive from 32 to 64, 2^64 x 512 = 9,444,732,965,739,290,427,392 bytes... or about 8 zettabytes.
Available IO
The average OEM built Windows Home Server comes with several SATA bays for easy addition of hard drives and can easily handle as many hard drives as there are physical plugs for, however it is easy to reach a point where as storage goes up, system performance goes down.
Ultimately Windows Home Server is dependant on what kind (and how much) of hardware it is used on and the more IO intensive devices you have plugged in and being utilized, the harder it is going to be for us to manage your files and for you to access them quickly, something that can easily happen with with the addition of eSATA and port multipliers, as well as USB hubs (up to 127 device per host controller) and Firewire daisy chaining (up to 63 devices per bus)... it is very possible to add a massive number of drives to PC or Windows Home Server to the point that the various buses will be so saturated with data that the end user experience is going to be less than optimal.
What does this have to do with hitting 16 TB? Imagine building your own 16TB system... in it you attach 8x 2TB drives, even when spread out amongst multiple buses, how likely is it that you will be able to access each of those drives at their optimal speed without interference from other drives in the system?
(On a side note, this does make me wonder... just how fast and massive a Windows Home Server’s storage pool could be if it used Fiber Channel)
At the end of the day it’s important to consider just how many different drives we want to plug into ones Home Server. Sure we can take a collection of old internal and external drives and plug em in to every available port we have. That will work, but may not offer the same performance as spending the money on a smaller number of larger capacity drives. Also having all of those external drives means there is a greater chance of one drive failing, though be it with 30 drives or 3... with Drive Extender and folder duplication, our files will still be protected.
...have been greatly... what’s that? There have been no rumors? In that case I may just have to start some.
Unfortunately I’ve been a wee bit silent since... September on this blog, and for that I apologize.
Between getting ready for PDC and a Live Mesh demo you may have heard about, WinHEC and an LCD demo you probably haven’t heard about (both of which I’ll talk about here soon) and other bits (vacation, holidays, product related work, etc)... time has been short.
That and the fact that I made a commitment to myself and to the community that there would be more interesting talk on this blog
I’m happy to say I’ve got a few posts queued up and a few other bloggable topics that need to be written up... so fear not, useful and/or informative content is on the way!
Here we are, 12 days into the month and it nearly slipped my mind. This month is Be Nice to a Recruiter Month!
A few years ago I opted to celebrate with a gift (sans resume).
This year I am celebrating with a referral of a friend who I think would make an excellent UX Researcher.
How are you celebrating?
As great as Windows Home Server is on its own... it's nothing without partners who take what we give them, create a full solution (hardware and software) and make it available directly to consumers while offering value above and beyond what we could put in the software box.
<Why does this blasted marketing hat keep jumping onto my head?>
On Wednesday and Thursday this week the Windows Home Server team played host to a number of partners who came to campus, learned about our product roadmap, had a deep dive into some of the nitty-gritty bits of Drive Extender, saw a couple of demos of things we were working on, and spent plenty of 1:1 time with members of the Windows Home Server to discuss how they might be better able to take advantage of the underlying platform as well as what we could do in future versions to make their solutions even more valuable and easier to build/market/support/etc.
In attendance were ISV, OEM, IHV and chipset partners both big and small, many with names that you know from the industry or the Windows Home Server community. Some who currently ship complete Windows Home Server solutions or add-ins... while others make possible existing solutions through their own hardware or software.
So to those who came, saw, listened and offered feedback... thank you!
The backup service built into Windows Home Server is designed for easy and efficient storage and recovery of files from multiple different PCs in the home as well as easy recovery. Because it does this job so well some have taken to using it as a longer term archiving solution so as to safeguard the last state of a PC before it was scrapped, never to be seen or booted from again.
While this is definitely an option, but it may not be an ideal one for all as there are a few areas that should be considered before relying on Windows Home Server for long term archiving within the backup database, areas including:
PC Limit – Windows Home Server is currently limited to backing up 10 PC's... even when some of those PC's are no longer actively being backed up and just are being stored for short/long term, this lowers the number of actual PC's that can be protected daily.
Legacy Support – If 5, 10 or even 20 years from now you were to attempt to read from the current backup database... how would you do so? The format of the database is at present not publicly documented and very well can change over time and so running/finding software that will be able to parse it in future may not be possible.
Retention Granularity – While it is easy to determine which files/folders/drives should be backed up... it is not so easy to specify after the fact which drives should be retained and which should not short of doing one final backup which only backs up the desired data.
<side note>Because Windows Home Server is such a consumer focused product, we are always listening to customer feedback (best given on Microsoft Connect) when it comes to what features and/or limitations exist (or do not exist) in the product (or environment) that prevent users from being able to use it best in their homes. If you have ideas, we want to hear them, especially right now on the subject of the 10 pc/user limit and alternative implementations.</side note>
Due to some of the above areas I recently found myself with a bit of a problem where my old desktop PC had 3 hard drives in it with a total space of over 800 gigabytes (about half of that being media that is now securely on my Home Server shares) had been regularly backed up to my home server for quite some time, that means that a significant chuck of my current 893 gigabyte backup database is data that is already safely elsewhere and a bit of trimming might be in order one day.
Given none of the above areas are likely to be resolved today or tomorrow other options should be considered... be it dragging just those files/drives I want to a folder somewhere, or perhaps one of the most obvious of booting up a whole new PC, doing a bare-metal restore to a HD (or set of HD's of just what you want) and then putting them on the shelf for a while.
Both of these options would certainly work... only they aren't the the best as the first doesn't allow me to retain all of the actual subtleties of the contents of the disk (boot data, user SIDs, NTFS junction points, etc) while the second is fairly inefficient when it comes to disk space.
One Solution
My solution to this problem was simple... to use Virtual PC 2007 to create a new virtual machine and virtual hard disk (VHD) of sufficient size, boot off of the Windows Home Server Recovery Disk (or disk image on the server) and restore which ever partition(s) I want to a virtual hard disk.
Best of all, as a VHD I have many different options for accessing the data in various ways as there are numerous tools out there that allow the reading/editing of them, in fact as part of the Open Specifications Promise (OSP) the Microsoft Virtual Hard Disk format is well documented allowing me to write my own later if I so wanted/needed... heck, Windows Server 2008 even comes with that support in the box!
What is needed
- Virtual PC 2007 (free)
- Virtual Server 2005 (free) or Windows Server 2008
- A Windows Home Server
- A desktop PC with plenty of ram and hard disk space
The process
- Install Virtual PC 2007
- Create a new virtual machine
- Create a virtual machine
- Specify name for virtual machine (default is fine)
- Specify operating system as Windows Vista (suggested as the recovery CD uses the Windows Vista version of Win PE)
- Use suggested amount of ram (512 MB)
- Create a new virtual disk
- Specify location for virtual disk and allocate sufficient space for restored image
Note 1: The space specified here will not immediately be used on the system, instead virtual hard disks grow in size up until the size specified here.
Note 2: Virtual hard disks created with Virtual PC 2007 are limited to 127 gigabytes in size, for archival backups involving larger drives/volumes it may be necessary to either use Virtual Server or Hyper-V (both of which support larger disks) or multiple VHDs
- Click Finish button to exist wizard
- If desired other 127 gigabyte disks can be created within the virtual machine and used
- Select new virtual machine in Virtual PC Console and click the Start button.
- Immediately after the Virtual Machine starts from the CD menu, select Capture ISO Image
- Specify the location of the Windows Home Server recovery image (likely located \\server\software\Home PC Restore CD\restorecd.iso) and click Open button
- Proceed through the normal restoration process:
- Specify server (if necessary)
- Login to Windows Home Server
- Select PC that will be restored from
- Select specific backup to be restored from
- Use disk management tool to partition virtual hard disk as desired
- Proceed through normal restore process
- Once the restoration is complete, allow the virtual machine to reboot and then turn off the virtual machine prior to it attempting to boot from the virtual hard disk for the first time.
At the end of this process you'll end up with a VHD which contains the same files and disk layout that is stored in your backup database, enabling you archive this image to a duplicated share on your home server, burn to DVD, store on an external hard drive or otherwise put in a safe place.
Now that we've got this giant file what can we do with it? Mount it!
Mounting
Ordinarily VHD files are only used with Virtual Machine software (Virtual PC, Virtual Server, Hyper-V, etc) but along with Virtual Server 2005 came an immensely useful tool called vhdmount which allows you to mount a VHD file as a local (potentially) read-only hard drive not unlike how Windows Home Server presents backups when doing a single file restore.
To install vhdmount:
- Download Virtual Server 2005
- Run the installer
- Disable all features other than VHD Mount
- Proceed though install
Once installed it's a simple matter of launching a command prompt (with Admin permissions under Vista or 2008), navigating to the location you installed Virtual Server (ex: C:\Program Files\Microsoft Virtual Server\) and proceed to the vhdmount directory and execute vhdmount.exe
vhdmount /m <path to vhd file>
Once mounted you should see a new disk in My Computer that you can read files from at will.
Once done with the disk unmounting it is just as simple:
vhdmount /u /d <path to vhd file>
It is important to make sure that during the unmount the /d flag is used as it causes any changes made to the VHD during the last mount to be discarded.
Other mounting options
With a couple of registry tweaks (used at your own risk) you can eliminate the need for working with the command line and simply be able to right click on VHD files to mount/unmount them at will.
It's also worth noting that Windows Server 2008 has support similar to vhdmount built in, enabling you to mount a VHD with Hyper-V.
Drawbacks
As good as even this option is... there are a few drawbacks that need to be considered:
Size - While the Windows Home Server backup service does a great job with only storing a single instance of individual file clusters between multiple backup sets and PCs... no such benefit is had with a VHD where the actual file size is roughly the same as all of its contents and multiple archive VHDs from either the same or different PCs will be quite large as there is mechanism (using the above procedure) to have one VHD only contain what another doesn't.
PC restoring - While both a PC backup as it sits in the Windows Home Server backup database or a VHD file can be dumped to a physical hard disk... the process of doing so with a VHD is far more complicated and no where near as easy as it is with Windows Home Server.
Reducing size
Just after you restore your first hard drive with this method you'll notice something... VHD files are big... really big. It's not that the format is wasteful, it's that they contain a whole heck of a lot of stuff! Various tools exist to try to reduce the overall size but even they can only reduce the size so far.
One not so quick but easy way to reduce the size even further is to take your favorite file compression application and use it to create a new archive containing the VHD... a task that can see huge size savings.
Example:
For my own little archiving project I took an 80 gig physical hard drive that was backed up to my server and restored it to a VHD which grew to 53.4 GB and after asking Virtual PC 2007 to try to shrink the disk... the size went down to 53.2 GB. Still thinking we could reduce the size a bit more I used the built in Windows Compressed (Zipped) Folder support to create a new zip file containing the VHD (ie right click, Send to -> Compressed (Zipped) Folder) and when it was all said and done 7.85 GB, ~14.7% of the original VHD size.
To some a zip file may not be the the most ideal container for a VHD as it does take a little while to compress/decompress such a large file for use, one must make the decision for themselves on the tradeoff of speed/disk size. How quickly do they really need to be able to read something from what is intended to be an archive?
Wrapping things up
Windows Home Server works great for routinely backing up home PCs and securing their contents, for longer term archiving the system is less than ideal for archiving as the entire back-end is a closed and not a publicly documented system. While backing up ones backup database from time to time can be done, pulling out just the drives we want to a more portable and open format using the existing built-in mechanisms provides for a lot more flexibility and security when archiving is the goal.
