Showing posts with label zcm. Show all posts
Showing posts with label zcm. Show all posts

Sunday, November 16, 2014

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.

Monday, April 14, 2014

Zenworks Configuration Management, PXE, and Firewalls

I recently added a new site to my ZCM setup and I couldn't get the clients to PXE boot.  This problem was particularly frustrating because it seemed so familiar and I knew that I had encountered it and fixed it once before.

I did remember to start the Proxy DHCP (pdhcp in some places) service and set it to automatically start.  That's a simple as going to the Services console, picking the "Novell Proxy DHCP Service" and setting the Startup type to Automatic and then clicking on Start.

But PXE still doesn't work.  What did I miss?

The firewall configuration.

Out of the box, the Zenworks installer sets a lot of firewall allow rules, but it doesn't set the ones needed for PXE booting.  You have to set those manually.  Here's how to do that.

Go to the Control Panel > System and Security > Windows Firewall.  Click on the "Allow a program or feature through Windows Firewall".  (You could just turn off the Windows Firewall if you wanted to, that would also fix this problem).


Then click on the "Allow another program..." button.

Then the "Browse..." button


Now you want to browse to your Zenworks folder.  By default that's C:\Program Files (x86)\Novell\Zenworks.  From there we're going to drill down further into the bin\preboot folder.  You should have wound up at C:\Program Files (x86)\Novell\Zenworks\bin\preboot


You'll notice a couple of applications: novell-pbserv, novell-proxydhcp, novell-tftp, novell-zisdservice, and novell-zmgprebootpolicy.  We're going to select and allow each of these in the firewall.  Just start with the first one, novell-pbserv, select it, then click the Open button.  Now you're back to the "Add a Program" screen, just click the Add button.


It should automatically check the box for the Domain network location which should be all you need.


At this point it's just rinse and repeat.  You'll click on the "Allow another program button" and go through and selecting all the "novell-xxxx" applications one by one adding them to the list.  Once you get them all done, it'll look like this.










How to change CTRL+ALT in vSphere Web Client

I've been working on setting up a new SYSPREP Win7.  I started the build on a virtual machine running on top of VMware vSphere.  I tweaked it and got it like I wanted it.  Then I went take the image in Zenworks and realized I couldn't get into the imaging mode.  To load the imaging menu you press CTRL + ALT during the PXE boot portion, but CTRL + ALT is also the same key combination to release control of the virtual machine window.  I could have just booted it from a Zenworks boot CD, but I wanted to use the PXE boot.  I looked through the options in vCenter and couldn't find anything related to the changing those settings.  Then I turned to Google and I found a bunch of posts talking about how you couldn't change it.  The outlook was starting to look a little bleak, but then I stumbled into a workaround.  Apparently, the standalone program VMPlayer and the vSphere console use the same configuration file.  You can find that file here:

C:\Users\yourusername\AppData\Roaming\VMware\preferences.ini

There are lot of guides on how to tweak the settings in that file.  But here's the settings that were relevant to what I wanted to do.

pref.hotkey.control = "true"
pref.hotkey.gui = "true"
pref.hotkey.shift = "false"
pref.hotkey.alt = "false"

These settings change the CTRL+ALT combination to CTRL + Win (that's "gui" above).  Keep in mind that the "Hint" across the top of the window still says press CTRL+ALT to release the cursor.   You also have to close and reopen the window for it to pickup the change.  I panicked at first because I changed the settings, couldn't get them to work and then forgot that I had changed them.  Later when I went back into a VM I couldn't get out of it.  I'll admit, it did take me minute to realize what I had done.

Wednesday, November 20, 2013

ZCM and the "Open File - Security Warning"

I kept building my ZCM (ZENworks Configuration Management) bundles to launch executables off of network shares and I kept finding that my apps either wouldn't ever run or I'd get the "Open File - Security Warning" box complaining that the file might not be safe.  Here's what that error looks like if you're not sure if you're seeing the same thing.


What I figured out was that when the bundle just ran and ran forever but never actually did anything, it must have opened this window in the Dynamic User's context and not the current user's context.  So it was sitting there waiting for someone to click Run, but no one could see it to click on it.  I could however reliably launch one application and while it was running and not doing anything, I could launch another application and it would give me the above message and I could click Run and it would go about it's business and launch.  

I don't want to train my users to click Run on random security warning boxes so I don't like leaving it up to them to click on it.  Also, since it only comes up part of the time it's not even a reliable fix.  So I went looking around for a better way.

I came across Joe Parsons post here about this same error and SCCM.  He references a Microsoft Knowledge Base article about the error and a way to get around it when running VBscripts.  That doesn't make a direct application for us in ZCM, but it puts us on the right track. 

To fix the problem we just need to add the mentioned SEE_MASK_NOZONECHECKS variable to the environment on the computer.  Easiest way to do that is in the bundle itself, just modify the "Launch Action" to add the variable and set it equal to 1.  Here's what it looks like when you've got it in there.


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.