You are browsing the archive for Cloud.

MABS v2: Error [0x8007007b] when performing a System State Backup on a DC running on a VMware VM

8:33 am in Azure, Azure Backup, Azure Backup Server, Cloud, Error [0x8007007b], MABS, MABS v2, Power, PowerShell, VMware by Wim Matthyssen

While configuring a Microsoft Azure Backup Server (MABS) v2 at a customer site, I encountered a problem while performing a System State Backup of their domain controllers (DC’s). The Protection Status showed Replica is inconsistent.

clip_image002

When looking in the Monitoring tab, following detailed message is show:

DPM cannot create a backup because Windows Server Backup (WSB) on the protected computer encountered an error (WSB Event ID: 517, WSB Error Code: 0x605A140).(ID 30229 Details: Internal error code: 0x8099ED0)

clip_image002[6]

Because the first part of making a System State Backup is done by the local Windows Server Backup (WSB) feature, logon to the protected server and open Windows Server Backup (Server Manager – Tools – Windows Server Backup). There a message was shown indicating that the last backup has Failed.

clip_image006

To view the error message a bit more in detail, open the Windows Server backup log file (with the exact date and timestamp) located in C:\Windows\Logs\WindowsServerBackup.

clip_image008

In the log file the following error message was shown:

Error in backup of C:\windows\\systemroot\ during enumerate: Error [0x8007007b] The filename, directory name, or volume label syntax is incorrect.

clip_image010

When looking in the Event Viewer (Application log) I could also find the following errors (CAPI2 – 513, Backup – 517):

Event ID 513

Cryptographic Services failed while processing the OnIdentity() call in the System Writer Object.

Details:

AddLegacyDriverFiles: Unable to back up image of binary Microsoft Link-Layer Discovery Protocol.

System Error:

Access is denied.

Event ID 517

The backup operation that started at ‘‎2017‎-‎11‎-‎16T15:16:22.000076700Z’ has failed with following error code ‘0x80780049′ (None of the items included in backup were backed up.). Please review the event details for a solution, and then rerun the backup operation once the issue is resolved.

clip_image012

clip_image014

Because all those errors descriptions do not really tell you what exactly is going wrong causing the backup to fail, you need to use the Diskshadow command-line tool to determine if there is an issue with the functionality of the VSS service or any of the application independent VSS writers.

To open the Diskshadow tool interface start PowerShell with elevated privileges and enter the below commands to write the output to a logfile.

clip_image016

When the logfile (c:\out.txt) is created open it with notepad and search for \\.

clip_image018

clip_image020

In my case, I found out there was an issue with the vsock.sys driver, which is part of the VMware vSockets Service and which is usually located in the C:\Windows\system32\drivers folder.

To fix the issue open the Registry Editor and go to the following location, HKLM\system\controlset001\services\vsock and changed the Start value to 1.

clip_image022

clip_image024

clip_image026

Also change the ImagePath entry from \SystemRoot\system32\DRIVERS\vsock.sys to system32\DRIVERS\vsock.sys.

clip_image028

clip_image030

When you have changed all those registry keys, logon to your MABS server and right click the failed System State backup and Perform a consistency check… (be aware that this could take a while). If the fix also solved your issue it would show OK when completed.

clip_image032

clip_image034

Hope this helps whenever you face the same error in your MABS environment. If you have any questions feel free to contact me trough my Twitter handle.

Wim Matthyssen (@wmatthyssen)

New features for Azure Backup and Azure Site Recovery released

10:02 am in Azure, Azure Backup, Azure Site Recovery, Cloud, Modern Backup Storage, Windows Server 2016 by Wim Matthyssen

Microsoft was very busy on the last day of May, because yesterday they launched many new features, not only for Azure Backup but also for Azure Site Recovery. I tried to list some of them below.

Azure Backup

  • Windows Server System State backups with Azure Backup now in public preview

This new extension allows the Azure Backup agent (MARS Agent) to integrate with the Windows Server Backup feature that is available natively on every Windows Server. It allows and provides seamless and secure backups of your Windows Server System State directly to Azure without the need to provision any on-premises infrastructure.

You can read more about it here

 

clip_image002

  • Microsoft Azure Backup Server v2 released which allows Windows Server 2016 and vCenter/ESXi 6.5 protection

This week Microsoft also released the second version (v2) of their Microsoft Azure Backup Server (MABS v2), which supports Windows Server 2016, vSphere 6.5 and the latest business critical applications such as SQL 2016, SharePoint 2016 and Exchange 2016. This new version is available for download from a Recovery Services vault in the Azure Portal or directly from here.

 

