If you haven’t already checked it out, definitely head over to Tom’s hardware for their article on setting up “GodMode” in Windows 7 (apparently it works in Vista too, dang, wish I’d known that).

Basically, you create a folder somewhere, then rename it to

GodMode.{ED7BA470-8E54-465E-825C-99712043E01C}

When you do, that folder becomes a “virtual folder” full of (on my system anyway) 278 links to virtually every administrator type function you might ever want to jump to on a Windows Machine. Here’s a sample screenshot:

Very, very cool indeed.

I’ve just finished paving my main machine with Windows 7 64 bit, and was working on tidying up some of the finer points of my installation.

One minor item I use is a batch file with a reference to the excellent Poweroff utility. The batch file basically powers down the monitor, locks the machine, then goes into standby/hibernate mode. I attach it to a Ctrl-f11 hotkey to make it a quick keystroke to powerdown my machine.

Anyway, I have that bat on my path, and I happen to keep it out on a network drive (a NAS array), not on my local machine. I generally keep data off my local machine, preferring to only have program installs and temp files locally.

But when I pointed my shortcut to the network path and hit Ctrl-F11, I’d get that annoying “The publisher could not be verified” prompt. Every time!

Well, a few googles later and I came across this tip on annoyances.com.

It’s for Vista, but it also works in Win 7 (even the 64bit version).

Run gpedit.msc 

Go to User Configuration >> Administrative Templates >> Windows Components >> Attachment 
Manager

Add "*.exe; *.bat" to the "Inclusion list for moderate risk file types" setting.

I added *.bat to the list, as well as *.exe because, in my case, I keep a number of handy BAT files in folders out on my network drives and then include those folders in my path.

Works a treat. Be sure to read up on why to include this in the Moderate risk element and not the High Risk, though. Generally, if you have a reasonably good firewall/router, making this change should be safe.

(No not that kind of volume!)

Seems like such a simple thing. If I'm on Skype or in general trying to use a mic in Vista, the sounds from the mic end up projecting out the speakers.

No big deal until the volumes get loud enough that you get a feedback loop. Then, look out! Dogs and cats (and wife and children) will run screaming from the house!

I'd dealt with this problem for far too long (Skype was almost unusable) but couldn't find anything on the web addressing the issue, at least not for Vista.

So I started poking around.

After far too much searching, I finally came across the secret room in Vista where the souls at Microsoft have stashed the hidden switch.

First, right click the speaker icon in the system tray (at the bottom right of the screen), and select Playback Devices:

On the next dialog, select Speakers and click properties:

On the next dialog, select the Levels tab

And make sure that little speaker icon under Input Monitor is DISABLED (like it is in the above screenshot).

If not, just click it to disable it.

This will prevent the mic input from being echoed out through the speakers, and thus prevent any kind of feedback.

Sure, it's simple now.

I wrote about my headaches with the Cisco VPN client some time ago.

I thought I'd resolved those problems, but as is the case with most things computer, I had not.

At least part of the problem, as I discovered some time ago, is that the 5.0.0 version of the Cisco VPN client didn't properly deal with network interfaces coming and going, so in cases where that happened, the client would often end up trying to connect to the VPN host via the wrong network adapter.

How would network adapters come and go, you might ask? After all, they're physical cards in the machine.

But not so! If you run VMWare or Microsoft's Virtual PC, those apps create "virtualized" network adapters that come online as you start the program (and in some cases when you start each individual virtual machine) and can go offline just as frequently.

The solution (or so I thought) was to do a hard reset of Cisco's VPN service. That worked, mostly. But it still wasn't 100% complete. I still sometimes had trouble connecting that would, in the end, require a reboot.

Fast-forward to yesterday, when I couldn't get connected even after several  reboots, and I decided enough was enough.

Sure enough, some Google searches revealed that there is NOW a new version of the Cisco Client, the latest I was able to find is 5.0.4.0300.

One point to note is that this is all under Vista 32. From what I understand, XP has none of these issues.

Anyway, after a lengthy and pretty painful install, this new version appears to completely fix the problem. No Service resets required at all.

