Overview

AltiGen's Cloud Operations group has become aware of a bug that may prevent some hosted servers from rebooting properly after running windows updates.  If this problem is encountered on a MaxCS Hosted system, please do not hesitate to contact AltiGen Technical Support Operations (TSO) to request a manual reboot of the virtual machine.

Scope of Impact

This bug appears to be limited to servers running Windows 2012 R2 in a VMWare environment. This is the environment that is used for AltiGen Hosted MaxCS Private Cloud servers. Servers running Windows 2008 and 2008 R2 have not been observed to have this problem. All MaxCS private cloud servers hosted by WorkSpace Communications should not be subject to the problems mentioned here.

Problem Description

This problem manifests itself as a server failing to reboot after applying Windows Update. A reboot from Windows Update may be expected to take somewhat longer than a normal reboot if there are updates to be applied, but generally speaking, even under the largest update conditions, the server should return to running state and be accessible via Remote Desktop within 15 minutes of issuing the reboot.

Resolution

The resolution to this problem is to simply reboot the virtual machine from the VMWare vCenter Server, however AltiGen's Reseller Partners (Dealers) do not have access to this system. If a MaxCS Private Cloud sever is not accessible via Remote Desktop 15 minutes after issuing the reboot, please contact AltiGen Technical Support - they are able to connect to vCenter, and check the console of the machine for status and reboot if necessary.

NOTE: AltiGen's Technical Support Operations only has this access for MaxCS private cloud systems. If you observe this problem in a premise based system, TSO may be able to assist, but they do not have any access to the customer's visualization infrastructure.

Additional Information

AltiGen's Cloud Operation's group has observed this problem on approximately 5 systems (including test systems), but has not been able to reproduce it. It does seem to be the problem described in this Technet forum. We have not implemented the work arounds cited in the article because they are explicitly stated as "not (having) been tested extensively by (VMware) engineering, and should be run at your own risk as it is just a workaround which has not been fully (VMware) QE tested".

AltiGen is still attempting to reproduce this problem, and if we find that we are able to do so, will also esclate the problem to VMware as well. We also regularly apply udpates to our ESXi hosts, and vCenter, so we will keep a diligent watch for a fix for this issue.