Thus far, the majority of this book has been on the communication within a site. In this chapter, you learn about how to communicate between sites in Systems Management Server. Site-to-site communication plays an important role in a regular daily setup
of SMS and is usually involved in tasks from inventory collection to setting up a secondary site. In both the cases, the Scheduler and the Senders and the Despooler play significant roles in transferring data from one site to another.
As you can see in Figure 37.1, the Scheduler initiates most data transfers by activating jobs from the SMS database (see step 1). Next, the Scheduler prepares packages and instructions for sending and produces send requests. The Scheduler has full
control over where these files are placed and usually places the files in appropriate sender boxes. The third step in the figure shows that each sender monitors its own outbox and provides data transfer to another site. Finally, when the data is received,
the Despooler decompresses it and carries out any associated instructions.
FIGURE 37.1. Overall flow of the way communication takes place between sites.
The Despooler and the Scheduler are not discussed in this chapter because I assume you have already studied them. This chapter concentrates on senders and their role in site-to-site communication, as well as how the senders work with the
Scheduler Service.
Think of a sender as a kind of a robust copy program. This program is designed to send data over a variety of network connections and to handle interruptions and data transfer errors. The information is transferred by the sender to locations that can
still be specified. Systems Management Server provides senders for local area network (LAN), Remote Access Service (RAS), SNA architecture, and communication mechanisms. There is room for third-party vendors to extend the System Management Server (SMS)
with their own senders, such as MAPI. An example of a third-party vendor is a MAPI sender.
Information between sites can generally flow through three types of senders (see Figure 37.2):
FIGURE 37.2. The LAN/WAN, RAS, and SNA senders that are included with the Systems Management Server.
Information flows between the three types of senders that are built into the Systems Management Server (SMS). However, if a company decides to use a third-party solution, the vendor's sender is also a means of media over which communication between sites is possible.
RAS senders use only Windows NT Remote Access connections to send data between two sites. Once connected, the data can only use three types of connections:
For all the preceding methods to be available, RAS must be started on Windows NT.
The LAN sender is the default sender that is installed when the site is first installed. Any job that is not to go over the network to another site (that is, any job that is not part of site-to-site communications and has a destination of local site)
uses this sender. The LAN sender uses the Windows NT redirector-server (that is, it uses the Windows NT workstation and Server services) to send traffic over a LAN or wide area network (WAN).
Two sites communicating over SNA senders use the SNA's Advanced Peer-to-Peer (APPC) or Advanced Program-to-Program (APPC) to communicate. The communication takes place between the two site's servers, each acting as a SNA LU 6.2 (Logical Unit) nodes, and
each must have the required Systems Management Server (SMS) software installed. The Microsoft SNA Server must be installed in order to use the SNA sender.
This section discusses the methodology of site communication and the actual sending of the data, as well adding senders and configuring outboxes and bandwidth. You explore the topics in the following order:
In site-to-site communication, each of the six senders (three on each side) performs three tasks:
The outbox of each sender is monitored by the SMS_EXECUTIVE service. This occurs for each installed sender. For every installed sender, a thread called the sender dispatcher thread within the sms_executive is used for monitoring the outbox associated with that particular sender. The outbox is monitored for send requests. The instructions for senders are placed in the outbox by the Scheduler Service. These instructions are placed as Send Request Files (with the SRQ extension). Monitoring the outbox includes any file changes in the SITE.SRV\SENDER.BOX\REQUESTS\outbox directory. The sender wakes up at the interval specified in the Polling Interval in the registry. This is determined by the Services Response time that in turn is set in the Services dialog box displayed from Site Properties. Upon monitoring its outbox if the sender finds an SRQ file, it creates another thread to service the send request placed in the outbox by the Scheduler.
FIGURE 37.3. Senders move the file from one site to another.
The sender moves the data. The data moved is not SRQ files. The SRQ files are only a send request put in the outbox by the Scheduler. The data is moved to the site or between sites, packages, and jobs. Usually, the data moved is in the form of
PKG or INS files. The data is moved from the location of the SITE.SRV\SENDER.BOX\TOSEND directory of the sender site to the SITE.SRV\DESPOOLER.BOX\RECEIVE directory in the destination site. The sender uses standard I/O file requests to move data to the
destination site. No SMS processes are required at the destination site to receive the data, because the Windows NT Server service receives the data. The data is then placed in the remote receive box. Data is transferred in blocks. The type of sender used
(LAN, RAS, SNA) determines the size of these blocks. The default sender, the LAN sender, has a block size of 256K blocks at a time. At every successful send of every block, the status file is updated. If, however, the block transmission failed, the sender
will retransmit the block starting from the last successful send. During the transmission, the file's extensions are changed to prevent the Despooler service from starting to process the data before it is fully received. The PKG files become PCK, and the
INS files become TMP.
The final piece of the puzzle in data sending is to update the status of the files or data transmitted with the Scheduler. As the processing of the SRQ file begins, this file is renamed to a status file with an SRS extension. This file is constantly
being updated by the Scheduler. The update occurs after each block transmission to the destination site. This is a successful transmission. If an error is encountered in the transmission, an error status is placed in the SRS file. Upon completing the
transmission, the file is updated with a Complete status and is then deleted by the Scheduler.
The previous sections lead to this general summary: A pending request is SRQ, and a working or in-process request is SRS. Either or both of these request files are composed of different sections that describe details at various levels of the request:
All of preceding can be displayed with a utility that is provided on the SMS Server CD-ROM: DUMPSEND.EXE.
The Send Request Data Record has various fields:
The range of priority is 1, 2, and 3 for high, medium, and low, respectively. The other two fields are important because the Destination Site is a three-letter site code assigned by the SMS Administrator during installation and the JOB ID number in the
SMS Server software.
Both the Sender and the Scheduler service use or update the Sender/Scheduler record. In fact, it is updated by the sender and used by Scheduler to determine the status of the send request.
The fields or sections are as follows:
Cancel has only one field: MODE.
It can read Canceled or Not Canceled. If the send request is canceled, this section is changed from Not Canceled to Canceled.
Action Code also has only one major heading: Code
The Scheduler sets the action code to instruct the sender how to handle the send request. There are three requests:
Address has just one field: Address
This specifies a universal naming convention (UNC) addressing scheme or RAS phone book entry. The SNA path name can also be used. The UNC goes hand-in-hand with the Default LAN Sender.
The package file contains a new heading: File. This is merely a UNC pathname to the package file to be sent.
Assume that an Windows NT-based computer that is a Site Server has a computer name of Test1 and the package file is called TESTPACK.PKG. Assume also that the file is located in the SITE.SRV directory and OUTBOX subdirectory. A UNC for the location of
the package file will read as follows:
\\Test1\SITE.SRV\OUTBOX\TESTPACK.PKG
Instruction File has one field: File. This contains the UNC pathname for the Instruction file to be sent.
You learned earlier that, by default, only the LAN sender is installed. For the Site Server to communicate over a different type of communication medium such as RAS or SNA, additional senders need to be installed or added (see Figure 37.4).
FIGURE 37.4. The hierarchy of communicating between sites in an SMS environment.
This section briefly mentions how to pass senders in SMS (see Figure 37.4). To communicate with another site using a sender other than the default [LAN] sender, you must first install the sender at each site. This requires a series of steps:
FIGURE 37.5. The steps necessary to add a sender in an SMS environment.
Sender outboxes are a means of controlling how the Scheduler uses the senders. Therefore, it is an integral part of tuning the site-to-site communication mechanisms (see Figure 37.6). The outboxes are no more than subdirectories in the
SITE.SRV\SENDER.BOX\REQUESTS directory.
FIGURE 37.6. The configuration screen in the SMS when configuring outboxes.
The configuration screen in the SMS when configuring outboxes. Each outbox has the following properties to be configured:
To configure outboxes, choose Outboxes from the Site Properties dialog box, select an outbox, then choose Schedule.
Priority has three levels of adjustment: low, medium, and high. This priority can be adjusted for each outbox and can also be adjusted for the same box at different times of the day. The Scheduler Service places the job in the outbox only if the job's
priority is higher or equal to that of the outbox for that particular instant or time of the day.
If an outbox is configured as a backup, a job that has failed during the regular start from the original outbox can be retried from the backup outbox. Remember, each sender (RAS, LAN, SNA) has its own outboxes, so you can use one outbox as its own media
sender and the other as a sender's backup. This works only if the destination site or the remote site also has a backup outbox.
The outbox can be closed and used during different times of the day. If the outbox closes while a request is in progress, the job is paused and later resumed when the outbox is available.
The utility that enables you to control the sender bandwidth is the SMS Sender Manager. This utility is located on the PSSTOOLS directory on the SMS Sever CD-ROM and enables the administrator of the SMS management system to control the bandwidth usage
either by site or by sender. The site controlling is done by address rather by site name. In this section, you look at control of the bandwidth usage by the sender. Different rates can be set for each sender. The options are as follows:
The rate can be set for each hour of the day and therefore is extremely important in regulating network traffic. This option controls the packets sent each hour. Using this, you can also set the Maximum Transfer Rate and choose Set Limit.
Using Concurrent Sessions, you can set the total number of concurrent sessions per site as well as the number of concurrent sessions.
Retry Settings merely sets the frequency of the sender retries.
The Scheduler selects a sender to send data to a remote site or a destination site. If multiple jobs are waiting to send data, the Scheduler automatically orders the jobs in a queue for servicing. This order is created or based upon two conditions: the
priority of the job and the job start time. The senders are then scheduled to send the jobs' data in that order. In short, the Scheduler not only queues the jobs in short time order but also selects the sender that will send the job across to the
destination site in the shortest time.
The LAN Sender is the default sender loaded when the SMS is first installed. The configuration of site-to-site communication using the LAN sender is a three-step process (see Figure 37.7). This sender can easily be thought of as a enhanced version of
the COPY application.
FIGURE 37.7. The steps taken to configure a LAN Sender Address.
The LAN sender uses general windows NT components to communicate with the destination site. Loopback functions are used to send the job to itself. In self-promoting jobs, the LAN sender does not use Window NT components. Because the LAN sender works on
a block at a time, it automatically knows where to start should the communication fail, which makes it an enhanced copy program—one that is smarter and one that does not work on sectors, but rather on blocks at a time. The three steps are as follows:
As with LAN sender, implementing the RAS sender is also done in three steps, but they are quite different because the protocol they use is different (see Figure 37.8):
FIGURE 37.8. The steps taken to configure a RAS sender Address.
The RAS sender is similar to the LAN sender in its architecture, because it also uses the Windows NT network components to move data. The RAS Sender resides in the application layer, and from there it makes requests to the lower layers to complete the
connection to the destination site. In short, RAS sender does its work on top of the RAS mechanism.
Configuring the SNA sender is achieved in four steps (I assume that the reader is knowledgeable about SNA architecture). Therefore, try to integrate the Systems Management Server into an existing architecture (see Figure 37.9). Here are the steps:
FIGURE 37.9. The steps taken to configure the SNA Sender Address.
IF the data is not flowing properly between sites, it could initially mean a few possibilities:
The way to approach this is in the following order:
A Systems Management Site is composed of a Site Server and a SQL Server database for Windows NT. This is required for the primary site only, a Site Server domain, and additional domains, as well as logon servers, distribution servers, helper servers,
and client computers. The key to efficiency of Network Management lies in properly selecting a site development plan for your organization. This is discussed in Chapter 35, "Installing SMS," in more detail.
Planning within a site is also important because a user must determine which servers to use as logon servers, which computers as a distribution server, and which ones as helper servers. You should also evaluate the following and incorporate it in the
final decision:
The preceding parameters should not only be thought of just during the planning stage and during installation, but also be kept in mind for future growth of the corporate network—which usually grows both in size and complexity. Keep in mind that
the SMS domain and the NT domain are two different logics. That is, an NT Domain can be an SMS domain. This is the reason you need Windows NT Server as a Domain Controller and install SMS Server on it. The SMS Domain that you set up during installation can
easily make use of and work within the Windows NT Domain. SMS Server can include a Novell Server, however, and thus operate at a different Domain Boundary. This boundary is not recognized by Windows NT Domain Controller; hence every machine within the SMS
boundary is not able to function in the Windows NT Domain Security environment.
It is extremely important for the network administrator to seriously plan the implementation and managing strategies of the SMS architecture. One small mistake could turn out to be extremely costly in troubleshooting. Furthermore, if SMS is to be implemented, the network architecture of the existing backbone may also have to be altered to account for the difference in the Windows NT domain environment and the SMS domain environment. The bandwidth usage suddenly becomes an important issue as yet another server will take up part of the bandwidth.
