There are many articles about configuring PowerChute Business Edition and connecting to VMWare from PowerShell, but I haven’t found all of this in one place along with a description of the intricate details. And there are some.
1. Introduction
Despite our involvement in the energy sector, electrical problems sometimes arise. This is where the UPS comes into play, but unfortunately, its batteries are not long-lasting. What to do? Turn it off!
While all the servers were physical, things were going well; PowerChute Business Edition was a lifesaver. The free version for 5 servers, which was quite enough. An agent was installed on one machine, along with the server and console. As the end approached, the agent simply executed a batch file that sent shutdown.exe /s /m to neighboring servers, and then shut down its OS. Everyone was fine.
Then came the time of virtual machines.
2. Initial Data and Thoughts
So, what do we have? Just one physical server with Windows Server 2008 R2 and one hypervisor with several virtual machines, among which are Windows Server 2019, Windows Server 2003, and CentOS. And also a UPS – APC Smart-UPS.
We’ve heard about NUT, but we haven't had the chance to explore it; we only used what was at hand, namely PowerChute Business Edition.
The hypervisor can shut down its virtual machines by itself; it just needs to be informed when it’s time. There is a useful tool, VMWare.PowerCLI, which is an extension for Windows PowerShell that allows connecting to the hypervisor and informing it of everything needed. There are also many articles about PowerCLI settings out there.
3. The Process
The UPS was physically connected to the COM port of the 2008 server, which was fortunate. Although this is not critical - it could have been connected via an interface converter (MOXA) to any virtual Windows server. Next, all actions are performed on the machine to which the UPS is connected - Windows Server 2008, unless otherwise specified. The PowerChute Business Edition agent was installed on it. Here comes the first subtle detail: the agent service needs to run under a user account, not the system account; otherwise, the agent cannot execute the cmd file.
Then we installed .Net Framework 4.7. A restart is required, even if the framework does not explicitly request it after installation; otherwise, it won’t proceed. Further updates may also come, which need to be installed.
Next, we installed PowerShell 5.1. A restart is also required, even if it does not ask.
Next, we install PowerCLI 11.5. A fairly recent version, hence the previous requirements. It can be done via the internet, and there are many articles about it, but we already had it downloaded, so we simply copied all the files to the Modules folder.
Checked:
Get-Module -ListAvailableOkay, we see we have installed:
Import-Module VMWare.PowerCLIYes, the PowerShell console is indeed running as Administrator.
PowerShell Settings.
- Allow the execution of any scripts:
Set-ExecutionPolicy Unrestricted- Or allow to only ignore script certificates:
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned - Allow PowerCLI to connect to servers with invalid (expired) certificates:
Set-PowerCLIConfiguration -InvalidCertificateAction ignore -confirm:$false- Suppress PowerCLI's message output about joining the customer experience improvement program, otherwise there will be a lot of unnecessary logging:
Set-PowerCLIConfiguration -Scope User -ParticipateInCEIP $false- Save user credentials for logging into the VMWare host, so they are not explicitly shown in the script:
New-VICredentialStoreItem -Host address -User user -Password 'password'The check will show whom we have saved:
Get-VICredentialStoreItemYou can also check the connection: Connect-VIServer address.
The script itself, for example: connect, shutdown, and just in case disconnect, possible variants:
Connect-VIserver -Server $vmhost
Stop-VMHost $vmhost -force -Confirm:$false
Disconnect-VIserver $vmhost -Confirm:$false
4. Default.cmd
That command file which is run by the APC agent. It is located in “C:Program Files [(x86)]APCPowerChute Business Editionagentcmdfiles”, and inside:
«C:Windowssystem32WindowsPowerShellv1.0powershell.exe» -File «C:…shutdown_hosts.ps1»
It seems we have configured and tested everything, we even ran cmd – it executes correctly, shuts down.
We launch the APC console to test the command file (there is a Test button) – it doesn't work.
Here's the awkward moment when all the work done was for nothing.
5. Catharsis
We check the task manager, see – cmd flashed by, powershell flashed by. We take a closer look – cmd *32 and, accordingly, powershell *32. We understand that the APC agent service is 32-bit, and thus it runs the corresponding console.
We launch x86 powershell as an administrator, repeat the installation and setup of PowerCLI from point 3.
And we change the line calling powershell:
"C:Windows<b>SysWOW64</b>WindowsPowerShellv1.0powershell.exe…6. Happy Ending!
Source: habr.com
