First, let's think about the target market for an SBS system... Small office. Less than 25 users. No formal IT skills and also no real IT department.  With that said, why would Microsoft think that someone at this office would follow a 45 page migration guide stuffed with command-line entries, INI files and geeky terminology?  Don't get me wrong, I applaud Microsoft's effort to make it less painful to have real IT tools in a small office environment, but it's just not really there yet.

Now that my little rant is out of the way, here's what I did. First, I read the 45 page migration guide.  Then I recycled it. Then I set about to perform the migration myself.  Here are some of my hurdles and how I overcame them (and in some instances, how I'd do it differently next time). Oh and did I mention that I was doing this 100% remotely?

...

Old server:

• DHCP and DNS server
• Static private IP address
• 3 LOB applications
• Folder shares
• Active Directory Domain Controller

What wasn't in use (and which would have altered my plan significantly):

• Share Point
• Exchange

Bright Idea #1

Idea:  Connect the 2011 server to the existing domain as a backup domain controller, sync the Active Directory, then promote and demote the new and old server respectively.

What actually happened: The 2011 server did not want to join the existing domain and neither server wanted to trust the other for domain controller. Oops.

What I did: Started from scratch with a new domain on the 2011 server

Bright Idea #2

Idea: Use the same server name to minimize client reconfiguration issues.

What actually happened: With Certificate Authority service installed and running on 2011 SBS, the system will not let you change the server name (or domain for that fact).

What I did: Resinstalled the server OS and gave it a unique server name.

What I could have done: Removed the CA role, changed the server name, add the CA role.

So, now that the server is on-site and I'm not.  I decide to punt and basically start over.

Now we have a fresh server install, with a new domain name and unique server name. Awesome. So, let's get the LOB applications loaded and start the client migration.  This actually was fairly painless. Connecting the clients to the new domain however, had it's share of hurdles.

Hurdle 1: Cannot connect a client to the new domain when logged in to the existing domain.  Also, interestingly enough, you can't run the SBS2011 connector via RDP. To get around these issues, I installed TightVNC server on each workstation. This enabled me to have full control (as well as disconnect, log off, log on, etc.).  RDP is much more efficient than VNC, but as I would come to learn, the benefits far outweighed the choppy performance.

Hurdle 2: I quickly discovered that the SBS2011 dashboard is more than a "convenience".  SBS looks to the dashboard form MANY things. However "easy" it is to use, it's much more restricted than the traditional server tools. For example, you can't set a user logon script via the dashboard. Also, you can't specify granular permissions via the dashboard. You also cannot choose any user group except Administrator or Standard user.  Yea, I told ya it was kinda dumb. It does, however, automatically add the user to the necessary RA* groups to enable remote access and remote shared folders.  So, I added one "standard" user via the dashboard, then went in and edited that user via the normal Active Directory applet. Doing this allowed me to add a logon script, alter group memberships, etc. that aren't available in the dashboard.  One other glaring ommission from the dashboard feature set is the "copy" user tool. So to make the other users, I remained in the AD applet and used the copy feature. Which led me to the discovery of...

Hurdle 3: The dashboard and the traditional server control applets do NOT interact very well.  What I mean is that all of the users I added via the AD applet copy tool, were missing from the dashboard.  Not a huge deal, but the dashboard does give you a nice overview of users and workstations. Fortunately, I found a powershell command to populate the dashboard with users from Active Directory.  (I'm still searching for a similar method for shared folders, so if anyone knows a method, please leave a comment.)  To populate the dashboard from the AD, perform these steps:

1. Open a command prompt as an Administrator. To do this, right-click the command prompt shortcut and click "Run as Administrator". (Still not as handy as sudo on a *nix box, but getting better).
2. Type cd "\Program Files\Windows Server\Bin" and press ENTER.
3. Type WssPowerShell.exe and press ENTER. (Your prompt will be prepended with a PS.)
4. Type Import-WssUser -Name <username> and press ENTER.
5. Repeat this for each user you wish to bring into the dashboard.

You can accomplish this with a script also, but I don't think a script is very efficient for the amount of users expected on an SBS machine.

After doing this, all the users show up in the dashboard.

Now the server is up and fully functional.  One thing  missing is to migrate the new server to the old server's static IP address and allow the new server to become the DHCP server for the network.  I'll cover these 2 topics in another post, so stay tuned!