Assigning local rights through Group policy and making it work

Trouble getting local computer rights assigned through group policy?  Have you read all the articles that tell you to edit the GPO and assign the rights?  Are they still not showing up on your Windows XP machines?  That's the trouble I ran into.

Before I get too far into this.  Let's go back to begining.  We made the switch to from a Novell network (Netware servers, eDirectory, ZDM, iPrint and the Novell Client) to Microsoft network (Active Directory).  After the switch we needed someway to manage the rights that local users have on machines.  In the past we used ZENworks and when users logged into their computers (through the Novell Client), Zen would pick that up and create a local user for that person with the rights that we assigned and then seamlessly log the user into that account.  When using AD it doesn't work the same.  The users just log into the machine, because the machine is in the domain they don't get (or need) a local account.  Which is great, except that some of the people need to be administrators or power users.  I know I could go through group policy and assign specific rights, but we don't need that granular of control.  Just making them members of the local groups is good enough.

Now there's a couple of ways to get them in as member of a group.  The original way to do it with group policy was to use the Restricted Groups feature.  Doing it that way makes sure people are members of the group and that only those people are members of the group.  That's nice for some environments, but we don't need that level of control.  For us, all we need is to add people to groups from time to time.  There's a new way to do just that.  Well, I say new way, it's been around for 5 or 6 years.  Its through an addon to group policy called Client Side Extensions.  Microsoft bought out a company that was doing some neat group policies addons and then MS built it into Windows and released it free of charge for all to use.  But that's a story for a different day, the point is that I wanted to assign the group membership using this part of gorup policies. So I started doing my homework.  I read a lot of posts about using them and I dug through the MS documentation.  It seemed pretty straight forward, I made my own policy, I assigned it, then I tested it, and then I found out it didn't work.

What had I missed?  I went back through and double-checked everything.  And then I tested agian.... nothing.  And I tested again and again.  It just wasn't working for me.  As it so often happens I got pulled away to work on something else, but I had left the policies applied.  They weren't working but didn't appear to breaking anything, so what did it matter, right?  A few days passed and then I got back to working on this problem again and guess what, it worked.  Right... it worked.  Go figure.  What had changed?  I went back through everything and the only thing that had changed was my test machine.  Lesson learned, if at first you don't succeed, try a different test machine.

Now that I knew the problem was in my machine, I just had to figure out what exactly it was.  Back to the internet to see what pieces made these group policy extensions tick.  What I found was two different Windows update that make it happen.

The first one is KB915865 which covers XMLLite.  If you're running XP 32-bit here's that download link so you don't have to go looking for it http://www.microsoft.com/en-us/download/details.aspx?id=13978

The second update is KB943729 which covers the actual new Group Policy preferences.  If you're running XP 32-bit here's that download link as well, http://www.microsoft.com/en-us/download/details.aspx?id=3628

Now that you know what you need to you need to figure out what systems need it right?  Well the fastest way for me to tell if the computer is working right is to use NET LOCALGROUP ADMINISTRATORS at a command prompt.  We've got a couple of accounts that we add as local admins on all machines, if the only thing listed on that command is a "MyDomain\Domain Admins" then I know I'm missing one of the updates listed above.

How about a quick way to tell which update you're missing?  Check the C:\WINDOWS\SYSTEM32 folder.  The XMLLite update installs an XMLLITE.DLL file, if it's there, then the update has been installed (of course it could be corrupt or not registered correctly).  To see if Group Policy preferences update has been installed look for a GPPREFCL.DLL file.

So one command to see if it's working.
NET LOCALGROUP ADMINISTRATORS

And two commands to figure out what you're missing.
DIR C:\WINDOWS\SYSTEM32\XMLLITE.DLL
DIR C:\WINDOWS\SYSTEM32\GPPREFCL.DLL

After you install the updates just let the machine reboot and log back in.  I have noticed that on the faster machines if you log back in after the reboot with a machine that's supposed to be getting admin rights that it doesn't get the rights on first log in.  If you check the group memberships it shows up rights but you don't have admin rights.  I think what's happening is that the system is logging the account in before the group policies have time to finish applying and since the memberships haven't assigned when the account logs in it doesn't get the rights.  By time you can check the memberships it shows up correctly, but you don't have the rights because the weren't there at login.  The fix is to just log out and back in and then you'll have the rights.  The irony is that it seems like some of our slower machines are not affected by this, I guess the policy has time to finish applying before it actually starts processing the login.  Who knows?  If all it takes is a log off and back on, I'll take it.

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.

