Hi,

We're migrating SCCM 2007 to SCCM 2012 R2.

In SCCM 2007, the proxy server is configured with user authentication, and this works.

In SCCM 2012 R2, the Software Update Point is installed locally and connected with a local WSUS 4.0 (Server 2012)

We use a proxy with user authentication for Update Deployment. (This user is the same as configured in SCCM 2007.)

The Proxy Server is Blue Coat SG.

The proxy account is used for:

The Synchronization works, but Automatic Deployment Rule (ADR) doesn't work.

When an Automatic Deployment Rule is started, it tries to authenticate 3 times.

The Patchdownloader.log shows:

Trying to connect to the root\SMS namespace on the <servername> machine.        Software Updates Patch Downloader        11/8/2013 12:19:06        3608 (0x0E18)

Connected to \\<servername>\root\SMS        Software Updates Patch Downloader        11/8/2013 12:19:06        3608 (0x0E18)

Trying to connect to the \\<servername.domain>\root\sms\site_ECM namespace on the <servername.domain> machine.        Software Updates Patch Downloader        11/8/2013 12:19:06        3608 (0x0E18)

Connected to \\<servername.domain>\root\sms\site_ECM        Software Updates Patch Downloader        11/8/2013 12:19:06        3608 (0x0E18)

Download destination = \\<servername.domain>\dp_wks_ms_updates$\3208bb5e-bcd9-4389-a0c9-02ef33ccb998.1\XPSEPSC-x86-en-US.exe .        Software Updates Patch Downloader        11/8/2013 12:19:07        3608 (0x0E18)

Contentsource = http://wsus.ds.www.download.windowsupdate.com/msdownload/update/v3-19990518/cabpool/xpsepsc-x86-en-us_7ae70ca1330a099080c6c41c4d5b7f19b30dc0cd.exe .        Software Updates Patch Downloader        11/8/2013 12:19:07        3608 (0x0E18)

Downloading content for ContentID = 16819067,  FileName = XPSEPSC-x86-en-US.exe.        Software Updates Patch Downloader        11/8/2013 12:19:07        3608 (0x0E18)

Try username <domain\ProxyAccount>        Software Updates Patch Downloader        11/8/2013 12:19:07        8364 (0x20AC)

Proxy enabled proxy server <proxyserver>:8080        Software Updates Patch Downloader        11/8/2013 12:19:07        8364 (0x20AC)

HttpSendRequest failed HTTP_STATUS_PROXY_AUTH_REQ        Software Updates Patch Downloader        11/8/2013 12:19:07        8364 (0x20AC)

Download http://wsus.ds.www.download.windowsupdate.com/msdownload/update/v3-19990518/cabpool/xpsepsc-x86-en-us_7ae70ca1330a099080c6c41c4d5b7f19b30dc0cd.exe to C:\Windows\TEMP\CAB6FD2.tmp returns 407        Software Updates Patch Downloader        11/8/2013 12:19:07        8364 (0x20AC)

ERROR: DownloadContentFiles() failed with hr=0x80070197        Software Updates Patch Downloader        11/8/2013 12:19:07        3608 (0x0E18)

Then the proxy user account is locked:

Trying to connect to the root\SMS namespace on the <servername> machine.        Software Updates Patch Downloader        11/8/2013 12:20:11        3608 (0x0E18)

Connected to \\ <servername>\root\SMS        Software Updates Patch Downloader        11/8/2013 12:20:11        3608 (0x0E18)

Trying to connect to the \\<servername.domain>\root\sms\site_ECM namespace on the <servername.domain> machine.        Software Updates Patch Downloader        11/8/2013 12:20:11        3608 (0x0E18)

Connected to \\<servername.domain>\root\sms\site_ECM        Software Updates Patch Downloader        11/8/2013 12:20:11        3608 (0x0E18)

Download destination = \\<servername.domain>\dp_wks_ms_updates$\e0a54221-3ff2-4129-b7cf-89bf5cd1f726.1\Windows-KB943729-x86-ENU.exe .        Software Updates Patch Downloader        11/8/2013 12:20:12        3608 (0x0E18)

Contentsource = http://wsus.ds.download.windowsupdate.com/msdownload/update/software/updt/2009/10/windows-kb943729-x86-enu_e174c41ce3dcbd5c8922d6d1c39df1be425a70e0.exe .        Software Updates Patch Downloader        11/8/2013 12:20:12        3608 (0x0E18)

Downloading content for ContentID = 16824262,  FileName = Windows-KB943729-x86-ENU.exe.        Software Updates Patch Downloader        11/8/2013 12:20:12        3608 (0x0E18)

Try username <domain\ProxyAccount>        Software Updates Patch Downloader        11/8/2013 12:20:12        12480 (0x30C0)

Proxy enabled proxy server <proxyserver>:8080        Software Updates Patch Downloader        11/8/2013 12:20:12        12480 (0x30C0)

HttpSendRequest failed HTTP_STATUS_FORBIDDEN or HTTP_STATUS_DENIED        Software Updates Patch Downloader        11/8/2013 12:20:12        12480 (0x30C0)

Download http://wsus.ds.download.windowsupdate.com/msdownload/update/software/updt/2009/10/windows-kb943729-x86-enu_e174c41ce3dcbd5c8922d6d1c39df1be425a70e0.exe to C:\Windows\TEMP\CAB6E4B.tmp returns 403        Software Updates Patch Downloader        11/8/2013 12:20:12        12480 (0x30C0)

ERROR: DownloadContentFiles() failed with hr=0x80070193        Software Updates Patch Downloader        11/8/2013 12:20:12        3608 (0x0E18)

The RuleEngine.log shows:

Failed to download the update from internet. Error = 403 SMS_RULE_ENGINE 11/8/2013 16:18:25 3608 (0x0E18)

Failed to download ContentID 16824467 for UpdateID 16819978. Error code = 403 SMS_RULE_ENGINE 11/8/2013 16:18:25 3608 (0x0E18)

It seems that the ADR uses a wrong password when authenticating with the proxy, but this same user works when synchronizing with WSUS.

We performed the following actions with no result:

• run the ADR manually and automatic,
• reinstalled WSUS and SUP,
• changed proxy user account.

Regards,
Matthias

• Edited by Matthias Waltniel Friday, November 08, 2013 3:46 PM

Hi Matthias, same issue here. Did you find a solution or just put in a workaround for anonymous access through the proxy?

Hi Jakster, we still have this issue. Our temporary workarround is not using a proxy.

In the ruleeninge.log we get a 407 error. Of course account gets locked out because of failures.

4771,AUDIT FAILURE,Microsoft-Windows-Security-Auditing,Fri Nov 15 13:56:51 2013,No User,Kerberos pre-authentication failed.    Account Information:   Security ID:  ...  Account Name:  .... Service Information:   Service Name:  ...    Network Information:   Client Address:  ::ffff:...   Client Port:  63798    Additional Information:   Ticket Options:  0x40810010   Failure Code:  0x18   Pre-Authentication Type: 2  

Also, it is weird, that if you want to verify your proxy account against a proxy under Security/Accounts in the account property, no matter what pw you type in for the account, it gives a successful verification.

I think this is a kind of a bug like where the backup may truncate the backup UNC path?? Of course I cannot check what pw is passed...

Hi, I can confirm that I am also having this issue.

My situation is a little different as SCCM 2012 R2 is running on Server 2012 R2 and WSUS is running on a separate Server 2008 R2. It first I thought my issues was related to being two different WSUS/server version, but that may not be the case as you all have the same error messages.

Is anyone closer to funding a solution?

When you manuall sync with MS updates or download manually via the console the logged on user credentials are used when connecting to the MS site.

For ADR the Server System account requires access to connect to the MS download Site. By default, the Local System account for the server on which an automatic deployment rule was created is used to connect to the Internet and download software updates when the automatic deployment rules run.

Does the Server Machine account have access to download from the MS Site?

Tried to remove and re-add account, also tried to change to a pw as simple as policy allowed. - No go.

Was playing around with the verification option in the console

1. in the verification window, entered wrong pw - verification says success (as stated earlier) - wth??

2. changed URL to a blocked one - message appears that URL is blocked

3. now changing back to allowed URL and wrong pw - auth failed

4. changing to good pw - auth ok

5. changing back to bad pw again - auth ok --- ?????????

I was trying to catch the pw sent to the DC with wireshark (in a lab, enabling WSUS pw sent trough nonSSL ) but no luck (not being a hacker it's no wonder...)

I'm wondering if you guys who have the problem too, did you upgrade from any previous version, or was it a direct R2 install?

We did upgrade from SP1 CU2...

Hi cgsilver,

In our case, it's a SCCM 2007 to 2012 migration, not an upgrade.

When we download the updates manually from the console, it works.

This problem only occurs if an ADR is used.

The system account doesn't have access to the internet, the ADR is configured the use the Proxy account.

The logs show that the ADR tries to use the proxy account, which is not working - wrong password.

Run  "netsh winhttp show proxy" to check the poxy settings. 

Ours was an Upgrade from SCCM 2012 SP1 to SCCM 2012 R2. I also checked and manual sync and download of updates is ok, it is only when an ADR is used. I have enabled our SCCM and WSUS servers to be able to connect to the internet without auth and this hasn't helped.

Currently, the command shows:

Current WinHTTP proxy settings:

    Direct access (no proxy server).

We've been testing with:

• upddwnldcfg.exe /s:<proxyserver>:<port> /u:<user> /allusers
• psexec -i -s iexplore.exe, set Internet Explorer proxy manually

All with same result, proxy user getting locked when ADR runs.

(These settings have been removed after the test.)

Currently, the command shows:

Current WinHTTP proxy settings:

    Direct access (no proxy server).

We've been testing with:

• upddwnldcfg.exe /s:<proxyserver>:<port> /u:<user> /allusers
• psexec -i -s iexplore.exe, set Internet Explorer proxy manually

All with same result, proxy user getting locked when ADR runs.

(These settings have been removed after the test.)

I think dekac99 would suggest netsh winhttp set proxy or import proxy.
then turn off proxy use on the role SUP (this way not SCCM will send auth but all winhttp will use proxy)

the problems with that for me are:

- if MS implemented role-based proxy usage, why set at http layer - of course this might work as a workaround for the time being so it might be a good idea but I'm just not sure what unwanted issues it may cause

- the other thing is where I'm not sure, with set proxy you cannot define authentication account. if you use import from IE and the IE prompted for proxy auth, the stored credential will be used on winhttp layer (though I'm not 100% sure of that) - so this is just too uncontrolled for me

- upddwnldcfg.exe will need to run in the name of system account (it stores credentials under HKCU so far I know it will be a per user based setting)

--> what confuses me, the catalog synch works which should use the same configured proxy and account(?), only ADR does not work. shouldn't they both use the same process for sending account auth info?

• Edited by cgsilver Tuesday, November 19, 2013 12:24 PM

We've been having this exact issue with SCCM 2012 R2 when attempting to use a proxy account/server.

I went back and tried the same config on SCCM 2012 SP1 and it works fine, so looking like a bug in R2 perhaps.  Have informed Microsoft, waiting to hear back.

We've been having this exact issue with SCCM 2012 R2 when attempting to use a proxy account/server.

I went back and tried the same config on SCCM 2012 SP1 and it works fine, so looking like a bug in R2 perhaps.  Have informed Microsoft, waiting to hear back.

Am interested in the outcome, kindly share results. There are already 2 acknowledged bugs with hotfixes, I'll keep checking this link too:

http://sccmguy.com/2013/11/09/configuration-manager-2012-hotfixes/

Having the same issues! Any news on that?

BR

Hi,

I have the same problem with R2.

It looks like a problem with R2, because you need to give your Primary Site access to the internet through your proxy.

Before R2 it was only the SUP that needs access to the internet.

If you open your console and go to the Administration --> Security --> Accounts and find the account for the SUP. Choose properties and click Set. Here you can try to verify the account through the Proxy, and in my scenario I got the 403 error when I try this on the Primary Site Server, and not on the SUP, where the proxy firewall is open.

My solution was to give the Primary Site access through the proxy and now my ADR works.

I hope that Microsoft will fix this, because I don't think it's a good idea that my Primary Site needs access to the Internet.

Hope that someone can use this. :)

Regards
Soren Helmer Lund

Tested and confirmed in hotfix:

http://support.microsoft.com/kb/2916611

• Proposed as answer by Jakster Friday, December 27, 2013 12:11 PM
• Marked as answer by Matthias Waltniel 21 hours 15 minutes ago

Tested and confirmed in hotfix:

http://support.microsoft.com/kb/2916611

• Proposed as answer by Jakster Friday, December 27, 2013 12:11 PM
• Marked as answer by Matthias Waltniel Friday, January 17, 2014 3:10 PM

Tested and confirmed in hotfix:

http://support.microsoft.com/kb/2916611

Tested in lab and in prod. Works.

Thanks!

Tested and works, thanks!