Exiting VMware vSphere PowerCLI command prompt? - powershell

Is there a script to input to exit VMware vSphere PowerCLI command prompt after executing a set of script for example created of VM.
MY last line of my .ps1 script is shown below, but the exit does not work, after executing my script, the command prompt is still there, unlike windows command prompt as the exit command works but not in powercli.
New-VM -name $vm -DiskMB 10000 -memoryMB 4000
New-CDDrive -VM $vm -ISOPath $win7 -StartConnected:$true -Confirm:$false
$scsiController = Get-HardDisk -VM $vm | Select -First 1 | Get-ScsiController
Set-ScsiController -ScsiController $scsiController -Type VirtualLsiLogicSAS -Confirm:$false
Start-VM -vm $vm
Exit

My hunch is that this has more to do with powershell and little to do with PowerCLI. I'm also guessing that the window closes if you focus it and press 'Enter'. I ran into this when executing some powershell scripts long ago, but never came across a decent fix until this evening. It seems powershell waits on a Readline() call after executing the script.
The solution: include the flag -InputFormat None in your call to powershell.exe. In your case, I'd include it in the call to the PowerCLI executable, it ought to be passed through.
Resources:
This looks like a known issue from Microsoft's tracker.
These two questions reference the same fix:
Powershell and WiX
Powershell and MSDeploy
Please let me know if this works correctly, I'm not on a system with PowerCLI installed currently.
Good luck!

Related

Is anybody having this Powershell "Update-Help" command, issue?

I am trying to download and install Help files for all the commands but it won't work. I am using Powershell 7.1.1 inside the Windows Terminal.
Update-Help: Failed to update Help for the module(s) 'ConfigDefender, PSReadline' with UI culture(s) {en-US} : One or more errors occurred. (Response status code does not indicate success: 404 (The specified blob does not exist.).).
English-US help content is available and can be installed using: Update-Help -UICulture en-US.
This is exactly what the out-put looks like
Solved, thanks to another post I've found on stackoverflow.
According to Microsoft, the below command should work in case of errors regarding the cmdlet: Update-Help.
Update-Help -Verbose -Force -ErrorAction SilentlyContinue
The issue is the capitalization of PSReadline, which changed to PSReadLine with PowerShell 6.
Fix is easy:
Close all PowerShell windows
From TaskMgr make sure to kill any remaining PowerShell processes.
Open Admin Cmd prompt (not PowerShell) and run the following:
ren "C:\Program Files\WindowsPowerShell\Modules\PSReadline" PSReadLine
ren "%APPDATA%\Microsoft\Windows\PowerShell\PSReadline" PSReadLine
That's it. Now you can close the Cmd prompt window, open a PowerShell window and do a normal Update-Help.
See this blog for some additional context:
https://devblogs.microsoft.com/powershell/updating-help-for-the-psreadline-module-in-windows-powershell-5-1/

Why does Chocolatey hang when using Powershell ISE without the `-y` switch?

