Using Windows Server 2008 as a Desktop OS - Installing Windows Live Writer

I'm using Windows Server 2008 as my primary desktop OS, for which I'll be blogging on over the coming weeks as I encounter non-obvious problems. I'll also cover my installation experiences which might help out others who wish to do the same.

The recent problem I had is that I saw the Windows Live suite of applications come out of Beta and I wanted to try them out. OK, up to the Microsoft Downloads site for the Windows Live category and download Windows Live Writer to use it on my Blogger account.

I download WLinstaller.exe, run it and I'm immediately presented with the following unhelpful error:

Hmmm, no Windows Live Writer for my Terminal Servers then.

Undeterred, I download and install Windows Live Writer on a spare Windows XP machine, open up regedit and navigate to HKLM\Software\Microsoft\Windows\CurrentVersion\Uninstaller and go browsing for Windows Live Writer. Within a couple of minutes I find the entry and also find that it has cached the MSI to:

C:\Program Files\Common Files\WindowsLiveInstaller\MsiSources\Install_{9176251A-4CC1-4DDB-B343-B487195EB397}.msi

So I copy this file to my Windows Server 2008 laptop, expecting to have to modify it with Orca. What the heck, I'll try running it first. And it installs without problem. And I'm using it just fine, as this blog article is written using it.

I'll try the same trick with the other Windows Live programs and write up my findings accordingly.

Desperately Awaiting Windows Vista SP1 (or why Power Users should use Firefox)

IE7 under Windows Vista (and also under XP) is driving me nuts.

I frequently have 20-30 browser tabs open. These tabs generally contain my reading list and I place them in reading order. I also have a second IE7 window open for general searches and Webmail.

About once a fortnight I have IE7 crash on me. What really sucks is a lack of built-in IE7 crash recovery. For that I use IE7Pro. It does a reasonable job.

Sometimes the crash recovery just doesn't work all that well. When it doesn't work, I use TravelLog to pull out my URL history, then use FileParse (with XP compatability enabled) to reformat the output so I can quickly process the URL history in Excel.

This is obviously time consuming.

The final nail in the coffin for IE7 on Vista for me is that when I have 32+ tabs open I get a Denial of Service on Windows Explorer. Yes, that's right. When I exceed 32 tabs and go to the Start Menu and click on Computer, Explorer opens and then immediately closes. If I reduce the tabs to less than 32 I get Explorer functionality back.

This is a serious regression from Windows XP. Under XP I don't get this DoS. Under XP, it takes about 64 tabs for the interface to screw up, but this only affects IE7. Windows Explorer in XP still remains functional. The obvious indication of exceeding the capabilities in IE7 is that tabs fail to render content and also losing the ability to bring up right-click menus. This also occurs under Vista, but at a tab count of about 32 and with the added bonus of a Windows Explorer DoS.

So I'm now installing Firefox 2.0 and will be using this as my primary browser. This will improve my browsing efficiency and will stop my blood from boiling when IE7 crashes, or Explorer stops loading.

I really, really hope Vista SP1 fixes this.

Disable Network Authentication Credentials Storage on Windows Desktops

It seems like I'm having to debug authentication-related problems several times a week, all with different symptoms and each with different errors in the Event Log. Today was the last straw.

I've decided to disable this poorly constructed component via Group Policy. Here's how I did it. I opened up Group Policy Management Console and created a new Group Policy Object.

Computer Configuration > Software Settings > Windows Settings > Security Settings > Local Policies > Security Options

Find the entry named "Network access: Do not allow storage of credentials or .NET Passports for network authentication". Enable this.

Assign the GPO to the appropriate OU and restrict using Security Groups as appropriate. I'm scratching my head wondering why I didn't do this a long time ago...

Windows XP - Corrupt secedit.sdb

Sigh. Another day, another problem.
This time it was the logging of Event ID 1202, source SceCli and Event ID 1000, source Userenv. I looked in C:\WINDOWS\security\logs\netlogon.log and found that there was an "Error creating database".
A quick google found MSKB 278316. I followed the instructions, but the note about ignoring the "access denied" error is bogus. I got round this by opening security.sdb instead of secedit.sdb, then renaming it to secedit.sdb after creating the database and closing MMC. My quest for eradicating errors in the Event Log continues...