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.