Outline the quirks of Windows Small Business Servers (SBS)

Question

I'm not much of a Microsoft administrator. However, I do work extensively with new and existing Microsoft Exchange deployments. That's just how the career-arc went.

I'm working with a small customer of 15 users who's not content with the local "PC guy". They've asked me to step in during a couple of system outages. One thing I noticed during this morning's "we can't access the internet" emergency was that the client had a Windows SBS 2011 server on premises.

• A rogue DHCP server was accidentally started on the phone system and the SBS DHCP service actually shut itself down. I'd never seen this happen with normal Windows Servers, so this caused some downtime and confusion.

• The main DHCP scope looks a bit odd, in that it defines the entire /24 subnet, but excludes a large swath of it. The local PC resource says that it has to be configure this way, or else "SBS won't work..."

• There are a lot of funny OU's that seem to have been created; mostly under the parent "MyBusiness".

• Exchange mail is convoluted, with desktop users requiring both POP3 and MAPI accounts, and inbound going to an offsite server. I can sort that out, but also happened to notice that Exchange wasn't even licensed. This server has been in production for 3 years, but this appears to be a configuration issue.

My recommendation is to avoid things like Small Business Server, even for 10-user businesses. However, that opinion was formed from lack of familiarity with SBS and hearsay. I'd like to understand the downsides/disadvantages more clearly.

• Are there any other quirks I should know about in the process of making a case to the customer?
• Given than there are so many odd behaviors and limitations associated with SBS, what is the intended or ideal use case for an SBS deployment?
• Assuming a new set of Windows Standard 2012r2 servers can be deployed, are there any major caveats to migrating from SBS?

Answer 1

I've always understood SBS to be the "Windows Server for small businesses when you don't have an IT department but want an all in one server". SBS makes sense in some shops, not so much in others. If you want to be 100% Microsoft, have no desire to go to the cloud yet, and have fewer than 25 employees, then it could make sense for your company. While "Standard" allows for up to 75 clients, I can't really see a shop of greater than 50 employees getting away with SBS...but again that also depends on the shop. 50 IT pros/developers?? No way. 50 basket weavers and 3 office workers? Sure.

The idea was that the SBS server has a lot of little wizards and tweaks that allow a non-IT person to at least semi-administer it well enough. User account creation, remote access, file and print sharing, backups, etc. are all supposed to be handled via SBS wizards.

The quirks that you've discovered are just how SBS likes to show it's uniqueness. :)

A rogue DHCP server was accidentally started on the phone system and the SBS DHCP service actually shut itself down. I'd never seen this happen with normal Windows Servers, so this caused some downtime and confusion.

SBS will stop its own DHCP service if it detects another DHCP server on the same network. You'll get an event ID 1053 in the System Event log on the SBS server explaining the IP address of the rogue DHCP server.

The main DHCP scope looks a bit odd, in that it defines the entire /24 subnet, but excludes 80% of it. The local PC resource says that it has to be configure this way, or else "SBS won't work..."

Again, another one of those "we think you aren't in IT" things. They allow for some static address exclusions at the top and bottom of the scope knowing that's most likely where someone will use them.

There are a lot of funny OU's that seem to have been created; mostly under the parent "MyBusiness".