Remotely installing software

Ever need to install software remotely?  Why not just fire up Remote Desktop (or VNC) and connect and install right?  That works great if it's one machine you need to install software on.  What happens when you have a lab full of machines that you need to install software on?  You either need a lot of time or something that works faster than remotely installing it on each machine.  So what are you options?

A login script.  Great!  But you have to make the script, associate with only the machines (or specific user) that you need it on, and then wait for someone to log into the machine.  Or remote the machine and log in yourself, but that doesn't really help us speed up anything since we need to make sure it gets installed.

Group policy.  The old school way to push software requires an MSI.  The programs that I was installing didn't come packaged in an MSI, it was an EXE.  Yes, I know I could repackage it into an MSI, but I want to get this software installed quick and I don't want to spend the time on that.

Third party management software.  Yes, this a really good option.  The problem is that we're still working the bugs out of the management software right now and for an unknown reason it doesn't want to push these installers.  The long term way to push software is going to be to get this fixed.  But right now I'm going to postpone troubleshooting on the management software just so I can quickly get this software installed and get the end users back running.

So what did I finally go with?

PSEXEC.  Psexec is your friend.  It's one of the ps tools available from Microsoft (formerly Sysinternals). It's a free download and it will let you execute commands on remote systems.  So with a quick (and very dirty) batch file I was a able to loop through a list of computer names and install programs that I needed to get installed.

psexec /? will give you all the options, but for my purposes here's what I used:

psexec \\machinename -user someuser -p somepassword C:\installerfilename.exe /switches

And that's it.  Well, actually I used a FOR loop in a batch file to process through all the machine names, but the actual work was done with that command right there.

Here's a link for info on the FOR loop.  http://ss64.com/nt/for2.html   This post is starting to run so I'll save the notes about FOR loops for another post.

Renaming a computer from a script

There's a lot of different ways to automate renaming computers.  An easy way to put a script together to automate computer renaming is to use AutoIt.  If you're not familiar with AutoIt you should check out their website, autoitscript.com/.  It's an easy to use (yet still powerful) scripting language with built-in functions for automating mouse movements and key strokes.  Here's a script I put together that will use the standard XP interface to rename a computer.

$name = "COMPUTERNAME"
$workgroup = "WORKGROUP"
$restart = 0 ;0 = no restart, 1 = restart

Run("control sysdm.cpl,,1 -1") ;Launch System Properties Page
WinWait("System Properties") ;Wait for the page to exist
WinActivate("System Properties") ;Activate it (it should be already, but just in case)
ControlClick("System Properties","","&Change...")
WinWait("Computer Name Changes")
WinActivate("Computer Name Changes") ;Activate it just in case
ControlSetText("Computer Name Changes","","Edit1",$name) ;Change computer name
ControlSetText("Computer Name Changes","","Edit4",$workgroup) ;Change workgroup
ControlClick("Computer Name Changes","","OK")
WinWaitNotActive("Computer Name Changes","You can change the") ;Wait for something else to take focus
WinWaitActive("Computer Name Changes","Welcome to the",5) ;Wait for new workgroup dialog box
If WinActive("Computer Name Changes","Welcome to the") Then
   ControlClick("Computer Name Changes","Welcome to the","OK") ;If the new workgroup dialog pops up click OK
EndIf
WinWaitActive("Computer Name Changes","You must restart")
ControlClick("Computer Name Changes","You must restart","OK")
WinWaitActive("System Properties") ;Wait for System Properties to come back to focus
ControlClick("System Properties","","OK")
WinWait("System Settings Change")
WinWaitActive("System Settings Change","You must restart your")
If $restart Then ;Pick the restart option
   ControlClick("System Settings Change","","&Yes")
Else
   ControlClick("System Settings Change","","&No")
EndIf

Set the 3 variables at the top, $name, $workgroup, and $restart.  The name and workgroup should be pretty obvious, the restart options just controls whether or not the script answers yes or no to the "Would you like to restart your computer" prompt that pops up after you rename your computer.

New ways to access the print wizard

