There is nothing you can do to unlock those files.
In NT 4.0, Microsoft moved part of the user profile to NTUSER.DAT (and
NTUSER.DAT.LOG) and locked it.
The ADSM client cannot read it as a flat file, because nothing else can,
either. And the ADSM client was really written for NT 3.5 and doesn't
account for the problem.
Now actually ALL users with accounts on an NT 4.0 system have their own
personal NTUSER.DAT files.
ADSM can back up all of them except for the user logged on at the time
the backup is taken . That user's NTUSER.DAT is the only one locked.
The only exposure you have is that for Administrator, you could lose
your user profile settings for things like wallpaper
and Microsoft Exchange. Most people don't do a lot of customizing for
the Administator account and don't care.
But, if you want to work around it, you can create a logical backup of
that account's profile by running this ADSM command:
DSMC REGBACK USER CURUSER
Or, go into the GUI and do a Registry backup selecting ALL or just the
Current User key. This creates a logical registry-type backup of the
current user profile. Then it doesn't matter if NTUSER.DAT gets backed
up as a flat file or not - you can recover your profile from EITHER a
flat-file backup of NTUSER.DAT, or the logical DSMC REGBACK copy. If
you do the DSMC REGBACK, after you recover your system, to get the
profile back, you log on to that account and do DSMC REGREST USER
CURUSER, then reboot. (If you are working in an NT domain environment,
do this while you are still in a workgroup, not in the domain.)
The reason the normal registry backup doesn't account for this is that
if you are using the NT Scheduling service to run the backups, it backs
up the profile for the "system" id that runs the service as the
"current" user. So any user logged on while the backup is running is
missed.
Most people don't care if they lose the profile for an admin id on a
server. But we have a lot of users with NT 4.0 workstation who come in,
boot up NT, let the Scheduler run their backups while they are logged
on, and then shut down NT, so their own id is always logged on while the
backup is running. To get around this problem, IBM Level 2 told us to
have each user put a DSMC REGBACK USER CURUSER into their startup group.
That way we are sure every user gets a logical backup of their profile
each time they log on, no matter when the Scheduler registry backup
runs.
Hope this helps.
=======================================================================
Wanda Prather
Johns Hopkins Applied Physics Lab
301-953-6000 X8769
wanda_prather AT jhuapl DOT edu
"Intelligence has much less practical application than you'd think."
- Scott Adams/Dilbert
=======================================================================
> ----------
> From: Julie Phinney[SMTP:jphinney AT humana DOT com]
> Sent: Friday, September 05, 1997 10:20 AM
> To: ADSM-L AT vm.marist DOT edu
> Subject: Win NT client NTUSER.DAT
>
> On an Windows NT v4.0 client we are a getting the message, in our
> DSMSCHED.LOG that access is denied for
> WINNT\PROFILES\ADMINISTRATOR\NTUSER.DAT and NTUSER.DAT.LOG I figure
> that must mean that those files are locked by Win NT? Does anyone
> know? We are planning to restore the machine to a hardware upgrade
> tonight, does this mean these files won't restore properly? We are
> going to be following the Disaster Recovery process outlined in the
> redbook, but I'm concerned about those files not having been backed up
> properly. Maybe there's something we can stop prior to tonight's
> backup, that will cause those files to back up?
> TIA!
> Julie Phinney
> JPHINNEY AT HUMANA DOT COM
>
|
