We seem to have an error which is only occuring on our clients with Win 10 1903.

The clients have binding errors in the logs with reference to the IP-HTTPS adapter. The client connects momentarily (1 successful ping) and then drop and this process repeats on every connection attempt.

The DA server registers an schannel issue about no compatible Ciphers although we have checked this and they match.

Downgrading the clients to a vanilla 1803 works without issue. Upgrade them to 1903 and we get the same issue as above.

Anybody else seen this?

We have now two customers with similar Direct Access problems that appeared in the last time. Direct Access is working sometimes, sometimes not. It happen that some clients can connect successfully to a DA server, and other clients can not connect to the same DA server at the same time. The DA status on the server is always ok, all components have a green mark. The windows 10 client (various versions) also says that Direct Access is configured correctly, but stay sometimes at "connecting" state forever.

When comparing the DA client logs of a working and a not working client, we have a client authentication problem on the not working client, according http://techgenix.com/7-steps-troubleshooting-directaccess-clients/. The "security associations" in the firewall applet are empty for main mode and quick mode.

Our DA installations are configured to use certificate authentication for Windows 7 backward compatibility. For testing, we have changed the authentication on a affected DA server to machine/user with the DA Kerberos Proxy by clearing the checkbox "use computer certificates" in the DA setup wizard. But we have the same problems: Some clients can successfully connect, some not.

Haven't found any information how to troubleshoot these DA authentication problems, wherever using certificate based- or Kerberos machine/user authentication. 

Thank you all in advance for any help.

Franz

When trying to access the Remote Access Management Console we get the error "Settings forserverFQDN cannot be retrieved. The cmdlet did not run as expected". Similarly when using PowerShell we get "The cmdlet did not run as expected" using the many of the key cmdlets; "Get-DAServer", "Get-RemoteAccess", etc. Many others however do work and report back.

DirectAccess is operational, there's no connectivity issues and the group policy with the configuration says it's applied.

We can't pinpoint when the management aspect stopped working, there was mention that it coincided with one of our first domain controllers being decommissioned but that could be a misdirection.

I've not found anything particular to this problem and other than risk removing the GPO, removing the config, reapplying the GPO and DA config to see if that causes the management to start working. Below is a sample of the UI trace:

Hi All

I can get direct access working great with the single adapter option. We use nat from the WAN-LAN dns for the external url and open port 443.

However, when i introduce the DMZ in there i encounter problems.

I have tranferred the NAT address to the DMZ and created the relevant firewall rules

I removed the default gateway from the LAN card and ensured the DMZ card has this gateway and created static routes on the DA server so it can contact resources internally, and i have tested this and it seems ok.

The problems i encounter when i set it up this way is my DA Client upon getting the policy does not seem to differentiate internet from corporate, i have specified the corporate only servers via ping. I can see the client trying to connect to DA regardless. Its really wierd and i had this setup working about 2 weeks ago and i had to rebuild and i know im doing something silly, i just need a fresh brain to say have you done A,B,C. 

Any ideas would be great.

Cheers

Julian

I keep on getting error messages for Active Directory Web Services after the service starts. I have two UAG servers using Windows NLB.

Log Name:      Active Directory Web Services
Source:        ADWS
Event ID:      1004
Task Category: ADWS Startup Events
Level:         Information
Keywords:      Classic
User:          N/A
Computer:      UAG-APP02.domain.com
Description: Active Directory Web Services has successfully started and is now accepting requests.

Log Name:      Active Directory Web Services
Source:        ADWS
Date:          3/20/2011 11:28:00 PM
Event ID:      1202
Task Category: ADWS Instance Events
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      UAG-APP02.domain.com
Description: This computer is now hosting the specified directory instance, but Active Directory Web Services could not service it. Active Directory Web Services will retry this operation periodically. 

While this service is running on the array manager server, it works OK. I do get certificate error (on the array manager)

Active Directory Web Services could not find a server certificate with the specified certificate name. A certificate is required to use SSL/TLS connections. To use SSL/TLS connections, verify that a valid server authentication certificate from a trusted Certificate Authority (CA) is installed on the machine.

