8.2 Scheduling and Tiered Electronic Distribution Objects
Scheduling can be a complex undertaking if you do not understand the fundamental scheduling principles. Review the following sections for guidelines that will help you to set up effective schedules for your Distributions:
8.2.1 Understanding the Tiered Electronic Distribution Objects and Their Schedules
When sending Distributions between Distributor and Subscriber servers, several Tiered Electronic Distribution objects are involved in the distribution process. Because of this, you must set schedules in some of the objects so that the process flows efficiently, yielding the intended distribution results.
The following sections explain the schedules:
The Tiered Electronic Distribution Schedules
The Tiered Electronic Distribution objects listed in Table 8-1 can be scheduled:
Table 8-1 Tiered Electronic Distribution Schedules
The above Tiered Electronic Distribution objects must be scheduled or they cannot perform their Distribution-related actions, such as determining when Distributions are discovered, built, distributed, and extracted.
The following Tiered Electronic Distribution objects do not have schedules:
- External Subscriber
- Subscriber Group
- Policy Package 1
1 Only the Container Package and Service Location Package. The Distributed Policy Package can be scheduled using the Schedule tab in the Distribution object.
The following sections explain scheduling issues:
Server CPU Usage by the Schedules
Schedules do not directly affect the total resources used by a Distribution (such as CPU cycles, bandwidth, and disk space), but rather when the resources are used. Therefore, Tiered Electronic Distribution’s schedules control when Distributions are built, sent, and extracted.
However, CPU usage is affected by which servers are being used to perform a schedule’s action. A server’s CPU time depends on which Tiered Electronic Distribution function is running on the server, as shown in Table 8-2:
Schedule Types
When you set an object’s schedule, you have the following schedule types to choose from:
- Never
- Daily
- Monthly
- Yearly
- Interval
- Time
- Run Immediately (except for the Distributor object)
For more information on the schedule types, see Frequency and Section B.0, Schedule Types.
Resolving Certificates when Changing Schedules
You might need to resolve certificates when making changes to one of the schedules. For more information, see Section 7.1.6, Resolving Certificates.
Distributor Object’s Refresh Schedule
A Distributor’s schedule determines when the Distributor reads Novell eDirectory™ for configuration changes. This enables the Distributor to respond to a request to build a Distribution. The Distributor rebuilds a Distribution when the Distribution’s schedule indicates that is should be built.
When the Channel’s Send schedule starts, the Distributor checks with the Subscribers that it sends to directly to see if they have the current Distribution. However:
-
If the Distribution is non-sequential, the Distributor simply checks for the current version.
-
If the Distribution is sequential (the File or Desktop Application types of Distributions only), it checks to see if the Subscribers have all of the versions of the Distribution, starting with the baseline and every change since the baseline.
If the Subscriber does have the entire Distribution, it checks with its subordinate Subscribers to see if they do, and so on down the routing hierarchy.
The time it takes to verify that all receivers have all of the Distributions in the Channel is minimal.
IMPORTANT:A Distribution might never get sent completely if the Refresh schedule is shorter than the time it takes to build or send the Distribution. In other words, if the Refresh schedule is too short, when the Distributor is refreshed the Distribution in the process of being built or sent could be cancelled before it has completed sending. Therefore, we recommend the Distributor’s Refresh schedule be daily, unless changes to Distributions warrant a more frequent refresh, then set it in hours. Do not refresh the Distributor more often than every five minutes.
Scheduling a Distributor
-
In ConsoleOne, right-click the Distributor object > click .
-
Select the tab > click the arrow for the drop-down box > click > select an interval, such as .
-
Set the start and end times, if necessary.
The and the fields specify the time window for performing the schedule’s action.
You can repeat the action every so often throughout the day.
You can also have the refresh occur randomly in the specified time window. For more information, see Using the Randomly Dispatch Option in a Distributor’s Refresh Schedule.
-
Click .
Distribution Object’s Build Schedule
The Distribution’s schedule determines when a Distributor is requested to create the Distribution file based on the definition in the Distribution object.
Most Distributions consist of a set of files that change over time and need to be redistributed on a regular basis. Each Distribution has its own Build schedule that tells the Distributor how often to rebuild the Distribution. When the Distributor builds a Distribution, it automatically compares it with the previous version to see if there are any changes.
For the File Distribution, if there are no changes in the current build, no new version is created. If there are changes, a delta is built consisting of only the changes to be distributed.
For the FTP, HTTP, and Software Package Distribution types, a new version is only built if there has been a change since the last version. The Distributor sends the complete new version to all target Subscribers.
The Distribution’s End Time is used to determine the end time for randomly dispatching events. In other words, the Distributor does not stop building the Distribution until it is complete.
Deleted files and directory synchronization are handled in the Build schedule.
Scheduling a Distribution
-
In ConsoleOne, right-click a Distribution object > click .
-
Select the tab > click the arrow for the drop-down box > select a schedule type, such as .
You can repeat the action every so often.
The and the fields specify the time window for performing the schedule’s action.
You can also have the build occur randomly in the specified time window (if you select the Daily schedule type). For more information, see Using the Randomly Dispatch Option in a Distribution’s Build Schedule.
-
Click .
Channel Object’s Send Schedule
A Channel’s Send schedule provides a window of time for when a Distributor can start sending its Distributions to the Subscribers associated with that Channel.
The Channel’s schedule applies only to the Distributor and its direct receivers (first tier Subscribers). When the Send schedule ends, the Distributor stops distributing to those first tier Subscribers.
Second-tier receivers and beyond do not adhere to the Channel’s schedule. The parent Subscribers that are sending Distributions to other Subscribers continues to send a Distribution after the Send schedule ends. Their subordinate Subscribers also ignore the Send schedule.
The Send schedule’s End Time forces the Distributor to stop sending a Distribution when the Send schedule ends. The Distributor starts sending the Distribution where it left off when the Send schedule begins again. A Distribution is not totally re‑sent. For example, if 50 MB of a 60 MB Distribution had already been sent before the disruption, when the Send schedule starts again for the Channel, the Distributor begins sending the remaining 10 MBs.
For information on how time zones affect a Channel’s schedule, see Scheduling Tiered Electronic Distribution Objects in Different Time Zones.
Cache and Forward has no bearing on whether a parent Subscriber continues to send a Distribution when the Channel’s Send schedule ends. Parent Subscribers who have completely received a Distribution prior to the Send schedule ending continues to send that Distribution to subordinate Subscribers. There is no mechanism for controlling whether parent Subscribers should continue to send when the Send schedule ends.
IMPORTANT:A Distribution might never get sent if the Send schedule is shorter than the time it takes to send the Distribution. Therefore, we recommend the Channel’s Send schedule be daily or in hours. Make the Send schedule at least long enough to allow all of the Channel’s Distributions to be sent.
Scheduling a Channel
-
In ConsoleOne, right-click the Channel object > click .
-
Select the tab > click the arrow for the drop-down box > click > select an interval (in the field), such as 1 hour > click .
The and the fields specify the time window for performing the schedule’s action.
For information about randomly starting the Send schedule (if you select the Daily schedule type), see Using the Randomly Dispatch Option in a Channel’s Send Schedule.
Subscriber Object’s Extract Schedule
The Subscriber’s schedule determines when a Subscriber can extract a Distribution that has been received.
The Subscriber’s End Time is used to determine the end time for randomly dispatching events. In other words, the Subscriber does not stop extracting the Distribution until it has completed the extraction process.
Scheduling a Subscriber
-
In ConsoleOne, right-click a Subscriber object > click .
-
Select the tab > click > browse for the Channel > click > click .
Make sure the Channel is listed as Active in the list.
-
Select the tab > the arrow for the drop-down box > select a schedule, such as , then click .
This schedule type causes the Subscriber to extract the Distribution as soon as it is received.
The and the fields specify the time window for performing the schedule’s action.
For information about randomly starting the Extract schedule (if you select the Daily schedule type), see Using the Randomly Dispatch Option in a Subscriber’s Extract Schedule.
-
Repeat these steps for each Subscriber.
8.2.2 How the Tiered Electronic Distribution Schedules Interrelate
The Tiered Electronic Distribution object’s schedules do not all interact directly with each other. There is a flow to how they are sequentially interconnected, as shown in Figure 8-1:
Figure 8-1 Schedule Interrelationships
Most importantly, the sequence of Refresh, Build, Send, and Extract must have their schedules configured so that they allow a Distribution to be successfully discovered, built, sent, and extracted within the time frame that you intend.
If even one schedule is out of sync with the other three, it can take longer than intended for a Distribution to be created and eventually used.
For example, if you set the following schedules as indicated, the results are:
-
Set the Refresh schedule to occur hourly: The Distributor is triggered to read eDirectory each hour to discover new or changed Distributions. You should determine this frequency by how large the Distributions are that this Distributor builds after each refresh. Generally, the shorter the time between refreshes, the better.
-
Set the Build schedule to run immediately: The Distributor builds the new or changed Distributions immediately after the Distributor’s Refresh schedule has caused it to read eDirectory to discovered them. However, very large Distributions might need to be built during off-peak hours.
-
Set the Send schedule to midnight: The Distributor sends its Distributions during off-peak hours when the network’s bandwidth is less busy.
-
Set the Send schedule to run immediately: The Distributor sends its Distributions as soon as they are built.
-
Set the Extract schedule to 3 a.m.: The Distributions received are extracted during off-peak hours when the server is likely to be the least busy. This is useful for servers receiving very large Distributions that do not need to be extracted and installed immediately.
-
Set the Extract schedule to run immediately: The Subscriber extracts the Distribution as soon as it is received. This is useful for servers receiving important Distributions, such as virus patterns.
Ways that you could mess up the distribution scheduling flow:
-
Setting the Distributor’s Refresh schedule to occur too frequently to allow time to build new Distributions or rebuild changed Distributions.
-
Setting the Distributor’s Refresh schedule to not occur frequently enough to get important Distributions built and sent on time.
-
Setting the Distribution’s Build schedule to occur too frequently to allow completion of the Distributions it was building during the previous schedule window.
-
Setting the Distribution’s Build schedule to not occur frequently enough to get important Distributions built and sent on time.
-
Setting the Channel’s Send schedule to not coincide with the Distributor’s Build schedule, possibly delaying the sending of Distributions.
-
Setting the Channel’s Send schedule window to be too short for all its Distributions to have time to complete sending.
8.2.3 The Three Timing Aspects of Scheduling
There are three time-related aspects that affect scheduling:
Frequency
When setting schedules, you determine how frequently you want a particular Distribution to be built, sent, and extracted.
The frequency for processing a Distribution can be determined using the schedule types listed in Table 8-3:
Table 8-3 Schedule Frequencies
The frequency you select in scheduling the distribution process should be determined by the purpose of the Distribution. For example:
-
Virus protection pattern files should be distributed and installed as soon as possible whenever they become available
-
A software update should be sent and installed only once
Duration
Some schedule types have durations that you may need to determine. The duration is defined by start and end times that provide a window for the time wherein the scheduled action can be performed.
Some schedules completely stop their function at the end of the schedule’s duration. Therefore, the duration of a schedule must accommodate the size of a Distribution with reference to how long it takes to build it, send it, and extract it.
Duration has different issues for different schedules, as explained in the following:
The Distributor Object’s Refresh Schedule
When a Refresh schedule starts, the following happens:
-
Distribution building stops: The Distributor stops building any Distributions that it is in the middle of building. Temporary build files are not cleaned up, and building of the unfinished Distribution are not resumed where it left off. Unfinished Distributions are rebuilt by starting over when the next Build schedule starts.
-
Distribution sending is interrupted: The Distributor stops sending any Distributions that it is in the middle of sending. However, when the Send schedule starts again, the Distributor picks up where it left of and finishes sending the Distribution.
Therefore, the Refresh schedule should not overlap the Build or Send schedules. In other words, it should start after the others end, and end when the others have not yet started.
Because the Refresh schedule can stop a Distributor from finishing a Distribution build, you may need to have multiple Distributors in your system to handle the different types of Distributions you’ll be creating. For more information, see Determining Whether You Need Other Distributors.
After the Refresh schedule’s end time is reached, the Distributor picks up where it left off in sending its Distributions, but restarts building Distributions that it had not completed building when it was interrupted by the start of the Refresh schedule.
The Distribution Object’s Build Schedule
When a Build schedule starts, only the Distributions that a Distributor knows about at that time start being built during the duration of the Build schedule. The Distributor learns of changes made to existing Distributions or of newly-created Distributions by reading eDirectory, which is done according to the Distributor’s Refresh schedule.
After the Build schedule’s end time is reached, building continues on all Distributions that it started building until the Distributions are finished being built or failed to be built.
The Channel Object’s Send Schedule
When a Send schedule starts, the Distributor begins sending its Distributions that are listed in the Channel, but only those Distributions that the Distributor knows about that are listed in the Channel at the time the Send schedule starts.
When a Send schedule’s end time is reached, the Distributor stops sending its Distributions, even if the Distributions have not completed being sent. However, the next time the Send schedule starts, the Distributor picks up where it left off and completes sending the partially-sent Distributions, plus begins sending any new or revised Distributions that the Distributor discovered during its Refresh schedule time.
The Subscriber Object’s Extract Schedule
When an Extract schedule starts, any Distributions it has already received or will receive during its schedule’s duration begins to be extracted all at the same time.
When an Extract schedule’s end time is reached, the Subscriber continues to extract all Distributions that it started to extract until the Distributions are finished being extracted or failed to be extracted.
Interval
An interval is how often during a schedule’s duration that the schedule restarts its function.
An interval is the equivalent to splitting up the schedule into a consecutively run series of mini-schedules. During a schedule’s duration, intervals act as a stop/start position within the duration, causing the same actions to take place as for the start and stop times of the schedule itself.
Intervals can have different issues for different schedules, as explained in the following:
The Distributor Object’s Refresh Schedule
Use intervals to sync up a Distributor’s refresh frequency with how often you want configuration information changes Distributions, Channels, Subscribers, or policies to be recognized.
The interval should not be so short that the Distributor doesn’t have time to read eDirectory and build the Distributions that it finds are new or changed.
The Distribution Object’s Build Schedule
For Distributions that have changes made often to the Distribution’s content that you want distributed in a timely manner, use intervals for the Build schedule to efficiently recognize those changes and provide rebuilt Distributions on time.
The Channel Object’s Send Schedule
When you set intervals within a Send schedule’s duration, Distributions that are in the process of being sent are stopped each time the interval begins, then pick up where it left off in sending the Distributions, plus start sending any new Distributions that were added to the queue.
If you do not use intervals, any Distributions added to the Send schedule’s queue after the Send schedule starts, are not sent until the next time the Send schedule starts. Therefore, setting intervals in the Send schedule allows you to have newly-queued Distributions included in the Send schedule’s window of time.
The Subscriber Object’s Extract Schedule
Intervals do not make sense for the extraction process. All Distributions received prior to the start of the Extract schedule, or received while the Extract schedule is open, is extracted. Extraction continues after its schedule ends, so intervals would be ignored by the extraction process.
Using Intervals with Distributors
For any schedule type that has an interval, the event does not start until after the Distributor has re-read eDirectory. For example:
-
Daily: If the Distributor is refreshed before the current day’s time window has passed, the event runs on the current day, then every day thereafter; otherwise, it first runs during that time window on the next day, then every day thereafter.
-
Interval: If you set the interval to be three days, the event runs three days after the day the Distributor re-reads eDirectory, then run every three days thereafter.
-
Weekly, Monthly, or Yearly: The event runs the first day, month, or specific date (the Yearly option) after the Distributor has re-read eDirectory. For example, on Wednesday you set up a Weekly event to happen each Sunday. The Distributor re-reads eDirectory on Thursday, so the event runs the following Sunday, and every Sunday thereafter.
-
Run immediately: As soon as the Distributor is refreshed, the event runs, then runs thereafter according to the interval you set.
To cause an event for one of the interval-related schedule types to execute out of sequence (other than Run Immediately), you can use the ZENworks Server Management role in iManager. For more information, see Section 2.0, Novell iManager.
8.2.4 Approaches to Scheduling
The following are approaches that you can use in determining how to set up your schedules:
Determining Whether You Need Other Distributors
Distributor server workload and the ability to complete Distribution building tasks should determine how many Distributors you need.
For example, if you have a very large Distribution that you want built during off-peak hours, which does not need to be sent immediately, and also have virus pattern Distributions that do need to be sent immediately, you might need two different Distributors, one with a daily refresh schedule (because you are only going to be building the Distribution once per day), and another with a frequent refresh schedule for discovering new virus pattern changes, so that their Distributions can be built and sent on time.
Putting Channels In Control
The idea in using Tiered Electronic Distribution is that you have a Distribution that you want to be used by the Subscribers at a certain time. To do so, you would have a Distribution built at a time when you want the Subscribers to use it. The key then is to get the other schedules to cooperate in getting the new Distribution down to the Subscribers on time.
The most useful scheduling configuration to do this places emphasis on the Channel’s Send schedule. Review the following scenario:
-
A Distribution’s Build schedule depends on how often you expect the Distribution’s information to change. For example:
-
If the Distribution consists of forms that change monthly, and it is critical to distribute the updated forms quickly, the Build schedule should be set to Daily. This means the forms would be checked each day for changes, and the change would be found the day, or within a day, of when they are made to the forms. When it is discovered that the forms have changed, a new Distribution is built.
-
If the Distribution consists of a software application that changes once every six months or so, you may want the Distribution to build weekly. When the application is changed for the Distribution, no more than a week would pass before the Distribution was rebuilt.
-
-
Set all of your Subscriber’s Extract schedules to Run Immediately. That way, no matter when a Distribution is built and sent, the Subscriber is ready to use it.
You can have all of your Subscriber’s Extract schedules set to Run Immediately and not worry about impacting the Subscriber server during peak business hours with a large Distribution, because you can use the Channel’s Send schedule to control when the Subscribers receives and extracts a particular Distribution.
-
Set the Channel’s Send schedule to correlate with when its Distributions are scheduled to be rebuilt, and to occur when you want the Subscribers to extract them.
-
In the case of a Distribution that changes monthly, set the Channel’s Send schedule to monthly.
-
In the case of a Distribution that only changes every six months or so, set the Channel’s Send schedule to yearly or at an interval of xxx number of days.
-
In the case of a large Distribution that needs to be extracted during off-peak hours, set the Channel’s Send schedule to run immediately, if all you are concerned with is the Distribution’s extraction, which is determined by the Subscriber’s Extract schedule, which can be set to control off-peak hour extraction.
-
Simply, build a Distribution when it is needed, get your Subscribers ready to extract and use the Distribution as soon as they receive it, then set up your Channel to send the Distribution at the optimum time for the Subscribers.
Enabling Load-Balancing for Distributors
To help load balance a Distributor server’s distribution duties, do the following:
-
Select the Maximum Number of Concurrent Distributions option on the Distribution object.
-
For the Distribution object, use the Randomly Dispatch option for the Daily, Monthly, or Yearly schedule type.
For more information on the Randomly Dispatch option, see Using the Randomly Dispatch During Time Period Option.
This spreads the network traffic that is caused by sending many Distributions over the entire scheduling window.
Inactivating Schedules
A Distribution can be set as Active or Inactive:
-
Active: The Active check box is found on the General tab of the Distribution object.
-
Inactive: Inactive is used when you are building a Distribution because you want to keep it inactive until it is ready to be sent to a Subscriber.
We recommend that as you are either creating or modifying a Distribution object, its associated Channel be set to Inactive until you are ready to begin distributing the Distribution package. This prevents the Distribution from being inadvertently sent before you have completed its configuration.
Scheduling Conflicts with Other Software
Most distributions are anticipated to occur during off-peak hours. For some networks, it is possible that this scheduling window may need to be very short. Other systems on the network can also use off-peak hours for processing, such as backups.
You might have instances where the limiting factor is available time; therefore, the critical condition is how fast the Distributions can take place, regardless of the resources consumed. You might need to experiment to determine the best relationship between time and resources.
8.2.5 Scheduling Issues
The following explain various scheduling issues:
Schedule Interactions
Each of the four schedules (Refresh, Build, Send, and Extract) interact with each other in ways that determine the success or timeliness of the distribution process:
Overall Interaction Issues
Because the distribution process is dependent on each of the four schedules interacting with each other in a timely manner, the purpose of a Distribution should help you to determine what each of the schedules need to be that are involved in its distribution process.
For example, if you want a virus pattern Distribution to be sent as soon as it is configured or as soon as a change to it has been completed, you need to make sure the schedules involved for all four Tiered Electronic Distribution objects allow the virus patterns to be in use by the target servers as soon as possible.
However, if you want a Distribution to be built, sent, and extracted during off-peak times, because it is very large and requires a lot of bandwidth in sending and server time in building and extracting it, then you would want each schedule to help in determining when to start those processes.
Because your Distributions can vary in both purpose and size, and because you may be using the same Distributor server for building these Distributions, you need to configure the various schedules to compensate for this. For example, the Distributor could have its Refresh schedule set to start every five minutes, and that would work for both sending Distributions immediately or during off-peak hours. This is because the Distribution’s Build schedule would trigger when the particular Distribution would get built (immediately or during off-peak hours).
Subscriber Extract schedules are where you could have conflicts between extracting Distributions immediately or during off-peak hours. However, if you set the Subscriber’s schedule to immediately extract and install its Distributions, you can use the Build and Send schedules to control when it gets certain Distributions. That way, it can extract virus pattern Distributions immediately (small, so no impact on the server), and extract large Distributions when they are sent during off-peak hours.
The fact that you can control build times individually for each Distribution, and that you usually create Channels unique to the Distributions, you can configure frequent schedules for the Distributor’s Refresh and Subscriber’s Extract schedules. In other words, most of your scheduling differences can be controlled by the Build and Send schedules.
Refresh versus Build
The Distributor builds a Distribution according to the Distribution object’s Build schedule, but not before the Distributor’s Refresh schedule has told the Distributor to read eDirectory for changes related to the Distribution, such as whether there is a new one, or that something in an existing Distribution has changed, requiring it to be rebuilt. This means the Build schedule is dependent on the Refresh schedule
Therefore, if you intend that a new Distribution be built right after you have created its object and configured it, the Distributor’s Refresh schedule must be frequent enough to cause the Distribution to be built. For example, you would have the Distributor’s Refresh schedule set to an interval of every five minutes.
However, if you only want a Distributor server to be building Distributions during off-peak hours, then you’d want its Refresh schedule to start and end during off-peak hours. Therefore, you would select a Refresh schedule type that allows you to specify such a time window. For example, Daily, Monthly, and Yearly each provide the capability to set a time window. Additionally, Daily allows you to specify which days of the week to read eDirectory for changes.
Refresh or Build versus Send
A Distribution can only be listed in a Channel after it has initially been built. Therefore, the Channel’s Send schedule is for existing Distributions, whether they be newly built or rebuilt because of changes. The Distributor sends a Distribution according to the Channel object’s Send schedule. This means the Send schedule is not dependent on the Refresh or Build schedules.
However, the Refresh and Build schedules are dependent on the Send schedule, because the Subscriber servers do not receive a Distribution until the Send schedule starts.
Build versus Send
A Channel only lists Distributions that can be sent. The Channel doesn’t care whether an existing Distribution is in need of being rebuilt. The Send schedule only tells the Distributor when one or more of its Distributions can be sent to the Subscriber servers that have subscribed to the Channel.
Therefore, the Build schedule is dependent on the Send schedule in that a Distribution should be initially built or rebuilt in time to be sent when the Channel’s Send schedule starts. Also, after a Distribution has been built, it must wait for the Send schedule to start to be sent.
Send versus Extract
When a Send schedule starts, the Distributor sends the Distributions listed in that Channel to the Subscriber servers subscribed to the Channel. However, the Distributions received are not extracted until the Subscriber’s Extract schedule starts.
Therefore, the extraction of a Distribution is only dependent on the Extract schedule. However, the Send schedule determines when the Distribution is available for extraction. Thus, the Extract schedule is dependent on the Send schedule.
The only dependency that the Send schedule has with the Extract schedule is that a sent Distribution is not extracted and installed until the Extract schedule starts, meaning you would not count on the Send schedule alone to get Distributions completely processed.
Time Zones and Scheduling
Multiple time zones can complicate your scheduling efforts. The following sections explain some of the issues:
Scheduling Tiered Electronic Distribution Objects in Different Time Zones
The following information concerning time zone offsets is from the perspective of the Channel object. However, this information is applicable to all Tiered Electronic Distribution objects that can be scheduled.
Because a Channel is an object in the tree that is not associated with a specific server, the Channel’s time is always set to the local time zone of the workstation that is running ConsoleOne® and setting the Channel’s schedule.
For example, if you (the administrator) live in New York City, the local time for any Channels you schedule from there is local New York time.
If Distributors in different time zones from the Channel have Distributions in that Channel, the Distributors need to send their Distributions according to the Channel’s local time schedule. For example:
-
You set a Channel’s schedule to be from 1 a.m. through 5 a.m. local time in Los Angeles.
-
In New York you select to have a Distributor’s Distribution listed in that Los Angeles Channel.
-
The Distribution can be sent only between 4 a.m. and 8 a.m. in New York because for New York, being three hours ahead of Los Angeles, its time window of 4–8 a.m. is happening at the same time as the Los Angeles time window of 1–5 a.m.
You should use a time zone offset to determine the true local time when the Distributor can send its Distributions. Also, because a Channel’s schedule determines when a Distribution can be sent, you must make sure the build schedules you set for your Distributions occur before a Channel’s schedule.
Calculating Time Differences
The World Time Server is a Web site where you can determine the time difference between any two locations in the world.
As you look at the site, note the following:
-
The locations in the left frame can be listed by countries or major cities.
-
The current GMT time relative to the International Date Line is displayed in the right frame.
-
When you select a location in the left frame, the time displayed in the right frame includes the day, date, whether Standard Time or Daylight Saving Time is in effect, and the GMT offset.
To use this site to calculate time differences between Tiered Electronic Distribution locations,
-
Select the location for one of the Tiered Electronic Distribution sites.
-
Note the time, day/date, GMT offset, and whether Daylight Saving Time is in effect (for future reference).
-
Select the location for another Tiered Electronic Distribution site.
-
Note the time, day/date, GMT offset, and whether Daylight Saving Time is in effect.
-
Repeat this process for all of the Tiered Electronic Distribution locations where you want to coordinate schedules.
-
Using the information you have gathered, calculate the time differences between the Tiered Electronic Distribution locations.
-
Taking into consideration when events are taking place locally at the various Tiered Electronic Distribution locations, configure the appropriate schedules using the time differences.
As an example,
-
A Distributor in Hawaii lists a Distribution in a Channel in New York.
-
Using the World Time Server Web site, you can find that the offset between the two locations is –6 when Daylight Saving Time is in effect. (The negative number means it is later in the time sequence, so you must subtract Hawaii’s time from New York’s time to arrive at the correct a.m. or p.m.)
-
If the Channel’s starting time is 1 a.m. in New York, select 7 p.m. for the Distributor’s schedule in Hawaii.
-
The result is that the Distributor can start to send its Distribution at 7 p.m.
-
Because Hawaii is not observing Daylight Saving Time and New York is, when New York moves back to Standard Time, the result would be 8 p.m.
If you wanted the Distributions to be sent later in the evening in Hawaii, the Channel’s time window would have to start later than at 1 a.m. in New York. For example:
-
You want the Distributions to begin sending at 11 p.m. in Hawaii.
-
You need to set the Channel’s start time to be 5 a.m. in New York.
When you set up your Channel schedules, you need to consider which object’s time window is more important. For example, it might be more important for the Distributor to be sending Distributions during off-peak hours. Therefore, using the New York and Hawaii example, to have the Distributions begin sending after midnight Hawaii time, you would need to have the New York Channel’s start time set to 6 a.m. or later.
Using Geographically-Based Channels
If you want a Distribution to be received at the same local time (such as 3 a.m.) when you have Subscribers in different time zones, use geographically-based Channels.
Using a single Channel for the Distribution only allows the Distribution to be received at the same time it is sent, meaning it could arrive at different local times if the Subscribers are not all in the same time zone. For example:
-
Distribution_A is created and listed in Channel_A.
-
The Send schedule for Channel_A is set to cause Distribution_A to be sent at 3 a.m. of the Distributor’s local time.
-
Subscriber001 is in the same time zone as the Distributor.
-
Subscriber002 is in a time zone that is 2 hours later than the Distributor’s.
-
Subscriber001 and Subscriber002 are subscribed to Channel_A.
-
Channel_A’s Send schedule fires at 3 a.m. local time of the Distributor owning Distribution_A.
-
Distribution_A is sent at 3 a.m. local time of the Distributor to Subscriber001 and Subscriber002.
-
Subscriber001 receives the Distribution at 3 a.m. its local time.
-
Subscriber002 receives the Distribution at 1 a.m. its local time.
However, your intention is that Distribution_A be received by both Subscribers at 3 a.m. their local times.
To get Subscriber002 to also receive Distribution_A at 3 a.m. its local time instead of 1 a.m., do the following:
-
Unsubscribe Subscriber002 from Channel_A.
-
Create Channel_A2 for Distribution_A.
-
Subscribe Subscriber002 to Channel_A2.
-
Set the Send schedule for Channel_A2 to cause Distribution_A to be sent at 5 a.m. of the Distributor’s local time.
Then:
-
Channel_A2’s Send schedule fires at 5 a.m. local time of the Distributor owning Distribution_A.
-
Subscriber002 receives the Distribution at 3 a.m. its local time.
Using Channels that are geographically-based, the Distributor sends the same Distribution at different times of the day.
Using the Randomly Dispatch During Time Period Option
The Randomly Dispatch During Time Period option is available for each of the schedules (Distributor, Subscriber, Channel, and Distribution). It is used in conjunction with a time window (Start and End times) that you can set for a Daily, Monthly, or Yearly schedule type.
Randomly dispatching causes the scheduled action to run at any time during the window for the day. This helps load-balancing on servers. However, random-dispatched schedules can be confusing if you are expecting an action to take place immediately.
The following describe the issues for the Randomly Dispatch option:
Using the Randomly Dispatch Option in a Distributor’s Refresh Schedule
You can use the Randomly Dispatch option for Distributor Refresh schedules to load balance Distributor refreshes from eDirectory. This is useful to minimize the network traffic that can be caused by many Distributors trying to read eDirectory at the same time.
Be sure to coordinate a Distributor’s Refresh schedule with that Distributor’s related Distributions’ Build and Channels’ Send schedules.
The Distributor’s Refresh schedule should be determined by how frequently Tiered Electronic Distribution information is updated in eDirectory. For example, how often new Distributions are created, properties of existing Distribution objects changed, new Channels are added, and so on. The Distributor cannot know of changes made to Tiered Electronic Distribution objects without re-reading eDirectory. An eDirectory refresh should finish before the Build and Send schedules begin.
IMPORTANT:Do not refresh the Distributor more often than every five minutes. The following can need up to five minutes to complete their processes: Distribution building, eDirectory replication, and tree walking (when no Search policy is defined).
If you are using the Randomly Dispatch option, you should consider the End time for the Refresh schedule when setting the Start times for the Build and Send schedules.
Using the Randomly Dispatch Option in a Distribution’s Build Schedule
You can use the Randomly Dispatch option for a Distribution’s Build schedule to load-balance the Distributor’s work in building Distributions. This becomes more necessary as the number of Distributions for a Distributor grows.
Be sure to coordinate a Distribution’s Build schedule with its Distributor’s Refresh schedule and any related Channels’ Send schedules. A Distribution build should begin after the Refresh schedule ends and finish before the Send schedules begin.
IMPORTANT:Do not refresh the Distributor more often than every five minutes. The following can need up to five minutes to complete their processes: Distribution building, eDirectory replication, and tree walking (when no Search policy is defined).
If you are using the Randomly Dispatch option, you should consider the End time for its Distributor’s Refresh schedule when setting the Build schedule’s Start time; and, you should consider the End time for the Build schedule when setting the Start times for the Send schedules.
Using the Randomly Dispatch Option in a Channel’s Send Schedule
You can use the Randomly Dispatch option for a Channel’s Send schedule to begin sending its Distributions to Subscribers randomly within a scheduling window. Each Distributor that has Distributions in the Channel calculates a random time between the specified Start and End times to begin sending its Distributions. This helps to balance the distribution workload for the network over a period of time.
For example, Distributor A and Distributor B have Distributions in a Channel. Each Distributor would calculate its own random time to begin sending its Distributions.
Another use of the Randomly Dispatch option for the Send schedule is if you have many Channels and you want all Distributions for all Channels to occur between 10 p.m. and 4 a.m. Using the Randomly Dispatch option in each Channel would allow you to disperse Distribution sending times for all Channels over that six-hour period of time.
If you are using the Randomly Dispatch option, you should consider the End time of each associated Distribution’s Build schedule when setting the Send schedule’s Start time; and, you should consider the End time for the Send schedule when setting the Start times for all associated Subscribers’ Extract schedules.
Using the Randomly Dispatch Option in a Subscriber’s Extract Schedule
You can use the Randomly Dispatch option for a Subscriber’s Extract schedule to balance the Subscriber’s work load in extracting Distributions.
If you are using the Randomly Dispatch option, you should consider the End times for the Send schedules of the Channels where the Subscriber is subscribed when setting the Start time for the Extract schedule.
Repeating Actions
For schedule types that have the Repeat the Action Every field, how this option works depends on other factors, such as other schedules and how frequently the Distributor reads eDirectory.
For example:
-
You select Daily as the Send schedule for a Channel
-
You set 1:00 a.m. to midnight (23 hours) as the sending window
-
You set the Repeat the Action Every field with 1 hour as the repeat value
The action (sending the Distribution) repeats as follows:
-
Starting at 1:00 a.m. and repeating every hour, the Distributor queues the Distribution to be sent.
-
If a Distribution is in the process of being sent, it continues to be sent.
-
Once a Distribution is off the queue after being sent, the Distributor queues the next newer version for sending.
If a previously queued version of this Distribution has not been sent yet (still in the queue), the next newest version is placed in the queue. In other words, only one version of the Distribution (the last built) is queued while another version of the Distribution is being sent.
The Distributor always sends the latest Distribution, even if the Subscriber already has it.