Running With Elevated Privileges

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!

This morning, I thought I would try to take advantage of the ability to publish blog posts to WordPress directly from Microsoft Word 2010. There are numerous posts out there (such as this one) that explain the basics of connecting Word 2010 to WordPress, and to be fair the process is quite simple.

Unfortunately, when I initially tried to connect to my hosted WordPress instance, I received a “helpful” error message:

Clicking “More Information” brought up a “Help with blogging in Word” page that didn’t directly address my problem, but jogged my memory just enough to clue me in. I hadn’t enabled XML-RPC from my WordPress Writing Settings (under Remote Publishing)!

After enabling XML-RPC, I was good to go (as evidenced by your ability to see this post)!

My initial thoughts about this capability:

• I like being able to use Word as a platform for composing and editing posts.
• I really like using Word to paste and crop screenshots, then letting Word manage the upload and linking of the images automatically within my posts.
• I was able to easily open posts I had previously published via the browser-based WordPress interface, and save for some minor formatting issues (e.g., missing line breaks), everything came over perfectly into Word.
• I could not readily find a place to tag my posts in the Word interface. This is a small drawback.
• I got ambitious and tried to superimpose a shape over an image. Word treated these as two separate images and inserted a line break between them. It was worth a shot.
• I wish credentials didn’t have to be sent in the clear to take advantage of this capability, and I expect this could be a show-stopper for many users. I suppose I will have to change my password often (be sure to update the account within Word after you do that).

If you have Office 2010 and enjoy using Word as an authoring platform, I highly recommend giving this capability a try!

Most everyone is aware of the new inline editing capabilities offered by SharePoint 2010 in list views. If not, just know that in the Edit View page for a given list, you can expand the “Inline Editing” section and check a box to enable it:

Checking this box will provide a streamlined list editing experience. Simply hover over a row in the list and an “Edit” icon will appear to the left of the row:

Clicking the “Edit” icon will allow you to modify values for any editable field in the list item (e.g., NOT “Created By” or “Modified” if they are in your list view, but most everything else):

You can click the “Save” icon to update your changes to the item, or the “Close” icon to discard your changes. Pretty neat, huh?

Well, what if you are like me (or my friend Laura Rogers of SharePoint911) and you like your list views styled a little bit? Perhaps just a little alternate row shading to break up the monotony of a white canvas filled with gray text? Sadly, there is a cautionary note at the end of the description of Inline Editing that will break your heart (especially if you didn’t take the time to read it when you enabled the setting): “Inline editing is only available on views that have their Style set to Default.”

This makes no sense to me, but if you apply any other style to the list (even when that style makes the simplest of cosmetic changes, as is the case with “Basic Table” or “Shaded”), you really do lose the ability to perform inline editing on the list. Here is the full list of style options and some proof that the ability to perform inline editing with those styles applied is gone:

Shaded:

Basic Table:

I don’t think I’m quite done with this one yet. In a future post, I will explore ways that we can (hopefully) take advantage of CSS to style our list views in such a way that we can keep the list view style as “Default” as far as SharePoint is concerned, but give our lists a little more style and flavor while preserving the ability to do inline editing.

Stay tuned!