[isapros] Re: ISA EE Disaster Recovery - Apologies, a bit long!

  • From: "Jason Jones" <Jason.Jones@xxxxxxxxxxxxxxxxx>
  • To: <isapros@xxxxxxxxxxxxx>
  • Date: Tue, 8 Aug 2006 23:20:34 +0100

Hmmm...you saying this kind of DR experience is "normal"?
 
TBH I have used ISA for ages and never actually had to DR an enterprise
firewall node (done SE a few times and recovered CSSs just fine). This
was the first time it is is a chargeable part of the overall project, so
gotta get some answers, hence I have now logged a PSS call to see what
they say, maybe the NLB stuff makes recovery harder or maybe not even
possible. Will feed back responses from PSS to help the group. 
 
You mention Acronis, so I assume you mean you prefer imaging solutions?
I guess there is no issue recovering array members from images, even if
the images are months out of date?
 
Thanks for the sanity check! ;-)

________________________________

From: isapros-bounce@xxxxxxxxxxxxx [mailto:isapros-bounce@xxxxxxxxxxxxx]
On Behalf Of Thomas W Shinder
Sent: 08 August 2006 18:37
To: isapros@xxxxxxxxxxxxx
Subject: [isapros] Re: ISA EE Disaster Recovery - Apologies, a bit long!


Hi Jason,
 
I've noticed similar issues. Now I use Acronis :)
 
Thomas W Shinder, M.D.
Site: www.isaserver.org <http://www.isaserver.org/> 
Blog: http://blogs.isaserver.org/shinder/
Book: http://tinyurl.com/3xqb7 <http://tinyurl.com/3xqb7> 
MVP -- ISA Firewalls

 


________________________________

        From: isapros-bounce@xxxxxxxxxxxxx
[mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jason Jones
        Sent: Tuesday, August 08, 2006 12:05 PM
        To: isapros@xxxxxxxxxxxxx
        Subject: [isapros] Re: ISA EE Disaster Recovery - Apologies, a
bit long!
        
        
        No ideas????
         

        Jason Jones | Silversands Limited | T: 01202 360489 | M: 07971
500312 | F: 01202 360900 | E: jason.jones@xxxxxxxxxxxxxxxxx
<mailto:jason.jones@xxxxxxxxxxxxxxxxx> 

         

________________________________

        From: isapros-bounce@xxxxxxxxxxxxx
[mailto:isapros-bounce@xxxxxxxxxxxxx] On Behalf Of Jason Jones
        Sent: 03 August 2006 14:10
        To: isapros@xxxxxxxxxxxxx
        Subject: [isapros] ISA EE Disaster Recovery - Apologies, a bit
long!
        
        

        Hi All, 

        Just got back from spending a few days trying to do a disaster
recovery exercise for ISA EE. Had a few problems, so wondered if anyone
could provide some ideas.

        Before the test, we have been writing our own DR procedures
based upon testing in our virtual labs. During research for this, I
found that there seems to very little information available of any value
(from what I can tell) so I have had to base a lot of the process on
"what I have seen/found" rather than "how it works". Any info on
detailed  recovery for ISA would be really handy (specifically on how
ISA deals with server objects and GUIDs)

        Anyhow, the CSS recovery went fine, but I had lots of issues
trying to recover array members. The biggest problem seemed to be
related to the use of NLB. For background, the servers are also acting
as multinetwork firewalls so have 5 NICs, each with one or more VIPs.

        The process I followed was: 

        *       Reinstall OS with same computer name and IP settings
etc. 

        *               Configure pre-install configuration changes
(edit hosts file, reinstall SSL certs etc.) 

        *       Re-Install ISA Server software and join the original
array 
        *       Apply ISA specific service packs and updates (SP2 +
KB916106) 
        *       Array cleanup (delete old server object with new GUID) 
        *       Configure post-install manual configuration changes (reg
changes, PMTU, add missing VIPs etc.) 

        Are there a flaws in this approach? Should I be doing something
different? 

        From the testing in the labs, I noticed that when you try and
install a new array member with the same computer name, ISA shows a new
object under the array members called Servername{GUID} and the existing
object is still shown as ServerName. After a short time (maybe once the
firewall service is restarted) the properties of the old server are
moved back to the original object and you can then delete the temporary
ServerName{GUID} object. From the actual DR test, this didn't actually
happen and the correct server object was the one labelled
ServerName{GUID}.

        The key problem seems to lie with NLB, because as soon as the
reinstalled server contacted the CSS and downloaded the array config,
NLB is enabled on interfaces and at this point the server loses network
connectivity. I managed to get the server working again by running the
'RemoveallNLBsettings' script and restarting firewall services, but this
didn't work every time and on occasion needed to be run several times
before working. 

        Funnily enough, the customer wasn't happy with this "try it a
few times until it works" approach :-))) 

        Any ideas, really appreciated... 

        Cheers 

        JJ 

Other related posts: