Number of Logins Per Day

[Blahages]

Right now, my dad has a machine which he uses, as well as my three sisters. His user is unrestricted, however, my sisters are set as restricted accounts, and I wrote a little batch file that runs on start up, hidden, which after 30 minutes displays a warning that they have 2 minutes, and they will be forcefully logged out. After the two minutes are up, the machine logs out.

They're not too technical, so none of them knows how to stop the logout. So, that's not a problem.

But, After they are forcefully logged out, they can log back in, without any problem.

My question is, I don't know if Windows logs this or not, but is there a way I can view the number of times specific users log into the machine each day? They're all supposed to be limited to three 30 minute sessions a day. I don't care about forcefully restricting them to the 3 times, BUT, I would like to be able to see if one has been logging in, say 5-6 times a day, when either nobody else is here, or nobody is paying attention.

One of them has a long history of lying about anything and everything, and I know without a doubt that on several occasions she'll log right back in, or get on 5-6 times a day. I just want something that confirms that.

I'm not looking to use any bloated third party tools, which have 500,000 "features." I just want either a way to check the number of logins manually, or something little that will tell me easily the number.

Thanks

Edited August 7, 2007 by Blahages

[Tarun]

The Event Viewer logs every login attempt, that may be of some help. It also tells you what username.

[jcarle]

I wrote a little utility for you... took me about 2 hours. (I was avoiding my real work )

It does exactly what you want and it's very effective. (I got logged out while writing this post because I forgot to turn it off while I was writing this.)

All you do is run the attached program at startup during the login of each user. I would suggest putting it in HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run so that they can't just delete the icon. Remember, this program is only effective if the application is actually run.

It will automatically keep a session log in the registry of how many times they've logged it. It will also automatically create the default limits of 3 logins per day at 30 mins per session.

You need to run the program from a user's account at least once to create the default settings. Once the default settings are created, you can change them for a specific user. Say one of your sisters was grounded, well you could put her LoginsPermitted down to 0. If someone else was allowed longer sessions, say 60 minutes, you could change the SessionLength value to 60. All settings are found in the registry in HKEY_LOCAL_MACHINE\SOFTWARE\SessionManager.

At the 2 minute mark, it will beep once. At the 1 minute mark, it will beep 3 times and the timer changes to dark red. At the end of the session, the person will be logged out. No matter what the person is doing.

Hope it solves your problem and that it works well for you. I had fun making it.

Oh and one last thing. You MUST have .NET 2.0 installed on your machine for this to run.

-- file removed (see posts below) --

Edited August 8, 2007 by jcarle

[Railman5]

jcarle

I am interested in using you neat program for my kids also.

Can you please explain the steps to this please?

All you do is run the attached program at startup during the login of each user. I would suggest putting it in HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run so that they can't just delete the icon.

Thanks

[jcarle]

jcarle

I am interested in using you neat program for my kids also.

Can you please explain the steps to this please?

All you do is run the attached program at startup during the login of each user. I would suggest putting it in HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run so that they can't just delete the icon.

Thanks

To simplify the task for you and others who may be interested with this program but aren't comfortable playing with the registry, I've updated the attachment in the post above.

The attachment now includes a folder with 5 files:

SessionManager.exe - The program executable

Install.bat - A batch file to copy the executable to C:\Windows\system32

Remove.bat - A batch file to remove the executable from C:\Windows\system32

Add To Startup.reg - A registry file which you can import to set the session manager to run from the current user

Remove From Startup.reg - A registry file which you can import to remove the session manager from the current user

Basically, if you throw this on say a USB stick or something, all you need to do after is run Install.bat to copy the program file, login as the user you want to limit, run Add To Startup.reg. Logout and login into any other additional users you want to limit and run Add To Startup.reg again.

Don't forget, this is nowhere near hack proof. But it's sufficient to act as an aid when your kids aren't old enough to go through the registry and system files.

Edited August 7, 2007 by jcarle

[nmX.Memnoch]

jcarle,

Would you have any problems with me compiling this into an actual setup/install package?

[Railman5]

nmX.Memnoch

that would be even better.

much more comfortable with that.

jcarle - would that be Ok for nmX.Memnoch to do?

Thanks

[jcarle]

Sure. Go nuts. I just lack time to do it all.

[nmX.Memnoch]

I need to figure out how to handle user configuration with the installer. You have the session settings for each user being written to HKLM\SOFTWARE\SessionManager\<domain_workgroup>\<user>. Regular users don't have permissions to change registry keys under HKLM\SOFTWARE. They also don't have permissions to add files to %SystemRoot%\system32.

Since the three accounts in question on restricted accounts they'd currently have to be made Admins temporarily to run the app the first time. I'm thinking maybe create a configuration utility that parses the local accounts and prompts for the configuration of each account. That way someone with admin privs could install and configure the application, but the settings can't be changed by the restricted users. This obviously wouldn't work in a domain environment, but how many home users have a domain?

