Invoke-Command and Start-Process Issues - powershell

I'm trying to execute the following script:
$Cred = Get-Credential
Invoke-Command -Computername Localhost -Cred $Cred -Scriptblock {Start "Notepad.exe" -Wait}
Well, the notepad comes up no problem as Administrator but it is not visible in the current user's account.

I think it's not possible to see gui in an interactive session with different credential, it live in another user session.
Workaround:
start-process notepad.exe -Credential $Cred

I've run into this problem with PS Remoting and could not find a way to get an app running under one set of credentials to show up on the interactive desktop of a different user. I eventually gave up and used SysInternals utility psexec along with its -i parameter.

Related

How to prompt to run EXE as different user in powershell

How would I go about running an EXE as a different user? How could I prompt for credentials or atleast ask for the password for a local admin to launch an exe through powershell. I'm having a hard time getting the runas command to work.
This was the latest thing I tried:
runas -credential .\me c:\windows\system32\notepad.exe
This works in the powershell terminal:
runas /user:asdf c:\windows\system32\notepad.exe but doesn't ask for credentials in a standalone powershell script.
This is a simple operation.
Start-Process "c:\windows\system32\notepad.exe" -Credential $(Get-Credential)
Using Get-Credential will prompt the user for credentials, You can also store it in a variable.
$Creds = Get-Credential
Start-Process "c:\windows\system32\notepad.exe" -Credential $Creds
Try following
Start-Process notepad.exe -Verb RunAsUser
change directory to .exe directory and run below command
runas /netonly /user:<domain\username> .\<app name>

“Access Denied” trying to execute a command using alternate credentials as user SYSTEM

I have a script that runs as SYSTEM, if i try to start-process notepad.exe it's working fine. if i add -credentials $cred it shows Access Denied. The credentials i pass over has local admin access, so why is there Access Denied? with procmon on powershell.exe i can not identify any access denied operation, i can see that powershell access notepad.exe with success result.
any ideas?
in one forum-post I read that it's not possible to execute a command with -credentials as SYSTEM. is that so?
if so, is there any workaround?
to my background, i use a software distribution where any installation runs as SYSTEM, from there i want to execute a powershell script as different user.
i found a solution:
$secpasswd = ConvertTo-SecureString 'password' -AsPlainText -Force
$mycreds = New-Object System.Management.Automation.PSCredential ('domain\user', $secpasswd)
Invoke-Command -ScriptBlock { Start-Process powershell c:\temp\mmc.ps1 -verb runas -wait} -ComputerName localhost -Credential $mycreds -Verbose
its not exactly what i want because here you need to enable psremoting first. but its like a workaround.
any idea how this is possible without invoke-command would be appreciated

win32_process create fails with Unknown failure for service account user

I have a windows service account user, using which i'm trying to create a background process using the WMI win32_proces. But fails with Unknown Failure.
(Tried this with administrator, nonadmin, domain admin, domain nonadmin users. works fine)
$process = [WMICLASS]"\\$computername\ROOT\CIMV2:win32_process"
$processinfo = $process.Create("powershell.exe -WindowStyle Hidden test.ps1")
Write-Host $processinfo.returncode
As explained in this msdn blog post: Win32_Process.Create fails if user profile is not loaded, the WMI call is hardcoded to access the users profile through the registry.
If the user profile is not already loaded in HKU, WMI tries to load it into the registry using RegLoadKey.
This fails unless the user account in question have the following privileges on the local machine:
SeRestorePrivilege
SeBackupPrivilege
So, either
Grant these privileges to the account in question
Call LoadUserProfile for the user in question prior to calling Win32_Process.Create
Or use Start-Process instead of WMI!
# Set up service account credentials
$Username = "domain\svcaccount"
$Password = "7oPs3çürEûN1c0deZ"
$Credential = New-Object pscredential -ArgumentList $Username,$(ConvertTo-SecureString $Password -AsPlainText -Force)
# Establish a session on the remote machine
$RemoteSession = New-PSSession -ComputerName $computername -Credential $Credential
# Launch the process with Start-Process -LoadUserProfile
Invoke-Command -Session $RemoteSession {
Start-Process 'powershell.exe' -LoadUserProfile:$true -Argumentlist 'test.ps1' -WindowStyle Hidden
}
# Cleanup
Remove-PSSession -Session $RemoteSession
Remove-Variable -Name Username,Password,Credential
To Mathias suggestions in below comments:
Start-Process works in background only when invoked through interactive prompt. If run from a .ps1 script, the process created through start-process exits if the .ps1 script exits.
Inside your script. You can create a New-PSsession and then pass this session to invoke-command to trigger start-process.
But again to use New-PSsession and ExitPSSession, you must have Enable-PSRemoting and other setting enabled if you are lacking permissions. http://blogs.msdn.com/b/powershell/archive/2009/11/23/you-don-t-have-to-be-an-administrator-to-run-remote-powershell-commands.aspx

Remote scripting credentials

I've a strange problem that I can't understand. Maybe someone will be able to explain it to me.
I'm trying to automate the installation of an app for SharePoint in a multitenant environment. I run the scripts on a remote machine like this:
$session = New-PSSession -Name "Install App Session" -Authentication Credssp -Credential $InstallAccountCredentials -ComputerName $frontend
$installAppScriptPath = Join-Path $currentScriptPath "\SharePoint\InstallApp.ps1"
$job = Invoke-Command -Session $session -FilePath $installAppScriptPath -ArgumentList $customerUrl, $env:COMPUTERNAME -AsJob
Wait-Job $job
Inside the InstallApp.ps1 I invoke the Import-SPAppPackage command but I get an "Access denied.
You do not have permission to perform this action or access this resource." error. However, if I login to the machine with exactly the same credentials that are used as $InstallAccountCredentials and start the script, everything is working perfectly fine. The account that is used for running this script is an tenant admin account.
Is there something I miss in invoking the command?
PowerShell remote doesn't work for a significant portion of the SharePoint cmdlets. Use the client object model instead - you can invoke those methods from PowerShell as needed.

Powershell script using another user account

I'm not very good with powershell (to be honest, I'm bad !) but I need to do a script which download pictures and store them in a specific shared folder. I can download the pictures easily, but the folder where I need to store them is protected and there's is only one user (created specifically) who has access on it.
So my question is : how can I configure my script to use this user credentials ? I searched on the net, but I can't understand. As I said, I'm not a powershell user, and I use OS X at home, so I'm not even good with Windows rights and permissions. So a clear and easy answer would be really appreciated !
Thank's !
Use the Invoke-Command command with the -Credential and -ScriptBlock parameters to launch a PowerShell ScriptBlock as a different account. I believe that you will also need to enable PSRemoting in order for Invoke-Command command to work, even on the local system.
$Credential = Get-Credential;
$ScriptBlock = { Copy-Item -Path c:\test\test.txt -Destination c:\test2\test.txt; };
Invoke-Command -Credential $Credential -ScriptBlock $ScriptBlock;
A more complicated solution would be to use the Start-Process cmdlet with the -Credential parameter, to kick off an external executable under an alternate credential. If you just want to kick off PowerShell code though, you're better off using Invoke-Command.
$Credential = Get-Credential;
$Executable = 'c:\path\to\file.exe';
Start-Process -FilePath $Executable -Credential $Credential -Wait -NoNewWindow;