I found it on IBMlink. Here's the apar text:
ERROR DESCRIPTION:
TSM Client on Windows 2000 incorrectly restores the registry
key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum
This key is specified in the registry under KeysNotToRestore,
and according to Microsoft article Q249694, the existing copy of
this registry key and its subkeys should be retained during a
registry restore. During a TSM registry restore, this key is
replaced with the backed up version because Administrators do
not have access to write to this key, by default.
No error is reported, but the registry is restored incorrectly
which could cause unknown results. This problem occurs because
permissions are preserved in the registry copy being restored,
so TSM cannot overwrite the Enum key with the existing copy.
This affects 4.2 and 5.1 TSM Clients on Windows 2000 and XP.
Initial Impact: MEDIUM
LOCAL FIX:
Use regedt32 to grant Administrators 'Full Control' to the key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum
Then run registry/system object restore.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: Windows BA clients. *
****************************************************************
* PROBLEM DESCRIPTION: TSM Client on Windows 2000 incorrectly *
* restores the registry key: *
* HKLM\SYSTEM\CurrentControlSet\Enum. *
* This key is specified in the registry *
* under KeysNotToRestore, and according *
* to Microsoft article Q249694, the *
* existing copy of this registry key and *
* its subkeys should be retained during *
* a registry restore. During a TSM *
* registry restore, this key is replaced *
* with the backed up version because *
* Administrators do not have access *
* to write to this key, by default. *
****************************************************************
* RECOMMENDATION: *
****************************************************************
Some of the Registry keys (like 'Enum') give ReadOnly access
for Everyone and Full access for System only. As a result
everyone gets the ERROR_ACCESS_DENIED error trying to write
into these keys.
Also, to access Registry keys TSM uses Win32 API function
RegQueryInfoKey(). There is a MS article Q307308
(W2k, W2k SP1, W2k SP2) which describes that RegQueryInfoKey()
function may return Zero for ControlSetnnn subkey parameters.
PROBLEM CONCLUSION:
TSM uses temporary Registry hive to perform operations which
are described in Microsoft article Q249694. Added code to reset
Registry key access permissions for this temporary hive before
any operations and restore them after.
Also due to Microsoft article Q307308 TSM could incorrectly
skip some of the Registry keys. Added code to avoid this
problem using RegQueryInfoKey() and RegEnumKeyEx() together
to obtain the correct subkey parameters.
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU]On Behalf Of
Frost, Dave
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.
|
