Prior to deleting users, the prudent action is to remove or alter any files
created by that user. IMHO the purgeuser command should have this option as
the default i.e.

purgeuser xyz;newcreator=abc

Without specifying the new creator "orphaned" files may exist. These files
may be critical and will not be restored by default. Note, this usually goes
unnoticed because very rarely can one restore 100% of the files. As Stan
indicate in a previous post some system files can not be restored only
'installed' or 'updated' under the ISL.

According to HELP RESTORE ALL
<snip>
If CREATE=CREATOR is not used, the default
behavior is:  If the creator of the file is not
found in the system directory, the file will not
be restored.  You will get an error message
telling you that the creator does not exist In
order to restore this "orphan" file, you must use
the CREATOR option or the CREATE option.
<end snip>

If you do use the CREATE=CREATOR to get closer to all of the files, then you
will also get those users you deleted! dejauser :(

The newcreator option could physically scan the files, or simply be part of
the file system that is used at restore time to map an orphaned creator to
an existing user.

TGIF
Mike


-----Original Message-----
From: Sletten Kenneth W KPWA <[log in to unmask]>
To: [log in to unmask] <[log in to unmask]>
Date: Friday, May 07, 1999 4:38 PM
Subject: Re: default user on sys account


>Yesterday Gavin said:
>
>> At first glance my gut reaction was that only MANAGER.SYS
>> and OPERATOR.SYS and maybe one or two others are official
>> (HP created) users in the SYS account, .....
>
>> ..... On checking a :LISTUSER @.SYS of course I find that:
>
>> NWIXUSER.SYS, PCUSER.SYS, RSBCMON.SYS, and
>> SCOPE.SYS, exist on all the machines that I checked, ......
>> It appears that one of these may have a default password ......  but
>> the others have no password by default, and any one of them can
>> be used to trivially leverage PM and SM capabilities once logged on, ..
>
>> Creating lots of additional users for the SYS account is *not* a very
>> good idea.
>
>Gavin is right on....  but I will add a caution that I learned from
>experience when I first stumbled on it a couple years back:
>
>Be careful deleting "external" users on your machine (external
>meaning HP or third-party created).  I had a number of users
>that I knew we did not need anymore, so without thinking it
>through very clearly I sez to myself: "Well, even though we
>have VE-AUDIT it still wouldn't hurt to simplify our accounting
>structure by purging them....   BZZZZST !!!....  Some months
>later (meaning I failed in my MANAGER.SYS duty) I discovered:
>THEY'RE BACK !!.....
>
>Of course what happened is that in the interim I had done a
>major system upgrade (5.0 to 5.5 or whatever).  And since I
>had deleted some of the "standard" HP users, the update
>process just re-created them...   WITH NO PASSWORDS !!!
>~!@#$%&*-+=....     And it is not just HP that does this:  One
>or more well-known third-parties who have some otherwise
>excellent products have also been guilty of silently using the
>"; CREATE" option in their install jobs to create new users with
>AM and even new accounts WITH NO PASSWORDS !!...
>The 3rd-party vendor that did this that I am aware of shall for
>now remain nameless, since after I told them I believe they immediately
>fixed the problem.
>
>Solution I adopted:  Unless you are *very* sure that a particular
>user / group / account will never be re-created by any standard
>HP or vendor install or update job:   Leave the user name in
>place;  but with the best eight-character alpha-numeric
>password you can think of.  At least for the products we run, I
>have yet to see an install or update job that will change an
>EXISTING password on a user that is already in the directory...
>I might add that if I ever find a software install / update job that
>would silently do such a thing, that might be sufficient grounds
>for excommunicating that product from my system......
>
>Ken Sletten