Netsh shows direct access.

 

I'll have the proxy guy set up an exception, but it all looks alright. I can
browse to the internal server with IE without hitting a proxy. WCM.log
doesn't show any real errors, it also doesn't look like permissions, because
the SUP is being installed and everybody seems to be talking to another.

 

I'll do some more testing.

 

From: [email protected] [mailto:[email protected]]
On Behalf Of Russ Rimmerman
Sent: Wednesday, 1 October 2014 12:59 PM
To: [email protected]
Subject: RE: [mssms] SUP in DMZ

 

Sounds like your proxy is intercepting the traffic from the dmz sup.  Can
you configure a direct route from dmz to intranet for the DMZ sup so it
doesn't hit your proxy?  Seems like that proxy/firewall device needs the
change.  You can telnet and connect, but when it detects http traffic it's
probably intercepting it.  If you're able to temporarily disable the proxy,
does it work?  Does netsh winhttp show proxy show a proxy being set on the
dmz sup? 

It's OK to use a separate db for the DMZ SUP.  

 

From: [email protected] <mailto:[email protected]>
[mailto:[email protected]] On Behalf Of David O'Brien
Sent: Tuesday, September 30, 2014 7:43 PM
To: [email protected] <mailto:[email protected]> 
Subject: RE: [mssms] SUP in DMZ

 

80, 8530/8531 are open from the untrusted domain to the internal domain, and
also the other way around for that matter. Telnet works.

 

I've attached the last successful wsyncmgr.log from the Primary Site. The
line that worries me a bit is this:

 

DB Server not detected for SUP UntrustedMP.untrusted.test.local from SCF
File. skipping.               SMS_WSUS_SYNC_MANAGER      1/10/2014 3:30:00
AM    10216 (0x27E8)

 

WCM.log shows the installation of that SUP, but doesn't group it with the
others. It also shows 

"Attempting connection to WSUS server: UntrustedMP.untrusted.test.local,
port: 8530, useSSL: False

System.Net.WebException: The request failed with HTTP status 407: Proxy
Authentication required.~~ at
Microsoft.UpdateServices.Administartion.AdminProxy.CreateUpdateServer(Object
[] args)~~ at
Microsoft.SystemsManagementServer.WSUS.WSUSServer.ConnectToWSUSServer(String
ServerName, Boolean UseSSL, Int32 PortNumber)

"

This, I suspect, is showing because that WSUS is trying to communicate with
Microsoft and doesn't have a proxy set. That's how I want it, it's supposed
to talk to the first SUP.

 

As I said, except for the server in the untrusted domain, all others share a
single WSUS SQL DB. The one in the untrusted domain has its own DB.

 

Thanks.

 

From: [email protected] <mailto:[email protected]>
[mailto:[email protected]] On Behalf Of Russ Rimmerman
Sent: Wednesday, 1 October 2014 8:17 AM
To: [email protected] <mailto:[email protected]> 
Subject: RE: [mssms] SUP in DMZ

 

Are the ports open from the DMZ sup to the internal sup?  Any errors in
wcm.log/wsyncmgr.log?  It sounds like the dmz sup just may not have been
able to finish configuring yet due to firewall ports or something, so it
hasn't gotten far enough to show that it's syncing with the internal sup.
You should have a port (80/443 or 8530/8531) open from DMZ sup to internal
SUP so they can sync.

 

From: [email protected] <mailto:[email protected]>
[mailto:[email protected]] On Behalf Of David O'Brien
Sent: Tuesday, September 30, 2014 4:38 PM
To: [email protected] <mailto:[email protected]> 
Subject: [mssms] SUP in DMZ

 

Hi all,

 

A quick sanity check for me please:

I've got an internal domain with a SUP (Software Update Point) that's
allowed to communicate with Microsoft (the internet for that matter) and
synchronise all the updates. I've got a second SUP in that internal domain
that's sharing a SQL DB with that first SUP. That second SUP syncs without
any issues from the first SUP.

I've also got an untrusted forest with third SUP. 

 

That third SUP, for whatever reason, thinks it doesn't need to sync from the
first SUP, but from Microsoft.

Because it's an untrusted forest I can't have it share the SQL DB with the
others, so I've told it to use its own SQL DB. That shouldn't however be the
reason why it goes out to Microsoft instead of to the first SUP.

 

Am I missing something here? To be clear, I'm talking about the SUP itself,
not clients.

 

Thanks for clearing that up for me :)

David

 

 

 

 



Reply via email to