One way i see this affecting UAG (still not confirmed if two issues are related) is that users cannot authenticate using their email address (configuration from this blog: http://blogs.technet.com/b/edgeaccessblog/archive/2010/08/23/authenticating-to-uag-with-an-email-address-instead-of-user-id.aspx) it did work for a while...

Current Setup

2 x MS Directaccess 2016 VMWare VM's running on CISCO UCS Blade infrastructure, operating in HA mode NLB Cluster utilising multicast

Current VSwitch set to

Promiscuous mode: Reject

Mac Address Changes: Accept

Forged Transmits: Accept

Notify Switches: Yes

All,

I am looking to transition a bunch of users from 2012 > 2016, we have the same setup in our 2012 environment above, albeit it's on HP hardware utilizing DL380 G8's and is working fine for many years.

I've built out new 2016 servers on new hardware utilizing Cisco UCS blade infrastructure, and whilst DA is working fine and traffic is routing in/out properly i am seeing Network security messages stating a network security component is under a replay attack intermittently which results in dropped connections.

Please do not suggest moving to always on vpn that's not the answer i'm looking for.

I've tried everything to troubleshoot, but i just cannot seem to figure out what's causing it, we don't have these issues on the old HP servers.

Anyone come across this and have any suggestions please?

We have a working DirectAccess solution in place with no issues for inbound connections from DA clients. We are wanting to manage these clients from SCCM and so I've looked at setting up manage out for this.

I have configured a group policy linked to a security group for manage out clients where I have enabled an ISATAP router and set this as a DNS entry for the internal IP address of our DA server (we only have one). I have also enabled ISATAP in the same group policy, as suggested in the various walkthroughs of this set up.

I have checked clients and the ISATAP interface is enabled via group policy, but they are not receiving an IPv6 address on their tunnel adapter from the ISATAP router. They only have an IPv6 link-local address defined.

Can anyone point me into the direction of why this would be the case?

We have a requirement for certain public web sites to be tunnelled internally over DA. This is due to some public services being white-listed using our own organisation's public IP or need to accessed through a VPN.

DirectAccess is currently configured on Server 2012 R2 and is notusing force tunnelling. 

When testing we've found that two services with the above criteria are unable to find the web services, DNS name resolution is fine. The service that is white-listed reports "Forbidden" so the assumption is the browser proxy settings are ignored by DA. Is that correct?

Richard Hicks' Article explains how to use selective tunnelling to route traffic although has come key caveats in that it only works with IE and Edge. In addition at least on of the cmdlets isn't valid on 2012 R2 (2016?). We're attempting to translate and test the settings on the client.

We'd welcome any advice on how best to approach this and how best to apply the configuration. Thanks.

Hi,

I upgraded our DA server from 2012 R2 to 2016, optimistically expecting things to stay the same as I used exactly the same settings.

But no. Now I have clients who won't be in the office for a while and so won't have the updated policies. Because of the way DA works these devices are rendered totally broken if they can't contact the (old) DA server, so I need to send them the updated policies to get them working again.

How can I manually export the settings to send these users?

Thanks

tmg2010 and forefront 2012 what is the new vision

Hello,

I've the following issue:

Within my UAG have I configured ADFS as authentication repository. With username/password is it working fine.

Now I want to move to client certificate authentication. When I try my adfs server internally, it indeed prompt for my certificate (user certificate and/or smartcard certificate). But when I then reach the page from outside, it didn't prompt for my certificate, and get immediatly an error, saying that the client certificate presented is not valid. (while I had no change to select it)

May somebody have an idea, if this can be solved and how.

Regards,

Daniel

Facing one issue with only DA client , it connects to Direct access for few seconds and then get disconnected.

Looking at error on Event viewer I see below error

Any help appreciated certificate looks ok on client not sure why IPSEC is still failing.

Main

An IPsec main mode negotiation failed.

Local Endpoint:

                Local Principal Name:          -

                Network Address: fd03:c8e4:6dc5:1000:65c3:ec29:19db:d27

                Keying Module Port:            500

Remote Endpoint:

                Principal Name:                    -

                Network Address: fd03:c8e4:6dc5:1000::1

                Keying Module Port:            500

Additional Information:

                Keying Module Name:         IKEv1

                Authentication Method:      Unknown authentication

                Role:                                       Initiator

                Impersonation State:            Not enabled

                Main Mode Filter ID:            0

Failure Information:

                Failure Point:                         Local computer

                Failure Reason:                      No policy configured

                State:                                      No state

                Initiator Cookie:                    9859f832aff8f6c2

                Responder Cookie:               0000000000000000

Quick

An IPsec quick mode negotiation failed.

Local Endpoint:

                Network Address: ::

                Network Address mask:       0

                Port:                                        0

                Tunnel Endpoint:                  fd03:c8e4:6dc5:1000:65c3:ec29:19db:d27

Remote Endpoint:

                Network Address: fd03:c8e4:6dc5:7777::405a:e2f2

                Address Mask:                       0

                Port:                                        0

                Tunnel Endpoint:                  fd03:c8e4:6dc5:1000::1

                Private Address:                    0.0.0.0

Additional Information:

                Protocol:                                0

                Keying Module Name:         AuthIP

                Virtual Interface Tunnel ID:  0

                Traffic Selector ID: 0

                Mode:                                     Tunnel

                Role:                                       Initiator

                Quick Mode Filter ID:           148975

                Main Mode SA ID: 9

Failure Information:

                State:                                      Sent first (SA) payload

                Message ID:                           3

                Failure Point:                         Local computer

                Failure Reason:                      Main mode SA assumed to be invalid because peer stopped responding.

We can't be certain when this issue started, however we only noticed it yesterday when troubleshooting on a laptop.

Client is Windows 7 Enterprise with the Direct Access Connectivity Assistant (DACA) installed.

Starting from a power off situation we follow the following steps: 

* boot laptop on LAN, login, verify everything working, DACA reports "Corporate connectivity is working" (DACA is happy)

* undock laptop and wait for DA to kick in, verify everything working, DACA is happy

* re-dock laptop to LAN, verify everything working, DACA is happy

* undock laptop and wait for DA to kick in, verify everything working, DACA is happy

* re-dock laptop to LAN, verify everything working (i.e. can access internal network, drive shares working) ... and ...

after the 2nd re-dock, DACA reports "Corporate connectivity is NOT working" and despite the fact that everything is actually working, it stubbornly stays that way.

If we shutdown the laptop and restart, it returns to normal behaviour again, until the 2nd re-dock and then the problem repeats.

Hi 

My pc OS version is 10.0.17763 N/A build 17763. Currently the pc at home network always stay in ''connecting" status , I manage to collect log by navigating 'Network settings->DirectAccess->Troubleshooting info' , when hitting 'Collect' button , no new window pops up , I am not sure if the log is generated or not ? Please suggest me how to start to troubleshooting ? thanks!

in addition , on this pc I can not ping or nslookup any of the internal servers

/Michael

Hi, 

Another weird direct access issue :) Hopefully someone can help sorry for the long winded post. 

