locked
Deploying a PowerShell script RRS feed

  • Question

  • We need to backup our users .PST files and many are of course in-use.  Since we are running Office 2010 Microsoft does not support storing .PST files on our home drives (network).   We actually tried that but kept running into major slowness and/or systems hanging for long periods fo time.

    So  I have written a PowerShell script that uses a custom written cmdlet.  This cmdlet allows you to copy "in-use" files.  And since this is dealing with the logged on user it has to run with their credentials.  The problem is this custom cmdlet requires Administrative rights to run and none of our users are admins on their local boxes.  

    How to I run a PowerShell script in the logged on users context yet run it with Admin privileges?    


    mqh7

    Thursday, August 7, 2014 1:53 PM

Answers

  • You could run the script as system.

    You can find out who's currently logged on by listing the subkeys under HKEY_USERS. The one with the long number is a real user, the ones with the short numbers are internal system and admin accounts. Then you can browse their registry subtree to find out where the PST is and copy it with ninjacopy/hobocopy.

    Or, as an alternative, you can start the script under the user by putting it in the RunOnce registry key. Scripts in RunOnce block the login from proceeding, so the next time a user logs on to his PC he is prevented from opening Outlook until the copy is done.

    • Proposed as answer by Garth JonesMVP Friday, March 20, 2015 8:49 PM
    • Marked as answer by Garth JonesMVP Wednesday, February 3, 2016 6:00 PM
    Thursday, August 7, 2014 3:26 PM
  • That question is way too specific to be answered here in the forums. Just try it and let us know if it worked.

    Torsten Meringer | http://www.mssccmfaq.de

    • Proposed as answer by Garth JonesMVP Friday, March 20, 2015 8:49 PM
    • Marked as answer by Garth JonesMVP Wednesday, February 3, 2016 6:00 PM
    Thursday, August 7, 2014 6:41 PM

All replies

  • And since this is dealing with the logged on user it has to run with their credentials.  The problem is this custom cmdlet requires Administrative rights to run and none of our users are admins on their local boxes.  


    The logged-on user either is local admin or is not.
    You could run that script in admin context (which uses 'local system'), but that's (obviously) not the currently logged-on user. What does the script exactly? Can't you run it in admin context (system) and access "something" of the currently logged-on user?

    Torsten Meringer | http://www.mssccmfaq.de

    Thursday, August 7, 2014 2:16 PM
  • I got the PowerShell cmdlet from github.  It is called NinjaCopy and you run it within PowerShell like this.

    Invoke-NinjaCopy 

    It somehow bypasses Windows security and I think works similar to Shadow Copy where it lets you copy an in-use file.  We have many computers that are shared boxes since we are a 24/7 shop.  So it is very common for a PC to have 3 or more profiles.   So if you were logged in I want to copy your .PST up to your Home drive on the network.   (note:  my PS script will only copy a .pst file that was modified %today%)

    Now, why not copy any/all .PST files found up to each users home drive?  I could read each profile on the machine and copy up to their home drive but our home drives are not all in the same place, they are in 3 or 4 different locations.    I guess I could get the profile name, if it contains a .PST file then query AD for there Home drive and copy it there.     

    My m&m sized brain just hurts thinking about all of this :(


    mqh7

    Thursday, August 7, 2014 3:01 PM
  • You could run the script as system.

    You can find out who's currently logged on by listing the subkeys under HKEY_USERS. The one with the long number is a real user, the ones with the short numbers are internal system and admin accounts. Then you can browse their registry subtree to find out where the PST is and copy it with ninjacopy/hobocopy.

    Or, as an alternative, you can start the script under the user by putting it in the RunOnce registry key. Scripts in RunOnce block the login from proceeding, so the next time a user logs on to his PC he is prevented from opening Outlook until the copy is done.

    • Proposed as answer by Garth JonesMVP Friday, March 20, 2015 8:49 PM
    • Marked as answer by Garth JonesMVP Wednesday, February 3, 2016 6:00 PM
    Thursday, August 7, 2014 3:26 PM
  • how about this:   I wrap my PowerShell script inside of an .MSI and then I use the AlwaysInstallElevated reg key to allow anyone to run .MSI files?  Would that work or does Windows not like .MSI spawning other processes from within an .MSI to run as Admins?   

    I like your first suggestion however.   And in fact I've found some code that queries WMI and finds out why has Explorer.exe open, which is the logged on user.   

    Thanks for any insight you can provide on the .MSI part of my question.  


    mqh7

    Thursday, August 7, 2014 5:20 PM
  • That question is way too specific to be answered here in the forums. Just try it and let us know if it worked.

    Torsten Meringer | http://www.mssccmfaq.de

    • Proposed as answer by Garth JonesMVP Friday, March 20, 2015 8:49 PM
    • Marked as answer by Garth JonesMVP Wednesday, February 3, 2016 6:00 PM
    Thursday, August 7, 2014 6:41 PM
  • I'd go with the registry method and forget the additional MSI package, it just adds way too much complexity for a simple task.
    Thursday, August 7, 2014 7:23 PM