The Install

The biggest problem is the actual installation of the new version.

First make sure you write down all the connection details from your existing VPN connections. Once you've got the new version installed, you'll have to reset all those details back to what they were. This includes the host name (or ip address), passwords, username, etc).

Uninstall the old Cisco VPN client. For me, this took several reboots as the uninstall appeared to hang several times. Eventually, it did uninstall itself, though.

At this point you can try to install the new version, but I received a message that the "Deterministic Network Enhancer" wouldn’t install properly.

I had to manually uninstall the "Deterministic Network Enhancer" from my network connection properties dialog before Cisco would complete a successful install.

To do that, click on the Windows button (the old "Start" button), select Control Panel, and Network and Sharing Center".

Find you network adapter listed and click View Status.

On the resulting screen, click Properties

and on the next screen, click the Deterministic Network Enhancer and uninstall it.

Then, you should be able to install the latest Cisco VPN Client and not have any more connection problems.

Google to find the latest version.

This Vista Update, delivered 9/4/07 at about 3am (for one machine, anyways) has some serious issues, so beware.

Now, when I load Word 2007, if I immediately quit Word, it crashes. And if I attempt to load a document by dbl clicking on it, Word fails to load the document completely, just opens an empty window. Even odder though, is that I have a different machine that I pulled the update earlier for (it's set to manual update) and it's fine.

The only difference between the two that I can see, is that on the failed machine, Word was OPEN at the time of the upgrade.

Even worse, UNDOING the Patch caused the machine to fail to boot. It would start to boot up, then just shut down.

I had to use the "Boot to last known valid configuration" option, then use the System Restore Point function to rewind back to before the 3am patch.

Once I'd done that, everything ran fine again.

Ah the joys of automated updates.

Neeru Hundal has a pretty interesting and informative blog at http://msiblogger.com that's all about MSI issues.

A very good article there focuses on issues to look out for when creating MSI's for Vista (or that might end up on Vista, which means pretty much any MSI, I'm guessing).

One in particular hit me just a few days ago. Neeru indicates you need to set the ALLUSERS property to 1. He emphatically states you need to SET IT (not just leave it blank or not there at all). I've found that you definitely need to set it, but you should set it to 2, or you may end up getting UAC and "You don't have proper permissions" messages, even though you've created the install to specifically NOT require admin privileges. Originally, I had ALLUSERS set to 1 and was getting a "requires admin privs" message even though my installation shouldn't have required administrative privileges.

Another nugget:

• Custom Actions

1. Custom Actions in the UI Sequence will run with standard user privileges
2. For Custom actions requiring admin rights, mark custom action as Deferred - No Impersonate

Anyway, he's got a few other articles there, too, which make for some good reading.

I've noticed a disturbing trend with Windows Explorer in Vista.

It tends to want to choose a "helpful" view of your files, regardless of what you have TOLD it to use for the view.

For instance, even though I've explicitly turned off grouping, it seems to want to turn it back on arbitrarily, and once it's on, it seems like it's back on all over the place, not just for a single folder.

And to add insult to injury, Explorer offers this helpful grouping:

What the hell? I know. I just blogged about Star Wars. Explorer must have hooks into Live Writer!

"A long time ago" ?!^$*!@#?

It's bad enough that I didn't say to group files in this folder, but to group them and then use an arbitrary "group" like this?

I can't wait till I group by size, and at the top of the list is:

"Big ol' honkin' files"

Working with Vista, I've noticed that it tries to be a tad too helpful sometimes. I've already posted about it's proclivity for attempting to AutoTune my network card and in the process, detuning it.

There's a reason Bob failed, and a reason those annoying "Office assistants" got dumped first thing after installing Office. I suppose I should be thankful there's no 3D animated wizard bouncing out of the sidebar from time to time to "wave it's wand" on a window of mine to move it to the monitor that would be "more appropriate", or whatever.

One annoyance I've run into is that Vista tends to just "decide" that I want a particular folder to show in grouped view, or in thumbnail view, even though I've gone through the process of turning all that crap off and setting ALL FOLDERS to view in Details mode.

Grrr.

Well, I was just browsing for something completely unrelated and happened upon this posting by MVP Keith Miller about turning off the autodetect view in Explorer.

In it, he describes a reg hack that'll do just that, turn that feature off.

Here's the script (you'll need to save it to a REG file and Right click and select MERGE)

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\Bags\All Folders\Shell]
"FolderType"="NotSpecified"

Before you run it though. Load up RegEdit and check out that Bags key:

[HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\Bags

If your system is anything like mine, there will be literally HUNDREDS of entries in there.

Make sure you turn off "Remember Each folders settings", and then Delete the whole Bags key to remove all those "memorized" folder settings you didn't want to memorize in the first place. No wonder the damn registry balloons faster than Steve Fossett in a hurricane.

Ever since I disabled UAC on my Vista machine, I'd been hoping for a way to disable it only for specific users.

Then I just stumbled across a promising page for disabling the UAC prompting for administrators only.

It wasn't the "Per User disabling of UAC" that I was hoping for, but I'd take it.

In a nutshell, run SECPOL.MSC from the Start, Run box

Expand Local Policies, and select Security Options.

Find the entry "User Account Control: Behavior of the elevation prompt for administrators in Admin Approval Mode" in the list (it's towards the end) and double-click on it.

Change the setting to "Elevate without prompting".

Note that this won't work with Vista Basic and Home, because those versions don't come with the SECPOL.MSC file. Check out the blog above for a reg script for that.

So, then, I thought,  just setup an Admin user for doing standard development stuff (where the UAC is just a flat pain in the ass), then, login as a NON-ADMIN user with UAC enabled to test things out.

Well, not so fast. Turns out, even with the Automatic elevation setting on, elevation still doesn't happen quite right in all cases. Take for instance, Winternal's Process Explorer:

That Replace Task Manager option will cause a "Process Requires Elevation" prompt with UAC enabled, regardless of the "Elevate without prompting" setting mentioned above, so there's more to this that what would appear to be mentioned in the help for that security option. Granted Process Explorer is pretty low level stuff, but it's something I use all the time.

Screw that. Not worth bothering with, so off goes the UAC again.

How's this for a peculiar error message:

This one is from FileBackPC (a normally awesome little backup app). I can configured a rule for my server (which runs FileBack) to reach out to each of my workstations and grab a backup of certain folders, including the entire user profile.

There's the rub. Apparently, Vista creates a hardlink from the "Application Data" folder back to its parent. This results in a recursive folder structure that is guaranteed to give fits to any app that recursively traverses the dir structure.

Vista itself appears to "know" what's up though. You get this if you try to navigate into the Application Data folder via Explorer:

This same technique works great with XP. In the FileBack, I just had to reconfigure the rule to not traverse into that folder. Other apps might not be so obliging.

Sigh. Yet another one of "those little issues."

Apparently, DirectX supports something called "retained mode". Not exactly sure what it is or what it does.

But I just found out that one of my favorite apps, Flying Model Simulator or FMS requires it and you get a lovely dialog that "D3DRM.DLL cannot be loaded" when you install the latest FMS 2 Alpha 85

A little digging and it seems this is quite the problem with a number of older DirectX programs. I suppose MS figured that if the app is more than a few years old, nobody would possibly want to use it anymore:-(

Anyway, this forum posting discusses the problem and pointed me to the Dell web site here to download the missing file.

Copy it to my fresh and shiny clean System32 folder and I'm flying my simulated RC heli again.

Here's something interesting. If I switch windows away from FMS, it pauses in the background, which is actually quite nice.

I don't recall it doing that under XP.

Something to actually like about Vista? I...feel....so....dirty.... 

Well, I finally succumbed.

After hours of working to get some scripts going that, with XP took all over about 10 minutes the first time around, I've given up.

I simply opened the Windows Users control panel applet and turned off UAC.

Lo and behold, everything works just like it did back in XP.

I know, I know. "Users won't run with UAC turned off so how are you going to properly test your app?"

Well, how 'bout a VM with Vista in it and the UAC turned on?

Even better, my user account with UAC off, and a Test User account with minimal rights and UAC turned on. (But I haven't yet figured out how or if  you can turn UAC on, on an account by account basis, Anyone have any ideas?)

I'm not happy about it, but I refuse to spend any more of my time clicking those damn "accept" boxes.

Not only that, but I've heard not just a few respected programmers in the community say things to the effect of "Vista is just too difficult to program under, I'm going back to XP."

My question is, if running Vista without the UAC is basically like running XP, then, at least from a developer perspective, why not just run Vista without the UAC, then test on a VM with it? Does continuing on with XP bring anything to the table that Vista without UAC leaves out? From what I can tell, no.

Is it ideal? No. Is it better than XP? Well, the drivers and eye candy are nice, but otherwise, I don't see much difference. Surely there's additional security details that have been cooked in that have nothing to do with UAC, so I'll get their benefits.

And when PowerToys for UAC (Ugh) comes out and I can munge the UAC as necessary to get everything I need working properly, I can turn it back on.

On my setup, I have a file server with a RAID that generally is a bare (but SP'd and updated) Win2003 server install, ie a very minimal installation. At one point I set up ADS with a domain, DNS, etc. Nowadays, I still setup the DNS server on this box, but generally don't make use of ADS, in my (albeit weak) attempt at simplification.

On my workstations, I install Win2000/XP/Vista in Workgroup mode and use identical passwords and user accounts on the server and each workstation. That way, legacy login support kicks in and login validations still apply, but I don't have to mess with ADS and domains to make it happen. Not as secure as ADS, but not completely open either. 

One thing I tend to do, when possible, is install apps to a network drive and run them from there. I say when possible because for those apps that require COM registration, etc, this doesn't work too well. But there are plenty of apps that work just fine this way, including Trillian, Keepass, InfoSelect, NotePad++, IrfanView, etc. Keeps me from having to reinstall and redo configuration.

With the latest install of Vista, however, I was getting a "Are you sure" dialog like this every time I went to run an app off a server share.

Now, before people start screaming "Good Lord, don't turn that off, there's no telling what might have replaced that app out on the network! How do you know it's safe?!", the fact is that my entire network runs behind a firewall, and all machines run NOD32. If something infected an app out on the server share, it's just as likely to have already infected my local workstation anyway.

I'd rather not have to "accept" running any app off the server every time I want to, so what I needed was a way to tell Windows, "Hey, it's OK to run files from these locations, I'm fairly certain they're safe".

Come to find out, such a setting exists, of all places, in the Internet Settings area of the Control Panel:

Make sure the Local Intranet security is medium-low or lower. This is the default though, and doesn't appear to need to be changed.

At this point, just enter the UNC of your server, say \\MyServer (you only need to enter the root server name, unless you specifically don't trust certain shares on your server, in which case you could specify the server and share name, such as \\MyServer\MyTrustedShare.

And that's it.

If there are any significant security issues with this approach, I'm not seeing them. I have to trust my server as much as my workstations (if not more, since I rarely actually install any software on my server. Anybody care to enlighten me?

I like Apple, and I even owned a Mac for a time (a IIcx, yeah, it was a while back ).

But QuickTime is a bit annoying.

First, it keeps "offering" to install ITunes for me, even after I've clicked the "don't bug me about this again" button.

And second, on a Vista machine I have, it totally trashes the video, puts little bars everywhere. You can still see what's going on, at least enough to reboot the machine.

And reboot you must. There's no other way I've found to correct the situation once it's happened.

I started hunting for possible resolutions to this and found several mentions of this:

• Right click the QuickTime icon in the tray
• Select settings
• Click the drop down and select Video Settings
• Click the "safe mode" option
• Close and reboot

It seemed to work for a bit but the problem came back.

So I started playing with it and found that if I unselect the Safe Mode option (ie click the OPTIONS radio button), then UNCHECK the Enable DCI and Enable DirectDraw, that seems to make things much more stable. Haven't gotten the trash screen since.

Your mileage may vary.

Let me know if it helps.