This has been a fun topic of discussion on Server Fault. There appear to be varying "religious views" on the topic.
I agree with Microsoft's recommendation: Use a sub-domain of the company's already-registered Internet domain name.
So, if you own foo.com
, use ad.foo.com
or some such.
The most vile thing, as I see it, is using the registered Internet domain name, verbatim, for the Active Directory domain name. This causes you to be forced to manually copy records from the Internet DNS (like www
) into the Active Directory DNS zone to allow "external" names to resolve. I've seen utterly silly things like IIS installed on every DC in an organization running a web site that does a redirect such that someone entering foo.com
into their browser would be redirected to www.foo.com
by these IIS installations. Utter silliness!
Using the Internet domain name gains you no advantages, but creates "make work" every time you change the IP addresses that external host names refer to. (Try using geographically load-balanced DNS for the external hosts and integrating that with such a "split DNS" situation, too! Gee-- that would be fun...)
Using such a subdomain has no effect on things like Exchange email delivery or User Principal Name (UPN) suffixes, BTW. (I often see those both cited as excuses for using the Internet domain name as the AD domain name.)
I also see the excuse "lots of big companies do it". Large companies can make boneheaded decisions as easily (if not moreso) than small companies. I don't buy that just because a large company makes a bad decision that somehow causes it to be a good decision.
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
Best Answer
You have a DNS issue. You must have DNS running in order for AD to run. It is possible that the client registered its IP and broke things. (although for the life of me, I cannot believe AD would allow that)
Try this - find the workstation's IP then shut it down. Add that IP to the NIC of the domain controller. This should allow the computer name to get associated with the right IP address.
If it doesn't help, try uninstalling DNS and reinstalling. Once it is loaded run
ipconfig /registerDNS
on the DC to recreate the AD records