FAQ from the Rev: Frequently Asked Questions About ZENworks Solutions
Novell Cool Solutions: Feature
By Ted Haeger
Digg This -
Posted: 27 Jun 2001
Current Version: ZENworks for Desktops 3
In case you missed the wildly popular free ZENworks web seminar presented during April 2001, here is a roundup of the most frequently asked questions that cropped up during the seminar, and afterwards. Reverend Ted promises to add more answers from time to time as they occur to him, so if you have questions you'd like to pose to him, send us your Questions for Reverend Ted, and we'll slip them under the door to his cell.
- Business Questions
- Version Questions
- Technology Questions
- Application Management
- Help Desk Tools
- Windows Policy Support
- ZENworks for Servers Policies
- ZENworks Deployment
- More Questions?
Q: Typically who implements tactical solutions that follow the divided management paradigm you spoke of in the Web Seminar?
A: A surprising number of organizations still use such tactical solutions. Even though there is a better way, many people live with near-sighted solutions that follow this paradigm, and even still select them.
Q: Is ZENworks for Desktops 2 compatible with Windows 2000 workstation or do we need ZENworks for Desktops 3?
A: ZENworks for Desktops 2 (ZfD2) has a support pack that improves ZfD2 performance on Windows 2000. However, ZENworks for Desktops 3 (ZfD3) was built with Windows 2000 in mind, so you will find much better support if you upgrade. For examples, ZfD3 natively supports Windows 2000 Group Policies, Windows Terminal Server. It also provides a much higher level of stability for this young operating system.
Q: What server platforms does ZENworks for Desktops 3 support?
A: ZENworks for Desktops does not require a NetWare server. It can run from many different server platforms, including Windows NT 4 and Windows 2000, as well as NetWare 4 and NetWare 5.
Q: What server platforms does ZENworks for Servers 2 support?
A: ZENworks for Servers 2 (ZfS2) has several different components that run on various platforms.
- Tiered Electronic Distribution (TED) can distribute data to both Windows NT & 2000 Servers, and NetWare 4 & 5 servers. The current version of ZENworks for Servers requires a NetWare server to be the distributor.
- ZfS2 Server Policies are currently for NetWare servers only, although we are working to expand them to Linux, NT, 2000 and Solaris.
- Finally, the Monitoring and Management tools supports both Windows NT & 2000 and NetWare 4 & 5, but requires one NetWare server to host the back-end monitoring services.
Q: Can ZENworks for Desktops manage Windows 2000 and Windows NT Servers?
A: Because Windows 2000 Server and Windows NT 4 Server are based on the same kernel as their workstation equivalents, most ZENworks for Desktops components can be used on these server operating systems.
Q: Can you upgrade from ZENworks for Desktops 1 to ZENworks for Desktops 3, or do you have to go to ZENworks for Desktops 2 first?
A: You can go directly from any version of ZENworks for Desktops to the latest version.
Q: What version of Starter Pack comes with NetWare 5?
A: Some packages of NetWare 5 shipped with the ZENworks Starter Pack (ZSP). NetWare 5 itself shipped with a version of ZSP based on ZENworks for Desktops 1.1. NetWare 5.1 shipped with a version of ZSP based on ZENworks for Desktops 2.
Q: How can I get the ZENworks Starter Pack?
A: ZENworks Starter Pack (ZSP) is available for download at http://download.novell.com/. Bear in mind that the feature gap between ZSP and ZENworks for Desktops 3 is quite extreme, since the Starter Pack was a partial set of the features from ZENworks for Desktops 2.
Q: What is the future of the ZENworks Starter Pack?
A: At this time there are no plans to release another version of the ZENworks Starter Pack.
Q: Is the policy an eDirectory object to which each user is individually added?
A: The short answer on this is "yes," but you can also use user groups, and eDirectory containers to associate policies to users. Also, different types of policies can be associated to different types of objects: there are server policies for servers, server groups and containers holding servers; and workstation policies for workstation groups and containers holding workstations.
Q: Are changes to ZENworks policies enforced without a workstation reboot?
A: Yes! And No, depending. Most of the ZENworks for Desktops agents-such as the remote management agent, printer install, and the help desk utility-can be quickly re-configured by policy without a re-boot. Desktop policies built upon native Windows tools-such as the Microsoft System Policy Editor and Windows 2000 Group Policies-require additional procedures.
Q: Please discuss your use of ConsoleOne instead of using the NetWare Administrator. Does this imply limitations for NetWare 4.x or all Windows NT Server environments?
A: ConsoleOne can be run to administer any version of Novell eDirectory (NDS). It installs to NetWare 4 & 5, as well as Windows 2000, Windows NT, and even Windows 9x. Because nearly all new Novell products use ConsoleOne, ZENworks (ZfD3 & ZfS2) snap-ins were developed only for ConsoleOne.
Performance on ConsoleOne 1.2d1 is very good, particularly in larger systems that typically limited using the NetWare Administrator. The only technical limitation of ConsoleOne is that it is very heavy on the client and over the wire. Because of this limitation, we are exploring options to make the next major releases of both ZfD and ZfS completely manageable via the browser over extremely low-bandwidth conditions.
Q: Where can I get detailed info on how to deploy ZENworks, such as examples of solutions that people have actually done with these tools?
A: A great spot to start is Novell's CoolSolutions ZENworks community at http://www.novell.com/coolsolutions/zenworks. Another good source is in Novell's success stories, http://www.novell.com/success, which gives overviews of how people have implemented many One Net solutions, including ZENworks.
Q: Is there a particular anti-virus software that works with ZENworks, or can I basically use any anti-virus software?
A: ZENworks does not ship with any anti-virus software. You can automatically deploy any anti-virus software using ZENworks, and you can easily deploy anti-virus pattern file updates automatically throughout the enterprise as well.
Q: Can the snAppShot application packaging tool package multiple applications at once or do I have to snAppShot each individually?
A: snAppShot is extremely flexible, but in the case of this question, all it really does is collect information about your system before you make changes and compare to what you have afterward. In so doing, snAppShot produces an output that summarizes all changes you have made to the workstation as a snAppShot package (known as an Application Object Template, or AOT). It will even package (and consolidate!) multiple re-boots. Use snAppShot either way, whichever is appropriate to your situation.
Techie-tip: snAppShot can even package system changes you manually create, such as adding a background to your system, or changing a registry key.
Q: When using snAppShot to package and deploy applications, do all your hardware have to be the same?
A: Because snAppShot captures only the changes to the workstation (file system, registry, shortcuts, INI file changes, etc.), snAppShot packages tend to be extremely hardware independent. Most (nearly all) applications do not change or access the workstation's hardware. If you have an application that you know cannot run on specific machines, you can exclude those machines by adding criteria to the application, such as a registry key, file existence, or memory requirement.
Q: Can you prevent a specific user from accessing an application that has been installed to the desktop?
A: Yes. Since a user could double-click a data file to start the application (such as an XLS file to start Microsoft Excel), it is best to use a Windows Desktop Policy that prevents the user from accessing that application in conjunction with the application launcher.
Q: In ZENworks for Desktops 2, it was recommended you not relate Application items with Groups. Why? And is that and is it still an issue?
A: The recommendation to not associate applications to user groups is a general recommendation, and is not applicable in every situation. Consider the following:
- Applications, like policies, can be associated to the user, the user group, or the user's parent containers. (We'll leave out association to the workstation as a consideration for this answer.)
- At login, and at each refresh, the Novell Application Launcher (NAL) must search for all applications associated to the currently logged-in user. Direct association to the user object is easy, since there is only one user account. However, the user may have applications through multiple containers and groups, and NAL will have to scan each of those objects for associated applications as well.
- If the user is a member of 12 groups, each group must be scanned for applications. If some of those groups exist in remote containers, NAL may need to do some NDS tree walking to get the group's attributes. If a remote group has associated applications, the applications may not be designed for WAN localization, so the applications might be remote as well. This can greatly reduce NAL performance.
- Associating applications to containers is also an important consideration: if you associate an application to a parent container two levels above the user, that container may be located in another partition (depending on your NDS tree design), and therefore may also cause some tree walking.
If you follow this logic, you can see that using groups is not inherently bad, and using containers is not an inherently better alternative. By using good design logic, as well as understanding some of the custom NAL settings (such as how many parent container levels up to search for associated applications), you can make the right decisions for optimal NAL performance.
Q: How much traffic does the workstation inventory process generate?
A: ZENworks uses bandwidth extremely well. In regard to inventory, from workstation to server, ZENworks saves bandwidth three ways: by using differential scans, by using intelligent scheduling, and by using a designated inventory server.
- Differential scanning: the first time ZENworks scans a workstation, it uploads the workstation's complete hardware inventory, as well as software if configured to do so. After the first scan, the local workstation only uploads changes to the inventory database.
- Intelligent scheduling: ZENworks inventory uses the ZENworks Workstation Manager to run the inventory scan process instead of using other means, such as a login script. This capability means that you can have workstations run their scan at non-peak hours. Also, because ZENworks can randomly dispatch the scanning on various workstations, you can ensure that multiple workstations do not all simultaneously flood the network with inventory information.
- Designated inventory servers: Using a designated inventory server ensures that workstations at a specific site do not send their info across the WAN. ZENworks Backend processes can handle that part.
Q: What impact does workstation inventory have on the WAN?
A: Workstation Inventory is very WAN-friendly as well. ZENworks primarily uses three technologies to minimize inventory WAN traffic: scheduled multi-site data rollup, data compression, and transmission of only new or changed data.
- Scheduled multi-site data roll up: ZENworks inventory servers can be tiered into WAN-friendly hierarchies so that each site collects local workstation data, then sends local data up to the next level server according to an Inventory Roll Up policy.
- Data Compression: All data that is rolled up from one inventory server to the next is compressed before transmission.
- Transmission of only new or changed data: Inventory data is rolled up only if it has changed since the last send, or if it is new data.
Q: What does ZENworks for Desktops offer for the Help Desk support staff?
A: ZENworks provides remote control, remote view, a workstation remote diagnostics utility, a remote program launch utility, and a ping utility for testing if the workstation is running the ZENworks management agent.
Q: What is the difference between remote control and remote view?
A: Remote control allows the managing user (controller) to see the user's entire desktop, as well as control their keyboard and mouse. Remote control can even allow the controller to shut off the keyboard and mouse access from the end user.
Remote view merely shows the end user's screen. It does not allow the managing user (viewer) to perform any remote actions on the remote workstation.
Remote control and remote view access is controlled by the managing user's rights. That means you can have some help desk users able to remote control, and others able to only view the same workstation.
Q: Do ZENworks for Desktop policies work without Microsoft's System Policy Editor?
A: ZfD3 leverages the policy tools that are native to Microsoft Windows. In the case of Windows 9x and Windows NT, ZENworks supports all policies that can be created via the Microsoft System Policy Editor. The differences provided by ZENworks are:
- You use ConsoleOne to create desktop policies.
- Policies are stored in the corporate Directory instead of the file system, so they are made more fault-tolerant, universally available, and secured from tampering.
- Policies are associated to users in the directory instead of in the policy file, which makes a more logical method of tracking which policies effect which users.
It should also be noted that Windows Policies are not foolproof. ZENworks follows the Microsoft System Policy APIs. Windows 9x was not designed as a secure (or securable) operating system; policies on Windows NT and Windows 2000 are much more secure.
For the Windows 2000 platform, ZENworks fully supports Windows 2000 Group Policies.
Q: Is there a place that you can find additional policies to lock down workstations other than the ones available with ZEN?
A: Check out the CoolSolutions community for ZENworks at www.novell.com/coolsolutions/ zenworks. Here are some good articles to start with:
Q: Using ZENworks, is there a way to make Windows 9x system just as secure as Windows NT?
A: No. Windows NT's security starts with the operating system's kernel. No policy can completely fix the lack of security in Windows 9x. However, there are many suggested policies available at: http://www.novell.com/coolsolutions/ zenworks/subject_index.html under the heading "Especially for School Admins."
Q: Will we ever be able to provide the tight security restrictions found in a user policy in the workstation policy as well? Currently, workstation policies are very limited and do not have the settings to be as restrictive as user policies.
A: The issue you cite is by design from Microsoft's original System Policy Editor tools, so you find ZENworks limited by the capabilities of the Microsoft OS. Windows 2000 Group Policies alleviates this disparity between policy types.
Q: Do the ZENworks for Desktops 3 policies conflict with Windows NT System Policy Editor policies?
A: ZfD3 is designed to over-ride Windows NT System Policy Editor policies. However, because ZfD3 desktop policies leverage the capabilities of the System Policy Editor policies, it's a best practice to select which tool you will use to deploy Windows NT System Policy Editor policies.
Q: Could a user with a copy of POLEDIT change their system's policy?
A: Absolutely! This is why when you apply a restrictive policy to a user, it is important to include "Disable registry editing tools" as part of the policy.
Q: Is there a new imaging piece to be released soon?
A: The first release of ZENworks Imaging shipped with ZENworks for Desktops 3.
Q: Is there a SID Changer within ZENworks Imaging or do you need to use a third party software like SYSPREP?
A: ZENworks for Desktops has a client component called the ZENworks Imaging Service, which handles the SID generation process for Windows NT and Windows 2000 workstations. You can also use tools such as SYSPREP, if you prefer.
Q: What about the machine name (for Windows networking)?
A: Machine names are also handled by the client's ZENworks Imaging Service component. New machines that have never had an NDS identity will have a workstation name randomly generated, optionally with pre-filled characters from your imaging policy. Workstations that were already imported to NDS before imaging will have the same Windows networking name they had before imaging.
Techie note: This is accomplished by caching the workstation name and NDS identity on the workstation's hard disk's boot sector 6.
Q: Can I purge files on volume with ZENworks for Servers?
A: Yes! Because you can create NetWare Server Policies to run actions from a script or NCF file on a periodic basis, you can easily create a server script to purge the files from whatever volumes you need. Using NetWare Object Variables, you can even base execution of actions on specific criteria, such as free disk space, so that when the script runs, it can intelligently decide which course of actions it should perform.
Q: Can you upgrade from ZENworks for Desktops 1 to ZENworks for Desktops 3, or do you have to go to ZENworks for Desktops 2 first? (Repeated from the "Versions" section above.)
A: You can go directly from any version of ZENworks for Desktops to the latest version.
Q: Can ZENworks for Desktops be distributed to each desktop-whether Windows 9x, Windows NT, or Windows 2000 without visiting each station?
A: Deploying the ZENworks client to Windows 9x workstations is very easy because the Windows 9x platform natively has no strong security to impede automated, remote deployment methods. Login scripts, the Novell Application Launcher or centrally-deployed batch files can help to rapidly roll out the Novell client and ZENworks management agents.
However, Windows 2000 and Windows NT both present a particular challenge: local security, which is built into the OS, can hinder your deployment. However, if your workstation is part of a Windows NT or Active Directory domain, then you can leverage the centralized security of the domain to assist your deployment. Alternatively, if you already have deployed a previous Novell client with either the Workstation Manager or the Application Launcher Service, you can automate the ZENworks client deployment using one of these two services.
Q: Given the number of objects that ZENworks adds to the NDS eDirectory tree, is it recommended to put ZENworks objects in their own containers?
A: There are many ways to enhance your eDirectory tree design to better accommodate ZENworks objects. The ZENworks online documentation and NDS Design for ZENworks in ZENworks Cool Solutions are two good starting points.
Send your Questions for Reverend Ted to email@example.com
Hello, Ted. One big FAQ that I have not been able to find the answer for is what executables are required to properly start & boot a ZfD3 environment? This is important for school administrators like me who would like to restrict and lock down lab workstations to only applications delivered through ZENworks.
Here is the configuration I am trying to implement this fall:
- NW 5.1 SP2a servers
- Win 2000 Pro SP2 workstations
- ZfD3 running either with App Launcher or App Explorer (not sure which yet).
- ZENworks 3 remote control
- ZENworks 3 workstation manager
A list of needed executables for these items would save MUCH time!!
Rev: I wish I had an easy answer for you on that. Unfortunately the lockdowns to the OS are all Microsoft's; we simply DS-enable them. To really do a solid lockdown, I would suggest reading on how to use the NAL shell as a replacement to the Windows Explorer shell. It's a really tight way to do the lockdowns you seek to make, since all icons are provided by NAL.
I work for Mississippi College in Clinton, Mississippi. I watched the web seminar for ZENworks, and during that presentation, it mentioned that ZENworks could be used to stop the execution of setup.exe on workstations. It never explained how to use this ability.
We have student computer labs, and it would be nice to be able to stop users from installing extra software to the computers such as chat programs.
Rev: This is available on Windows 2000 by using the ZENworks for Desktops 3 Group Policy integrations.
I have recently installed ZFD3 with ZFD sp1 and have created a search policy. Our organistation has one WAN link and so our UK office is linked with the US office.
Our organisation is split into Europe and Namerica underneath the root. Underneath root is an OU called Betalm. It is here that we split into Europe and Namerica. Under the Europe container is another container called HWY. It is here that all our users and network objects exist. I have been able to import workstations successfully but here comes the problem. It's importing workstations across the WAN link. So, I created a search policy to only look at the HWY container. I used a Selected Container for the search policy and choose the hwy.europe.betalm container with a search level=0.
Somehow it seems to tree walk from here up to root and down to our day.namerica.betalm container.
I'm sure there are other factors that come into the equation but being new to ZFD3 I'm not sure where to start looking. I would appreciate any pointers as I'm scratching my head on this one. Many thanks, Reverend Ted.
Rev: in ZENworks for Desktops 3, importing workstations has nothing to do with Search Policies and everything to do with DNS.
Your workstations locate their import server through a DNS record called "zenwsimport." If you ping zenwsimport from any workstation, it should give you back the IP address of the import server that the workstation is contacting.
For more information on this, you should really read the documentation. Here is my BrainShare 2001 presentation, complete with speaker notes. It's 1.2 megabytes, but it should help.
Hello, Ted. What I'm trying to do is to use NAL icons for applications instead of the application icons. I do this with fault tolerance. I have made an application distribution object for installing the application only. That application has multiple icons so I made a couple of NAL applications to make these NAL icons. These NAL Icon Applications have as fault tolerance the application distribution. So if the executable does not exist of the icon than the application distribution will run. This works fine but if I make a change to the distribution application this change won't come over to the workstation because the fault tolerance has already been running. I don't know how to handle this problem.
I'd like to give a dependency in an application object to run another application if the version number is changed on that application object. This would be a cool solution because we would like to use NAL icons instead of application icons.
Rev: This is already possible, and you can do it without two App objects. On your distribution object, change it from "Install only" to "Path to Executable file" as shown here.
This makes the distribution run once, after which the app will run from the same icon. This also enables application self-repair, and re-distribution after changing the version number.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com