• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 471
  • Last Modified:

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 scriptI 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?
0
Evan Hines
Asked:
Evan Hines
  • 4
  • 3
  • 2
  • +1
1 Solution
 
Davis McCarnOwnerCommented:
I'll try to help with the backup status first....

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\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\ProfileList\<SID-from-WHOAMI> and note the ProfileImagePath value
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.
0
 
kevinhsiehCommented:
Run the script as a startup or shutdown script. Those run under the SYSTEM account, which has administrative access. A scheduled task would work as well.
0
 
Evan HinesAuthor Commented:
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?
0
 The Evil-ution of Network Security Threats

What are the hacks that forever changed the security industry? To answer that question, we created an exciting new eBook that takes you on a trip through hacking history. It explores the top hacks from the 80s to 2010s, why they mattered, and how the security industry responded.

 
Davis McCarnOwnerCommented:
Not from what I found.  It was the deletion and recreation of the UserProfile which seems to cause it.
0
 
kevinhsiehCommented:
How are you determining that a profile is 15 days old? How are you using GPO to delete it?
0
 
Evan HinesAuthor Commented:
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.
0
 
Davis McCarnOwnerCommented:
That will cause your issue if the user does not login to the PC for 15 days.
0
 
markdmacCommented:
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.
0
 
Evan HinesAuthor Commented:
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.
0
 
Evan HinesAuthor Commented:
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.
0

Featured Post

VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

  • 4
  • 3
  • 2
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now