Zenworks Configuration Management Updating 11.2.0 to 11.2.4

Sometimes I can get a little behind.  You really know you're behind when you go to System Updates and look at the release date and realize it was a year and a day before your download date.  But that's the name of the game.  We jumped from Zenworks for Desktop 7 straight to Zenwork Configuration Management 11.2 last summer and brought all of our XP clients along with us.  For the most part 11.2 was a good version for us and our XP clients and we didn't really have a need to upgrade.  Fast forward a year and we've deployed a whole lot of Windows 7 machines and are running into some bugs that have been patched, now we need the update.  A good long weekend with a couple of user free days looked like the perfect opportunity to do the upgrade.

You can safely ignore that "Check for Updates" option in the System Update section.  It's a known issue (apparently been known for a while) and has something to do with the update being too big to download automatically.

To start out, grab the update from the Novell page (you can find it here http://download.novell.com/Download?buildid=ZCUFlvDkC9w~ ).  The instructions in the details section at the bottom are spot on.  Copy the file to the server, run the "zman sui" command, and now it shows up in the System Updates section.

The online instructions (you can find them here https://www.novell.com/documentation/zenworks11/zen11_sys_updates/data/bjppvdf.html ) look pretty straight forward but are not as clear.  You can skip the first couple of steps about getting the updates (since you just did that manually with the download and the zman sui). What through me for a loop was that I only wanted to update one server before I rolled it out to the rest of the servers.  Which is their recommendation.  The instructions aren't obvious on this.  The process starts out designate a server and then assign the update.  That looks pretty easy.  What they don't tell you is that you don't assign the update on the frontend, you pick the update and set it to install and then pick which server on the backend.  If you read ahead this becomes a bit clearer and after you've done it once it's really obvious how it works and it's really easy.  But for the first time through it not super clear and can be a little unnerving.

The update on the first box went pretty smoothly.  It took an hour or so (quick description, about a dozen primary servers spread out across different sites, ~3000 devices total, internal Sybase DB, running in a Hyper-v VM on a Dell R720 with the slowest 10K SAS hard drives ever).  After it came back up the Configuration tab of the ZCC showed no version for the server.  That did induce a little bit of panic, but running a "zac ref" on the server updated the display version so it showed the correct 11.2.4.0 version number.  That trick would come in handy as most of the updated servers also showed up blank, but refreshing the agent on those boxes fixed it.

Then I kicked off two more server updates.  Two hours later they both showed "Rebuilding Deployment Packages"  This wasn't cool, the first server updated in around 2 hours and it supposed to take the longest.  I searched around to see what I could find.  Since I had two boxes I left one alone and picked on the other.  I tried a "zac ref", no luck, I tried a "zman surp" (found that on the forums) still no luck, tried a reboot, nothing.  I did dig around in the file system and I found the folder C:\Program Files\Novell\Zenworks\install\downloads\msi which looks to contain the deployment packages.  I noticed that most of the files had varying timestamps from today and that some of the timestamps were only a few minutes old.  That would mean it was still actually doing something and hadn't stalled.  So I left that folder open and went about searching for more things to check or try and while I did that it finished... Update Completed.  Then the box that I hadn't touched finished a few minutes later.  Apparently, I was just impatient.  I'm glad I didn't toast the box trying to hurry it along, but it is nice to know that the process can be fairly resilient.

Then I picked a few more to start upgrading and kicked them off.  They seemed to progress nicely.  I picked the remaining boxes and set them a scheduled time over night to upgrade.  Crossed my fingers and went home.

I arrived in the morning to find some boxes updated, some boxes "Rebuilding Deployment Packages" and one box failed.

The failed box hadn't run out of space, the update was all there, and the log files looked to just have a simple "failed to update..." message.  So I selected the box from ZCC and selected "Redeploy update to device", it jumped back to rebuilding packages and in about 20 minutes it showed "Update Completed".  Easy enough right?

The rest of the boxes?  Just slow.  As the morning progressed they slowly started finishing.   All except for one.  Over a day later is looked like it was stuck.  I gave it a reboot and a couple of hours after that I tried to the "zman sui" command.  A few hours later I rebooted again and waited.  It finally picked up and finished.

Silently Installing Audacity and LAME

Want to silently install Audacity and LAME?

Audacity

I learned my lesson in my previous adventures looking for silent install switches for iPrint (here's that post Removing iPrint Printers).  This time I started out running audacity-win-2.0.5.exe /? to see if there are any silent install options.  What do you know, there are. The "/SILENT" option looks promising for my needs.  I think I'll go ahead and add the "/CLOSEAPPLICATIONS" option in there too just so I don't get any pesky, "You need to reboot" messages.  I'm also going to go ahead and add the "/LOG" option too.  In the past I always skipped logging stuff just to make things faster, but as of late I've decided that having some log data lying around can come in handy and is worth the extra second it takes.

LAME

Unfortunately, the learned lesson with the "/?" is lost on LAME.  It doesn't support that, guess I'll have to go search for this one.  A quick search doesn't return an obvious answer.  A lot of install guides but no body talking about installing silently.  I did find a link to a WPKG package that has some command line switches burried in their XML file listed on the site.  It looks like LAME will take similar options to Audacity.  I'm going to pick the "/VERYSILENT", "/NORESTART", and "/LOG" options for the LAME installation.

Wrapping It Up

For both of the installations I just let it put the files in their default locations.  In the past you had to point Audacity to the LAME files so I used to always install the LAME dll files inside the Audacity directory.  That way when the end users tried to Export as MP3 and the window popped up asking for the dll file it was right there ready to click on.  It looks like in this new version of Audacity automatically searches the default LAME install folder (C:\Program Files\LAME for Windows).  Which is nice, that's one less thing for the end user to have to do.

I went ahead and built separate ZENworks installers for both Audacity and LAME.  I don't know why I'd ever deploy them separately, but now I can if I need to.  I'm also building a Bundle Group to include both of those installers to make it easier to assign to users.

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.