Hi Paul,
Have you try ASR and Citrix?
Now you got problems...
But there is BMR software that is made for more advance environment that IBM
recommends.
Talk to your local IBM rep for more information.
Thanks
Christian
-----Ursprungligt meddelande-----
Från: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] För Paul van
Dongen
Skickat: den 16 februari 2006 13:45
Till: ADSM-L AT VM.MARIST DOT EDU
Ämne: ASR woes
Hello TSMers, or more precisely, the intersection between the TSMers and
WINDOWSers
I spent the last 24 hours struggling with the ASR bare metal recovery
process with W2K3 and TSM. Got some good things, and some strange things
which I would like to share/comment, and also seek for some answers. Here's
the story:
First of all, I used TSM client 5.3.2.2 to backup all disks on the
servers, including System State/System Services. Open Files backup also
working fine.
First machine to be recovered was a test machine with one disk split in
two partitions (C: and T:). Restore went file, and ASR recreated my two
partitions and restored C:. The T: partition was left empty, but this is a
minor problem.
After this degree of success, we went for the restoration of a MS Cluster
node running SQL Server, on a brand-new IBM xSeries 366. Here begins the
real story....
Problem #1: This machine uses SAS disks and matching RAID controller, for
which I had to provide the drivers. When I pressed F6 during text-mode
setup, it prompted for the driver, an went on, but then it wouldn't accept
the ASR diskette anymore. I finally solved it by integrating the RAID
controller driver into the W2K3 CD.
Problem #2: The network cards present on the machine (6 in total) are not
recognized by the standard Windows setup. After a call to MS's support, I
got the answer that "only local restores are supported". After many hours
and iteractions of "burn CD-RW (15 min)/boot the server (20 min)" I could
get Windows to accept a set of network drivers integrated as OEM drivers
pointed by the "Unattended Install" mode. I had some dark thoughts because
the ASR process uses its own kind of response file, and soon enough I was
feced with the effects of this. After the device detection, Windows setup
would simply freeze. After some 10 minutes, I gave up I went to reboot the
machine. By chance I pressed Enter and... oops!! Setup resumed.... Not too
good to document, I think. "If setup freezes, get a cup of coffee an try
pressing Enter several times"....
After that, Windows finally came back, but it started complaining on
every boot that the cluster service could not be started because the quorum
disk could not be accessed (Quite right, since the other node has it). But
after 60 sec, cluster service restarts and the node joins the cluster
normally. That is problem #3.
The last problem# is by far the silliest.... The (standard) MS Sql server
install placed in the registry the SHORT file names (intended for 16-bit
programs that must use the old 8.3 naming convention). So, the directory
named "Microsoft SQL Server" had a short name of MICROS~1 before the ASR
process, and MICROS~2 after (because there was a "Microsoft MOM" directory
which was restored earlier ad got MICROS~1). Obviously SQL Server wouldn't
start, and I had to rename both directories to get it to work.
I am currently trying (after some sleep) to solve these so I can get a
decent automated process. If someone gets any light on these questions
please let me know.
Thanks to all,
Paul van Dongen
|