Direct access multi site setup and working great SERVER 2016 WINDOWS 10.... except when switching to a cellular connection the iphttps profile is only active for 1 minute. All ipsec tunnels are up, all apps work pings work and then the IP-HTTPS Adaptor turns off like something has cancelled the connection. A restart of the IP helper service brings the connection back again for 1 minute but then goes again. 

All DA commands show that the iphttps profile is not active. The firewall profile does not change, Antivirus and third party applications have been removed, tried different sim vendors, vodafone, three, O2 all the same. 

This only happens when connecting to cellular or tethering and it is repeatable. WIFI Connections work fine no issue. 

We have found if the laptop is cold booted straight to a cellular connection the direct access connection stays online until the connection is removed and then retried at which point we have the same issue. 

I noticed on a cold boot the internet connectivity warning exclamation mark was gone. I found 2 fixes 

1 - disabled the internet connection probe Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\NetworkConnectivityStatusIndicator\NoActiveProbe=0

2 - Change the DNS entry on the cellular connection to 8.8.8.8. 

So the issue appears to be something to do with the NCSI tests and split tunnelling. 

To add to this we have another direct access setup that uses forced tunnelling, clients using this direct access solution have all the same polices applied and NCSI does not seem to cause an issue, in fact the NCSI seems to fail for the first 5 minutes of the connection as the warning exclamation mark about no internet access hangs around. 

