I rebooted my clustered Hyper-V server. When I logged back on a test Virtual Server was showing a 'Saved-Critical' state. Attempting to start it resulted in the error message 'failed to restore virtual machine state'.

The issue? I had not made the VM clustered, so it was trying to launch the server without having access to the drive where the VM was stored. DOH!!!

Roll it back and start it, no problemo....

Recently someone reported that a banner ad they wanted posted on a page was not showing up internally, although it did when viewed from their home. The banner ad was a hyperlinked picture - snagged from an external site. What was happening internally was that the image simply did not appear, although the rest of the page rendered fine and the call to the remote site's page (wrapped in a javascript script tag) was in the page source.

When I tried to open the specific page I received a error status 64 - The specified network name is no longer available.

Suspecting that the blockage was caused by ISA, and also suspecting that the blockage might actually be a good thing, I loaded fiddler on a outside client and tried to access the page. Sure enough, fiddler (once again) came through. The issue? In the words of fiddler 'This buggy server did not return headers.'

The issue is that whoever was returning the code stripped out all headers. While browsers will let that pass, ISA will block it.

The solution? Fix those darn headers!!!!

Recently when playing around with the Sharepoint 2010 beta I extended a site to use Forms and passed that through ISA 2006.

This is all very basic stuff, there are a number of good references on how to set this up, but what I did not expect was the http 500 internal error on my browser (see below).

The solution was to modify the HTTP filter (egad! an error message that actually gives the correct problem!) within ISA for that Rule (right-click the rule and select "Configure HTTP") and uncheck "Verify normalization" (see image below). I do not know if this is restricted to Sharepoint, but I suspect that will all the razzle-dazzle that SP2010 is trying to pull off it is tripping over the big feet of ISA...

This was verified by checking the logs. I tried many, many things to resolve it, including making sure "Network Service" had full control over the 14-hive, per this blog and setting up Network Service using the aspnet_regiis -SampleKeys, etc. I even disabled the UAC (see my earlier post for an explanation).

No dice.

The resolution lay, as you may be suspecting, in messed up perms on the RSA folder, specifically C:\Program Data\Microsoft\Crypto\RSA\MachineKeys. I had checked to the RSA level and Administrators had full perms (I was logged on as with an Administrative account) but I had not taken the next step and checked MachineKeys.

Turns out that that folder had removed all perms from Adminstrators. I ended up having to take ownership of the folder and give Admins full perms again. Sure enough - it worked...

As a bonus it DID fix my Search problem (I was getting "The search request was unable to connect to the Search Service.").

Maybe.