Windows Vista and Windows Server 2008 both disable administrative access when accessing via a network. So all those administrative things you're used to doing, like accessing an administrative share (\\machinename\D$) have to be thrown out when you use Vista or Server 2008.

However, you can bring it back, Windows XP / 2003 style. The key is in the registry, at KHLM\Software\Microsoft\Windows\CurrentVersion\Policies\System. Add a DWORD value named LocalAccountTokenFilterPolicy with a value of 1. Reboot.

Something I like about Windows Server 2008 x64 is that it (finally) gives the user the benefit of a doubt when disabling the advanced security options in Internet Explorer. Now it automatically prompts me to install ActiveX controls, for instance, and when I download files from the Internet I no longer have to right-click the file, choose Properties, and "Unlock" before I can use them without security warnings (this being something I've been habitually doing on all file downloads since IE7 was released).

But all is not trusting. I was tinkering with the recent release of the the new OS when I noticed as I was saving stuff to my Program Files directory in a new subdirectory that the new subdirectory didn't exist. Namely, I downloaded Notepad2 and attempted to create a new directory at C:\Program Files (x86)\ called "Notepad2" where I would save the file, then open the directory up in Windows [File] Explorer to unlock and extract the .zip file. Lo and behold, my Internet Explorer "Save As..." dialogue box told me I was looking right at C:\Program Files (x86)\Notepad2, but Windows Explorer insisted that no Notepad2 directory exists in C:\Program Files (x86). Could it be a bug?

Directory virtualization, perhaps? Indeed, I've seen Microsoft do this more and more lately. I knew where to look: C:\Users\jdavis\ ... hmm that's right, Local Settings got moved to AppSettings\Local. VirtualStore? Yes! There it is! "Program Files (x86)", and in there, a "Notepad2" directory, all by itself.

I don't want this. I REALLY don't like this. Microsoft implemented this virtualization feature to work around insecure design bugs in software. Whose software, though? Theirs? Ours? Third parties?

I mean, come on, Microsoft, if you're going to virtualize the Program Files directory like this, go all the way with it and do it in Windows Explorer and the command prompt as well. Heck, do it at the kernel level so that any app running in user space sees this thing where it really is.

Or not. I don't like virtualized paths. It's an administrative nightmare. Let's disable this thing.

So, after turning off UAC from the User Accounts control panel, which I hadn't done yet to this point, I rebooted and still had this problem. Then I tried disabling Local Security Policy -> Security Settings -> Local Policies -> Security Options -> User Account Control: Virtualize file and registry write failures to per-user locations. I think this fixed it. I'll update this blog entry if I find otherwise.

I realize why Microsoft implemented this file path virtualization thing, but IMO it's a crutch and does NOT demonstrate good computing practices despite what some IT folks would proclaim. This is the kind of stuff that just makes computing all the more confusing and difficult to work with. While the intentions were valid, we don't need anymore unexpected twists and turns in our computing experiences.

UPDATE (1/17/2009): This HORRIBLE "feature" ended up in Windows 7 as well!! To fix it now you need to open "Security Configuration Management" where you'll find Local Policies -> Security Options -> "Virtualize file and registry write failures to per-user locations" and disable the thing.