This occured after applying the new firmware policy to the server/host. Our Maintenance policy is set to User ACK so after acknowledging the activity the server began the firmware upgrade. I saw the same behavior on an ESX host and a windows host so I don't believe it is an host OS issue. Additionally, The frimware policy was applied to the ESX host first while it was in maintenance mode. The Windows server was shutdown when the policy was applied.
In the case of the ESX host, the server shutdown and began rebooting into ESX. While loading the vmware kernal the system performed a hard shutdown, rebooted, and then began the firmware upgrade. After the firmware upgrade finished the server rebooted again and came up into the ESX environment. After witnessing the odd boot pattern on the ESX host, my hope was that the Windows server would go through the firmware upgrade without booting into the Windows OS and being interrupted. Just to clarify, when I say the OS was interrupted I mean the server was almost completely up. The Windows logon screen displayed very briefly and then the UCS appeared to have "cut the power" to the blade and bagan the frimware update.
