ISATAP failing with error 0x490

ISATAP can be very useful if you need to manage out from a machine with an IPv4 address to a machine with an IPv6 address. This is commonly used where DirectAccess has been deployed as all DA clients will be using IPv6. Being able to RDP to them or use the SCCM Remote Control feature from a machine inside your network is very helpful for the IT support staff – it’s as if the user was just working from their desk like usual!

One time I was configuring an ISATAP interface on a server and I got the follow error in the event log:

Unable to update the IP address on Update type: 1. Error Code: 0x490

I scratched my head over this for quite a while – setting up an ISATAP interface should be easy! After a while I remembered that there was a history of disabling the IPv6 components on servers via GPO. It turns out that even though the GPO had been removed, the setting to disable IPv6 had been tattooed on the servers it had once been applied to.

To check this I had a look in the following location in the registry:


The value was set to 0xFFFFFFFF (it may instead be set to 0xFF). This disables enough of the IPv6 components to prevent an ISATAP interface from being able to be created.

Simply delete the DisabledComponents key and restart the server. So long as everything else is set up correctly you will have your ISATAP interface when you next log in.

The clients that didn’t know they were on the corporate LAN

I recently came across an issue where all of the Windows 10 clients in a particular remote site were unable to access network resources when connected to the local LAN. The strange thing? This LAN was part of the corporate network.

After searching around I found a number of people reporting similar issues with clients configured to use DirectAccess, usually being caused by things such as a corrupt Name Resolution Policy Table (NRPT) or other issues with the DirectAccess configuration. This led me to try exporting the NRPT registry keys  from a working client and importing them on one of these clients that was not working. But… that did not fix the problem. And anyway, there were devices in other offices that worked when they were connected to DA and the corporate LAN. This problem was limited to this particular office, so I started to dismiss DirectAccess as being the problem.

A little more troubleshooting and I discovered something else. When connected to the LAN these clients could not ping the IP address of any internal server hostname I tried pinging. Any time I tried to use ping on an internal server I just got back "Ping request could not find host hostname.local. Please check the name and try again." They could be pinged by IP address though. So perhaps a DNS issue? Perhaps not, as I discovered that nslookup did work.

Checking the Application log in Event Viewer I found the following three critical errors repeating every minute or so:

NETLOGON | Event ID 5719
There are currently no logon servers available to service the logon request.

DNS Client Events | Event ID 8015
The system failed to register host (A or AAAA) resource records (RRs) for network adapter
with settings:

The reason the system could not register these RRs was because the update request it sent to the DNS server timed out. The most likely cause of this is that the DNS server authoritative for the name it was attempting to register or update is not running at this time.

Time-Service | Event ID 129
NtpClient was unable to set a domain peer to use as a time source because of discovery error. NtpClient will try again in 15 minutes and double the reattempt interval thereafter. The error was: The entry is not found. (0x800706E1)

This led me to think there was something wrong with these clients ability to contact DNS, which eventually led me back to DirectAccess. As noted previously, these clients did work when connected via DirectAccess. So I thought, if I remove the DirectAccess configuration, will that make any difference to this broken-when-on-the-corporate-LAN situation? As I couldn’t just remove the DirectAccess client from the DirectAccess security group (because the client could not contact the domain controller to receive the policy change) I had to find the DirectAccess configuration in the registry and delete it there. It resides under HKLM\Software\Policies\Microsoft\Windows NT\DNSClient\DNSPolicyConfig. I my case there were 4 entries underneath this key, composed of DA-{GUID}. I deleted these keys,  restarted the client and found, to my delight, that it was now functioning correctly on the LAN. For good measure I re-added the DirectAccess configuration (this time by simply adding the client back into the DirectAccess security group) and confirmed that with the DirectAccess configuration back in place, the client was broken again on the LAN.

So what was going on? Eventually the following article from Microsoft led me to the answer: Network Location Detection. This article details the process Windows goes through to determine whether or not it is on the corporate network. When a network adapter status change is detected Windows attempts to access the URL that is stored in the registry key HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\NetworkConnectivityStatusIndicator\CorporateConnectivity\DomainLocationDeterminationUrl. The URL in this key will have been configured by whoever originally set up DirectAccess in your organisation. If Windows does not receive a valid HTTP response (HTTP status 200 OK) it believes you are not connected to the corporate LAN and attempts to connect to DirectAccess. During this process the entry in the NRPT table that governs what DNS server to use when connected to DirectAccess is used and, because you are not actually connected to DirectAccess, name resolution problems start to occur.

What about a fix? Why couldn’t the client access the network location detection URL? This goes back to the way DirectAccess is configured. Best practise states that your DirectAccess servers should have two network adapters; one internal and one external. Only the external adapter should be configured with a default gateway to prevent routing issues. Internal routing has to be done via static routes.

And that was the key. This was a small remote site that had only recently been connected to the corporate network and there was no static route between the DirectAccess server and the IP subnet being used by this site. After hours of investigating, this issue was resolved in a single moment by issuing the following Powershell command:

New-NetRoute -InterfaceAlias InternalAdapterName -DestinationPrefix Subnet/Mask -NextHop GatewayAddress

I went back to my broken client, opened my browser and entered the network location detection URL and was presented with the Microsoft IIS splash page. I restarted all the clients onsite and they correctly detected that they were on the corporate LAN.