That was disturbing enough in itself. When the system came back up, it helpfully asked me to type in “Why did the system shut down unexpectedly?” and I enthusiastically typed in “Fuck if I know you jackass.” Then, I headed straight for the event log.

The event log was full of terrifying messages such as

The system failed to flush data to the transaction log. Corruption may occur.

or

An error was detected on device \Device\Harddisk1\DR2  during a paging operation.

Hmm. There was no blue screen, no bug check, no minidump. It was as if the power had been cut.

I looked accusingly at the UPS since I have had problems with bad UPSs interrupting the power supply in the past. I held down its self-test button, it made that satisfying buzzing noise, and … everything stayed up.

But while crouched down next to the UPS, I heard an odd swishing noise, like a tiny man was running his finger across a sheet of Saran Wrap. Then I noticed that the external Western Digital hard drive that we use for SBS 2008 backup was doing its swooshing-lights mode, not its solid-lights mode, and I knew from previous experience that it only did that when it was starting up or shutting down.

I had a hunch–in SBS 2008, backup uses Volume Shadow Copy, and I had seen similar disk errors when another of our external hard drives cooked itself (though instead of rebooting, that server became unresponsive). I unplugged the external drive and the event log messages stopped.

I then promptly threw the external hard drive into the trash, drove straight to Best Buy and bought a new external hard drive with the company credit card. (Aside: Why do 90% of external hard drives come with craptastic backup software or “one-touch” buttons? I just want a drive in a box. I finally found one in the “Seagate Expansion” line.)

Then I plugged in the new external hard drive and re-ran the “Configure server backup” wizard from the SBS 2008 console. I unchecked the old, now non-existent drive, checked the new one, and off it went. And all seems happy now. (I ran chkdsk for good measure on the system and data drives and they checked out OK, so it does all seem related to the external backup drive cooking itself.)

Should it be capable of handling faulty backup hardware more gracefully? Sure. And I wish that SBS 2008 had the option to use the old ntbackup utility because then at least you could backup to network-attached storage. It’s been my experience that external hard drives really are not that reliable and have an average lifespan of only about two years, but maybe I have just been glaring at them the wrong way.

FedEx ZP 500

The FedEx ZP 500 is a bit of a white elephant in that Zebra doesn’t mention it on their Web site; it’s some sort of special contract job with FedEx to produce and jointly brand these devices. It’s probably just a re-branded version of the Zebra GK420d, but in reality we have the printer manufacturer pretending that they don’t make the printer (e.g., “call FedEx for support”) and a shipping company who has no idea how to support the printer (e.g., “call Zebra for the printer driver”). But I’m getting distracted.

The real issue was that the shipping desk is running Windows XP and shares the printer via the native Windows printer sharing mechanism so that it’s listed in the Active Directory. I do this so that I can run integration tests from the workstation in my office and test the label generation functions of our software without needing to have a thermal label printer hooked up to my workstation solely for this purpose. These printers aren’t cheap, you know.

New operating system, new drivers required

I recently upgraded my workstation to Windows 7. When I tried to add the shared FedEx thermal printer, I was greeted with error code 0x00000007a along with an error message that generally amounted to “something didn’t work.” I suspected a driver problem since Vista is when Microsoft locked down on the mandate that printer drivers run in user mode, not kernel mode–which is a good thing in terms of system stability, since a poorly-written printer driver can no longer trigger a BSOD and a reboot, but a bad thing in terms of backwards compatibility.

The problem is that

• the Windows XP machine is offering the Windows XP drivers to my Windows 7 install;
• the Windows 7 printer wizard doesn’t give me a chance to supply my own printer drivers, and instead happily installs the XP ones, which don’t work;
• the FedEx-supplied Vista drivers are mutually exclusive in terms of compatibility with the XP drivers, so I can’t install them on the XP machine via the Server Properties thingie; and
• even if I could do that, I am hesitant to dick around with the printer drivers on a critical machine.

Adding the printer

The solution was to add a printer in a different, counter-intuitive way. Here’s what I did:

1. From the Windows 7 Control Panel, I went to “View devices and printers” and then “Add a printer”.
2. When asked “What type of printer do you want to install?” I chose Add a local printer, even though I know full damn well that I’m not actually adding a local printer.
3. For “Choose a printer port,” I chose “Create a new port” with “Type of port” set to “Local Port”.
4. In the “Enter a port name” dialog, I entered the UNC share name for the printer, which looks like \\{MACHINE-NAME}\{PRINTER-SHARE-NAME}. In my case, it was \\ASHWHWS003\FedEx ZP 500 Plus.
5. When asked for a driver, I chose “Have Disk” and navigated to the *.inf file in the ZD directory of the Zebra Designer drivers available from the FedEx Web site.

This allowed me to use locally-available printer drivers on a printer attached to another machine. Good luck!

We happen to like our system

So we’ve branched out and offered fulfillment services to other merchants, as I’ve mentioned before. Essentially, other e-commerce stores or merchants can store their items in our warehouse and then transmit orders as “fulfillment requests” to us. We either ship the request or mark it as invalid with a little message (“item has insufficient stock, delivery point validation failed, tax identification number required, etc.”). If they want to re-attempt, then they re-submit an entirely new fulfillment request.

This simple model has worked surprisingly well: the system doesn’t track “orders” (since each merchant handles backordering and cancellations differently), and while it does maintain an inventory log, it doesn’t track the cost of goods in inventory or anything like that, since that is not necessary for us to do our job. (Instead, it tracks a whole boatload of other information that people don’t normally think about, like HS codes or unit weight.)

Some of our merchants need some hand-holding

We have an API so merchants can integrate with our system. And so I’ve written a few plug-ins for Magento and osCommerce that auto-transmit their orders as fulfillment requests, sync outbound shipments back, and deduct inventory from their systems (since we are the authoritative inventory count). This works great for their retail businesses.

We have a merchant that we’ve been doing retail business with for some time who now wants to do wholesale stuff with us. He wants a sales order/invoicing/inventory management solution, and it needs to be able to track multiple inventories across multiple warehouses (our integration, if any, would only be adjusting inventory for a particular warehouse). He wants to enter sales orders remotely, press a button that shows him how much is ordered so he knows how much to make, have that manufactured and sent to us, click another button to transmit the sales order as a fulfillment request to us once it’s in stock, and then have us sync back with the shipment info, creating an invoice.

“Shouldn’t they have had these features prior to switching to you guys?” you ask. Well, yes. In this case, all of these features were provided in an all-in-one system provided by their previous fulfillment warehouse. They have since learned their lesson about keeping all of their data in the hands of a third party because when that relationship went south, so did their access to their own data.

We would rather not add these features to our system. Since all merchants have different ways of handling backorders, pre-orders, cancellations, cost of goods sold (FIFO, LIFO, average, priority), we’ve been maintaining the position that–unlike our competitors–our system is essentially feature complete, since it’s ours and does what we need it to do to ship things out. The features that I’ve mentioned should be things that the merchants are keeping track of themselves–since that’s their business–and integrate with our system via the programming API. While an argument could be made that our system would be abso-freaking-fantastic for merchants who need an all-in-one software and data solution (yes, it certainly would), the reality is that our competitors have an outsourced team of software developers, and we are a small business working in an area that is tangential to our core business as a result of the “new economy” that has a software development team of just one person (me) and can’t even begin to dream of hiring any more until we start seeing some serious cash flow.

In any case, to land this deal, we need to find a system for this merchant, and fast, because there are some important trade shows coming up.

Welcome to marketing Hell

Now for the rant, because you would think that these requirements are not exotic:

• Let salespeople enter sales orders remotely.
• Keep track of inventory in multiple locations, and track the cost of inventory.
• Provide integration hooks so the user can send orders to the warehouse and so the warehouse can send shipment data back.
• Keep track of sales-order-to-invoice conversions and payments.
• Provide reporting features.

QuickBooks 2010: Same as last year! Now with more shininess!

You might take a look at integrating with QuickBooks, but you’d realize that once you’ve penetrated the marketing speak that the software in 2010 is essentially no different in terms of fundamental feature set as it was in 2006, and that it doesn’t support inventory in multiple locations and doesn’t scale well. In fact, QuickBooks performance once you start approaching 10,000 SKUs is so bad that they sell an “enterprise” version that essentially–aside from some fine-grained access permissions–has no added features other than the feature of not crashing when dealing with large lists of information.

