First published on TechNet on Jun 08, 2015
Ahhh, welcome to summer. The cool splashing blue water of the municipal pool. Blue-raz slushies from Tropical Snow. Bright, clear blue skies. Sometimes all that blue makes me think of Azure - the colors of the portal, the logo and the word itself – Azure – is a type of blue.
Gary Green and Mike Hildebrand will be your tour guides today, speaking with you about some very handy Azure IaaS VM management tools and a big "bonus nugget" at the end that almost makes this post a two'fer (no skipping ahead).
As an IT Pro, you're likely getting more and more comfortable with the cloud paradigm and you're brain is sparking with ideas of how your current IT architecture could benefit from integration with cloud services. That's great!
You've signed up for an Azure trial and you quickly blow through the UI wizard to create a VM. Now, you eagerly await the provisioning process to finish. Tick. Tock. This is worse than waiting for the toaster to pop.
You pound a can Mountain Dew KickStart and a few minutes later, you see in the portal that your shiny new VM is up and running. Ohhhh man!! You're like a kid on Christmas. A moth to the flame. A dog to a bone. Hilde to a theater-sized box of Mike and Ikes. You get the idea.
You click the "connect" button at the bottom of the portal and up pops an RDP connection dialog box for your VM.
Then …
Your mind races but it's coming up empty …
"What credentials did I set up on the VM to login?"
Your minds is blank. You try some of your usual suspects for test credentials but none work.
You think out loud, "Seriously?? I don't remember what username and password I specified when I set this thing up two minutes ago?!"
Perhaps you fat-fingered the password the same way twice when you entered it? It certainly can happen. I know sometimes my brain thinks "the" but my fingers type "then" or "they." It's as if my fingers have a mind of their own. Muscle memory is weird.
Maybe you had to choose a VM name that wasn't your 1 st , 2 nd or 12 th choice due to uniqueness requirements of cloud service names? Maybe it's just me; maybe it's early-onset dementia; maybe it's the Azure version of the Jedi Mind-trick.
Maybe you are coming back to a VM that you provisioned a while back and now, your brain draws a blank for the user ID and/or password.
Or, maybe you aren't as absent minded as I am? Maybe you have a solid naming convention for Azure resources that enables you to precisely keep track of and know what's-what (that's a suggestion, by the way… J ).
Well the folks working on Azure aren't a lazy bunch and they created some out-of-band tools to help you manage your VMs. Collectively, these are enabled by an agent you can install on the VM called, creatively enough, the "VM Agent." For you virtualization techs out there, this won't be a foreign idea – it is along the lines of the Hyper-V "Integration services" and the "VMWare Tools." These drivers and other software light up features and functions for virtualized systems. The VM Agent for Azure VMs does the same type of thing for VMs running in Azure.
The focus of this post is IaaS Windows VMs but there is an agent for LINUX VMs, too, and the Agent is always installed on PaaS VMs (where it is known as the "GuestAgent").
If you use the 'quick-create' option, the agent is automatically part of the VM deployment but if you use the gallery to build your VM, you can check the box to install the agent (default) or clear the check to not install it.
NOTE: At the moment, it is not supported to uninstall the VMAgent from a VM after it's been installed. If you don't want the Agent on your VM, don't install it when provisioning the VM.
NOTE: If you don't want the VMAgent on your VM and you're provisioning VMs via Azure PowerShell, you use the –DisableGuestAgent switch with either the New-AzureQuickVM or New-AzureVM/Add-AzureProvisioningConfig
Once installed, there are a few indications the VMAgent is there:
NOTE: Currently, BGInfo options aren't configurable – you get what you get
If you didn't choose to have the VMAgent installed when you provisioned the VM, you can install it after the fact via an MSI and some Azure PowerShell.
Here's the process to get the VMAgent on an existing VM:
!! SECOND WARNING !! This is one of two ways to connect Azure PowerShell to an Azure subscription. The subscription settings file you download contains your Azure credentials and should be well-protected and/or deleted when you're done connecting . Be sure to read more about connection methods and note the bright pink warning here: https://azure.microsoft.com/en-us/documentation/articles/powershell-install-configure/
You can now use Azure PowerShell to interact with the VM 'out-of-band', via the VMAgent, and perform tasks such as resetting the local admin username and password, re-enabling remote access defaults and turning on/off BGInfo.
NOTE: Most of these actions require a sign-out/sign-in or possibly a reboot of the VM to take effect.
NOTE: If this is performed against a Domain Controller, it will affect the built-in Administrator account of the domain, including enabling it (if it is disabled) and renaming the SAMAccount attribute of that ID. In my testing, doing this against a DC also resulted in the DC being gracefully rebooted.
Activities are logged to specific logs files on the VM itself:
In this specific log clip, I used Azure PowerShell to rename the local admin account to mhilde and reset the password:
Additionally, there are Azure-specific Event Logs but they don't track specific changes at the moment; these are more about health of the Agent.
Obviously, the OS itself will capture certain changes, too (in this case, as above, an account rename from user-002 to mhilde):
Lastly, there is logging within the Azure Portal:
And now for the bonus nugget/teaser …
In times past, the only choice you had was to use Azure PowerShell to work with most of the VMAgent functions.
However, you can do these things via GUI from the Azure preview portal!
NOTE: The Azure Preview Portal is NOT currently supported. For your production workloads, obviously we recommend you continue to use the "vCurrent" portal ( https://manage.azure.com ) and/or the PowerShell commands above to avoid any issues where support isn't available. If you like living your Azure-life on the edge, though, or you're interested in a sneak-peek at the near-future, the preview portal is a really good time.
BGInfo is no longer active…
NOTE: If this is performed against a Domain Controller, it will affect the built-in Administrator account of the domain, including enabling it (if it is disabled) and renaming the SAMAccount attribute of that ID. In my testing, doing this against a DC also resulted in the DC being gracefully rebooted.
Well, that about does it for today. The Azure VMAgent, along with some Azure PowerShell, can be quite helpful for managing your IaaS VMs if/when you've painted yourself into a corner.
You can perform some of those admin tasks via the preview portal but that UI isn't supported yet.
The addition of these capabilities to the preview portal was a nice surprise to me but, equally as exciting (or more), were the other style changes and feature-adds to the preview portal. If you haven't been out there recently, I URGE you to go have a look ( https://portal.azure.com ).
You'll find a very polished and eye-friendly web UI with a high degree of operational maturity and functionality to manage your Azure VMs. I, for one, am looking forward to GA for the preview portal (no, I don't know when that will be).
Cheers from Gary and Hilde!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.