ADSM-L

Re: Restoring and NT System

1997-04-29 12:25:20
Subject: Re: Restoring and NT System
From: "Prather, Wanda" <PrathW1 AT CENTRAL.SSD.JHUAPL DOT EDU>
Date: Tue, 29 Apr 1997 12:25:20 -0400
Hi.  Yes, I have seen this before, and it's ugly.
You don't say whether the client is running NT 4.0 or NT 3.5.1.  If it's
3.5.1, discard this message.

If it's NT 4.0, I just posted another message to the list (4/29, 11:47),
titled "NT Client - ntuser.dat? " that explains in fairly awful detail
how you can lose your user profile/desktop.

Some additional information:

*       I have also seen the problem you describe where you get a new id
created with the .000 and .001 suffix.
When an NT 4.0 userid gets created, it gets assigned an "S-id key" in
the registry, a long string of digits starting with "S".  If you damage
the machine, and log on to an NT network again, you get a new S-id
created which is not the same as the old one.  You are disconnected from
the old one permanently, and that causes problems.  If you are working
in an NT domain, where domain security is involved, and you have to do a
machine restore, DO IT ALL LOCALLY.  Log on to the LOCAL machine, not
the NT domain, until you have everything put back together, and do not
try to use any of your userids until the registry has been restored.

*       If you don't have a good backup of the user profile (see the other
post), it causes the problem you describe.

*       If you restore WinNT but don't explicitly restore the registry files
before you log on to the machine, I think it can cause the problem you
describe.

*       If you restore the registry, then log on WITHOUT REBOOTING, it causes
the problem you describe, on NT 4.0.

*       In other words, if you restore the system, restore the registry,
REBOOT, AND you have a good backup of the User Profile, it works
perfectly.  If you do any of this out of order, you get your userids and
profiles hosed, and it's very hard to understand why, or figure out what
went wrong.  We are telling our users NEVER to try to restore their
registry unless there is an ADSM admin staring over their shoulder -  it
is just about impossible to figure out what they did wrong after the
fact.  (It could also be the case there was something wrong with your
user's registry or his security data base before he did the restore, or
he did not wipe the hard disk completely before he did this restore, or
he wasn't working with a current registry backup, etc.  .....)

We found we actually had to know more than we wanted to about the
structure of the Registry to get this stuff cleaned up.  I don't know
how to repair the damage when the S-ID key is hosed.  We blew the userid
away and started over.

To repair the damage when the user profile is disconnected, we figured
out how to update the registry entry to point to the right profile.  I
listed a reference in the previous post that describes the user profile
entries in the registry.  If this sounds like something you want to
pursue, write me back and I will send you a quick-and-dirty-no-guarantee
writeup of where to find the registry entry.


 =======================================================================
=
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:  Moir,Elizabeth[SMTP:Elizabeth.Moir AT vm.ssw.abbott DOT com]
>Sent:  Monday, April 28, 1997 3:59 PM
>To:    ADSM-L AT VM.MARIST DOT EDU
>Subject:       Restoring and NT System
>
>To: OAS     --LMS1
>
>FROM: Betsy Moir (TTCEDM) Ext 85020
>      VM Tech Services
>      email:  elizabeth.moir AT vm.ssw.abbott DOT com
>Subject: Restoring and NT System
>
>I have a client who, by his own admission, generally pushes the limits of
>what his workstation can and can't do.  He runs three operating systems.  He
>has done a full NT restore successfully on two other occasions.  This time
>the procedure was:
>
>1.  Boot to a small recovery partition.
>2.  Load ADSM.
>3.  Restore his system to his his primary partition using the
>    restore by subdirectory branch option.  From: \
>                                            To:    e:
>
>Everything restored successfully, and he booted successfully to his primary
>partition, but the restore process had created three new administrator ids
>and two additional user ids.  These ids had extensions of .000, 001, 003,
>etc.
>It caused him to be unable to access the server and he lost his desktop.
>
>Has anybody ever seen or heard of anything like this or have any clues as to
>what he might have done wrong THIS time that he didn't do the other times.
>He's felt very confident in the past with his testing, etc. knowing he could
>restore his system easily with ADSM and he'd like to get that confidence
>back.
>
>One other thing, and not being a PC guru I'm not sure it's relevant, but he
>used WINDOWS 95 to restore WINDOWS NT to his recovery partition and then
>restored his primary partition using WINDOWS NT.
>
>Any help or thoughts on this would be much appreciated.  Thanks.
>
>Betsy
>
<Prev in Thread] Current Thread [Next in Thread>