Powershell Script Deployed through Intune - Command Not Found - powershell

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.

Related

Getting error when I try using Sharepoint Online power shell commands

When I try to execute Powershell command, it gives the error:
Connect-SPOService : The term 'Connect-SPOService' 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.
Tried uninstalling and reiinstalling S P Online Management shell. None of the SPO commands are working.
On my system this came down to a conflicting .dll (different versions) that was found in both the SharePoint PowerShell module folder and the Global Assembly Cache.
I deleted the following file from the GAC:
C:\Program Files\WindowsPowerShell\tmp\Microsoft.SharePoint.Client.Publishing\v4.0_16.0.0.0__71e9bce111e9429c\Microsoft.SharePoint.Client.Publishing.dll
After that everything was running smoothly. Full details on research leading to this is found here:
https://www.easy365manager.com/the-term-connect-sposervice-is-not-recognized/
Are you using the cmdlet in the SharePoint Online Management Shell or in the PowerShell? If you are using it in PowerShell, still you need to import the module with
Install-Module -Name Microsoft.Online.SharePoint.PowerShell
Besides, ensure you are running the management shell under administrator privilege.
Here is a doc which may be helpful:https://learn.microsoft.com/en-us/powershell/sharepoint/sharepoint-online/connect-sharepoint-online?view=sharepoint-ps
On mac run the following command:
rm -rf Users/<username>/.local/share/powershell/Modules/Microsoft.Online.SharePoint.PowerShell/16.0.22810.12000/Microsoft.SharePoint.Client.Publishing.dll
PS: replace with username

Running PsExec.exe on Remote PC

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()

Powershell as scheduled task issue with importing module, it seems

I am attempting to configure some powershell/view powercli scripts for our VMware horizon environment. I have a powershell script that works properly to query the horizon instance and check machine states. However, when I try to run this as a scheduled task using a service account, it seems to fail to import a module, as a command is unrecognized ("The term 'Connect-HVServer' is not recognized as the name of a cmdlet, function, script file, or operable program.")
I tried profiles as well, didn't matter.
What I observed is that if I open powershell as the user in question (run as different user > authenticate as service account), leaving that powershell instance open will allow the scheduled task to run as expected. However, if i close the powershell instance, the scheduled task fails. This is obviously not viable since the goal is for this script to run on a schedule without the service account (or any account) being logged into the windows server at the time the powershell script gets run.
The problem you're running into is environment variables. In the course of running as a user versus running as machine, the PSModulePath environment variable changes to include user-directories for user-scoped module installs. You should install PowerCLI machine-wide.
Alternatives (these assume your service account has admin privileges):
Modify your $Env:PSModulePath in the script to include each user's module path
Specify the path in an Import-Module statement in your script before you use any of the cmdlets
Example of the first alternative:
foreach ($user in (Get-ChildItem -Path C:\Users)) {
$Env:PSModulePath += ";$($user.FullName)\Documents\WindowsPowerShell\Modules"
}
Example of the second:
Import-Module -Name 'C:\Users\KnownUser\Documents\WindowsPowerShell\Modules\PowerCLI'

Alternate for esbimportutil.exe for PowerShell BizTalk

I am working on a PowerShell Deployment scripts for BizTalk. I want to import an itinerary in XML format using PowerShell. Commands available for this task is esbimportutil.exe. But this works only in Command Prompt and not in PowerShell.
The error shows is :
The term 'esbimportutil.exe' is not recognized as the name of a cmdlet, function, script file,
or operable program.
I run the PowerShell as an Administrator and even tried running the command from the source root location but still no use.
I got the solution. The problem was resolved by using a simple command:
Start-Process -FilePath "...\esbimportutil.exe" -ArgumentList $argument
The command "start-process" did the magic.

How to run get-vm command on windows powershell

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.