How do you build Add-ins? Awfully hard for me to say. That's kind of like asking how you should build a Windows application. Oh, wait, it's exactly like asking how you should build a Windows application.

However, I can provide some general guidelines for developing Windows Home Server Add-ins:

• Call them Add-ins. That's what we call them.
• If your code currently installs and runs on Windows Server 2003 it will probably install and run on Widows Home Server.
• If your code currently installs and runs on Windows XP or Windows Vista, but does NOT currently install and run on Windows Server 2003 you'll probably have 3 general areas to work on:
• Your installer. Check if you are running on Windows Home Server version information using GetVersionEx() and looking for VER_SUITE_WH_SERVER. Also understand the Add-in manager and to craft MSI file that work with it.
• Your code as a service. There's no desktop session you can run under on Windows Home Server. Your long running code must be installed as service using the standard Windows service APIs (or it can run under the context of IIS of course).
• Testing against Windows Home Server. There are differences in the Windows API between Windows XP, Windows Vista, and Windows Server 2003. They are relatively minor, but they do crop up and the best way to identify these is to make sure you do a full test pass.
• If you are developing something new, don't get hung up on the fact that Windows Home Server is still in beta and our SDK might change slightly before we ship. Just get started solving the really hard problems on your dev machine. All the really important APIs and services are all there (repeat to yourself "Under the covers it's practically W2K3").
• The Home Server Console is designed to be an infrequently used application. It is intended to be used by one individual in the household (whoever the sucker was who signed up for helping everyone else) for infrequent configuration tasks. We call this person Jeff (we used to call him Peter but for reasons I will not get into here we had to change...don't ask).  It would be a mistake to implement UI in the admin console that you expect Jeff's family members to access.  Instead, build client-side UI for them.
• Be seriously thoughtful about the implications your design and code can have on security. We have worked very hard to ensure that Windows Home Server is secure by default. You need to do the same thing.
• Use the Windows Home Server forums to share your experiences and to get assistance.

What should you build? I can't really answer that directly. But I can tell you to think generally about it using the generic definition of home server:

"A home server is an always available smart node on the home network dedicated to providing services to other nodes on the home network and the Internet."

Relative to this, Windows Home Server provides you with:

• A stable platform for services in the house that need to be "always available".
• A built-in set of enterprise-class infrastructure services such as IIS.
• A rich, well documented, and widely used API (the Windows API) for building Add-ins.
• A broad ecosystem of already existing tools and technologies that can help you build Add-ins (e.g. everything ranging from PowerShell, to Visual Studio Express, to Ruby on Rails).

Beyond that, I'm confident the community will have no trouble suggesting actual problems to solve and solutions to create. In fact over on http://www.onemanshouting.com/, Rick has a nice post on this. Dan Fernandez blogged about it a while ago, and I'm sure he'll post something new now that the SDK is out. And if you are still out of ideas, check out the suggestions section of the Windows Home Server forum.

So what are you waiting for? Go bang out some code already!

-cek

Today we are announcing the availability of the Windows Home Server SDK. You can access it here.

As I stated in my Channel 9 video interview (and in this post) in January, enabling developers to build on Windows Home Server is an important goal for us. We include all sorts of developers in our definition, including pros doing it to make a living, hobbyists doing it for others just for the gratification, and makers who just do it for themselves.

I personally have fit into all three categories. I obviously build software professionally here at Microsoft (although my team would laugh if I were to suggest that I actually write code anymore), but I did write software professionally in the past. Over the years, I've built many freeware and shareware packages for things relating to making printing easier in Windows, to integrating Windows Media Center Edition into an all-house control system.  I'm constantly dinking with hardware & software projects that are useful (or not) only to me. My office and workshop are littered with evidence of this, much to my family's chagrin.

My first 9 years at Microsoft was spent focused on developers. I started as a support engineer supporting the Windows 2x and 3.0 SDKs and DDKs. I was a developer evangelist. I designed and explained and got all religious about COM, OLE, and ActiveX. And so on. Made some mistakes. Learned a ton. So I get it.

Which is why I pushed so hard from day one that one of the fundamental tenets of Windows Home Server was it would be a platform for developers to build on.

In software development (there goes Charlie pretending he's Joel on Software again) there tend to be widely held beliefs, or truisms. I've written about some of them before here. One truism is when building a v1 product you have to decide between being a platform and a solution. You can't focus on both and be successful. I almost completely believe that.

The original vision document for Windows Home Server (back when the project was codenamed Quattro) made the following statement:

"Quattro" is not a platform. We are a solution. That said, there will be areas where 3^rd party extensibility will be important and where we will do specific things to enable 3^rd parties. This will likely be limited to our administration Ux.

Beyond that we will rely on the broad platform that Windows provides beneath our solution.

This told the team what to focus on: Build a solution for the problems our end-user customers have, do a few things to make sure the most important extensibility points are addressed, and let 3rd parties innovate deeply by using the rich, underlying Windows platform.

But, the reality is, 99% of what developers want to build on top of Windows Home Server will be done using the rest of the MSDN documentation. Our little set of APIs let you integrate your Add-in into the Home Server Console and interact with some of the elements behind the solutions we provide. But all the interesting work that great Windows Home Server Add-ins will do will be done using the standard "Windows API".

I'll post more later on using the SDK and building Add-ins...

[EDIT: For those of you direct linking here, I've posted a follow up here...]

-cek

The basic premise for troubleshooting your broadband modem and other home networking equipment often comes with the advice from your broadband provider to "turn it off, wait 60 seconds, and then turn it back on".  I have fielded calls from family members and friends asking me what to do because "...the internet is down".  I remember back to the original IBM PCs with the big red power switch on the back, and when something went wrong people would shout out - "hit the BFRS"  (Big "fine" Red Switch).

A few months back I implemented a rather simple solution for the "internet is down" calls that I get from time to time.  Get a power strip, plug the power block for your broadband modem and router/firewall device into this power strip - do not plug anything else into the power strip.  Now when I get the call, I simply tell them to turn off the power to this power strip, wait 60 seconds and then turn in back on.  If the power strip has a red power switch, then you can say "BFRS it".  This is a lot simpler than saying "unplug the power to the broadband modem, unplug the power to the firewall, ... " - and worrying that they plug the correct power plug back into the correct device.

Troubleshooting is 1/2 art and 1/2 science - if you are a scientist, you can argue about this ratio.  Finding simple solutions to complex problems is often times a wonderful feeling.   While turning the power off isn't considered ideal, it has worked 5 times in a row for "turning the internet back on". 

t.