Proxy Management Point: Benefits and Otherwise.

  • Article

One of the most confusing concepts in SMS 2003 is the use and application of a Proxy MP (PMP). I’ll try to explain firstly what the PMP does and doesn’t do, and secondly address when you could consider implementing a PMP.

Firstly the key benefit of deploying a PMP (on a secondary site) is in the network traffic and network scheduling capabilities that the secondary site provides when sending inventory data files up the hierarchy (when I refer to inventory I really mean DDRs, software inventory, hardware inventory, status messages and software metering files).

Without a PMP at a location the advanced client will send all its inventory data over the WAN (be it, somewhat compressed, but not nearly as compressed as the same data being transferred by a secondary site. The client has a compression configuration optimized for speed; the secondary site has one optimized for file size)to a MP over the WAN, based on the client inventory schedule.

With a PMP at the location, the client will send inventory files. Once received the PMP will convert them from XML to native SMS file formats and “forward” them to the secondary site. The secondary site will then compress these files and forward them, via the sender (and using the sender scheduling and bandwidth controls) to its parent primary site server. The secondary site will also send these files in batches (saving even more space) on a per file type basis, if there are multiple inventory files of the same type.

For locations with small numbers of clients the difference between having a PMP and not is very small (particularly because the secondary site sender header adds additional network traffic, and could be even costlier than not having a secondary site/PMP). However as the number of clients at that location grows, so too does the network savings. To get an idea of whether or not your locations will benefit from a PMP/secondary site use the SMS 2003 Capacity Planner to illustrate the various site server options you have.

The PMP does also offers some network traffic and potential fault tolerance benefits related to software distribution, this however has been misrepresented as the primary reason for deploying a PMP.

As a bit of a background the Advanced Client (AC) issues 3 software distribution requests:

  1. Policy Request for a machine or user: This is check to see if there are any advertisements for the machine or user/usergroup. These occur by default every 60 mins (admin configurable). Policy requests are ~10-12Kb per client per hour. These are unique for each machine or user/usergroup. Therefore cannot be cached locally by the PMP.
  2. Policy Body: This is the details of a particular advertisement and as such is unique only to the advertisement and therefore can be cached.
  3. Location Request: This provides the location of the available DPs with the advertisement package. This is based on location (IP subnet etc) and thus is kinda unique to the client machine. Location requests are ~6-8kb per client per advertisement executed. These are not cached.

As you can see the only software distribution data cached on the PMP is the policy body, these are typically <50Kb. The other 2 transactions are smaller, however they are per client. Therefore as the client count increases, so to does the network traffic associated with software distribution functions.

The only way to reduce this software distribution traffic from traveling over the WAN (since the PMP makes these requests on behalf of the client to its Primary Site SQL Data) is to deploy a replicated SQL database at the PMP/secondary location and then replicate the SMS database tables & stored procedures needed. These can be found by executing:

Select * from replicatedobjects where sitesystemtype = ‘MP’

With this design the PMP will not travel across the WAN, but will instead make queries against the local database replica. Note this does require additional configuration in SQL Enterprise manager AND in the SMS Admin UI to “point” the PMP at the replicated SQL DB. An will result in more SQL network traffic, as the replication of transactions etc occurs (SQL replication can be configured in a number of ways, which affect the nature and volume of replicated data).

Depending on the number of clients at the primary site, this SQL replication may generate more or less traffic that having the PMP use the primary sites’ local DB. I’ll discuss SQL replication and its implications in a future article.

Hopefully this illustrates the reasons for PMP placement and clears up some of the misunderstanding surrounding PMP usage/benefits.

When to consider deploying a PMP

Basically this comes down to inventory file volume. When the volume of inventory generated by the ACs at the location exceeds the overhead of deploying a secondary site (and PMP) then a secondary site/PMP should be deployed. I don’t have a rule of thumb as to when this might be, since it depends on number of clients, WAN link speeds, inventory configurations etc.

The best advice I can give you is to download the SMS2003 capacity planner and enter in your environments’ appropriate data and review the various site server options (including appropriate traffic volumes). This analysis will illustrate the expected WAN utilization for a location if you were to place; no SMS server, a DP, a Secondary site, a Secondary site/PMP, a Secondary site/PMP/Replicated SQL or a Primary site.