Microsoft

System Center Configuration Manager Feedback

Suggestion box powered by UserVoice

How can we improve Configuration Manager?

Eliminate need for clients at Secondary Sites to ever contact Primary Site's MP

Clients can use the Proxy MP at Secondary Sites for most communication. However some communications must fall back to the primary site's MP. For example - client registration.

102 votes
Vote
Sign in
(thinking…)
Sign in with: Facebook Google
Signed in as (Sign out)
You have left! (?) (thinking…)
Admindjam (Product Director, or Executive, System Center Configuration Manager) shared this idea  ·   ·  Flag idea as inappropriate…  ·  Admin →

5 comments

Sign in
(thinking…)
Sign in with: Facebook Google
Signed in as (Sign out)
Submitting...
An error occurred while saving the comment
  • Chris commented  ·   ·  Flag as inappropriate

    We're also facing an increased demand for secured/segmented environments. There is a need for an isolated Secondary that does not require clients to register with a Primary MP. We are forced to have a separate CM environment for a relatively small number of clients.

    Any update available from product team on this feedback?

    Thanks!

  • NC commented  ·   ·  Flag as inappropriate

    “Most” doesn’t cut it. We are working in a highly secure and segmented network. Clients can’t talk to the primaries, ever. We need them to register without traveling across the WAN to the primary.

  • I wanted to note that if your goal is true network isolation, you can use the AllowedMPs registry key to largely work around the problems with this configuration without needing a secondary site.

    See https://blogs.technet.microsoft.com/jchalfant/management-point-affinity-added-in-configmgr-2012-r2-cu3/

    This is more of a blunt instrument than the MP affinity added in 2012 SP2 but it's also highly effective for restricted networks to ensure that the clients only use a specific list of MPs.

  • Kevin commented  ·   ·  Flag as inappropriate

    Allow Secondary Sites to accept client registration requests and forward them to the Primary Site.

    The goal is to allow a secondary site to really provide Network Isolation. Many customer environment have complex networks in which they can not/will not open firewall rules to allow all systems to communicate back to remote Primary Sites. In these cases, allowing the customers to make 1:1 firewall rules between the primary and secondary sites is usually acceptable.

    Clients could them completely communicate only with the secondary site and not have to reach back to the primary site.

  • Robert Marshall - EM MVP commented  ·   ·  Flag as inappropriate

    Currently if a Primary Site server is unavailable, but SQL is remote, most front-line services continue to function. The MP, DP and SUP function well enough to complete a Task Sequence, but, the Client Registration will fail due to the Primary being offline.

    Please move the Client Registration process away from the Primary, and position it so that the MP can take care of it without the need for any in-flight data to pass through the Site servers inboxes to succeed.

    This will allow for OSD to continue operating using front-line services, while parts of the back-end (Primary Site server) are down\under maintenance.

    Obviously if SQL is local to the Primary, I wouldn't expect things to continue to function, but when designing for a more robust environment, the option to offload SQL so that Client Registration and MP (RMP would mitigate against this in part) activity can continue to function, even if we lose the primary, would be a boon.

Feedback and Knowledge Base