I’m having a problem remotely executing scripts as a non administrator on the target server.
This is an portion of the scripts I’m trying to run:
New-PSSession -computername ServerA.DomainA.org -Credential $LoginCredentials
$PSServerA = Get-PSSession -computername bl ServerA.DomainA.org
Invoke-Command -Session $PSServerA -scriptblock {Add-PSSnapin Quest.ActiveRoles.ADManagement}
I get the following error:
The following error occurred while loading the extended type data file: Quest.ActiveRoles.ADManagement, C:\Program Files\Quest Software\Management Shell for AD\Quest.ActiveRoles.ADManagement.Types.ps1xml : File skipped because of the following validation exception: AuthorizationManager check failed..
This is a small part of an account creation script I’m writing. I want the helpdesk to be able to execute the script and they are not members of the administrators group on the target server although they are members of the server operators group. I can logon to the target server as them and from a Standard (non admin) PowerShell prompt I can successfully run the command the Add-PSSnapin.
The ExecutionPolicy on the target server is Unrestricted.
I have given the users Execute rights to the default microsoft.Powershell remote session configuration, this is successful as they can open the session.
So the question I have is what rights do I need to assign the users in order for them to execute the commands remotely?
You're probably running into a PowerShell double-hop restriction. PowerShell doesn't like it when you remote into a machine and then try to access another computer from there. I've never used the AD snap-in before, though. This is my best guess.
Any chance you can contact the developer's of your AD snap-in for help? They might know.
Related
First off: This is not a duplicate of How to remote execute an ELEVATED remote script in PowerShell.
My scenario is similar but different in a certain way. What I want to do is the following:
Invoke-Command -UseSSL -ComputerName "$COMPUTER" -FilePath \\script.example.com\secretshare$\install_test.ps1 -ArgumentList 'U'
As the called script performs an installation and manipulates firewall rules, it needs elevated privileges. Irritatingly the error I get is an access error on the share mentioned above.
When I use this suggestion where I use PowerShell DSC, which is run as SYSTEM, it works. But only on Servers running Windows Management Framwork 4.0. So obviously I need a solution for Windows Server 2008 (R2) systems.
I hope someone can point me to the right direction so I can update this question to help other admins aswell.
Ive never used powershell before but it seems like the correct tool to use to read the number and size of mailboxes on our 2007 and 2010 exchange servers. I'm running Powershell on Windows 7 and NOT on the exchange server. The commands used in the examples i have found are not recognised.
From my initial reading it appears i need the Exchange snap in. However, i can't seem to find a download page or instructions for loading it into Powershell, or if it is even possible to access this data from a workstation other than the exchange server. I was wondering if some one could give me some feedback on my problem and point me in the right direction.
thanks.
I have gotten this to work on windows 7 64 bit with exchange 2007 64
I installed the exchange management console via the exchange server 2007 installation files
you don't need to establish a remote powershell session, you run the commands with a domain/network administrator privileged powershell on the workstation.
I'm trying to get just the powershell snapin as I don't need the whole console, but as of right now, with the whole console and powershell you can load the exchange management snapin to powershell and create mail-enabled user accounts.
after installing the exchange management console you can execute
add-pssnapin microsoft.exchange.management.powershell.admin
to load the exchange snapin and begin pulling exchange data.
on top of that you may need to start the service on the exchange server "microsoft exchange system attendant"
i guess you need to establish a powershell remote session to the exchange server and run your powershell cmdlets.
You can start with having a look at the help about remote powershell
PS C:\Windows\system32> help about_Remote
Once you establish a remote powershell session to the exchange server you can add the Exchange Management Shell snap-in from Windows PowerShell
Click Start, click Programs, and then click Windows PowerShell 1.0, Click Windows PowerShell, Type the following command:
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.Admin
Use the chdir command to change to the Exchange Server\Bin directory. For example, type:
chdir "c:\program files\microsoft\exchange server\bin"
Type the following command:
.\Exchange.ps1
Once the exchange module is loaded you can start using the various cmdlets.
I had the same problems when I was first trying to get this work, and it was never clear to me what I needed to do.
I was very new to Powershell and was trying to run the add-pssnapin without first creating a new session.
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://EXCHANGE-SERVERNAME/PowerShell/ -Authentication Kerberos -Credential $myCred
Import-PSSession $Session
Where the -ConnectionUri points to your exchange server name and the $myCred holds your admin credentials to access the server.
This will import all modules you can use against MS Exchange.
Note1: you can narrow this down to improve the speed of the import by only selecting to import certain modules you will be using. Good if, for example, you know you will only use certain tools.
You can do this by adding -CommandName and list necessary aliases you want to import.
Note2: Good practice to remove the sessions after you are finished:
Remove-PSSession $Session
I am trying to use the Invoke-Command powershell cmdlet to install a MSI installer. From within powershell on the local machine and from the proper directory, the following works:
./setup /quiet
The following does not seem to work:
$script =
{
param($path)
cd "$path"
& ./setup /quiet
return pwd
}
return Invoke-Command -ComputerName $product.IPs -ScriptBlock $script -Args $sourcePath
For test purposes I am working on the local machine passing in "." for the -ComputerName argument. The paths have been verified correct before passing in to Invoke-Command, and errors generated on different versions of this code indicate the paths are correct. I have also tried with and without the "& " on the remote call to setup. Other Invoke-Command calls are working, so I doubt it is a permissions issue. I have verified that the return from the pwd call is the expected directory.
How do I get the install to work?
What error (if any) are you receiving? Unfortunately, you must run the shell as admin on your local machine to be able to connect to your local machine with invoke-command or any WINRM based command that requires administrative privilege (this is not a requirement when connecting remotely).
When connecting to loopback, I believe it is unable (for some security reason) to enumerate groups and determine if you are in an admin enabled AD or local group, which is how it auto elevates when invoking on a remote machine. The only solution may be to have a conditional which checks for localhost and if so, don't use the -ComputerName parameter.
This GitHub Issue covers it
You might try using Start-Process in your script block:
cd $path
start-process setup.exe -arg "/quiet"
Not sure if you will want or need to wait. Look at help for Start-Process.
I have had weird issues when trying to remotely execute a script on a local machine. In other words, remote powershell to the local machine. It comes back with an error that seems to say that PowerShell remoting is not enabled on the machine, but it was. I can run the script remotely from another machine to the target, but when using remoting to the same box, the issue crops up.
Verify that the WinRM service is running.
Verify powershell remoting has been enabled as in Enable-PSRemoting -force.
Verify your powershell execution policy is loose enough as in Set-ExecutionPolicy Unrestricted, for example. If the policy was set to RemoteSigned, this might be the problem.
You might also want to verify the user you are running the script as (locally, but using remoting) has privileges to "log on as a service" or as a batch job. Just guessing there, if the above list doesn't solve anything.
I am trying to execute an exe on machine B from machine A. I have logged on to machine A as userx and trying to run the exe on machine B as usery.
usery is system admin on machine A as well as B.
i tried using PsExec to execute an exe as well as invoke-command to execute a script in both the case am getting access denied exception in spite on passing credential of usery in both case
invoke-command -computername "machineB" -scriptBlock { c:\psscript.ps1 } -credential $useryCred
psExec \\machineB c:\exec.exe -u usery -p ypass
what am i doing wrong ?
Update:
simple scripts gets executed with out any hassle but this script is trying to create a process on remote machine under the userY's credential !
is it something related to mapping of incoming request to different user say guest ?
regards,
jeez
are there 3 machine's involved? it sounds like you are remoting from A to B and the script on B is remoting to C - is that right?
How are you supplying the credentials (for userY)?
I wonder if it's double hop related... if it is and your on windows 2008 you can try using CredSSP.
Here's some links to help explain it better than I would:
http://www.ravichaganti.com/blog/?p=1230
http://blogs.msdn.com/b/powershell/archive/2008/06/05/credssp-for-second-hop-remoting-part-i-domain-account.aspx
http://blogs.msdn.com/b/clustering/archive/2009/06/25/9803001.aspx
and Get-Help credssp displays the commands that you'll need.
HTH,
Matt
I have the following line of code to create object to access to a remote server before I associate it with user name, password and process:
$process = [WMIClass]"\\remoteServer\ROOT\cimv2:Win32_Process"
I tried this on two PCs, one is OK without any errors, but another one I am going to run has an exception:
Cannot convert value "\\remoteServer\ROOT\cimv2:Win32_Process" to type "System.Manage
ment.ManagementClass". Error: "Access is denied. (Exception from HRESULT: 0x800
70005 (E_ACCESSDENIED))"
The remoteServer is the same one. Not sure what I have to set on local PC or remote PC to make this work? On both client PCs, the user names are all member of Administrators.
Have you considered looking into PowerShell remoting? If your running PowerShell 2.0 I'd recommend that you take a look at it. Once you have set up remoting you'll be able to execute commands on the remote server using the Invoke-Command:
Invoke-Command -ComputerName {serverName} –ScriptBlock { commands }
The ScriptBlock can contain any powershell commands so you will be able to start processes on the remote machine with this mechanism. To enable remoting you'll need to use the Enable-PSRemoting cmdlet and you can get details of this at http://blogs.msdn.com/powershell/archive/2009/04/30/enable-psremoting.aspx and http://technet.microsoft.com/en-us/library/dd819498.aspx
Is there some reason you don't want to use psexec?
http://technet.microsoft.com/en-us/sysinternals/bb545027.aspx
I know this is an old post, but what I think you need to do is run the following command on the remote machine:
"Get-ExecutionPolicy"
it sounds like its set to "Restricted" which means it will not run any "Invoke-Commands" commands, or remote scripts.
You can change it to 1 of 7 options:
Unrestricted____(least secure but if you need to troubleshoot set this option)
RemoteSigned__(will only all scripts with a signature, this a so so option)
AllSigned______(Best option if youu need to run remote scripts, but all will beed signed)
Restricted_____(I believe this option is set by default in windows 7 nad WS2k8)
Default
Bypass
Undefined