none
Windows 8 Windows Update error 8024401C

    Question

  • Good day.

    I have installed Windows 8 Enterprise x64 on my Compaq PC (3.4GHz AMD dual-core, 8GB DDRM) which sits on an enterprise network that uses http proxy authentication for Internet access. For the most part, all modules of WIn 8 have no troubles accessing the internet, but Windows Update will not, nor can the Store app. For long hours I have searched the internet looking for a solution to the update error 8024401C and have found TONS of causes and solutions, but none work for me.

    Often the solution is for administrators with access to a Windows 2008 Server, but nothing useful for clients of Windows 8. There are no problems with Windows 7 Professional x64 and Windows Update.

    What can I do to get my update service to work online?

    Thank you.

    Cole


    A teacher affects eternity: he can never tell where his influnce stops.

    Friday, December 07, 2012 10:15 AM

Answers

  • To solve it I quit "Orbit Downloader Manager". Updates work. To confirm execute orbit and error reappears.

    Monday, December 10, 2012 9:17 PM

All replies

  • Hello Aj,

    I copy the procedure I posted the other day in one of the related threads here for more convenience.

    Gentlemen, whilst it not yet solved and, yikes!,  we still have no comments on this issue from MSFT, I will recap my post with the workaround to this problem from Windows Store and Windows Update Fail With Error 0x8024401c On a PC Under Corporate Proxy With Direct Access (Proxy Disabled) thread.

    Note! The procedure below is a workaround and has its issues. While it definitely will allow you to install apps from Windows Store by tricking your apps make them think they are going out through a transparent proxy, the mess with implementation of WinHTTP library support in different apps causes completely different behavior of apps.

    Cause When processing asynchronous requests, WinHTTP does not handle thread impersonation properly. This causes requests that require NTLM/Negotiate authentication to fail, unless credentials are explicitly given using the WinHttpSetCredentials or WinHttpSetOption functions.

    In other words, currently available apps, including Windows Store app, do not properly use WinHTTP library.

    Issues Some apps will always connect through your proxy, so won't no matter exempted or not. If your proxy server is located in another area, this will render it impossible for some apps to correctly determine your location. In other words, some apps, mostly weather apps, will always show you the forecast for the location of your corporate proxy server and not the location of your PC, examples include but are not limited to:

    • WindGuru
    • WeatherFlow
    • Frost

    Apps that correctly handle location

    • Microsoft Weather
    • Accuweather
    • WeatherBug

    Gentlemen, it looks like I've found a possible solution to the problem with Modern apps not working in a corporate environment with a NTLM proxy.

    I've written complete step-by-step procedure that will guide you through issues with purchasing and installing Modern apps from Windows Store when working on a Windows 8 computer in a domain environment with corporate NTLM-enabled proxy server.

    Symptoms

    When working with Modern apps, you cannot make the apps to connect to a remote location. For example, your radio apps return connection errors, your Mail app returns Offline in a top-right corner of the app display when you sync messages for the selected mailbox, or you cannot purchase apps from Windows Store, and looking into the WindowsUpdate.log (the log file that journals Windows Update and Windows Store activity) shows the log contains records like:

    012-09-14      22:50:09:933     624    17f4    WS      WARNING: The server returned HTTP status code '407 (0x197)' with text 'Proxy Authentication Required'.

    012-09-14      22:50:09:933     624    17f4    WS      WARNING: The proxy requires HTTP authentication scheme 'NTLM'.

    012-09-14      22:50:09:933     624    17f4    WS      WARNING: Web service call failed with hr = 8024401b.

    012-09-14      22:50:09:933     624    17f4    WS      WARNING: Current service auth scheme='None'.

    012-09-14      22:50:09:933     624    17f4    WS      WARNING: Proxy List used: 'proxy.domain.com:port', Bypass List used: '(null)', Last Proxy used: 'proxy.domain.com:port', Last auth Schemes used: 'None'.

    Cause

    Unlike desktop applications such as Windows Internet Explorer, which uses WinInet library (http://msdn.microsoft.com/en-us/library/windows/desktop/aa383630(v=vs.85).aspx) to establish

    connections, Modern apps establish connections using WinHTTP library (http://msdn.microsoft.com/en-us/library/windows/desktop/aa382925(v=vs.85).aspx).

    You may find comparison table for these to communication libraries available at http://msdn.microsoft.com/en-us/library/windows/desktop/hh227297(v=vs.85).aspx but the main difference, I guess, is here:

    Credential Prompting

    Provides an API
        that allows the calling code to prompt the user for credentials.

    yes

    no


    In other words, when WinInet library supports requesting connection credentials, the WinHTTP library does not. I am not a developer in either way, and I don't know if my assumptions are true, and I definitely can't understand why impersonation from threads, supported by WinHTTP library, does not work here but my guess is that WinHTTP library impersonates under some service account such as LocalSystem or WinHttpGetIEProxyConfigForCurrentUser function is NOT user in currently available Modern apps.


    That being said, I believe that the root of the problem lies in the current WinHTTP limitation (mentioned here http://msdn.microsoft.com/en-us/library/windows/desktop/aa384086(v=vs.85).aspx):

    When processing asynchronous requests, WinHTTP does not handle thread impersonation properly. This causes requests that require NTLM/Negotiate authentication to fail, unless credentials are explicitly given using the WinHttpSetCredentials or WinHttpSetOption functions.

    In other words, currently available apps, including Windows Store app, do not properly use WinHTTP library.

    Solution

    Part I

    To make your Modern apps properly authenticate on a corporate NTLM-enabled proxy server using current user credentials (that is your credentials you provided when logging into Windows 8 on the logon screen), you have to use third-party application that would authenticate connections outgoing from apps on the proxy server.

    This third-party application would be a NTLM-capable proxy server such as cntlm (cntlm.sf.net) (you may use any other proxy that can ask you for NTLM credentials required by your corporate proxy and is capable of working in a chain of proxy).

    Once installed on your local Windows 8 computer, cntlm proxy will accept outgoing anonymous connections established by Modern apps and redirect them to a parent proxy server (that is, chain to upstream proxy), that is to your corporate proxy server. This way, your Modern apps that are not capable of authenticating via NTLM protocol authenticate on a corporate proxy server without even knowing that this corporate proxy server requires explicit authentication  --- cntlm will do this trick for the apps.

    Briefly, connection chain will now look as:

    Modern app (localhost) -> cntlm (localhost) -> corporate proxy (domain network) -> web service (remote end-point).

    To install local cntlm proxy, do the following:

    1. Download the cntlm proxy setup package from cntlm.sf.net (direct link to the latest version: http://sourceforge.net/projects/cntlm/files/latest/download?source=files) or any other NTLM-capable proxy server; install the setup package.

    2. Open Services snap in by pressing WindowsKey and typing 'services' (without quotes), locate and stop the Cntlm Authentication Proxy service;

    Alternatively, to stop the service type at the elevated command prompt

    sc stop cntlm

    3. Open cntlm program folder (%programfiles(x86)%\cntlm or %programfiles%\cntlm for x64 and x86 platforms correspondingly) and open cntlm.ini configuration file in the notepad.

    3.1 Specify the user account name used to authenticate on your corporate proxy server such as:

    Username Jon

    3.2 Specify authority to which your user account name is belonging, this is typically your domain name, for example:

    Domain corporation.com

    ATTENTION: If you do not know your domain/authority name used to authenticate your account name, type the following at the command prompt:

    systeminfo | findstr /B /C:Domain

    This will return a string like:

    Domain:                    corporation.com

    3.1 Comment out the Password option by preceding it with the sharp sign:

    #Password password

    because you don't want to specify your domain password in a plain text.

    3.3 Determine what version of NTLM challenge is supported by corporate proxy server.

    To do that, open the command prompt and change working directory to cntlm program folder (%programfiles(x86)%\cntlm or %programfiles%\cntlm for x64 and x86 platforms correspondingly), or simply navigate to cntlm program folder in Windows Explorer and choose File|Open command prompt.

    At the command prompt type:

    cntlm.exe -M http://google.com

    Type your domain user account password when prompted.

    This will return the most secure NTLM authentication response hash supported by your corporate proxy server.

    ATTENTION: If you want to use other types of response hashes to authenticate on a corporate proxy server (such as LM or NT, which is not recommended for security reasons if the corporate proxy server supports NTLMv2 responses), type the following:

    cntlm.exe -M

    Type your domain user account password when prompted.

    This will return the all the three NTLM authentication response hash supported by cntlm proxy server.

    3.4 Copy hash string (a 16-byte [32-character] alpha-numeric string) that looks like:

    FBB7DAA8D3663EC34F199E3CF838D3BD

    This is a result of HMAC-MD5 function (NTv2 = HMAC-MD5(v2-Hash, SC, CC*), see http://en.wikipedia.org/wiki/NTLM for more details.

    3.5 Paste the copied string next to the PassNTLMv2 option (if you used NTLMv2 response returned by cntlm -H or cntlm -M commands):

    PassNTLMv2 FBB7DAA8D3663EC34F199E3CF838D3BD

    ATTENTION: Comment out all the unused responses

    #PassLM

    #PassNT

    PassNTLMv2 FBB7DAA8D3663EC34F199E3CF838D3BD

    3.6 [optional] Specify your computer name:

    Workstation computername

    3.7 Specify the IP or hostname of the corporate proxy server, for example:

    Proxy 192.0.2.2:8080

    ATTENTION: You may get the corporate proxy server address from the %systemroot%\WindowsUpdate.log log file by locating line like:

    012-09-14      22:50:09:933     624    17f4    WS      WARNING: Proxy List used: 'proxy.domain.com:port', Bypass List used: '(null)', Last Proxy used: 'proxy.domain.com:port', Last auth Schemes used: 'None'.

    Alternatively, type the following at the command prompt:

    reg query "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings" | find /i "proxyserver"

    SR at 14.11.2012 17:21

    This command will obtain the proxy server address used by WinInet library from Windows registry.

    3.8 [optional] Specify the target network addresses that should not be routed via cntlm proxy

    NoProxy  localhost, 127.0.0.*, 10.*, 192.168.*

    3.9 Specify the local TCP port that will be used by cntlm proxy server to listen for incoming connections from Modern apps (actually from WinHTTP library), for example:

    Listen 3128

    3.10 [optional] Specify which source networks are allowed to establish incoming connection to your cntlm proxy server. Since you only install proxy to route Modern apps that run on your local computer, specify the loopback 127.0.0.0/8 network as the only allowed and prohibit connections from all other (0/0) networks:

    Allow  127.0.0.1

    Deny  0/0

    3.11 Leave all other cntlm configuration file options intact, close notepad, and save changes to the configuration file.

    ATTENTION: Because User Account Control (UAC) needs to be enabled for Modern apps to run, you may need your cntlm.ini sent to a non-prohibited location such as your My Documents folder (because %programfiles% folder is prohibited for writing under non-elevated processes). Once save to a temporary storage, copy changed cntlm.ini file back to cntlm proxy server program folder.

    Continued in the message below.


    Well this is the world we live in And these are the hands we're given...

    Friday, December 07, 2012 12:05 PM
  • Part II

    Continuation, see Part I above for the beginning.


    4.  Open Services snap in by pressing WindowsKey and typing 'services' (without quotes), locate and start the Cntlm Authentication Proxy service;

    Alternatively, to start the service type at the elevated command prompt

    sc start cntlm

     

    This will start cntlm proxy server's Windows service. This time the service will use settings you have specified in the cntlm.ini configuration file.

     

    1. Now this is time to specify the local cntlm proxy server you have      just configured within WinHTTP library settings to make Modern app connect      via cntlm proxy.

    The quickest way to do that is to import proxy settings from WinInet library settings, but before you could do that, you would need to set proxy settings for the WinInet library itself, which you can do using desktop version of Windows Internet Explorer.

     

    5.1 Start Windows Internet Explorer by clicking its icon on the taskbar. In the started Windows Internet Explorer press Alt+X to show settings menu, chose Internet Options and switch to the Connections tab in the opened Internet Options dialog box. Next click LAN Settings and set Use a proxy server for your LAN (These settings will not apply to dial-up or VPN connections) check box.

    In the Address and Port fields specify the localhost IP address and listen port correspondingly as specified in the cntlm.ini configuration file, namely:

    Address: 127.0.0.1

    Port: 3128

    Click OK to apply proxy settings to WinInet library and close Internet Explorer.

     

    1. When proxy settings are      defined for the WinInet library, you are good to go with WinHTTP.

     

        6.1 Firstly, check currently used WinHTTP connection settings using Network Shell NetSH tool. To do that, start an elevated command prompt and type:

    cd "..\..\Windows\System"

    to open Windows system folder.

     

    Now execute the following command:

    netsh winhttp show proxy

     

    This will return your current proxy settings used by WinHTTP library, and hence this will show you the way it is currently used to connect to remote addresses by Modern apps:

     

    Current WinHTTP proxy settings:

    Direct access (no proxy server).

     

    Most likely, you will see that your Modern apps are connecting directly, that is connections go from your local computer to the default gateway (an IP address such as 192.0.2.1 provided that your computer is a located within the 192.0.2.0/24 private subnet).

    If you are using 64-bit Windows 8 on a x64 platform, check settings with 32-bit version of NetSh tool located in SysWOW64 folder. When in the System folder, type

     

    cd ..\SysWOW64

     

    to change to SysWOW64 folder and then execute

     

    netsh winhttp show proxy

     

    This will return the same settings:

     

    Current WinHTTP proxy settings:

    Direct access (no proxy server).

     

    ATTENTION: To be doubly sure direct settings are used when impersonating under different user accounts, including service accounts, such as LocalService, Local System, Network Service, and your Microsoft account such as username@live.com or username@outlook.com provided that you have connected your domain user account to your Microsoft account (formerly known as Windows Live ID or WLID account).

     

    6.2 To check WinHTTP library connection settings under different accounts, use PSExec tool from SysInternals.

    Download Sysinternals Suite zip file from http://technet.microsoft.com/en-us/sysinternals/bb842062.aspx and unpack it to %ProgramFiles%\Sysinternals\. Open elevated command prompt and type:

     

    cd "..\..\Program Files\SysInternals"

     

    to navigate to SysInternals program folder.

     

    6.2.1 To interactively start command prompt window with LocalSystem privileges type

    PsExec.exe /s /i cmd

     

    Check that command prompt is running under LocalSystem privileges, type:

    whoami

     

    You should get

    nt authority\system

     

    To verify  WinHTTP library settings when it impersonates under LocalSystem, type:

     

    netsh winhttp show proxy

     

    both for 64-bit and 32-bit flavors of the Network Shell just as you did in bullet item 6.1

     

    Close started interactive command prompt running under LocalSystem and return back to the elevated command prompt opened in the %Program Files%\SysInternals\ working directory.

     

    6.2.1 To interactively start command prompt window with Network Service privileges type

    PsExec.exe /i /u "NT AUTHORITY\NETWORKSERVICE" "cmd"

     

    Check that command prompt is running under  Network Service privileges, type:

    whoami

     

    You should get

    nt authority\network service

     

    To verify  WinHTTP library settings when it impersonates under  Network Service, type:

     netsh winhttp show proxy

     

    both for 64-bit and 32-bit flavors of the Network Shell just as you did in bullet item 6.1

     

    Close started interactive command prompt running under  Network Service and return back to the elevated command prompt opened in the %Program Files%\SysInternals\ working directory.

     

    6.2.2 To interactively start command prompt window with Local Service privileges type

    PsExec.exe /i /u "NT AUTHORITY\LOCALSERVICE" "cmd"

     

    Check that command prompt is running under Local Service privileges, type:

    whoami

     

    You should get

    nt authority\local service

     

    To verify  WinHTTP library settings when it impersonates under Local Service, type:

     netsh winhttp show proxy

     

    both for 64-bit and 32-bit flavors of the Network Shell just as you did in bullet item 6.1

     

    Close started interactive command prompt running under Local Service and return back to the elevated command prompt opened in the %Program Files%\SysInternals\ working directory.

     

    6.2.3 To interactively start command prompt window with privileges of your Microsoft account press WindowsKey and type cmd.

    Right-click the command prompt icon and choose Open file location from the bar.

    In the opened Windows Explorer window right-click command prompt shortcut when holding Shift key pressed and choose Run as different user. In the Windows Security dialog choose Microsoft account. Specify your Microsoft account credentials.

     

    Check that command prompt is running under Microsoft account privileges, type:

    whoami

     

    You should get

    computername\microsoftaccounlogin

     

    (where computername and microsoftaccountlogin will substitute for your actual computer name and account name used on Live services)

     

    To verify  WinHTTP library settings when it impersonates under Local Service, type:

     netsh winhttp show proxy

     

    both for 64-bit and 32-bit flavors of the Network Shell just as you did in bullet item 6.1

    Close started interactive command prompt running under Local Service and return back to the elevated command prompt opened in the %Program Files%\SysInternals\ working directory.

      

    1. Now import connection      settings from WinInet library to WinHTTP library.

     

    Repeat all steps on the step 6 and its minor steps, but do use the following command that will import connection settings:

     netsh winhttp import proxy source=ie

     

    Do that for both flavors of Network Shell.

    Repeat step 6 and its minor steps when finished to confirm your cntlm proxy server is specified within WinHTTP library connection settings.


    Well this is the world we live in And these are the hands we're given...

    Friday, December 07, 2012 12:05 PM
  • Part III

    Continuation, see Part II above for the beginning.

     
    1. By default, each Modern app  runs in a separate container and so applies to its network connections.      Connection isolation is performed by Network Isolation.

    Network Isolation uses its own proxy autodiscovery feature to discover proxy server to use for connecting Modern apps. This autodiscovery feature (please correct me here) is different to WPAD (Web Proxy Auto Discovery) protocol used by desktop applications.

     

    To make sure your Modern apps connect though your specified proxy server, set local group policy.

     

    8.1     Press WindowsKey+R to open Run dialog box and type gpedit.msc to start Local Group Policy Editor.

     

    8.2 In the Local Group Policy Editor window right-click Administrative Templates folder under Computer Configuration and choose Filter options.

     

    8.3 In the Filter Options dialog box type 'proxy' (without quotes) in the Filter for word(s) field and choose Any in the drop-down list. Make sure all checkboxes are set for Within to make the filter apply to settings that have 'proxy' keyword in policy name, description, or help.

     

    8.4 Set the Enable Keyword Filters check box and click OK to apply the filter.

     

    8.5 Expand the Administrative Templates folder under Computer Configuration and click All Settings to display all policies related to configuring proxy settings.

     

    8.6 In the right results panel find the following policies

     

    Internet proxy servers for apps

    Intranet proxy servers for apps

     

    and  enable them.

     

    8.7 To enable a proxy policy, double click it and choose Enabled. Specify a local proxy server address such as 127.0.0.1:3128 (just as specified in the WinHTTP library settings) in the Domain proxies field and click OK.

     

    8.8 Enable the Proxy definitions are authoritative policy to make sure your local proxy server is a preferred proxy should your corporate proxy be discovered by Windows Network Isolation automatic proxy discovery.

     

    8.9 Press WindowsKey+R and type gpupdate/force to forcibly apply changes to local Group Policy settings.

     

    1. Because of enhanced security      measures implemented in Windows 8, Modern apps run in isolated in      application containers. Let me quote Eric Lawrence:

    "Metro-style applications run inside isolated processes known as “AppContainers,” and by default, AppContainers are forbidden from sending network traffic to the local computer (loopback). This is, of course, problematic when debugging with Fiddler, as Fiddler is a proxy server which runs on the local computer. The post went on to explain how the CheckNetIsolation tool can be used to permit an AppContainer to send traffic to the local computer. However, using CheckNetIsolation is pretty cumbersome—it requires that you know the AppContainer’s name or security ID, and you must configure each AppContainer individually. To resolve those difficulties, I have built a GUI tool that allows you to very easily reconfigure an AppContainer to enable loopback traffic. This tool requires Windows 8 and runs on the .NET Framework v4. When launched, the utility scans your computer’s AppContainers and displays them in a list view. Each entry has a checkbox to the left of it, indicating whether the AppContainer may send loopback traffic. You can toggle these checkboxes individually, or use the buttons at the top to set all of the checkboxes at once. Click Save Changes to commit the configuration changes you’ve made, or click Refresh to reload the current configuration settings.

    After you install the EnableLoopback Utility, a new “Win8 Loopback Exemptions” item is added to Fiddler’s Tools menu; clicking this item launches the utility. To make changes to the exemption list, you must elevate to Administrator."

     

    9.1 Download and install the Enable Loopback tool by Eric Lawrence from http://blogs.msdn.com/b/fiddler/archive/2011/12/10/fiddler-windows-8-apps-enable-loopback-network-isolation-exemption.aspx

     

    9.2 After installing run it with elevated privileges and and exempt necessary apps.

    To exempt an app, find the app in the app list within the AppContainer Loopback Exemption Utility and set a check box next to app name and click Save changes.

    If you had selected app opened, close the app by tapping and dragging it down to the bottom of the screen or move the mouse pointer to the top of the app display, wait until the pointer will turn from arrow to and drag the app screen with the mouse.

    Start the app again. It will now be exempted and will connect via your local cntlm proxy server.

     

    IMPORTANT: DO NOT EXEMPT your SkyDrive app if you are using it with your Microsoft Office 365 2013 ProPlus, or it will render it impossible for Office apps to open your documents from SkyDrive. Most likely, you will face with an error described in this my post at Microsoft forums: http://social.technet.microsoft.com/Forums/en-US/w8itprogeneral/thread/a87dd6ce-6339-4677-a9e1-27a4903a8b8f

     

    1. Finally, make sure apps that      are delivered from Windows Store are downloaded via local cntlm proxy.

    Like Windows Update, Windows Store uses BITS (Background Intelligent Transfer Service) to create download jobs and download purchased APPX Modern app packages from Windows Store.

    You may use BITSADMIN tool (or a dedicated PowerShell cmdlet) to make sure BITS transfers are made through manually specified cntlm proxy server:

     

    Also, make sure BITS service is routed via local proxy:

    C:\Windows\SysWOW64>bitsadmin.exe /Util /GetIEProxy "LocalService"

     

    BITSADMIN version 3.0 [ 7.6.9200 ]

    BITS administration utility.

    (C) Copyright 2000-2006 Microsoft Corp.

     

    BITSAdmin is deprecated and is not guaranteed to be available in future versions

     of Windows.

    Administrative tools for the BITS service are now provided by BITS PowerShell cm

    dlets.

     

    Current Internet proxy settings for account LocalService:

    (connection = default)

     

    Proxy usage:  MANUAL_PROXY

    Proxy list:   127.0.0.1:3128

    Proxy bypass: <empty>

     

    C:\Windows\SysWOW64>bitsadmin.exe /Util /GetIEProxy "LocalSystem"

     

    BITSADMIN version 3.0 [ 7.6.9200 ]

    BITS administration utility.

    (C) Copyright 2000-2006 Microsoft Corp.

     

    BITSAdmin is deprecated and is not guaranteed to be available in future versions

     of Windows.

    Administrative tools for the BITS service are now provided by BITS PowerShell cm

    dlets.

     

    Current Internet proxy settings for account LocalSystem:

    (connection = default)

     

    Proxy usage:  MANUAL_PROXY

    Proxy list:   127.0.0.1:3128

    Proxy bypass: <empty>

     

    C:\Windows\SysWOW64>bitsadmin.exe /Util /GetIEProxy "NetworkService"

     

    BITSADMIN version 3.0 [ 7.6.9200 ]

    BITS administration utility.

    (C) Copyright 2000-2006 Microsoft Corp.

     

    BITSAdmin is deprecated and is not guaranteed to be available in future versions

     of Windows.

    Administrative tools for the BITS service are now provided by BITS PowerShell cm

    dlets.

     

    Current Internet proxy settings for account NetworkService:

    (connection = default)

     

    Proxy usage:  MANUAL_PROXY

    Proxy list:   127.0.0.1:3128

    Proxy bypass: <empty>

     

    If for some service account you get a return that shows direct connection is used, like in this example for Local:

    C:\Windows\SysWOW64>bitsadmin.exe /Util /GetIEProxy "LocalService"

     

    BITSADMIN version 3.0 [ 7.6.9200 ]

    BITS administration utility.

    (C) Copyright 2000-2006 Microsoft Corp.

     

    BITSAdmin is deprecated and is not guaranteed to be available in future versions

     of Windows.

    Administrative tools for the BITS service are now provided by BITS PowerShell cm

    dlets.

     

    Current Internet proxy settings for account LocalService:

    (connection = default)

     

    Proxy usage:  NO_PROXY

     

    make sure you specify MANUAL_PROXY for this account:

    C:\Windows\SysWOW64>bitsadmin.exe /Util /SetIEProxy LocalService MANUAL_PROXY 12

    7.0.0.1:3128 NULL

     

    BITSADMIN version 3.0 [ 7.6.9200 ]

    BITS administration utility.

    (C) Copyright 2000-2006 Microsoft Corp.

     

    BITSAdmin is deprecated and is not guaranteed to be available in future versions

     of Windows.

    Administrative tools for the BITS service are now provided by BITS PowerShell cm

    dlets.

     

    Internet proxy settings for account LocalService were set.

    (connection = default)

     

    Proxy usage set to       MANUAL_PROXY

    Proxy list set to        127.0.0.1:3128

    Proxy bypass list set to <empty>

     

    Make sure to restart Windows, seems like it is necessary (possibly, settings are applied to machine account?).

     

     

    Sure, this seems to be extremely unfriendly procedure, but it works.

     

    Once again, the problem lies in the fact that current WinHTTP "does not handle thread impersonation properly. This causes requests that require NTLM/Negotiate authentication to fail, unless credentials are explicitly given using the WinHttpSetCredentials or WinHttpSetOption functions".

     

    Shortly, start with explicitly specifying the address of your corporate proxy server in Windows Internet Explorer LAN Settings and importing them to WinHTTP service settings using

     

    netsh winhttp import proxy source=ie

     

    But when it does not help you and you still see records like

    012-09-14      22:50:09:933     624    17f4    WS      WARNING: The server returned HTTP status code '407 (0x197)' with text 'Proxy Authentication Required'.

    012-09-14      22:50:09:933     624    17f4    WS      WARNING: The proxy requires HTTP authentication scheme 'NTLM'.

    012-09-14      22:50:09:933     624    17f4    WS      WARNING: Web service call failed with hr = 8024401b.

    012-09-14      22:50:09:933     624    17f4    WS      WARNING: Current service auth scheme='None'.

    012-09-14      22:50:09:933     624    17f4    WS      WARNING: Proxy List used: 'proxy.domain.com:port', Bypass List used: '(null)', Last Proxy used: 'proxy.domain.com:port', Last auth Schemes used: 'None'.

     

    in WindowsUpdate.log, follow this 10-step instruction, chain your local proxy server and upstream connections to your corporate proxy server.


    Well this is the world we live in And these are the hands we're given...

    Friday, December 07, 2012 12:05 PM
  • Shortly:

    1. Windows Updates uses WinHTTP library to fetch data and receive updates.
    2. Windows Store app uses Windows Update facilities to obtain apps from Windows Store.
    3. WinHTTP library has to be configured to be aware of your corporate proxy server using NetShell, or, otherwise, this configuration should be performed automatically using WinHTTP Web Proxy Auto-Discovery Service (WinHttpAutoProxySvc).
    4. When manually configuring WinHTTP library, you can opt for two options:
    5. Specify proxy address directly: netsh winhttp set proxy proxyservername:portnumber
    6. Import proxy address from the WinInet librarary (library used by Internet Explorer and desktop apps): Netsh winhttp import proxy source=ie
    7. Configure proxy chain and install a local NTLM-authentication aware proxy server (such as cntlm) that will work in chain with your corporate outgoing external proxy that requires NTLM authentication. This will trick your Windows 8 apps that connect through WinHTTP library into thinking they are connecting via transparent proxy that does not require NTLM authentication. The cntlm proxy server will do the authentication for them.

    For more information about how Windows Update works through the proxy and how it discovers it, see How the Windows Update client determines which proxy server to use to connect to the Windows Update Web site


    Well this is the world we live in And these are the hands we're given...

    Friday, December 07, 2012 12:16 PM
  • To solve it I quit "Orbit Downloader Manager". Updates work. To confirm execute orbit and error reappears.

    Monday, December 10, 2012 9:17 PM
  • What if I don't have Orbit Downloader Manager whatsoever and never had?

    The 0x8024401c error actually indicates HTTP status 408: "server timed out waiting for request"

    Error code (hex): 0x8024401c

    HRESULT (dec): -2145107940

    Error string: WU_E_PT_HTTP_STATUS_REQUEST_TIMEOUT

    Description: HTTP status 408 - Server timed out waiting for request

    See more details in this thread: Windows Store and Windows Update Fail With Error 0x8024401c On a PC Under Corporate Proxy With Direct Access (Proxy Disabled)        

    For more information, please refer to: WUA Networking Error Codes  (Windows)

    This code typically goes along with:

    Error code (hex): 0x803D0006

    HRESULT (dec): N/A

    Error string: WS_E_OPERATION_TIMED_OUT

    Description: The operation did not complete within the time allotted.

    So the solution would be to check connection to Windows Update/Windows Store web service using information from %systemroot%\WindowsUpdate.log and verify if your connection to the web service cannot be installed due to impersonation issues on your corporate proxy server.

    @Niki Han: Please unmark solution with Orbit Downloader as an answer. This hardly is the answer and more environment specific.


    Well this is the world we live in And these are the hands we're given...






    • Proposed as answer by Exotic Hadron Wednesday, December 19, 2012 11:59 AM
    • Edited by Exotic Hadron Wednesday, December 19, 2012 12:07 PM
    Wednesday, December 19, 2012 11:58 AM