When using PowerShell ISE with Chocolatey to install applications, if I forget the -y switch, it hangs waiting on some sort of "confirmation" that's not popping up anywhere?
I have to Ctrl+Alt+Del to kill PowerShell ISE and Chocolatey and it leaves things in half-way state.
This is what it looks like below:
In addition to the comments to the OP above, regarding PowerShell ISE not supporting (most) interactive console applications...
It is worth remembering that the REPL window in PowerShell_ISE.exe is not just some sort of docked PowerShell.exe console. Most of the time the user experience is the same, but this hides a number of differences:
https://blogs.msdn.microsoft.com/powershell/2009/04/17/differences-between-the-ise-and-powershell-console/
Both these executables are host applications that run a PowerShell runspace (engine). You can even write your own application that "hosts" PowerShell. It is the host application that determines the user experience.
PowerShell.org: The Shell vs The host
Spiceworks.com: The Shell vs The Host
Writing a Windows PowerShell Host
And finally, for the most curious:
How PowerShell works
I think I wrote this answer more for my own benefit; it's a useful refresher for me as I get asked this by colleagues every now and again...
It's simply because PoSH ISE is not a thing to use for user interactive .exe commands.
If you .exe or whatever expects a response, when in the ISE you have to provide it.
You can easily prove this is not a Chocolatey thing by trying any other .exe that kicks out interactive stuff. For example, just type:
nslookup in the script pane and F8 to run it, or type it in the console pane and hit enter
Either way, the console will just hang, waiting for a interactive response that you cannot provide.
You can still use interactive commands like nslookup in the PoSH ISE, but you have to provide all parameters. For example:
nslookup microsoft.com
nslookup -type=mx microsoft.com
nslookup -q=soa microsoft.com
PS 5.1 even kicks out an error message now.
nslookup
Cannot start "nslookup". Interactive console applications are not supported.
To run the application, use the Start-Process cmdlet or use "Start PowerShell.exe" from the File menu.
To view/modify the list of blocked console applications, use $psUnsupportedConsoleApplications, or consult online help.
At line:0 char:0
You can easily shell out to the PowerShell console host temporarily this way.
Here is a function I have in my profile for such efforts.
Function Start-ConsoleCommand
{
[CmdletBinding()]
[Alias('scc')]
Param
(
[string]$ConsoleCommand,
[switch]$PoSHCore
)
If ($PoSHCore)
{Start-Process pwsh -ArgumentList "-NoExit","-Command &{ $ConsoleCommand }" -Wait}
Else
{Start-Process powershell -ArgumentList "-NoExit","-Command &{ $ConsoleCommand }" -Wait}
}
So, just type
scc -ConsoleCommand choco install winmerge
It'll pop the console host and stay open until you close it.
Update
As per request of - Alex Kwitny
PoSHGet default has only two repositories,
nuget
PSGallery
but you can add your own or another.
You use the below cmdlets to make this happen.
I have not had to use Chocolatey in a while, but taking a quick look and my archives, the below is what I used
Set up chocolatey repository
Find-Module
Get-Module
Find-Package
Get-Package
Get-PackageProvider
Get-PackageSource
Get-PackageSource -Provider chocolatey
Register-PackageSource -Name chocolatey -Provider Chocolatey -Trusted -Location http://chocolatey.org/api/v2/ -Verbose
Find-Module
Get-Module
Find-Package
Get-Package

Why process that terminated by script from PowerCli stuck in "suspended" mode

When I run a script trough PowerCLI after connecting to a VM, I get a strange behavior of some processes, I'm using the "Invoke-VMScript" command that is running an EXE file (compiled in .Net 4.5) that looks for running process and try to kill them.
For some reason some process doesn't get closed, and stuck in "Suspended" mode. When they stuck in this mode even if I tried to remove them from the task manager I get an error "The operation could not be complete, Access is denies."
I'm logged in with the Administrator user
The powershell script that I'm using is:
$executeCommand = "call D:\myCleaningProcess.exe $param1";
Invoke-VMScript -VM $vmName -GuestUser $vmUser -GuestPassword $vmPass -ScriptText $executeCommand
*When running manually the file "EXE" it's works as expected and the process get killed.
Anyone know why I get this strange behavior?
You need to use the -ScriptType Bat parameter when calling EXEs in this manner. See example 3 for reference: https://pubs.vmware.com/vsphere-55/index.jsp?topic=%2Fcom.vmware.powercli.cmdletref.doc%2FInvoke-VMScript.html

Module returns different result from the script version [Test-Path]

