Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

The objective here is to start a simple .NET application I've written which captures some environment variables (time, username, computername, etc) upon login. This .NET application subscribes to the Windows "User logout" event.

Upon launch, the application captures the above variables, and creates a record in my database, upon logout (which I'm capturing) I update another field in the same record, with the logout time.

The above is working exactly as I would like, when I launch the binary, it makes its initial log entry, then waits for the logout event and updates the same record.

Restrictions, the .NET binary should be able to live on a share point (\server\share\myapp\v1) so I can update the application to (\server\share\myapp\v2) and simply update the GPO/Logon script.

My initial thought was to use the \domaincontroller\sysvol\ directory to store the binary and then update all user accounts to include a call to my application. Can you see any flaws in this approach?

My question is this: First, is there anything wrong with my idea above? Second, if so, what is the best way (through group policy or otherwise) to ensure this application launches whenever a session is started on a server?

share|improve this question
up vote 2 down vote accepted

For launching every time a session is started, using a Group Policy based logon script will do it. The one caveat we've found is that such scripts specified in a User GPO seem to execute TWICE if 'loopback processing' is turned on for any Computer Object GPOs that apply. We've had to modify our logon scripts to handle this case as a result.

I'm not familiar with .NET event subscriptions so I don't know if that means the application file is held open for the entire session. If that's the case, then updating the app will be very difficult due to the open lock problem. If 50 stations are logged in, then the app will have 50 deny-write locks on it, and that makes updating the app harder. This is one instance where keeping the app on sysvol (in the GPO itself, actually) can help, since it handles that case better.

However, it that just means it re-fires on logout keeping it on a share should be fine.

share|improve this answer
Yes, the event subscription will keep the process running until logout, its not ideal but it is currently working how I want. How would I go about putting it in the sysvol and/or actually inside the GPO? – Nate Jun 17 '10 at 15:29
The way I go about that is to open the Group Policy Manager, browse to the Scripts option. There is a Browse button in the dialog box that causes an Explorer window with the right sysvol directory to pop up. Copy the script into that. – sysadmin1138 Jun 17 '10 at 15:33
Would I also copy my .NET application into there as well? And then if I need to update it, just replace it via the GPO editor? – Nate Jun 17 '10 at 16:15
Yes, placing compiled programs there works as well. We do this on XP stations for printers (another .NET program) and it Just Works. We haven't updated files that get continually locked, so you'll have to see if this works for you. We HAVE updated logon scripts during peak login times and had them work, so I have hopes. – sysadmin1138 Jun 17 '10 at 16:22

There's nothing terribly wrong with running it from sysvol.

And creating a gpo logon script would do exactly that by default, and also ensure that it is run. Typically terminal servers have multiple gpo's and one of those would run your logon script and specify the group policy loopback processing mode.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.