Deploying SystemIdleCheck via GPO

Some users of SystemIdleCheck (SIC) have been confused as to how to deploy the program in large, complex environments, so I've put together this guide which details how to deploy the program through Group Policy Objects (GPO).

Overview

If you manage an Active Directory domain, there are several ways to deploy SIC:

Logon script
Registry hack
Add to startup group in each users Start menu
Group Policy Object (GPO)
(insert your method here)

In my opinion, the easiest, most reliable, and scalable method is through the use of GPO. You can control many user experience through the use of GPOs, including the functionality and application of third party programs, such as SIC. With this guide, I will use a test environment to demonstrate the procedure.

In addition to explaining the procedure, you can find a demonstration PowerShell script attached to this post.

Also attached are GPO backups from my test environment. You can import these backups to cut out most of the legwork of editing the GPOs. The backups contain each use case of SIC (Logoff, Restart, Shutdown, Lock), with the timeouts set for five minutes, with a warning at 30 seconds.

Plan

There are a couple things we need to in order to make this all work. The defaults in the PowerShell script are configured thus:

$TargetGroupPath = "OU=TestGroups,DC=test,DC=local" # Where the AD groups will be created $GPOTarget="OU=TestUsers,DC=test,DC=local" # Where to link the GPOs $SICGPOAutoRestart = "SIC Auto Restart" # Name of the Auto Restart GPO $SICGPOAutoLogoff = "SIC Auto Logoff" # Name of the Auto Logoff GPO $SICGPOAutoLock = "SIC Auto Lock" # Name of the Auto Lock GPO $SICGPOAutoShutdown = "SIC Auto Shutdown" # Name of the Auto Shutdown GPO

Be sure to change the paths and or group names to match your environment.

Active Directory Groups

We're going to want to target the GPOs as specific Active Directory groups, since we don't want the SIC to affect all users. For example, you may not want some developers or administrators to be automatically logged off, since they may have long-running scripts which will "die" when SIC executes its function and logs them off.

So we'll be creating AD security groups to apply the four different GPOs. For simplicity, I've name the groups as such:

SIC Auto Restart
SIC Auto Logoff
SIC Auto Shutdown
SIC Auto Lock

Using the variables defined above, we can use this PowerShell snippet to create the AD groups:

New-ADGroup -DisplayName $SICGPOAutoRestart -Name $SICGPOAutoRestart -GroupScope Global -GroupCategory Security -Path $TargetGroupPath New-ADGroup -DisplayName $SICGPOAutoLogoff -Name $SICGPOAutoLogoff -GroupScope Global -GroupCategory Security -Path $TargetGroupPath New-ADGroup -DisplayName $SICGPOAutoLock -Name $SICGPOAutoLock -GroupScope Global -GroupCategory Security -Path $TargetGroupPath New-ADGroup -DisplayName $SICGPOAutoShutdown -Name $SICGPOAutoShutdown -GroupScope Global -GroupCategory Security -Path $TargetGroupPath

By adding users to these groups, you will get the described behavior. In the event that you add a user to multiple groups, only the last applied GPO will take effect.

Active Directory Group Policies

This is where the action is. For simplicity, I've created four GPOs that match the Active Directory groups mentioned above:

This is where you can import the sample GPOs, if you so desire. If you'd rather play along with this guide, you can use the following bit of PowerShell to create the GPOs and link them to the proper place.

New-GPO -Name $SICGPOAutoRestart New-GPO -Name $SICGPOAutoLogoff New-GPO -Name $SICGPOAutoLock New-GPO -Name $SICGPOAutoShutdown New-GPLink -Name $SICGPOAutoRestart -Target $GPOTarget -LinkEnabled Yes New-GPLink -Name $SICGPOAutoLogoff -Target $GPOTarget -LinkEnabled Yes New-GPLink -Name $SICGPOAutoLock -Target $GPOTarget -LinkEnabled Yes New-GPLink -Name $SICGPOAutoShutdown -Target $GPOTarget -LinkEnabled Yes

Now that you've got the GPOs created and linked, you'll need to modify the permissions. If you leave the default permissions, all four GPOs will be applied to everyone in the Authenticated Users. This means everyone who successfully logs on will have the GPOs applied.

HOLD UP! Don't just edit the permissions to remove the Authenticated Users group and add your SIC group(s). Authenticated Users still need the ability to read the GPO. Why, you ask? The Authenticated Users group doesn't include just your average user object. Server objects, including domain controllers, also fall in to this category. So if you don't leave Authenticated users with at least Read permission, they won't be able to read, process, and replicate the GPO.

I've included the following PowerShell script to mod it for you.

set-gppermission -name $SICGPOAutoRestart -targetname $SICGPOAutoRestart -targettype Group -PermissionLevel GPOApply set-gppermission -name $SICGPOAutoRestart -targetname "Authenticated Users" -targettype Group -PermissionLevel GPORead -replace set-gppermission -name $SICGPOAutoLogoff -targetname $SICGPOAutoLogoff -targettype Group -PermissionLevel GPOApply set-gppermission -name $SICGPOAutoLogoff -targetname "Authenticated Users" -targettype Group -PermissionLevel GPORead -replace set-gppermission -name $SICGPOAutoLock -targetname $SICGPOAutoLock -targettype Group -PermissionLevel GPOApply set-gppermission -name $SICGPOAutoLock -targetname "Authenticated Users" -targettype Group -PermissionLevel GPORead -replace set-gppermission -name $SICGPOAutoShutdown -targetname $SICGPOAutoShutdown -targettype Group -PermissionLevel GPOApply set-gppermission -name $SICGPOAutoShutdown -targetname "Authenticated Users" -targettype Group -PermissionLevel GPORead -replace

Modifying the GPOs

Now that we've got our GPOs created, linked, and permissioned, it's time to actually make them do something. They're just blank GPOs right now, with no settings applied.

We've got four GPOs, each with a specific name, related to a specific functionality of SIC: Logoff, Lock, Restart, and Shutdown. This is where you probably should've just imported the GPOs from the backups included above!

Editing the GPOs is not hard. Crack open the Group Policy Management editor. Not the Local Policy editor on your workstation. You want to the one that controls GPO for the domain.

When you have the GPO editor open, find the SIC policy you want to edit. Right click the policy, and select Edit from the context menu. Navigate to the following branch:

Computer Configuration \ Policies \ Administrative Templates \ System \ Logon

When you have the Logon entry highlighted in the left pane, find the entry in the right pane that reads Run these programs at user logon. Double-click it.

In the window that opens, click the Enabled radio button, then click the Show button below it. This opens the contents editor. In this editor, you can run any number of programs when a user logs on to a computer, and this is where the command line for SIC goes.

To add the SIC command line, double click an empty row in the content editor and enter the full path and filename of the program you want to run, along with any command line switches that it requires. An example for SIC is shown below.

c:\admin\userscripts\sic T:300 I:30 L:Logoff

In this example, I've given the full path and filename for SIC, and configured the program to take the logoff action after five minutes of inactivity, while giving the user a warning at 30 seconds prior to the action.

Also note in this example that the path is on the local machine of wherever the user is logged in. I've configured it this way in my test environment on purpose, for ease of testing. However, I would recommend that you put the SIC executable on a network share that is marked read-only for regular domain users.

If the program is not present in the specified location, it won't execute, right? So put it somewhere that the users can't simply delete it, and thereby bypassing the automated logoff/shutdown/lock/restart functionality.

An example of specifying a network share would be something like this:

\\MyFileServer\userscripts\sic T:300 I:30 L:Logoff

This gives the same effect, but doesn't give the end user the opportunity to simply delete the file. This also gives you the added bonus of only needing to update the program in one location, rather than updating on all your workstations.

Summary

That should be about it. With this short guide, you should be able to get this program up and running in your environment pretty easily. However, as always, feel free to drop me a note if you need assistance.

About this post

Posted: 2020-03-15
By: dwirch
Viewed: 3,731 times

Comments

AnonymousCoward posted this comment on 2021-09-07:

Hello and thanks for the post. How does one run this without the system prompting to RUN the file after the user logs on?

Application is on a network share and GPO is working but user is forced to respond to "Do you want to run this file?" prompt?

dwirch posted this comment on 2021-09-07:

Which version are you running?

dwirch posted this comment on 2021-09-07:

My mistake. Looks like the codesigning certificate has expired. It'll take a couple days to renew the certificate, and I'll get the re-signed executable up on the download page.

You must be logged in to make a comment.