DirectAccess IP-HTTPS Not Working Properly in Windows Server 2019

After installing and configuring DirectAccess in Windows Server 2019 you may encounter an error message indicating that IP-HTTPS is not working properly. Looking at the Operations Status overview in the Dashboard of the Remote Access Management console shows that the IP-HTTPS interface is in error.

DirectAccess IP-HTTPS Not Working Properly in Windows Server 2019

IP-HTTPS Route Error

Viewing the detailed Operations Status shows the following error message.

Error: The IP-HTTPS route does not have published property enabled.

DirectAccess IP-HTTPS Not Working Properly in Windows Server 2019

Missing Route

Looking at the routing table on the DirectAccess server reveals that a route to the client IPv6 prefix is indeed missing.

DirectAccess IP-HTTPS Not Working Properly in Windows Server 2019

Resolution

To resolve this error message, add the client IPv6 route to the DirectAccess server’s routing table and publish it. This is accomplished by running the following PowerShell commands on the DirectAccess server.

$IPv6prefix = (Get-RemoteAccess).ClientIPv6Prefix
New-NetRoute -AddressFamily IPv6 -DestinationPrefix $IPv6prefix -InterfaceAlias “Microsoft IP-HTTPS Platform Interface” -Publish Yes

Next, restart the Remote Access Management service (RaMgmtSvc) using the following PowerShell command.

Restart-Service RaMgmtSvc -PassThru

DirectAccess IP-HTTPS Not Working Properly in Windows Server 2019

Once complete, refresh the management console and the IP-HTTPS error message should be resolved and the operations status should state that it is now working properly.

DirectAccess IP-HTTPS Not Working Properly in Windows Server 2019

 

Additional Information

SSL Certificate Conisderations for DirectAccess IP-HTTPS

DirectAccess Expire IP-HTTPS Certificate and Error 0x800b0101

Leave a comment

21 Comments

  1. Glad they didn’t deprecate DirectAccess on Win Server 2019 yet. 🙂

    Reply
    • You and a lot of other folks I’m sure! Gives Microsoft some time to get Always On VPN sorted. 🙂

      Reply
      • Hey Rich, this worked fine on our first DA server but for the second one in the cluster, the route adds but then removes itself when you restart RaMgmtSvc or the server. I can re-publish it but I cant get it to stick.

        Tried using PoSH and netsh, for some odd reason it’s removed when the service reboots, any idea?

      • Thanks for the heads up. Suspected that might happen. I just did some quick testing with a single server and didn’t see any issues. For now you’ll have to keep re-applying the missing route until a fix is available. FYI, Microsoft is aware of the problem and working to address it. I’ll be sure to update the post when it’s available.

  2. Grigori

     /  March 5, 2019

    I have the same problem, first server works perfect, but when I add the second one after reboot of RaMgmtSvc route disappears.

    Reply
    • Yes, this workaround only seems to work for single server deployments. Hopefully Microsoft will release an update for this soon. 🙂

      Reply
  3. Bradley

     /  March 29, 2019

    We have a SingleSite setup. Getting this issue. Ran the fix as described

    PS C:\Windows\system32> $IPv6prefix = (Get-RemoteAccess).ClientIPv6Prefix New-NetRoute -AddressFamily IPv6 -DestinationP
    refix $IPv6prefix -InterfaceAlias “Microsoft IP-HTTPS Platform Interface” -Publish Yes
    At line:1 char:51
    + … IPv6prefix = (Get-RemoteAccess).ClientIPv6Prefix New-NetRoute -Addres …
    + ~~~~~~~~~~~~
    Unexpected token ‘New-NetRoute’ in expression or statement.
    + CategoryInfo : ParserError: (:) [], ParentContainsErrorRecordException
    + FullyQualifiedErrorId : UnexpectedToken

    Reply
    • Looks like you’re trying to run all of this as a single command. It is actually two commands. The “New-NetRoute” command is a separate command and should be run on its own after you run the first line. 🙂

      Reply
  4. Ryan

     /  May 16, 2019

    When I run the second command, I get an error:
    New-NetRoute : Invalid parameter InterfaceAlias Microsoft IP-HTTPS Platform Interface
    At line:2 char:1
    + New-NetRoute -AddressFamily IPv6 -DestinationPrefix $IPv6prefix -Inte …
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : InvalidArgument: (MSFT_NetRoute:ROOT/StandardCimv2/MSFT_NetRoute) [New-NetRoute], CimException
    + FullyQualifiedErrorId : Windows System Error 87,New-NetRoute

    Should I substitute “Microsoft IP-HTTPS Platform Interface with IPHTTPSInterface, instead? No quotes?

    Reply
    • This issue was fixed recently,, so instead of running this PowerShell command I’d suggest running Windows Update on the server and getting all of the latest updates.

      Reply
      • Mark

         /  June 6, 2019

        I have a comparable issue even with fully patched Windows Server 2019:

        (Variable IPv6prefix sets correctly)

        PS C:\Users\Administrator.COMPANY> New-NetRoute -AddressFamily IPv6 -DestinationPrefix $IPv6prefix -InterfaceAlias “Microsoft IP-HTTPS Platform Interface” -Publish Yes
        New-NetRoute : Element not found.
        At line:1 char:1
        + New-NetRoute -AddressFamily IPv6 -DestinationPrefix $IPv6prefix -Inte …
        + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        + CategoryInfo : ObjectNotFound: (MSFT_NetRoute:ROOT/StandardCimv2/MSFT_NetRoute) [New-NetRoute], CimException
        + FullyQualifiedErrorId : Windows System Error 1168,New-NetRoute

      • If you have a fully updated Windows Server 2019 system you should not need to run the PowerShell command referenced in this article. This issue has been fixed. I’m surprised it doesn’t run though. And no idea why you would get an “element not found” error. Curious to know if the command works on other interfaces?

  5. Luke

     /  June 7, 2019

    “element not found” error, there could by 2 reasons, I saw both personally in my previous deployment.

    1. InterfaceAlias is NOT “Microsoft IP-HTTPS Platform Interface”, usually it is ‘IPHTTPSInterface”. You can find interface name by doing: netsh int ipv6 show int

    2. Or it means IPv6 is not enabled on the server. this could be caused by GPO setting that somehow disabled IPv6 on the server, you will need to enable IPv6 on that server.

    But you shouldn’t need to run this PowerShell command, Ipv6 route should be published automatically

    Reply
  6. Franz Schenk

     /  March 9, 2020

    Thank you for this valuable post with the script!
    Have installed February 2020 cumulative update, and the issue isn’t fixed from Microsoft.

    Reply
    • That’s strange, because I’ve built a few Windows Server 2019 DirectAccess servers recently in my lab and didn’t have this issue. I assumed it had been addressed. :/

      Reply
  7. Hi Richard M. Hicks.
    I am korean ms engineer.
    Your advice is good to my trouble is solved
    Thank you your advice

    Reply
  8. Richard Marder

     /  June 1, 2020

    Hi Richard
    I had this issue on DA servers which are setup Network Load Balanced (Windows). I corrected as above but clients are not getting IP6 address which I think is because there is no prefix published in router advertisement on the IP-HTTPs Interface. The IPv6prefix from query above in my case is /59. Do I publish the same prefix in the router advertisement on the interface of each server or should these be different?

    Regards
    Richard

    Reply
    • These issues have been resolved by Microsoft so you shouldn’t have to do anything manually. However, you need to make sure that Windows Server 2019 is fully updated *before* installing/configuring DirectAccess. If you want to try to fix this without rebuilding your servers, you can try publishing the /59 to see if that resolves the issue.

      Reply
  9. Gary Buttrey

     /  July 29, 2020

    I have the error on a 2016 DA server. Any suggestions on how to resolve it? the above commands fail

    Thanks!

    Reply
    • This post is for an issue specific to Windows Server 2019. If you are having the problem on Windows Server 2016 it is most likely related to something else. What that is I don’t know, unfortunately.

      Reply

Leave a Reply to Luke Nie Cancel reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: