none
External IP Address Change and Direct Access Clients RRS feed

  • Question

  • We are in the process of migrating our internet connection and I am investigating the best way to migrate our UAG Standalone server with minimal disruption to our direct access clients most of whom are not based in the same country so I can't just recall the laptops and plug them in to the internal network.

    I know that changing the external IP address is not supported and that I might have to rebuild the UAG server. If I have to rebuild I will be using exactly the same settings as are currently running with the exception of the changed IP addresses.

    Looking at the policies that UAG deploys it looks like the current external IP is referenced in the UAG DirectAccess: Client GPO as well as the FQDN.

    Will I be able to change the external IP address of the UAG server and the DA clients connect in to pick up any updated GPOs or am I going to have to look at getting some sort of VPN up and running to allow them to connect first?

    Could I create a local policy on a template PC to export and import on the DA clients by sending a backup policy out via email?

    Any help would be greatly appreciated. Hopefully Microsoft will get something up on Technet at some point soon to cover this kind of scenario as I'm sure they must realise that networks change over time.

    Thanks in adance

    Darren


    Darren
    Tuesday, March 29, 2011 1:17 PM

Answers

  • You can definitely make the change without needing to rebuild the server. Should be as simple as changing the IP addresses and then re-running the wizards in UAG Management. You'll want to re-run the "Network Interfaces" wizard and also run through the DirectAccess config wizards again to choose the new IP, and then re-apply the policies and reactivate the configuration. In my day job, it's fairly common to proof-of-concept UAG/DA in a test network and then "swing" the server/appliance over to a production network.

    That's the good news...however, in those situations the device was still in "testing phase", meaning that any client machines in the DA environment were easily taken onsite to have their new GPO applied after we moved the UAG appliance. This is going to be your struggle. Changing the server is easily done, but as soon as you change the IP addresses, which is your first step, you will be breaking the clients connection. Teredo (which covers most client connections) will no longer work as the client computers will be pointing to the old IP address. Hypothetically, as soon as you get your external DNS record adjusted to point to the new primary IP then IP-HTTPS would be able to function again, and your clients will fail with Teredo but then be able to successfully connect via IP-HTTPS. When they do, they'll pull down the new GPOs and then Teredo should work again as well.

    The only problem I see with the above is that I don't personally know of anyone who has tried it exactly like this. It all looks good on paper and I can't think of a reason it won't work. But I would have a backup plan in case. You can easily use the SSLVPN portal side of UAG to create a trunk that users could log into and establish an SSTP VPN connection back to your network. So if you get that in place, then even if clients cannot connect over IP-HTTPS to grab their new GPO settings you could instruct them to log into the SSLVPN portal, launch the SSTP VPN, and then they would grab the new GPOs over that connection.

    Tuesday, March 29, 2011 2:23 PM
  • Well the migration has gone incredibly smoothly thanks to the advice here.

    While I know there are a couple of people who have had problems here is what I did:

    1) Backed everything up (I used Symantec Backup Exec System Recovery to get images of the UAG server and the DCs and then took backups of the GPOs using the Group Policy Management tool

    2) Changed the external IP addresses on the UAG server.

    3) Ran the Network Interfaces wizard to set the external network on UAG.

    4) Ran through all the Direct Access configuration wizards to make sure everything there was correct. Deployed the GPOs and then saved and activated the configuration

    5) Verified that the UAG DirectAccess: Client GPO had deployed correctly by checking that the IP addresses under Administrative Templates\Network/TCPIP Settings/IPv6 Transition Technologies had updated.

    6) Went through the Portal configuration to ensure that the portal was set to listen on the correct IP addresses and that certs were allocated correctly.

    7) enabled SSTP SSL VPN using this useful blog post http://blogs.technet.com/b/edgeaccessblog/archive/2009/07/05/adding-the-sstp-magic-to-the-uag-charm.aspx

    8) Got my test laptop and got lucky. Repeated the process with another users laptop and that came across as well. Direct Access just worked - however I wasn't so lucky with my users. They needed to use the SSTP SSL VPN. Now you would think that people could follow simple instuctions with screen shots  (i.e. log on to the portal, let it install whatever it wants to install and add itself to whatever it wants to do and then start the VPN, bring up cmd and then run gpupdate). For one or two this proved impossible and led to fun and games all round.

    I also had to migrate a TMG server. This too was a question of changing the IP addresses and then re-running the Configure Network Settings wizard. I also had to tweak the listenters used to publish ActiveSync. It is worth noting that not only do you have to ensure that the IP address has been updated on the Networks tab but also that the IP address has been updated on the Certificates tab.

    Hope this helps others thinking of doing this.

    Thanks to everyone who has posted here, particularly Jordan.


    Darren
    Monday, April 11, 2011 8:13 AM

All replies

  • You can definitely make the change without needing to rebuild the server. Should be as simple as changing the IP addresses and then re-running the wizards in UAG Management. You'll want to re-run the "Network Interfaces" wizard and also run through the DirectAccess config wizards again to choose the new IP, and then re-apply the policies and reactivate the configuration. In my day job, it's fairly common to proof-of-concept UAG/DA in a test network and then "swing" the server/appliance over to a production network.

    That's the good news...however, in those situations the device was still in "testing phase", meaning that any client machines in the DA environment were easily taken onsite to have their new GPO applied after we moved the UAG appliance. This is going to be your struggle. Changing the server is easily done, but as soon as you change the IP addresses, which is your first step, you will be breaking the clients connection. Teredo (which covers most client connections) will no longer work as the client computers will be pointing to the old IP address. Hypothetically, as soon as you get your external DNS record adjusted to point to the new primary IP then IP-HTTPS would be able to function again, and your clients will fail with Teredo but then be able to successfully connect via IP-HTTPS. When they do, they'll pull down the new GPOs and then Teredo should work again as well.

    The only problem I see with the above is that I don't personally know of anyone who has tried it exactly like this. It all looks good on paper and I can't think of a reason it won't work. But I would have a backup plan in case. You can easily use the SSLVPN portal side of UAG to create a trunk that users could log into and establish an SSTP VPN connection back to your network. So if you get that in place, then even if clients cannot connect over IP-HTTPS to grab their new GPO settings you could instruct them to log into the SSLVPN portal, launch the SSTP VPN, and then they would grab the new GPOs over that connection.

    Tuesday, March 29, 2011 2:23 PM
  • Thanks very much for this.

    That's a bit of a relief to here. I haven't enabled the SSL VPN on the UAG server. We have an existing portal with a valid SSL cert. Is it basically just a question of ticking the appropriate boxes and telling people to log on to the portal to start the VPN or is it a lot more involved than that?

    Thanks again.


    Darren
    Tuesday, March 29, 2011 2:38 PM
  • Yup, basically just getting the settings into place. You need to configure the general SSTP VPN settings which are detailed here:

    http://technet.microsoft.com/en-us/library/ee809077.aspx

    After you set your options, then you simply add the "Remote Network Access" application to your portal's applications list. If you're not using your portal for anything yet, you can set the app to auto-launch so that as soon as your users log into the portal they will have the VPN tunnel establish automatically.

    You'll see in the document link that I provided that there are two types of VPN access. One is the SSTP which we are talking about that covers your Vista and Windows 7 clients (so all of your DA clients), the other is called Network Connector and is for connecting older machines like XP to a VPN. Please note that the older Network Connector is NOT supported to run on the same server that you are running DirectAccess.

    Just to throw a whole different idea at you, if you have the equipment available, is to setup another UAG server. You could set it up as a completely separate path for DA, and then when you move your clients from the old security group or OU to the new, they would still be connected via the old UAG server and should be able to grab their GPO updates, which would then automatically swing them over to the new UAG server.

    Tuesday, March 29, 2011 4:00 PM
  • Thanks again. I had thought about the seperate UAG server but unfortunately it isn't available as an option. I'll give the SSTP connection a go and post how the migration goes for others that may be interested. Might be a week or two before it finally gets done as I'm still testing the new internet connection at the moment and don't want to jump until I have had at least a few days reliable uptime on it.


    Darren
    Tuesday, March 29, 2011 4:10 PM
  • Hi Jordan,

    Very good information in this thread! Thank you!

    Just one small clarification, to avoid confusion:

    You'll see in the document link that I provided that there are two types of VPN access. One is the SSTP which we are talking about that covers your Vista and Windows 7 clients

    SSTP is not supported by UAG for Vista clients, only for Windows 7 clients. UAG will launch Network Connector on Vista client machines (in any case, this should not matter to Darren, since he is only interested in offering SSTP for his UAG-DA clients).

    Regards,


    -Ran
    Tuesday, March 29, 2011 4:43 PM
  • Thanks Ran! I was unaware that a Vista client over UAG would be given Network Connector. Vista is capable of SSTP is it not?

    Like you said, doesn't matter for this thread but good to know!

    Tuesday, March 29, 2011 5:35 PM
  • Hi Jordan,

    Yes, Vista is capable of SSTP, however UAG allows/uses SSTP only from Windows 7 clients. See here: http://technet.microsoft.com/en-us/library/dd920232.aspx

    Regards,


    -Ran
    Wednesday, March 30, 2011 7:41 AM
  • Learn something new every day :)

    Thanks again!

    Wednesday, March 30, 2011 12:13 PM
  • Well the migration has gone incredibly smoothly thanks to the advice here.

    While I know there are a couple of people who have had problems here is what I did:

    1) Backed everything up (I used Symantec Backup Exec System Recovery to get images of the UAG server and the DCs and then took backups of the GPOs using the Group Policy Management tool

    2) Changed the external IP addresses on the UAG server.

    3) Ran the Network Interfaces wizard to set the external network on UAG.

    4) Ran through all the Direct Access configuration wizards to make sure everything there was correct. Deployed the GPOs and then saved and activated the configuration

    5) Verified that the UAG DirectAccess: Client GPO had deployed correctly by checking that the IP addresses under Administrative Templates\Network/TCPIP Settings/IPv6 Transition Technologies had updated.

    6) Went through the Portal configuration to ensure that the portal was set to listen on the correct IP addresses and that certs were allocated correctly.

    7) enabled SSTP SSL VPN using this useful blog post http://blogs.technet.com/b/edgeaccessblog/archive/2009/07/05/adding-the-sstp-magic-to-the-uag-charm.aspx

    8) Got my test laptop and got lucky. Repeated the process with another users laptop and that came across as well. Direct Access just worked - however I wasn't so lucky with my users. They needed to use the SSTP SSL VPN. Now you would think that people could follow simple instuctions with screen shots  (i.e. log on to the portal, let it install whatever it wants to install and add itself to whatever it wants to do and then start the VPN, bring up cmd and then run gpupdate). For one or two this proved impossible and led to fun and games all round.

    I also had to migrate a TMG server. This too was a question of changing the IP addresses and then re-running the Configure Network Settings wizard. I also had to tweak the listenters used to publish ActiveSync. It is worth noting that not only do you have to ensure that the IP address has been updated on the Networks tab but also that the IP address has been updated on the Certificates tab.

    Hope this helps others thinking of doing this.

    Thanks to everyone who has posted here, particularly Jordan.


    Darren
    Monday, April 11, 2011 8:13 AM