ADSM-L

Re: Win2k system state restore

2002-08-15 09:51:42
Subject: Re: Win2k system state restore
From: "Seay, Paul" <seay_pd AT NAPTHEON DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 15 Aug 2002 09:24:10 -0400
The Tivoli Knowledge base does not have everything.  IBMLINK does.  You have
to have a userid to look at that information.

Paul D. Seay, Jr.
Technical Specialist
Naptheon Inc.
757-688-8180


-----Original Message-----
From: Frost, Dave [mailto:dave.frost AT GUARDIANIT DOT COM]
Sent: Thursday, August 15, 2002 5:15 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Win2k system state restore


Jim,

Thanks for that.  But...

A lookup in the tivoli/support/knowledgebase/ for apar ic34015 returns 0
records.  Nor is it documented in the readmes for the 4.2 or 5.1 client in
"maintenance" or "patches" at boulder.

It would seem that this apar is not publically available.


  regards,

-=Dave=-
--
+44 (0)20 7608 7140

Know thyself.  If you need help, call the C.I.A.



-----Original Message-----
From: Jim Smith [mailto:smithjp AT US.IBM DOT COM]
Sent: Wednesday, August 14, 2002 11:55 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Win2k system state restore


Dave,

The TSM B-A client does have a facility to not replace the hardware
dependent driver information during a system object restore.  Let me
explain:

The traditional method backup/restore of the registry was for the backup
product to export the registry files and backup the exported files.  For
restore, the backup product would simply then restore the files to a staging
area and import the information back into the registry (the activation of
the registry, if you will).  This was a pretty simple exercises for a backup
product.

When Windows 2000 arrived Microsoft changed the procedure a bit and
introduced the registry key:
HKLM\SYSTEM\CurrentControlSet\Control\BackupRestore\KeysNotToRestore.
The basic procedure now is the backup product restores the registry
information to the staging area (as before) but now is required to move
information from the current registry (these KeysNotToRestore) over the
information that was just restored and then activate the registry. This is
basically allowing information in the current registry to be preserved
across a restore and reboot.  Systems like Active Directory rely on this as
they write information about the log reply into the current registry which
would otherwise be overwritten by the restored copy of the registry and not
available after the reboot.  Another system which exploits this is the Plug
& Play subsystem which describes the hardware dependent driver information
about which you are inquiring.  This subsystem preserves the information in
the HKLM\SYSTEM\CurrentControlSet\Enum portion of the registry among other
things.

While TSM uses the procedures that Microsoft outlines regarding registry
restoration, we found that by default the administrator doesn't have the
proper permissions to write into Enum branch.  This information is well
documented in APAR IC34015.  The APAR will be fixed in TSM 5.1.5; a simple
work around involving using regedit to grant the proper permissions is
documented in the APAR if you are using the TSM 4.2.2 client or TSM 5.1.0
client.

Having said all this, I caution that Microsoft does not guarantee that you
can always restore from hardware a to hardware b.  If you are using
Ntbackup.exe, then it would be safe for me to say that if your particular
environment can be brought back by Ntbackup.exe then TSM should be able to
do it as well.

Hope this helps,
Jim Smith
TSM Development

>>>

Dear All,

Does anybody know if there is any plan in future releases of the TSM client
for W2K, to implement a facility to not replace the hardware dependent
driver information during a system object restore.

My reason for asking ;

We have a requirement to fully restore a W2K server back to different
hardware (ie. different RAID controller and/or different processor
architecture)
At present, our solution is to use NTBACKUP to backup the system state and
TSM to backup the remainder.

NTBACKUP is intelligent enough to not restore hardware dependent drivers
back onto a platform that is different. I cannot get TSM to emulate this.

The above solution is OK, but I am backing up the WINNT directory with TSM
as flat files, then I am backing up the System Object with TSM and finally
backing up the flat file generated by the NTBACKUP system state operation.

It all seems a bit needless really. ( I know I could exlude WINNT but as yet
I don't know of any way to exclude the systemobject).

Any thoughts or knowledge of future client releases would be welcome.

Thanks

regards,

-=Dave=-
--
+44 (0)20 7608 7140

"I'll be Bach." - Johann Sebastian Schwarzenegger



www.guardianit.com

The information contained in this email is confidential and intended only
for the use of the individual or entity named above.  If the reader of this
message is not the intended recipient, you are hereby notified that any
dissemination, distribution, or copying of this communication is strictly
prohibited.  Guardian iT Group will accept no responsibility or liability in
respect to this email other than to the addressee.  If you have received
this communication in error, please notify us immediately via email:
postmaster AT guardianit DOT com


________________________________________________________________________
This e-mail has been scanned for all viruses by MessageLabs.

________________________________________________________________________
This e-mail has been scanned for all viruses by MessageLabs.

________________________________________________________________________
This e-mail has been scanned for all viruses by MessageLabs.

<Prev in Thread] Current Thread [Next in Thread>