AppNote: ZENworks for Servers 3.0.2 : Configuring Distributions
Novell Cool Solutions: AppNote
By Ron van Herk
Digg This -
Posted: 20 Aug 2004
Ron van Herk
Novell Worldwide Support
- Configuration of ZENworks for Servers Distribution
- General Properties
- Use Digest
- Maximum Revisions
- Distribution Type
- File Distributions
- New Target
- Synchronize Directories
- Verification Distributions
- Desktop Application Type Distribution
- Maintain Associations
- Load Balancing / Fault Tolerance
- Application Requirements
- How the Desktop Application Distribution Works
- Schedule Properties
- Send Distribution Immediately after Building
- Schedule Type
After installing ZENworks for Servers, the next thing to do is configure schedules, channels, distributions, etc. This document describes the different configuration options on the TED Distribution objects and will give some information that will help on configuring the TED Distribution objects.
I hope that this document will provide insight on what ZENworks for Servers can do and how to optimize the use of ZENworks for Servers.
I will go through the different screens and will discuss the important configurable options that are available on these pages.
This option is enabled by default. It will generate a checksum that can be used to recognize if the distribution is valid or not. Creating the checksum will take some time and CPU resources on both the Distributor and the Subscriber, however Novell recommends to leave this turned on.
If a distribution for some reason gets corrupted, the digest that is generated will be different then the one that was received from the distributor in the workorder. If this occurs the received DISTFILE.TED will be renamed to CORRUPT.TED so that the distribution will be sent out again the next time the channel schedule is reached. Running with the Digest turned off would disable this feature.
The "Encrypt" option will add encryption to the distributions. This option is only recommended in the following two situations:
- If a Distributions will be sent over a public network like the Internet. For Distributions that will be sent over a secure WAN environment Novell recommends not to use Encryption.
- When distributing a NetWare Support Pack. When distributing a NetWare Support Pack an account with administrative rights needs to be entered, these credentials will be in the distribution and encryption of the distribution might be required. For more information see TID 10081510.
This is the most interesting setting on this page, the value that needs to be used for this setting is depending on the content of the distribution.
ZfS will create a distribution file to transfer the files to the Subscribers. The initial distribution that is made is called a Baseline-Distribution. If any files are changed and the Distributor is creating a new build of the distribution, this new distribution will contain all changed files in the source directory. Such a distribution is called a delta-distribution or revision. The Baseline distribution and all following delta distributions is what will be available on the subscriber. After a number of delta distributions, ZfS will start with a new baseline so that all files are stored again within a single distribution, and again, the following distributions will be delta-distributions. The "Maximum Revisions" setting specifies how many delta-distributions will be created before a complete new Baseline is built.
The value that should be used for this setting depends on what is inside the distribution. If the distribution has a large amount of data and only small file changes are made inside the source directory, the baseline distribution will be quite large and the delta files will be small. In this case it will be useful to have "Maximum Revisions" set to a high number to avoid re-sending the baseline too often.
If the distribution contains a limited number of very large files, the best option is to limit the amount of revisions. This will reduce the amount of disk space required to store the complete distribution.
Note: The Maximum Revisions setting will only have affect on sequential distribution types (File and Desktop Application distributions), Other distribution types will always use a baseline distribution.
There isn't so much to configure on Channels, however there is something that might be useful to know.
With ZfS 3.0.2 we can distribute Applications. To determine if there is anything new to distribute the Distributor will check the eDirectory revision stamps on the Application objects but also on the Distribution object. When adding or removing a channel to a distribution, the NDS revision of the Distribution object will change and it will cause a new delta file to be built on this distribution as soon as the distribution build schedule is reached (as mentioned, only for Desktop Application distributions).
On this page the distribution type needs to be selected. There are different types of distributions each of these has their own specific configuration page. The following distribution types are available:
- Desktop Application
- Policy Package
- Software Package
The target is a very important setting, since there can be some serious problems if the target isn't set properly.
The first reason why it's important to have the right target defined is because of the "synchronize directories" option. This option will delete everything in the target that isn't part of the distribution. By setting the proper target, the right directory will be used to perform the "synchronize directories" operation.
The second important reason why the target needs to be set properly has to do with performance. The extract of the File Agent will build a hash table that is used to determine what files will need to be updated. Building this hash is quite CPU intensive. The processing time taken to build the hash table can be easily limited by using the right target directory for the distribution.
When specifying the target the default target that will show up if the New target button is clicked is %DEST_VOLUME%. In most cases it's not recommended to keep this as the target directory. In most cases the distributions will be transferred to a subdirectory within the %DEST_VOLUME%. It is possible to create additional directories underneath and specify the files and directory to be within these directories. This would look as follows:
If %DEST_VOLUME% is the root of a large data volume, ZfS will build a hash table with the information on all files on the data volume. This is quite useless as only the files within Dir_3 might change in this distribution. For this reason it is better to modify the target to point to the exact directory used for this distribution. This will look as follows:
As mentioned above, "synchronize directories" will delete everything in the target that isn't part of the distribution. Setting this option with the wrong target specified can be very destructive, this is why there is an additional message showing up as soon as this option is enabled.
Enabling this option will force an extract of the distribution every time the extract schedule is reached. If any of the distributed files has been deleted or modified, the original file from the distribution will be restored.
As mentioned in the documentation, this option will maintain associations between the distributed application and the trusted groups and containers (within the source root container). ZENworks for Servers will create groups and containers if they do not exist. If a group already exists and has been assigned to the application, ZENworks for Servers won't overwrite the settings that exist on the application.
ZENworks for servers has specific requirements on the applications that need to be distributed, these requirements are listed in the documentation. Make sure the applications follow the requirements mentioned in the documentation at http://www.novell.com/documentation/zfs302/zfs_admin/data/a86shwb.html
If the eDirectory time stamp on one of the applications(or the distribution object) has changed, a new revision will be build. The Distributor will export the application object details to an AOT file (similar to the export of an application from the wizard in ConsoleOne), this AOT file together with some more configuration files (for example regarding the GUID and associations) and the files that come with this application are added to the distribution.
On the Subscriber this application will be either created or updated based on the information available in the AOT file.
There are a few important things to know about application distributions:
- If an attribute was deleted it won't be exported into the AOT file (because it doesn't exist anymore) and as such it won't update (delete) the attribute on the subscriber.
- An association will only be distributed if the association doesn't already exist on the target application, this will prevent changes made on the associations at the target application to be overwritten. Changes to the associations (like adding force-run on an existing association) won't be distributed as this would mean that the existing association needs to be overwritten.
- If there are multiple subscribers using the same working-context and these subscribers would extract the distribution at the same time, it could be that the subscribers will create the same application object at the same time in two different replica's, this is what is called a eDirectory collision. Make sure that if multiple servers are working in the same working context, one of these servers extracts the applications before the other subscribers start extracting.
- The Subscriber will add the file location used within the extract as a source location for this application, this functionality makes it possible to have multiple subscribers in the same context updating the same application with their file location, workstations will be able to use these different file locations. There is one limitation due to this functionality, if the file location on the golden application has been changed, the new location will be added and the old location won't be deleted. Make sure you keep the source location for your applications consistent.
This option can be used to send out an update without waiting for the channel to open. This can be very useful to send things like virus updates to the subscribers. Do not use this option if the channel is set to run immediately as this could cause some timing problems.
The Schedule type will specify how often a distribution gets built. The setting that should be used is depending on the information that the distribution contains, if the distribution is a daily update of sales information, then the distribution should be built every day and as such the schedule should be set accordingly.
If the distribution contains applications that normally shouldn't change so often, it might be useful to set the schedule to never and manually build the distribution (through iManager). Desktop Application distributions will build a new revision if the revision stamp on one of the application or the distribution object in eDirectory has changed. In eDirectory there are many reasons that can cause the object revision to change, in a large environment with a controlled roll-out of application updates it is often recommended not to use an automatic schedule for the build of application distributions. By setting the schedule to never and manually manage rebuilds through iManager, unwanted revisions can be avoided.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com