Jump to content


lord_hydrax

Remote SUP for Internet Clients on SCCM 2012

Recommended Posts

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

Share this post


Link to post
Share on other sites


After some further reading it would seem a remote SUP will need WSUS with its own Database.... At least until SCCM 2012 SP1 where SUPs can share a database.

Share this post


Link to post
Share on other sites

Have you upgraded to SP1 yet? I'm deploying an internet facing SUP for the same reason. I guess my question is, is there any problem with having 2 databases as long as they are all speaking the same language? I just mean, if you push out a patch from the CM console, I expect whichever SUP to push it, and not worry about whether my client is inside or outside.

 

I'm pretty sure you need to make your internet site an "active" SUP, as that means clients will scan against that SUP. Passive being a site which clients don't scan against.

 

I saw this good link about moving a database once it's set up...

 

http://scug.be/sccm/2012/10/03/configmgr-2012-sp1-installing-multiple-software-update-points-per-single-primary-site-and-use-a-single-shared-wsus-database-on-your-sql-cluster/

 

But I'm not convinced that's the right path, if I just have to have a small SQL DB on a server, I'd rather do that until MS officially supports it.

Share this post


Link to post
Share on other sites

I certainly have upgraded to SP1 now, however I have not tried two SUPs sharing a single database.

 

To resolve this issue I ended up removing the SUP role and WSUS from my primary site server and installing it on my remote server then configuring that server to handle updates both internal and external.

 

This has been working fine, the only problem I had was when I upgraded to SCCM SP1 I had to install an additional hotfix on the server hosting WSUS, which was KB2734608 and KB2720211.

Share this post


Link to post
Share on other sites

Thanks, I'm about to do the SP1 upgrade today or tomorrow. Thanks for the heads up on those updates. It seems the documentation is a bit better these days (links below)

 

Did you have to open up 8530 and 8531 to the internet for internet based clients to be able to scan against the remote server? I'd rather just keep 80/443 open, but MS reccomends using a custom website (per best practices). Again, I'm still a bit confused whether I even need a remote SUP, i.e. if I have my Primary site inside, and I allow internet based clients on that, I assume I would have to open 8530/8531 to the internet; which is the whole point of my DMZ server. I'm just not sure how the CM client works, i.e. if I have the Remote site handling Internet clients fine, do I even need a SUP sitting out on the DMZ or would the CM client somehow pass the packages/data through to the inside SUP.

 

 

Planning for Software Updates in CM 2012

Use a Shared WSUS Database for Software Update Points

For Configuration Manager SP1 only:

When you install more than one software update point at a primary site, use the same WSUS database for each software update point in the same Active Directory forest. By sharing the same database you can significantly mitigate the client and network performance impact that can occur when clients switch to a new software update point. When a client switches to a new software update point that shares a database with the old software update point, a delta scan still occurs, but this scan is much smaller than it would be if the WSUS server had its own database.

This is good that they're now saying that you can use a shared DB, and I assume those KBs you mentioned are for the SUSDB sharing capability.

Share this post


Link to post
Share on other sites

We do use a custom website with ports 8530/8531 as per the best practices.

 

I believe in a situation where you use multiple SUPs and separate databases, any clients roaming externally and internally will take a long time to switch between SUPs, which could add some problems to update deployments. This is because by default a client will try a certain SUP several times with a long interval in between (around 30 minutes) before trying a different one.

 

Multiple SUPs sharing a single DB is meant to significantly reduce that time, which is noted in one of the articles you linked, however I am not sure exactly how that works.

 

A simple way though to look after internal and external clients is just to setup the Primary Site server as a SUP and have a reverse proxy in the DMZ forward internet clients to that server. This is similar to the setup we use, except we have a separate server setup with the SUP role and have that receive the requests from clients internally and externally. Clients seem to flick over between internal and external very quickly using this method.

Share this post


Link to post
Share on other sites

Thanks, I'm going to look more at that reverse proxy method, because the way it looks from the KBs, is that it takes 4x 30 minutes to fail over to the "other" SUP, and once it's moved, it will stay on that server indefinetly. So basically laptops which roam outside will stay on the DMZ based server as long as they can reach it from the inside as well... which I don't care for.

 

But I may try just installing the wsus 3.0 sp2 on the DMZ server today and point it at the shared DB (while the other one is up and running) and see if it plays nicely... I can't imagine it would, but stranger things have happened.

Share this post


Link to post
Share on other sites

So the install seemed to go fine, I'll let you know if I have any issues, but basically on the WSUS install on the 2nd site (DMZ) I just pointed it at the default instance of the server and it found the database, and I said "reuse existing database" then I did the KB updates, and I'm waiting for it to all synchronize now.

Share this post


Link to post
Share on other sites

Sorry for the long delay, but the shared DB worked great, SYNC works well, but I'm now struggling to get clients to swap over to the ICBM for SUS updates... I'll let you know when I get that working.

 

I did 2012 SP1 and just did CU1, and started having some random issues with ccr records, had to add some random SQL code to get it to work, MS had to help on that one.

Share this post


Link to post
Share on other sites

What a pain, sounds like boundaries, I keep finding new issues with mine.

 

Just the other day I found one boundary using an IP Subnet wasn't working properly because the Class C subnet was split in 4 parts and 75% of the clients didn't have a matching Network ID. Changing to an IP Address Range fixed that one up.

 

Haven't had a chance to apply CU1 yet, want to do it soon.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

@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

 

 

Share this post


Link to post
Share on other sites

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!

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

×
×
  • Create New...