Hello,

I'm struggling to set up Direct Access to allow it's clients to pick up the WPAD file. It works ok for the LAN clients, but not for DA ones.

Some information about our setup:

1) Force tunneling is used

2) There is a WPAD entry in the DNS table set up as an Alias pointing to the FQDN of our web server hosting the WPAD file. (somehow I think this might be a problem and we should use an A record for that)

3) Local name resolution is set to least-restrictive (use local DNSfor any kind of DNS resolution errors). 

4) Windows 7

The problem I am having is that my browser can't pick up the WPAD file using Direct Access. And it does not matter if I use "Automatically Detect Settings" or "Use Automatic Configuration Script". I clear the browser cache, re-open it and the WPAD file is not picked up. I do the same thing on a Client on the LAN and it works like a charm.

This is also not a firewall problem because I can download the WPAD file when typing the "Auto-config script" address in the address bar. 

Does anyone have any ideas? Something needs to be done in the NRPT table? The WPAD alias should be changed to a host record?

Kind regards,

Wojciech

EDIT:

To add some more confusion to this topic, something about WPAD is working. 

We have 2 WPAD files:

1) Production one with the Alias in the DNS

2) Test one without a DNS entry that needs to be manually specified as the "auto-config script"

At this moment the only difference between the two is the entry for the Proxy server. The production one has it set by IP address, the test one by FQDN. And what I am unable to understand is why MS Teams are working fine with the test one, but do not work with the production one...

And why MS Teams are actually looking at the WPAD file and IE is not...

Hey

How do I migrate from Windows 2012 to Windows 2016 direct access?

Today we have 2 Windows 2012 running direct access using NLB. 

(new hardware)

Best approach?

Thanks in advance

Mike

Hi,

 We've deployed IPHTTPS DirectAccess to Windows 10 clients using a single Windows 2012 R2 server behind a NetScaler for load balancing. DA works, but we have an issue where DA user's can't collect troubleshooting information. If you go the DirectAccess menu and go to collect under "Troubleshooting info" the icon

is temporarily surrounded by some spinning circles and nothing happens. I'm expecting Outlook to pop-up with a HTML attachment, but it doesn't.

The diagnostic file is generated in c:\users\username\appdata\local\temp\, but the file is only 4KB and the diagnostic links do not work. The probe list successfully finds the NLS and the DTE ping list passes as well.

This is our 2nd DA instance, the first instance doesn't have this issue. All DNS records look OK.

Any ideas?

Thanks

Hi,

 We have a single DA server setup as a 1 node cluster. The server uses a NetScaler as a load balancer. We want to add another node into the cluster. Currently we have Windows 10 clients connected to the single node cluster. If we add another server into the mix, will it break DA for existing client connections?

Thanks

IT Support/Everything

Hi,

just discovered that our DirectAccess-RADIUS-Encrypt-ourhostname.ourdomain.com certificate (in Local Computer/Personal/Certificates) has expired. I think it is generated when DirectAccess is setup via wizard.

What this certificate do? How to renew it?

I found this when I started to inspect two red cross over our first directaccess server (two server farm, second server is totally healty) health monitor: 

IP-HTTPS Not working properly: The IP-HTTPS certificate is missing. Causes: The certificate has been removed from the computer store.

IPsec Not working properly: There is no valid certificate to be used by IPsec which chains to the root/intermediate certificate configured to be used by IPsec in the DirectAccess configuration. Several causes.

These two errors seems to pump on/off in mysterious interval.  Suddenly everything is green on healty monitor without doing anything and other time this two redcross is back :(  Other certificates (other than da-radius-encrypt) are valid and running.

Any ideas? :)

Tsiksuka

Hi,

I have configured Directaccess with IPHTTPS Interface, My most of the DAClient  are getting connected on the IPhttps Interface but some of the DAClinet are getting in Connecting stage instead of being Connected because they are searching for Teredo Interface which is not configured on my server end. Even though all the DAClient are on the same network some are stuck on Teredo tunnel and after the reboot some are moving towards IPhttps and getting connected. 

But I have to resolve this as all the clients should go with IPhttps and get connected with the DA Server.

How to resolve this. help will be appreciated.

Thanks,

Roshan

Hello,

We have deployed a Server 2012 R2 DirectAccess infrastructure, single server and we only use IPHTTPS. Our clients are a mix of Windows 7 and Windows 10.

• Our DA server uses a public certificate on the IP-HTTPS tunnel
• We've deployed a new PKI to replace our existing one. 
• I need to migrate our DA implementation (server/clients) to use certificates from the new PKI.

