Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Zenworks 3.2/4 Imaging vs Ghost 5

Status
Not open for further replies.

Bandjelek

MIS
Oct 6, 2002
28
NZ
Hello,

We just upgraded from ZfD3.0 to 3.2SP1 (and will possibly move to Zen 4 in the near future), and are considering Zenworks Imaging to replace Ghost.

I'd like to know what other people that had implemented Zen3.2/4 imaging think about it. Also, how it compares with Ghost, pros-cons, pitfalls, etc.

Any suggestion & experience sharing would be appreciated!

Thanks,
Bandjelek
 
Me too, me too... we are also currently using Ghost and are preparing to move to ZfD4. Very interested if there will be an improvement in speed and/or reliability.

Thanks,
Matt
 
From personal use, Ghost is still faster than ZFD. Even after Reverend Ted's promise that ZFD 4 would be faster. HOWEVER, the managment with in ZFD 3.2/4 is hands down much better than Ghost.

Go to this link to answer common questions;

The key is using the PXE feature. In ZFD 3.2 it is an add on purchase from Novell. In ZFD 4, it is built in. When you use PXE, you get the true value out of the software. Using the Imaging Partition can be confusing and difficult to roll out in a working enviroment. In the desktop managment packages I've rolled out, I've always included the PXE feature. It allows for shops with no IT or small IT to take on a "15 minute do or die" policy. What this means is that if an issue comes up that can not be fixed in 15 minutes, then we just image the workstation and go. Saves a lot of time and money for my clients (plus I don't have to figure out every single stupid issue that comes up with an M$ OS anymore). To make this work you have to put in the time and effort to get all of the back ground work done.

You also MUST have a company policy in place that tells the users to store all personal DATA on a server, never the workstation. The workstation MUST be expendable in the even of a failure. If your users store data on the workstation, then your job is much more difficult if you don't have a product like iFolder in place.

You will also need to create "Self-Healing" applications.

The process will bascily go like this;

You will need a separate image for each mother board in your network (NIC, Video and everything else does not matter). You can get away with a single image that uses overlay images by utilizing a third party product to help strip drivers for you. These guys have such a product .

Once you have setup your workstation with all the settings you want, use the Microsoft SYSPREP tool (RTFM on usage) to shut the system down and prep it for imaging. This tool will remove the SID and force the system to run a mini setup when it first boots up. You can make this mini setup completly automated, see this link for additional info
Once you have a system up and running, the user can install their own apps using the self healing deployed icons. If you have NDPS in place, or iPrint, the user can also install their own apps.

This is not a slam dunk procedure. Expect it to take about 3 to 4 weeks of testing to get your image to work right. Once it is done, it works great. I have about 3 client sites that have no IT, and have not required an on site vist for some time now (about 6 months). When they have a workstation issue, I just use pcAnyware, Windows Terminal, or Citrix to access the network remotly. Take remote control over the workstation and try to fix it. If I can't, I shut down the pc, tell the user to go have a coffee break. Tell NDS to image the PC on next boot, the remote wake the PC. Wait about 20-30 minutes. Once the system has compete the image, the mini setup, the renaming, and registering with DS, I run a quick test to ensure everything is fine and the previous issue is gone. If the issue is still there, then the issue is something else. It could be either the workstation hardware or something on the network. Brent Schmidt CNE,Network + [atom]
Senior Network Engineer
Keep IT Simple [rofl]
 
I'm in the middle of putting in Zen4 and trying to suss out how it's all going to work, so your post was a both a big help and a nice bit of reassurance that PXE works. ;) I've been replacing every nic in the joint with Intel Pro100's to ensure a consistant PXE situation..

Great post! Thanks!
 
We currently use Ghost but will be implementing Win2K and ZEN4 within the next 6-9 months - I was also wondering about how the ZENworks imaging performed, thanks for the info.
 
Ghost is slightly faster but the management fetures of ZEN4 far outweigh the speed.
 
Hello all,

Good info Provogeek,
I just tried your site you have listed in your name and nothing comes up. I am new to novell. Had to learn by way the School of Hard Knocks. When you say self healing this is??

Anyway, thanks for the info and when we move to Zen4 I will bookmark this page.

Thanks,
IdahoTech
 
IdahoTech,
The sig seems to place extra spaces before one of the slashes, so the link goes to la la land. Follow the link in the forum sponsor banner, my company has been sponsoring Tek-Tips novell forums.

Self-healing apps are apps you deply to the users desktop that if anything happens to the app, if the executable is the issue, then the app will redeploy. If the app just doesn't work right, but the executable is fine, the user can right click and do a "Verify" and the app will redeploy. No involvment by the admin. It is pretty much just another way of deploying applications using the application launcher program with in ZFD. Brent Schmidt CNE,Network + [atom]
Senior Network Engineer
Keep IT Simple [rofl]
 
We are running 3.2 but have not implemented the imaging feature and still may not.

