Thursday, February 19, 2009

Mounting a Virtual PC disk image with VHDMount in Vista

As a SharePoint developer, I do a lot of work on Virtual machines. I use VMware occasionally, but I mostly use Virtual PC or Virtual Server from Microsoft. Through the years, I’ve accumulated many, many virtual machine images – hard drives are cheap, so cleanup gets delayed at times.

Recently, I came across a need to get a file off of an existing VHD file for one of my virtual machines. I wondered if there was some kind of voodoo magic that would enable me to simply mount the VHD file on my local host machine without having to spin up the virtual machine to just get at a single file. The Google turned me on to this:

http://community.bartdesmet.net/blogs/bart/archive/2006/09/02/4385.aspx

Virtual server contains a command line utility called vhdmount that enables exactly what I want to do. That’s great, if you have virtual server installed. I do have virtual server installed on two different machines in my network, one x86, one x64, but the machine where the VHD file was located only had Virtual PC, and Virtual PC doesn’t come with the vhdmount command.

It turns out, that doesn’t matter – the vhdmount command that works in virtual server can be copied to a machine that has virtual PC installed, and from there it can be used to mount disks just like any machine that has Virtual Server installed. However, there’s an extra step involved…

To get vhdmount working on your Vista machine with only Virtual PC installed, do the following:

  • Copy the vhdmount folder from an existing virtual server installation. It will be located (by default) in c:\Program Files\Microsoft Virtual Server. I’d recommend copying it to c:\Program Files\Microsoft Virtual PC, but it should work from any folder. Be sure to match the bits – if you have x86 vista, copy the files from x86 virtual server.
  • Open up Computer Management (Click the Start Menu, right click “Computer” and select Manage).
  • In the left hand navigation tree, select “Device Manager”
  • From the menu, select “Action >> Add Legacy Hardware”
  • On the Welcome to the Add Hardware Wizard, click Next
  • Select “Install the hardware that I manually select from a list (Advanced) and click Next
  • Leave “Show All Devices” selected and click Next
  • Click “Have Disk”, browse to the Vhdmount folder (C:\Program Files\Microsoft Virtual PC\Vhdmount if you followed my advice earlier – select either INF file, it doesn’t matter), click OK
  • Under Manufacturer, ensure “(Standard system devices)” is selected. Under “Model”, ensure “Microsoft Virtual Server Storage Bus” is selected. Click Next.
  • Click Next to install the hardware. Be patient – it takes a while.
  • Close the wizard when finished.

If all goes well, you’ll get a success message and your new device should be properly installed under System devices in Device Manager.

image

Now, follow the instructions in the blog mentioned earlier and you should be able to mount a VHD drive in Vista without having to install virtual server.

Wednesday, February 11, 2009

Office and SharePoint – Follow Up

I just wanted to beat this topic into the ground follow up on my last post on how office applications interact with SharePoint in an extranet scenario. I created a VPC and ran through installations of all office versions from Office 2000 through Office 2007 to see how the different versions interact with SharePoint. I’ve summarized the results of my testing here.

The following table shows what happens when you click on an office document in a SharePoint document library in various office versions:

 

Word

Excel

PowerPoint

Office 2000

A

A

A

2002 (XP) No updates

B

B

C

2002 (XP) With Updates

B

B

B

2003 (No Updates)

D

D

D

2003 (NU, ActiveX Disabled)

B

E

E

2003 (With Updates)

F

F

F

2003 (Updates, ActiveX Disabled)

B *

B *

B *

2007 (No updates)

G

G

G

2007 (NU, ActiveX Disabled)

H

H

I

2007 (With Updates - Pre SP2)

G +

G +

G +

2007 (Updates, ActiveX Disabled)

H #

H #

H #

2007 (With SP2 Beta)

J

J

J

2007 (SP2 Bata, ActiveX Disabled)

K

L

L

NOTE: The add-on disabled for "ActiveX Disabled" above is the "SharePoint OpenDocuments Class (File: OWSSUPP.DLL)

KEY:

A: File Opens in browser without prompt
B: IE Prompt to open or save file, File opens in browser
C: IE Prompts to open or save file, application opens with authentication error, file does not open
D: Prompt "Some files can harm your computer…", 3 prompts for credentials, application opens but file doesn't open, 3-4 more prompts for credentials
E: Prompt to open or save, 3 prompts for credentials, cancel all 3 - file opens in browser
F: Prompt "Some files can harm your computer…", prompt for credentials, Cancel - authentication error, file does not open, Enter credentials - file opens in application
G: Prompt to open or edit, tries to open file in application, two authentication prompts, cancel both - file does not open. Credentials in either one, file opens in application
H: Prompt to open or save, 1 prompt for credentials, cancel, file opens in application
I: Prompt to open or save, 1 prompt for credentials, cancel, file does not open, enter credentials, file opens
J: Prompt to open or edit, tries to open file in application, four or five authentication prompts, file does not open. Enter credentials in one of the first three prompts, file opens
K: Prompt to open or save, 2 prompts for credentials, cancel, file opens. On close, another prompt for credentials that can be cancelled. Enter credentials on a prompt prevents future prompting
L: Same as K: without prompt on closing application
   
