Windows Azure Virtual Machines

Announcements

• Link

  New Security Enhancement: User defined administrator name

  Drew McDaniel [MSFT] Monday, April 08, 2013 7:47 AM

  As a security enhancement for Windows virtual machines we now allow, actually force, you to select a name for the administrator account. By selecting your own administrator account name it is more difficult for an attacker to guess both your administrator account name and your password. You will see this new feature in the Azure Portal when you deploy a Windows VM from either the gallery or via the Quick Create option.

  

  The name that you provide will be used to rename the built-in administrator account. If you connect to the virtual machine using the RDP protocol you will need to select the option to enter a new username and then enter the name that you selected for the administrator name. For example if the administrator name selected was “MyAdmin” then you would configure the RDP connection like this:

  

  
  

• Link

  Reboot warning for VMs deployed prior to April 16th

  Drew McDaniel [MSFT] Thursday, May 09, 2013 7:17 AM

  Note: This warning only applies to Virtual Machines deployed prior to April 16^th that are part of a availability set. Feel free to stop reading if this warning does not apply to you.

  The symptom that we are trying to avoid here is an unexpected reboot of a VM. Under rare conditions you could have all VMs in an availability set reboot if you make a change to any VM in the cloud service that contains these VMs. The underlying issue is a defect that was resolved before Virtual Machines were brought out of preview; however some VMs that were deployed during the preview timeframe may still be affected.

  Required conditions for a VM to be affected by this defect (VM must meet all conditions):

  1. VM deployed before April 16^th
  2. VM added to an a availability set after the VM was initially provisioned
  3. No change to the cloud service that contains the VM except for stop/start/reboot of VMs since April 16^th.

  Resolution: If you believe that you have one or more VMs that meet the conditions described above, then all that is needed to get the VMs health again is to make any change to the cloud service that contains these VMs. The change can be any of the following operations:

  • Add or remove VM from the cloud service
  • Add or remove a data disk to any VM in the cloud service
  • Add or remove an endpoint on any VM in the cloud service
  • Resize any VM in the cloud service
  • Change the availability set of any VM in the cloud service

  You should make this change at a time when it is OK for the VMs in the cloud service to reboot. If the VM(s) were being affected by this defect then they will reboot when you make the change to the cloud service. From this point forward the defect will not affect your VMs and reboots of your VMs will only occur on configuration changes that require a reboot such as changing the size of a VM which will reboot just the VM that has the size changed.