Altiris Agent Transport Service Dataflow
search cancel

Altiris Agent Transport Service Dataflow

book

Article ID: 179470

calendar_today

Updated On:

Products

IT Management Suite

Issue/Introduction

 

Resolution

Question
What are the details for an Altiris Agent Transport Service Dataflow?

Answer
Altiris Agent Transport Service Dataflow diagram:





Altiris Agent Transport Service Dataflow Walkthrough:

  1. .NSI files are created and combined to an .NSE file. The .NSE is sent to the NS via the agent transport service.
  2. .NSE files are posted via HTTP or HTTPS (encrypted data transfer). HTTP POST process is used with the data itself composed in XML format to the postEvent.aspx page as XML.
    1. The standalone inventory process will copy the .NSE file using SMB to the NSCap\EvtInbox folder under the \\NShostname\NScap share.
    2. The Altiris NS receiver service monitors the NSCap\EvtInbox folder, and will pass any files written to this queue over to the Event Router process. Stopping the receiver service will stop the transfer of .NSE files from the EvtInbox to the event router.
    3. Clients compress .NSE file before sending them to the NS if the .NSE file size is greater than the value defined in the "Compression" element of the communications section of the agent policy.
    4. If the .NSE file is greater than 512 KB (by default), it is streamed to the NSCap\Temp folder as a temporary store. Once the complete .NSE file has been received it is written to the file queue. The 512 KB setting can be modified using the "LargeEventThreshold" registry value (in bytes).
    5. The header of the .NSE file is then checked for the compression algorithm and un-compressed if required.
  3. The Router Object places the .NSE a queue based on size. .NSEs that contain inventory data are typically 15 to 999 KB. .NSEs that contain status messages are typically around 1 KB. The event queues that Notification Server uses are file queues. See Event Queues below. It is important to remember that the event router process is running under the IIS anonymous user security context. This is necessary so that anonymous connections may post data to the event router via the postevent.asp page. When modifying default NTFS security (everyone = full) on the folders listed above it is essential that the IIS_anon is granted read, change and delete permissions so that the incoming .NSE may be processed.
  4. The Event Queue used depends on the size of the file being processed. Typically, an inventory file would use the EvtQueue. See Event Queues (next topic) for information on the Event Queues.
  5. The Dispatcher Service monitors both event queues using two Dispatcher thread pools, one for the large event queue and one for the small event queue. .NSEs get processed generally on a last in—first out basis. There is no order to which NSEs get processed. You cannot assume any order that the .NSEs get processed.
    1. When an .NSE appears in one of the event queues, the Dispatcher thread that is monitoring that queue moves the data into the Process directory.
    2. The NS Dispatcher Service, through a Dispatcher thread, gives the .NSE in the Process directory to the Notification Server processes. The .NSE is processed by the Notification Server Event Processor.
    3. This Event Processor finds which policy the .NSE is attached to, looks at the Automated Actions that are in the policy, then acts on the .NSE based on the policy and Automated Actions. This usually includes inserting the .NSE data into the Notification Database. License verification also happens at this step. If the .NSE is from a computer that is not licensed based on the GUID ID lookup for licensed computers, the .NSE is put in the bad folder.
    4. If the data is corrupted or cannot be processed, it is placed in a Bad event directory by the NS Dispatcher Service.
  6. Optional (can only happen if you have the Altiris Connector for SMS installed):
    1. If you have installed the Altiris Connector for SMS, and the Notification Server is set up to forward data to SMS, MTS creates a process to pass the inventory data in native SMS format (MIF) to an SMS CAP (Client Access Point).
    2. The SMS Server picks up the inventory data from the SMS CAP.
    3. The SMS Server places the inventory data into the SMS database.