clip_image004

If you are interested to read more about MABS v2 you can do so over here

An important remark to make is that when you install MABS v2 on a Windows Server 2016 the VMware protection will be in preview mode, because VMware first needs to release support for VDDK 6.5.

In addition, the UserVoice I opened to address this issue to the Azure Team will be closed, so everyone who voted will get some votes back.

  • Introducing Modern Backup Storage with Azure Backup Server on Windows Server 2016

With the latest release of Azure Backup Server (MABS v2), which is based on System Center Data Protection Manager 2016 (SCDPM 2016), Modern Backup Storage can be used. This technology will improve performance and reduces consumption (50 % disk storage savings and 3x faster backups) by leveraging ReFS block cloning and deduplication.

 

clip_image006

You can read more about it here

 

Azure Site Recovery

  • Disaster recovery for Azure IaaS virtual machines with Azure Site Recovery is now in public preview

This will allow you to use Azure Site Recovery (ASR) to easily replicate and protect IaaS based applications running on Azure to a different Azure region of your choice without deploying any additional infrastructure components or software appliances in your subscription.

 

clip_image007

You can read more about it here

 

Enjoy reading about these nice new features and have fun testing them out.

Wim Matthyssen (@wmatthyssen)

Azure Security Center: Endpoint Protection installation failed with “Permission denied”

2:56 pm in Azure, Azure Security Center, Cloud, Endpoint Protection, Microsoft Antimalware by Wim Matthyssen

Most of you who are already familiar with Azure Security Center (ASC), know that it periodically analyzes the security state of your Azure resources. Whenever Security Center identifies a potential security vulnerability, it creates a recommendation. Last week when trying to apply the solution for such a Recommendation, namely Install Endpoint Protection, the Endpoint Protection installation failed with “Permission denied”.

clip_image002

The error showed that the installation failed because of an RBAC issue (permission error), However, the user used was a Subscription co-admin (Role Owner), so that could not cause the problem because he has all permissions needed.

Because Endpoint Protection is deployed as an extension and deployments of extensions are handled by the VM agent, my next troubleshoot step was to check the log of Azure VM agent on that particular VM.

The path to access this log is: “C:\WindowsAzure\Logs\WaAppAgent.log

clip_image004

clip_image006

But also no issue over here.

Therefore, after troubleshooting for some time, I finally opened a support request to Microsoft. As a response to this request, Microsoft confirmed that this error is under investigation of the product team and that there currently is a design change request in the making to get this problem fixed. For the moment, the problem only occurs in some Azure Regions. In the meantime as a temporary workaround in wait for the real fix, they suggest to install the Azure Antimalware extension from Compute or Azure PowerShell instead of with ASC.

To deploy the Azure Antimalware extension using the Azure Portal you can follow these steps:

Log in to the Azure portal

Select the VM, select Extensions and click Add on the Extensions blade

clip_image008

Select Microsoft Antimalware and click Create on the Microsoft Antimalware blade

clip_image010

To enable Antimalware with the default settings just click OK without putting in any configuration values. If you prefer you can also configure it with your own settings and values

clip_image012

Once the extension successfully installs, it reflects in ASC and the recommendation for that specific VM is gone. Hope this helps!

Wim Matthyssen (@wmatthyssen)

Azure PowerShell: Migrate an Azure ASM Virtual IP address (VIP) to an ARM Public IP address (PIP)

12:13 pm in ARM, ASM, Azure, Azure PowerShell, Cloud, PIP, Public Cloud, Public IP address, VIP, Virtual IP address by Wim Matthyssen

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:

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

clip_image004

clip_image006

2) Next we need to login to the ASM environment

clip_image008

3) As the next step we need to reserve the public IP Address

clip_image010

4) Next we need to de-associate the Reserverd IP address from the Cloud Service. Press Yes when asked

clip_image012

clip_image014

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

clip_image016

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

clip_image018

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

clip_image020

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

clip_image022

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

clip_image024

clip_image026

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

clip_image028

clip_image030

clip_image032

11) Afterwards you can assign the public IP address to whichever resource you would like

clip_image034

clip_image036

That concludes this blog post. Hope it comes to your use.

Wim Matthyssen (@wmatthyssen)

Azure IaaS: Build a VM from a Bring your Own License (BYOL) image with Azure PowerShell

9:16 am in ARM, Azure, Azure Hybrid Use Benefit, BYOL, Cloud, IaaS, PowerShell by Wim Matthyssen

For all people who do not yet know, with the Azure Hybrid Use Benefit you can use your on-premises Windows Server licenses that includes Software Assurance for Windows Server (Standard and Datacenter Editions) virtual machines (VM) in Azure. More recently also Azure Hybrid Use Benefits for Windows Client which includes Windows 10 (only Enterprise customers with Windows 10 Enterprise E3/E5 per user or Windows VDA per user – User Subscription Licenses or Add-on User Subscription Licenses – are eligible) came in Preview.

By using your existing licenses, you only pay for the base compute rate (equal to the Linux rate for VMs) without the Windows licenses cost, which can save you up to 40 %.

You can download the Azure Hybrid Use Benefit datasheet here

clip_image002

These days it’s even simpler to deploy a new Azure server VM whit your own on premise license via the Windows Server BYOL images available in the Azure Marketplace. There are images available for the following Server Oss (*be aware that not all Azure Subscriptions can use the BYOL images):

  • Windows Server 2008 R2 SP1
  • Windows Server 2012
  • Windows Server 2012 R2
  • Windows Server 2016 (not available in all regions)

You can search for the Windows Server images by running following PowerShell command:

clip_image004

In the above screenshot, you can see that some Skus now contain the BYOL suffix.

You can search for the Windows Client images by running following PowerShell command:

clip_image006

To build a VM with from a BYOL image you can run following Azure PowerShell script (adjust all variables for your own use):

clip_image008

The script is also available on Microsoft TechNet

When the script is completed and the VM is build, you can log into the VM via remote desktop. Like you can see the VM is not registered and you’ll able to use your own Windows product key.

clip_image010

Hope this comes in handy!

Wim Matthyssen (@wmatthyssen)

Azure IaaS: VM status Running (Installing Extensions)

6:13 am in ASM, Azure, Azure PowerShell, Cloud, IaaS, Installing Extension, Microsoft, Public Cloud by Wim Matthyssen

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.

clip_image002

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

clip_image003

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

clip_image005

clip_image006

clip_image007

clip_image008

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)

clip_image010

To check the current status of the extension, run following command (replace cloud service name and VM name by your own):

clip_image012

Or you can also check trough both Azure portals

clip_image014

clip_image016

After the reinstallation of the VMAccessAgent, it ran with STATUS Success and I was able to reconnect to the VM with RDP. This concludes this blog post, hope it helps whenever you have this issue.

Wim Matthyssen (@wmatthyssen)

Microsoft Azure Backup Server: Anti-Virus Exclusions

1:05 pm in Anti-Virus Exclusions, Azure, Azure Backup, Cloud, hybrid cloud, MABS, Microsoft Azure Backup Server by Wim Matthyssen

Running a solid, constantly updated antivirus product on your servers is a necessity to keep a healthy and secure server environment. However, with installing an antivirus product, you also risk having issues with certain workloads and services on those severs. Just like System Center Data Protection Manager (SCDPM), the Microsoft Azure Backup Server (MABS) is compatible with most antivirus software products. Though, the implemented antivirus product can also affect MABS performance and, if not configured properly, can cause data corruption of replicas and recovery points.

clip_image002

So, to avoid file conflicts and to minimize performance degradation between your MABS server and the antivirus software running on top of it, you should disable real-time monitoring by the antivirus software for all of the following processes and directories, which are listed below.

MABS processes to exclude from antivirus real-time monitoring

For information about configuring real-time monitoring based on process name or folder name, check the documentation of your antivirus vendor.

  • DPMRA.exe (*full path: C:\Program Files\Microsoft Azure Backup\DPM\DPM\bin\DPMRA.exe)
  • csc.exe  (*full path: C:\Windows\Microsoft.NET\Framework\v4.0.30319\csc.exe -> you can also exclude csc.exe in all the other Microsoft.NET Framework folders)
  • cbengine.exe (*full path: C:\Program Files\Microsoft Azure Backup\DPM\MARS\Microsoft Azure Recovery Services Agent\bin\cbengine.exe)

 

clip_image004

clip_image006

clip_image008

 

MABS directories in the MABS Program Files folder to exclude from antivirus real-time monitoring

Be aware that when you installed MABS on another drive then “C:”, like in the example below, look under the correct drive for the folders to exclude.

  • C:\Program Files\Microsoft Azure Backup\DPM\DPM\Temp\MTA\*
  • C:\Program Files\Microsoft Azure Backup\DPM\DPM\XSD\*
  • C:\Program Files\Microsoft Azure Backup\DPM\DPM\bin
  • C:\Program Files\Microsoft Azure Backup\DPM\MARS\Microsoft Azure Recovery Services Agent\bin
  • C:\Program Files\Microsoft Azure Backup\DPM\DPM\Cache (*MABS scratch folder)

 

clip_image010

clip_image012

clip_image014

clip_image016

clip_image018

 

Delete infected files on the MABS server

As a final remark, I would also advise to configure to delete infected files by default on the MABS server rather than automatically cleaning or quarantining them. Automatic cleaning and quarantining can result in data corruption because these processes cause the antivirus software to modify files, making changes MABS cannot detect.

 

In summary, there are a lot of antivirus settings you should keep track of when running MABS. I’ve tried to list all of the exclusions, so hopefully it will help you with getting the most out of your MABS setup. If you have any questions, feel free to contact me through my Twitter handle.

Wim Matthyssen (@wmatthyssen)

2016: My blog year in an overview

2:37 pm in Azure, Azure Backup, Azure RemoteApp, Client Hyper-V, Cloud, DC, Hyper-V, IaaS, PowerShell, Private Cloud, Public Cloud, Replica DC, SCAC 2012 R2, SCVMM 2012 R2, System Center 2016, W2K12R2, Windows 10 by Wim Matthyssen

Hi all,

As a blogger completely focused on Microsoft technologies, it was a fun year of writing about all those interesting and ever changing products and services. As we almost end the year 2016 and are preparing for 2017 to start, I wanted to make a list of all the blog posts I wrote throughout the twelve months of 2016. During the year, I’ve published 26 blog posts mostly about Azure, the System Center Suite and Hyper-V. Below you can find them all divided by technology.

 

clip_image002

Azure Compute – IaaS (ASM)

Step-by-step: Move an Azure IaaS VM between different Azure Subscriptions

Clean up Azure PowerShell when using different Azure subscriptions

Replica DCs on Azure – Removing the Azure Endpoints

Replica DCs on Azure – Transferring FSMO roles to the IaaS DCs

Replica DCs on Azure – Manage the Time Configuration settings on the DCs

Replica DCs on Azure – Domain Controller Health Check

Replica DCs on Azure – Promote the Azure IaaS VMs to a domain controller

Replica DCs on Azure – Add the Active Directory Domain Services role

Replica DCs on Azure – Adjustment of some server settings before promoting the DCs

Replica DCs on Azure – Initialize and format the additional data disk

Replica DCs on Microsoft Azure – Create the VMs with Azure PowerShell

Step by step: Change the drive letter of the Temporary Storage on an Azure IaaS v1 VM

 

Azure Networking

How to connect an Azure ARM VNet to an ASM VNet using VNet Peering

Replica DCs on Azure – Switch DNS servers for the VNet

Replica DCs on Azure – Create the Active Directory site for the Azure VNet

 

Azure Backup

Microsoft Azure Backup Server: Install a new version of the Microsoft Azure Recovery Services Agent

Microsoft Azure Backup Server: System State backup fails with WSB Event ID: 546

Microsoft Azure Backup Server: System State backup fails with the message replica is inconsistent

Step by step: How to install Microsoft Azure Backup Server (MABS)

 

Azure RemoteApp

An RDP connection to the Azure RemoteApp custom VM fails with the following error: “No Remote Desktop License Servers available”

 

Windows 10

How to deploy Windows 10 from a USB flash drive

 

System Center

System Center 2016 evaluation VHDs download links

Step by step: How to connect SCAC 2012 R2 to SCVMM 2012 R2 and Microsoft Azure

Step by step: Installing SCAC 2012 R2

 

Hyper-V

A list of tools that can be used to do a V2V from VMware to Hyper-V

Client Hyper-V – Using nested virtualization to run Client Hyper-V on a Windows 10 VM

 

Before I wrap up this blog post, I want to thank you all for reading my blog posts in 2016, and I really hope you will keep doing so in 2017. I wish you all a healthy, successful and outstanding New Year! See you all in 2017!

Wim Matthyssen (@wmatthyssen)

How to connect an Azure ARM VNet to an ASM VNet using VNet Peering

4:25 pm in ARM, ASM, Azure, Azure virtual network, Cloud, DC, DNS, VNet peering by Wim Matthyssen

Hi all,

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

clip_image002

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

clip_image004

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

clip_image006

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

clip_image008

5) Click Add

clip_image010

6) In the Add Peering blade, name your link (in my case LinkToVNetASM). Under Peer details select Classic. Choose the correct Subscription and the ASM Virtual Network you want to peer with. Leave Allow virtual network access Enabled, this will allow communication between the two virtual networks. Then click OK

clip_image011

7) After clicking OK the peering link will be created

clip_image012

8) When done, the two virtual networks are peered and you will see the PEERING STATUS between the two virtual networks is in a Connected state

clip_image014

9) Like you can see, both VMs can ping each other. Don’t forget to allow ping through the Windows Firewall

clip_image016

clip_image018

10) After adding AZU-DC-01 (10.0.1.36) as DNS server to the AZU-Vnet-ARM VNet, I was able to add AZU-APP-01 to the azuvlab.local domain which was created an AZU-DC-01

clip_image020

clip_image022

clip_image024

This concludes this blog post. If you have any questions don’t hesitate to contact me via twitter.

Wim Matthyssen (@wmatthyssen)

Step-by-step: Move an Azure IaaS VM between different Azure Subscriptions

11:22 am in Azure, Azure subscription, Cloud, IaaS, Microsoft Azure Storage Explorer, Public Cloud by Wim Matthyssen

From time to time, customers ask me to migrate Azure IaaS virtual machines (VMs) between Azure Subscriptions (for example moving a VM between the Dev subscription and the Prod subscription). There are several ways to accomplish this move, you can use Azure PowerShell or Azure Site Recovery (ASR), but mostly I do it the way that I will describe below.

1) First of all, you need to download an Azure Storage Explorer which enables you to move the VHD (page blob) which is used by the IaaS VM from one storage account (Azure Subscription 1) to another (Azure Subscription 2). Mostly I use the Microsoft Azure Storage Explorer which you can download for free via following link: http://storageexplorer.com/

clip_image002

2) When downloaded and installed you’ll need to add the two Azure Blob Storage Accounts, the one you want to move the VHD from and the one you want to move the VHD to. Open up the Microsoft Azure Storage Explorer, right click Storage Accounts and select Connect to Azure storage…

clip_image004

3) To find the Storage Account name and the Account key, just logon to the Classic Azure portal (https://manage.windowsazure.com/). Go to STORAGE select the correct Storage Account and click MANAGE ACCESS KEYS.

clip_image006

clip_image007

4) Fill in the correct Account name (STORAGE ACCOUNT NAME) and the Account key (PRIMARY ACCESS KEY)

clip_image009

clip_image011

5) Repeat steps 3 to 5 also for the Storage Account in the other Azure Subscription. At the end two Storage Accounts should be available to use in the Microsoft Azure Storage Explorer

clip_image013

6) Now stop the VM (logon trough RDP and choose shutdown) and you are good to copy/paste your VM’s VHD from one Storage Account to another

clip_image015

7) Open up Microsoft Azure Storage Explorer, right click the VHD for the VM you just stopped and select Copy

clip_image017

8) Open the other Storage Account’s Blob container (in my example azureos01 – Blob Containers – vhds) and select Paste. Be aware that this copy can take some time depending on the size of the VHD

clip_image019

clip_image021

clip_image023

9) When the VHD is completely copied, open the Azure classic portal and logon to the second Azure Subscription. Go to VIRTUAL MACHINES, then DISKS and select CREATE A DISK

clip_image025

10) Fill in a NAME (for example AZ-VM-SUB2) and select the correct VHD URL from the storage you just moved your VHD file to. Mark “The VHD contains an operating system.” and select Windows. Click the check mark to finish

clip_image026

clip_image028

clip_image030

clip_image032

11) As the next step create a new VM. Click NEW – COMPUTE – VIRTUAL MACHINE – FROM GALLERY

clip_image034

12) Select MY DISKS and select the newly created disk (in my example AZ-VM-SUB2)

clip_image036

13) In the next screen choose a proper VIRTUAL MACHINE NAME, the TIER and the VM SIZE

clip_image038

14) Create a new CLOUD SERVICE or select an existing one, choose the correct VNET and SUBNET. If an AVAILIBILITY SET is required, select or create it

clip_image040

15) Select the ENDPOINTS you require and finally press the check mark icon to start provisioning the VM

clip_image042

16) Like you can see the VM is created and starts Running. You should now able to connect to it again with RDP

clip_image044

image

17) If the VM looks and reacts like it should, you can delete the original VM with the attached VHD in the first Azure Subscription. Also don’t forget to delete the Cloud Service

This concludes this blog post, hope it helps!

Wim Matthyssen (@wmatthyssen)