Yesterday I finally started my RC1 Server 2008 installation to replace the older Beta 3 setup. However, one piece of software refuses to install - Cygwin:

The funny part - it worked just nicely in Beta 3 (I need it for WebSVN, which now obviously is offline). But at least it seems that I am not alone with this issue: Installation problem with Windows Server 2008

A default install of Windows Server 2003 ships with a locked-down Internet Explorer, in a so-called enhanced security configuration. Getting rid of it was done via configuring the Windows components. Not so on Windows Server 2008. At first of course I looked in all the wrong places (after all who reads a text they "know"?), until I found it in Server Manager:

You can turn it on / off separately for administrator or users:

Why did I turn it off? Because when it is on, you cannot view IIS7 FREB log files - the XSL has code in it that won't run in any browser but IE. At least at Beta 3 of Longhorn, that is.

Bill Staples put together a post on what's new in IIS7 Beta 3. He also talks about the all-new IIS7 FTP server (which I knew about for a long time - I had hoped Beta 3 would be available for my MSDN Briefing in Vienna last month, but no such luck). Also, he mentions the GoLive! license for IIS7.

Be sure to check out IIS.net, the Web site dedicated to IIS7. There you will find forums, whitepapers, webcasts, HOL virtual labs, walkthroughs, FAQs and more.

Today I set up my new laptop with Windows Vista - a "dry run" for Beta 2, because I want to use it as the primary OS on that machine. Part of the drill was getting my UMTS card (a Merlin U630) up and running.

First, I tried it using the standard software that came with the card. Installation went smoothly, however the Connection Manager software is based on an HTA solution, and IE7 most definitely didn't want to cooperate and kept throwing JavaScript errors (Note: I view this as a bug of the Connection Manager software, this is most decidedly not IE's fault). Dialing using this software therefore was out of the question.

So I went out on the Internet to search for a solution. At first, I tried dialing manually using AT commands, but it turned out that initializing a Merlin card isn't exactly easy-peasy. So I decided that a thorough forum search was in order. Thankfully, that search turned up a great piece of software (onlinekosten.de Community to the rescue).

What I found is MWConn (looks like that this time the international audience is out of luck, at least at the time of this writing as the software is German only). It does support the Novatel card, allows for dialing (make sure you check the default connection that is generated, at least my provider is using a different dial-in number), gives feedback on UL / DL traffic you generate, plus signal quality information. Way cool & saved my day!

On Tuesday I was presenting a Windows Vista security session, which included UAC (user account control) and respective demos. One part was showing UAC data redirection, and for this blog post I will stick with the registry side of things.

Why this redirection in the first place? Well, old legacy applications do tend to assume that you are running as admin on your box. Thus, those apps simply store "stuff" in the HKLM hive of the registry, instead of HKCU. To allow such misguided apps to run on Vista smoothly, UAC automagically redirects write operations from the actual HKLM location to a VirtualStore branch of the current user's profile.

Let's look at an example of a classic no-no:

try
{
  RegistryKey MyTest = Registry.LocalMachine.OpenSubKey("Software\\Microsoft\\Microsoft SDKs\\.NETFramework\\v2.0", true);
  MyTest.SetValue("InstallationFolder", ContentsText.Text, RegistryValueKind.String);
  MyTest.Close();
  ResultsLabel.Text ="Successfully written to registry!";
}
catch (Exception ex)
{
  ResultsLabel.Text ="Unable to write to registry: "+ ex.Message;
}

On XP, being non-admin, you would end up in the catch block. Not so on Vista. With Vista, this will work out ok, and the data will be stored like this:

Nice indeed. Or is it actually nice? Let's look at the code for reading the value again:

try
{
  RegistryKey MyTest = Registry.LocalMachine.OpenSubKey("Software\\Microsoft\\Microsoft SDKs\\.NETFramework\\v2.0", true);
  ContentsText.Text = MyTest.GetValue("InstallationFolder") asstring;
  ResultsLabel.Text ="Successfully read from registry!";
}
catch (Exception ex)
{
  ResultsLabel.Text ="Unable to read from registry: "+ ex.Message;
}

So what's your guess where the value will come from - the original HKLM location or the redirected HKCU VirtualStore location? Right, the VirtualStore is the winner.

Now, I intentionally picked an existing value in the registry to "overwrite". Imagine somebody writing a "fuzzer" to go over every single value in HKLM and write back gibberish for every value it finds. The original application will now too see this gibberish instead of the original good values.

Time will tell whether virtualizing based on user and not application will create more havoc than do good. Because thanks to UAC malware needs no extra rights to botch up your registry...

Update Yes, sure, you can turn off this virtualization. Check out the blog entry User Account Control Windows Vista Policies.

A friend of mine pointed me to the article The Windows Vista Developer Story: Application Compatibility, Migration, and Interoperability quite some time ago (shame on me for not mentioning it earlier). It is a very useful resource when you have to deal with adapting existing applications for the changes that come with Windows Vista.

Topics of this article include:

• Thirty-Minute Compatibility Check
• Operating System Versioning
• User Account Control
• Windows Resource Protection (WRP)
• Internet Explorer Protected Mode
• Windows Vista 64-bit
• Microsoft Graphical Identification and Authentication (GINA)
• Session 0 Isolation
• Networking: TCP/IP Stack and the Windows Filtering Platform
• Networking: Kernel Mode IP Helper APIs
• Networking: IPv6
• Compatibility Risks

There is one feature coming with IIS 7 (http.sys, as such it is more an OS feature) that I have been waiting for a long time: being able to see what's in the kernel cache! The key to this new supercool feature is the netsh command:

C:\Users\Administrator>netsh http show cachestate ?

Usage: show cachestate [[url=]<string>]

Parameters:

    Tag       Value

    url   -   Fully qualified URL. If unspecified,
implies all

              URLs.
The URL could also be a prefix to registered URLs

Remarks: This command lists all resources and their associated properties

         that are cached in HTTP response
cache or displays a single

         resource and its associated properties.

Examples:

      show cachestate url=http://www.myhost.com:80/myresource

      show cachestate

Some information can be obtained in the article New Networking Features in Windows Server "Longhorn" and Windows Vista (you can even flush the cache), and here is how it works if you browse to the default Web site of IIS 7:

C:\Users\Administrator>netsh http show cachestate http://localhost

Snapshot of HTTP response cache:

--------------------------------

URL: http://localhost:80/pagerror.gif

    Status code: 200

    HTTP verb: GET

    Cache policy type: User invalidates

    Creation time: 2006.3.21:23.30.16:0

    Request queue name: DefaultAppPool

    Headers length: 187

    Content length: 2806

    Hit count: 1

    Force disconnect after serving: FALSE

URL: http://localhost:80/iisstart.htm

    Status code: 200

    HTTP verb: GET

    Cache policy type: User invalidates

    Creation time: 2006.3.21:23.30.14:0

    Request queue name: DefaultAppPool

    Headers length: 233

    Content length: 774

    Hit count: 1

    Force disconnect after serving: FALSE

Tracking caching behavior will be so much easier.

IIS 7.0 Beta: Operations Guide
IIS 7.0 Beta: Feature Reference

Aside from disabling UAP, I also went back to THE Administrator account. Doing so can get quite messy unless you join your Vista box to a domain, as outlined in the blog entry Trouble signing on as THE Administrator on 5308? Now I have access to applicationHost.config again. Good security does get in the way, but this is just way too onerous.

After 'killing' three Vista installations yesterday, laziness got the better of me. I launched msconfig.exe, went to the Tools tab, and did this:

A reboot later I am a happy (and no longer annoyed) camper. Security obviously went out the window, however, I don't think this installation will live long enough either for this to be an issue.

How to get from here

to here:

Step 1 - enable the Navigation Pane:

Step 2 (if you don't already see it):

You need to click on the up arrow next to the Folders text (it is like an Outlook tab, but rather hard to see).

Not only is Standby not possible since initial installation, now even Hibernate balks at my sincere request for cooperation:

Not that it worked great before - the last hibernation took almost three minutes for 1GB of memory. The XP installation on the same box still works fine... I have the sinking feeling I am in for more "surprises".

Application note: Forgot to mention that Daemon Tools wouldn't install, but that I almost expected.

Update Longhorn experiment terminated. It hung with not even Ctrl+Alt+Del reacting any more. Looks like something went awfully wrong with my installation.

I arrived late yesterday in Seattle after a total flight time of 14 hours. If only Lufthansa were offering a direct connection from Munich. Well. At least another MVP had to endure the same route with me: Christian Wenz.

Learned another lesson about Longhorn yesterday in the hotel: if you have installed ISA client, and are not connected to the network it was configured for, it will balk at being disabled! Only way to straighten this out was uninstalling the firewall software. Guess I will be having some more fun in the next weeks of self-imposed Longhorn testing.

Seems that I found another application that more or less breaks entirely on Windows Server Codename Longhorn: SharpReader. It does load the feeds and cache correctly, however, one thing does not work at all - refreshing the feeds. I'd say that this pretty much renders a RSS reader useless. Darn. Especially now that I got everything else up and running, including #develop 2.0 Codename Corsavy Build 510.

Update PEBKAC. I didn't install SP1 for .NET Framework v1.1. Now SharpReader works as expected. Note to self: having a WSUS server up and running for your other boxes really can spoil your Beta experience.

In preparing my laptop for Seattle, I had to copy my SharpReader configuration, which lives in Documents and Settings\<username>\Application Data\SharpReader on my XP box. I did that many times before, however, this was the first time for Longhorn. Again, I was in for a surprise - first, it is now AppData, second, there are two renditions: Local and and Roaming.

I picked the correct one by chance (Roaming, although Administrator is a local account). Seems I have to learn a lot more about Longhorn than I previously thought.

For those of you also going to Seattle, you should read UF's The Lord of the Rings.

I already have one box (the Shuttle XPC) that is running Windows Server Codename Longhorn Build 5219. Because it wasn't all that much of a hassle when compared to Beta 1 of Windows Vista, I decided to set up Longhorn on my laptop - and try to work with that installation for a week, while I am in Seattle for the MVP & AspInsiders summits. Boy did I end up with an installation marathon...

Lessons learned in this Sunday's "don't try this at home kids" department:

• Don't assume that ATI drivers for your IBM X31 will install on Longhorn. They refuse, making for rather crappy UI performance. By the way, on failing, setup suggests to install a VGA driver first.
• None of the network adapters were found - neither the onboard LAN, nor the onboard WLAN. When you peek into Computer Mangement, it is your guess which of the two "Ethernet Controller" is which.
• Don't only update the driver for one, even if it is the LAN one. Your ISA 2004 client installation will mysteriously fail. After installing drivers for all LAN equipement, it just works.
• Minor annoyance: the OS-provided sound driver produces hisses et al. Not too bad, but annoying if you plan to watch loads of Channel 9 movies. Your guess is correct: the vendor-provided driver refuses to install.
• No standby. That sucks royally.
• You learned about that in my previous post - no .NET 1.1 for you by default.
• Installing VS can be so much fun, especially if MSXML 6.0 refuses to install as part of the default install. Doing it separately works so much better. And the "Locate File" dialog for the VM driver irritated me only for the better part of a minute...
• Before installing the Atlas VSIs, you better start VS at least once. Otherwise the Atlas installation will fail. Only mildly interesting.
• Do I need to mention that Virtual PC networking doesn't work? That one didn't change for the better, which will make me dual boot into XP.

On a different note: default installs of 5219 have a blank password for Administrator. And IIS 7 is installed by default, which really baffled me. I'm so trained to enable features after install that at first I was thinking it was not part of the bits I got...

Seen today on Windows Server Codename Longhorn, Build 5219 (the PDC build). At first, I thought Paint.NET was kidding me, but once I checked with Windows Explorer, I knew this was for real. Doh!