On Thursday I contended Microsoft Small Business Server (SBS) was a woeful product.
Actually, I was really talking about how Linux keeps Microsoft honest. In the face of competition – no matter if you deride the amount of market share – the advent of Linux has forced Microsoft to enhance their server products. Really, this was no “Linux r00lz” argument but instead saying Windows offerings have been bolstered.
As part of this I made reference to Microsoft’s coming Essential Business Server (EBS) which gives a bit more than SBS traditionally had. The reason being that Microsoft knows SBS is a bad product.
After all, why would anyone recommend SBS over the regular standard editions of Windows Server and Exchange server except for the matter of price? You don’t do it for any functionality gain and you most certainly lose any chance of scalability. You lock yourself in if you use SBS.
A consultant with the interests of the client at heart could provide an open source Linux solution which still provides authentication, file and print sharing, groupware mail and calendars and a firewall. In fact, if they did this they’d be able to spend more money on the hardware because they’ve completely eradicated the software tax.
Microsoft knows this. This is why EBS lifts some of the shackles SBS places on a business to dole out just a little bit more. Of course, as it turns out, consultants will still recommend SBS because in the end it’s not about the technology. I’ll come back to this shortly.
First, let’s address some criticisms of my story.
The most frequent complaint was that zillions of small companies will never grow beyond 75 users. Actually, this isn’t really a criticism of what I wrote than a depressing admission that lots of companies will plateau, stagnate or fail.
In fact, this kind of statement even readily acknowledges SBS has limitations but is going with the line that the SBS constraints are tolerable in a lot of circumstances.
I would hate to be seen as lambasting small business. My parents owned their own restaurant for most of my young life. At other times they also owned a bookshop and a pool and leisure product store. On the one hand in a situation like theirs of course they’re not going to grow beyond 75 staff that legitimately require a login and e-mail address.
However, then again, isn’t that a limiting statement?
How can I look at a business and decide it won’t grow, it won’t become part of a franchise, and it won’t be acquired by a larger entity?
In a more traditional office environment than a restaurant or retail store this is even more significant. I’d be certain the bulk of service providers would love to grow. Even if they don’t have legions of staff it’s a certainty they’d like to operate out of more than location.
Which brings up another SBS fault, as well as – yes, it’s true – a mistake of my own where I unjustly repeated a common SBS fallacy.
User limitation isn’t the only constraint in SBS. You’re also restricted to having just one SBS server in your network (well, until EBS.) If you want more servers you have to pay the full price for a Windows Server 2003 license.
This particularly comes in to play if you set up a second office. And that’s definitely not outside the realm of possibility for any small business. Even the type of stores my parents operated. If you have a branch network – even if only two branches – you would be best served by networking them. This gives you consistency of logins and authentication, a consistent and unified address book and calendaring system. You can share files and other resources.
So what do you do? Well, firstly, if you have the domain, mail and file server in one office, and let the second office’s users drag files over the wide area network (WAN) connection you’ll just frustrate them. They’ll experience lag.
A popular option is terminal services. If you have a second office you could opt to go this route. This means the first office – where the server is housed – run their desktop computers as normal.
The second office use remote desktop protocol (RDP) clients to effectively log in to a session on the server in the first office. They get all the benefits as if they were on the local network in the first office because that’s where they really are opening and saving files. All that goes over the wide area connection are keystrokes, mouse movements and screen refreshes.
Oh crap, that’s right; SBS doesn’t let you run terminal services. You need a second server if you want to use terminal services. And it must be a Windows Server product at the regular price, not the SBS price. Oh yes, and you will need to buy new terminal server client access licenses (CAL) too. Thanks for nothing, SBS.
Let’s start again. Perhaps you could place a second server at the new office. This server would give local file and print serving. Your users can even authenticate it. Ok, time for an admission.
I said last time SBS won’t allow another server to be a domain controller. I said you were restricted to just one domain controller. In a second branch scenario like the one we’re discussing here all user authentication would have to go over the WAN even if you had a local server.
This was wrong. You can, in fact, have additional domain controllers. The local branch server could become a domain controller and then the second office folk can login against it.
I do appreciate the legion of SBS consultants who pointed this out to me, and I do consider myself corrected. It’s no defence but at least I’m not alone; most expressed “when will this chestnut die” so it’s an oft-repeated myth.
Still, even though I am corrected I don’t consider myself defeated. I was corrected on one point alone. Yes, an SBS network will permit additional domain controllers.
However, not one person said I was wrong that SBS limited the number of users, it limited the number of SBS servers, and it did not lend itself to participating in larger, multi-domain, networks because it does not permit trust relationships and more.
In fact, even though SBS does allow more than one domain controller there is one particularly fatal flaw which becomes a true problem in such a multi-office scenario as I’m describing. And I’m still to tell you the real reason consultants recommend SBS.
A Windows network with an SBS server can have more than one domain controller. Of course, the other domain controllers need to be regular Windows Server systems at the regular, non-SBS, price. There is something which concerns me more however.
A Windows Active Directory network infrastructure assigns what it calls flexible single master operation (FSMO) roles to the servers in the network. In a domain there are four FSMO roles available (and five in a forest.) Each FSMO can be assigned to one and only one server.
By default, the first server set up in Active Directory holds all the FSMO roles – which means your SBS server. Good and sensible practice suggests you would break this up to distribute the FSMO’s across multiple servers. Yet SBS will not allow this. One further SBS constraint is that it must hold all FSMO roles.
To me this is an unacceptable risk and it cannot be underestimated. If you use SBS, no matter how many additional servers and domain controllers you deploy your Active Directory root and FSMO roles are all held on the one single machine. If it fails your network goes down. The fix is not pretty; a dead SBS server requires what’s known as “graveyard swing migration” and it’s not a trite operation.
What other criticisms did I receive? Oh yes, some people failed to understand how I could not love SBS so they assumed I’d never used it. In truth much of my frustration comes from having to integrate “yet another fricking SBS site” to nation-wide infrastructures during mergers and acquisitions.
Another conceded I was right that SBS did not permit trust relationships and even conceded SBS greedily hoarded all the FSMO roles to itself. They gloated that I probably didn’t know about that though, but wrong again.
One more person figured if I recommended Linux to someone it’s only because I’d want to run it on clunking old Pentium III machines. This was an interesting one. Firstly, it’s wrong; after all, I said if you didn’t spend money on SBS you could spend more on the hardware. I’m advocating even better machines than the SBS consultant!
But secondly, this argument implicitly recognises that Windows Server products impose a heavier hardware burden than Linux. If my critic took their argument to its logical conclusion they’d recognise Linux will perform better than SBS on equivalent hardware.
Let’s cut to the chase. Why do consultants recommend SBS?
I’m going to repeat my contention that standard editions of Windows Server and Microsoft Exchange are much more useful and scalable than SBS. I don’t think any sensible person could deny this.
So why use SBS? The reason I’ve given previously is price. The small business client has a budget. The full suite of Windows server products is expensive. This is why a cut-price – but reduced-functionality – version exists.
But why suffer that reduced functionality? You could instead chop out the entire cost of the software with free open source equivalents.
Ultimately, then, it’s not really about price. There’s something deeper at heart. It’s the quality of the consultants themselves.
I argued last time that the consultants don’t know better. They don’t have experience with the larger range of Windows products – let alone Linux equivalents.
It could be argued that a sole trader can’t be expected to pony up the funds for, say, an Exchange 2007 license just so they can get familiar with it, but this doesn’t take into account sandbox virtual machines that Microsoft provide for testing and evaluation.
Nor does it take into effect the peanuts price of the Action Pack that anyone can buy if they register for free as a partner. Best of all, the Action Pack gives you a license for production use not just evaluation.
I’m going to go further; this is the same reason why commercial developers implement solutions in Microsoft Access. It’s not because they’ve got the client’s best interests at heart, it’s because the consultant themself doesn’t know any better nor have the experience to produce something more robust and scalable.
You don’t have to take my words for it. An SBS consultant – a Microsoft Valued Professional (MVP) in the product no less – has this to say:
“There’s firms like mine that want to stay in the sweet spot of seat size of SBS. We pass on mergers. We don’t want to grow big.”
Yes, according to the so-called SBS Diva the reason a lot of consultants recommend SBS is because they, themselves, are content with being small. They don’t want to know more. They don’t want to grow their own business. They don't want to grow with the client's business. They don’t want to do the hard work. SBS suits them. To hell with the client’s needs.
Stay tuned; on Thursday I’ll tell you some Linux small business and groupware equivalents proving that Linux can provide all that SBS does, and so much more, at a price Microsoft cannot beat.