Thursday, December 1, 2016

Monitor services in Microsoft Azure

Management Pack for Microsoft Azure

Many organization I work with struggle with the 'how-to' monitor the resources in Microsoft Azure. How do I connect my on-premises monitoring solution to Microsoft Azure and how do I monitor my resources. Traditionally the answer would be, look at OMS, set up alerts in the portal or logon when you notice something is wrong. Well none of the above really work well for most organizations.


To address the gap Microsoft has released a SCOM Management Pack for Microsoft Azure. It covers a wide range of services and support SCOM 2012 environments. 

Some of the services that can be monitored using the management pack:

Data Factory
DocumentDB
Logic App
Media Services
Mobile Services
Networks
Notification Hubs
Operational Insights
Redis Cache
Scheduler
Search
Service Bus
SQL Azure
Storage Accounts
Traffic Manager
Virtual Machines
Websites


So go ahead and grab a copy today and start testing it. Be mindful that it is in Technical Preview so there could be some glitches here and there, please review the prerequisites before you deploy the management pack.

The management pack can be found on the Microsoft website by hitting the following link:

Friday, August 26, 2016

ASM to ARM Migration

Migration from ASM to ARM

When Microsoft Azure was released it came with a deployment model named Azure Service Management (ASM). Since that time Microsoft has obviously looked at their competitors and decided to introduce a new deployment model named Azure Resource Manager (ARM). Great new deployment model but services deployed in ASM and ARM are not compatible with each other. After a long wait Microsoft has finally released some migration tools to migrate services from ASM to ARM. This article describes the process of migrating resources from the classic deployment model ASM to ARM and more specifically that of an environment that contains ExpressRoute, Virtual Network and virtual machines. My findings are based on an actual production scenario. I ran into a few issues in the process and hope you can use this article to plan your migration.

Some additional information in regards to the differences between the two models can be found here.


The migration from ASM to ARM is three steps process. You first run the prepare command which will "prepare" your ASM resources for the migration. Once you have prepared them you can Validate them. Once Validated you can Commit or Abort.

ASM to ARM Process
Handy to know:
  • ExpressRoute migrations are not supported as part of the virtual network migration. You must disconnected the ExpressRoute prior to the migration.
  • The migration process is considered to have no impact. The caveat here is around the virtual network. You cannot have a gateway, this must be removed prior to the migration, else the commit will fail. 
  • The migration "prepare" locks out classic operations. So once in this mode you cannot make changes to your classic resources. This is important as it means you cannot delete gateway, or the ExpressRoute link once the prepare command is run.
  • Virtual machines that are placed in one cloud services are migrated into availability sets in ARM. This might not necessarily be what you want. So be aware and remove if necessary.
  • Virtual machines that are placed in one cloud services are given a shared public IP and load balancer in ARM. Again this might not necessarily be what you want. So be aware and remove if necessary.
  • Network Security Groups are migrated across, but the classic objects are left behind. Delete them after the migration process.
  • Storage Accounts are migrated into a resource group that matches the name of the resource group. Not necessarily what you want, so move the storage accounts into the appropriate resource group after the migration.
  • ExpressRoute "connection" and "virtual network gateway" cannot be moved into a different resource group. So make sure you place them in the correct resource group.

The migration process

Prepare yourself


1. Map out the environment. To get make sure you're not forgetting about anything map out the environment that you are planning to migrate. In my case I had the following services to consider. A single subscription with the following services that would be affected by the migration.
  • ExpressRoute classic (Private, Public and Microsoft Peer)
  • 1x Virtual Network classic
  • 3x Cloud Services classic
  • 3x Storage Accounts classic
  • 5x Azure virtual machine classic
  • Network Security Groups bound to subnets
2. Sort out your backups. Make sure you have backups of the configuration of all your services. Not only backups of the virtual machines, but more importantly export the configurations. Below a short description of how to export the config of what services.

