When a clustered Process Automation enviornment needs to be rebooted (such as when Windows Update is applied), after the initial restart, some subprocesses will complete while the parent process seems stuck in "Waiting". Another reboot will usually correct the issue.
This can occur when the Process Automation Windows Service is set to Automatic. Especially in situations where Windows patches are applied, there are additional behind the scenes tasks that Windows will do after a restart. And Process Automation will start pretty immediately when Windows is up and running. It is typical for Windows networking to not be available immediately after a patch is applied and Windows is restarted.
To manually test this, you can set the Process Automation service to Manual and give Windows some time after a restart before you manually start the Process Automation service. If you want to automate this you can try the following:
Change the Process Automation Service to a delayed autostart, and modify the registry entry to increase the delay (default is 2 minutes) to 10 minutes. To do this you add a registry key - AutoStartDelay as a DWORD -32 bit key with a value of 600 (seconds, which is 10 minutes) to the HKLM\SYSTEM\CurrentControlSet\services\<service name>\DelayedAutostart entry.
With this enabled, the Process Automation service will wait for 10 minutes before starting giving Windows update time to complete and thus avoid the issue where Process Automation is started but not all Windows components are.