Could anyone shed any what direct access is doing when performing the NCSI test and why this may be different when using the cellular connection?

Should I add an NRPT Exemption for the NCSI Websites? www.MSFTNCSI.COM?

Why would the connection be ok when cold booting what am I missing?

Hopefully someone on tech net has seen something like this before its driving me mad. 

Hi, We're trying to move/ migrate a directaccess member server from a hyper-v host to a new VMware host. DA is setup with external NLB on F5. The migration it self seems to go fine but the DA server doesn't work. Most of the things in the operation staus is green exept for DNS, IP-HTTPS, Network adapters and services which have a blue exclamation mark. When going to configure server it says external and internal adapter: Not available. When trying to update the configuration it errors out with this message: Error: Modifying network adapters is not supported when Remote Access is deployed in a load balanced cluster.

Anyone have a clue have we can fix this?

Dave

We are testing out DirectAccess on 2016 in a lab and so far everything has been working pretty well. Clients are connecting in, getting GPO, accessing files shares, RDP works, etc. Inbound is great. However, outbound/manage out is proving to be a problem. I have gotten it to work a few times but it looks like I have DNS issues based on the behavior. In this scenario my manage out internal server is an SCCM system. I'd like to be able to remote control DA clients like we do internally.

I have a 2 NIC DirectAccess server in the DMZ. We NAT to the DMZ interface, 443 inbound. The interface also holds the default gateway (second NIC is blank on the gateway). It's configured to use certs + AD auth. We're not doing force tunnel (yet). My infrastructure server is the SCCM server in question. I have specified my internal domain search suffix as well. We have an NSL web server running internally as well.

For the manage out clients I have configured ISATAP using a DNS alias + GPO to enable it on the SCCM server. This appears to be working for the most part but this is where it gets murky.

I bring my DA system online. It registers in DNS on the domain controllers with the IPv6 address. At first I am completely unable to ping that system from SCCM. If I do an NSLOOKUP <client host name>. It resolves (doesn't matter if I use the host name or FQDN for nslookup). If I ping that hostname it will fail. If I ping the FQDN AFTER doing an NSLOOKUP it fails on the first attempt. If I ping it a second time it responds. This second ping situation happens pretty consistently. Sometimesafter pinging the FQDN successfully I can then ping the host name. If I leave it for awhile (15-30 minutes) I won't be able to ping anymore. I can then do the nslookup and repeat the process. Like there's some odd failure to cache long term. See below;

At this point it is very hit or miss if I will be able to remote control the client from SCCM. But one thing is consistent, if I remote control the host name it fails. If I manually type in the FQDN using the File > Connect option it generally work. That's why I don't believe it's firewall related. Though I have turned on logging dropped packets on the client just in case.

I saw this similar post but it dead ended. This gentleman was having a very similar remote control + FQDN issue.

I feel like we're close but need some help getting this last bit of DNS weirdness sorted out. Thanks in advance for any feedback.

Hello i got a simple da deployment. Everything looks fine it connect but cannot brose local resources or have internet access.

After check many things i have discovered that the public firewall is blocking the connectivity to local resources and internet. The weird thing is that it never request to identify the network, anyway its not related to networkProfile its related to firewal rules.

Do you know which rules are necesaries to connect by DA? i already have checked the ports and works fine with FW enabled and DA doesnt work. with FW disabled everything works as expected.

Any Idea? thanks in advance. Robert DL