Thursday, June 1, 2017

Install .NET Framework 3.5 on Azure VM

Older applications often require .NET Framework 3.5. The images available in the Azure Gallery of Windows Server 2012 and Windows Server 2016 don't include this piece of software which can be quite frustrating at times. Typically in order to install this piece of software you need to mount the iso or image of the operating system and add the role using the image as source.

Luckily Microsoft have decided to include the source files in the gallery images. The files are located in the following location c:\windows\sxs\.

Now how do i install .NET Framework 3.5?

Well there are a few options, the simplest is through Add or Remove Roles or through PowerShell. In this article I will demonstrate how to install it using PowerShell.

The command to run in PowerShell is:

Install-WindowsFeature Net-Framework-Core -source c:\windows\sxs


The steps:

1. Open PowerShell in the administrative context

Open PowerShell and run the command

2. Watch the installation progress. (takes approx. 30 seconds)

Track the progress
 3. Installation feedback confirms the success.

.NET Framework 3.5 install completed



Friday, March 17, 2017

Finding images in Azure

Microsoft Azure has lots of images available through the marketplace. All of them can be deployed through PowerShell but how do you actually select the right version.

An easy way to do this is by running the following little script. It will query the available images based on the location that you select. Use the box in the prompt to search for the publisher, or version that you are after. It will provide a clear output of the available templates and version. Super simple.

Enjoy!

Script:

#Logon to Azure
Login-AzureRmAccount
#Select your location
$loc = Get-AzureRmLocation | OGV -passthru | select Location
#View the templates available
$publisher=Get-AzureRmVMImagePublisher -Location $loc.Location |OGV -passthru | select publishername #check all the publishers available
$offer=Get-AzureRmVMImageOffer -Location $loc.Location -PublisherName $publisher.PublisherName|OGV -passthru |select offer #look for offers for a publisher
$sku=Get-AzureRmVMImageSku -Location $loc.Location -PublisherName $publisher.PublisherName -Offer $offer.Offer | OGV -passthru |select skus #view SKUs for an offer
Get-AzureRmVMImage -Location $loc.Location -PublisherName $publisher.PublisherName -Offer $offer.Offer -Skus $sku.Skus #Pick one

How does it work?

1. Select the Location you are planning to deploy your virtual machine.


2. Select the Publisher


3. Select the Offer

4. Select the Sku.


5. Review the output and use this in your deployment.





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.


Sunday, May 17, 2015

Resize Azure VM OS or Data Disk

Resizing an Azure VM disk using Update-AzureDisk -ResizedSizeinGB

Resizing an Azure VM disk was only possible until recently by using third party software such as Cloud Xplorer using a multistep approach. Not ideal. Best practice says provision Azure disk at maximum capacity but for one of my customers I faced the challenge where I migrated VMs using Azure Site Recovery. ASR is a great tool but it provisioned the target VMs with disks that match the size of the source, and it doesn't provide the option to change this. Now what if I run out of space? Or what if I don't want a 30 GB OS volume, but the 127 GB default size.

To overcome this problem I searched and found the following article. Azure Linux VM - Resize root volume. Great article, but it's only covers OS disks and Linux. The article includes a new command which hasn't been documented on MSDN yet. Which is Update-AzureDisk -ResizedSizeinGB

In my case I'm dealing with Azure VMs that run the Windows OS, and in many cases it's not only the OS disk that needs to be resized, but also the data disk.

I tested both scenario's and can confirm the Update-AzureDisk -ResizedSizeinGB works on both OS and data disks. In this article I'll explain how to use the command to resize Azure VM disks.

Note: The disk cannot be in use, shutdown the VM prior to making this change. And it cannot be reversed. You can only increase the size, the command will not allow you to shrink. 

The command

The command is pretty straight forward and all you need is to be a co-administrator and running the latest AzurePowerShell cmdlet. The command itself is as follow. 

Update-AzureDisk -DiskName 'MyDiskName' -Label 'MyLabel' -ResizedSizeInGB 300

Changing the disk size Step-by-Step


The Azure VM OS disk resize

1. First of all we'll connect to the subject VM and check out it's OS disk size. In this case it's a standard Azure VM with a 127GB disk. It can of course also be a much smaller disk which is in desperate need of resizing.

Azure VM OS Disk - 127 GB


2. De-allocate the Azure VM. The disks cannot be in use at the time of the resize.

3. Connect to your subscription using the latest Azure PowerShell cmdlet. 

4. To resize the disk you'll require the Diskname. To retrieve this information, in my case of VM ate-azr400, run the following command. If you want to make your life easy, store this information in a variable.
Get-AzureVM -ServiceName ate-azr4 -Name Ate-azr400 | Get-AzureOSDisk


Retrieve Azure VM DiskName


5. Run the following command to resize the disk. This will take a few second so be patient while the resize takes place.
Update-AzureDisk -DiskName ate-azr400-ate-azr400-0-201502180257360595 -Label Resized -ResizedSizeInGB 300


Update-AzureDisk -ResizedSizeinGB


6. Now have a look in the portal and browse to the container where the OS disk is stored. You'll find that the VHD has increased from the former 127 GB to 300 GB.

New size in Portal


7. Power On the Azure VM, and open the disk management to view the changes that have been applied. If you require the space extend your volume.

Resized VM OS Disk - 300 GB


The Azure VM Data Disk Resize

To resize the Azure VM Data Disk you pretty much follow the same process. The only difference is the command used to retrieve the Azure Disk Name.

1. To resize Azure Data Disk you'll require the Diskname. Note that this time I run Get-AzureDataDisk. In this case I want to extend the 10 GB disks.
Get-AzureVM -ServiceName ate-azr4 -Name Ate-azr400 | Get-AzureDataDisk


Get-AzureDataDisk


2. Next I run the same Update-AzureDisk -ResizedsizeinGB cmdlet to resize the Azure VM Data disk. This time I run it with the other DiskName.  
Update-AzureDisk -DiskName ate-azr400-ate-azr400-1-201505171031360397 -Label ResizeDataDisk -ResizedSizeInGB 150

Resize Azure VM Data Disk


3. If I now retrieve the information again I'll find that the disk size has been updated to 150 GB. 

Resized to 150 GB.

4. Power On the VM again and review the changes. You should find that the disk has now changed to 150 GB.

Disk size increased to 150 GB



I hope you enjoyed this walk through of how to resize a Azure VM disk. As mentioned earlier in the post, this change cannot be reversed.