Good afternoon,
I have a script I am running at the moment and in my script there are two lines of code.
The first line installed OneDrive with admin privileges without asking for permission (bypasses UAC).
The second line runs the application.
My problem is when the second line is run it will state the following:
"OneDrive can't be run using full administrator rights - Please restart OneDrive without administrator rights"
Start-Process -FilePath "$env:USERPROFILE\Downloads\OneDriveSetup.exe" -ArgumentList “/peruser /childprocess /cusid:$cusid /silent” –wait
[System.Diagnostics.Process]::Start($newexepath) | Out-Null #$newexepath = "c:\users\test\appdata\local\microsoft\OneDrive\OneDrive.exe"
Is there a way to stop the process in line one when it is finished, basically telling the script to forget about bypassing UAC?
You may try to disable administrative rights temporary by using “net user administrator /active:no” in cmd command. Then, try to relaunch the OneDrive client and see whether it helps. If so, you can reactive administrative rights by using “net user administrator /active:yes” in cmd command. It should help on this issue in OneDrive.
In addition, I also found that the problem could be caused due to the highest privileges settings in Task Scheduler. You can search Task Scheduler from Start and click “Task Scheduler Library”. Then find OneDrive in the list and double click on it. In the window open, make sure “Run with highest privileges” option is unchecked and click OK to save the setting. After your reboot the computer, the error message should be gone.
Related
Firstly: I have found a number of questions answered that do everything but allow me to bypass UAC. I am IT for a small business, but it is not my primary responsibility.
I have two machines in my domain that on startup often fail to correctly connect to the domain network. Restarting the network adapter fixes the issue until the machine restarts. Unfortunately, one of the machines is used by a non-admin, and a technically illiterate one at that.
I hoped to use a powershell script to do this. Using this website, I created script and batch files to solve the issue. Since the computer only has one network adaptor, I went simple:
internet.ps1
Get-NetAdapter | Restart-NetAdapter
internet.cmd
#ECHO OFF
SET ThisScriptsDirectory=%~dp0
SET PowerShellScriptPath=%ThisScriptsDirectory%internet.ps1
PowerShell -NoProfile -ExecutionPolicy Bypass -Command "& {Start-Process PowerShell -ArgumentList '-NoProfile -ExecutionPolicy Bypass -File ""%PowerShellScriptPath%""' -Verb RunAs}";
Unfortunately, I don't fully understand the last command in the batch file. As such I struggle to research the command to pass some form of user credential. This environment is not very secure. But I don't want to give this user domain admin permissions generally, or provide them with some admin credentials which would end up on a sticky note. Either option is just inviting trouble from my older, technically illiterate colleagues. And going over to punch in credentials every day is time consuming.
I am looking for a script that cycles the network adaptor and provides the necessary credentials to make that change so a non-admin user can fix their domain and internet access without having admin credentials on a post-it note.
You could schedule a task using the Task Scheduler in Windows. When scheduling a task, you can specify credentials for the task to use when it runs. You can add a trigger for this task to have it run when the computer starts, or you can simply allow the user to manually start it.
If you decide to go this route, there is a check box you can check that runs the program with the highest possible privileges. The entire point of that last line is to start a new PowerShell window that runs as administrator so it actually has permission to restart the adapter. This means that you can get rid of almost your entire script, and just keep the part that actually restarts the adapter.
For example, when you go to create a new task in Task Scheduler, under the Actions tab, you can create a new action and enter the following:
Program/script:
PowerShell
Add arguments:
-Command "Get-NetAdapter | Restart-NetAdapter"
Note: I'm not sure if this is still the case, but in my past experience, sometimes it will try to run before Windows is fully loaded. If it doesn't seem to be doing anything on startup, you may need to add a delay to it. You can do this by running the Start-Sleep command. You can add it to the arguments field by doing the following:
-Command "Start-Sleep 5; Get-NetAdapter | Restart-NetAdapter"
Replace the number 5 with how many seconds you would like it to wait.
I startet to look around but only found usage with a prompt. But as this is for the users I was wondering if I can make it run without a prompt still with elevated privileges behind.
Start-Process powercfg.cpl -Verb runas
this is a simple oneline but this prompts for creds can I somehow tell it just to run elevated without a prompt
Update1: We are thinking of creating a AD User which has only rights for the needed task than can be shared for this prompt.
Update2: WE figured out that pre installed Toshiba software was causing it to jump back after restart and after every edit. We deinstalled the software and since there was no need to run it as admin anymore.
I'm attempting to run a Powershell script as the SYSTEM account as a scheduled task, and the task runs OK, but the script runs incorrectly because it does not load some Citrix Powershell snap-ins that are needed when run as SYSTEM, but runs OK as my user account.
The script does a check to load the Citrix snap-ins, but those do not appear to work when run as SYSTEM.
if ((Get-PSSnapin "Citrix.Common.Commands" -EA silentlycontinue) -eq $null) {
try { Add-PSSnapin Citrix.* -ErrorAction Stop }
catch { write-error "Error Citrix.* Powershell snapin"; Return }
Is there anything special I need to do to get those Snap-ins loaded correctly? I'm calling the script like this, if it matters: powershell.exe -executionpolicy bypass -file C:\path\to\script.ps1.
EDIT: From running (Get-PSSnapin -registered).count as both SYSTEM and my user account, I can see that the snap-ins are loaded correctly, but still can't figure out why the script behaves differently.
OS is Server 2016, version 1607, this is the script: https://gist.github.com/4oo4/85cec464e123d7f2793745e662d6e7ab
This isn't the answer why your specific script doesn't work under the SYSTEM account but explains how you might troubleshoot your (or any other) PowerShell Script under the SYSTEM account.
Give a man a fish, and you feed him for a day. Teach a man to fish,
and you feed him for a lifetime.
The whole thing around this, is that you can actually open a interactive PowerShell command prompt under the SYSTEM account were you probably not aware of.
Run PowerShell as SYSTEM
There are a few ways to start a interactive PowerShell command prompt but probably the easiest one is using PsExec.
Using PsExec
Download
PsTools
Extract PSTools.zip and just copy PsExec into your executable path
Run PowerShell as Administrator (accept the User AccountControl prompt)
In the PowerShell administrator window, give the command: .\PsExec -i -s -d PowerShell
A new PowerShell command window will open:
(Type WhoAmI to confirm the current account)
From here you can troubleshoot the specific script:
Are there any errors when running the specific script?
Does it hang or crash at a specific command?
Are there any differences with running it under a user account?
If it appears that the script runs actually fine in the SYSTEM window, then I would check for any errors in the Task Scheduler:
Select Task Scheduler Local - Task Scheduler Library in the left pane
Select your task in the middle top pane
(Make sure you have Display All Task History in the right pane Enabled)
In the middle bottom pane check the events in the history tab
I've have created a Powershell script that automatically connects to office 365 and sets all users default calendar permissions to reviewer. this script runs perfectly when executed manually.
but
I am trying to launch the powershell script via task scheduler on WS-2012-R2.
i run the task but when i check a test users calendar permissions its still the same "contributor".
When task scheduler starts the task, it creates a process, that process is given a process ID.
i went to check the ID in task manager it showed as "Pick an App" under the processes tab.
i right clicked and clicked details and it shows as OpenWith.exe
i checked file association and (.PS1) is associated to WindowsPowershell
i went to the scripts file location in explorer, Rclicked and changed the OPenWith from POwershell to Windows Powershell ISE and i still get the same thing when i run through task sheduler. ("pick and app & OPenWith.exe")
i have tried editing the "actions" in Task Manager to a combination of things such as.
In task shceduler properties
Program/script: was set to: C:\Powershell script\default reviewer permissions
this doesnt work
then i changed that to C:\Windows\System32\WindowsPowerShell\v1.0\POwershell and also PowerShell_ise
with C:\Powershell script\default reviewer permissions in the "add arguments (optional) section.
and visa versa
Can anyone please tell me what i can do to make this script run.
Many thanks
What happens when you launch PowerShell from a command-line (CMD and not a PowerShell Session) like:
powershell -?
as this should show the syntax needed?
For example, mine shows (Removing the extra help information):
PowerShell
[-File ]
Specifically:
-File
Execute a script file.
You should be using something like in your Scheduled Task (note: the use of quotes as well):
PowerShell -File "D:\WORK\ps\webtest.ps1"
Hope this helps!
Alright, so, I've been searching online forever, and I can't find anything on this at all.
Basically, what I want to do is run a program from an elevated PowerShell script, but I want the program to run as the standard user.
I need to do this because the program that I need to run requires access to a mapped network drive that the domain administrator accounts don't have access to. So, I basically need a line of code that will take the script out of elevated mode, or some extension to the Start-Program command that will make it run as the logged on user rather than the administrator account that the script is running from.
you could use psexec
psexec -l powershell.exe -executionpolicy unrestricted -noexit -file c:\temp\checkelevated.ps1
-l : Run process as limited user (strips the Administrators group and allows only privileges assigned to the Users group). On Windows Vista
the process runs with Low Integrity.
One way that I have used extensively in the past is to create a scheduled task on the fly specifying the currently logged user as the account that will run the task. The task would run some other script, command, etc. and it would occur in the context of the logged on user. This is possible by using Start-Process to call the schtasks.exe program that will...
Create the task (schtasks /create /tn "MyTask" /tr "powershell -file...." /ru "domain\username")
Run the task (schtasks /run /tn "MyTask")
Delete the task (schtasks /delete /tn "MyTask")
You would just need your script to get the current user, which can be done in a number of different ways. I've also put a 2 second pause in between those calls to schtasks just to ensure they all run.
There are more ways to do it (probably some even better) I guess, but this should also work.
If you need to run an executable or script under currently logged in user from an elevated environemnt, you can use RunAs with USERNAME environment variable passed as user argument:
runas /user:%USERNAME% program.exe
USERNAME environment variable should contain currently logged in user even in an elevated environment.
The generally intended and accepted way to do this is to specify the network UNC path instead of the network drive. You can even re-map the drive in the elevated process if you need it. That's how you're supposed to do it. If you have an account running a process that needs access to a network location, the proper answer is to grant that account the access it needs to do it's job.
However....
Does this or this or this describe the problem you're actually having? It's very unclear what you're trying to do. You've eliminated all context from your question.
If you're trying to run a script that needs to run elevated and needs to access the user's network drive and you can't use a UNC path for whatever reason, then the above three links are what you probably want.
If you really, truly need to impersonate a logged on user -- and I really struggle to think of a situation where I'd need to do this from a script -- then read on.
The alternatives that don't require knowledge of user credentials are:
Use a user logon script instead of a computer startup script. If necessary, grant the local user the permissions they need to run the rest of the script. I can't imagine you haven't thought of this already.
Create a scheduled task which runs as "Domain Users" or some other group that represents the users in question and the "Only run when logged on" is checked. Again, you'd need to grant the user the permissions they need to run the rest of the script, but it wouldn't tie you down to logon only.
Write a program which calls ImpersonateLoggedOnUser, which requires SeImpersonatePrivilege (Administrators have this by default, IIRC). These are native Win32 calls, not .Net, so they will not be straightforward to use in PowerShell. It's been about a decade since I've looked at this, and it used to be a huge pain because it would sometimes still prompt for credentials. I have to think that the increased security in Vista and later (UAC, et al) would have made this even worse. I also have no idea if you have access to mapped drives (i.e., if the impersonation survives network hops). I would choose this method approximately never.
For anything else, I think you will require credentials of the current user. What you'd be doing is credential hijacking, and OS security is specifically designed not to allow that.