Ever been working on a machine that's been locked down and restricted from controlling the printer settings?  It can be a real pain to have to log out and log back in as another user to change settings.  You can work around these restrictions by combining the RUNAS command with PRINTUI.DLL and the RUNDLL32.


You can get into the inner workings of PRINTUI.DLL to see exactly what you can do with a peek at the help screen:
RUNDLL32 PRINTUI.DLL,PrintUIEntry /?


You can check out Rob Van der Woude's page at http://www.robvanderwoude.com/2kprintcontrol.php for a little more detail on the workings.  He also mentions a few VBS files (%windir%\System32\*prn*.vbs) that come with Windows XP that can also help when working with printers.  I've seen them, looked through them, played with them, but never tried to use them so I cannot say as to whether or not they would help on a locked down machine.  But, I have successfully used RUNAS with the PRINTUI.DLL to work with printers on a locked down machine.

Ringing the Bells

Recently we found our selves with a few classrooms that were not connected to the main bell system.  A classroom full of kids watching the clock like a hawk isn't the best thing in the world.  The few precious minutes of class time that is available doesn't need to be wasted clock watching, so they came to us in technology and asked if we could come up with a solution (cheaply).  My knee-jerk reaction was, "Get them all alarm clocks."  After that passed and I thought about it for a minute, an alarm clock didn't sound like a bad idea.  Why not turn the computers in the classrooms into alarm clocks.  They're old and slow, but they do keep time and will play sound.


We (in technology) tried to come up with an idea of exactly what we needed.  Then we set out across the internet looking for the solution.  We needed something that was cheap (free would be best), easy to use, allowed setting multiple alarms, and wrote the alarm settings to some kind of configuration file that we could easily push to the computers.  We found a lot of programs, some of the teachers even pitched in with suggestions, but we couldn't find anything that was a good fit.


Then the old reliable "Scheduled Tasks" came to the rescue.  It was free (comes with Windows), could be easily programmed with a batch file, could run as many alarms as we wanted, and the batch file was an easy way to set the schedule.  For any of you that don't know.  There's a way to set scheduled tasks through the command line, just run "SCHTASKS".  The built help is great and it takes just a few minutes to figure out what it takes to make the bell ring.  Well, it took just a few minutes to figure out that scheduled tasks doesn't include anything to make a sound.  That's ok, we're on a Windows box and we still have the trusty "Sound Recorder" program.  Now we've got the solution, Scheduled Tasks to watch the clock, Sound Recorder to play the sound, and a single batch file to set it all up.


The batch file we used is pretty simple.  Each bell ring gets created by a single command and we just copy that command over and over adjusting the times until we've got all the bell rings covered.  The command looks something like this:

SCHTASKS /create /tn BELL_8_00 /tr "sndrec.exe /play C:\Windows\Media\ding.wav /close" /D MON, TUE, WED, THU, FRI /ST 08:00


That command creates a schedule task that's named BELL_8_00, runs at 8:00AM, silently launches Sound Recorder, plays, ding.wav, automatically closes and runs Monday thru Friday.  Just rinse and repeat with the times for each bell ring that you need.  You can pick any wav file that you know is on the computers.  The key to making it play and close cleanly is the "/play" and "/close" switches on the sndrec.exe file.  


When it comes time to clean this up, it's much simpler command:


SCHTASKS /delete /tn BELL_8_00 /f


The /f forces the command to run, no prompts, no warning, it just deletes the tasks.  Rinse and repeat for each time.


This isn't a perfect solution, there are some draw backs, but it fit our requirements for the time. One problem is that it only allows for on schedule, unless you setup multiple batch files and make sure the teachers get the right ones.  It also doesn't account for activity schedules that occur at random times (like pep rallys or school plays).  And unless the teacher knows about configuring schedule tasks it doesn't give him/her many configuration options.  One solution might be to make a pretty wrapper with AutoIT or VBScript/HTA to allow for customization.  


Another idea that I had is a small program that watches for bell ringing commands from another computer so you can change and adjust the schedules in one spot.  That way each PC is sitting on the network ready to ring at any minute.  I was thinking a small stripped down XMPP client for each PC and a bigger XMPP bot that does the ringing and gets his ring schedule from a GUI that's configured by someone in the office.  That's going to be a project for my spare time.

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?