Jump to content


  • 0
lord_hydrax

Remote SUP for Internet Clients on SCCM 2012

Question

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

Recommended Posts

  • 0

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

  • 0

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

  • 0

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

  • 0

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

  • 0

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

  • 0

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

  • 0

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

  • 0

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

Join the conversation

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

Guest
Answer this question...

×   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...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.