Once again, back to "ease of use". This OU and its sub-OUs get created along with some default GPOs (see here: http://www.techrepublic.com/blog/the-enterprise-cloud/windows-small-business-server-2011-default-group-policy-configuration/) that are supposed to aid the non-IT administrator in handling what OUs are, what they are for, etc.

Exchange mail is convoluted, with desktop users requiring both POP3 and MAPI accounts, and inbound going to an offsite server.

That would be based on how Exchange was setup on the SBS server. I believe POP3 is enabled by default along with MAPI and even IMAP4. It also has (had?) some quirks like the POP3 connector and other means of collecting 3rd party email providers mailboxes and then bringing them internal to Exchange. But Exchange on SBS for the most part can be administered and deployed same as Exchange standalone.

All that said:

Are there any other quirks I should know about in the process of making a case to the customer?

There's the user limitations (Essentials is 25, 75 with the standard license). There's also limitations like SBS has to be the PDC Emulator DC, and "Organizations needing to deploy additional servers within their SBS environment must purchase the SBS 2011 Premium Add-on. The add-on includes a Windows Server 2008 R2 Standard license, which enables deploying a second server on a Windows Small Business Server 2011 network. The Premium Add-on also enables adding virtual servers running within a Hyper-V environment in an SBS 2011 network." Citation

However, a nice benefit for companies smaller than 25 is that Essentials requires no CALs...so no need to track those and no need to have a small company freak out when MS comes around.

Given than there are so many odd behaviors and limitations associated with SBS, what  is the intended or ideal use case for an

SBS deployment?

SBS is an economical alternative for a small company wanting a Windows shop. However, with the cloud (and Office 365 specifically for a small Windows shop) it's becoming less and less of a desire from what I can see.

Assuming a new set of Windows Standard 2012r2 servers can be deployed, are there any major caveats to migrating from SBS?

Not really...other than cost of the licensing and possible complexity due to administration. You can move AD over and then cleanup the old OUs and GPOs if you'd like. The bigger issues would be if they were using it for Sharepoint, SQL, and Exchange. At which point it's just a bigger migration to deal with, but nothing specific to SBS. If they're used to using Remote Web Access though, that would go away.

Another big deal is that after SBS 2011, it's now 2012 Essentials (limited to 25 users). SBS will likely just fade to memory as more and more small businesses simply utilize Office 365 and other Cloud offerings.

Some light reading/links:

http://www.techrepublic.com/blog/10-things/10-things-you-should-know-about-microsoft-small-business-server-2011/

http://blogs.technet.com/b/sbs/

http://thevarguy.com/information-technology-channel-partner-programs/microsoft-kills-windows-small-business-server-dont-p

Answer 2

I generally include the full subnet in the scope and exclude addresses as needed. 80% seems a little extreme, but for a small set of users, it's not unheard of. It's not required though and SBS will work just fine with a larger pool or a smaller scope.

OU's are an organization thing - I've seen many places that don't seem to know how to properly use them but that's a larger discussion with why they created the OU's

Inbound mail to offsite server: Are they using a 3rd party filter service? EOP/MXLogic/etc?

SBS is okay for small offices which will remain small. I generally shy away from it as well as most businesses expect to expand at some point and you can outgrow SBS pretty quickly. But for some smaller mom/pop type businesses that expect/want to stay small and in that 10 user range, SBS can work for them. What most places don't realize is that it still takes someone knowledgeable to maintain (and backup) SBS. Most places in that space might be better served by Office365 today if they wanted to stay with a Microsoft-centric solution.

The migration process from SBS to 2012 is documented.

This Migration Guide includes the following steps:

1. Prepare your Source Server for Windows Server 2012 Essentials migration. You must ensure that your Source Server and network are ready for migration. This section guides you through backing up the Source Server, evaluating the Source Server system health, installing the most recent service packs and fixes, and verifying the network configuration.

2. Install Windows Server 2012 Essentials in migration mode. This section describes the steps you should take to install Windows Server 2012 Essentials on the Destination Server in migration mode.

3. Join computers to the new Windows Server 2012 Essentials server. This section covers joining client computers to the new Windows Server 2012 Essentials network and updating Group Policy settings.

4. Move Windows SBS 2011 Standard settings and data to the Destination Server for Windows Server 2012 Essentials migration. This section provides information about migrating data and settings from the Source Server.

5. Enable folder redirection on the Windows Server 2012 Essentials Destination Server. If folder redirection is enabled on the Source Server, you can enable folder redirection on the Destination Server, and then delete the old Folder Redirection Group Policy setting.

6. Demote and remove the Source Server from the new Windows Server 2012 Essentials network. Prior to removing the Source Server from the network, you must force a Group Policy update and demote the Source Server.

7. Perform post-migration tasks for Windows Server 2012 Essentials migration. After you finish migrating all settings and data to Windows Server 2012 Essentials, you may want to map permitted computers to user accounts.

8. Run the Windows Server 2012 Essentials Best Practices Analyzer. After you finish migrating settings and data to Windows Server 2012 Essentials, you should run the Windows Server 2012 Essentials BPA.