Sign in
 
HomeProductsLibraryLearnDownloadsSupportForums
Microsoft Forefront TechCenter >
> 
> 
Bringing up a second UAG server for transition - it's not working

Answered Bringing up a second UAG server for transition - it's not working

  • Friday, December 14, 2012 1:56 AM
     
     
    Sign In to Vote
    0

    I've started the process of installing a new UAG server to replace the currently running one - we're only doing DirectAccess - and I'm running into a definite difficulty. The old one is meant to be kept running until I've moved the clients over to the new box.

    I've followed the steps in this blog (and asked a few questions, too) http://blog.msedge.org.uk/2011/11/limiting-isatap-services-to-uag.html.

    Now, however, when I run through the wizard at step 2 "DirectAccess Server", I find the Internet-facing IP ready, but on the Internal side, the dropdown list for the "Internal IPv4 address used..." is grayed out, and I can't use it. The dropdown for "Internal IPv6 address" can be populated, but when I choose the address that's listed (which is a link local address beginning with fe80::), I get this error message:

    "An external ISATAP router is already deployed in your organization. In order to avoid assymmetrical [sic] routing, disable the ISATAP interface on all of the Forefront servers, and create a native IPv6 route between the UAG server and the ISATAP router. Where native IPv6 connectivity is not available, a private 6to4 tunnel should be created between the UAG server and the ISATAP router."

    In addition, if I blow past that, by letting the IPv6 address populate the field, populate the GPOs and reboot to allow the UAG server to pick up the GPOs assigned, I don't see the ISATAP or IPHTTPS entries in 'ipconfig /all'.

    It's certainly possible that I've FUBARed the install on this machine, and willing to scratch it and start over, but if this is a known dead end, I'm going to have to re-think my approach.

    Kurt

     