ExpressRoute - Not much you can do here. Make sure you have the service key.
Virtual network - connect through the portal and export the virtual network configuration. 
Azure Virtual MachineExport-AzureVM -ServiceName servicename -Name vmname -Path 'file.xml'
Network Security Group - Get-AzureNetworkSecurityGroupForSubnet -VirtualNetworkName 'virtualnetworkname' -SubnetName 'subnetname' -Detailed > 'file.txt'

Execute

3. Now that you have backups of the configuration and an understanding of your environment start looking at the execution of the migration.  

4. Step one is to migrate the ExpressRoute classic circuit to ARM. This migration does not impact the actual link and can be performed through PowerShell. This process is well documented on the following page ExpressRoute ARM Migration. Alternatively it can be done through the Azure portal. https://portal.azure.com. You need the servicekey name in order to migrate it across. This process takes about 5 to 10 minutes.
ExpressRoute Migration

5. Once migrated enable the "classic" operations if you desire the link to continue to operate with classic virtual networks. 

Classic operations

5. Up to this part there is no impact. Simply because we are only making changes to the presentation layer.

From this point onwards we actually start the migration of compute resources from ASM to ARM. This is where your outage will start. The process from here took my about 30 minutes. So plan for an outage of an hour.

**NOTE** I made the mistake of going ahead with the migration of the virtual network at this stage. Which won't work. You will receive the following error if you do this.

Move-AzureVirtualNetwork : BadRequest : Virtual network ******** has a gateway which must be removed before commit. The commit operation will be blocked until the gateway is removed.

6. Now you will find you cannot delete the gateway when the ExpressRoute is still connected. So delete the ExpressRoute link by running the following command.

Remove-AzureDedicatedCircuitLink -servicekey ******* -VNetName *******

6. Now delete the gateway from the Virtual Network in the portal. Once deleted we can initiate the migration.

7. Register the migration by running the following command.

Register-AzureRmResourceProvider -ProviderNamespace Microsoft.ClassicInfrastructureMigrate

Wait about 5 minutes and confirm that your subscription is ready by running the following command.

Get-AzureRmResourceProvider -ProviderNamespace Microsoft.ClassicInfrastructureMigrate

8. Migrate the virtual network. This command will migrate the virtual network, the associated compute resources and network security groups. Run the command and wait until you receive the Operation Status Succeeded message. This can take a while, for me it took 10 minutes.

Move-AzureVirtualNetwork -Prepare -VirtualNetworkName "virtualnetworkname"

8. If you want to see the changes, logon to portal.azure.com and you will find that new resource group will be created with cloudservicename-Migrated.

9. Review the changes that have occured, once you are happy and confident run the -Commit command. This will cutover the resources and will delete the ASM resources.

Move-AzureVirtualNetwork –Commit -VirtualNetworkName "virtualnetworkname"

10. Once move it's time to move the storage accounts across. Run the following command.

Move-AzureStorageAccount -Prepare -StorageAccountName "Storageaccountname"

11. Once the prepare has run again review the portal and you will find that they now appear in as ARM resource. If successfull run the -Commit command.

Move-AzureStorageAccount -Commit -StorageAccountName "Storageaccountname"

We're now at a point where we have migrated all the resources to ARM, it's now time to reconnect the ExpressRoute.

To connect the ExpressRoute to a ARM virtual network you need to complete a number of steps.
  • Create a virtual network gateway
  • Create a public IP address for the gateway
  • Create an ExpressRoute connection
12. Open the Azure Portal, select Create a virtual network gateway. Select the virtual network that you have migrated. Create a new Public IP. Select Gateway Type ExpressRoute and VPN type Route-based.

13. Go to ExpressRoute Circuits, select the ExpressRoute circuit, select Connections and the connection to the Gateway that we have just created.

14. Confirm that you can connect to your resources. Once you can it's time to clean up! You will find a number of resources are now located in resources group named -Migrated. You can move the resources out of those groups using the portal and make your environment look clean.


