The suspected cause is that I changed the network configuration settings on the old DC too early.  The challenge precipitating that change was this:  during its semi-automatic configuration process following Windows setup, SBS wants to assert itself as both a DNS and a DHCP server.  Yes, that’s good as a default.  But in an environment where the existing DC provides DNS, a separate router provides DHCP, and the new server wants to do both, I was in way over my head.  The net (pun intended) result: I recreated the domain from scratch.  Bummer. 

For what it’s worth, once I got the new DNS and DHCP services working correctly on the new SBS DC, I knew I’d done the right thing.  I verified this with a test client laptop.  In my experience, once the network stuff is working, the remaining configuration steps (e.g. User and Computer accounts) are gravy.

The next challenge was that I’d allowed SBS to install a CA, but came to realize that the "Standard server SKU" version of the CA installed by the SBS package only supports V1 certificate templates.  That’s unacceptable for my testing requirements.  The standard SKU does support auto-enrollment, though - more on that later.  Fortunately, I still had access to the VMware-based Windows Advanced Server (ADS) which had hosted an Enterprise CA in the previous incarnation of my domain. 

My first step was to uninstall the SBS CA via Add/Remove Programs (ARP).  I speculated that some additional AD cleanup might be necessary, but I didn’t pursue it - more on that later.

Next, I brought up the ADS machine, disjoined and joined it to the new domain, uninstalled the CA, and re-installed the CA (again, via ARP).  As a sanity check, I opened the mmc.exe CA snap-in to confirm that the full V2 cert template support was there.  To my great dismay, there were no templates listed at all!  The problem was that I had just installed the CA component via the local administrator account, which doesn’t have rights to write the template information into AD.  Brilliant.  In my defense, the reason I’d logged in as local admin as opposed to Enterprise Admin (EA) was that I didn’t want to over-use the more powerful account.

So I again uninstalled the CA as local admin, logged on as EA, and re-installed the CA.  Now the expected templates were present.  Good!

The final requirement was to get smart card logon working in the new domain.  To complicate matters, the new DC had auto-enrolled for a machine certificate from the standard SKU CA which no longer existed.  And for some reason, my client workstations weren’t obtaining machine certs at all.  Strangely, smart card logon had worked for a brief period, but was now failing with, "your credentials could not be verified."  So helpful.

The first thing I tried was running "gpupdate.exe /force" at the command line.  I hoped that maybe auto-enrollment would notice that the old CA was no longer present, and that pulsing Group Policy would result in enrollment against the new CA.  No such luck. 

This article - http://support.microsoft.com/?kbid=889250 - made me realize that uninstalling a CA via ARP doesn’t remove the related information in AD.  After that, it seemed natural that the old AD data was confusing auto-enrollment.  In fact, I found the steps in that article to be needlessly confusing.  The following got me un-stuck:

Result - everything is fixed.  All of the machines now have certs and smart card logon works.  Whew!