How many client are geeting update under an additional update manager?
This thread was automatically locked due to age.
How many client are geeting update under an additional update manager?
It's more about the ability of the SUM server to perform as a file server/web server to meet the demands of the number of clients. For example, you could put a SUM on pretty modest hardware if it was writing an update location to a dedicated filer. At this point the SUM is just there to download files, push files out and report status.
I believe HTTP might be better at supporting a large number of clients rather than UNC if it's all on box and you need to squeeze more out of it so that could be an option.
The only other consideration is if you want the SUM server to act as a message relay, so all the clients using it as an update location also send their management traffic to the management server via that machine. This removes all the direct connections to the management/SEC server at least for managment. This approach can also be a design decision based on the topology and for future growth depending on how many clients you are wanting to support.
For example, I don't think I would want (management server OS depending) more than 5000 clients talking to a management server that was providing both updating and management to those clients and maybe also with a local SQL instance. Offloading SQL and updating would allow more resources to service management for example.
How many computers do you have in mind and how many sites? Maybe a rough number per site would be good, with a view to consider then next 5 years.
E.g.
Total 15K
Site 1 - 3000 -> 4000
Site 2 - 2000 -> 2500
Site 3 - 1000 -> 1500
etc..
Then there are the roaming/home users that don't quite fit into an office environment. How will they get management, via VPN?
Are any inter site networking limitations?
How many SEC servers in the environment? I assume just one?
Regards,
Jak
It's more about the ability of the SUM server to perform as a file server/web server to meet the demands of the number of clients. For example, you could put a SUM on pretty modest hardware if it was writing an update location to a dedicated filer. At this point the SUM is just there to download files, push files out and report status.
I believe HTTP might be better at supporting a large number of clients rather than UNC if it's all on box and you need to squeeze more out of it so that could be an option.
The only other consideration is if you want the SUM server to act as a message relay, so all the clients using it as an update location also send their management traffic to the management server via that machine. This removes all the direct connections to the management/SEC server at least for managment. This approach can also be a design decision based on the topology and for future growth depending on how many clients you are wanting to support.
For example, I don't think I would want (management server OS depending) more than 5000 clients talking to a management server that was providing both updating and management to those clients and maybe also with a local SQL instance. Offloading SQL and updating would allow more resources to service management for example.
How many computers do you have in mind and how many sites? Maybe a rough number per site would be good, with a view to consider then next 5 years.
E.g.
Total 15K
Site 1 - 3000 -> 4000
Site 2 - 2000 -> 2500
Site 3 - 1000 -> 1500
etc..
Then there are the roaming/home users that don't quite fit into an office environment. How will they get management, via VPN?
Are any inter site networking limitations?
How many SEC servers in the environment? I assume just one?
Regards,
Jak
