Quandaries

"But almost all commercial hosting environments are scalable," you say, scratching your head at the premise. "If you don't like the shared server plan, go to a VPS, or get your own box!"

Of course, that's the answer we've become accustomed to in the hosting realm, and of course, that is a certain sort of scalability, but it's not the sort I am talking about. What I am looking for may in fact belong in the realm of fantasy, but on an Internet where I can give an online pedicure, by god, anything should be possible.

What I am talking about is service scaling rather than capacity scaling. Capacity is what you get when you move from GoDaddy's shared hosting to one of their dedicated servers. But you still deal with the same old crappy GoDaddy service at either end of the scale, no matter what you are paying. At some point in your evolution of requirements, it's not so much the capacity that matters, but the service.

I am probably giving GoDaddy too little credit in the customer service department; they have always been cordial when I have taken a problem to them, but with their volume of business and their low prices, it seems that the first reaction in any situation is: "It's your fault, and because it's your fault, we're not going to help you with it. You're not paying us enough to do that!" But that's the thing; they won't let you pay them for better service. It's just not available. So, whether you are some punk with a shared server that gets three hits a year or a business with a host of dedicated servers pushing serious traffic (and that gap is more narrow these days than it may seem) you still have to fight with the first-line "just say no" brigade to get to a second-level response where someone might actually provide you an answer to your question. That's just a waste of time for the customer.