What would this process be?

I think I need to push computer certificates from the new PKI to all of our domain joined laptops that are enabled for DA before I change the certificates on the DA server itself otherwise how else can clients connect back?

1. Are there any issues that could happen if a client computer has two certificates, one from old PKI and one from new? Will this break existing DA connectivity or will DA know which certificate to use?
2. When I change the certificate on the DA server, to the new one from our new PKI, it will probably need to apply these updates to the GPOs; now will the DA clients need the updated GPO settings along with the updated certificates to work?

How can I do this with minimal downtime to our DA clients? I don't want to break DA connectivity for our mobile users on laptops, but i need to replace our existing PKI and get the DA infrastructure to use the new PKI.

Anyone done this before?

Hello,

We have a two-leg (DMZ+LAN) Direct Access infrastructure setup on Windows Server 2012 with Win 7 computers clients. Out of sudden, after the last server restart it stopped working. IP Sec Main mode negotiations are failing on both ends(client & server) with event id 4653. Can somebody help me troubleshoot this IPSec errors?

Looking with tcpview, I can see on both sides that the connection to https port on DA server is established.

On server side, I see only green checkmarks in Remote Access console. There are times when Network Security module is reporting that is under a DOS attack (probably caused by the high number of connections ~1000 that are failing IPSec)

• On      the server side 4653 event ids are logged (for most of them the reason is:      Sent DoS cookie notify to initiator.)

A wireshark trace is showing ipv6 traffic only in one direction, from fd00:0:0:1000::1 toward the remote client. I cannot see anything where the source is the ipv6 address of client.

• On the client side, I also get      4563 event ids:

The IPHTTPS interface is reporting as active, but it cannot reach the DA, DNS or any other infrastructure server.

DirectAccess Client Troubleshooter Tool is reporting:

[28/11/2018 10:37:30]: In worker thread, going to start the tests.
[28/11/2018 10:37:30]: Running Network Interfaces tests.
[28/11/2018 10:37:30]: Wireless Network Connection (Intel(R) Centrino(R) Advanced-N 6205): 10.3.77.53/255.255.252.0;
[28/11/2018 10:37:30]: Default gateway found for Wireless Network Connection.
[28/11/2018 10:37:30]: iphttpsinterface (iphttpsinterface): fd00::1000:4005:d6ac:8164:5a85;: fd00::1000:f45f:b394:7649:f2f9;: fe80::4005:d6ac:8164:5a85%18;
[28/11/2018 10:37:30]: No default gateway found for iphttpsinterface.
[28/11/2018 10:37:30]: Wireless Network Connection has configured the default gateway 10.3.79.254.
[28/11/2018 10:37:42]: Warning - default gateway 10.3.79.254 for Wireless Network Connection does not reply on ICMP Echo requests, the request or response is maybe filtered?
[28/11/2018 10:37:42]: Received a response from the public DNS server (8.8.8.8), RTT is 41 msec.
[28/11/2018 10:37:42]: The public DNS Server (2001:4860:4860::8888) does not reply on ICMP Echo requests, the request or response is maybe filtered?
[28/11/2018 10:37:42]: Running Inside/Outside location tests.
[28/11/2018 10:37:42]: NLS is https://nls.<COMPANY>.local/.
[28/11/2018 10:37:42]: NLS is not reachable via HTTPS, the client computer is not connected to the corporate network (external) or the NLS is offline.
[28/11/2018 10:37:42]: NRPT contains 3 rules.
[28/11/2018 10:37:42]:   Found (unique) DNS server: fd00::a03:ea
[28/11/2018 10:37:42]:   Send an ICMP message to check if the server is reachable.
[28/11/2018 10:37:54]: DNS Server fd00::a03:ea does not reply on ICMP Echo requests.
[28/11/2018 10:37:54]: Running IP connectivity tests.
[28/11/2018 10:37:54]: The 6to4 interface service state is default.
[28/11/2018 10:37:54]: Teredo inferface status is offline.
[28/11/2018 10:37:54]:  The configured Teredo server is the public Microsoft Teredo server teredo.ipv6.microsoft.com..
[28/11/2018 10:37:54]: The IPHTTPS interface is operational.
[28/11/2018 10:37:54]:  The IPHTTPS interface status is IPHTTPS interface active.
[28/11/2018 10:37:54]: IPHTTPS is used as IPv6 transition technology.
[28/11/2018 10:37:54]:  The configured IPHTTPS URL is https://da.<COMPANY>.com:443.
[28/11/2018 10:37:54]: IPHTTPS has a single site configuration.
[28/11/2018 10:37:54]: IPHTTPS URL endpoint is: https://da.<COMPANY>.com:443.
[28/11/2018 10:37:55]:  Successfully connected to endpoint https://da.<COMPANY>.com:443.
[28/11/2018 10:37:55]: No response received from <COMPANY>.local.
[28/11/2018 10:37:55]: Running Windows Firewall tests.
[28/11/2018 10:37:55]: The current profile of the Windows Firewall is Public.
[28/11/2018 10:37:55]: The Windows Firewall is enabled in the current profile Public.
[28/11/2018 10:37:55]: The outbound Windows Firewall rule Core Networking - Teredo (UDP-Out) is enabled.
[28/11/2018 10:37:55]: The outbound Windows Firewall rule Core Networking - IPHTTPS (TCP-Out) is enabled.
[28/11/2018 10:37:55]: Running certificate tests.
[28/11/2018 10:37:55]: Found 1 machine certificates on this client computer.
[28/11/2018 10:37:55]: Checking certificate [no subject] with the serial number [15CF7D9B0005000094D7].
[28/11/2018 10:37:55]:  The certificate [15CF7D9B0005000094D7] contains the EKU Client Authentication.
[28/11/2018 10:37:57]:  The trust chain for the certificate [15CF7D9B0005000094D7] was sucessfully verified.
[28/11/2018 10:37:57]: Running IPsec infrastructure tunnel tests.
[28/11/2018 10:37:57]: Failed to connect to domain sysvol share \\<COMPANY>.local\sysvol\<COMPANY>.local\Policies.
[28/11/2018 10:37:57]: Running IPsec intranet tunnel tests.
[28/11/2018 10:38:09]: Failed to connect to fd00:0:0:1000::1 with status TimedOut.
[28/11/2018 10:38:21]: Failed to connect to fd00:0:0:1000::2 with status TimedOut.
[28/11/2018 10:38:21]: Failed to connect to HTTP probe at http://directaccess-WebProbeHost.<COMPANY>.local.
[28/11/2018 10:38:21]: Running selected post-checks script.
[28/11/2018 10:38:21]: No post-checks script specified or the file does not exist.
[28/11/2018 10:38:21]: Finished running post-checks script.
[28/11/2018 10:38:21]: Finished running all tests.

