Limiting Automatic Groups to only 500 members on the basis of subnets

Hi All,

We have a requirement to patch workstations in phases and have been asked to create groups based on subnets across locations however limit the group to only 500 members. Is this possible?

Does it have to be divided by Subnets, or was that just a possible way to divide up the computers?

How many clients total?

What is the need to patch in batches? Is this due to server load? It might be there is an alternative that would help.


In general it is a very bad idea to patch in batches divided by Subnet. This would overwhelm the relay that the clients talk to from that subnet. Basically you would hit a small set of relays hard, then move on and hit another small set of relays hard. It is much better to hit all relays evenly, but with less impact on each.

If you instead divided the computers into batches randomly, then you would not overwhelm the network and the relays.


There isn’t a great way to have an automatic group contain exactly 500 endpoints.

You could take the number of endpoints, divide it by 500 and make that many groups. The relevance to define the groups would be something like:

(computer id) mod (NumOfGroups) = GroupNum

This would not divide the clients into groups by subnet, but it would divide them into groups semi-randomly.

There could be other options rather than just computer id to make it more random.

Also, I’m not sure what the correct relevence is for computer id of client

Hi JG

Thanks for getting back! Will give you some more information, the requirement is to roll-out the patches in phases and for the first 2 phase the number gotta be 500. As i understand, this is to minimize the impact if any from the patches to a smaller group of people spread across the globe. Even if the number is 500, we would have to cover all the sites/ regions, even if this means only a handful of people from each site. Thus came the idea of subnets. If you have another recommendation I am happy to hear it out…

B/r,
Subh

I did spell out an idea of random assignment above.

Also, you can have patches roll out over time rather than all at once. So even if you have 500 endpoints in a group, you could have it roll out to that group over a 4 hour period, or a 24 hour period, or a 72 hour period.

Also, for your first phase of patching, I would recommend first doing a set of machines closest to the group doing the patching so that they can diagnose issues in person if needed. Then it might be a good idea to have a task that people can run through either self service, or console operators could run to designate certain machines as a part of a QA set. These would be the machines that would get patched first in every site every time.

Only after those different groups have been patched would the random assignment start to roll the patches out more broadly.


Also, when you mean pick members of the automatic group based upon subnets, do you mean to pick 500 clients from all different subnets? or as many different subnets as possible?

@IEMNoob, You need to understand that as far as each client is concerned, it is the only client. Each client knows nothing about any other clients. So when a client joins a Automatic group, it doesn’t know how many are already in the group. The clients would need to “know” something about themselves that they can use to join the Test Group.

Where I work, we handle this process by designating “test” systems that represent, as best we can, our production systems. This “designation” is done manually, we built it into our naming convention.

James’ suggestion to keep the initial testing “close to hand” is a good one. You want to be able to quickly, and accurately diagnose any problems the patches create.

With this said, I can think of a few ways to approach your situation.

  • Base membership on IP address within the subnet?
  • you don’t mention if you use Active Directory, but AD groups could be used.
  • A text file listing Computer Names and Groups could be added to a Custom Site. An Analysis could be used to let each system periodically examine the file for it’s computer name and set a Client Setting based on this. Then the Automatic group could target based on the Setting.

Hi James,

Thanks and this is what we have been doing, my idea was to integrate little more intelligence in the way patches are delivered and cover a fairly large group of people working across all divisions. Bandwidth isn’t really one of the biggest showstoppers for us.

And as far as your question is concerned, I would want to pick these 500 clients from all different subnets.

1 Like

Now that I’m sure I understand what you are getting at, we are looking at refining our patching process along similar lines as what you are talking about throughout this post.

Our process starts by testing the patching across our own test machines that are disposable. Then to some of our groups actual machines. Then it rolls out to some of the groups we have a good relationship near us.

The next step is to roll it out to machines opted into a QA group by the various departments. These machines are tagged as being part of the QA set by either the user or the IT staff or a Console operator.

Then the next part is tricky. What if there aren’t enough QA machines across all of the groups? This is where we want to be able to start picking machines in a semi-random way to basically opt them into a sort of an early post-QA set. One idea to help with this selection process is to give the IT Departments a way to tag machines in such a way that they should be the last to get patched. These would be the machines that are important in some way and should be the last to help prevent more significant down time.

But then, we still have the problem of rolling out patches in a progressive way to the rather large set of machines that are in between the QA group and the “last to patch” group.

This is really where your question fits in.

We don’t have a solution implemented yet, but something we are exploring.

I think that random assignment into a 2nd tier after the QA set is the best option with the least amount of continuous work on our side. I think anything other than random assignment will get messy and be flawed, even if it is perfect when implemented, it will get worse over time. Even if you decide to do something other than random assignment to get your next 1000 clients patched after a QA set, then you should do so after that.

There might be some sort of algorithm to help implement the creation of an automatic group spanning some machines across subnets, but I’m not sure at the moment what the best option would be.

Hi James,

Went ahead with the option of random assignment however we tried covering all user subnets, the output was simple arithmetic 10% of random users from any subnet.So far the results have been good, we were even able to control the impact of an automatic reboot created from an Adobe Shockwave Player Update. Thanks for all your inputs!

Cheers

2 Likes