Hi all,
I've done a bit of reading of articles/resources and I'm not quite clear on communication requirements. I read that ICMP ping is required in addition to various TCP ports for client push installation. Our setup is a hub and spoke design with firewalls which we don't administer between premises (convenient how 'site' is a key word in SCCM grrr) :)

I thought we would be able to have Distribution Points/Management Points on remote premises and have the clients on those premises do all necessary communication with the local server in their same subnet in order to deploy the SCCM client and report status. Do I require ping etc through to the main server before it will use the local Distribution Point to deploy and report via the local Management Point?

We have a few clients manually installed at a couple of remote premises which are reporting but can't push the client and we have many clients at our central premises which have had client push installation and reported back successfully - presumably because they are in the same subnet with no firewalls between.

I also have a couple of manually installed clients at remote premises which are not reporting client activity but I'll look into that further once the main client push feature is working.

Thanks for any clarification, I'm building my SCCM knowledge!

R

• Edited by R-X Sunday, February 01, 2015 3:51 PM

You will find the complete list of ports required for ConfigMgr communication here

https://technet.microsoft.com/en-us/library/hh427328.aspx

You do NOT need Ping - although it is useful for troubleshooting.

I thought we would be able to have Distribution Points/Management Points on remote premises and have the clients on those premises do all necessary communication with the local server in their same subnet in order to deploy the SCCM client and report status.

This is incorrect. Client push is initiated by the site server and required communication initiated by the site server itself. Additionally, client selection of MPs is not location aware -- it can be hard-coded as of R2 CU3 but this is kludgey at best IMO.

Instead of "site" use the word "location".

Hi Gerry,
Thanks for your response and the resources on your blog.

I have looked at the link but I'm still not clear on instances (if any) where direct communication is required between the client and the primary site server.

Should clients be expected to be able to communicate only with their local distribution point/management point which is in the same subnet if they are firewalled from the primary site server as I have? How does SCCM know to have a remote distribution point do the communication to a client that is local to it without knowing the IP address? My servers have exceptions setup between them but the clients are fairly restricted to their own premises.

My boundaries are configured per AD Site but unless SCCM checks DNS for IP address would it be able to determine the AD Site to have the nearest DP/MP handle all the client interaction?

My query about ICMP was based on this link https://technet.microsoft.com/en-us/library/gg682180.aspx which says:
"In addition to the ports listed in the following table, client push installation also uses Internet Control Message Protocol (ICMP) echo request messages from the site server to the client computer to confirm whether the client computer is available on the network."

Edit: I see Jason has partly answered my question above - I spent too long typing this post :)

Thanks

• Edited by R-X Monday, February 02, 2015 1:58 AM

The ConfigMgr client agent never talk to the primary site. The client communicates with the site roles including the MP, DP, and SUP.

Addressing internal firewalls is unfortunately problematic at best.  As noted in my other reply about MP selection the primary reason to have multiple MPs is high availability and not remote locations or restricted traffic. Boundaries have nothing to do with MP or SUP selection. Clients do use boundaries for DP selection though. You could hard-code MP use as mentioned but that won't help for SUUP selection.

Client push is optional, there are multiple other ways to deploy the client agent if communication from the site server is problematic or restricted.

Ultimately, how many remote locations are you talking about and how many clients to be managed at each?

Hi Jason,
There are different amounts but lets say 15-20 each at 6 remote locations and 60+ centrally. It sounds like I need to reconsider just going with a central MP and ensuring ports are open to that one from all clients.

I believe our inter-server comms are OK but for remote clients to main server I will need to ensure the following ports are open according to those 2 articles + other sources:

80, 443

File/Print
TCP 135, 139, 445
UDP 137, 138

WMI dynamically-assigned RPC high ports

and 10123 (optional) ...oh and ICMP?

Or are the file sharing and WMI ports not required if (hopefully) the data for client installation gets sent from the nearest DP with the content? I would like to get the clients installed at least initially with client push before introducing other possible methods later.

Thanks, R

• Edited by R-X Tuesday, February 03, 2015 10:47 PM Removed kerberos ports from list

First, don't confuse the ports used for client push with those used client operations. File/print and WMI/RPC High ports are only necessary for the initial portion of client push. This is why I pointed out that client push is not the only method of deploying the client.

Normal client operation requires, by default 80 or 433, 8530 or 8531, and 10123 (although strictly speaking 10123 isn't required either as the client notification component will fall back to 80 or 433 but this will increases load on the MP however given the number you're talking about this is negligible). ICMP is never used for client operation -- I don't know for sure whether it's used during client push or not, I suspect not but don't know 100% on that but once again, there's no reason you need to use client push.

Also, for normal client operation, all traffic is client initiated so depending upon your firewalls, you should only need to open these ports up in one direction.

Thanks guys. I would say everything in this thread is the answer. I didn't realise clients wouldn't just speak to their nearest (AD site) Management Point as we had been trying.

Now that the Primary site server in our setup is also the only MP and the required ports as summarised have been opened to it the clients have installed and reported from various remote locations.