We could pay another couple of thousand dollars for Fishbowl inventory, which would add multiple location support to Quickbooks, but then we’d have created a Rube Goldberg machine straight out of the gate, with me synchronizing with Fishbowl which is then synchronizing with Quickbooks. I’m sure nothing would go wrong there. That would be insane; we might as well just stick a few fax machines into the sync process and call it an insurance company.

A gap in the market

The reality is that there is a huge gap in the marketplace between merchants who are moving $200k or less per year–just use commercial off-the-shelf (COTS) QuickBooks, you can do most things manually and use your e-commerce system’s native order management functions–and merchants who are moving $5m or more–just use SAP or some other enterprisey software. If you’re in between, like we are and like the merchant that I’m researching for is, the options available to you are not pretty.

I’m not sure why this is. All I can think of is that perhaps companies historically did not spend much time in this space–they either stayed small or had venture capital to acquire the big boy systems and grow quickly. People aren’t exactly lending money anymore, so I suspect that this is a segment that is only going to grow.

If you try to look for COTS software in this segment, you’ll never find the feature matrix that you need:

• inFlow Inventory is pretty, but offers no integration features, as if an entire business could be run out of one app, and doesn’t offer Web access.
• WorkingPoint is Web-based but doesn’t offer inventory tracking in multiple locations or an integration API.
• QuickBooks has a Web-based extension that lets QuickBooks understand multiple inventories but costs thousands of dollars, assumes that the company owns its own warehouse (that is, needing picking/packing/shipping capabilities), and still does the same style of synchronization as Fishbowl does. You’d think Intuit would just add the @#$#@ feature to QuickBooks itself!

No COTS to sleep in

The market seems to have determined that people in this segment have outgrown COTS software and need some consulting help. So any Web sites that advertise products will be full of pages and pages of impenetrable marketing bullshit that use obnoxious acronyms like ERP, CRM, MRP, and WMS, promise the moon, and coyly make no reference to pricing or contract requirements so you can’t even tell if you’re dealing with the right league of product, when the reality is at the end of the day you could look at two or three screenshots and the SDK’s API and immediately tell if the product fit your needs.

Instead, I notice a disturbing trend of “pretty Web site, crap product,” such as Sage’s Simply Accounting, which certainly appears to have an impressive array of features but in reality doesn’t even know the difference between a sales order and an invoice. You can try going to Microsoft’s Dynamics site, but good luck figuring out what the difference between Dynamics AX, Dynamics CRM, Dynamics NAV, and Dynamics GP are: you’ll be told to contact your “Microsoft Dynamics solutions representative” for help. At that point, you’re thinking “Microsoft solutions representative? Who said I committed to Microsoft?! I’m just trying to figure out what in the blue hell your product even does.”

If you do find a vendor that maybe sorta-kinda-hard-to-tell meets your solutions, then you can expect days of scheduling WebEx teleconferences and meetings and run-around with your “account rep” so that they can determine how much you’re worth and willing to pay so that they can charge you a completely different amount than what they charged Bob next door for the same services and bits. Trying to extract “$X/user” and “the login starts working on MM/DD/YYYY” and “the developer get a demo account so if you can know if this is feasible” answers from these people seems to require a hammer in one hand and their genitals in the other. We both know that to add a new account, they’re pressing a button that says “they really bought into that ‘enterprise’ crap” and poof! a new account is created. Let’s quit pretending that the world’s carbon footprint has increased ten-fold by us merely asking to be on the platform.

Trying to extract technical capabilities from these salespeople is nigh-impossible either. I think part of the problem is that they seem to actually believe that the features that they are promising really exist, when in reality I just need them to show me what the data dictionary looks like and how the session needs to be handled and then I can tell for myself whether or not my scenario is actually supported. Instead? I’m waiting on a “discovery session” teleconference with an “engineer” tomorrow.

Conclusions and Delusions

It has to be easier than this. No wonder there are so many not-invented-here software solutions in the world today–custom crap that barely works at home may yet indeed be better than generic crap that you have to waste hundreds of dollars on in productivity time and research before you even get it in your hands and realize that it is also crap, just with a maintenance contract.