Below is the output from some common troubleshooting commands:

<CMD>ipconfig /all

Windows IP Configuration

   Host Name . . . . . . . . . . . . : <HOSTNAME>
   Primary Dns Suffix  . . . . . . . : <COMPANY>.local
   Node Type . . . . . . . . . . . . : Hybrid
   IP Routing Enabled. . . . . . . . : No
   WINS Proxy Enabled. . . . . . . . : No
   DNS Suffix Search List. . . . . . : <COMPANY>.local

Ethernet adapter Bluetooth Network Connection:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Bluetooth Device (Personal Area Network)
   Physical Address. . . . . . . . . : C0-F8-DA-E3-1B-90
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes

Wireless LAN adapter Wireless Network Connection:

   Connection-specific DNS Suffix  . : <COMPANY>.local
   Description . . . . . . . . . . . : Intel(R) Centrino(R) Advanced-N 6205
   Physical Address. . . . . . . . . : A0-88-B4-55-F8-F0
   DHCP Enabled. . . . . . . . . . . : Yes
   Autoconfiguration Enabled . . . . : Yes
   IPv4 Address. . . . . . . . . . . : 10.3.77.53(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.252.0
   Lease Obtained. . . . . . . . . . : 28 November 2018 08:59:53
   Lease Expires . . . . . . . . . . : 02 December 2018 10:00:00
   Default Gateway . . . . . . . . . : 10.3.79.254
   DHCP Server . . . . . . . . . . . : 10.3.80.1
   DNS Servers . . . . . . . . . . . : 8.8.8.8
   NetBIOS over Tcpip. . . . . . . . : Enabled

Tunnel adapter isatap.{4A3D349D-D1ED-4F0E-967F-D4612C286083}:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft ISATAP Adapter
   Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes

Tunnel adapter isatap.<COMPANY>.local:

   Media State . . . . . . . . . . . : Media disconnected
   Connection-specific DNS Suffix  . : <COMPANY>.local
   Description . . . . . . . . . . . : Microsoft ISATAP Adapter #3
   Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes

Tunnel adapter iphttpsinterface:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : iphttpsinterface
   Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   IPv6 Address. . . . . . . . . . . : fd00::1000:4005:d6ac:8164:5a85(Preferred)
   Temporary IPv6 Address. . . . . . : fd00::1000:f45f:b394:7649:f2f9(Preferred)
   Link-local IPv6 Address . . . . . : fe80::4005:d6ac:8164:5a85%18(Preferred)
   Default Gateway . . . . . . . . . :
   NetBIOS over Tcpip. . . . . . . . : Disabled

<CMD>Netsh dnsclient 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             : Let Network ID determine when Direct
                                        Access settings are to be used

Machine Location                      : Outside corporate network

Direct Access Settings                : Configured and Enabled

DNSSEC Settings                       : Not Configured

<CMD>Netsh interface httpstunnel show interface

Interface IPHTTPSInterface (Group Policy)  Parameters
------------------------------------------------------------
Role                       : client
URL                        :https://da.<COMPANY>.com:443/IPHTTPS
Last Error Code            : 0x0
Interface Status           : IPHTTPS interface active

<CMD>Netsh namespace show effectivepolicy

DNS Effective Name Resolution Policy Table Settings

Settings for nls.<COMPANY>.local
----------------------------------------------------------------------
Certification authority                 :
DNSSEC (Validation)                     : disabled
IPsec settings                          : disabled
DirectAccess (DNS Servers)              :
DirectAccess (Proxy Settings)           : Use default browser settings

Settings for .<COMPANY>.local
----------------------------------------------------------------------
Certification authority                 :
DNSSEC (Validation)                     : disabled
IPsec settings                          : disabled
DirectAccess (DNS Servers)              : fd00::a03:ea
DirectAccess (Proxy Settings)           : Bypass proxy

<CMD>Netsh advfirewall monitor show mmsa

No SAs match the specified criteria.

<CMD>Netsh advfirewall show currentprofile

Public Profile Settings:
----------------------------------------------------------------------
State                                 ON
Firewall Policy                       BlockInbound,AllowOutbound
LocalFirewallRules                    N/A (GPO-store only)
LocalConSecRules                      N/A (GPO-store only)
InboundUserNotification               Enable
RemoteManagement                      Disable
UnicastResponseToMulticast            Enable

Logging:
LogAllowedConnections                 Enable
LogDroppedConnections                 Enable
FileName                              %systemroot%\system32\LogFiles\Firewall\pfirewall.log
MaxFileSize                           24096

Ok.

<CMD>Certutil -store my
my
================ Certificate 0 ================
Serial Number: 61d68c3200050000946c
Issuer: CN=<COMPANY-CAName>, DC=<COMPANY>, DC=Local
 NotBefore: 15/11/2018 13:35
 NotAfter: 02/07/2019 11:43
Subject: EMPTY (DNS Name=<HOSTNAME>.<COMPANY>.local)
Non-root Certificate
Template: 1.3.6.1.4.1.311.21.8.6693252.4963786.7359385.10098729.16443910.70.7655005.1833759
Cert Hash(sha1): fb 5d d5 b2 31 57 83 bb 9b 68 b8 91 b8 f2 b2 a4 8b a2 51 ac
  Key Container = f588ece0f8e5701064bc0b40d7c606f2_704c463e-1552-49a5-8244-f045c492456d
  Simple container name: le-SCCMClientCertificate-f86fdc58-1726-4779-9be3-aa3023c0fa21
  Provider = Microsoft RSA SChannel Cryptographic Provider
Private key is NOT exportable
Encryption test passed

On the server side, I've performed a restore back in time to a point when I know for sure that DA was working. Along with this, I've also restored the DA GPOs. This has not helped, so it makes me think that the issue is not on the DA server itself.

I don't believe that it can be on client side, as I consider that if it was this case, at least I could have seen at least one connected client. Or maybe the DOS protection of DA server is preventing all client connections.

Does anyone have any idea what might be wrong?

Hi,

One of our site closed suddenly with no option for us to decommission DC and DA entry point.

I could remove DC manually but unable to change within direct access environment, cmd I tried:

Set-DAEntryPointDC –ExistingDC “Server.domain.tld” -NewDC “Server.domain.tld” –Force -PassThru

but it says entry point cannot be found, I tried removing entry point first using this cmd, but wont work either:

Remove-DAEntryPointTableItem  -EntryPointName "abc" -PolicyStore "domain.com\DirectAccess2 Client Setting"

Get-DAEntryPointTableItem -EntryPointName "abc" -PolicyStore  "domain.com\DirectAccess2 Client Settings" | Remove-DAEntryPointTableItem

GUI cannot be opened as well, please suggest next steps.

Error: directaccess server gpo settings cannot be retrieved. ensure you have edit permissions for the gpo

Hi all,

           DA server on 2016 - been running for a few years with no issues, but I logged in today to update a setting, and found it could not write the config.

A bunch of troubleshooting later, I have found that

running get-DANetworklocationserver comes up with empty entries - which I imagine is the issue.

this has been pointing to an internal HA web server for ages - and seems to be working fine - but the config is seemingly gone.

in order to get around this - I have tried to run

Set-DANetworkLocationServer -NlsOnDAServer -PassThru

in order to "reset" the config - but unfortunately I still get "the system cannot find the file specified"

I cannot see any errors in the event log.

I have noticed IIS is only bound on port 80 - however, if I try and add 443, I get an error stating it is already in use. Additionally a netstat -an shows the server is listening on 443 - so I assume that's because the DA services don't show up in IIS.

Both domain admins and the DA computer account have full control over the GPO's.

Not quite sure where to look next.

Good Day

we have a multisite configuration with one entry point in location A and one in location B. Ofte we face the problem that clients located in location A are connecting to the entry point in location B and other way arround. (Location A and B are on different continents)

when i'm logged in on a client in location A and ping:

- Entry point in location A: time=24ms

- Entry point in location B: time=150ms

-> this client should connect to entry point in location A, but it connects to location B if it is set to "select automaticaly".

Question 1: is there any way to troubleshoot this? for example a logfile on the client where i can see why exactely it connected to the, in this case, wrong entry point?

Question 2: Can i smehow manually select an entry point for a client. for example that i can create a gpo where i can set the entry point for client a to location a and for client b to location b.

Thanks

Best Regards

Hey guys, we have a two tier CA hierarchy with an offline root and two issuing CA's - Direct Access works fine however we want to publish the DA computer certificate template to both issuing CA's to have some resiliency. When we do this and a client rightly picks up a computer certificate from the other CA server to where the DA server has issued it's certificate, we get an error and the ipsec tunnels fail. If we re-issue the certificate back from the first CA (the same as the DA server) all is fine and dandy.

Is it supported to publish Da computer templates to two separate CA issuing servers? Technet says this which suggest it isnt but surely there is a way to get better resiliency? Here is a quote from the technet link. 

The client certificate and the server certificate should chain to the same root certificate. This root certificate must be selected in the DirectAccess configuration settings. 

If we issued the DA computer certificate from the offline root, would it technically be chained if the client then issued from one of the sub issuing CA's? I haven't tried this, so thought I would ask. I've got a case open with Microsoft directly but am not getting very far with it.

hey guys, we have hit the issue described in Richard Hicks blog here - we have two DA servers in a load balanced cluster using a hardware load balancer. The New-NetRoute command as described in his blog works fine for the first server, eveything is happy and DA functions normally. The second server in the cluster, built with the same base OS, in the same subnet on the next IP address along for external and internal network cards, doesnt work.

The Client IPv6 prefix is published OK but on restarting the server or just the RaMgmtSvc service, the published route is removed. I've tried using PoSH and also the old way with netsh, the route is published fine with both. Restarting the service removes the route, so everytime I load the console it tells me the client prefix isnt published, when it is .... it just doesnt know about it yet as I need to restart the service... and well you get the idea.

Is this a bug? Time to log a call with Microsoft?

hey guys,

Technet here says that IPV6 must be configured on the corporate network when using multi-site. Is this the case? I've setup a lab with two sites and four DA servers with GSLB etc. I can get the infrastructure tunnel to come up and can RDP to domain controllers but the user tunnel doesnt come up, can only ping stuff. The connectivity status remains "connecting.." 

We can't go down the road of IPv6 so need to know, we will move to Always On if this is the case as we need multi site.

Hi,

I'm using two Win 10 computers with Win 10 1803. As far as I can tell both computers have the same configuration and I'm using the same user. Though only one computer has since one of the last Windows Updates a reliable Direct Access connection to our Windows Server 2016 Direct Access Server. I ran the build-in the Direct Access troubleshooter, but it couldn't identify the issue. The log tells what I pasted below

What can I do for further analysis? Is anyone else experiencing this issue with the latest Windows 10 Updates?

Any advice in advance

John

------------------------------------------------------------------------------

John

hey guys,

Technet here says that IPV6 must be configured on the corporate network when using multi-site. Is this the case? I've setup a lab with two sites and four DA servers with GSLB etc. I can get the infrastructure tunnel to come up and can RDP to domain controllers but the user tunnel doesnt come up, can only ping stuff. The connectivity status remains "connecting.." 

We can't go down the road of IPv6 so need to know, we will move to Always On if this is the case as we need multi site.