Monday, October 21, 2013

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.   


Friday, October 18, 2013

Removing iPrint Printers and Uninstalling Novell iPrint Silently


Over this past summer break we changed our servers from old Netware 6.5 servers and we moved to new Windows Server 2012.  At the same time we also changed from ZENworks Desktop Management 7 to ZENworks Configuration Managment 11.  Since we had over 3000 machines across 10 campuses to change over and there was only 3 of us we did our best to move as fast as we could.  In our haste we left the old Novell iPrint client (and iPrint printers) on the machines.  So now that school is back in full spring and we're almost caught up we need to tackle the issue of removing all of those old printers that are confusing the teachers.  We're not about to go back out and touch all of those machines again, that wouldn't be very practical.  So we're going to do our best to automate the process.

How best to go about removing all of those old printers?  You could write a script to loop through every printer on the local machine and check the name for ipp and remove it.  That sounds like it would be a lot of steps and as anyone that has spent any amount of time working in IT knows, the more steps the more places for something to break.  We wanted fast and simple.  So we dug a little further and found that we can simply uninstall the iPrint client and it removes the iPrint printers with it.  Keep in mind that this was an option for us because we are no longer going to be using iPrint.

So how best to uninstall the client?  You can download an "installer" from Novell that uninstalls the client.  Which is pretty cool.  If you haven't messed with iPrint much you should check out Novell download section for it.  They package several different installers to do a normal install, a silient install, a silent install with reboot, an uninstall.... (you get the picture, right?).  These are handy, because they don't require any command line switches, and you can just give users the file they need and tell them to run it.

But I didn't want to have to distribute another file just to uninstall a program.  So I dug through and found the uninstall command for iPrint.  It turns out that it's a pretty straight forward command:

C:\WINDOWS\system32\iprint\setupipp.exe /uninstall

Which almost works for us by itself, but it's not silent.  The user has to click that yes, they want to uninstall.  We don't like manual steps around here.  We don't like having to manually do something ourselves and sometimes simple things like clicking "Next" is a lot to ask of the users.

I did some Googling of the setupipp.exe command and really didn't come up with much.  So I made an educated guess and tried a "/silent" switch.  What do you know, it worked.  So if you want to silently uninstall iPrint you can use this command

C:\WINDOWS\system32\iprint\setupipp.exe /uninstall /silent

A quick check shows that after the uninstall finishes the setupipp.exe file gets removed too.  Which is great for us to use to automate.  I put together a ZENworks bundle that looks for C:\WINDOWS\system32\iprint\setupipp.exe as a requirement (which means iPrint is still on the machine) and then it it runs C:\WINDOWS\system32\iprint\setupipp.exe /uninstall /silent to remove it.  This works great, since it will only run on machines that have iPrint installed I can assign it to everyone without having to figure out first who needs it and who doesn't. And it doesn't require any work on the part of the user.  I'd call that a win win situation.

Didn't I mention above that I went Googling for the command line switches for setupipp and didn't have any luck?  Well I feel a bit dumb about it now.  I went back and tried the "/?" option on setupipp and what do you know, it tells you all of the command line options.  I guess there could still be something that's not documented, but it would have told me everything I would have needed to know.  The lesson here is don't go searching the internet for help with the program itself will help you out with only two extra characters, a / and a ?.

Just in case you want to know what those options are and you don't happen to have iPrint installed anywhere.  Here they are

---------------------------
iPrint Client Install
---------------------------
Installs or Uninstalls the Novell iPrint Client.

SETUPIPP [/S /R /U /L /?]

              The default (no options) runs the install wizard.

    /S      Install/uninstall the client silently.
    /R      Restart the workstation when the install/uninstall is complete.
    /U      Uninstall the client from your workstation.
    /?      Display this help screen.
    /L      Install for an LDAP compliant environment (only unique usernames).


Don't have ZENworks but want to do this remotely?  You can probably use PSEXEC to accomplish the same thing.  Luckily, since you're running it remotely you don't even have to worry about checking for setupipp first.  Just try to run it, PSEXEC will simply fail if iPrint isn't installed and the file isn't there.  Questions about using PSEXEC, check out my other post  http://practicalschooltech.blogspot.com/2013/10/remotely-installing-software_11.html


Wednesday, October 16, 2013

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.

Friday, October 11, 2013

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.

Back in the Game

Looks like I took a long break.  But I'm going to start back here and get back into writing again.  My goal is to write more than 1 post per week.  I would really like to be able to churn out one every day but I'm trying to set a more realistic goal.  Hopefully, that will mean some more helpful information is going to come pouring out onto this blog.  I guess the worst case is that it'll be a lot of random thoughts that come pouring out.

Thursday, May 20, 2010

CD Burning with limited accounts.... again

I posted a while back about allowing non-admin users to burn CD/DVDs.  I ran into a machine today that wouldn't respond to the registry fix and I was working remotely so I didn't want to mess with the Nero BurnRights utility (because it has to install and requires a reboot).  So I got to digging around again and came up with another fix.  It's called BurnRights (just like the Nero utility, but it's not the same one).  It's put out by a company called Poikosoft.  Strangely, I wasn't able to get the file directly from their site.  They reference it in the help section and even link to their download page from the help section but the file isn't listed.  A bit of Googling will find it on some of the software download sites and I was able to download it from there.  After running it through a couple of virus scanners to make sure it was legit, I gave it a try.  It has a really simple interface (see pic below), double-click to run the program, click on your drive (if you have more than one), and click OK to let it work it's magic. That's 3-4 clicks depending on your setup.  The best part is that NO reboot was needed and NO installation was required

Saturday, February 6, 2010

Automating Workstation Renaming

Sorry it's been a while since I posted.  The holidays came up and there was a lot of other stuff going on that had to be taken care of so blogging got pushed to the back burner.  Have no fear, I'm back. 

I still plan on finishing out the virutalization info but my ADHD is kicking in and I'm moving off to another topic.  Renaming workstations...

I know I've already covered this earlier with an AutoIt script.  But I came across another utility that's even easier to use so I thought I'd post it here. It's David Clarke's Workstation Name Changer and you can find it over at http://mystuff.clarke.co.nz/MyStuff/wsname.asp

It's got great documentation so everything you need is over there on his site.   So go check it out already.