If it takes a consultant to help people decide what software to buy, or which of your products is right for them, or whether or not your product even applies to their problem domain, then your marketing simply does not work.

Yes, it epitomizes Battleship Grey. You love it.

But, behind the scenes, it’s not quite as simple as all of that. It’s aggregating order data from heterogeneous data sources–some in our legacy database, some in our new fulfillment system, some in a custom integration with a third party. It has to figure out which postage account to pay for postage with or which FedEx account number to use to ship a package. For orders that aren’t coming from our new fulfillment system, it has to “cleanse” the address against the current USPS address database. It has to figure out the cheapest way to ship a package, compute customs values correctly, generate certificates of origin and commercial invoices for international shipments, and determine what box types an order is allowed to be packed in. And it has to write shipment information back to one of those three disparate data sources.

What this means is that I’m frequently making adjustments and bug fixes to the application. And managing the deployment and installation of those bug fixes had been, up until now, a pain.

A brief interlude on ClickOnce

The other internal application that we use (“Undies Client”) for our long-time running e-commerce store is deployed via ClickOnce, which is essentially the Java Web Start of the .NET world.

While ClickOnce is a neat technology and has its applications, to be sure, I probably wouldn’t use it again on Undies Client if I were starting that application over today, just as I decided not to use it for the Fulfillment Manager (which is an effort to divorce the processing and shipping features from Undies Client and make them simpler and applicable to multiple e-commerce stores).

First, there’s user confusion. If I deploy a Windows Installer MSI via Group Policy, then the application is magically there on all computers in the office. But for Undies Client, you have to go to a special Web page and click on a link. With ClickOnce, the installation happens per user, so employees can get confused if they go to another computer one day, log into their account, and see that the app isn’t there (“but Jennifer runs it on this computer so I thought it was already installed”).

Second, there’s deployment headaches. Like Java Web Start, you get a retarded warning if the deployment manifest wasn’t signed with an expensive code signing certificate. To mitigate that, you either buy one or start diddling with the self-signing certificate capability within the context of your own Active Directory domain. Not a show-stopper, and it makes sense, I guess, but it’s One More Thing that you have to deal with.

Third, when that certificate expires and needs to be renewed, you’re in for a world of hurt, because essentially all users will need to uninstall and re-visit the Web site download link and reinstall. Otherwise, the application simply stops seeing the newer updated versions and doesn’t update itself.

Fourth, the distribution of your app now has a dependency on an IIS installation somewhere, so that’s something else to maintain–both the configuration of that virtual directory in IIS as well as the shared drive to which Visual Studio dumps its files when clicking the “Publish” button.

Fifth, the installation can’t do much. Until recently, you couldn’t even create an icon on the desktop as part of the installation process. Nor can you do anything that would require elevated permissions for actions that you might typically do when running an installer, such as registering a COM DLL, or installing some third-party dependency. So the Web page at which you download the app usually contains things like “ooh be sure to install this that and the other first,” defeating the deployment simplicity of ClickOnce. And if you need to update one of those third party dependencies and your app because dependent on one of those updates, you have no way to update that dependency with ClickOnce, unless you take it upon yourself to have your application manage the upgrade during its next run. That’s just more work than you shouldn’t have to do.

After writing all of this, it may seem like I am saying that ClickOnce is a half-baked load of crap; it’s not half-baked. I’m saying it’s a fully-baked, complete load of crap. (Kidding. ClickOnce has its applications for applications that can be completely self-contained, but if at any point you become dependent on anything COM, it’s time to move on to real deployment technology.)

Using WiX to create a Windows Installer MSI file

I’ve blogged about WiX before. It’s a great open source tool put together by some guys who decided to write a reasonable mechanism for generating Windows installers because, for some reason, the Windows installer team has seemed to think that editing database tables in a cheeseball editor called Orca was sufficient. This would be like saying that our warehouse workers could ship orders by updating data in a Microsoft Excel spreadsheet.

