Hi, andy.
I wish my information on this were more clear to me, as well. I can't give you
a definitive accouting of what happens and why it happens, but I'll try to
illustrate what I mean.
First of all, I have never seen this happen on any member systems of domains
that I admin, only on workgroup members. Since these individual systems were
not under my direct control but were brought to me for rescue maintenance, I
cannot claim to have a really solid history on them. That being said, in a
couple of cases the users on the boxes have well above ordinary user level of
knowledge of operating system and software behaviors (mostly developers, and
good ones at that).
Typical story is that the user supplied a password for the built-in admin
during installation of the OS, then added a new user at the subsequent setup
screen that asks the installer to add names of users. Naturally, that first
new user is an admin user. Later on we mention that we would like for these
folks to use restricted user accounts for any operations that don't strictly
require admin privs. The user logs on as the built-in admin and goes through
the Run dialog to crank up the userpasswords2 applet instead of using the
ordinary User Accounts applet. (The regular applet doesn't allow you to change
the second admin account to a restricted user, but you can accomplish it via
this method.) Voila! Now you have a machine which at one time had the proper
number of admin accounts, and now it has only the original built-in account
and one restricted user account.
At some point the user now decides to change the password on his restricted
account. He logs on as the admin and goes to the regular User Accounts applet.
His regular account isn't listed! He goes into control userpasswords2, and it
isn't listed there, either! But he can't add the user because the applet says
the user account already exists. The profile storage location is intact, and
he can log on to the restricted account, but he can't administer the account
via any normal means. (Well, he could change his password, for instance, by
using Ctrl-Alt-Del from a logged in session on the account and choosing
change Password there, but he is freaked out at this point because his dev
box isn't acting properly.)
Bear in mind that we would have seen the effect immediately if any of our
people used the Welcome screen. We all use policy to enforce use of Ctrl-Alt
-Del dialog for logon. I know this because I turn on the Welcome screen, and
the restricted account is not listed. I can still log on to it, however, by
using the trick one normally uses at the Welcome screen for logging on to the
built-in admin account, by hitting Ctrl-Alt-Del twice.
At this point the fix is to add another admin account, and to go into the
registry Special Accounts section and change the DWORD value for the mal-
functioning account from 1 to 0. Now the user has his restricted account back,
and he can admin it properly.
I saw this happen on several boxes within a few weeks following mandate by
company policy that the devs change their accounts to restricted level, so I
I know that the behavior isn't isolated. WinXP likes to hide the built-in
admin account, of course. But this is like the OS becomes "frustrated"
because it can't do that, so it hides the only other account on the box.
I know it's weird of me to personify the OS by talking about its preferences
and about it being frustrated, but I think this behavior was clearly not
intended by Microsoft. It's just an idiosyncracy brought out by using the
OS in a manner they hadn't anticipated.
I have not tested to see if runas from a restricted user account will work
on a system with only the built-in admin. Obviously the hidden special
account issue isn't happening on the system you're describing, but the
history you relate suggests that the issue may have something to do with
the account having been an admin account at one time before having its
privilege level reduced.
ower Uers) for employee on this pc,and then