Running PowerShell issue

This topic contains 6 replies, has 3 voices, and was last updated by Profile photo of Allan Miller Allan Miller 2 years, 4 months ago.

  • Author
    Posts
  • #17348
    Profile photo of Mark DiPofi
    Mark DiPofi
    Participant

    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...

    After looking at Run Power Scritps from a Shared Directory http://blogs.technet.com/b/heyscriptingguy/archive/2012/10/29/how-to-run-powershell-scripts-from-a-shared-directory.aspx I seem to be missing something since I do not see where in "In Group Policy Management Editor, you'll find this policy setting under both the Computer Configuration and the User Configuration sections in the following path:

    \Windows Components\Internet Explorer\Internet Control Panel\Security Page\ Intranet Sites: Include all network paths (UNCs
    "

    I don't see this setting and frankly getting frustrated. I am new to Powershell so still learning as I am trying to accomplish as task.

    Any suggestions on how to overcome this.

  • #17350
    Profile photo of Don Jones
    Don Jones
    Keymaster

    Sounds like a problem indeed.

    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?

  • #17355
    Profile photo of Mark DiPofi
    Mark DiPofi
    Participant

    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).

    So I am going in circles.

  • #17356
    Profile photo of Don Jones
    Don Jones
    Keymaster

    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.

  • #17357
    Profile photo of Mark DiPofi
    Mark DiPofi
    Participant

    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.

    Any other suggestions?

  • #17358
    Profile photo of Don Jones
    Don Jones
    Keymaster

    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.

  • #17359
    Profile photo of Allan Miller
    Allan Miller
    Participant

    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.

You must be logged in to reply to this topic.