asked on Administrative Rights to Single Logon Script
Greetings, Experts!
A few months ago a few experts helped me develop a script to delete user profiles that were in backup status (found here). I have that script set to execute upon user login. That script works great, but only if logged in by an administrator. I have group policies set to prevent student access to registry editing, so each time a user logs in, the script is denied access to the registry![Output when running script]()
I have played around with a few workarounds, but so far have not been successful in making it work in my managed environment.
For example, I have found that if while logged in as a student and right-click on the file while holding the shift key that the option to run as a different user appears. When the proper credentials entered, it executes just fine. I just can't figure out how to make it work through Group Policy.
My clients are all running Windows 7 Professional and DCs are 2008 R2.
This wouldn't be an issue if the user profiles wouldn't end up in backup status...if I could prevent it from happening in the first place then that would be ideal. This is just a band-aid solution.
Any ideas?
A few months ago a few experts helped me develop a script to delete user profiles that were in backup status (found here). I have that script set to execute upon user login. That script works great, but only if logged in by an administrator. I have group policies set to prevent student access to registry editing, so each time a user logs in, the script is denied access to the registry
I have played around with a few workarounds, but so far have not been successful in making it work in my managed environment.For example, I have found that if while logged in as a student and right-click on the file while holding the shift key that the option to run as a different user appears. When the proper credentials entered, it executes just fine. I just can't figure out how to make it work through Group Policy.
My clients are all running Windows 7 Professional and DCs are 2008 R2.
This wouldn't be an issue if the user profiles wouldn't end up in backup status...if I could prevent it from happening in the first place then that would be ideal. This is just a band-aid solution.
Any ideas?
Windows 7Windows Server 2008OS Security
Last Comment
Evan Hines
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
ASKER
Running the script as a scheduled task with a local account occurred to me late last night. I am currently testing it.
We currently have a group policy in place that automatically removes policies that are more than 15 days old. Could that be contributing to the cause of the .bak profiles?
We currently have a group policy in place that automatically removes policies that are more than 15 days old. Could that be contributing to the cause of the .bak profiles?
Not from what I found. It was the deletion and recreation of the UserProfile which seems to cause it.
How are you determining that a profile is 15 days old? How are you using GPO to delete it?
ASKER
The GPO setting is
Computer Configuration > Policies > Administrative Templates > System > Delete user profiles older than a specified number of days on system restart : Enabled : Delete user profiles older than (days) : 15
We do that for basic system cleanliness and to speed up our summer computer data cleaning. It's really not necessary.
Computer Configuration > Policies > Administrative Templates > System > Delete user profiles older than a specified number of days on system restart : Enabled : Delete user profiles older than (days) : 15
We do that for basic system cleanliness and to speed up our summer computer data cleaning. It's really not necessary.
That will cause your issue if the user does not login to the PC for 15 days.
I agree with the advice given above to run the script as a startup script. Then you just to to remotely reboot the computers to initiate a cleanup.
ASKER
Previously during the year as part of our routine maintenance we would go through and remove the User folders of the users that are no longer going to use the computers. Our decision to do this was because it was quicker than using the GUI to remove them one at a time (and it was before we ran across the DelProf2 program). That resulted in us having registry entries without corresponding user folders. And from what has been said so far here, that is probably what is causing our issue.
We are currently taking a lab of computers and manually synchronizing the registry keys with the Users folders. We will monitor it for a few days to see if they manually stay in check and if we continue to have any issues with those computers.
As for the original issue of getting the batch script to run while a non-admin user is logged in, the scheduled task is working perfectly. I'll update with results of our test in a few days.
We are currently taking a lab of computers and manually synchronizing the registry keys with the Users folders. We will monitor it for a few days to see if they manually stay in check and if we continue to have any issues with those computers.
As for the original issue of getting the batch script to run while a non-admin user is logged in, the scheduled task is working perfectly. I'll update with results of our test in a few days.
ASKER
In addition to the answer to the question the other information about having non-synced user profiles & their respective registry keys was also causing issues. By synchronizing the user profiles and scheduling a task to delete the backup profiles regularly, nearly all of my profile-related issue have been resolved.
First, fix one of the users and login to that account
cmd<ENTER>
Run "WHOAMI /USER" to determine the user's SID.
Either login as an admin or invoke REGEDIT with admin credentials
Check the ProfileImagePath value under the following registry key
HKEY_LOCAL_MACHINE\SOFTWAR
Search the ProfileList key for that value and delete any other SID´s, that point to the same ProfileImagePath.
The problem is caused by multiple creations and deletions of the same username. It seems that the ProfilePath remains in the registry, even after the user has been deleted.
If that is too tedious or doesn't solve the problem, you can run your script as a scheduled task with local admin credentials which will then work.