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
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 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: