Remote SUP for Internet Clients on SCCM 2012

[lord_hydrax]

Hello,

 

I have a SCCM 2012 Primary Site Server that is configured with WSUS and the SUP role and deploys Updates fine to users on the internal network.

 

I have a remote server setup as an MP/FSP/DP for supporting internet clients which is also working fine.

 

I am wondering what I need to do to allow my internet clients the ability to receive software updates from the remote server?

 

My best guess was probably installing the SUP role on the server and not setting it as an active SUP. I do this and SMS_WSUS_CONTROL_MANAGER on the remote server fails to install the component becaise it can't find WSUS. I could install WSUS on the server I suppose but I don't want to have to have a second database and I don't know how that would complicate things....

 

All I need this server to do is push out software updates and clients to send back compliance updates over the internet.

 

Appreciate any assistance!

 

Regards,

Andrew

[Ocelaris]

be careful with CU1, SP2 should be out soon (later this summer, early fall) according to MS techs I've talked to. We did CU1 because we were about ready to roll out, but I don't think it necessarily fixed anything, but definetly broke the client reconcilliation inbox CCR records were piling up.

 

Did you find a reason to not do the AD discovery for boundaries? I started making all sorts of boundaries, but then just said the heck with it and just did AD Discovery, and it seemed to do a pretty good job.

 

The client finds the ICBM fine, and can do software installs through bits etc... (443) but the SUP point doesn't roll over when client discovery does for some reason. If you look in c:\windows\windowsupdate.log it will tell you where it pulls from. and despite it finding a Management point on the internet, it doesn't switch over to the DMZ SUP.

[lord_hydrax]

Righteo, that's annoying. Hadn't heard anything about SP2 coming out, thats nice to know I wonder what new features it will bring.

 

When you say AD discovery, do you mean use AD sites as a boundary type? Two reasons I don't use that in our environment:

 

• Nightmares from SCCM 2007 where it would randomly not work at all for many clients to set the location or they get silly DPs set - Never got to the bottom of this issue
• We have clients that roam between different subnets around the world and using IP subnets against different DPs seems to be the most effective way for us.

It is a pain managing boundaries by using subnets, but we have limited bandwidth at many of our remote sites and we need to keep a tight grip on where clients pull data from.

[Ocelaris]

So had a marathon 4 hour call with Microsoft today, but got it working. It was probably some misunderstanding of SSL and certs and IIS/WSUS configuration that was the issue.

 

First issue, the secondary site didn't have SSL configured for WSUS, despite having the "ports" configured through the WSUS console and the CM console, it wasn't configured properly.

 

You can check HKLM\Software\Microsoft\Update Services\Server\Setup for "UsingSSL" if it is = 1 or 0... you do a "c:\program files\update services\wsusutil.exe configuressl" once you get it set up right.

 

So to configrue SSL check this thread, basically all the virtual directories have to be configured properly.

 

http://technet.microsoft.com/en-us/library/bb633246.aspx

 

Also, our internal MP couldn't talk SSL to the DMZ MP (WSUS over 8531) because we had a 3rd party Cert which had our External DMZ hostname, not our internal. i.e. domain.com vs. domain.firm. To test we launched the WSUS console on the INternal MP and tried to "connect to another server" entered the DMZ server port 8531 and it could not connect.

 

So we ditched the 3rd party cert and used my DP Web server certificate and included in the DNS field External.domain.com and Internal.company.firm domains. Basically our 3rd party cert would only take 1 Domain, but my internal Root CA is flexible, and that takes away our ability to use mobile devices and macs because our certificates are Windows AD distributed...

 

lots of logs, I can go into more detail while it's fresh if it interests. Also my "AD Discovery" made ip address ranges, works great! I do have the "AD Sites" but you can delete those, but the forest discovery finds "subnets" but really makes ip address range boundaries based on AD sites and services.

[Mike C]

@Ocelaris how did you handle name resolution in this case - SCCM would configure your local GPO with the internal name of the Internet serving SUP server. Did you find that when it was outside it started to use the external name or did you have to publish an internal servername?

I find that unlike the MP role there is no second name option for mobile SCCM clients using the SUP internally vs externally.

Finding information on the software update process is a bit of a nightmare

Thanks

 

 

[Ocelaris]

You know, it's been so long since I worked on this (3 jobs ago), my recollection was that we specified an internet facing name and published it on our external dns. It worked quite well, but that company has since upgraded sccm, so I don't even have that for a reference. Sorry!

[lord_hydrax]

You should be able to just set the Internet FQDN on the Site System role for the SUP to a Public DNS record. For that to work you need split brain DNS so on the internal DNS server you set the A record to the internal IP and on the external DNS server you set the A record to the public IP.

[Mike C]

You see I thought I'd be able to do that but I don't see a specific entry for the SUP that allows it to have an internet FQDN - which seemed incredibly strange given that basic functionality is in the MP role. We've always operated a split brain (I never supported the idea of .local domains!).

 

Thankyou for the feedback I appreciated I was reviving an old post - but it seemed you'd found the same things I had.