## MS BackOffice Unleashed

- Introduction to Senders
- Different Types of Senders
  - RAS
  - LAN
  - SNA
- Site Communication
  - Data Sending
    - Monitoring the Outbox
    - Moving Data to the Destination Site
    - Update Status with Scheduler
  - Sender Status
    - Send Request Data
    - Sender/Scheduler
    - Cancel
    - Action Code
    - Address
    - Package File
    - Instruction File
  - Adding Senders
  - Configuring Sender Outboxes
    - Priority
    - Backup
    - Closed
  - Controlling Sender Bandwidth.
    - Rate Limits
    - Concurrent Sessions
    - Retry Settings
  - Interaction with Scheduler
- Implementing LAN Sender
- Implementing the RAS Sender
  - RAS Sender Architecture
- Implementing SNA Sender
- Sender Troubleshooting
- Planning the SMS Site
- Planning Within a Site
- Summary

#
— 37 —

##
Planning and Managing a LAN with SMS

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.

###
Introduction to Senders

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.

###
Different Types of Senders

Information between sites can generally flow through three types of senders (see Figure 37.2):

- RAS
- LAN
- SNA

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

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:

- Normal phone lines (ASYNC). This type of connection is called an ASYNC, for asynchronous, connection.
- Integrated Services Digital Network (ISDN). These use a special type of modem but are twice as fast as the fastest 28.8K/sec transfer-rate modems currently available. The ISDN speeds start at 56K/sec transfer rate.
- X.25 lines. These are special lines that require special X.25 cards in the Site Servers for communication to take place.

For all the preceding methods to be available, RAS must be started on Windows NT.

####
LAN

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).

####
SNA

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.

###
Site Communication

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:

- Sending data
- Checking sender status
- Adding senders
- Configuring sender outboxes
- Controlling sender bandwidth
- Interacting with Scheduler

####
Data Sending

In site-to-site communication, each of the six senders (three on each side) performs three tasks:

- Monitoring the outbox
- Moving data to destination site
- Update status with Scheduler

#####
Monitoring the Outbox

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.

#####
Moving Data to the Destination Site

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.

#####
Update Status with Scheduler

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.

####
Sender Status

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:

- Send Request Data
- Sender/Scheduler
- Cancel
- Action Code
- Address
- Package File
- Instruction File

All of preceding can be displayed with a utility that is provided on the SMS Server CD-ROM: DUMPSEND.EXE.

#####
Send Request Data

The Send Request Data Record has various fields:

- Priority
- Destination Site
- Job
- Job Request
- Outbox

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.

#####
Sender/Scheduler

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:

- First sender started at
- Sender started at
- Sender ended at
- Sender gate heartbeat at
- Scheduler to restart at
- Total bytes to send
- Total bytes left to send
- Sync point is
- File type is 0 = none, 1 = Instruction, 2 = Package File
- Number of connection = number of attempts
- Sender ID

#####
Cancel

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

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:

- SREQ_ACTION_NONE(0) means normal processing.
- SREQ_ACTION_RETRY(1) means failed requests are retried.
- SREQ_ACTION_DELETE(2) is for canceled requests or completed requests.

#####
Address

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.

#####
Package File

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

Instruction File has one field: File. This contains the UNC pathname for the Instruction file to be sent.

####
Adding Senders

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:

1. Choose Sender from Site properties. The sender dialog box appears.
2. Choose Proposed Properties.
3. Choose Create. A Sender Properties dialog box appears.
4. Choose the appropriate Sender from this list:
5. MS_LAN_SENDER
6. MS_ASYNC_RAS_SENDER
7. MS_X25_RAS_SENDER
8. MS_ISDN_RAS_SENDER
9. MS_INTER_SNA_SENDER
10. MS_BATCH_SNA_SENDER
11. Type the name of server in the Server Box.
12. Type the letter of the Systems Management Server drive in the Drive box.

FIGURE 37.5. The steps necessary to add a sender in an SMS environment.

####
Configuring Sender Outboxes

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:

- Priority
- Backup
- Closed

To configure outboxes, choose Outboxes from the Site Properties dialog box, select an outbox, then choose Schedule.

#####
Priority

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.

#####
Backup

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.

#####
Closed

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.

####
Controlling Sender Bandwidth.

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:

- Rate Limits
- Concurrent Sessions
- Retry Settings

#####
Rate Limits

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.

#####
Concurrent Sessions

Using Concurrent Sessions, you can set the total number of concurrent sessions per site as well as the number of concurrent sessions.

#####
Retry Settings

Retry Settings merely sets the frequency of the sender retries.

####
Interaction with Scheduler

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.

###
Implementing LAN Sender

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:

1. Configure the physical network (that is, with TCP/IP IPX/SPX or NetBEUI protocols). If using NetBEUI and going over a WAN link, you must use a bridge and not a router because NetBEUI is a non-routable protocol.
2. Install the Site Servers (the LAN sender is automatically installed as the default sender).
3. Configure the address between sites.

###
Implementing the RAS Sender

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):

1. Install and configure RAS server at each site. This does not necessarily have to be the Site Server.
2. Install the RAS sender at each site. It is important to note here that the RAS server must be installed on the Windows NT Domain Controller. If it is installed on a computer that is not the Site Server, the computer on which the RAS sender is installed becomes the helper computer in the SMS environment. Then the RAS sender server also can have either the server or client RAS or RAS software installed. If the client RAS software is installed, although it has the RAS sender on it, this computer does not receive incoming traffic. RAS clients do not receive calls. The RAS server with the RAS sender is a better combination to choose.
3. Configure an address, using the RAS sender to the destination site.

FIGURE 37.8. The steps taken to configure a RAS sender Address.

####
RAS Sender Architecture

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.

###
Implementing SNA Sender

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:

1. Install Microsoft SNA Server on a computer at each site. This is a must for the SNA sender to work. The computer on which the SNA server is installed does not necessarily have to be a Site Server.
2. Configure the SNA Link services between sites. These services include SDLC, X.25, and 802.2. The link services control hardware-to-software communications in the SAN architecture.
3. Install the SNA client software on the Site Server in order to receive packages over the SNA.
4. Install and configure the SNA sender on the Site Server. Then create an address at each site to use the SAN sender and the link.

FIGURE 37.9. The steps taken to configure the SNA Sender Address.

###
Sender Troubleshooting

IF the data is not flowing properly between sites, it could initially mean a few possibilities:

- Data is not arriving at the sender.
- Data is not processed properly by the destination site.
- Data is not being transmitted correctly by the sender.

The way to approach this is in the following order:

1. First Check the Scheduler service as it controls the sender. Check to see whether the monitoring of the outboxes is appropriate. Check also to see whether the Scheduler is receiving the jobs.
2. After full verification of the Scheduler, the second area is the sender. Check to see whether the appropriate sender is installed and configured for the destination site.
3. Finally, the Despooler service at the destination site should be checked for proper processing.

###
Planning the SMS Site

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

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 amount of hard disk space needed to support the MSSQL database
- The amount of hard disk space required to support the Systems Management Server Services and applications
- The amount of hard disk space needed for software packages
- The amount of memory needed
- The load on the Server processor

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.

###
Summary

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.