I have a PowerShell script that configures WinRM on our remote servers when ran on the local user's account. However, I need to upload the script to TFS and have each host run the script themselves.
The script checks if WinRM is configured. If it is not, then it checks if the C:\PSTools\PsExec.exe path exists. If the path exists, it needs to configure WinRM using:
$configure = (C:\PSTools\PsExec.exe \\$hostname -s winrm.cmd -q 2> $null)
However, the above results in the error
The term 'C:\PSTools\PsExec.exe' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
I know the file is there, so I am not sure what I am doing wrong here. Other examples I've seen use either psexec alone or ./PsExec.exe, but none of those work.
Any advise appreciated, thanks.
While this doesn't answer why psexec.exe isn't working (although I suspect it's because the file isn't actually there), you can use WMI to enable WinRM instead:
([wmiclass]"\\$hostname\root\cimv2:win32_process").
Create('powershell "Enable-PSRemoting -Force -SkipNetworkProfileCheck"')
and to restart your service remotely (even though Enable-PSRemoting handles this):
$svc = [wmi]"\\$hostname\root\cimv2:win32_service.Name='winrm'"
$svc.StopService()
$svc.StartService()
Related
We have a batch file that certain users can launch from their local machines that will run a PowerShell script on a DC in order to unlock user accounts or reset a password. However, all of a sudden it's not working, not even for network admins running it as an administrator. If we log on to the DC and run it locally, it works exactly as it should.
There haven't been any changes to the permissions of the file and no changes to the AD groups that have permission to run the file.
The batch file is this:
#echo off
cls
echo Loading, Please Wait...
;C:\Windows\System32\WindowsPowerShell\v1.0\Powershell.exe -ExecutionPolicy Bypass -File %logonserver%\<PATH TO FILE>\FILENAME.ps1
Same batch file that it's always been, but now when we run it remotely, we get multiple errors:
The term 'Get-ADGroupMember' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
Locally, it runs just fine. And yes, the first thing the PowerShell script does is
Import-Module ActiveDirectory -ErrorAction SilentlyContinue
As I said, it used to work but now it doesn't and we're completely lost as to why. We've searched and searched, but can't seem to find any information as to what might be causing it to error out.
If anyone has any ideas or suggestions, we would appreciate it.
Discovered that RSAT wasn't on any of the machines anymore. It required downloading the installer and running it on the machines. Once we did that, everything works like it should.
Not sure if this is for stakoverflow or serverfault.
I am deploying a Powershell script using MS Intune. The script works when run locally, but when deployed I get the error below:
Remove-LocalGroupMember : The term 'Remove-LocalGroupMember' is not
recognized as the name of a cmdlet, function, script file, or
operable program. Check the spelling of the name, or if a path was
included, verify that the path is correct and try again. At
C:\Program Files (x86)\Microsoft Intune Management
I am not sure why this commandlet is unavailable as it is definitely there if I open a powershell and run this command.
I am logging the $user variable to check that it is not null or running under a different context.
The code is quite simple as below:
$user = $(whoami)
$user | Out-File 'C:\powershelllog.log'
Remove-LocalGroupMember -Group Administrators -Member $user
I believe I've run into the same issue as you are having. I've been trying to create a local admin account on machines. Running the powershell script with the system context in Intune. What I've found is that you must check: "Run script in 64 bit PowerShell Host" inside of the Intune where you import powershell scripts.
Apparently not all commands are available with the 32 bit ps console running that way.
I also used the get-command to determine what module the command that was reporting not found was is in, and used the import-module at the top of my script in case.
I tried run get-vm command on windows powershell. It is throwing this exception:
"Error in script : The term 'Get-VM' is not recognized as the name of
a cmdlet, function, script file, or operable program. Check the
spelling of the name, or if a path was included, verify that the path
is correct and try again."
but I run same command on system center powershell it's run successful. But i need run on windows powershell. can i run it on windows powershell?
Import the VMM snapin. System Center's Powershell shortcut loads it per default. Vanilla Powershell doesn't.
Use Get-PSSnapin -Registered to list all available snap-ins. The one you are looking for is Microsoft.SystemCenter.VirtualMachineManager
Load the snap-in: Add-PSSnapin -Name Microsoft.SystemCenter.VirtualMachineManager
Get and set default VMM Server: get-vmmserver myVMMServer.VMMServeror use-VMMServer` switch to specify the VMM server the cmdlet is going to interact with.
I am running PowerShell scripts from a Windows service running as SYSTEM account. To increase rights I am letting users select a user that I later impersonate the whole thread as using LogonUser method.
This works so that I can access network drives and when I try to print the current user in PowerShell that works too.
But I have a case when it does not work:
One example is a user trying to load Exchange snapin and run cmdlet: Get-MailboxPermission
Then he get error: The term 'Get-MailboxPermission' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again. The term 'Get-MailboxPermission' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
I am guessing that this is permissions issue and I wonder if there is anything else that needs to be changed to RunSpace etc to get the increased permissions? Any other ideas?
Which PowerShell version?
Looks like you don't have the exchange snapin added. Try running this command before:
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.Admin
or, via code, in the runspace initialization, use this code:
RunspaceConfiguration rsConfig = RunspaceConfiguration.Create();
PSSnapInException snapInException = null;
PSSnapInInfo info = rsConfig.AddPSSnapIn("Microsoft.Exchange.Management.PowerShell.Admin", out snapInException);
Runspace myRunSpace = RunspaceFactory.CreateRunspace(rsConfig);
myRunSpace.Open(rsConfig);
read this article for additional info:
http://msdn.microsoft.com/en-us/library/exchange/bb332449(v=exchg.80).aspx
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.