So these are the basic steps I took to get my SharePoint 2010 Development Lab up and running:

Here’s the configuration I was looking for:

Windows Server 2008 R2 DC
SQL Server 2008 R2 (not express)
Developer/Productivity Tools (VS2010, Office, SPD etc.)
SharePoint 2010 (with all the services I could throw at it going)

So I created a new clone of my Windows Server 2008 R2 machine in VMWare Workstation and got moving.  I already have Win Server, SQL Server R2, all the Dev/Productivity Tools on there.  The only thing I needed to do was change the machine name, create the domain (promote the machine to a Domain Controller) and install SharePoint.

I’ll post elsewhere (elsewhen? future…) in more detail on how I’ve built out my virtual machine tree, but I should point out here that I’ve done it wrong.  What I’ve done is created a base VM with nothing but Windows Server 2008 R2 on it, patched up, and created a snapshot from there.  Then cloned it to include my 2010 tools (Office/SQL/VS/Blend etc.).  Then snapshotted that and cloned it down to do my DCPromo and SharePoint install.  Well, I know this (because I did this same thing with the 2007 stack), but I made a pretty big error in not just building two base snapshots—one with DC and one without.  See, SQL Server gets all mad (or at least, it did at me) and breaks once you promote your machine to Windows Server 2008.  The services wouldn’t turn on, which made sense because I had them running under local accounts (also stupid).  When I tried to change the services to run under a domain account I was getting this error:

WMI Provider Error [call to WMI Provider returned error code: 0x800742a2]

Fortunately I was pretty readily able to find a KB article that gave me the workarounds to fix this issue and get the services started back up.

Once I had SQL Server back and running again, I was able to get SharePoint 2010 up and cracking with an install going against my full on SQL Server 2008 R2 Developer Edition (which by the way if you want to do anything other than Express, you HAVE to install into a Domain).

The whole purpose of this environment build-out was to start messing with Access Services inside SharePoint 2010, so I went ahead and used the configuration wizard inside Central Admin to get the Service Applications turned on.  Remarkably (probably because I’m installing everything on a single server),  this got everything up and configured extremely easily.  At this point I knew I needed SQL Server Reporting Services integrated with SharePoint 2010 in order to get Access Services working, so I went ahead and configured those two components.  After I completed the steps in there, and provisioned the appropriate access to the service accounts, it appeared that my SSRS/SP2010 integration was complete.

But alas, no, I was not finished.

When I published an Access Web Application to SharePoint I would get this error when my report tried to render:

An attempt has been made to use a data extension 'ADS' that is either not registered for this report server or is not supported in this edition of Reporting Services.

Brief sadness followed this error, but the community came through for me yet again in this forum post which directed me back to this article on technet.  By following the instructions found under To install the Reporting Services Add-in for Connected Mode, I was able to get my solution fully functional—Reports and all!

Color me psyched.