locked
MP, DP, SUP in Untrusted DMZ for IBCM / Internal WSUS, SUP RRS feed

  • Question

  • Hi,

    So, I am looking to migrate my current SCCM 2007 SP2 Infrastructure to a ConfigMgr 2012 R2 enviornment. With this new enviornment there is a need for managing clients connecting from the internet. In the new enviornment there will be an internal forrest which will host my Primary and a few Secondaries as well as a separate server with the WSUS, SUP, FSP roles. I will not have the WSUS, SUP roles on the same box as the Primary. In addition to this forrest, there is an untrusted DMZ which will have a site system with the following roles, DP, MP, SUP. For IBCM - I understand Certificates play a huge role. PKI is currently up and running in the enviornment.

    1) I am a bit confused as to what is needed for the SUP in the Untrusted DMZ in order for it to make updates available to internet based clients. Primarily in the area of whether or not I can share the WSUS DB which will be hosted on a separate server from the Primary Site internally? Is this possible? or Do I have to Install WSUS on the SUP in the untrusted and create a separate DB?

    I realize this may be answered in other posts but I have been researching this for quite sometime and feel unclear as to how to accomplish this. Your guidance is appreciated.

    Thanks,

    Gabe

    Friday, September 5, 2014 2:52 PM

Answers

  • Yep, it's pretty much just opening the proper ports although keep in mind that the site systems must be domain joined so if you don't have a domain in your DMZ, you will also have to account for this which may involve opening ports required for domain members to communicate to your domain.

    The ports required for communication between the site server and site systems are defined at http://technet.microsoft.com/en-us/library/hh427328.aspx

    This traffic is normally not routed through a reverse proxy (although it could be).

    That same page linked above also lists traffic between the client and the internet facing roles. This traffic is however sometimes routed via a reverse proxy -- that depends upon your organization's practices though.

    Note that none of this takes PKI communication into account though. Really this is just the retrieval of the CRL from a CDP or using OCSP which can be done in a variety of ways assuming that you leave CRL checking enabled. PKI design itself is a task you should not take lightly however -- get a PKI smart person involved ASAP if you don't have that knowledge and experience yourself.


    Jason | http://blog.configmgrftw.com | @jasonsandys

    • Marked as answer by Gabe Alicea Friday, September 12, 2014 5:19 PM
    Friday, September 12, 2014 4:00 PM

All replies

  • "I will not have the WSUS, SUP roles on the same box as the Primary."

    Why not? WSUS and the SUP are very low over-head roles in general. If you want to split roles off for perf reasons, the MP and DP should be split off before WSUS and the SUP.

    A SUP must always have a local install of WSUS. Sharing the DB for WSUS is possible but probably more trouble than its worth given the presence of an intervening firewall between the two WSUS instances. It *may* also not be supported -- it is totally supported for internal WSUS instances used for SUPS, but I'm not positive if its something they've designed for or tested for the IBCM scenario. What's the reason you'd like to do this though?

    Also note that all site systems must be members of an AD domain -- it's not clear from the above description whether this is the case of not though.


    Jason | http://blog.configmgrftw.com | @jasonsandys

    Friday, September 5, 2014 3:13 PM
  • Thanks for your reply Jason.

    So, the design was already diagrammed and approved prior to my arrival here. I have seen the Advanced Infrastructure videos as noted by Brian Mason and Kent Agerlund and wanted to implement simliar functionality and offload the client facing roles from the Primary. But, It would seem I am unable to make changes to what was approved at this stage. With that said, the design called for the WSUS / SUP to be on a separate box from that of the Primary with the Primary hosting the MP, DP roles (smh). The DmZ based Site System Roles will be part of an AD Domain as there is a DC in the DmZ and a domain defined. The same is true for the internal site systems. There is no trust between the two forrests.

    A design goal for us is to be able to still provide clients with content (packages, updates) even if they are at home on the internet and not using VPN. However, those same clients will likely come into the office at any point in time. So, we just want to be able to make that content available no matter where that client is (Internet vs. Intranet).

    So, with that mouth full of stuff, I guess, my concern is how to accomplish this with specific regard to the SUS / WSUS in the DmZ. I have read some threads that suggest a ports are the only concern and others where a TmG (reverse proxy) is used... but all seem to circle back and state that so long as I am not doing any user based activity then I do not need a trust especially since WSUS / SUP does not seem to require any level of authentication so kerberos / trust relationship isn't necessary...

    Any further thoughts on this? I appreciate your help.


    Gabe

    Friday, September 5, 2014 4:58 PM
  • First for the design, a bad design is a bad design whether its "approved" or not. Better to stop a bad design before it gets implemented than to actually implement a bad design.

    As for the SUP and WSUS placement, I'm not sure what you are confused about. The ports required for communication are clearly defined: http://technet.microsoft.com/en-us/library/hh427328.aspx

    TMG only comes into play if you would like to reverse proxy client traffic to the site systems (which may be in the DMZ or on your internal network) instead of allowing direct contact by the clients to the site systems (that are in the DMZ). But don't confuse client traffic with site system traffic. They are two different things. Which are you concerned about?

    Also, the discussion of traffic is for more than just WSUS and the SUP as it also applies to other client facing site system roles like the MP and DP so why are you only focusing on the SUP and WSUS?


    Jason | http://blog.configmgrftw.com | @jasonsandys

    Tuesday, September 9, 2014 3:21 PM
  • Hi Jason - I am not in disagreement with you... Although I am no where as seasoned as yourself, I am not comfortable with the design and can see how it can be better, but politics are such that I cannot do anything about it at this time. So the design discussion is essentially moot at this point. 

    So, All I was looking for was to understand how the Site System in the non-trusted DmZ with the following roles (DP, MP, SUP) would work in relationship to the internal Site Server / Systems. If this is just a matter of opening ports in the FW then perhaps it is simpler than I am making it out to be. I have never had to work with Site Systems in a DmZ before and much less worry about IBCM so I was just looking to understand a more Senior ConfigMgr persons thoughts on the matter.

    At any rate, thank you for your input.


    Gabe | @ConfigMgrGeek

    Friday, September 12, 2014 3:17 PM
  • Yep, it's pretty much just opening the proper ports although keep in mind that the site systems must be domain joined so if you don't have a domain in your DMZ, you will also have to account for this which may involve opening ports required for domain members to communicate to your domain.

    The ports required for communication between the site server and site systems are defined at http://technet.microsoft.com/en-us/library/hh427328.aspx

    This traffic is normally not routed through a reverse proxy (although it could be).

    That same page linked above also lists traffic between the client and the internet facing roles. This traffic is however sometimes routed via a reverse proxy -- that depends upon your organization's practices though.

    Note that none of this takes PKI communication into account though. Really this is just the retrieval of the CRL from a CDP or using OCSP which can be done in a variety of ways assuming that you leave CRL checking enabled. PKI design itself is a task you should not take lightly however -- get a PKI smart person involved ASAP if you don't have that knowledge and experience yourself.


    Jason | http://blog.configmgrftw.com | @jasonsandys

    • Marked as answer by Gabe Alicea Friday, September 12, 2014 5:19 PM
    Friday, September 12, 2014 4:00 PM
  • Thanks. PKI was put in a bit ago (not by me...) I will sit and discuss with the folks that own it. Thanks for your time.

    Gabe | @ConfigMgrGeek

    Friday, September 12, 2014 5:19 PM