I have been using CloudShare for a little over a week now and have found it to be a convenient, cost-effective way to provision virtual environments to suit my development and testing needs. The time and money CloudShare saves me over having to procure the necessary hardware and software and install operating systems and applications myself has been HUGE. I can have a brand new server up and running, pre-configured with all the applications I need in a matter of minutes. I have also been very impressed with how quickly the machines come back up after a reboot. In spite of all these great things, CloudShare is a little light in the area of “how-to” documentation and their user support forums do not appear to be very active.

My primary objective at the moment is to use CloudShare to test various MOSS to SharePoint 2010 migration scenarios, particularly with respect to Claims authentication and the numerous problems users have encountered upgrading to Claims-based web applications in SharePoint 2010 (stay tuned for some blog posts about these problems in the future). In order to adequately test these out, I need a single domain with the same set of users and groups to test various pre- and post-upgrade scenarios.

In order to create this environment, I knew I needed to follow these basic steps:

1. Provision and configure a MOSS environment. For this, I set up a “SharePoint 2007” CloudShare machine which in addition to giving me MOSS, also took care of creating the domain shrpnt.loc on which I will ultimately be configuring a new SharePoint 2010 instance. On this machine, I have set up a number of different web applications including one with Forms-Based Authentication (FBA) tied to a custom authentication provider. I will also create a new SQL Server instance on this machine to host my SharePoint 2010 configuration and content databases.
2. Once the MOSS environment was complete, detach my MOSS content databases. To fully replicate the issues I have seen in various production environments, I wanted to use the “database attach” upgrade method described in detail here.
3. Create a new SharePoint 2010 farm on a new server on the same domain. Here is where things with CloudShare get tricky. They have plenty of pre-configured SharePoint 2010 virtual machines available, but all of them are already joined to a domain (obviously a different domain than the one that would be set up in my initial MOSS environment). I’ll describe how I work around this shortly.
4. Attach the new content databases in the SharePoint 2010 farm. After running the Mount-SPContentDatabase PowerShell command, this will automatically upgrade them to SharePoint 2010. From here, I am good to go and can continue with my testing.

As much as I would have loved to see a “Windows Server 2008 R2 Enterprise 64-bit with SQL Server and SharePoint 2010 install media available” option, CloudShare has no such offering. The next best thing, I assumed, was to take their “SharePoint 2010 (Clean Install)” VM and do the following:

1. Run dcpromo to remove Active Directory Domain Services from the machine, effectively un-joining it from its domain. After restarting, I also removed the “Active Directory Domain Services” and “DNS Server” roles from the server.
2. Join the machine to the existing shrpnt.loc domain by performing the following steps:
   1. Add the IP address of the shrpnt.loc domain controller as the primary DNS server on the VM I want to join to that domain.
   2. On the new VM, join it to the shrpnt.loc domain using the domain administrator credentials from the shrpnt.loc domain.
   3. Restart the new VM and enjoy being able to leverage the users and groups defined on the shrpnt.loc domain.

   NOTE: After doing this, CloudShare needs you to hold its hand a little bit to let it know about the “new” domain to which you just joined the SharePoint 2010 VM. If you use the browser-based client to access your servers and do not make this change, it will attempt to log you in with an account that is no longer valid. This value can be set by going to “Edit domains” under “Edit Environment.”

   

3. After another restart, run the SharePoint 2010 Products Configuration Wizard. When it errors out trying to find the original farm, choose to disconnect the server from the existing farm.
4. Re-run the SharePoint 2010 Products Configuration Wizard, this time telling it to create a new server farm.

After completing this step, I now have a fresh SharePoint 2010 farm from which I can begin my migration testing. I wish CloudShare had some way to allow users to perform fresh installs of SQL Server and SharePoint 2010 on a Windows Server box without a pre-configured domain VM, but until they do, I believe this is an adequate workaround.

Please post any suggestions for improvements or enhancements to this process in the comments. Thanks!