Disable Chrome Frame

Now that Google has ended support for Chrome Frame (see here) the time has come to transition to their new Legacy Browser Extension.  I've run into a few systems that I'm unable to remove Chrome Frame from.  This wouldn't be an issue except that we have a new site that's IE only, and Chrome Frame is ignoring the policy to render the site with IE.  So now they open it in Chrome, the LBS extension kicks them over to IE and then it gets rendered in Chrome Frame.  That's extremely helpful, right?  Easiest solution is to remove Chrome Frame, right?  That would work great if it would uninstall, but the uninstaller fails.  So I tried to install a newer version so I that I could maybe get it to uninstall.  That didn't work either, the installer fails.  So what about a quick and dirty way to disable Google Chrome Frame?  You can go into IE and disable it through the Add-On Manager, but I need to disable it on a bunch of machines.  How can you do that?  Just push the registry key to the machine that says disable the Chrome Frame.  What is that registry key?  Actually, it's two keys and here they are (just cut and paste this into a .reg file for easy import).

Windows Registry Editor Version 5.00[HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Ext\Settings\{ECB3C477-1A0A-44BD-BB57-78F9EFE34FA7}]"Flags"=dword:00000001"Version"="*"

Import those keys to disable it and just delete them to re-enable.  Which hopefully you will never have to do once you get Legacy Browser Support up and going.

This is for my old XP machines.  I haven't run into this issue on Windows 7 yet, so I haven't bothered with testing it there.

Changing XP Wallpaper from ZENworks

I mentioned in a previous post  ( Changing XP Background (Wallpaper) Images ) about creating a ZENworks application to reset the background or wallpaper image.  But I should have tested my app more thoroughly as it took a little tinkering to get it working.  ZENworks veterans probably wouldn't have made this mistake, but as I'm new to version 11 (made the jump from 7) I did make the mistake.

The most common bundle action that I use is one of the "Launch" actions, whether it's an executable or an installer.  Those actions by default run as the logged in user.  What I found out is that "Registry Edit" actions by default execute as the System account.  Which is probably great for making sure that the settings apply, but that's not so great when you're working in HKEY_CURRENT_USER.  But there's an easy fix for that.

In the action properties just go to the Advanced tab and look at the "Run Action As" section.  There's two ways to run it as System and as User.  When you pick System there's one optional setting "Apply HKEY_CURRENT_USER changes to the logged in user's hive instead of .DEFAULT".  The is fix is to check that box to make it work.  Easy enough, right?  I probably could have used the run as user option, but I tried checking the box worked and that fixed it, so I didn't try it with the user option set.  

Here's picture so you can check that we're both looking at the same thing.   

Changing XP Background (Wallpaper) Images

I know, I know, XP's old.  But this is Practical School Tech and education is a little behind the times.

We had a couple of student systems where the students had set a background image by right-clicking images in IE and setting them as the wallpaper.  Cute trick, right? But it's a pain to undo on a system where they don't get rights to the Display Properties page.  The setting is stored per user (that way everyone can have their own) which is great unless your using a generic account that several students share.  So how to undo it?

I though I'd start with the background image file.  I did some Googling and most places said look in here 
C:\Documents and Settings\Local Settings\Application Data\Microsoft\

But that isn't the right path, but it's close, it's really in
 C:\Documents and Settings\Application Data\Microsoft\Internet Explorer

Or if you want to find it in a batch file (or just typing by hand), try this path instead
%AppData%\Microsoft\Internet Explorer

After finding the file I wanted to know where it is set in the registry.  Since the image was set from inside IE file name was a very descriptive Internet Explorer Wallpaper.bmp.  That's fairly unique, so I just searched through the registry for that file name.  It turns out that path is stored in
HKEY_CURRENT_USER\Control Panel\Desktop

To clear the background image out I just blanked out the registry here.
HKEY_CURRENT_USER\Control Panel\Desktop\Wallpaper  

After a reboot (or log off and log back on) the background image will be cleared and you'll be back to the pleasant soft blue.  

But I didn't want to stop there.  I wanted the change to go into affect immediately. I new when I changed the background through the Display Properties that the change happened right then.  So that means there's a programmatic call somewhere that can make that happen.  I had figured it was probably in some windows dll file and since wallpapers had been around so long that it was probably in one of the more common ones.  A little more Googling and I came across this line

%SystemRoot%\System32\RUNDLL32.EXE user32.dll,UpdatePerUserSystemParameters

I crossed my fingers and gave it a shot and what do you know, it actually worked.

So I take all this information and roll it into a ZENworks bundle that deletes the key and then calls the UpdatePerUserSystemParameters to make it go into affect immediately.

CD Burning for Power Users in XP

What happens when you've got non-Administrator users (like Power Users) that need to burn CD's under Windows XP? It must be group policy setting, but where? I went over the local group policies with a fine tooth comb and couldn't find the "Allow Non-Admnistrator users to burn CD's" settings. There are a lot of crazy ideas floating around the internet about how to make this work and most of them don't work. But, I did come across 2 (or 3, depending on how you look at it) working solutions.

I actually first encountered this problem some time ago, but the problem recently reappeared. I couldn't find my original notes on how to fix it so I turned to Google, armed with a vague idea of the solution and found the answer within a few minutes. Now I'm making notes for all the world to see and hopefully, this post will be of help to someone else.

The first solution, and seemingly more popular one on the internet, is to use a small application from the makers of the Nero called Nero BurnRights (you can find it here http://www.nero.com/enu/support-nero6-tools-utilities.html ). You can install and configure it by hand if you want, but it's easier to automate it with a script or batch file. There are a few command line switches to help out. The switches I liked were: /silent and/burnrights:all. That sets everyone up to be able to burn and makes the installation silent so it doesn't interrupt anyone while it runs. There's only one catch, you have to be an administrator to run the installer. Otherwise the installer craps out (silently, of course) and it doesn't actually install anything.

Now, I don't have Nero installed on every computer, a lot of them run InfraRecorder. This problem shows up in InfraRecoder as the program launching but not being able to see any available burners. It seemed to be overkill to have to install one application to make another application run so I wanted a better and easier solution. Where's that simple group policy setting or registry key that fixes this problem? Obviously if one group (Administrators) can burn and another group (Power Users) cannot burn then it has to be a fairly simple rights issue. I worked off and on for several days when I stumbled upon the solution in an unlikely place. Over at AppDeploy.com I was looking at some of the configuration settings for the Nero suite ( http://www.appdeploy.com/packages/detail.asp?id=627 ) and I found in the notes section that TheWorkz had answered my questions:

I have found instead of using Nero Burn Rights for user rights to Low Level Device Access in Windows XP, you can use the following registry key/Policy to enable users rights to CD Drives.

Registry Key:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
"allocatecdroms"="1"

OR

Group Policy
Policy: Local Policy > Security Options
"Devices: Restrict CD-ROM Access to Locally logged-on users only" = Enabled

There it was, as simple as that (imho a lot easier that the BurnRights solution listed above). I'd seen that group policy setting before, but my logic had been flawed. I had incorrectly assumed that I needed less restriction instead of more. One might argue that if you apply "Microsoft logic" that it all makes perfect sense. Whatever the case, changing this setting works.

You might be saying, "Come on! Still battling with Windows XP?" This is 2009 and we all know Windows Vista has been out for a while and Windows 7 is right around the corner. But this is practical school tech, and for all practical purposes Windows XP is going to be around for a while in public education. I've got Windows 98 machines still floating around and I know of school systems that have gotten rid of their last Windows 3.11 machines in just the past few years. If it upsets you that your children are using really old computers at school, call any politician that you know and tell them that more money needs to go to technology in education. In this economy they may laugh at you, but once the economy turns around it might help. It can't hurt can it?