As a state government agency we do not get funding to upgrade PCs very often. 1/3 of the users in my program are using Pentium 200s with 96mb of RAM. Zen's imaging requires a small linux partition on each system. The PC boots to this first and then queries the server to see if there are any images that will be applied before it begins to boot Windows. This function easily adds 2-3 minutes to the boot time and would surely earn many complaints.

Your imaging server must also have adequate disk space. The Zen image is not compressed and will be the same size as they are on the workstation. This can really add up if you have many different models and configurations in your locations.

Another issue I've never gotten straight is how static IP addresses play into this. I know the workstation object uses the netbios name and has the network address info but I'm not sure if it automatically populates these fields on the workstation after the image is installed. My understanding is that it does not which would mean you would basically need a separate image for each workstation you have. Anyone know the definitive answer on this?
 
we are currently running ZWFD 3.2 we did spent quite some time testing and setting up the imaging system, but it is worth the time. You do need quite a large amount of disk space on the server if you have multiple images, we have 5 different at the moment.

The IP address is not an issue for us as we use dhcp on all client workstations, but all Workstation names / IP/ MAC details are held in the image safe data area and these are restored to the imaged workstation workstaion after it is rebooted.

The only qualifier on this is after the initiall image (where you would need to change the workstation name & IP details) you then do not need to change them again as this is added during the install proccess.

The double boot does add a small amount of time to the switch on of the workstation but in our experience this is less than 30 sec, once the system is inplace then the users get used to it and we have no real issue here.

The imaging speed can also be affected by the make and model of NIC installed, we use Intel Pro100 desktop NIC's and found them very good (there was an issue with some 3com NIC's which were taking 45mins + to image) So it is worth testing this as well.

Whilst still not as fast as ghost imaging takes under 10mins on most of our workstations, even whilst imaging entire rooms 30+ workstaions.

The workstaions are then managed through Console 1 so we can remotely image anywhere on the site.

We went with the ZEN Imaging option because we could not also afford to buy a networked version of ghost. But if we had the funds we may have looked at it.
 
fwiw
In Zen 4 the linux piece is handled via PXE support -you just need PXE compliant nics, so you don't lose disk space on the clients. The PXE client sends for the IP of the server on boot, DL the linux engine and then that goes to NDS to check on work to be done etc. It's an add-on for 3.2, and standard in v4. It will slow down boot up, but it's a small price to pay for the added features and functionality IMHO.

On # of base images, it's my understanding that you need one either per motherboard type or HD controller type - not 100% sure on that. It might just be per HD Controller type.
(assuming of course you have enough disk etc for the image, etc etc) There is some flexibility to the image though WRT drivers and hardware. (and there are 3rd party apps to helop with this) We are rolling Zfd4 on Thurs so the next week or 3 will be very, um, educational. We have tried to get down to a fairly flat setup, all matrox video cards (their dual & quad cards can use the same driver..), all Intel Pro100 nics and a limited # of different desktops. We'll see if that helps at all..

in case I am dead wrong, what kind of wine goes with crow? ;)

Just as an added resource, the Novell nntp groups have some good folks too for ZW Q's. I will post back here with my own experiences as we go through the roll out.
 
I thought i might mention the image safe data that is included with Zen 3.2\4...I am right in the thick of this at the moment, and what i can gather is that when you image over the top a 2K or XP box you can ellect to use the image safe data that is stored on the local windows partition... the image safe data stores all kinds of usefull stuff about the client PC...it includes the SID, IP address, last loged in user, and a few others i cant remember...it also means that the Workstation does not have to reimported into NDS thus not haveing to re-assioate the workstation to the policy package...This has proven very usefull in testing because all that has to be done after the workstation is imaged is join the NT domain(if ur using the little thing)...i have also automated this with a force run app that checks for a dummy reg key that i have created on the master image...if the key exists then the app runs NetDom.exe which joins the domain and restarts the computer...

This also means that the image that is stored on the server or the local Zen partition does not have to be syspreped ...the only draw back is that you will need two image for each client(If a HDD dies or the Zen partition is corrupted)

Hope this helps.....
 
just fyi (courtesty of Novell support group)
to speed up your imaging, try this flag out:
(add at the end of settings.txt)

hdparm -dl /dev/hda

