9

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..."

enter image description here

  • 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?
ewwhite
  • 194,921
  • 91
  • 434
  • 799
  • 1
    Regarding the DHCP exclusions, that's only about 40%, not 80%. IPs .51 through .199 are available for DHCP leases. As to the local IT guy's claims that "it won't work" without those exclusions, it's probably a matter of the network gear and other stuff with static IPs being near the start and end of the IP range, but he's not experienced enough to know that. (But yeah, stuff "won't work" if you give a client PC the address of the switch, etc.) You can probably get away with much smaller exclusion ranges, but it doesn't sound like you need the IPs anyway, so ... why mess with it? – HopelessN00b Oct 21 '14 at 15:18
  • Ooops, misread. But am I weird for specifying the exact range of IPs I want for DHCP? – ewwhite Oct 21 '14 at 15:21
  • Nah, not weird. I see it done both ways a lot. It might have to do with coming from a Linux background - most Windows admins I've worked with use exclusions, like above, but the Linux and networking guys I've worked with tend to favor explicitly defining the DHCP range and just leaving out whatever addresses they don't want assigned by DHCP. – HopelessN00b Oct 21 '14 at 15:48
  • @ewwhite - DHCP exclusion ranges within the scope range are sort of a "best practice". Per MS: "You should use exclusions for all devices that must be statically configured." -- they also want you to use DHCP reservations too for static devices, which seems contrary to their own advice lol. – TheCleaner Oct 21 '14 at 16:20
  • It's a strange notion for a Linux engineer used to ISC DHCP. – ewwhite Oct 21 '14 at 16:22
  • @TheCleaner I (try to) do that bit with the DHCP reservations for our static devices, for no other reason than centralizing information about our network devices on the DHCP server. – HopelessN00b Oct 21 '14 at 16:58
  • 1
    It sounds like this was a poorly-engineered SBS 2011 install. I only used a little of SBS 2011 before Microsoft killed it, but it was a *very* inexpensive way to get Windows Server 2008 R2 and Exchange 2010. That's what I always used it for. I installed the SBS management garbage, stopped unnecessary services, created my own OU structure and disabled the silly stock GPOs, and ultimately managed it like a regular ol' Windows Server / Exchange installation. The pricing was great but, of course, MSFT wants SMBs on recurring Office365 subscriptions now... >sigh – Evan Anderson Oct 21 '14 at 17:26
  • 1
    I don't think this merits a full answer, so I'll just comment: the SBS I support was purchased solely based on price. SBS08 was considerably cheaper than buying all the various bits separately. So this is perhaps a longer way of saying, "What @EvanAnderson said." :D – Katherine Villyard Oct 21 '14 at 21:18
  • 2
    Ah, but it costs far more to have me look at it when it breaks :) – ewwhite Oct 21 '14 at 21:20
  • @ewwhite That's what they have me for. ;) Seriously, our install is well-behaved. – Katherine Villyard Oct 21 '14 at 21:21
  • @ewwhite Same thing that KatherineVillyard said here. My SBS installs (2003, 2008, 2011, and now 2012 R2 'Essentials') have all been very well-behaved, but I treated them like "full blown" versions of the products (and I'd like to think that I'm a fairly decent Windows admin... >smile<). I don't think there's inherently anything that makes them any more costly to support than their equivalent products as long as they're treated well. Arguably, they attracted VARs and IT admins who weren't actually competent to handle them, though. – Evan Anderson Oct 21 '14 at 21:35
  • @EvanAnderson And the consensus is that SBS doesn't make sense *today*, right? All of my other small customers went with full product versions, so I don't know that the cost was an issue here. I think their PC person just steered them toward SBS. – ewwhite Oct 21 '14 at 21:41
  • @ewwhite - Since MSFT killed the SBS product it's difficult to discuss the relevance today. Obviously, I wouldn't recommend any new installs use old MSFT software, so there's nowhere that I could recommend using SBS today. If a business falls into the market segment that Windows Server 2012 R2 Essentials (the "spiritual" successor to SBS) covers, though, I'd see no problem with using it. (It's a lot less SBS-ey than SBS was-- fewer wizards, more just plain ol' Windows Server.) (It would be fun to discuss this market segment stuff and biz-dev over lunch sometime... >smile<) – Evan Anderson Oct 21 '14 at 21:51

2 Answers2

8

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

TheCleaner
  • 32,352
  • 26
  • 126
  • 188
  • @Ewwhite Another feature unique to SBS is its built-in E-Mail Alerts and Reporting functionality (*SBS Console>Network>Computers tab>View Notification Settings* and *SBS Console>Reports*). If you're making a case to your client for a non-SBS solution and they are currently getting any reports from their SBS server, you may want to consider including in your conversation how *you'll* be monitoring their system (if you do so) or perhaps provide them an alternate solution. – I say Reinstate Monica Nov 01 '14 at 03:04
4

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.

Rex
  • 7,815
  • 3
  • 28
  • 44
  • As for the POP3 mail, it's looks like it's because the previous admin didn't get autodiscover and a few DNS things arranged properly. There's no spam filtering. – ewwhite Oct 21 '14 at 15:07
  • Would you argue that the specific knowledge needed to make SBS run well is more specialized than the knowledge to keep a normal Windows Server installation healthy? Smaller mindshare, more caveats... more problems? – ewwhite Oct 21 '14 at 15:08
  • 1
    Anyone capable (capable by my standards) of being an admin for a windows network can manage an SBS solution either by already knowing the technology or by being able to learn it. The problem is most places that small don't want to pay the going rate for someone capable. People that are self-proclaimed as being capable are not always the best. Like the "network engineer" I talked to recently who didn't understand routing tables. – Rex Oct 21 '14 at 15:10