ZENworks Best Practice PDS
The appnote listed on the ZENworks Best Practices overview page only describes the best practices on creating Distributions, so let's start with adding some info about scheduling.
Distributor Refresh Schedule
The Distributor refresh schedule defines when the distributor should re-read e-Directory to get configuration changes. In general a single refresh at the end of the working day should be the best option.
Distribution Build Schedule
The Distribution build schedule defines when the Distributor needs to check if a new revision should be created and will gather this revision if needed. Determine how often a new revision needs to be created, set distributions that won't change to 'never' so that there won't be any unwanted rebuilds (if needed a build can be started manually from within iManager).
It's not recommended to use the option to build immediate. With the Build schedule set to run immediate the distribution will build at the moment the Distributor does a refresh, in general this would mean that a new build takes place at the end of the day when the distributor does it's refresh, however if a manual refresh is done during the day the same action will start and could cause high utilisation during business hours.
Some customers deactivate their distributions to avoid new revisions to be generated, deactivating the distributions has however more implications, these distributions won't be send through the channels. If a new server gets added to the environment it needs to receive all distributions, the distributions will need to be activated before they can be send to the new server.
A general recommendation is to have Distribution Build schedule set to a specific time short after the distributor did it's refresh (15 or 30 minutes after a distributor refresh is the most commonly used setting), if no new revisions should be generated the Build schedule can be set to never. If needed a manual build can be started through iManager.
Channel Send Schedule
The process used to send files to the subscribers is scheduled through the channel object. An understanding of the send process is required in order to understand how to configure the different channels, so let's have a look at the TED process.
At the moment the channel opens, the distributor will look at all distributions in this channel and will check if there are any revisions ready in the working directory of the distributor. For each revision the distributor will generate a so called ÃƒÂ¯Ã‚Â¿Ã‚Â½workorderÃƒÂ¯Ã‚Â¿Ã‚Â½, this workorder is an XML file that explains the task that needs to be executed. The workorders are kept in memory, they aren't written to disk.
One important thing to remember, if the channel is open from 7PM to 6AM, the workorders will be generated at the time the channel opens. This also means that if a distribution builds a new revision during the time the channel is open, this distribution won't be sent as there is no workorder created for this revision.
The workorderserver will look at the queued workorders and will start executing the workorders specified. The workorder server is able to handle outgoing connections to multiple servers but will only work on one workorder per server, if multiple workorder for the same server are in the queue, they will be handled one by one.
The workorder server will pick up a workorder from the workorder queue and will send this workorder to the specified subscriber. Next, the subscriber will check to see if this specific revision has already been received completely and will send this answer back to the distributor. In case the revision already exists on the subscriber the distributor will just update it's status files and if configured it will update the database. If the subscriber doesn't have the revision specified in the workorder or only has a part of this distribution in it's working directory (in this case the subscriber will indicate how much data has already been received) the distributor will send the revision file (distfile.ted) to the subscriber. As soon as the whole file has been received the subscriber will send a status message back to the distributor indicating the distribution has been received.
There are a few important thing's to think off when configuring the channel schedules.
- If a time window is specified, the workorders will be generated at the time the channel opens
- There will be a workorder for each revision of each distribution in the channel
- There will be workorders for all servers in the channel
- For each workorder the subscriber will return a status message, the Distributor will need to handle the incoming status messages and will need to update the status files and if configured also needs to write the update to the database
Subscriber Extract Schedule
With all our schedules we define a certain time for different events that need to be started. If we work with time there is the question what time do we use.
Within ZENworks Server Management we're using the GMT time, this means that the schedule will not shift in case daylight savings time starts or ends. The result of this behavior is that if daylight savings time starts it looks like the schedules shift one hour in time. When defining schedules it's good to be aware of this behavior so that schedules can be defined properly.
With ZENworks for Servers there is an automatic cleanup feature that cleans out the TED.LOG log file, however this log file isn't the only place where thing's are logged. There are two additional log files that are used to show the Subscriber and Distributor status from within iManager, these files (the distEvent.ted and subEvent.ted) do not get cleared automatically. In large environments it's recommended to clean out these log files periodically, this can be done by deleting the files manually or by using a policy that deletes the files every few months.