I been looking at the best way to run my powershell script to end users. If I try to copy the .ps1 file to the local c:\windows\system32 and schedule a task to run the script it fails on permissions. Yes even if I make sure I say run as Domain\Administrator…If I run powershell (run as Administrator) and run the script it works fine.
So now I decided perhaps I should just create a network share and allow the script to run there. Yes I set-executionpolicy unrestricted (just to quickly finish up this task and circle back and do it the right way) I still am unable to run the script…
First, Windows\System32 is for Windows OS files… you probably shouldn’t be putting scripts there.
Keep in mind that “Unrestricted” is not the same as “Bypass;” Unrestricted will still prompt for unsigned remote scripts.
So, let’s perhaps circle back further and figure out what your need is.
Do you want users to be able to run this script? If so, does the script need to do things that the users do not have permission to do? Or do you want this script installed on user computers, and run as a scheduled task? Is there a specific reason you wanted to put it in System32?
Basically I am prepping for an Email Migration from Sherweb to Office 365. Migration is IMAP so I loose calendar entries, contact, Signature files etc. So I decided to write a script to do the following: Shutdown outlook copy OST files, Copy Signatures files, export calendar entries, export N2k files and export contacts.
So I thought the easiest way was to run the script via a Schedule Task locally on a computer. Yes I realize the security risks and just trying to get things moving forward and figure I would circle back in the future to setup powershell for signatures (can’t recall the correct terminology).
A logon script might be the easiest way. But, the trick with most of those things will be to get the script running not as an admin, but as the user. That way the script will have access to the users’ data. Running as a scheduled task should be fine, provided you can give the task the needed permissions. There’s no need to have the script in System32, though - that’s a protected folder and Windows is a little sensitive about it. I wouldn’t describe what you’re doing as a “security risk” per se; I just think the tricky part is going to be getting the script “logged in” as the current user, so it can access that user’s data. Login scripts run under the user context, so that might be an easier way.
Yes I have thought of the Login script option and was hoping not to go there since I wanted to schedule the process after the workday.
I believe if I did the logoff it shutdowns down the drives and connections before the script is able to finish…Or I am doing something wrong.
Correct, a logoff script would not likely have enough time to run before drives and whatnot are disconnected. Thing is, a scheduled task has to run “as” the user in order to have access to their profile. And, a scheduled task won’t necessarily get the user’s connected drives and so forth, since the task doesn’t log on in the same way.
If the script needs to have access to things in the user profile, then it’ll need to run while the user is logged on, as the user. From a technical perspective, having the user run the script would be the easiest way to accomplish that.
What I would do if I were you is just use GPO Preferences. There is a preference that will allow you to place the files on the system where you need. As Don noted, the system folders may not be the best place. After that use the Task Scheduler Preference to call that PowerShell script that you are placing and make sure and give it a proper user to run as and specify the execution policy bypass. Basically, make your script rock solid and let GPO setup your framework.