none
Replacing UAG server hardware RRS feed

  • Question

  • All,

    I'm finished with the pilot stage of my DA project, using UAG 2010 SP1. However, it's currently running on an older server, and it's time to replace the hardware and roll out to all laptops.

    Although I've found directions for side-by-side migration to 2012, I have no experience with it, and it seems a bit risky to make this my first project, so I'll be sticking with Win2k8R2 and UAG 2010 SP1.

    Is there a recommended way to do this? I haven't found any guidance from MSFT after a fair amount of searching.

    Top goal is to keep connectivity up for our people currently in the field, though a couple of hours of downtime, if announced ahead of time, would be acceptable.

    I can see three approaches:

         o- P2V the current server and use a hypervisor (I'd probably use ESXi), but that would involve some downtime

    or

         o- Bring up the new server as a member of an array containing it and the old server, then shut down the old server. I've not worked with arrays before, so am pretty uncertain if this is a reasonable way to go

    or

         o- Bring up the new server, give it a random name, don't make it a member of the domain. Then export the configuration of the working machine, shut it down, remove it from the domain, rename the new machine to match the old machine name and set up the IP addresses to match, join it to the domain, install UAG and import the settings from the old machine

    Are any of these, or something else I haven't thought of, recommended? Are any of the above a formula for disaster, or just too complex to both with?

    Thanks for your thoughts,

    Kurt

    Friday, November 9, 2012 7:15 PM

Answers

  • The TLG is the Test Lab Guide that was published when UAG was first coming out. Many proof-of-concept environments are built off of it step-by-step, including a DNS record for "ISATAP" like you have. Doing ISATAP on this scale is no longer recommended and this should be removed. Yes, I recommend removing ISATAP and adding it back to the block list, and then migrating over to your new server, and then IF NEEDED - re-enable ISATAP selectively, using Jason's great post here: http://blog.msedge.org.uk/2011/11/limiting-isatap-services-to-uag.html

    Many of my installations go without ISATAP completely. Only if you have a need to initiate a connection from inside your network out to a DA client (like a helpdesk computer RDPing into a DA client) do you need ISATAP. If you don't need that capability, you don't need ISATAP at all.

    • Marked as answer by KurtBuff Friday, December 14, 2012 12:47 AM
    Tuesday, November 13, 2012 8:28 PM

All replies

  • There is very little information available on disaster recovery of UAG or UAG DA (which is essentially the same as what you are trying to do) so there is no easy answer :(

    Of the three options I would probably go with the last one...or even reconfigure the DA wizard from scratch unless your configuration is really complex...


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

    • Proposed as answer by Jonas Blom Tuesday, November 13, 2012 6:40 AM
    Saturday, November 10, 2012 12:31 AM
    Moderator
  • Hi,

    A suggestion. (Nothing regarding what's officially recommended, just how I try to do things like this myself)

    If you have extra IPs available, do a new setup on two other IPs along with a separate new DNS record for IPHTTPS.

    That way you can move the users from the group connecting them to you PoC setup to the production setup and they will simply receive the production settings and loose the PoC settings at the same time.

    Used this approach a few times when beeing in situations similar to the one you are in now.

    The best part of this is that you can test moving a few selected clients back and forth how many times you want until you feel certain that things work as you expect.

     


    Jonas Blom | Relevo AB | http://blog.nrpt.se

    • Proposed as answer by Jonas Blom Tuesday, November 13, 2012 6:40 AM
    Saturday, November 10, 2012 7:17 PM
  • Thanks for the reply. It's unfortunate MSFT hasn't documented anything about this.

    I'll take a look at the suggestion from Jonas, I think.

    Kurt

    Monday, November 12, 2012 11:56 PM
  • Jonas,

    Thanks for your thoughts. I think this is a reasonable way to go.

    I'm going to run through that process and if I have any difficulties I'll post back here.

    Kurt

    Monday, November 12, 2012 11:59 PM
  • Hi, you could do a bare metal recovery of the machine to the new Hardware of you are using DPM. I've done this last week and it just worked fine. Only Thing to do was to run the Network configuration wizard one more time. Downtine about 10 minutes.
    Tuesday, November 13, 2012 3:45 PM
  • I agree with the path you are heading down, if you have additional public IPs you can setup another entry point and "swing" computers back and forth very easily. A couple of other considerations in doing this though:

    1. If you setup a second box you will need not only two more public IPs, but also another public DNS name and an SSL cert to go along with it.

    2. This is only going to work well if you do NOT have ISATAP inside your network. If you are using ISATAP, your second box will set itself up as an ISATAP client of the first box, and you will have confusing options in the IP addressing screen of the wizards. You will have to force your second box not to talk to the first as an ISATAP client. Hopefully you haven't configured "global" ISATAP inside your network as it's not recommended anyway, but many folks who walked through the TLG to setup their test environment did so because that was written long enough ago that it was recommended at the time...

    Tuesday, November 13, 2012 4:31 PM
  • No DPM currently - it's part of our recent EA, but we haven't implemented that yet. Good thought, though.

    Kurt

    Tuesday, November 13, 2012 6:51 PM
  • I agree with the path you are heading down, if you have additional public IPs you can setup another entry point and "swing" computers back and forth very easily. A couple of other considerations in doing this though:

    1. If you setup a second box you will need not only two more public IPs, but also another public DNS name and an SSL cert to go along with it.

    2. This is only going to work well if you do NOT have ISATAP inside your network. If you are using ISATAP, your second box will set itself up as an ISATAP client of the first box, and you will have confusing options in the IP addressing screen of the wizards. You will have to force your second box not to talk to the first as an ISATAP client. Hopefully you haven't configured "global" ISATAP inside your network as it's not recommended anyway, but many folks who walked through the TLG to setup their test environment did so because that was written long enough ago that it was recommended at the time...

    For 1., I'm already on that. I have requisite addresses and a wildcard cert from a 3rd party, which is already in use for my first box. I've also already put in the new public DNS entry.

    For 2., well, I need some more info, I think. TLG? Define, please? I do have a DNS entry for isatap.example.com set up, so I suppose that qualifies as global, given that we have a single forest/domain with offices in US, AU and UK (we're only doing DA/UAG for the US office, though). I did read in the guide for side-by-side migration from 2010 to 2012 a few bits about ISATAP. Should I do as it says, and eliminate the DNS entry (and though it didn't mention it, put it back on the global DNS block list), along with the rest of the steps? Or would it be simple just to turn of ISATAP on the new box and not have to worry about it?

    Thanks,

    Kurt

    Tuesday, November 13, 2012 7:06 PM
  • The TLG is the Test Lab Guide that was published when UAG was first coming out. Many proof-of-concept environments are built off of it step-by-step, including a DNS record for "ISATAP" like you have. Doing ISATAP on this scale is no longer recommended and this should be removed. Yes, I recommend removing ISATAP and adding it back to the block list, and then migrating over to your new server, and then IF NEEDED - re-enable ISATAP selectively, using Jason's great post here: http://blog.msedge.org.uk/2011/11/limiting-isatap-services-to-uag.html

    Many of my installations go without ISATAP completely. Only if you have a need to initiate a connection from inside your network out to a DA client (like a helpdesk computer RDPing into a DA client) do you need ISATAP. If you don't need that capability, you don't need ISATAP at all.

    • Marked as answer by KurtBuff Friday, December 14, 2012 12:47 AM
    Tuesday, November 13, 2012 8:28 PM
  • The TLG is the Test Lab Guide that was published when UAG was first coming out. Many proof-of-concept environments are built off of it step-by-step, including a DNS record for "ISATAP" like you have. Doing ISATAP on this scale is no longer recommended and this should be removed. Yes, I recommend removing ISATAP and adding it back to the block list, and then migrating over to your new server, and then IF NEEDED - re-enable ISATAP selectively, using Jason's great post here: http://blog.msedge.org.uk/2011/11/limiting-isatap-services-to-uag.html

    Many of my installations go without ISATAP completely. Only if you have a need to initiate a connection from inside your network out to a DA client (like a helpdesk computer RDPing into a DA client) do you need ISATAP. If you don't need that capability, you don't need ISATAP at all.

    Definitely want the ability to RDP to remote machines and do other manage out tasks - sales guys are often not technical, and it's just too useful.

    I'm reading that blog entry now. Thanks for this.

    Kurt

    Tuesday, November 13, 2012 8:35 PM
  • I'm doing this now.

    I just have to fight my way through the config of the new machine - I'm missing a bunch of config on the new machine, but I'll start a new thread if I find I need help.

    Thanks to all,

    Kurt

    Friday, December 14, 2012 12:48 AM