I've configured a local group policy on our Win2K Advanced server (running
Terminal Services) to run a script when users logoff. If I log on and log
off as an administrator, the script runs fine. If I log on and log off as a
general user, the logoff script never runs (it may attempt to run, but
doesn't generate an expected output file nor does it give any errors).

When logged on as a general user, I can access the script location
(%systemroot%\system32\GroupPolicy\User\Scripts\Lo goff and run it by
double-clicking on the .cmd file. When doing this, the script generates the
expected output file (in another location). I'm puzzled as to why this
script won't run upon logging off (unless I'm logged in as an administrator).

Is there an alternative method for invoking scripts upon logoff and/or is
there a way to debug this type of an issue?

Have you turned on the policy to disable the command prompt for users?

If so, you could have blocked scripts from running as well. Look in your
GPO and find the "User Config | Administrative Templates | System | Prevent
Access to the command prompt" policy and ensure that it is set to Enabled
with "also disable script processing" set to NO.

You might also check the permissions on the GPO itself to make sure that
users are given the Apply Group Policy right.


"Paul999" <Paul999@discussions.microsoft.com> wrote in message
news:E97847C9-2B49-47E2-90F0-0EE90209AE90@microsoft.com...

I looked at the policy for the command prompt and configured as you indicated
below (the original setting was "Not configured"). As for the permissions on
the GPO...

....where do I go to set this?

A few more notes on our configuration and testing:

- this is a member server of an AD domain (and I only have admin rights on
this box and cannot gain access to user account settings on the DC).
- I'm having the problems with the network (AD domain) accounts. As a
test, I created a local account (non-admin) and logged in with the local
account. Upon logging off, the script ran perfectly.
- I also enabled "Group Policy Loopback processing" on the server, but that
didn't seem to help with network accounts. I wanted to override any
(potential) GPO that were pushed from the DC (if any).
- I am forcing local user profiles (I don't want to download user's roaming
profile to this server)...not sure if this impacts anything.

Not sure where to look or debug steps to take at this point.


"Gabe Knuth" wrote:

So, only regular DOMAIN users are not working correctly...right?

"Paul999" <Paul999@discussions.microsoft.com> wrote in message
news:8414E03C-29CC-451E-91B2-E02F1DED15FF@microsoft.com...

Well...that's what I originally thought. As it currently stands, my domain
account doesn't work (as is the case with several other domain accounts I've
tested). However, I did find a few domain accounts for which the logoff
script worked. These are slightly different accounts (we refer to them as
"Functional" accounts), but I'm not sure at this point what the slight
difference is.

I can query AD to get group memberships and other AD settings, but don't
know if this will tell me anything.

Knowing that I am using local profiles with Group Policy loopback on, is it
possible that a Group Policy is being pushed from the domain level that's
affecting the ability of (some) domain accounts to run logoff scripts?

"Gabe Knuth" wrote:

I would say it is possible. What mode are you using in Loopback Processing?
Merge or Replace? If it's Merge, I'd change it to Replace and see if that
helps.

My guess is it's a policy override or a policy rights issue. It might help
if you configured an XP or 2003 box the exact same way as your terminal
server and ran the Group Policy Results Wizard from the Group Policy
Management Console (just google for it, it's easy to find). You may not
have the right permissions to do it, though. Worth a shot... The report
will tell you which policies are fighting and which ones are winning, or if
a policy was denied and why. You can't run it against a 2000 box,
unfortunately.

"Paul999" <Paul999@discussions.microsoft.com> wrote in message
news:AD4BEC21-315F-4E12-976E-A214818BD511@microsoft.com...