You're wondering what happened with the bike ride from Los Angeles to San Diego after the PDC, aren't you? For two months now, you've been expecting to see photos of four tired but elated geeks riding into Union Station in San Diego. Or perhaps you were worried that we were struck by a car on I5, on the stretch where you were formerly able to ride through the US Army's Camp Pendleton. Fellow Microsoft Regional Director Tim Huckaby referred to this stretch as "the scariest place you'll ever ride". He's done it many times. In fact, we didn't make the journey at all. Shocked?
We wanted to go; really we did. I printed page after page of color maps, made hotel reservations, and planned the whole thing to the smallest detail. Unfortunately, Southern California's fire season conspired to make it impossible for us to make the trip. Listen, I don't want to complain or joke about those fires. I'm sure you heard about the conflagration?it was a huge disaster, affecting thousands of people. We were stolidly planning to head out on Thursday, and on Tuesday, fires were still raging throughout southern California. Smoke was thick?the air was somehow a visible presence?and ash was falling all over the place. (I got to my car one day to find it covered in what looked like snow. It was over 100°F outside?clearly, this wasn't snow.) We thought about it, and argued about it, and finally we were convinced that the fun of accomplishing this goal wasn't worth the health risks involved in breathing in tons of carcinogenic charred debris and particulate matter as we huffed and puffed our way down the coast. Contrary to what it looks like on a map, riding south doesn't mean riding downhill.
So, we didn't go. Instead, we thought it might be fun to install Windows Server 2003 on my Dell server box, which hadn't been touched, really, since installing Windows 2000 three years ago. The server had gotten awfully crusty, and I was looking forward to using some of the new features in WS2003. I had Richard Campbell (from Canada), Adam Cogan (from Australia), and Tom Howe (from Portland, OR) here for PDC helping out. They all stayed at my house (along with Andy Baron and Mary Chipman)?it was a veritable geek hostel. And believe it or not, it took all three of us several days and nights to get this thing working. (Thanks, guys?I really appreciate the time you took to rebuild my server that we could have spent having real fun. Never mind?I forgot?to geeks like us, rebuilding servers is fun!)
It's not that hard to install and configure Windows Server 2003. Anyone can do that. I wouldn't advise installing it on top of another operating system?I've never trusted operating system upgrades?but we saved all the original data, formatted the hard drive, and got the server and Exchange Server 2003 running without much effort.
The real problems occurred when we attempted to retrieve settings from the old server. We had carefully stored things like DNS settings, mailbox identities, and more, before we reformatted. When it came time to retrieve these settings from our saved locations, however, things got ugly. As far as we could tell, there was no easy way to reset the new DNS server to match the settings in the old one. Richard pulled up the saved settings, and manually re-entered them into the new server's applet. Recreating the same users (we didn't need to preserve the SIDs of the users, so there weren't any security issues) and rebuilding their mailboxes took another day?and I only had three or four mailboxes on the server! Finally, Tom spent the better part of a day tracking down every single warning and error in the event log, and some were quite tricky. (For example, if you have more than 1GB of memory in the machine, you have to add a command line option to BOOT.INI so that memory gets configured correctly. If you don't do that, things don't work right. How were we supposed to know that?)
We spent much of the three days involved in rebuilding this server trying to restore many of the original Windows 2000 Server's settings. (Yes, we could have avoided these issues by simply installing on top of Windows 2000 Server, but I'm convinced a good solid repave is required when building a server.) We whined (or whinged, if you're from Australia like Adam) the entire time, wondering why it's so hard for Microsoft to build applications so that they save settings in a humanly readable form, in a known location. Some applications store their settings in the registry, others in the Windows folder, and others in all sorts of alternate locations. A few well-behaved applications place XML files into folders beneath the Documents and Settings/ <UserName>/ Application Data folder. Of course, operating system-level settings should be stored in a different location, but wouldn't it be great if there was some hard and fast standard for this sort of thing?
And don't get me started on backing up and restoring user settings! After installing and massaging the new server installation, we found that I needed to unjoin the old domain, and join the new one. This action, of course, creates a new identity on the client machine, so I lost all my personal settings. Sure, there are ways to avoid this (you can store your profile on the server), but I hadn't done that ahead of time. I did try to use the File and Settings Transfer Wizard, but this only preserved a fraction of my personalized settings. It's a month later and I'm still fighting with my personal computers.
In a perfect world, you should be able to back up a single folder (such as the Application Data folder) and restore it on a new machine to have all your settings applied to the new installation. That's not even close to the way it works, but that's how it should work. If all applications were required to save their settings to this folder, life with Windows would be a lot simpler. When you write your own applications, you should consider saving your own settings in the Application Data folder, as opposed to writing them to the registry, or to some file within your application's directory structure.
There's really no excuse for not writing your configuration information to the Application Data folder?the .NET Framework makes this part really simple. The Application.LocalUserAppDataPath property returns the path for a user's application data, or the Application.UserAppDataPath property for roaming user profiles (I guess I could have saved myself some trouble had I been using a roaming profile so that the profile gets stored on the server, and then is downloaded to the local computer when I log in).
These properties return a path using the following construction:
Base Path\CompanyName\ProductName\ProductVersion
Base Path is generally something like this for a local profile:
C:\Documents and Settings\username\
Local Settings\Application Data
and like this for a roaming profile:
C:\Documents and Settings\username\
Application Data
Your application could retrieve the CompanyName, ProductName, and ProductVersion portions of the full path as individual properties of the Application object. You can set the values for these properties at design time by supplying attribute values in the AssemblyInfo.* file, using the AssemblyCompany, AssemblyProduct, and AssemblyVersion attributes.
For example, if your AssemblyInfo.cs file looked like this (you can use the same data in an AssemblyInfo.vb file):
[assembly: AssemblyTitle("My Sample Application")]
[assembly: AssemblyDescription("")]
[assembly: AssemblyConfiguration("")]
[assembly: AssemblyCompany("MCW Technologies")]
[assembly: AssemblyProduct("SampleApp")]
[assembly: AssemblyCopyright("")]
[assembly: AssemblyTrademark("")]
[assembly: AssemblyCulture("")]
[assembly: AssemblyVersion("2.1.4.776")]
then the results of retrieving the Application.UserAppDataPath property might look like this:
C:\Documents and Settings\KenG\Application Data\
MCW Technologies\SampleApp\2.1.4.776
Place your configuration data in the folder retrieved by the Application.UserAppDataPath property and you won't have to worry about developers cursing your application when they can't back up and restore your configuration settings. If you really want to make friends, store your settings in a human readable format if possible?XML makes a perfect format to store your settings.
Next time you write an application, think of Richard, Tom, Adam, and me?you don't want us cursing your app as we attempt to back up and restore settings the next time we rebuild my server. Actually, my guess is that next time we get together, we won't waste time rebuilding servers?we'll actually do the bike ride we originally planned. I still have the color map printouts ready to go. I just need to figure out how to survive ten miles on Interstate 5?the scariest place I'll ever ride.
