Outlook Offline over DirectAccess on Windows 10

Outlook Offline over DirectAccess on Windows 10You 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.

Outlook Offline over DirectAccess on Windows 10

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

Outlook Offline over DirectAccess on Windows 10

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!

Leave a comment

17 Comments

  1. ioan

     /  November 28, 2017

    Hi Richard.
    The settings are overwritten only in one specific deployment scenario. This is happening on DA servers with only one network adapter.

    Reply
  2. Bernhard

     /  January 15, 2018

    Hi 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).

    Reply
    • Yes, 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!

      Reply
  3. Windows 7 clients seem exempted of this issue.

    Reply
  4. Anyway this enables also the connection of Skype for Business clients, together with Outlook. Thanks for sharing.

    Reply
  5. Chris

     /  February 17, 2018

    Hi 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

    Reply
    • That’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?

      Reply
  6. venkat

     /  February 27, 2018

    hi,
    thank you for great article our problem solved but in 2012 R2 this setting overwritten by GPO

    Reply
    • Yes, I’m aware that happens in some (but not all) deployment scenarios. I don’t have a workaround to suggest either, unfortunately. :/

      Reply
  7. Thank 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.

    Reply
  8. Nick

     /  July 20, 2018

    Hi 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

    Reply
    • Nick

       /  July 20, 2018

      Just 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.

      Reply
  9. Digging 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!

    Reply
    • Agreed, 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?

      Reply

Leave a Reply to venkat Cancel reply

%d bloggers like this: