Proxy Management Points: Part 2

This is a follow up to the previous posting on the topic of Management Points.

A number of you have asked some clarification questions which I’ll seek to answer here.

 

Firstly there were a number of questions around when a client initiates a particular request:

• Policy Assignment requests: These are executed as per the Software Distribution Client Agent polling period. By default this is every 60 mins. However what is not clearly known is that the client will actually issue 2 policy assignment requests every polling cycle.
  • One for all advertisements assigned to the machine.
  • One for all advertisements assigned to the user and the usergroups the user belongs to.

These requests may or may not happen at the same time and are 2 distinct requests.

• Policy Body Requests: These occur only when a new advertisement has been received via a policy assignment request. These specify the configuration of the advertisement; such as when it should run, how it should run etc.
• Location Requests: These only occur when a mandatory advertisement needs to execute or the user has chosen to run an optional advertisement. This request then seeks to identify what DPs have the source files necessary for this advertisement.

 

In summary, only the policy assignment requests are scheduled, the other two only occur “as needed” and are determined by the software distribution frequency.

 

Another question I get on a regular basis is “How much traffic is generated by SQL replication?”

 

This is a tough question to answer, since SQL replication is almost a product unto itself. It has a number of methods of configuration.

 

In the worse case we could assume that a snap shop replication occurs daily. This equates to approximately 50 bytes per resource at the Primary Site times the average number of advertisements per resource.

 

50 bytes X (# of resources X average number of active advertisements per resource)

 

However we recommend that transactional replication being used. This is where things get tricky since you can configure transactional replication to occur immediately or on a scheduled basis. This could be smaller or larger than snap shot replication since this will replicate the transactions that occur against the tables we replicate. These are then “replayed” against the replicated DB. At this point in time we still need to perform in-depth analysis on this process before we can provide guidance/sizing of this process.

 

This is where lab testing will be beneficial to simulate a production environment prior to deployment.

 

I think the next set of articles I write might focus on testing processes and guidelines for pre-production deployment of SMS 2003.

Comments

• Anonymous
  September 14, 2004
  I would very much like to hear your pre-production deployment ideas.
• Anonymous
  September 28, 2004
  Part 1 and 2...very helpful!! Thanks for taking the time to share.