Windows 2008 Server Experiences

Overview

Some weeks ago I accepted an offer from my provider to relocate the APL wiki on a new machine with more disk space, faster CPUs and more memory for the same price. The machine came with Windows 2008 Server which is more or less the server equivalent of Windows 7.

From a user's point of view it's better than XP, fullstop. And there are no drawbacks. Seems to be a good deal. Well...

Security

To improve security Vista introduced a new concept: Installing software as well as writing to the Windows\ directory and the Program Files\ directory was prohibited. Vista made a fuzz about this, requesting admin passwords all day long and got quite infamous as a result. Many people did switch off the whole mechanism to avoid this kind of annoyance, but that was no good for security of course.

Windows 2008 Server has improved in this area. It's less annoying than Vista was, with a significant improvement to security.

However, as a result of the new security procedures some things have changed in the background, and that might well cause some headache.

Files in "Program Files"

An important part of the new security concepts is that you are not allowed to write to "Program Files". At first sight that seems to be no problem: you have to have admin rights in order to install software, but that's it, isn't it? Not quite.

Given that you've just installed an app "Foo" into C:\Program Files\Foo consider these scenarios:

You want to write to a log into a sub folder of Foo.
You want to save aplcores in another a sub folder.
You want edit a config files of Foo from time to time.

Note that all this is not possible without taking action!

It first came to my mind when I was editing an Apache config file and missed the effects of my efforts. As it turned out my editor, UltraEdit, tried to save the changed config file but wasn't allowed to succeed. Instead of telling me UltraEdit saved the file in what I now call "VirtualShit":

C:\Users\Kai\AppData\Local\VirtualStore\Program Files (x86)\Apache Software Foundation\Apache2.2\conf\httpd.conf

Note that this is certainly a bug in UltraEdit. WordPad manages to tell me that the file couldn't be written to its original place and asks whether it should be saved elsewhere, but this is still quite annoying since there is no "Try as admin" button available.

Aplcores will also end up in the VirtualShit directory.

Having made it so hard to deal with these new security measures I dare to forcast that people will start to shy away from installing in "Program Files".

The Windows Registry

I never understood why people are so opposed to the Windows Registry. I agree that to configure an application INI files are the way to go rather then using the Windows Registry. But for saving user-dependent preferences the Windows Registry is great.

If you use the Windows Registry for that purpose you are using the HKEY_CURRENT_USER branch. When you install an APL application which establishes some values in this branch you won't see any problem. For example, this:

      path←'HKCU\Software\APLwiki\'
      WinReg.PutString (path,'hello') 'World!'
     WinReg.GetString path,'hello'
World!

looks just fine, doesn't it! Yes, everything seems to be fine as long as you avoid looking into the Windows Registry. If you do that with RegEdt32.EXE you will find that there is no such path in the Registry. Instead it is, at least on the APL wiki server, written into Computer\HKEY_USERS\S-1-5-21-5873051-797429366-1855703571-1016\Software\APLwiki\hello.

One could argue that because Windows not only directs the Write but also the Read that's acceptable. Well, I would disagree. I think the whole thing is a very bad idea. This kind of things always falls back on you one day.

However, for the time being we have to live with the mess, so what shall we take from this?

Adding a value manually

Note that you cannot add a new value manually to the Windows Registry's HKEY_CURRENT_USER branch: You cannot read this value!

Importing values via a *.REG file

Used to export part of the Windows Registry on one machine and then move the resulting *.reg file to another machine where a double-click imports it into the Registry of that machine?

Doesn't work on Windows Server 2008: This mechanism does not follow the redirection, so the values are actually imported to HKEY_CURRENT_USER where you cannot read them from.

@sig@