ADSM-L

Re: Restoring user profiles

2000-01-31 14:46:57
Subject: Re: Restoring user profiles
From: "Prather, Wanda" <Wanda.Prather AT JHUAPL DOT EDU>
Date: Mon, 31 Jan 2000 14:46:57 -0500
Yes, there is a hole you can fall into where your profiles doesn't  get
backed up.  We discovered this and it was discussed on the list about 2
years ago, when we first started using NT 4.0.

For WinNT 4.0, the current  logged on  user profile is part of the registry
in the "current user" key.
Each user's profile is also saved in their own NTUSER.DAT file.
A backup of either is sufficient.

Now NTUSER.DAT cannot be backed up while the user is logged on, it's locked.
But the first thing that happens during an incremental backup is a backup of
the registry, which picks up the "current user" key.

However, if you run backups via the scheduler, the scheduler is running
under the "system" id, so the "current user" key that gets backed up is the
profile of the "system" account, not the user.

This creates a tiny backup exposure you can fall into if you have NT 4.0
workstation on people's desktops.
Now most people never see this problem:

*       People running NT 4.0 on servers generally don't care about any user
customization, who customizes a profile for the admin user, anyway?
*       If backups occur in the middle of the night and/or the user is
logged off at the time, the user's NTUSER.DAT file gets backed up OK.
*       If a user runs the GUI to do a backup, the profile is saved as the
"current user" registry key, so the profile is backed up fine that way.

The ONLY case where you have a hole is when you have NT 4.0 on the desktop,
and the SCHEDULER ALWAYS RUNS THE BACKUP WHILE THE USER IS LOGGED ON.  In
this case, the user's profile never gets backed up, so can't be restored.

We actually have this situation a lot.  Our workaround, which we got as a
suggestion from ADSM lvl 2 support:

When we install ADSM, for each user we create a .bat file in the startup
group that contains:

cd c:\adsm\baclient
dsmc regback user curuser

This means every time the user logs on,  just that user's profile gets
backed up immediately as the "current user" registry key.  This closes the
hole.

After a bare metal restore, our last step is to log on as the user and do
this:

dsmc regrest user curuser

That does a restore of just this user's profile.

Hope this helps, it's a very sneaky issue.

************************************************************************
Wanda Prather
The Johns Hopkins Applied Physics Lab
443-778-8769
wanda_prather AT jhuapl DOT edu

"Intelligence has much less practical application than you'd think" -
Scott Adams/Dilbert
************************************************************************








> -----Original Message-----
> From: Ken Franklin [SMTP:kpfadsm AT HOTMAIL DOT COM]
> Sent: Thursday, January 27, 2000 1:07 PM
> To:   ADSM-L AT VM.MARIST DOT EDU
> Subject:      Restoring user profiles
>
> We have been testing ADSM/TSM to see if it will work for our organization.
> We have been having problems with Bare Metal restores - every time we try
> to
> restore a workstation, the user settings are lost and we end up with the
> default profile.  We brought a ADSM/TSM rep on sight and he was baffled.
> He
> had us call tech support and they told us is was an OS issue - Microsoft
> Windows (NT or 95) does not allow the active profile to be backed up.
> This
> means in order to back up the profile, the user would need to log out, log
> in with another username, run a backup, log out and log back in as
> themselves.  A lot of people, in particular those who most need to be
> backed
> up, just aren't going to be willing to go through all that.
>
> Is what the tech support guy told me correct?  Is ADSM/TSM really unable
> to
> back up the active user?  Does anyone know of a workaround?
>
> Thanks,
>
> Ken
> ______________________________________________________
> Get Your Private, Free Email at http://www.hotmail.com
<Prev in Thread] Current Thread [Next in Thread>