I hope this article helps you with migrating your resources to ARM. Any questions or feedback please feel free to leave a comment.

Monday, August 8, 2016

Azure Tags - Visio stencil

Once in a while you find that Microsoft hasn't updated their Visio stencils to reflect new features that have become available on the platform. Whilst working on a new Visio diagram I was struggling to find a Visio stencil that included Azure Tags or Azure Tagging. Very useful to illustrate how you plan to tag your Azure resources. Especially when using the ARM deployment model.

To work around this I created my own Azure Tag stencil. Please feel free to download it or distribute to who might benefit of this.

Happy Visio-ing!

Download

Thursday, March 17, 2016

Azure VM Activation

Azure VM Activation fail

One of the great things of Microsoft Azure is that license cost of the operating system is included in the running cost of the virtual machine. That saves you the hassle of having to procure operating system licenses and activating them through the internet or via your own KMS server.

This method Azure uses to active your server licenses is unfortunately not fool proof. It's dependent on the Microsoft Azure KMS service. This service needs to be available.

The KMS service that Azure VMs connect to is kms.core.windows.net and listens on port 1688. If you can't connect it for any reason you'll find your server reporting that it's not activated. The screenshot below indicates a Windows 2012R2 server which isn't activated..

Windows Server 2012 - Activate Windows

So why and how does it break?

The service stops functioning when your Azure virtual machine is no longer able to connect the the Microsoft Azure KMS server. Either because it cannot connect, or because the service is not available. Let's assume that the service is always available and therefore it's an issue on your virtual machine.

I myself have run into this issue due to the following. And I'll describe how I resolved this.

In the first scenario we migrated virtual machines from on premises infrastructure (vmware) to Microsoft Azure. The VMs were moved using DoubleTake Move and Azure Site Recovery.

After migration we found that the virtual machine would no longer be activated. Which makes absolute sense as the virtual machine in question was still pointing at the on premises KMS server!

To Update the Azure Virtual Machine run through the following commands.

1. Logon to the Azure Virtual Machine
2. Open PowerShell as a Administrator
3. Run the following command:
iex “$env:windir\system32\cscript.exe $env:windir\system32\slmgr.vbs /skms kms.core.windows.net:1688″

It should return the following:
Key Management Service machine name set to kms.core.windows.net:1688 successfully.
4. After that we'll run the command to activate the server.
 iex “$env:windir\system32\cscript.exe $env:windir\system32\slmgr.vbs /ato”
5. Which will if connectivity is working correctly result in the following.

Activating Windows(R), ServerDatacenter edition (12345678-1234-1234-1234-12345678) …
Product activated successfully.

Activating Windows






But what if this still won't work?
You might actually find that this doesn't work. And it could manifest itself with the following error.

Error: 0xC004F047 The Software Licensing Service reported that the computer could not be activated. No Key Management Service (KMS) could be contacted. Please see the Application Event Log for additional information.

Failed Activation

Hmm ok. Well it's likely to be due to network connectivity. To confirm what's wrong by running ping kms.core.windows.net. As per screenshot below in my case I couldn't even resolve the name. Let alone connect to it.

Connectivity test

Solution:
In my case it was all due to a name resolution. The virtual machine I was working on did not have a functioning DNS server to look up kms.core.windows.net. Therefore it could not contact the KMS server. This was simply resolved by adding kms.core.windows.net into the hosts file located in c:\windows\system32\drivers\etc.

Update the hosts file with the following entry.

23.102.135.246 kms.core.windows.net

Update host file

After this repeat the basic connectivity test by running ping kms.core.windows.net. Confirm it can now resolve the name. The ping can time out. It's just for the name resolution.

Resolution working
After this run the KMS activation command again and confirm your success!

Activation completed!

Hope you enjoyed this article. Any comments please feel free to leave feedback.