Hi, I have a single SCCM 2012 SP1 CU1 primary site which has three SUP's. Two are in the same forest/domain and share the susdb database. I have a third SUP installed in an untrusted forest which is firewalled from our network and only the primary site server has firewall access on the required ports.

The setup above is all working fine. I am now trying to integrate three additional untrusted forests into the single primary site. These forests only have 5-10 clients at this stage so I don't want to setup additional SUP's in each of these forests.

So I have extended these forests schema for SCCM and are publishing into these forests so the MP's are created in the System Management container. I've also setup additional client installation accounts so that we can install the sccm client via client push. This is working and the clients can download packages using the network access account.

What isn't working is software updates and hence SCEP definition updates. Looking in the wuahandler.log I can see the client using the SUP in the other untrusted forest which is behind a firewall and hence inaccessible.

From my understanding this is fine, as the clients will fail over to an alternative SUP after multiple attempts - the other two SUPS are accessible. But after 5 days of monitoring the logs, these clients still haven't failed over to another SUP. Some of the clients are actually working and these are the ones that originally connected to one of the two SUPS that are on the same network.

Is anyone else experiencing this and is there a way to force the client to use an alternative SUP?

Thanks for your help.

Carl

I've not seen this, but that is an exotic configuration you have there. It looks like the Clients are still trying to contact the SUP they want to fail over too and the fail-over code is not taking not of its inaccessibility. I assume the error coming back is tricking it into thinking it should continue to try?

Is there any indication of failure during attempts to access this firewalled SUP?

Hi Rob, that's what it sounds like to me i.e. the return code is not one of the ones that currently cause the client to fail over to another SUP.

Looking in WUAHandler.log, I can see it attempt to perform the scan against the firewalled SUP and it then receives the error below. Is there a list of error codes from a scan failure that cause fail over or has this not been published as yet?

OnSearchComplete - Failed to end search job. Error = 0x80072ee2.

Scan failed with error = 0x80072ee2.

That's an HTTP error and means "The operation timed out" which is indicative of the traffic never making it to the SUP because of the firewall in this case.

So I guess this means that particular error code doesn't cause an sccm client to choose another SUP?

Any suggestions around this, or is this one for Microsoft support to look into?

Thanks

To update this thread, currently error code 0x80072ee2 doesn't cause the client to fail over to an alternative SUP. In order to work around this issue we are creating a host record for the firewalled SUP on the affected clients pointing at a valid (non-SCCM) IIS server.

The client then receives a different error code and after a number of retries finally fails over to a working SUP.

To update this thread, currently error code 0x80072ee2 doesn't cause the client to fail over to an alternative SUP. In order to work around this issue we are creating a host record for the firewalled SUP on the affected clients pointing at a valid (non-SCCM) IIS server.

The client then receives a different error code and after a number of retries finally fails over to a working SUP.

I have tried to use the hostfile to point to another IIS server. However, my client still receives the 0x80072ee2 response in WUAHandler.log, and doesn't fail over.

I've also tried stopping the WSUS_SYNC_MGR component using the Component Manager tool.

How can test the SUP failover on a client?