(EDIT: It's been brought to my attention that GoDaddy does, in fact, offer a premium tier support package, their Assisted Service Plan. I don't immediately see what the pricing is on that or what the scalability might be, but it's a step in the direction I am talking about, at least.)

"But if you want good service," you say, "go to Rackspace! They are fanatical about service!"

Yes, they are; even says so in their slogan. And as you might expect, you pay a premium for that service. But, in the opposite of GoDaddy's problem, you can't not pay that premium.

Switching providers or hosting techniques as you expand is the accepted method for growth among website owners now, but it strikes me as being less than optimal. It detracts from business focus, takes away development and operations resources from improving the site itself, and is ghastly inefficient.

What would be better for the consumer would be a company that offers the full spectrum of capacity and service, from the entry-level shared instance with minimal support, to full cloud scale with dedicated support. The new, accepted model of the Internet startup, after all, is the small one or two person concept site that blows up into the next Facebook or Twitter... but no hosting provider out there today is oriented toward fostering and subsequently benefitting from the growth of such sites.

This isn't exactly the cloud concept, but it is a concept that many cloud service providers certainly could adopt. After all, the great promise of cloud computing, or utility computing as Nicholas Carr describes it, a more useful term conceptually, is that it will eventually commoditize the power and storage of these vast server farms. Today, early in the cycle, there is novelty, wonder, and the impression that first-movers like Amazon are minting money, but the business model itself is oriented toward driving profits down by providing computing cycles for the least cost. Differentiation in such environments is made by service.

So far, service doesn't seem to be doing much differentiation. Amazon is cordially amenable to developers and users, and their services are tiered to some extent, but they are all high-end services. There is no entry level at the level of the non- or minimally-technical user. As of yet, I'm not aware of anyone fronting their service with a more structured hosting product line (although, who does Squarespace use on the back-end? My impression is that it is their own product but if it's not, then they are already doing something of what I suggest), but it might be an interesting exercise if the math could be made to compare with the like of 1and1 or GoDaddy.

Although it's an imperfect solution, I have been relying on WebDAV file sharing for remote file access quite a bit lately. It's relatively easy to connect to, and unlike Sharepoint it allows LAN users of Windows file shares to access files directly on the file system at the same time as WAN users can, with all the same file/folder paradigms.

Tonight I was setting up a server for this purpose and found myself banging my head against the wall with this seemingly simple task. Although I've done it dozens of times, and ran quickly through the setup steps on the server, I could not for the life of me get a Windows client (I tried three) to connect. I didn't happen to have my Mac handy to try it; as it happens, that might have saved me a lot of trouble, since the server wasn't the problem.

The mechanism of the failure of a little maddening--I could connect to the server easily enough, but it would prompt for my credentials and then keep prompting even when they were provided accurately. The Security event log on the server showed absolutely no activity. The IE client would return a 405 error, and the IIS logs showed a 401.2 error on each attempt.

Finally, after forty-five minutes of making absolutely no progress on the subject, I stumbled quite by chance across this Microsoft Knowledge Base article, which described a different problem entirely but ultimately contained the right solution. The issue was with XP Service Pack 2 and later versions of Windows, including Vista; to quote the KB article: "For security purposes, Windows Vista and Windows XP SP2 disable Basic authentication in the Web Distributed Authoring and Versioning (WebDAV) Redirector."

Isn't that swell! IIS still allows Basic Authentication, but the Windows client does not! I'm sure that this is intended primarly to service non-Windows clients, but there is absolutely nothing the OS error messages to indicate this functionality is disabled, and it seems a poor solution. Security is important, but as I've discussed previously, security can't break functionality. Basic Authentication is intended to be the final fall-back; it's unacceptable that it simply be made unavailable to Windows clients.

I had never run into this before because every other situation in which I had configured WebDAV was in a domain environment. This server happens to be a hosted, stand-alone Terminal Server. Because it's not in a domain, neither Integrated nor Digest authentication are allowed and Basic was the only available option.

I don't expect that this is a common problem for anyone, but I couldn't find anything anywhere on the Web when I was looking for solutions, so I hope this post helps someone, somewhere. I also wanted to link to David Wang's invaluable HOWTO post on diagnosing 401.x errors in IIS.

I keep running across this and I'm writing it down here now so that I will remember it the next time someone asks me about it (or better yet, they'll find it here themselves, and won't ask me at all, and I can get back to WoW).

When installing an XP client computer on a Small Business Server 2003 network, when attempting to run the Network Configuration Wizard, you may receive an error just after the point of entering the wizard which reads "Make sure that only one network adapter is enabled and that it is connect to the Small Business Server" with options to retry or cancel. You may have a wireless and a LAN connection (this is most common on laptops) and you may disable one or the other and find that you still get the message.

The trick here is that the wizard doesn't like any kind of networked connection, not just the local area connections you may assume are important--so you must disable 1394 (Firewire) and Bluetooth connectors as well. Since these aren't even always in the same area of the Network control panel, they can be easy to overlook and/or disregard.

This is similar to another error often encountered during SBS client setup using the Network Configuration Wizard, which is "The list of users and computers could not be found on the server. Make sure that the Small Business Server network adapters are configured correctly." You may receive this even if the server can be seen on the network and the users and computer list enumerated in other ways. The cause of this is having a secondary DNS configured; SBS clients can only point to a single DNS server, which must be the SBS server.

Now, many less technical users wouldn't bother to configure a secondary DNS address in their DHCP anyway, so you could argue this issue only happens to people with sufficient technical resources to figure it out eventually. But I think it's ridiculous that SBS doesn't support assignment of a secondary DNS in the first place. After all, most offices that are running Small Business Server probably are not running any other server internally, and so have a built-in single point of failure--and limited on-site technical resources to fix that point of failure should it, you know, fail. A secondary DNS assignment, taking some of the eggs out of that basket, is tremendously helpful as it would allow, in most cases, continued Internet connectivity in the event of a server failure, and so would allow people to get at least some work done while the other issues were being addressed. I thought that this was a fairly well-known best practice in networking configurations. I've always made it a practice to use multiple, redundant DNS servers on diverse subnets--you would have thought that Microsoft would have got the message after this semi-famous failure that resulted from failing to follow that practice, which left their main public website inaccessible from the Internet for the better part of two days.

That may be good enough for Bill, but most of my clients prefer slightly better up-time than that.