SSSD Authentication – SSSD Authentication to Windows Domain Without @domain.com Everywhere

While I can't speak to having multiple profiles for the same user across multiple workstations, I will say that if SBS2008 is anything like SBS2003 it should do a pretty nice job of joining the computers to the domain and migrating the individual user profiles to domain profiles. Of course I'm talking about a scenario where there's one primary user per workstation, not multiples like you have. IMHO this is one of the strong points of SBS, making a migration from a workgroup to a domain as painless as possible. The "Add User Wizard" does a fairly nice job of assisting you in creating user and computer accounts based on your current user and computer names. I might suggest that you pick a "primary" user per workstation and use the "Add User Wizard" to "migrate" those users and profiles to the domain, as well as joining their computers to the domain. You can then go in after the migration and pick out the pieces you need from the various user profiles leftover that are scattered across the workstations.

In my opionion 32 - 40 billable hours to perform the testing necessary for a domain rename in such a small infrastructure is insanely high.

The configuration you describe could be tested in an afternoon with a couple of physical "scratch" client computers, a virtual domain controller, and a virtual member server on an isolated LAN.

I'd start by obtaining a test domain controller by installing a VM connected to the LAN, joining it to the domain, and promoting it to a domain controller. I'd install a DNS server, mark it as a Global Catalog server, and set it to refer to itself for DNS. Once all AD replication completed I'd take a snapshot of the VM, and then demote it back to being a member server before removing it from the domain. This leaves the production AD domain in a state consistent with how it started.

I'd detach the VM host from the LAN (or otherwise isolate it), reboot the domain controller VM from the snapshot taken when it was still a DC and seize the FSMO roles to it. This gives you a DC "under glass" to work from. I'd join a couple of "scratch" client computers to the domain hosted by the DC in the isolated network, and bring up a test file server VM as a member server. Once I verified that the "domain under glass" functioned properly I'd proceed with taking snapshots (to give me a fall-back position to re-start testing) and start the domain rename resting.

Domain rename without an Exchange 2003 infrastructure to worry about isn't something you should be too scared of. It's reasonably well documented (others provide links in their answers that are reasonable) and is "supported" by Microsoft. As you've already noted, doing it before you deploy Exchange is important because this is your last chance to rename the domain.