We were working on an issue recently where one single machine was unable to connect to any resources via direct access.

The first thing we checked was the Direct Access Connectivity Assistant logs and found the below errors.

“RED: Corporate connectivity is not working. Windows is unable to resolve corporate network names.  Please contact your administrator if this problem persists. 18/11/2010 11:35:40 (UTC)

Probes List
FAIL        FILE: \\DC.domain.com\sysvol\domain.com\policies\policydefinitions\desktop.admx
FAIL        HTTP: http://CA.domain.com/
FAIL        PING: SERVER.domain.com

C:\Windows\system32\LogSpace\{C892E78B-EA58-4990-86D8-E3E82C7A1D12}>netsh dns show state

Name Resolution Policy Table Options
——————————————————————–

Query Failure Behavior                : Always fall back to LLMNR and NetBIOS
                                        if the name does not exist in DNS or
                                        if the DNS servers are unreachable
                                        when on a private network

Query Resolution Behavior             : Resolve only IPv6 addresses for names

Network Location Behavior             : Never use Direct Access settings

Machine Location                      : Outside corporate network

Direct Access Settings                : Configured and Disabled

DNSSEC Settings                       : Not Configured”

The first thing that jumped out at us was that the DNS “Network location Behaviour” was set to “Never use Direct Access Setting” so this was the reason that all the probes failed as DNS could not resolve them.

After doing some research we came across the following MS article “http://msdn.microsoft.com/en-us/library/ff957870(PROT.10).aspx” which told us that if the following REGKEY “HKLM\Software\Policies\Microsoft\Windows NT\DNSClient\EnableDAForAllNetworks was set to 2 , then this would force the machine to “Never use Direct Access settings”.

After checking the machines registry we could see that the value was actually set to 2 therefore forcing the machine not to use DA setting, so what we did was change this value to 0 and gave the machine a reboot and everything sprung back into life

Came across an issue this week where a single users DFS target was set to a remote location instead of it’s own.

So first thing i did was install the DFS tools from the windows 7 RSAT.

I then ran the following command to view the cache for the referrals “dfsutil cache referral” this displayed a list of all the DFS shares the user had accessed. I scrolled down the list to find the troublesome share. On the troublesome share there was an error code on the status instead of a status to 0.

So what i decide to do was flush the cache “dfsutil cache referral flush” , i then accessed the DFS share which had now started to point it’s target as the local file server.

I then ran the “dfsutil cache referral” to see if the error code had gone from the local file server and it had

We Came across an issue the other day where a user was receiving mail in a different language.

So first thing we did was check the language on the users mailbox by running the following CMDLET

Get-Mailbox –Identity “username” | fl languages

This Returned a value of “ Languages  :  {jp-JN}” . So we had found that the problem was that the mailbox had been set to the wrong language, so we run the following command to set the language to English (United Kingdom)

Set-Mailbox –Identity “username” –Languages “en-GB”

To confirm the language of mailbox had change we ran the first command again and it returned the “en-GB” value