All Replies

  • Friday, December 14, 2012 2:31 AM
     
     
    Sign In to Vote
    0

    No need to start over, I have seen this many times when bringing up a "production" box to replace a "poc" box. I believe we talked before on another post about the global use of ISATAP. You will need to put a kabosh on this before proceeding. Basically what is happening is that your old UAG box is your network's ISATAP router, and the new UAG box is setting itself up automatically as an ISATAP client. You need to stop this from happening, then re-run the UAG wizard and it will go back to normal.

    I assume you still have an "ISATAP" host record in DNS. Delete it. Either that or somehow this new UAG server is in the list you created from Jason's blog post and is being told to become an ISATAP client of the other box for some reason. Whatever the cause, you need to get this new UAG server to be the ISATAP router instead of being an ISATAP client. Then you'll need to reboot the new UAG server, re-launch UAG and you'll be back to IPv4 on that screen.

     
  • Friday, December 14, 2012 4:27 PM
    Moderator
     
     
    Sign In to Vote
    0
    You could put a fake isatap.domain.com entry in the hosts file on the new UAG server to prevent it from getting an IPv6 ISATAP address (and make sure it's not in the custom ISATAP GPO group too).

    Jason Jones | Microsoft MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk


     
  • Friday, December 14, 2012 7:51 PM
     
     
    Sign In to Vote
    0
    Update:
    I have eliminated isatap.example.com in my environment, and per the link mentioned previously I now have two isatap references in DNS (isatap-old and isatap-new). That eliminated the problem with the error message above.

    This has not solved all of my problems on the new machine, however, as I still am lacking any isatap, teredo or iphttps interfaces on the new machine. I've checked and rechecked the installation, and I'm not seeing what might be causing this.

    Kurt
     
  • Friday, December 14, 2012 7:54 PM
     
     
    Sign In to Vote
    0

    Populating the hosts file is an interesting thought. Might try that.

    The only group the new machine inhabits is the one I designated for UAG gateways, so I don't think that's an issue.

    Kurt

     
  • Friday, December 14, 2012 9:22 PM
     
     
    Sign In to Vote
    0
    You could put a fake isatap.domain.com entry in the hosts file on the new UAG server to prevent it from getting an IPv6 ISATAP address (and make sure it's not in the custom ISATAP GPO group too).

    Jason Jones | Microsoft MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk


    I put an entry for isatap in the hosts file on the new uag machine, using the new machine's internal ipv4 address, then rebooted. It was unhappy about that, giving the error message about a pre-existing isatap router. Eliminating that entry in the hosts file fixed that.

    Kurt

     
  • Friday, December 14, 2012 10:01 PM
    Moderator
     
     
    Sign In to Vote
    0
    It was meant to be a "fake" address that went nowhere so that the ISATAP adapter would not receive an address - maybe I wasn't clear enough, sorry

    Jason Jones | Microsoft MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk

     
  • Friday, December 14, 2012 10:39 PM
     
     
    Sign In to Vote
    0
    It was meant to be a "fake" address that went nowhere so that the ISATAP adapter would not receive an address - maybe I wasn't clear enough, sorry

    Jason Jones | Microsoft MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk

    Got it. I updated the hosts file with an RFC 1918 address that's not in use, and I'm not getting an error in the wizard regarding a preexisting isatap router. Still don't have any isatap, teredo or ip-https interfaces, though.

    Kurt

     
  • Saturday, December 15, 2012 3:40 AM
     
     
    Sign In to Vote
    0
    If you don't have interfaces it sounds like the GPO settings are not being applied yet. Are you allowing UAG to handle the management of the GPOs? Are you using new GPOs for the new server or trying to re-use the existing GPOs from the POC? I recommend using new GPOs to keep everything separate.
     
  • Sunday, December 16, 2012 11:18 PM
     
     
    Sign In to Vote
    0

    Jordan,

    It seemed pretty obvious to me that I should have new GPOs, so I did indeed create new empty ones for the new UAG server called DA1 (uag_da1_gateways, uag_da1_clients and uag_da1_applicationservers), and let the wizard populate them when clicking the Apply Policy button at the end.

    And, as expected, uag_da1_gateways shows in the output of gpresult /z on DA1. I double-checked and the wizard shows that the gateway GPO name is correct - uag_da1_gateways is the entry in the field for Gateway in the wizard, so it doesn't look as if I applied the wrong GPO to the unit.

    I'm sure I've done something silly to cause the problem, but for the life of me I can't figure it out.

    I've also double-checked the IP addresses, just to make sure the two machines don't overlap.

    Kurt

     
  • Monday, December 17, 2012 6:43 PM
     
     
    Sign In to Vote
    0

    More data - The working gateway configuration is running UAG SP1, with AFAICT no updates. The non-working configuration has UAG SP2 on it.

    Also I've done a comparison between the two GPOs for the UAG Gateways, and found at least one seemingly large difference, which I don't know how to interpret.

    Below, I'm quoting from from each GPO the section Policies\Windows Settings\Security Settings\Windows Firewall with Advanced Security\Connection Security Settings - note that Endpoint 1 in the working config has many more entries than the non-working config.

    Working GPO:

    Name Description
    UAG DirectAccess Gateway - Clients Access Enabling Tunnel - All Policies to enable access granting resources(DC, DNS, NAP, etc.) over IPsec. Generated on Thursday, 16 August 2012 22:11 UTC.
    This rule may contain some elements that cannot be interpreted by current version of GPMC reporting module
    Enabled True
    Authentication mode Require inbound and outbound
    Endpoint 1 2002:4332:7626:8001::c0a8:3d1f, 2002:4332:7626:8000:0:5efe:192.168.61.31, 2002:4332:7626:8001::c0a8:2615, 2002:4332:7626:8000:0:5efe:192.168.38.21, 2002:4332:7626:8001::c0a8:a0d, 2002:4332:7626:8000:0:5efe:192.168.10.13, 2002:4332:7626:8000:0:5efe:192.168.10.13, 2002:4332:7626:8001::c0a8:a0a, 2002:4332:7626:8000:0:5efe:192.168.10.10, 2002:4332:7626:8000:0:5efe:192.168.10.10, 2002:4332:7626:8001::c0a8:a63, 2002:4332:7626:8000:0:5efe:192.168.10.99, 2002:4332:7627::4332:7627
    Endpoint 2 Any
    Endpoint 1 port Any
    Endpoint 2 port Any
    First authentication {21723387-B217-4971-A94F-EC5B88942ED7}
    Second authentication {F20FF69E-0880-456C-A027-D10F5BB354C9}
    Data protection {4B947208-8DFE-4D8E-8ED6-C21715996854}
    Protocol Any
    Profile Private, Public
    Tunnel endpoint 1 Any
    Tunnel endpoint 2 Any
    Network interface type

    Any

    Non-working GPO:

    Name Description
    UAG DirectAccess Gateway - Clients Access Enabling Tunnel - All Policies to enable access granting resources(DC, DNS, NAP, etc.) over IPsec. Generated on Friday, 14 December 2012 01:24 UTC.
    This rule may contain some elements that cannot be interpreted by current version of GPMC reporting module
    Enabled True
    Authentication mode Require inbound and outbound
    Endpoint 1 2002:4332:7624:8001::c0a8:3d1f, 2002:4332:7624:8001::c0a8:2615, 2002:4332:7624:8001::c0a8:a0d, 2002:4332:7624:8001::c0a8:a0a, 2002:4332:7624:8001::c0a8:a63, 2002:4332:7625::4332:7625
    Endpoint 2 Any
    Endpoint 1 port Any
    Endpoint 2 port Any
    First authentication {4D965BD8-8C55-457E-9D52-62CD1213FB75}
    Second authentication {55E1858C-2F58-4C37-A552-5E2D38D291DA}
    Data protection {A560ADE7-B374-440C-9868-CBD6A5CDB263}
    Protocol Any
    Profile Private, Public
    Tunnel endpoint 1 Any
    Tunnel endpoint 2 Any
    Network interface type Any

    Kurt

     
  • Monday, December 17, 2012 9:06 PM
     
     
    Sign In to Vote
    0

    Ah, I think this clues us in a little. Those lists of IPv6 addresses are the "infrastructure" machines. The wizard automatically adds domain controllers and sccm servers into that list, and you can add your own if needed. This is the list of machines that needs to be available inside the first IPsec tunnel, prior to user authentication. You can see in the first list that you have some with "8001" in the middle and hex at the end, those are DNS64 addresses that have been created by the DirectAccess server, as they are IPv4 resources. However, the other ones with "8000" in the middle and the IPv4 address at the end - those are ISATAP hosts who have picked up IPv6 routing information from your old server.

    Since those machines, whatever they are, have picked up ISATAP IPv6 routing information from the old server, they are now preferring to communicate via IPv6 using ISATAP. Since your new machine is not part of the ISATAP or any IPv6 network, it cannot communicate with these servers. This could be your entire problem.

    I say you need to either force all of these internal ISATAP hosts to "swing" over to using the new server as their ISATAP router by pointing their ISATAP resolution at the internal IP of the new DirectAccess server, or you could make sure to remove their ability to resolve ISATAP to the old server (removing that ISATAP record in DNS if you haven't already), and then restart these servers and make sure they don't pick up any IPv6 address. Then re-run through the wizards on the new DirectAccess server, everything should now be IPv4-only, and this list of addresses should change over to all "8001"s.

     
  • Monday, December 17, 2012 9:57 PM
     
     
    Sign In to Vote
    0

    OK, sounds interesting

    There is no isatap.example.com record any more - I deleted it and put it on the DNS global block list. I substituted isatap-old for the pilot server, and have isatap-new for the new machine.

    Can you suggest a method to swing those IP addresses over?

    Also. how do you surmise that this affects the lack of interfaces on the new UAG server?

    Kurt

     
  • Monday, December 17, 2012 10:48 PM
    Moderator
     
     
    Sign In to Vote
    0

    From memory it takes a little while for the ISATAP addresses to age out after you disable it in DNS etc. You can force this using the sc control iphlpsvc paramchange command.

    Jason Jones | Microsoft MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk

     
  • Tuesday, December 18, 2012 1:59 PM
     
     
    Sign In to Vote
    0
    Yup, that command will do it. Also, restarting the IP Helper service or restarting the server typically clears it as well. And then even though the IP is cleared from the machine, doesn't necessarily mean that the IPv6 record is cleared out from DNS - you'll want to make sure that those ISATAP records that stuck themselves in your DNS also get cleared out, if they continue to sit there then the DirectAccess servers will continue to try and make use of them.
     
  • Tuesday, December 18, 2012 8:44 PM
     
     
    Sign In to Vote
    0

    OK - I've linked the GPO that contains the isatap-new address to the root of the domain. I'll check on it tomorrow, and see what's happened.

    I've also checked DNS, and the isatap address is gone - it's not listed in DNS, nor can any of the machines I tested ping it, so it's not cached anywhere..

    Kurt

     
  • Wednesday, December 19, 2012 10:10 PM
     
     
    Sign In to Vote
    0

    Still nothing.

    Here's my point of reference. I'm appending the output of 'ipconfig /all' for the two machines - pilot and production. Note that the pilot machine has many more interfaces listed than does the production machine. Given the discrepancy, I'm nearly ready to scratch the production machine and start the install process over again, unless I can find out why the difference and remedy it.

    To my understanding (which is probably limited) I don't see how an IP address for isatap would have an effect on bringing up those interfaces, if it does, why it's not affecting the pilot machine.

    Kurt

    Production Machine:
    Windows IP Configuration

       Host Name . . . . . . . . . . . . : DA1
       Primary Dns Suffix  . . . . . . . : example.com
       Node Type . . . . . . . . . . . . : Hybrid
       IP Routing Enabled. . . . . . . . : Yes
       WINS Proxy Enabled. . . . . . . . : No
       DNS Suffix Search List. . . . . . : example.com

    Ethernet adapter Local Area Connection* 9:

       Media State . . . . . . . . . . . : Media disconnected
       Connection-specific DNS Suffix  . :
       Description . . . . . . . . . . . : SSL Network Tunneling
       Physical Address. . . . . . . . . : 00-FF-08-01-19-47
       DHCP Enabled. . . . . . . . . . . : Yes
       Autoconfiguration Enabled . . . . : Yes

    Ethernet adapter External:

       Connection-specific DNS Suffix  . :
       Description . . . . . . . . . . . : Broadcom NetXtreme Gigabit Ethernet #2
       Physical Address. . . . . . . . . : 90-B1-1C-06-08-EC
       DHCP Enabled. . . . . . . . . . . : No
       Autoconfiguration Enabled . . . . : Yes
       Link-local IPv6 Address . . . . . : fe80::7491:2180:a18d:a196%12(Preferred)
       IPv4 Address. . . . . . . . . . . : 67.50.xxx.yy6(Preferred)
       Subnet Mask . . . . . . . . . . . : 255.255.255.0
       IPv4 Address. . . . . . . . . . . : 67.50.xxx.yy7(Preferred)
       Subnet Mask . . . . . . . . . . . : 255.255.255.0
       Default Gateway . . . . . . . . . : 67.50.xxx.yy1
       DHCPv6 IAID . . . . . . . . . . . : 311472412
       DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-18-33-27-49-90-B1-1C-06-08-EB
       DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1
                                           fec0:0:0:ffff::2%1
                                           fec0:0:0:ffff::3%1
       NetBIOS over Tcpip. . . . . . . . : Enabled

    Ethernet adapter Internal:

       Connection-specific DNS Suffix  . :
       Description . . . . . . . . . . . : Broadcom NetXtreme Gigabit Ethernet
       Physical Address. . . . . . . . . : 90-B1-1C-06-08-EB
       DHCP Enabled. . . . . . . . . . . : No
       Autoconfiguration Enabled . . . . : Yes
       Link-local IPv6 Address . . . . . : fe80::c856:a899:d109:cee5%11(Preferred)
       IPv4 Address. . . . . . . . . . . : 192.168.8.37(Preferred)
       Subnet Mask . . . . . . . . . . . : 255.255.255.0
       Default Gateway . . . . . . . . . :
       DHCPv6 IAID . . . . . . . . . . . : 244363548
       DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-18-33-27-49-90-B1-1C-06-08-EB
       DNS Servers . . . . . . . . . . . : 192.168.10.13
                                           192.168.10.10
       NetBIOS over Tcpip. . . . . . . . : Enabled

    Tunnel adapter 6TO4 Adapter:

       Connection-specific DNS Suffix  . :
       Description . . . . . . . . . . . : Microsoft 6to4 Adapter
       Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
       DHCP Enabled. . . . . . . . . . . : No
       Autoconfiguration Enabled . . . . : Yes
       IPv6 Address. . . . . . . . . . . : 2002:XXXX:YYY4::XXXX:YYY4(Preferred)
       IPv6 Address. . . . . . . . . . . : 2002:XXXX:YYY5::XXXX:YYY5(Preferred)
       Default Gateway . . . . . . . . . : 2002:c058:6301::1
       DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1
                                           fec0:0:0:ffff::2%1
                                           fec0:0:0:ffff::3%1
       NetBIOS over Tcpip. . . . . . . . : Disabled


    Pilot Machine:

    C:\Windows\system32>ipconfig /all

    Windows IP Configuration

       Host Name . . . . . . . . . . . . : G1
       Primary Dns Suffix  . . . . . . . : example.com
       Node Type . . . . . . . . . . . . : Hybrid
       IP Routing Enabled. . . . . . . . : Yes
       WINS Proxy Enabled. . . . . . . . : No
       DNS Suffix Search List. . . . . . : example.com

    Ethernet adapter Local Area Connection* 9:

       Media State . . . . . . . . . . . : Media disconnected
       Connection-specific DNS Suffix  . :
       Description . . . . . . . . . . . : SSL Network Tunneling
       Physical Address. . . . . . . . . : 00-FF-08-01-19-47
       DHCP Enabled. . . . . . . . . . . : Yes
       Autoconfiguration Enabled . . . . : Yes

    Ethernet adapter External:

       Connection-specific DNS Suffix  . :
       Description . . . . . . . . . . . : Broadcom BCM5708C NetXtreme II GigE (NDIS VBD Client) #2
       Physical Address. . . . . . . . . : 00-15-C5-EB-37-F4
       DHCP Enabled. . . . . . . . . . . : No
       Autoconfiguration Enabled . . . . : Yes
       Link-local IPv6 Address . . . . . : fe80::4484:e295:c4c7:2c7e%12(Preferred)
       IPv4 Address. . . . . . . . . . . : 67.50.xxx.yy8(Preferred)
       Subnet Mask . . . . . . . . . . . : 255.255.255.0
       IPv4 Address. . . . . . . . . . . : 67.50.xxx.yy9(Preferred)
       Subnet Mask . . . . . . . . . . . : 255.255.255.0
       Default Gateway . . . . . . . . . : 67.50.xxx.yy1
       DHCPv6 IAID . . . . . . . . . . . : 301995461
       DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-17-16-49-50-00-15-C5-EB-37-F2
       DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1
                                           fec0:0:0:ffff::2%1
                                           fec0:0:0:ffff::3%1
       NetBIOS over Tcpip. . . . . . . . : Enabled

    Ethernet adapter Internal:

       Connection-specific DNS Suffix  . :
       Description . . . . . . . . . . . : Broadcom BCM5708C NetXtreme II GigE (NDIS VBD Client)
       Physical Address. . . . . . . . . : 00-15-C5-EB-37-F2
       DHCP Enabled. . . . . . . . . . . : No
       Autoconfiguration Enabled . . . . : Yes
       Link-local IPv6 Address . . . . . : fe80::fc52:2ec5:a512:ab9e%11(Preferred)
       IPv4 Address. . . . . . . . . . . : 192.168.8.38(Preferred)
       Subnet Mask . . . . . . . . . . . : 255.255.255.0
       Default Gateway . . . . . . . . . :
       DHCPv6 IAID . . . . . . . . . . . : 234886597
       DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-17-16-49-50-00-15-C5-EB-37-F2
       DNS Servers . . . . . . . . . . . : 2002:XXXX:YYY6:8000:0:5efe:192.168.10.13
                                           2002:XXXX:YYY6:8000:0:5efe:192.168.10.10
                                           192.168.10.13
                                           192.168.10.10
       NetBIOS over Tcpip. . . . . . . . : Enabled

    Tunnel adapter 6TO4 Adapter:

       Connection-specific DNS Suffix  . :
       Description . . . . . . . . . . . : Microsoft 6to4 Adapter
       Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
       DHCP Enabled. . . . . . . . . . . : No
       Autoconfiguration Enabled . . . . : Yes
       IPv6 Address. . . . . . . . . . . : 2002:XXXX:YYY6::XXXX:YYY6(Preferred)
       IPv6 Address. . . . . . . . . . . : 2002:XXXX:YYY7::XXXX:YYY7(Preferred)
       Default Gateway . . . . . . . . . : 2002:c058:6301::1
       DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1
                                           fec0:0:0:ffff::2%1
                                           fec0:0:0:ffff::3%1
       NetBIOS over Tcpip. . . . . . . . : Disabled

    Tunnel adapter Teredo Tunneling Pseudo-Interface:

       Connection-specific DNS Suffix  . :
       Description . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface
       Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
       DHCP Enabled. . . . . . . . . . . : No
       Autoconfiguration Enabled . . . . : Yes
       Link-local IPv6 Address . . . . . : fe80::8000:f227:bccd:89d9%15(Preferred)
       Default Gateway . . . . . . . . . :
       NetBIOS over Tcpip. . . . . . . . : Disabled

    Tunnel adapter isatap.{A83F3F47-71EA-4870-864C-BC57AC71AA19}:

       Connection-specific DNS Suffix  . :
       Description . . . . . . . . . . . : Microsoft ISATAP Adapter
       Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
       DHCP Enabled. . . . . . . . . . . : No
       Autoconfiguration Enabled . . . . : Yes
       IPv6 Address. . . . . . . . . . . : 2002:XXXX:YYY6:8000:0:5efe:192.168.8.38(Preferred)
       Link-local IPv6 Address . . . . . : fe80::5efe:192.168.8.38%16(Preferred)
       Default Gateway . . . . . . . . . :
       DNS Servers . . . . . . . . . . . : 2002:XXXX:YYY6:8000:0:5efe:192.168.10.13
                                           2002:XXXX:YYY6:8000:0:5efe:192.168.10.10
                                           192.168.10.13
                                           192.168.10.10
       NetBIOS over Tcpip. . . . . . . . : Disabled

    Tunnel adapter isatap.{27EB1E5E-72E6-4FCD-8203-DBA613E6F6EF}:

       Connection-specific DNS Suffix  . :
       Description . . . . . . . . . . . : Microsoft ISATAP Adapter #2
       Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
       DHCP Enabled. . . . . . . . . . . : No
       Autoconfiguration Enabled . . . . : Yes
       Link-local IPv6 Address . . . . . : fe80::200:5efe:67.50.xxx.yy8%17(Preferred)
       Link-local IPv6 Address . . . . . : fe80::200:5efe:67.50.xxx.yy9%17(Preferred)
       Default Gateway . . . . . . . . . :
       DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1
                                           fec0:0:0:ffff::2%1
                                           fec0:0:0:ffff::3%1
       NetBIOS over Tcpip. . . . . . . . : Disabled

    Tunnel adapter IPHTTPSInterface:

       Connection-specific DNS Suffix  . :
       Description . . . . . . . . . . . : IPHTTPSInterface
       Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
       DHCP Enabled. . . . . . . . . . . : No
       Autoconfiguration Enabled . . . . : Yes
       IPv6 Address. . . . . . . . . . . : 2002:XXXX:YYY6:8100:9db4:b4b8:4d8e:a50d(Preferred)
       Link-local IPv6 Address . . . . . : fe80::9db4:b4b8:4d8e:a50d%18(Preferred)
       Default Gateway . . . . . . . . . :
       NetBIOS over Tcpip. . . . . . . . : Disabled

    Tunnel adapter isatap.{7951B562-0418-4B0E-9C81-C33A07929FF2}:

       Media State . . . . . . . . . . . : Media disconnected
       Connection-specific DNS Suffix  . :
       Description . . . . . . . . . . . : Microsoft ISATAP Adapter #3
       Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0
       DHCP Enabled. . . . . . . . . . . : No
       Autoconfiguration Enabled . . . . : Yes

     
  • Friday, December 21, 2012 1:56 PM
     
     
    Sign In to Vote
    0

    You should definitely have more interfaces on your Production machine, once it has activated successfully. So there is still a question of whether there is just something wrong with this box (in which case starting over would probably be best) or if there is still some GPO filtering issue where the GPO settings for Production are either not making their way into the GPOs successfully, or not making their way back down to the new server successfully. I wouldn't expect any IP-HTTPS adapters to show themselves until you have had a successful application of settings and a successful final activation, turning DA live on that new server.

    No, this shouldn't have much to do with your ISATAP configuration (except that when ISATAP was enabled globally and your new server grabbed an ISATAP address from the Pilot, that was a big problem)

    We have been focusing on ISATAP because even if you get these adapters to show up, if you have ISATAP addresses hanging around that were handed out by the Pilot server, those internal resources are not going to be available to your DirectAccess computers coming in through the Production box, so either now or later, the ISATAP stuff has to be worked out.

     
  • Saturday, December 22, 2012 12:50 AM
     
     
    Sign In to Vote
    0

    OK...

    I'm off on vacation now until after the 1st. I'll put this at the top of my list as soon as I get back.

    Anything you think I can check on when I get back to see if the GPO settings are being applied?

    Thanks,

    Kurt

     
  • Sunday, December 23, 2012 12:43 PM
     
     
    Sign In to Vote
    0
    Start with some gpresult commands on both servers and compare them. Also, you can open the Gateways GPOs themselves in Group Policy Management Console and compare the actual settings, make sure it looks like the new ones are really being populated fully, or if perhaps something is going wrong during the script that creates those objects.
     
  • Tuesday, January 22, 2013 12:58 AM
     
     Answered
    Sign In to Vote
    0

    My apologies for not getting back to this sooner.

    I got terribly frustrated with the process, and under pressure from management I've done a P2V and placed the VM on ESXi 5.1, using the machine that was supposed to be the production server.

    It is now the production server, but running the VM of the pilot machine - getting the P2V done worked well and relatively quickly, once I installed the newest VMware standalone converter on the DA machine.

    Kurt

    • Marked As Answer by KurtBuff Tuesday, January 22, 2013 12:58 AM
    •