K
KAdamsInCo
I had originally posted a problem with Windows Server
2003 Standard Edition Terminal Server where a user who
belonged to just "users" and "Remote Desktop Users", but
not to an administrative group such as "Power Users", did
not receive an Explorer Desktop after logging in. All of
my TS users had to belong to at least "Power Users"
before they would receive a desktop at TS login.
So here is the solution to this problem, just in case
others have it.
It was a problem with access to certain Windows Registry
entries by normal "users" and "remote desktop users".
This is how I diagnosed and resolved this issue:
1. I went to http://www.sysinternals.com and downloaded
the RegMon program.
2. With RegMon running on the Terminal Server capturing
events, I opened up another session and logged in under a
normal "users"/"remote desktop users" account.
3. The desktop did not display, so I went back and
reviewed the RegMon log.
4. It did take time to scroll through a fairly large list
of output, but I did discover some ACCDENIED results for
the explorer.exe process during OpenKey requests for the
test user I was attempting to log in by.
5. I ran regedit and identified the folders and keys that
it had problems accessing. Some were under HKCR
(HKEY_CLASSES_ROOT) and HKLM (HKEY_LOCAL_MACHINE). I
modified the permissions to allow "users" and "remote
desktop users" the same level of access as "power users"
on the specific folders/keys that explorer.exe couldn't
access.
With the registry entries modified I tried to log in
through my test account again, and this time a full
desktop displayed. I was able to launch applications
such as Word and Excel, and in my Terminal Server session
only the printers mapped in my session were visible to me
(the original desired effect).
Exactly why the key values/folders necessary to display a
desktop for a normal user did not have the correct
permissions remains a mystery. I know for a fact that I
did not manually modify the registry to limit access to
these values. If it is something that I did through
software security, it was completely accidental. Since I
have had this problem from the very beginning, I am
inclined to believe the server was installed with this
registry permissions problem already in existence.
Thanks,
Keaton
2003 Standard Edition Terminal Server where a user who
belonged to just "users" and "Remote Desktop Users", but
not to an administrative group such as "Power Users", did
not receive an Explorer Desktop after logging in. All of
my TS users had to belong to at least "Power Users"
before they would receive a desktop at TS login.
So here is the solution to this problem, just in case
others have it.
It was a problem with access to certain Windows Registry
entries by normal "users" and "remote desktop users".
This is how I diagnosed and resolved this issue:
1. I went to http://www.sysinternals.com and downloaded
the RegMon program.
2. With RegMon running on the Terminal Server capturing
events, I opened up another session and logged in under a
normal "users"/"remote desktop users" account.
3. The desktop did not display, so I went back and
reviewed the RegMon log.
4. It did take time to scroll through a fairly large list
of output, but I did discover some ACCDENIED results for
the explorer.exe process during OpenKey requests for the
test user I was attempting to log in by.
5. I ran regedit and identified the folders and keys that
it had problems accessing. Some were under HKCR
(HKEY_CLASSES_ROOT) and HKLM (HKEY_LOCAL_MACHINE). I
modified the permissions to allow "users" and "remote
desktop users" the same level of access as "power users"
on the specific folders/keys that explorer.exe couldn't
access.
With the registry entries modified I tried to log in
through my test account again, and this time a full
desktop displayed. I was able to launch applications
such as Word and Excel, and in my Terminal Server session
only the printers mapped in my session were visible to me
(the original desired effect).
Exactly why the key values/folders necessary to display a
desktop for a normal user did not have the correct
permissions remains a mystery. I know for a fact that I
did not manually modify the registry to limit access to
these values. If it is something that I did through
software security, it was completely accidental. Since I
have had this problem from the very beginning, I am
inclined to believe the server was installed with this
registry permissions problem already in existence.
Thanks,
Keaton