introduction
I've written my first PowerShell script aimed for retrieving detailed information from a Windows Setup ISO file. Once the basic features achieved, I've started to convert the ps1 script into a psm1 module. I hoped the result would be the module just work like the script but I'm facing issue I'm not able to solve.
You can download my work here, script version and module (roughly translated to English from French).
I successfully installed the module in PSModulePath in:
[Environment]::GetFolderPath("mydocuments")\WindowsPowerShell\Modules
Command usage is very simple. You call it like that:
WinIsoInfo [[-Path] <String>] [<CommonParameters>]
Help is provided by module: man WinIsoInfo
Usage Example:
WinIsoInfo -Path "E:\Win 10\Installation\ISO\Windows 10 x64 fr.iso"
The ps1 script version is the exact same code as the psm1 module but there are commands examples at the end of the file that you can un-comment and edit before running the script.
Current Status
All the tests are and need to be run as admin, in console or PowerShell ISE.
The ps1 script works as expected but the psm1 module doesn't produce the same result.
At line 108 of the code, there is a Test-Path in a Switch statement:
{(Test-Path "$wimPath\sources\install.wim") -or (Test-Path "$wimPath\sources\install.esd")}
In the ps1 script, this Test-Path return True and user get the expected info.
But in the psm1, it seems to return False since Switch statement jump to the next test after this one. So at the end the user gets that the ISO doesn't contain windows setup. I can assure that the Test-Path should return True because I manually checked it while the function was paused by breakpoints.
Hint and lead
There are 2 cases where I manage to get the module work as expected. But only using in PowerShell ISE, NOT in console.
Using Automatic Variable $? in console pane while debugging module
Step to reproduce:
PowerShell ISE is not running.
Open PowerShell ISE as admin.
In console pane, run import-module Get-WinIsoInfo -Force -Global -Verbose or import-module -path X:\Path\To\Modules\Get-WinIsoInfo -Force -Global -Verbose
In console pane, run WinIsoInfo -Path "X:\path\to\AnyWindowsSetup.iso"
In my case, at this point, the command returns there is no Windows Setup in ISO file.
Now open the Get-WinIsoInfo.psm1 and put a breakpoints anywhere between line 90-108.
do step 4 again
While the script is paused at breakpoints, run $? in the console pane then press F10 then F5
And "voilĂ  !" the module return the expected result and will keep working but only during PowerShell ISE session and inside PowerShell ISE. Command run in console still won't work. And the next time I run PowerShell ISE, the module won't find the setup image path again.
Previously run the ps1 script version in PowerShell ISE
Step to reproduce:
PowerShell ISE is not running.
Open PowerShell ISE as admin.
In console pane, run import-module Get-WinIsoInfo -Force -Global -Verbose or import-module -path X:\Path\To\Modules\Get-WinIsoInfo -Force -Global -Verbose
In console pane, run WinIsoInfo -Path "X:\path\to\AnyWindowsSetup.iso"
In my case, at this point, the command returns there is no Windows Setup in ISO file.
Now open the Get-WinIsoInfo.ps1 script, edit a valid command at the end of the code then press F5 to run it.
Note: Since the command in script has the same name as the module previously imported, at this point I don't know if the triggered function is the one from the ps1 script or the one from the module. Tell me if you know.
The script returns the expected result as Windows Setup info.
Close the ps1 file (it is no longer needed in PowerShell ISE for the next to work)
do step 4 again
And "voilĂ  !" the module return the expected result and will keep working but only during PowerShell ISE session and inside PowerShell ISE. Command run in console still won't work. And the next time I run PowerShell ISE, the module won't find the setup image path again.
Conclusion
After the Hint and lead tests, I found out that they were some differences from modules imported in session before and after success. These key modules loaded by PowerShell ISE are Storage and Microsoft.WSMan.Management. I thought I found the solution and added this line to manifest:
RequiredModules = #("Storage";"Microsoft.PowerShell.Management";"Microsoft.PowerShell.Security";"Microsoft.PowerShell.Utility";"Microsoft.WSMan.Management")
I added all the modules that was present after the module works as expected, just to be sure.
I did the same for assemblies but 2 of them could not be imported: Microsoft.Management.Infrastructure.UserFilteredExceptionHandling and Microsoft.Management.Infrastructure.resources
Resulting in this new manifest line:
RequiredAssemblies = #("Microsoft.Management.Infrastructure.Native";"Microsoft.WSMan.Runtime";"System.Security")
Unfortunately, it seems it is not enough to solve the issue.
Maybe other things has to be imported or it's a wrong lead.
I really hope you could reproduce the bug or at least I hope the Hint and lead section will lead you to find the cause and a solution. I'm too novice to understand why this happens on my system.
My setup uses PowerShell v5.0 with Win 8.1 Pro.

Source a PowerShell script on each new shell

I have a script called Restart-Audio.ps1
Stop-Process -Confirm -Name musicapp*
Stop-Service audiosrv
Stop-Service AudioEndpointBuilder
Start-Service audiosrv
Invoke-Item C:\path\to\music\app.exe
Every time I start a new PowerShell session, I want this script to run when I type "Restart-Audio" like a normal cmdlet. When I tried to add this to my PowerShell profile, it tried to run the script, asking for the confirmation to stop the processes. I don't want it to run as soon as a PowerShell session starts; I want the command to run when I tell it to.
Thanks.
This can be done using Powershell profiles, see here for details.
You basically create (if the file doesn't already exist) C:\Users\<<UserName>>\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1 and that can contain your above script.
I'd construct the file as:
Function Restart-Audio{
Stop-Process -Confirm -Name musicapp*
Stop-Service audiosrv
Stop-Service AudioEndpointBuilder
Start-Service audiosrv
Invoke-Item C:\path\to\music\app.exe
}
Then you just open Powershell and type Restart-Audio to run that function.
Additionally, if you save the script to any folder in your $env:PATH you can just type the first few characters of the script name and TAB complete to run the script.