You could also pay lots of money for InstallShield or something similar, which would create MSI installers for you, but installation is a convenience for me–as a small business whose primary focus is not end-user software, paying for that doesn’t make much sense. There’s also NSIS, but, oh–I just threw up all over myself. We’ll save NSIS for another post.

Additionally, the WiX guys have realized that installers usually need to do useful things, like install certificates, set up Web sites in IIS, and run database scripts, whereas the Windows Installer team seems to have been trying to make writing custom actions harder, not easier, with their subsequent releases, because that’s where most of the crashes and problems in setup packages happen. With WiX, we now have a suite of well-tested custom actions that lots of people are using; this should have been the Installer team’s original response instead of depending on the community and third parties to fill in this gap for them, but it is what it is.

The point is that WiX enables a whole class of small business developers like me to build first-class deployment methods into their applications. With a 300-odd line XML file, the Fulfillment Manager now builds to an MSI file. And since WiX integrates with Visual Studio, I can generate that XML file as part of my build process.

Indeed, I’ve set up TeamCity and use this as a continuous integration server. Whenever I commit a change to Subversion, TeamCity picks up the change, compiles the solution, runs the tests, and if they pass, copies the newly generated MSI file to a network share for potential deployment. It’s pretty sweet.

The missing piece of the puzzle, then, is actually getting this freshly baked MSI file onto all of the client machines in the office.

Deploying via the Group Policy Software Installation Extension

My first instinct was to use the Group Policy Software Installation Extension. This is the thingie where when you open up a group policy in the Group Policy Management Editor, you can drill down to the Software Installation thing under Computer Configuration, specify an MSI file for deployment, and (presto!) any computers linked to that GPO will install the MSI on next boot.

This worked swimmingly well for the first release of Fulfillment Manager.

We pause for another brief interlude on update strategies

Let me explain the design of the installation for a moment. I’ve written my WiX file such that each new MSI file that it generates is a “major upgrade” in the Windows Installer parlance–it has a different product code, a different package code, and a different version number (since my version numbers are a combination of an incrementing build number and the Subversion revision number). But they all have the same upgrade code and I schedule RemoveExistingProducts during the install.

This means that if you have an older version of the Fulfillment Manager on your machine and double-click the MSI file for a newer, updated version, you don’t have to do anything–the existing version is completely uninstalled and the new version is installed on top of it.

The Windows Installer has support for “minor upgrades” and “small updates”, but I can never keep the damn things straight. Can I add a new component? Can I change a file? Can I reorganize a feature? Do I really want to be thinking about this every time I press Build in Visual Studio? My application is small, so I think it’s far easier and more reassuring to just blow away the whole thing and install again during an update, starting with a clean slate each time. In fact, I think this is a reasonable approach for many reasonably-sized applications (Paint.NET, for example, does this) and only becomes a problem when you start getting really large (such as Visual Studio or Microsoft Word).

Getting the update out there

OK. So all I really need to do is get all of the client computers to run msiexec /i FulfillmentManager.msi on the MSI and I’ll be good to go.

You might think that I could just overwrite the old MSI file on the network share with the new one, and the computers would notice the change at the next boot. But you would be, as I was, a fool–machines that already had the install would not notice the change and machines that did not have the install would freak out because they could not find the correct MSI file. After positing my question on ServerFault, I discovered the way the Group Policy Software Installation Extension works is by creating an advertisement script (*.aas file) and referencing that script via an object sitting in the Active Directory. That LDAP entry and the script file both do annoying things like reference a specific package code and product code, both of which I change with every new build of my software. So this method is out for the count.

Similarly, lugging out the Group Policy Editor and trudging down to the package entry and clicking “Redeploy application…” won’t work for the reasons described above–except that it’ll break the machines that already have the software installed, too.

What works is lugging out the Group Policy Editor, trudging down to the package entry, clicking “Remove” and “Immediately remove”, and then adding the package right back. This creates an updated *.aas file and correspondingly updated LDAP entries, and the old LDAP entry is flagged with a “remove me now please” flag. This works, but there are three things that I don’t like about it:

• It’s a manual process, so I have to remember to do it every time I create a new deployable build.
• References to all of the old versions hang around by necessity, since it’s recording the fact that “hey, if I see this particular product code then I need to uninstall it.” Indeed, upon inspecting the SYSVOL share, I saw that there about 45 of such files sitting in there since development of this app started in early July.
• There is no way to perform this process programmatically. (Well, there is, it’s documented as part of the EU anti-trust settlement, but let’s get real now: if it has LDAP in the spec then I’m not touching it with a ten-foot pole. Plus, this would be work that is totally tangential to my problem, which is automating a 1-minute task that ignores the crap out of me. At several days’ worth of work, it’d take me a long time to climb out of that time deficit to realize any savings.)

Nirvana: Automatic updating

The Software Installation extension for Group Policy can do a lot of things that I don’t need, like using patches or transforms, or shifting installed software by just moving a computer to a different OU, when at the end of the day all I really wanted was something that looked like this:

Must this be so difficult?

Since my installer will uninstall any previous versions, all I need to do is run the installation package via msiexec. This is easy enough to do via batch script that I’ve configured to run at startup via group policy, since those batch scripts run as SYSTEM and will have the necessary privileges to complete successfully.

You would think that in addition to /i and /x (and the idiotic /vomus), msiexec would have a somewhat useful parameter called, oh, I don’t know, /install-it-only-if-the-damn-thing-isn't-already-installed, but that would be a useful feature, so of course the Windows Installer team didn’t actually implement it.

Now, granted, there is actually no harm in running my installer when my app is already installed. It just would check that all the components are indeed installed and exit. But this still leaves a bad taste in my mouth. Not all MSI’s that I want to use in this way might behave like this. And, if I have any custom actions, that means that they’ll also get run on every boot, which seems like a waste.

While I could spelunk through the registry to try and see if I can find my current product code in the list, I’d rather not do that, because (1) that might not work consistently on all versions of Windows and (2) really, I’m just not that comfortable with batch scripts to begin with.

What ended up doing is writing a little command-line program called msicheck. The source file is boring and decently commented. Because all of the Windows Installer APIs are in C, my utility is in C. I briefly thought about writing it in C# with some interop, because I hate C just that much, but that did seem awfully overkill for such a simple application.

Ah, C in Windows. I had long forgotten the days of Hungarian variable names that sound like Yosemite Sam cussing (“lpszPackageVer“) and the land of if ("swizzle" == "swizzle") returning false. Heck, I had forgotten the days of not evening having false! I digress; the code is probably awful, but seems to work well enough for my purposes.

> msicheck.exe /?
 
Determines if a given Windows Installer package is installed.
 
msicheck package
 
Exit Codes:
        0       Exact version installed
        1       General failure
        2       Path to MSI package not found or not accessible
        3       Error determining package status
        4       Newer version installed
        5       No version installed
        6       Older version installed

All msicheck does is take the full path to an MSI file as an argument and returns an exit code that indicates the status of that particular package by looking at the product code and the version. (That is, if the product code is not installed, it returns 5; if the same product code is found, it compares the version and returns 0, 4, or 6.) I call it in my batch script (which, I don’t do this for a living, it’s probably retarded) like so:

@ECHO OFF
 
REM ---------------------------------------------------------------------
REM VARIABLES
REM ---------------------------------------------------------------------
 
SET path=\\SKIVIEZSBS2008\Group Policy Installations\Fulfillment Manager\
SET package=%path%Skiviez.FulfillmentManager.Installer.WinForms.msi
SET msicheck=%path%msicheck.exe
 
ECHO Checking installed version of Fulfillment Manager...
 
"%msicheck%" "%package%"
 
IF ERRORLEVEL 0 IF NOT ERRORLEVEL 1 (
	echo Fulfillment Manager is up to date.
) ELSE (
	IF ERRORLEVEL 5 (
		echo Installing latest version...
		%SYSTEMROOT%\system32\msiexec /qn /i "%package%"
		IF ERRORLEVEL 0 (
			echo Fulfillment Manager successfully updated.
		) ELSE (
			echo Errors may have occurred during installation.
		)
	) ELSE (
		echo Newer version installed or error occurred.
	)
)

Keeping in mind that IF ERRORLEVEL 5 evaluates to true for error levels of 5 or greater, this means that I call msiexec only if the product isn’t installed or if an older version is installed.

