Following the Notification Server Web Stack, from the Network Interface Card to the Hosted Services

One of the great design decision behind the Notification Server design was to set it to run on top of IIS. In this manner the NS team didn't have to worry about scalability: this was all done by Microsoft thanks to the improvements made from IIS 4 to IIS 5 and now IIS 6 (IIS 7 is not yet in use for Altiris).

 

However one of the (minor) downside to the design is that there are a number of elements that are not necessarily clear or well known about the underlying architecture and configuration items.

 

So in this article we will review the components involved and some of the configuration items, from a workstation or package server agent all the way up to the client config manager objects.

 

Here is an overview of the elements we will review today (click to open in a new windows):

 

 

 

Starting from the client we know that the Altiris Agent communication interfaces are provided by the Notification Server on http or https using the IIS configuration (by default port 80 or 443).

 

The Altiris agent crafts the required http (or https, but we'll omit it from now on)  request and send it to the Notification Server in order to perform its many operations (request the client configuration xml, download package source, snapshot or files, post inventory to the server etc). The Altiris Agent and Package Server agent are using the same COM component to communicate via the network and transmit the htpps request. Note that the Task Agent is using a different type of mechanism which we won't review here to communicate with it's Task Server.

 

So moving up the stack, once the http request as traveled across the network to the Notification Server it is received on the Network Interface Card (NIC) which passes it upstream to the Win32 kernel by means of its own drivers and to tcpip.sys.

 

The tcpip.sys driver handles the ip datagrams and higher level tcp connection before it routes the incoming requests to applications that registered to listen for specific port or to open client session. In IIS 6.0 incoming http request are handled in kernel mode via the http.sys driver, so tcpip.sys passes the tcp data to to this driver which handles the queuing and routing of requests to the appropriate worker process threads.

 

The queue length under the http.sys driver are configure on the IIS metabase (accessible thru inetmgr.exe or the IIS mmc snap-in).

 

It is set to limit the queue depth to 1,000 request by default as shown here (click to enlarge):

 

 

This setting can have a serious impact on the Notification Server if the environment is not configured to spread the various agent workloads over time. For example if 10,000 computers are running a daily inventory at 09:00 the server could be hit by a fair proportion of these computers (likely anything above the 5,000 mark) thus causing a large count of requests to be dropped from the queue. And this would not be because NS doesn't have the capacity to process them, but because the kernel queue length is not configured for very high traffic by default. So bear this in mind when doing capacity planning and reviews.

 

Moving on up, now that we have past the queue which is serviced by the default application pool in the case of the Altiris agent interfaces (and the Altiris Agent console) the requests are processed by ASP.Net in the w3wp.exe process space.

 

This task involves loading the clr types and base types defined in the aspx/ascx/asmx pages. The pre-html processing then takes place. In the Altiris web pages the main processing is done within the local dll (under the sub-directory bin) and makes use of hosted objects provided by the Altiris Service.

 

Let's make this a little more concrete by looking at a specific case: a newly installed agent needs to register with the Notification Server and send a request to CreateResource.aspx. This file is located under /Altiris/NS/Agent. The dll containing the asp.net code that execute when the page is loaded is under /Altiris/NS/Agent/bin. 

 

The page loads on the server and executes some code to check that the http get request is correctly formatted. If not it sends back an error message to the agent. If the request is correctly formatted the page will requests a ClientConfigManager object instance from the Altiris Service.

 

The Altiris Service uses a hoster that can be access via tcp internally. This hoster is the central point of control to ensure that core Altiris objects are not instantiated (and manipulated unduly) by external or internal code. It also ensures that central security checks and auditing can be performed.

 

Once the ClientConfigManager is instantiated and a reference is received by the asp.net thread running inside the w3wp process the page can consume the object, calling the CreateResource method.

 

The ClientConfigManager execute the method (and completes the registration process) by accessing the database and calling other internal code or SQL procedures. Once it has finished processing it returns the newly registered resource guid for IIS to send back to the agent in http.response.

 

So to wrap this article up, the NS is a very modern and complex assembly of code to perform all the required task to provide intuitive manageability ;).