Shutdown settings and Outlet sequences

[GaryG_Accel]

I looked for an existing answer that clarifies that Shutdown sequence.  I didn't find what I was looking for. The order on the webGUI is partly counter-intuitive (or maybe I'm counter-intuitive).

I apologize in advance if this is hard to understand. It's difficult for me to compose, with all the necessary details.

I now have 2 identical SMT3000s, small-mid office space, don't have NMC, only with USB cables connected to 2 servers.  The main object is shutting down some servers on LAN with Stop-Computer -ComputerName commands, then also shutting down a special VM on one server with special commands, then lastly Windows Server OS shutdown commences.

I scripted those custom shutdowns so default.cmd calls each Powershell.PS1 file.

(I can't see the default.cmd window running when triggered by PowerChute, so I'm not sure if it runs all 4 PS1 commands quickly or waits for each response.)

Lastly, power off outlets after Windows Server OSs do graceful shut down.

• The APC PBE Agent services are on both Dell servers as Hyper-V hosts.
• One of Dell servers also has PCBE software and so that one is running APC PBE Server service.
• Each server with dual PS has PS#1 connected to APC#1 and PS#2 connected to APC#2.

I think I only have 2 main questions.

Do the Shutdown agents remain reliant on the APC PBE Server service running on one of the two servers?

If so, I need to keep Server 1 up longer than Server 2, despite the fact that Server 2 needs more delay to process special shutdown commands. (This involves one VM Guest running Linux-based backup system that must first stop DBs and then shut down modules during power off process; I timed it at about 5-6 minutes during manual poweroff. Windows OS and Hyper-V services may or may not wait for the Linux system to gracefully poweroff, so I gave it extra time.)

If each PowerChute Agent's processes operate independently of the one APC Server service, then it matters less if Server 1 shuts down before Server 2.

On the other hand (this is a mini-question), keeping both Servers powered on by APC#1 and APC#2, by not turning off APC#1 Unswitched Outlets too early, I think that may (or may not) avoid putting extra drain on APC#2 during an outage. Extra drain would increase the risk of going to "insufficient battery power" on APC#2.  This seems like a logical theory to me, but not sure.

-------

Second question

As far as I can tell from reading the WebGUI and looking at results of settings, final poweroff of Unswitched Outlets time is cumulative of the previous delays.

Am I correct that all these delays are cumulative?

wait 60 after power outage detected

wait 360 for default.cmd to complete (graceful shutdowns on special servers)

wait 240 for VM Guests to do graceful shutdowns as Windows Server OS does graceful shut down

Outlet Group 1 turns off at 600 after process, which is 660 after initial outage detected -- but I think I could shut down OG1 much sooner to preserve battery.

lastly, wait 180 more to turn off Unswitched Group, just in case Windows Server OS takes longer to gracefully shut down VM Guests and shut down the VM Host and other OS processes.

It looks like wait 360 for default.cmd to complete means "Do Not Trigger Windows Server OS graceful shutdown until after special shutdown commands complete" (my intention, so Linux poweroff process completes), but the WebGUI doesn't make that clear.  I'm a bit uncertain. 

The WebGUI seems to link this default.cmd delay to the OG1 poweroff.  This has me a little confused, I think I get it, but not sure.

Depending on this answer, I might want to reduce the default.cmd delay ... if it doesn't trigger Windows OS shutdown too early, and/or if Windows Server OS VHHost will wait politely for Linux VM to finish to Poweroff. This might work better if I swap those two delay numbers.

So that's a messy question about "sequencing theory" (if you will 🙂 ). I hope I did OK explaining my issues and questions.

I wish SE had a full tutorial explaining this process and theory, better than the WebGUI.