Conclusions and Delusions

So, by using a batch script and my msicheck utility, I have things the way I want them. I commit a change; TeamCity builds it, runs the tests, and copies the resulting MSI to the network share that is referenced in my batch script; and the batch script runs at the next boot, uses msicheck to note that that package is not installed, and so runs msiexec to install the update (which removes the old version as part of the install process).

It’s certainly not applicable to every software deployment scenario, much like ClickOnce, but hopefully it’ll help someone out there who wanted to do something similar.

Download MsiCheck, which requires Windows Installer 4.5 to run. Complete with the “works on my machine!” guarantee of absolutely no warranties.

Good luck!

Simple! The “new” workstation already had the Zebra LP2844 printer drivers installed, so I’ll just Start > Printers > Add Printer > Yep, LPT1: > Mmhmm, ZEBRA EPL > (scrolling … scrolling … Why is this dialog box so small? … scrolling) ah, LP2844 > Continue Anyway (Why can’t a million dollar company get their drivers signed?) > Finish, insto presto, and….

Boom. “Printer Driver was not installed. The operation could not be completed.”

Hum.

I’ll try it again. This is an indication of insanity–expecting a different result from the same operation–but it’s 7:30 a.m. and I can’t be experiencing problems already. Come on.

Boom. “Printer Driver was not installed. The operation could not be completed.”

Okay, I’ll just download Zebra’s driver setup utility and install the printer that way. Next > Next > Add a printer > Next > Next, and….

Boom. “The data area passed to a system call is too small.”

Hum. That’s a new one. But different!

I know this printer works, why is this not working?

The Solution

After about 30 minutes of head-scratching, I stumbled upon the solution. These types of errors are apparently the result of corrupted or just plain buggy printer drivers already installed on the machine. They could be unrelated to the printer that you’re trying to install; it doesn’t matter. They’ll cause the error when the “add a printer” mechanism enumerates through the list of printer drivers already installed on the machine.

To fix it, it’s time to blow away some printer drivers. Go to Printers under the Control Panel. Click File > Server Properties and switch to the Drivers property sheet. Remove any suspicious-looking drivers and try to add your printer again. (For me, the problematic driver was a custom LP2844 driver that came on a UPS WorldShip disk.)

One of these was something that I used for my convenience over a VPN connection from home. You see, the internal order processing application that I wrote uses some shared folders to store some temporary data, such as e-mails that are generated but not yet released to Exchange, or a local copy of images that are available on the Web site. This software–and our users–are used to referring to Windows file shares as \\COMPUTER-NAME\SHARE-NAME; for example, \\CYRUS\Pickup Holding, because for some reason some of the older servers are named after my boss’s dead cats.

When connecting through VPN to SBS 2008, however, that “suffix-less” name resolution was not working. So when \\CYRUS\Pickup Holding failed to resolve to anything, \\cyrus.skiviez.com\Pickup Holding would work fine. This was super annoying.

The reason this worked previously with our SBS 2003 installation is that it was acting as a WINS server, which provided this type of computer name resolution for us. SBS 2008 finally retires this ancient technology by default, however, so I had two choices: I could either install the WINS server role on SBS 2008, or I could just figure out how to get the 015 DNS Domain Name option from DHCP to relay through the VPN connection.

I chose the latter option, since it’s certainly less confusing to be able to say to someone in the future “we don’t use WINS, DNS does everything.” So here’s how to do it:

1. On the SBS 2008 server, click Start > Administrative Tools > Routing and Remote Access.
2. In the tree view, drill down past the server name to IPV4 > General. Right-click the General option and choose “New Routing Protocol” and choose DHCP Relay Agent.
3. Now right-click the newly appended “DHCP Relay Agent” node and choose Properties. Add the IP address of your DHCP server (which is probably your SBS server itself), and click OK. Then click it again and choose “New Interface” and add the “Internal” interface.
4. Now if you connect through VPN, an ipconfig /all should show your domain name as a “Connection-specific DNS suffix” and pinging machines by their suffix-less computer names should work. (If it doesn’t, make sure your DHCP server is using that 015 DNS Domain Name option, which the SBS 2008 wizards set up by default.)

Happy file sharing!