Example: I'm in the process of some infrastructure shifting for a small business. They currently use Microsoft Small Business Server 2003 RC2 using Windows XP SP3 workstations.
In order to simplify things they are moving to a more homogeneous environment (all workstations will be exactly the same, there are only 4 so its not as big of a deal as it sounds).
Now I COULD stick with the SBS2003 installation, but there are a lot of things that I don't like about it. It DOES work pretty well, most of the time. Here is a list of things that I wish I could change:
Remote management WITHOUT having IESBS2003 uses the RWW (Remote Web Workplace) in order to allow you to connect to a secure website and do things like check email (Outlook Web Access), Run Reports (status/use reports for server) and connect to the server & desktops. Most people look at the RWW as the strongest feature you get in SBS that you DON'T get in other Server environments (Either Microsoft server or any other server installation). For me it is a hindrance. I don't run IE, because I use Ubuntu for my OS. If I need to remotely administer or remotely connect to any of the computers at this location I have to start my XP virtual machine and connect from within there. It is the last "gotta have windows for this" thing in my migration from Windows to Linux.
Expensive client licensingSmall Business Server 2003 Standard costs $639.99 according to Newegg.com. That includes a whole 5 CAL license. What does that mean? It means 2 things: 1. you have to choose user/machine licensing scheme. 2. you can only have 5 connected to the server at one time. This is pretty limiting. If you want 6 computers you need to spend an additional $349.99 according to Newegg.com This very quickly drives the cost of the server up, this is completely exclusive of any desktop costs. Oh yea... if you want to include SQL in the package the cost goes up more. Though at some point around the 15 user mark the cost of cal's becomes more then the cost of the server, even with SQL, so the more people you have the less it matters.
Unused servicesThis is not as big of an issue for me as the other two items previously mentioned, but it is still something I would like to see addressed. Something I realized, running your own mail server is stressful. A lot of a business' ability to function hinges on access to email and telephone. Even if things are critical in other areas of the infrastructure if you have access to email and telephones you can hobble along. This is the primary reason we moved our main mail services from Exchange over to Gmail. The $50/user/year cost was acceptable to us in order to ensure that critical part of our infrastructure was operational. Once we had transitioned from exchange TO Gmail there was no "clean" way to remove exchange from our environment. In fact if there is no good way to not install exchange. The SBS components are SO tightly integrated that things begin to break down once you remove one part of it, even if it is not completely necessary. There are a bevy of things that are similarly required arbitrarily. Updating, backup, firewall, faxing.
Backup SolutionSBS2003 does backups, but it misses the last critical step. Firstly it favors setting up full system backups, and the reading materials strongly suggest a daily schedule. In my sittuation that means a daily single file of about 30-40 GB. Now that excludes a few folders like the updated service packs etc that are easily accessible online and are not "installed apps" per-se. I have a drive on the server that I use to backup the server to, which is a sub-optimal solution. The real trick... and the killer for most backup scenarios is where is/are the off site options? My solution is not great, but it works ok. We purchased 2 500GB external hard drives that connect to the LAN. These are switched out weekly. We keep 2 weeks of daily full system backups (10 x30-40) plus as many weekly full system backups that will fit on each of the drives. In this sittuation the most we would ever lose is 1 week of data if the building burned to the ground on a friday. This scenario works ok, in theory, but all of the scripting/logic that is used to copy the large files over the network is coded by hand... by me, and I am not a coder. So it fails on occasion, and that is bad for a backup scenario. What would be better would be Weekly full backups and daily (or a few times a day) incremental backups directly to the NAS. This is NOT possible without the purchase of more software.
There are plenty of things that I like about SBS2003, but they are all things that are central to Microsoft's polcy of non-interoperability vs the fact that Microsoft has an inherently better product. They certainly do seem to be backing down from that stance with the release of some API's that make the ability of projects like SAMBA to interact more successfully with Windows.
So what is my alternative? Well I have two that I am actively pursuing, both of them Linux solutions to this common "Small Business Server" problem.
Do what Linux does bestAnd that is to provide a customized solution to my specific problem. I found a few tutorials online that have helped me to get to the point where I can have users logging on to my Domain, hosted on a Linux domain controller. I can install/configure/uninstall any of the components in the SBS equation that I do not need, and switch out the ones that are present for something that fits my needs much better. It comes at a great cost however, and that is time. The amount of time it is going to take me to setup and get working the way I want is several factors more this way, but the solution is exactly what I want... in so far as the technology allows for.
So as you can probably guess, I'm opting for the fully customized Linux alternative. I'm still in the testing phase at the moment, configuring a virtual lab of computers that are acting as server and clients (both Linux and Windows) in order to hammer out my plan of attack. This is not to say that I am 100% set with this option, but the main advantage of testing the most desirable/most difficult solution first is that if it ends up not working, you will usually be pleasantly surprised at how little time it can take to implement one of the other solutions.
I'll try and keep this blog updated on my progress, so far I am impressed with how cool learning about this stuff has been.