Getting IP-HTTPS error code 0x2AF9?

Today’s post is specifically about the common causes for IP-HTTPS error code number 0x2AF9.  When viewing your DirectAccess connection status on Windows 8 clients, you will see them stuck in “Connecting” state while looking at the properties of your DirectAccess Connection  :

Windows 8 DA Connecting

Windows 8 DA Connecting

If your DirectAccess client is trying to connect via IP-HTTPS, then there’s some built-in troubleshooting tools in Windows you can use to diagnose why the connection is failing.  On Windows 7 and Windows 8 machines, you can run netsh from the command prompt to see the current status of the IP-HTTPS connection as shown below :

C:\>netsh int https show int

Interface IPHTTPSInterface (Group Policy)  Parameters
————————————————————
Role                       : client
URL                        : https://da.contoso.com:443/IPHTTPS
Last Error Code            : 0x0
Interface Status           : IPHTTPS interface is active.

In this example we have a DA client that is successfully connected to DirectAccess as shown above with error code 0x0.

Now this past week I had to troubleshoot a relatively rare IP-HTTPS error code of 0x2AF9 that looked just like this in the netsh output :

Interface IPHTTPSInterface (Group Policy)  Parameters
————————————————————
Role                       : client
URL                        : https://da.contoso.com:443/IPHTTPS
Last Error Code            : 0x2af9
Interface Status           : failed to connect to the IPHTTPS server.

To save everyone time in case you encounter this error in the future, here are the most common causes of this particular error code :

  1. Make sure your DA client can properly resolve the external DNS name of your DirectAccess server.  From my example above, you can see the FQDN URL listed was da.contoso.com.  Make sure this resolves from the DA client and it’s the correct IP address.  The 0x2AF9 error code translates into “No such host is known” or the name listed doesn’t resolve to a proper IP address.  Common issues include bad entry in the local hosts file, no external DNS entry, or even a bad entry in the DNS cache.  Just make sure the client resolves the IP address correctly before moving to step number two.
  2. Second thing to check would be the system proxy settings.  Since this is a HTTPS connection to the DirectAccess server, it’s possible there could be a GPO or a local system proxy setting causing an issue for your computer to reach the DA server via HTTPS.  The easiest way to check for a local system proxy setting again is to use the following netsh command : netsh winhttp sh pro

    Current WinHTTP proxy settings:

    Direct access (no proxy server).

    Ensure the output shows that you have Direct access as shown above.  If this is not the case, then you can use the netsh winhttp command to reset the local system proxy settings.  It’s also possible to manipulate these settings by viewing the proxy settings in Internet Explorer.  Just remember you must open IE under the local system context, not with your user account.  My preferred method to launch IE as the local system would be using psexec from the Sysinternals tools :http://technet.microsoft.com/en-us/sysinternals/bb897553.aspx

  3. The last and final place to check begins in the registry.  Open up regedit on your broken DA client and navigate to the following location :HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\iphlpsvc\Parameters\ProxyMgrIf you happen to see any sub-keys listed below the ProxyMgr key that look like this :ProxyMgr Registry Key

    Then go ahead and delete the entire ProxyMgr key and restart your DA client.  The sub-keys below ProxyMgr should only appear on Windows 8 DA clients.  If these do exist, then it’s possible the cache listed below ProxyMgr has become stale.  The easiest way to clean out this cache is to delete the entire ProxyMgr key.  Don’t worry, when you either reboot or restart the IP Helper service this location gets re-created with a clean cache.

I’d like to give a big “Thank You” out to Brandon and Jake for being patient while we tracked down this error code and worked through to find a resolution in their environment.  Hopefully this will save the rest of you some serious troubleshooting time for error code 0x2AF9.

Tags: , , , , , , , ,

Categories: Troubleshooting DirectAccess

4 Comments on “Getting IP-HTTPS error code 0x2AF9?”

  1. August 5, 2013 at 10:42 #

    Very Useful stuff!!!

  2. Joey
    October 22, 2013 at 02:42 #

    Hi I delete the ProxyMgr Key reboot and DA works fine but if I reboot again it fails and the same error is there. How can I resolve the issue so that it doesnt keep reoccuring?

    • October 23, 2013 at 07:12 #

      Hi Joey,

      Does the ProxyMgr fill up with new information after you reboot?

  3. Joey
    October 29, 2013 at 06:28 #

    Hi Yes it fill up again and I have to delete the entries to get it working again..

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: