DirectAccess Troubleshooting and the Windows 10 Network Connectivity Assistant
NCA
The DirectAccess NCA can be accessed by pressing the Windows Key + I and then clicking on Network & Internet and DirectAccess. Here you’ll find a helpful visual indicator of current connectivity status, and for multisite deployments you’ll also find details about the current entry point.
DirectAccess Missing?
If DirectAccess does not appear in the list, open an elevated PowerShell window and restart the Network Connectivity Assistant service [NcaSvc] using the following command.
Restart-Service NcaSvc
If you receive the error “Failed to start service ‘Network Connectivity Assistant [NcaSvc]‘”, ensure that the client operating system is Enterprise or Education edition. The NCA service will always fail to start on Professional edition as it is not a supported DirectAccess client.
Log Collection
The DirectAccess NCA also provides access to crucial troubleshooting information. Clicking on the Collect button creates a detailed diagnostic log file that is often helpful for troubleshooting DirectAccess connectivity issues.
Troubleshooting Info Missing?
The option tocollect a log, and email it to your IT admin will only bedisplayed if a support email address is defined in the DirectAccess configuration. To define a support email address, open the Remote Access Management console and perform the following steps.
1. Click Edit on Step 1.
2. Click Network Connectivity Assistant.
3. Enter an email address in the Helpdesk email address field.
4. Click Finish to complete Step 1.
5. Click Finish to apply the changes.
Email Program
Microsoft assumes that an end user will be generating the DirectAccess client troubleshooting log and will be emailing them to their administrator. If an email program is not installed on the client, the following information is displayed.
There is no email program associated to perform the requested action. Please install an email program or, if one is already installed, create an associate in the Default Programs control panel.
If you wish to simply view the log file on the client and not email them, you can find the generated DirectAccess troubleshooting log file in HTML format in the following location.
%SystemDrive%\Users\%Username%\AppData\Local\Temp
Unable to Generate Log Files
There are numerous reports that generating the DirectAccess troubleshooting log fails on Windows 10 v1709. DirectAccess administrators have been reporting that the process seems to fail during the creation of the log file, leaving it truncated and incomplete. To resolve this issue, open an elevated PowerShell window and enter the following command.
New-ItemProperty -Path “HKLM:\SYSTEM\CurrentControlSet\Services\NcaSvc\” -Name SvcHostSplitDisable -PropertyType DWORD -Value 1 -Force
The computer must be restarted for this change to take effect. If initial testing of this workaround is successful, the registry setting can be pushed out to all DirectAccess clients using Active Directory Group Policy Preferences.
Additional Information
Installing and Configuring DirectAccess Connectivity Assistant 2.0 on Windows 7 Clients
Planning and Implementing DirectAccess with Windows Server 2016 Video Training Course on Pluralsight
Managing and Supporting DirectAccess with Windows Server 2016 Video Training Course on Pluralsight
Implementing DirectAccess with Windows Server 2016 Book
Share this:
- Tumblr
Like this:
Like Loading...
16 Comments
by Richard M. Hicks on March 15, 2018 • PermalinkPosted in DirectAccess, enterprise mobility, multisite, NCA, network connectivity assistant, PowerShell, Remote Access, troubleshooting, Windows 10, Windows 8.1
Tagged DirectAccess, enterprise mobility, log, log collection, log file, NCA, ncasvc, network connectivity assistant, PowerShell, Remote Access, troubleshooting, Windows 10, Windows 7, Windows 8.x
Posted by Richard M. Hicks on March 15, 2018
//directaccess.richardhicks.com/2018/03/15/directaccess-troubleshooting-windows-10-network-connectivity-assistant/
Problem
When attempting to check Direct Access connection status on a Windows 8 client machine with a Get-DaConnectionStatus command you see the following error;
Get-DaConnectionStatus : Network Connectivity Assistant service is stopped or not responding.
OK, so lets go and check the status of that service, if it starts great, but mine did not as you can see.
And it logged an Event ID 7024
The Network Connectivity Assistant service terminated with the following service-specific error:
The request is not supported.
Note: This will also happen if you have not configured Remote Access properly on your server, and the client has not got the necessary group policies applied, so make sure that’s discounted first!
“The [Service name] Service on Local Computer Started and Then Stopped. Some Services Stop Automatically If They Are Not in Use By Other Services or Programs” – Windows Error Message [TEKLYNX Software]
Bookmark[0]
Please login to bookmark
Username or Email Address
Password
Remember Me
9 Replies
· · ·
Mace
OP
Oct 9, 2015 at 15:15 UTC
Is the issue random? or is it usually around X time a day?
The reason I ask, is my buddy has an older SQL server that when it runs backups it disconnects due to load. He gets to replace it this year so he's excited.
0
· · ·
Poblano
OP
Oct 9, 2015 at 15:18 UTC
It's random.
0
· · ·
Datil
OP
Oct 9, 2015 at 16:00 UTC
Why is it applying group policies randomly? I usually only see it apply them at startup.
Another place to look would be Windows update...do you have set to look for updates?
0
· · ·
Datil
OP
Oct 9, 2015 at 16:03 UTC
When did this start happening? did you make any changes recently?
If your SQL server is on a physical server, check the NIC.
0
· · ·
Poblano
OP
Oct 9, 2015 at 16:18 UTC
I don't know of anything that changed when it started happening, that would have been the first thing I checked.
Applying group policy isn't random, its every 15 mins,
I causes the problem randomly, once or twice a day.
I don't think It is the NIC, [or any hardware] we failed over the secondary server and still see the problem.
0
· · ·
Mace
OP
Oct 9, 2015 at 16:31 UTC
justin22 wrote:
I don't know of anything that changed when it started happening, that would have been the first thing I checked.
Applying group policy isn't random, its every 15 mins,
I causes the problem randomly, once or twice a day.I don't think It is the NIC, [or any hardware] we failed over the secondary server and still see the problem.
15 min seems like a really short update interval.
Is there a reason its so low? If it is pushing a large amount of info each refresh I could see the possibility of it GPOs being the issue. Or possible a load issue on the DC.
Default is 90 minutes with a random 30 minute window added to it.
0
· · ·
Poblano
OP
Oct 9, 2015 at 16:50 UTC
Someone before me must have changed it,
It doesn't need to be any more frequent than default.
It may be worth changing back if I can't find the real fix,
I would think it would make the errors 6x less frequent at least.
But our DCs are not over stressed, Typical CPU and network load are maybe 1%.
I also doubtGP data is stressing ourSQL server much,
The hardware isless than a year old, with 10Gbe connection between it and our VM's including the DC.
0
· · ·
Mace
OP
Oct 9, 2015 at 16:56 UTC
I would also go through and check GPOs for any weird policy preferences and scripts. Those two can cause odd behavior sometimes.
0
· · ·
Poblano
OP
Best Answer
Nov 2, 2015 at 14:46 UTC
I setup a static route between SQL and the webservers,
And the errors went away.
I'm guessing our load balancer was messing it up somehow,
But I'm not sure why it started happening all of a sudden.
~Justin
0
This topic has been locked by an administrator and is no longer open for commenting.
To continue this discussion, please ask a new question.