On the non-domain server SERVER I have a local administrator account USER.
On the domain client machine I am running as a domain user.
Using the following code I attempt to view all services on SERVER
$cred = Get-Credential "SERVER\USER"
Invoke-Command -ComputerName SERVER -ScriptBlock {Get-Service} -Credential $cred
However, I receive the following error
Cannot open Service Control Manager on computer '.'. This operation might require other privileges.
+ CategoryInfo : NotSpecified: (:) [Get-Service], InvalidOperationException
+ FullyQualifiedErrorId : System.InvalidOperationException,Microsoft.PowerShell.Commands.GetServiceCommand
Yet, if I RDP to SERVER as USER, I can manually open a Powershell window and run Get-Service without any issues. What's going on?
When remoting cross-domain, the remote command/session will not run with administrative rights. Even though you're connecting as a local admin, the resulting PSSession will not be elevated.
To fix this, you need to set the registry key LocalAccountTokenFilterPolicy located in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System to 1. See Microsoft for more details
Related
The following code works fine when I run it in the PowerShell ISE as Administrator (i.e. I start the PS ISE as Admin)
Invoke-Command -ScriptBlock {[IntPtr]::Size}
Invoke-Command -ScriptBlock {[IntPtr]::Size} -ComputerName $env:COMPUTERNAME -Credential $Credential
Invoke-Command -ScriptBlock {[IntPtr]::Size} -ComputerName $env:COMPUTERNAME -Credential $Credential -ConfigurationName Microsoft.PowerShell32
I get the expected responses of
8
8
4
This tells me that WinRM is correctly configured and running, and that my $Credential is correctly setup. However, when I try running the same in the PS ISE as a user (with or without Admin rights) I get the following errors for the second and third commands
[<ComputerName>] Connecting to remote server <ComputerName> failed with the following error message : Access is denied. For more information, see the about_Remote_Troubleshooting Help topic.
+ CategoryInfo : OpenError: (<ComputerName>:String) [], PSRemotingTransportException
+ FullyQualifiedErrorId : AccessDenied,PSSessionStateBroken
I will be substituting the ScriptBlock code with something more substantive, that needs to run in 32 bit mode because of dependencies on 32 bit DLLs, and the ability for users to run some of the code in 64 bit mode and other parts in 32 bit mode is important.
Any thoughts?
PSRemoting uses an endpoint, or session configuration, on the remote computer. You're obviously aware of this, as your third command includes the ConfigurationName parameter. These endpoints -- Microsoft.PowerShell, Microsoft.PowerShell32, etc. -- include permissions on them that indicate who can connect to them.
Go to your remote computer (your local computer in this instance), and run Get-PSSessionConfiguration and take a look at the Permission property. You'll quickly realize that you administrative access is a requirement. This is by design; it's a good thing!
Your options are to one, edit the endpoint(s) and add your user(s), two, grant required access to your user (whether that be Admin or potentially Remote Management Users access), three, use a credential object when you run Invoke-Command, passing the credentials, or four, creating your own endpoint with the necessary permissions.
I was trying to establish a remote connection to another system and execute some basic commands.
Below are the steps that I have done :
Configured the remote machine to accept Shell commands - Enable-PSRemoting –
Force
Tested the configuration on remote machine - Test-WsMan COMPUTERNAME.
Executed the following commands on the host machine :
1.Invoke-Command -ComputerName COMPUTERNAME -ScriptBlock { Get-ChildItem C:\ } -credential USERNAME.
2.Invoke-Command -ComputerName COMPUTERNAME -ScriptBlock { Get-ChildItem C:\ } -credential $Credentials.
3.Invoke-Command -ComputerName COMPUTERNAME -ScriptBlock { Get-ChildItem C:\ }
In all the cases, we were getting access denied error :
Access is denied. For more information, see the about_Remote_Troubleshooting Help topic. + CategoryInfo : OpenError: (:) [], PSRemotingTransportException
+ FullyQualifiedErrorId : PSSessionStateBroken
From MSDN:
Start Windows PowerShell as an administrator by right-clicking the Windows PowerShell shortcut and selecting Run As Administrator.
The WinRM service is confi gured for manual startup by default. You must change the startup type to Automatic and start the service on each computer you want to work with. At the PowerShell prompt, you can verify that the WinRM service is running using the following command:
get-service winrm
The value of the Status property in the output should be “Running”.
To configure Windows PowerShell for remoting, type the following command:
Enable-PSRemoting –force
In many cases, you will be able to work with remote computers in other domains. However, if the remote computer is not in a trusted domain, the remote computer might not be able to authenticate your credentials. To enable authentication, you need to add the remote computer to the list of trusted hosts for the local computer in WinRM. To do so, type:
winrm s winrm/config/client '#{TrustedHosts="RemoteComputer"}'
Here, RemoteComputer should be the name of the remote computer, such as:
winrm s winrm/config/client '#{TrustedHosts="CorpServer56"}'
You should check if the winrm is running. Also add your remote hosts to the trusted hosts list (or your local machine).
Hope that helps.
I am currently trying to import a SharePoint 2013 site into a single server farm via the Import-SPWeb PowerShell cmdlet. It is a pretty straightforward process, except the twist is that I need to do it remotely from another machine by using Invoke-Command. This remote machine calls Invoke-Command and invokes the following script on the SharePoint server, which I called SPOINT13SSS.
Below you will find the content of both the call and the script.
CALL (from remote machine to SPOINT13SSS):
Invoke-Command -ComputerName SPOINT13SSS.sandbox.local -Authentication CredSSP -Credential $spusercreds[0] -ArgumentList "SPOINT13SSS" -FilePath C:\Users\rsmith\Desktop\SPScripts\Framework\Create\Create_SPSite.ps1
SCRIPT:
$spserver = $args[0]
Add-PSSnapin Microsoft.SharePoint.Powershell
Write-Host "[INFO] SP Server is $spserver"
Write-Host "[INFO] Beginning Import of the Site Collection into SharePoint for testing..."
try{Import-SPWeb http://$spserver -Path C:\SP13Install\siteexport.cmp -UpdateVersions Overwrite}
catch{Write-Error "[ERROR] Importing the Site Collection failed. Please make sure that the siteexport.cmp file exists and that you have proper access permissions to both the file and the SharePoint database."}
The issue I'm having - When I run
Import-SPWeb http://$spserver -Path C:\SP13Install\siteexport.cmp -UpdateVersions Overwrite
on SPOINT13SSS, the import works just fine, no flaws.
When I run it remotely, however, I get the following error:
Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))
+ CategoryInfo : InvalidData: (Microsoft.Share...CmdletImportWeb:SPCmdletImportWeb) [Import-SPWeb], UnauthorizedAccessException
+ FullyQualifiedErrorId : Microsoft.SharePoint.PowerShell.SPCmdletImportWeb
+ PSComputerName : SPOINT13SSS.sandbox.local
I have made sure that the user I am authenticating with via CredSSP has the following privileges:
Farm Administrator
Site Collection Administrator
Local Administrator on SPOINT13SSS
I am also 100% sure that the credentials are correct because I have other scripts called via Invoke-Command with this PSCredential and they work fine.
In addition, I have also tried fiddling with the NTFS Permissions on C:\SP13Install\siteexport.cmp (Everyone - Access Full control) and can't seem to get this to work. I also attempted to share the folder. I can access it from the remote machine, read and write to it, but I just can't Invoke this command from the remote machine to SPOINT13SSS.
I solved the issue by assigning the account as the service account for the web application pool where the site collection resides and resetting IIS via iisreset /noforce
I've created a new VM in Windows Azure to use to act as a host to learn a bit of Powershell Remoting. After the VM was created I RDP'd onto the box and enabled remoting via the following command:
Enable-PSRemoting
I confirmed both prompts with 'a' replies and it finished without errors. If I run
Get-PSSessionConfiguration
I can see that three endpoints (?) have been set up. In the Azure portal I can see that the Powershell port is open - both 5986 is open as a public and private port.
I've added the public IP address of the machine to my hosts file, but when I try the following:
Enter-PSSession -ComputerName AZURESERVERNAME
I get an error:
Enter-PSSession : Connecting to remote server AZURESERVERNAME failed
with the following error message : A specified logon session does not
exist. It may already have been terminated. For more information, see
the about_Remote_Troubleshooting Help topic. At line:1 char:1
+ Enter-PSSession -ComputerName AZURESERVERNAME
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (AZURESERVERNAME:String) [Enter-PSSession],
PSRemotingTransportException
+ FullyQualifiedErrorId : CreateRemoteRunspaceFailed
I've also tried setting all hosts as trused as follows:
cd wsman::localhost\client
Set-Item .\TrustedHosts *
Restart-Service WinRM
But that doesn't seemed to have helped either.
Is there anything else I need to do to get this working?
Thanks
OK, figured this out thanks to the awesome Secrets of Powershell Remoting ebook. Looks like you must add the machine directly to the TrustedHosts via IP address:
Set-Item -Path WSMan:\localhost\Client\TrustedHosts -Value '11.22.33.44'
Then use that IP address and specify credentials in the Enter-PSSession:
Enter-PSSession -ComputerName 11.22.33.44 -Credential 11.22.33.44\username
You should then get a prompt for your password and voila! :)
I've successfully created a SharePoint farm in Azure using the scripts from Automated-Deployment-of-SharePoint-2013-with-Windows-Azure-PowerShell
On that page there are steps that configure PowerShell to work with Azure
Set-ExecutionPolicy ByPass
Enable-PSRemoting
Enable-WSManCredSSP -role client -delegatecomputer "*.cloudapp.net"
$regKey = "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\Credssp\PolicyDefaults\AllowFreshCredentialsDomain"
Set-ItemProperty $regKey -Name WSMan -Value "WSMAN/*.cloudapp.net"
Get-AzureSubscription -ExtendedDetails
You may also need to do this
Run GPEdit.msc You must also enable delegating of fresh credentials
using group policy editor on your client machine. Computer
Configuration -> Administrative Templates -> System -> Credentials
Delegation and then change the state of "Allow Delegating Fresh
Credentials with NTLM-only server authentication" to "Enabled." Its
default state will say, "Not configured."
In the Add Servers sections add the following.
WSMAN/*.cloudapp.net
I can not remote into any machine to save my life! I have tried everything I can find. If anyone could troubleshoot or guide me, I'd appreciate it as this would be a great tool to add on my domain.
SETUP:
Client machine inside domain
Server machine inside or outside domain - Virtualized and utilized for WSUS Computername: wsustest
CLIENT SERVER MACHINE physical- computername: epizzi-pc
STEPS:
enable-pssremoting done! on all machines
trustedhosts configured with * or client machine added
Firewalls with public profile off just in case
Enter-PSSession -ComputerName wsustest -Credential wsustest\administrator
Enter-PSSession -ComputerName epizzi-pc -Credential epizzi-pc\administrador
Enter-PSSession : Connecting to remote server epizzi-pc failed with the following error message : WinRM cannot process the request. The following error with errorcode 0x80090311
occurred while using Kerberos authentication: There are currently no logon servers available to service the logon request.
Possible causes are:
-The user name or password specified are invalid.
-Kerberos is used when no authentication method and no user name are specified.
-Kerberos accepts domain user names, but not local user names.
-The Service Principal Name (SPN) for the remote computer name and port does not exist.
-The client and remote computers are in different domains and there is no trust between the two domains.
After checking for the above issues, try the following:
-Check the Event Viewer for events related to authentication.
-Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport.
Note that computers in the TrustedHosts list might not be authenticated.
-For more information about WinRM configuration, run the following command: winrm help config. For more information, see the about_Remote_Troubleshooting Help topic.
At line:1 char:1
+ Enter-PSSession -ComputerName epizzi-pc -Credential epizzi-pc\administrador
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (epizzi-pc:String) [Enter-PSSession], PSRemotingTransportException
+ FullyQualifiedErrorId : CreateRemoteRunspaceFailed
Enter-PSSession -ComputerName wsustest -UseSSL -Credential wsustest\administrator
*Enter-PSSession : Connecting to remote server wsustest failed with the following error message : WinRM cannot complete the operation. Verify that the specified computer name is
valid, that the computer is accessible over the network, and that a firewall exception for the WinRM service is enabled and allows access from this computer. By default, the WinRM
firewall exception for public profiles limits access to remote computers within the same local subnet. For more information, see the about_Remote_Troubleshooting Help topic.
At line:1 char:1
+ Enter-PSSession -ComputerName wsustest -UseSSL -Credential wsustest\administrato ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (wsustest:String) [Enter-PSSession], PSRemotingTransportException
+ FullyQualifiedErrorId : CreateRemoteRunspaceFailed*
ERRORs:
I was receiving the same problem when remoting to a server and found this blog post very helpful - http://jeffgraves.me/2013/10/14/powershell-remoting/
For my specific case I did the following:
On the Local machine
winrm quickconfig (although this was already configured)
winrm s winrm/config/client '#{TrustedHosts="myservername.domain"}'
On the Remote machine
enable-psremoting -force
Set-PSSessionConfiguration -ShowSecurityDescriptorUI -Name Microsoft.PowerShell -Force
I got around this problem by using a fully qualified logon. Instead of "netbiosdomain\accountname", I used fqdn\accountname, as in Microsoft.com\myaccount in the get-credential prompt. May not work for everyone, but it's worth a shot.
This is how I do it. I use this on my scripts.
# This is only done once
Read-Host -AsSecureString | ConvertFrom-SecureString | Out-File
c:\Windows\temp\securepass.txt
# Setup credentials
$SecureString = Get-Content c:\Windows\temp\securepass.txt | ConvertTo-SecureString
$mycredentials = New-Object -TypeName System.Management.Automation.PSCredential
-ArgumentList "yourDomain\userID",$SecureString
# Open remote session:
$MyRSession = New-PSSession -ComputerName Computer1 -Credential $mycredentials
-Authentication default
# Use remote session:
Enter-PSSession $MyRSession
Get rid of -UseSSL. I enabled PSRemoting and had problems with using that. I guess I could look at it later but for now it doesn't matter.
If there is no trust between the client and server computers, you have to enable basic authentication on the server side. Do this by toggling the correct properties on the WSMAN: drive on the server. You'll obviously have to do this interactively on the console or via remote desktop, due to the chicken and egg problem :) Also, this may come into play too:
http://www.nivot.org/blog/post/2009/10/30/PowerShell20EnablingRemotingWithVirtualXPModeOnWindows7
I was getting that same error currently no logon servers available.
The issue was resolved by using instead of Domain\Username as credentials the user UPN or Username#Domain.
I have achieved a remote session with Enter-pssession command, had to follow these exact parameters
$creds = get-credential (the -credential parameter in enter-pssession does not work properly, thus u must previously enter the object at another variable)
Enter-pssession -computername wsustest -authentication Default -credentials $creds
i Also had to set both client and remote server in the trusted hosts wsman: space
another solution which surely wouldve worked but i havent tried, wouldve been setting https: which is harder to do.
thx to all, your comments certainly led to the solution!