Use Remote Desktop to trick Virtual PC and Virtual Server into using USB smartcards

Summary: Microsoft Virtual PC and Virtual Server say that they don't work with USB smartcards, but you can trick it to work by using Remote Desktop.

The Microsoft site says the following about Virtual PC 2004:

Standard USB input devices such as keyboards and mice are supported through PS/2 emulation, but Virtual PC does not support USB devices that require their own drivers.

Similarly, about Virtual Server 2005, it says:

Virtual Server currently does not support USB hardware such as smart card readers and scanners. However, standard USB input hardware, such as keyboard and pointing devices, are supported.

Although it may be true that Virtual PC and Virtual Server don't directly support USB smartcards, you can work-around this issue by doing the following:

1. In the Guest OS virtual machine (i.e. inside The Matrix if you know what I mean), go into the System control panel, Remote tab and enable Remote Desktop. You'll also need to make sure any firewall in the Guest OS allows port 3389 (Remote Desktop). The System control panel automatically configures the Windows Firewall appropriately.



2. In your real Host OS, run Start Menu -> All Programs -> Accessories -> Communications -> Remote Desktop Connection, or run mstsc.exe from the command line.



3. Enter in the hostname or IP address of the Guest OS virtual machine.
   
   
   
   
   
4. Click Options, then click the Local Resources tab and make sure there's a checkbox next to "Smart cards".
   
   
   


5. Click Connect, login to the Guest OS and run apps, etc. that use your smartcard via the Remote Desktop connection.

Debugging the Internet Explorer View Source problem with Fiddler and fixing ASP.NET

Summary: This article shows how to figure out why Internet Explorer's View Source command didn't work on an XML document, how it was debugged using Fiddler, and the ASP.NET fix.

You ever try "View Source" on an XML document and get this dialog box that says "The XML source file is unavailable for viewing."?

I got this while creating an ASP.NET page that was outputting RSS. I ran Fiddler and spied on what the web server was returning:

I didn't really see anything wrong with the output, so the next step was Process of Elimination to try removing HTTP headers until the problem didn't occur anymore. So I chose Rules -> Automatic Breakpoints -> After Responses from Fiddler's menus. This causes Fiddler to break-in and effectively pause the HTTP session so that you can change the response before the browser gets it:

Eventually, I tried deleting the Vary: * HTTP header by selecting it, right-clicking, and choosing "Remove Header". This was the header causing the problem! I did a quick check around various RSS feeds on the Internet and I didn't see any that used this header. For the detailed info on what this header is for, see the HTTP spec.

It seems that ASP.NET was outputting this Vary: * HTTP header because I used the following in my page:

<%@ Page Language="C#" CodeFile="t.aspx.cs" Inherits="t_aspx" %>
<%@ OutputCache Duration="300" VaryByParam="*" %>

The reason I used VaryByParam="*" was because my page is dependent on all of the QueryString parameters.

Eventually, after digging around, I found these two pieces of documentation:

• The OmitVaryStar OutputCache configuration setting
• The HttpCachePolicy.SetOmitVaryStart method

So if you put the following in your ASP.NET web.config file, it will no longer output the Vary: * header and then your cached XML output will be View Source-able in Internet Explorer.

<?xml version="1.0"?>
<configuration>
  <system.web>
    <caching>
      <!-- Don't send the Vary: * HTTP header when
        VaryByParam="*" is used because IE
        does not cache pages with Vary: *
        in the HTTP headers. -->
      <outputCache
        omitVaryStar="true">
      </outputCache>
    </caching>
  </system.web>
</configuration>

Proof that Digg has at least 6 web servers

The Straight p00p: Anyone on the Internet can experimentally determine how many web servers Digg.com has, due to their server configuration. If Digg tweaks their web servers to fix this, they can speed up the site and save everyone bandwidth. Anyone can try these investigative techniques on other sites, too.

The Details: A quick check with Fiddler shows that Digg.com seems to serve all its content from www.digg.com. That hostname resolves to a single IP address (they probably use a load balancer like BigIP), but we can still figure out what's going on by requesting a static file from their site and looking at the HTTP headers. I used the HEAD perl script that comes with perl and the LWP library:

>head http://www.digg.com/img/comment-1.png
200 OK
Cache-Control: max-age=3600
Connection: Keep-Alive
Date: Tue, 27 Jun 2006 05:02:41 GMT
Accept-Ranges: bytes
ETag: "870384-a72-41414d62cbc00" <-----------------
Server: Apache
Content-Length: 2674
Content-Type: image/png
Last-Modified: Thu, 18 May 2006 19:13:52 GMT

The entity tag value by default seems to be composed of the file inode value, the file size, and the modification time.

File inodes are values that make sense on a particular file-system (i.e. they're unique to the volume/partition/file-system on the box). So if the server cluster has multiple filesystems (i.e. content copied around and on each box in the cluster), it's highly likely that the inode values will be different. (of course, this assumption could be wrong if network filesystems or SANs are in use, etc.).

To test this theory, I wrote a short quick-hack perl script that makes 200 HEAD requests and shows how many unique inode values are returned. Here's the output:

>perl -w p.pl
"5c01db-a72-41414d62cbc00"
... // lot more output
"4f01c8-a72-41414d62cbc00"
INODES:

870384 = 24
430251 = 30
4f01c8 = 42
6481c8 = 31
981c0 = 34
5c01db = 39

SIZES:

a72 = 200

MTIMES:

41414d62cbc00 = 200

As you can see, there's 6 unique inode values, so that's how I deduced that Digg probably has at least 6 web servers. Back in April, it was reported that Digg had 3 web servers and just today Digg was stocking up on BestBuy boxes.

What's wrong with differing ETag values? The problem is that if you happen to access server #1 in the cluster and it returns one ETag for that file, then later you go back to the site, your browser will ask the server "give me that file, but don't give it to me if your file matches the ETag I got earlier". Well, if you're talking to server #2 this time around, it has a different ETag (even though the file content is the same), so then it has to retransmit the content to you again, for basically no reason.

Digg could reconfigure their web servers to use the same ETags across their cluster, then this wouldn't be an issue, then guys like me couldn't write these kinds of investigative reports. :-)

The technique I explained in this write-up could be used on other sites as well. Found anything interesting?