This allows lets Linux mount and image the first IDE drive which should be fine on most any workstation. This is disabled by default. You can use hdb, hdc, hdd as necc depending on how your drives are hooked up.
One person on the group reported imaging faster than Ghost in all cases using this combo (I don't yet know what all the extra flags do.)

hdparm -c3 -m16 -d1 -u1 /dev/hda

Just something to test out. Hope it helps! I know the basic command (with just the -dl flag) helped trim a lot of time off of our imaging process.

- Joe
 
We're using PXE. Just curious if there is a way to apply these configuration settings to a PXE image session?

Matt
 
Heres some info on hdparm from Novell TID 10082755

GOAL

Using HDPARM to increase imaging performance

FACT

Novell ZENworks for Desktops 4 - ZFD4
Novell ZENworks Imaging

FIX

The linux utility hdparm (used with a syntax of "hdparm -d1 /dev/hda") is included in the current imaging implementations, and can be used to increase the performance of ZENworks imaging (you should test it with your hardware). This command line can be entered anywhere, but is usually added to the existing commands already in hdparm.s. Another place you could put it is in the Settings.txt, as an added line at the bottom of the file, or at the bash# prompt before restoring an image manually.


HDPARM is also discussed on the O'Reilly Newtorking Web site at
 
Well, we've got about 85% of Zen4 rolled out. Inventory, remote control, DLU and imaging all work well. Remote control is slower than PCA, but so far has been more stable and having the directory enabled aspect has been huge (all objects are created in eDir automatically and you can set rights for remote control centrally.. nice!) Also, you save the $30 per head you'd spen on PCA (subtract that from the cost of Zen..) Now I am getting to the more granular stuff like add on images and policies. It's been a complex rollout, probably the most complex software project I've ever been involved in. It's working very well and making a huge difference already in our day to day operations. Our "basic" workstation works out to about a 1.3GB image which takes all of 13min to come down. I have not tweaked beyond the plain vanilla hdparm -d1 /dev/hda command. I'm sure we could improve on this with some work but seeing as how I just went from 8 hours to 13 min I'm focusing on other aspects. ;)
Problems we had with imaging:
1 - our imaging server used 2 nics in a load balancing config. this broke pdhchp/tftp in a big way. solution was to take it to 1 nic. I think dealing with 2 MAC's was more than it could cope with. I just pulled one cat5 out; if the main nic gets flaky, i can pop it back in and pull the other (and run them both if we're not going to image for a while..)
2 - some workstations had 2 nics (1 unused) linux activates the first one it finds on the box (regardless of being disabled in bios..) so make sure it finds the driver of the nic you want it to use. There is a TID for this (adding drivers to linux..) With this broken, everything worked but the last bit before the imaging engine kicked in. We just could not get a DHCP address (although we had one in the beginning!)

Otherwise it's been pretty painless.. :)
 
A couple of issues. Zen images can't span media like ghost can - this could be a problem if you need to use cd-based imaging - for laptops, remote locations etc... also if your network uses VLANs you need to make configuration changes on the routers for PXE to work. The Zenworks documentation on Novell's site explains this.
 
I would mostly agree with Provogeek.

One thing I would recommend is the use of Syspreped images. Basically I am in the middle of project managing a rollout of XP using Netware 6 & Zen 4, to around 2000 systems at a college in the UK. We have managed to get a syspreped image to work on every disparate type of machine present on the network, thus avoiding the storage of many different images for each different spec of machine (P3, P4, different chipsets and different graphics cards). By syspreping each type of machine and including the drivers in the image, the college virtually need only one image for every location. The only exception is when the starting point image needs to contain different applications, like the basic staff image, the MIS image and the student image. We also have an image on each site, to avoid downloading accross the WAN. We are using PXE very successfully, although some changes were needed to the configuration of the 3COM core layer 3 switch for imaging and multicasting.

A very useful feature we have used regularly is the client side multicast/image feature, where you can use any PC as a "Master" and multicast or image to any single or group of PCs that require a unique configuration.

Things aren't all perfect though, as we have had issues with machine naming and the fact that you can't use the "image safe data" area with the sysprepped image.

I would say Ghost is still slightly faster, but that is soon overtaken by the advantages of ZEN.

The integration of XP policies (using windows GPO) with ZEN4, is a big advantage as well.

We have also had some problems with using NAL to deliver apps the WIndows XP. Mostly this has been with older apps, not written for XP.

So far so good!

Garry Thompson
 
Garry,

For your workstation naming, check out this tool from ENGL


It's free and it works great. I place it in the system and when a SYSPREP runs, I have it run a BAT file that places it into the RUN option in the registry. Then on boot, the workstation gets named acording to pre set qualifiers (mostly name the workstation based on BIOS serial number, makes inventory easier).

I have trouble getting a single image to work when mainboard chip sets change with out using third party tools. Were you able to get yours to work with out third party tools?
 
Hi Provogeek,

So far our image has worked on everything from P3s on old clone machines with MSI motherboards and Via chipsets to the current Dell Optiplex GX260 and Dimension 8250!
Having all the extra drivers in the image doesn't seem to have impared the performance of the systems either.
I'll have alook at the tool you mentioned. At this college they are using a combination of the classroom number and PC number to identify the unit in NDS.
They aren't using ZenWorks to its full potential here yet, in that they aren't delivering apps to each user via NAL, but just to an administration account. It's a long story..... Compared to how they were working before this is a great enhancement!

Thanks for the response!

Regards,

Garry
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top