Last week I was troubleshooting a Windows Update issue at several Azure IaaS VMs for a customer. All those Windows Server 2012 R2 servers were workgroup members and had no Network Security Group (NSG) attached which could block the connection to the Microsoft Update servers. But whenever starting Windows Update the below error was shown after a few minutes.

To get this error fixed I followed the below steps. Be aware that you can retry running Windows Update again after each step because it could be already working again.

Step 1

If the server has been configured to use WSUS to get its updates, first wipe out those registry keys by running the below command in a PowerShell window (with admin privileges). Press Y to delete all registry keys when asked:

This also may reset some Windows Update settings, for instance, the one that decides if updates should install automatically or after asking permission. Therefore, you need to set your preferred settings afterwards.

Check for updates using Windows Update and see if the issue has been resolved, if not proceed to step 2.

Step 2

If you still receive the same error, run the following PowerShell Script to rename the SoftwareDistribution and catroot2 folder. These folders, which are maintained by the WUAgent (Windows Update Agent), are essential components for Windows Update. However, sometimes the content of these folders could prevent Windows Update from applying new updates to the server. When having trouble with Windows Update, it is safe to delete this folder. The server will always re-download all the necessary files, or re-create the folder and re-download all the components, if removed.

Now please check for updates using Windows Update to see if the issue has been resolved.

Step 3

If step 2 also does not fix the problem, you could try running the below command from an elevated PowerShell window. This command will import proxy information used by Internet Explorer in the Windows HTTP Services (WinHTTP). Several server roles, like the Microsoft Windows Update client, rely on WinHTTP to manage all HTTP and HTTPS traffic. Windows Update uses it mainly to scan for available updates.

1

2

3

# Import proxy settings

netsh winhttp import proxy source=ie

Step 4

As a last solution, you could try running the Windows Update Troubleshooter tool. To download and startup this tool run the below PowerShell commands.

The last weeks, I am assisting some customers with the migration of their existing Azure Service Manager (ASM) VMs to the Azure Resource Manager (ARM) portal. Most of those workloads are migrated with the use of Azure Site Recovery (ASR). The only thing ASR cannot handle for the moment is the migration of the Cloud Services Virtual IP Address (VIP). This public IP address can for example used by an IIS website running on a specific IaaS virtual machine (VM) which is part of that Cloud Service. You can work around this problem, as in many of these cases, by using Azure PowerShell. Below I will wake you through this process with an example.

Overview used Azure VMs:

1) First, we need to login and prepare the ARM environment. To do so run following PowerShell commands (change variables as needed):

5) When you now check the list of reserved IP addresses, it will show the reserved IP address 40.68.191.13 as unassigned. The attribute InUse is set to False and the ServiceName and DeploymentName attributes are empty

1

2

3

# List out the Azure Reserved IP addresses and their status

Get-AzureReservedIP arm-vm-001-pip

6) Also check if the Reserved IP address is valid for migration

1

2

3

# Validate the Reserved IP address for migration

Move-AzureReservedIP-ReservedIPName arm-vm-001-pip-Validate

7) Next we need to prepare the Reserved IP address for migration

1

2

3

# Prepare the Reserved IP address for migration

Move-AzureReservedIP-ReservedIPName arm-vm-001-pip-Prepare

8) Now run the following PowerShell command to finalize the migration of the Reserved IP address

1

2

3

# Commit to migrating of the Reserved IP address

Move-AzureReservedIP-ReservedIPName arm-vm-001-pip-Commit

9) You can verify the availability of the migrated Public IP address by login in to the Azure portal. Under Public IP address, you should see the resource with the correct IP address

10) Now, you can move this resource to the correct resource group. When you do so, and your asked to Confirm the move, click Yes

Last week while migrating Azure IaaS VMs from ASM to ARM, I noticed that one VM was showing the status “Running (Installing Extension)” in the Azure Classic portal. When I tried to connect to that specific VM with RDP no connection could be made. This status also prevented me from doing some automation activities, the VM however still responded to a ping.

When I opened the DASHBOARD page of the VM and looked at the extensions, I saw that the Microsoft.Compute.VMAccessAgent showed following error:

The simplest way I found to resolve this error was to delete the extension, and add it back. To do so login to the Azure portal with your Azure account. Go to Virtual Machines and click on the specific VM. On the opened blade select Extensions,right click the VMAccessAgent and click Delete. When asked to delete the extension select Yes

To reinstall the VMAccess extension open PowerShell ISE, connect to your Azure subscription with your Azure account and run the following command (replace cloud service name and VM name by your own)

In this blog post I will show you how you can connect an Azure Resource Manager (ARM) virtual network (VNet) to a classic or Azure Service Manager (ASM) VNet using VNet Peering.

VNet Peering, which was made generally available (GA) on September 28th, is a mechanism that allows you to connect two VNets in the same region through the Azure backbone network as they were a single network. This means that you don’t need a VNet gateway anymore, like when you setup a VNet-to-VNet VPN connection. It will allow full connectivity between the entire address space of the peered VNets. So, for example when VNet peering is setup, all virtual machines in the peered VNets will be able to communicate with each other. If you’re interested you can read more about VNet Peering via following link: https://docs.microsoft.com/en-us/azure/virtual-network/virtual-network-peering-overview

Before we start setting things up, first some things to keep in mind:

VNet Peering requires that both VNets are located the same Azure region

The VNets must be in the same Azure Subscription (only for ARM – ASM VNet Peering)

The IP address space of both VNets must not overlap

Using your peer’s VNet gateway (UseRemoteGateways and AllowGatewayTransit settings) is not supported when peering with an ASM VNet

There is a small charge for data transferred between VNets using VNet Peering (inbound and outbound data transfer $ 0,01 per GB)

To be clear, you can find below a drawing of my ARM – ASM VNet Peering setup

After all this is said and shown, we can start

1) First of all login to the Azure portal and sign in with your Azure account

2) Select Virtual Networks

3) Select your ARM VNet (in my case AZU-Vnet-ARM)

4) Click Peerings (like you can see there is one connected device AZU-APP-01)