You may encounter a scenario in which Outlook on Windows 10 reports that it is working offline while connected remotely via DirectAccess. The Network Connectivity Status Indicator (NCSI) shows DirectAccess is in a connected state and all other internal resources are accessible.
This is caused by the default settings of the IP-HTTPS tunnel interface on the DirectAccess server not advertising a default route for connected DirectAccess clients. To resolve this issue, enable default route advertising for IP-HTTPS on each DirectAccess server in the enterprise by running the following PowerShell command.
Get-NetIPInterface | Where-Object {$_.InterfaceAlias -eq “IPHTTPSInterface”} | Set-NetIPInterface -AdvertiseDefaultRoute Enabled -PassThru
In the past I’ve heard reports of this setting being overwritten after group policy refresh. Recent testing on Windows Server 2016 does not show this behavior, however. Please report any results you may have in the comments below. Thanks!
ioan
/ November 28, 2017Hi Richard.
The settings are overwritten only in one specific deployment scenario. This is happening on DA servers with only one network adapter.
Richard M. Hicks
/ November 29, 2017Ok, good to know. Was this on Windows Server 2012 R2 or Windows Server 2016 that you noticed this behavior?
Bernhard
/ January 15, 2018Hi Richard! We found out, that the settings are overwritten by a task called RaConfigTask (Microsoft\Windows\RemoteAccess). We wrote a powershell script, that is triggered by event-id 10018. This script contains only the following line: netsh int ipv6 set int xx advertisedefaultroute=enabled (xx is the index of the IPHTTPSInterface).
Richard M. Hicks
/ January 18, 2018Yes, the RaConfigTask task essentially forces a reapplication of GPOs, which obviously overwrites the changes we make to the server directly. Glad you were able to come up with a workaround though!
lonblu
/ January 18, 2018Windows 7 clients seem exempted of this issue.
lonblu
/ January 18, 2018Anyway this enables also the connection of Skype for Business clients, together with Outlook. Thanks for sharing.
Richard M. Hicks
/ January 18, 2018Good to know!
Chris
/ February 17, 2018Hi Richard
we’ve the problem that MS Outlook will prompt the user for their credentials each time if the network connection was(shortly) lost(for example suspend mode, inactive user,…). I can click “save the credentials” but it will not work. So i closed the client and start it again. Any idea?
Thanks Chris
Richard M. Hicks
/ February 17, 2018That’s unusual and I’ve never encountered that scenario myself. To me it sounds like a Kerberos ticket is expiring, but I have no idea why momentarily losing network connectivity would cause that. Perhaps it is an authentication setting specific to Outlook that forces reauthentication?
venkat
/ February 27, 2018hi,
thank you for great article our problem solved but in 2012 R2 this setting overwritten by GPO
Richard M. Hicks
/ February 28, 2018Yes, I’m aware that happens in some (but not all) deployment scenarios. I don’t have a workaround to suggest either, unfortunately. :/
Paul Oswald (IT) (@OswaldPaul)
/ April 23, 2018Thank you. We have had a working DirectAccess deployment for over 5 years, but due to a security limitation had to implement forced tunnelling last week which broke Outlook – this worked a treat to resolve.
Nick
/ July 20, 2018Hi Richard,
The fact that this setting gets wiped out with a gpupdate is caused because every time gpsvc runs an update, RaConfigTask also runs. This clears out the AdvertiseDefaultRoute.
For 2012r2 this occurs and in 2016 this has been mitigated looks like as you mentioned.
For 2012r2 you can go open event viewer > remoteaccess-remoteaccessserver > operational
Find event ID 10018 and this is the complete event for RaConfigTask
Right click – attach task to this event
Start a program
powershell.exe
Start in location (choose any location you want to save your script to such as c:\scripts)
Arguments – .\AdvertiseDefaultRoute.ps1
Choose the check box to to open properties after this
Check the following boxes:
Run whether user is logged on or not
Run with highest privileges
Click ok
Navigate to your directory you specified earlier
Create a new text file and put this in there:
Get-NetIPInterface | Where-Object {$_.InterfaceAlias -eq “IPHTTPSInterface”} | Set-NetIPInterface -AdvertiseDefaultRoute Enabled -PassThru -PolicyStore ActiveStore
Get-NetIPInterface | Where-Object {$_.InterfaceAlias -eq “IPHTTPSInterface”} | Set-NetIPInterface -AdvertiseDefaultRoute Enabled -PassThru -PolicyStore PersistentStore
Restart-Service iphlpsvc
File > save-as . AdvertiseDefaultRoute.ps1
Run gpupdate /force and then check your AdvertiseDefaultRoute status:
Get-NetIPInterface | Where-Object {$_.InterfaceAlias -eq “IPHTTPSInterface”} | fl * | findstr “AdvertiseDefaultRoute”
Hope this helps someone
Nick
/ July 20, 2018Just to add as I see that someone else detailed this already.
The reason I chose this way of doing it is because when using netsh and relying in the if index, I have found that sometimes this does not resolve the issue as the IPHTTPS if index can change.
Richard M. Hicks
/ July 20, 2018Not exactly an elegant solution, but if it works you that’s all you can ask for! 🙂
Ronan Fahy
/ April 20, 2021Digging up an old article i know, but if anyone knows the answer, you will 😉
We have a Force Tunnel deployment running happily for years. We’ve moved users from the original Force Tunnel enabled 2016 server to 2019 Force Tunnel no problem. We also have a “Test” server also 2019 with Force Tunnel disabled i.e. split tunneling. When we move devices across to that we see about 50% of clients have frequent, as in up to 30 times a day, disconnects. By disconnects, i mean they see Skype for Business drop, they see Outlook go into offline / not connected mode, they usually retain share drive access, and usually the NCSI connectivity status indicator will switch to no internet.
This onlly happens if the remote client is on Wifi, never Wired. We considered roaming aggressiveness as a cause but are dubious, as the only thing that changed was force tunnel –> split tunnel, the devices, are the same.
We apply a . any rule in the NRPT to specify a proxy server.
We had issues with NCSI years ago and had disabled active probing, this was fine until we discovered that devices that were upgraded from prior releases to 20H2 would then show no internet all the time. So had to reenable active probing.
NCSI seems to be involved, and seems to be very flakey.
Wondering have you or any of your readers had this experience with clients shifting from force tunnel to split tunnel deployments?
thanks!
Richard M. Hicks
/ April 23, 2021Agreed, NCSI is likely the cause. From experience, I can tell you that NCSI always seems to be unstable/unreliable when a proxy server is configured. If you try removing the proxy configuration is it more stable?