* Office 2003 may try to open the "Shared Workspace" task pane when opening a document in the app or the browser. This will prompt for credentials. Hit cancel - no access to shared workspace.
+ Office 2007 with vista - even if you enter credentials in the first prompt, you still get the second prompt
# Office 2007 with Vista, ActiveX Disabled - you are prompted twice and can hit cancel both times

So, for versions prior to Office 2003, office documents are designed to simply open inside the browser. This makes for a very nice experience, so long as you aren’t trying to edit the documents directly in the document library. For read only users, it would be desirable to have this experience, but alas, once Office 2003 or higher is installed, that doesn’t happen by default anymore. With Office 2003, you can disable the SharePoint OpenDocuments Class add-on to effectively turn off the document library integration features and restore Office XP open-the-document-inside-the-browser functionality:

  • In Internet Explorer, browse to a SharePoint document library. This ensures that the SharePoint OpenDocuments Class add-in gets loaded.
  • Navigate to Tools >> Manage Add-ons >> Enable or Disable Add-ons…
  • In the Show: list, ensure “Add-ons currently loaded in Internet Explorer” is selected.
  • In the list of Add-ons, select “SharePoint OpenDocuments Class”
  • Under Settings, select “Disable” and click OK
  • Click OK on the warning that you may have to restart your browser. You don’t – the effect if disabling the SharePoint OpenDocuments Class Add-on is immediate.

Note that if you do this, you lose the ability to interact with the SharePoint document library through your office applications. If you need to edit a document, either re-enable the add-on or you’ll have to edit locally and re-upload the document when done.

Note that disabling the add-on with Office 2007 doesn’t make documents open in the browser – they still open in the application. They even still prompt for credentials, even though there’s no benefit to entering credentials. This is the FrontPage check I wrote about previously.

For fun, I even tested the Office 2007 SP2 beta, and I kind of wish I hadn’t. There are even more credential prompts. I really feel sorry for the end user that just wants to read a document posted on SharePoint and has to constantly deal with all these credential prompts. Hopefully some of that will be cleaned up before SP2 is released.

One other surprise was that the prompting in Office 2007 behaves a little differently with Windows XP as the client rather than Vista. With XP, if you enter credentials in the first prompt, you don’t get prompted a second time. With Vista, you’re prompted twice no matter what.

Monday, February 2, 2009

Office Applications and their Interaction with SharePoint Document Libraries

One of the cool things about Office 2007 applications is that you can work with SharePoint document libraries from directly within the application. For example, if you click on, say, a PowerPoint document in a document library and open it directly without saving it first, Office will make a connection to the document library and give you additional functionality. Things like the Document Management task page, the enhanced save as dialog, etc. all use this voodoo magic to make your interaction with SharePoint seamless from with your application.

It’s all fun and games while everything is on the same side of the router – as long as you and your SharePoint server are all in an intranet scenario, everything works together nicely and seamlessly – you authenticate once against the SharePoint server, probably using the same domain credentials you used to log onto your own machine, open your document, work with it, save it, manipulate your document library, whatever – all without having to re-authenticate.

What happens when you and your SharePoint server are separated by a router – an extranet scenario? That’s where things get a little dicey. I recently helped set up such a system by exposing a SharePoint site to the internet using ISA Server 2006. I plan to go into detail on how I set this up in a future blog, but for now, know that ISA handles all the authentication using LDAP connections to active directory, and users are then authenticated to SharePoint using NTLM from ISA to the SharePoint server. The login is done with Forms authentication on ISA, and Office applications have no problem performing their own voodoo magic to recognize ISA’s form prompt and turn it into a regular windows prompt when the need arises.

One of the first things my client noticed during testing was that even though they had logged in to the system already, when they opened office documents, they were getting prompted for credentials again. Twice. That’s right – two prompts for credentials, after already logging into the SharePoint server.

Since this was the client and I did most of the ISA server configuration to get this site on the internet, it was up to me to figure out what was going on. As it turns out, that voodoo magic I was actually speaking of that works quite well on the intranet causes all kinds of extra network calls on the internet that are guaranteed to confuse users when they encounter them.

The first thing I did was turn on monitoring in ISA server to find out what was causing the prompts to appear. I tested with a PowerPoint document, but the same problem exists with all Office applications. I ran several experiments to try to figure out what was causing the two prompts to appear, with various combinations of entering credentials and canceling the prompts without entering credentials. Here’s an ISA log entry for the file trying to be retrieved on the first prompt:

Allowed Connection

Log type: Web Proxy (Reverse)

Status: 404 Not Found

Rule: My SharePoint Extranet Rule

Source: External (555.555.555.555)

Destination: (mysharepointsite.mycompany.com 777.777.777.777:443)

Request: POST http://mysharepointsite.mycompany.com/_vti_bin/shtml.exe/_vti_rpc

Filter information: Req ID: 08843636; Compression: client=No, server=No, compress rate=0% decompress rate=0% ; FBA cookie: exists=no, valid=no, updated=yes, logged off=no, client type=unknown, user activity=yes

Protocol: https

User: (LDAP)myusername

Additional information:
1.Client agent: MSFrontPage/12.0
2.Object source: Internet (Source is the Internet. Object was added to the cache.)
3.Cache info: 0x40000008 (Request includes the AUTHORIZATION header. Response should not be cached.)
4.Processing time: 16 ms

The first thing that caught my eye was the client agent: MSFrontPage. I thought we were done with FrontPage already with the rename to SharePoint Designer, but it turns out this was something else. Look at the request – it’s a POST for /_vti_bin/shtml.exe/_vti_rpc. The Google tells me this is a test to see if the site supports FrontPage Server Extensions. A little more research tells me that when Office applications access files in a SharePoint document library, the first thing they do is check to see if the server supports FrontPage extensions. In my case they don’t, but the file PowerPoint is trying to post to exists on a secured server, being accessed over the internet, from a machine not on the domain. Yep – that’s going to require credentials. And there’s no way to turn it off.

So fine, you enter your credentials, hit OK, and PowerPoint tries to open your file. But wait – you’re prompted again! “Didn’t I just enter my credentials” you say to yourself. And you’re right, you did, but Office wants to make extra sure you are who you say you are. Or something like that…

What Office is actually doing is making another connection to the server with a different Client Agent. The credentials from the failed FrontPage server extensions do nothing to help avoid this prompt:

Allowed Connection

Log type: Web Proxy (Reverse)

Status: 200 OK.

Rule: My SharePoint Extranet Rule

Source: External (555.555.5555)

Destination: (mysharepointsite.mycompany.com 777.777.777.777:443)

Request: OPTIONS http://mysharepointsite.mycompany.com /

Filter information: Req ID: 08843643; Compression: client=No, server=No, compress rate=0% decompress rate=0% ; FBA cookie: exists=no, valid=no, updated=yes, logged off=no, client type=unknown, user activity=yes

Protocol: https

User: (LDAP)myuseraccount

Additional information
1.Client agent: Microsoft-WebDAV-MiniRedir/6.0.6001
2.Object source: Internet (Source is the Internet. Object was added to the cache.)
3.Cache info: 0x42220008 (Request includes the AUTHORIZATION header. Response includes the CACHE-CONTROL: PRIVATE header. Response includes the CACHE-CONTROL: MAX-AGE or S-MAXAGE header. Response includes the SET-COOKIE header. Response should not be cached.)
4.Processing time: 47 ms

 

This is the actual magical connection that is going to allow Office to do it’s document library voodoo – good old WebDAV. Or a version of it anyway that appears to be specific to SharePoint.

Ok, so now that we know what the prompts are for, what about supplying credentials for what we’re actually trying to do – open a file. Remember the file? It turns out that you need to enter your credentials on one of the two prompts, it doesn’t matter which one, in order to access your file. The second prompt has the added bonus of giving you access to the document library, but either one will suffice for gaining access to the file. If you hit cancel on both dialogs, you won’t get access to your file.

Unless of course you’ve already successfully supplied credentials during your current session (since the last time you logged on to the computer you’re using to access your document). If that’s the case, your credentials are cached, and you can click cancel to both prompts and still get access to your file. I’ll wait while you scratch your head…

So, the first time you access a file, you have the following four combinations of options:

Cancel both dialogs No access to file or document library
Enter credentials in the first dialog, cancel the second Access granted to the file, not the document library
Hit cancel on the first dialog, enter credentials in the second dialog Access granted to the file, access granted to the document library.
Enter credentials in both dialogs Same as above – Access granted to the file, access granted to the document library

If you look over those options closely, something may jump at you – you can always click cancel on the first prompt. If you get prompted a second time, enter your credentials there. I say If you get prompted a second time, because that second prompt may not be necessary if you’ve already entered your credentials during your current session.

Another way to avoid having to enter credentials into that second prompt is to add an entry in your network passwords:

  • Go to control panel >> user account >> manage your network passwords.
  • Click Add
  • Enter the name of your SharePoint server and your user credentials
  • Select “A web site or program credential

Note these are instructions for Vista, but I believe something similar works for XP.

You’ll still get that first prompt when Office tries to determine if FrontPage extensions exist on the server. If anyone knows how to get rid of that prompt, please let me know.