Edited August 8, 2007 by nmX.Memnoch

[jcarle]

I never use restricted accounts so I didn't know... in that case... I need to change the way the program works because it also creates the session logs in HKLM. I'll rework it so it works around HKCU instead.

[nmX.Memnoch]

It's a good idea to keep the configuration in HKLM. That'll keep restricted users from changing their settings. But the session logs...yeah, those'll need to go in HKCU.

Let me know when you're done. In the meantime I'm going to see if I can figure out a way to right an AutoIt script to prompt for the configuration of each user on the system.

For a stand-alone (non-domain) PC does the registry path contain the workgroup or machine name? In other words, which of the following is correct?

HKLM\SOFTWARE\SessionManager\<workgroup>\

Or

HKLM\SOFTWARE\SessionManager\<machine_name>\

To me, machine name would make more sense for local accounts, but stick with domain name for domain accounts (I tested it on my PC at home and it was HKLM\SOFTWARE\SessionManager\<domain>\<user>\).

[cluberti]

Ummm.... queue up Mr. Mackey voice:

Using the registry for database storage of anything other than app settings are bad, mkay? Storing data in the registry causes the registry to grow in size, which can cause kernel memory pressure, registry corruption and fragmentation, and even an inability to boot if the hive or hives get too large to mount on boot.

Store volatile data in files, not the registry. Please .

[jcarle]

Ummm.... queue up Mr. Mackey voice:

Using the registry for database storage of anything other than app settings are bad, mkay? Storing data in the registry causes the registry to grow in size, which can cause kernel memory pressure, registry corruption and fragmentation, and even an inability to boot if the hive or hives get too large to mount on boot.

Store volatile data in files, not the registry. Please .

You need not worry. This is very very small data. The "session log" is a single byte. I'm not storing information in quantities like an application event log or a report or anything huge like that.

It's a good idea to keep the configuration in HKLM. That'll keep restricted users from changing their settings. But the session logs...yeah, those'll need to go in HKCU.

Let me know when you're done. In the meantime I'm going to see if I can figure out a way to right an AutoIt script to prompt for the configuration of each user on the system.

For a stand-alone (non-domain) PC does the registry path contain the workgroup or machine name? In other words, which of the following is correct?

HKLM\SOFTWARE\SessionManager\<workgroup>\

Or

HKLM\SOFTWARE\SessionManager\<machine_name>\

To me, machine name would make more sense for local accounts, but stick with domain name for domain accounts (I tested it on my PC at home and it was HKLM\SOFTWARE\SessionManager\<domain>\<user>\).

First, identity is written out as machine_name\username\ always when there is no domain, when there is a domain, you'll know because I don't have a domain to test it on.

I've completely reworked the registry handling. Now... it works like this...

Read HKLM for settings, if not found, read HKCU, if not found, write out default settings to HKCU and use those.

In otherwords, it never writes to HKLM and only to HKCU, however if HKLM settings exists, they will override those of HKCU.

HKLM settings are in HKLM\SOFTWARE\SessionManager\(machine_name/domain)\(user)\

HKCU settings are in HKCU\SOFTWARE\SessionManager\

And that should do it.

SessionManager.zip

[cluberti]

You need not worry. This is very very small data. The "session log" is a single byte. I'm not storing information in quantities like an application event log or a report or anything huge like that.

You say things like "session log", and I freak out - the term "session log" doesn't sound like a 1-byte endeavor .

[nmX.Memnoch]

It's a good idea to keep the configuration in HKLM. That'll keep restricted users from changing their settings. But the session logs...yeah, those'll need to go in HKCU.

Let me know when you're done. In the meantime I'm going to see if I can figure out a way to right an AutoIt script to prompt for the configuration of each user on the system.

For a stand-alone (non-domain) PC does the registry path contain the workgroup or machine name? In other words, which of the following is correct?

HKLM\SOFTWARE\SessionManager\<workgroup>\

Or

HKLM\SOFTWARE\SessionManager\<machine_name>\

To me, machine name would make more sense for local accounts, but stick with domain name for domain accounts (I tested it on my PC at home and it was HKLM\SOFTWARE\SessionManager\<domain>\<user>\).

First, identity is written out as machine_name\username\ always when there is no domain, when there is a domain, you'll know because I don't have a domain to test it on.

I've completely reworked the registry handling. Now... it works like this...

Read HKLM for settings, if not found, read HKCU, if not found, write out default settings to HKCU and use those.

In otherwords, it never writes to HKLM and only to HKCU, however if HKLM settings exists, they will override those of HKCU.

HKLM settings are in HKLM\SOFTWARE\SessionManager\(machine_name/domain)\(user)\

HKCU settings are in HKCU\SOFTWARE\SessionManager\

And that should do it.

Like I said, I think it would be best to keep the configuration strictly in HKLM. If the settings don't exist in HKLM then it should exit. That would force proper configuration of the app for each user. But that's just the way I would do it...