locked
DirectAccess Disabled Network Binding after V2V RRS feed

  • Question

  • HI

    I am using Directaccess on my Xen Server and its working fine. 

    the current Remote Access Server Setup are (Behind an Edge Device (With Two network Adapters)

    Recently I migrated DA to VMWare ESXi

    I reconfigure the drivers and IP/Routes and the server is reachable and seems to be OK

    but directaccess is not working.

    when I open the DA Console \ Remote Access Setup I notice the following

    The Default option is Behind an Edge Device (with a Single Network adapter) and the options are disabled. 

    The Server have 2 Network interface and the drivers and the tools are installed.

    what should i do to correct this behavior.

    Tuesday, January 10, 2017 12:01 PM

Answers

  • This is the answer. 

    Yes the only thing I dont want is to call all the user back in order to update the policy

    Here what I did, after checking that is stored in the GPO. I notice that DA is depending on the GUID for the network interface, so after migration, DA cannot apply the GPO cause GUID stored in the "Extra Registry Settings"

    Software\Policies\Microsoft\Windows\RemoteAccess\Config\MachineSIDs\SOME SID\Internalinterface
    Software\Policies\Microsoft\Windows\RemoteAccess\Config\MachineSIDs\SOME SID\Internetinterface

    is not matching with the new one. So I used the PS command to get the new GUID

    Get-WmiObject -Query "select * from win32_networkadapter" | select GUID,NetConnectionID | where {$_.GUID -notlike $null} | ft -AutoSize

    backup the DirectAccess Server Settings, Edit the Registry.pol using Registry Workshop Application and update the InternalInterface - InternetInterface GUID with the new ones, save and import the GPO again to the server. 

    Force Policy update and I have it again back running and healthy :)

    head ache, but worth it. I can not take the risk of having it fail or crash.

    • Marked as answer by Tony Anuas Friday, January 13, 2017 9:23 AM
    Friday, January 13, 2017 9:23 AM

All replies

  • You will probably end up having to wipe out the DA config and re-run through the wizards. It only takes 10 or 15 minutes to do this, so it's not worth messing around with anything else for too long.

    The reason is that when you configure DA is has information that is specific to the NICs in the server upon which you set it up. Now that you have migrated to a new platform, you are running new NICs (to the operating system's eyes) - and DA is confused.

    In the Configuration section, the top-right action should be "Remove Configuration" - make sure you have all the info from inside the wizards before you do this, because doing this will wipe them all out, and it will even delete the GPOs. Then I would check over all of your NIC settings just to make sure they are correct. Then re-run through the DirectAccess setup wizards which will re-create new GPOs with the new settings that are appropriate for this server.

    Unfortunately you might be stuck in a situation where your users to come into the office in order to get a group policy update before they will be able to connect again. It's hard to say with something like this. It is possible that when you get it back up and running, assuming you are using the exact same public DNS name and same public IP addressing, that they may just pick up and start connecting on their own again, but there is a chance that they will not and will need a GP update before they can connect.

    Wednesday, January 11, 2017 1:54 PM
  • This is the answer. 

    Yes the only thing I dont want is to call all the user back in order to update the policy

    Here what I did, after checking that is stored in the GPO. I notice that DA is depending on the GUID for the network interface, so after migration, DA cannot apply the GPO cause GUID stored in the "Extra Registry Settings"

    Software\Policies\Microsoft\Windows\RemoteAccess\Config\MachineSIDs\SOME SID\Internalinterface
    Software\Policies\Microsoft\Windows\RemoteAccess\Config\MachineSIDs\SOME SID\Internetinterface

    is not matching with the new one. So I used the PS command to get the new GUID

    Get-WmiObject -Query "select * from win32_networkadapter" | select GUID,NetConnectionID | where {$_.GUID -notlike $null} | ft -AutoSize

    backup the DirectAccess Server Settings, Edit the Registry.pol using Registry Workshop Application and update the InternalInterface - InternetInterface GUID with the new ones, save and import the GPO again to the server. 

    Force Policy update and I have it again back running and healthy :)

    head ache, but worth it. I can not take the risk of having it fail or crash.

    • Marked as answer by Tony Anuas Friday, January 13, 2017 9:23 AM
    Friday, January 13, 2017 9:23 AM