Hi all,

These days I’m working on several Azure projects for different clients. As a result, my default subscription data file which is used by Azure PowerShell is completely filled up with settings from those different subscriptions. Frequently, I notice that Azure PowerShell mixes up all this information and does not perform as expected. I strongly assume this is caused by the cached credentials and other elements. In order to fix this, I regulary clean up my Azure PowerShell to have a better overview and to accomplish a better working scripting environment. Below you can find the Azure PowerShell cmdlets to clear a specific customer’s Azure subscription from Azure PowerShell. I will also show you how you can clear your complete Azure profile.

Delete a specific Azure subscription from PowerShell

1) Open up PowerShell ISE as an Administrator and run the following PowerShell cmdlets to list all Azure subscriptions available in the default subscription data file on the computer in use, which can be found under the following location C:\Users\%username%\AppData\Roaming\Windows Azure PowerShell and is named AzureProfile.json

2) To delete a specific subscription from the date file run the below cmdlet (adjust for your own purpose). You may be sure that this cmdlet will not delete the subscription from Azure in any way. You can use this cmdlet with the -Force parameter to suppress the confirmation prompt

3) If the above cmdlet ran without any errors the specific subscription will not be shown anymore when you’re re run the Get-AzureSubscription cmdlet and it should also be cleared from the subscription data file

Clear your complete Azure Profile

1) Open up PowerShell ISE as an Administrator and run the following PowerShell cmdlets to completely clear your Azure Profile on the computer in use

2) If the cmdlet ran without any errors your Azure Profile should be cleared.

This ends this short blog post, hope it helps and till next time!

Wim Matthyssen (@wmatthyssen)

From Windows 10 build 10565, Microsoft added a long awaited feature called nested virtualization. This technology will allow you to run Hyper-V inside of a virtual machine (VM) running on a Windows 10 (Client Hyper-V) or Windows Server 2016 host. In other words, in the simplest configuration it enables you to install Hyper-V in a guest VM, whit the possibility to create and also run VMs on top of that Hyper-V host VM. Completely different than the previous situation with Windows Server 2012 R2 or Windows 8.1, were you could create the VMs, but weren’t able to actually start them. This new feature kind of creates a second virtualization layer, like shown in the detailed screenshot below.

This new technology is very useful when you are setting up a test/lab environment because there is no need to buy a lot of expensive hardware anymore, it simply can run on top of your notebooks OS. It also comes in handy whenever you want to train you’re failover clustering or even your System Center skills. But it’s main purpose and probably Microsoft’s main reason to finally created this feature, is to enable you to work with Hyper-V containers (operating system level virtualization). If you’re interested in reading more about this type of containers you can do so via following link: https://msdn.microsoft.com/en-us/virtualization/windowscontainers/management/hyperv_container

Now before we start playing around with this new feature, I will first list up some things you should really keep in mind:

• The Hyper-V host must be running at least Windows 10 build 10565 or Windows Server 2016 Technical Preview (TP) 4
• An Intel processor with Intel VT-x (AMD-V is not supported yet) and EPT technology is needed to be able to use Hyper-V
• Currently only Hyper-V is supported, all other hypervisors like for example vSphere ESXi will fail to run
• Be aware that some VM features are not supported or will fail: Dynamic Memory, applying checkpoints, Live Migration and save/restore, hot memory resizing
• The VM should have more than 1 vCPU
• At least 4 GB RAM should be attached to the VM
• MAC address spoofing must be enabled on the NIC attached to the VM
• If you’re using Windows 10 Enterprise as the host, you should turnoff Virtualization Based Security (VBS) because it will prevent the use of nested virtualization
• Plenty of available RAM is needed (at least more than 4GB of RAM is preferred to get started)

After going through the theory it’s now time to get our fingers wet and get everything up and running. I will walk you through all the different steps needed to use this feature on a Windows 10 Enterprise computer. In my example I will setup a generation 1 VM (Windows 10) with a PowerShell script to test the nested virtualization scenario. So off we go.

1) First of all, you should check your windows version (should be build 10565). Click run and type winver

2) Create two internal virtual switches, one is to use your wireless card and the other one will be used in a later step as a Hyper-V vSwitch inside the VM

3) To install the VM, run the following PowerShell script (customize to your need).

4) Go through the Windows Setup Installation Process on the newly created VM

5) When installation is completed shutdown the VMs and run following PowerShell commands on the Windows 10 computer (host) to set the Virtualization Extension for the vCPUs and to enable MAC spoofing on both VMs. Be aware a warning message will appear that Nested Virtualization is an unsupported preview feature. When both commands ran successfully start up the Windows 10 VM

6) To configure the W10-TST VM and to install the Client Hyper-V role with all tools, run the following PowerShell script (customize to your need). Connect to the VM with a Virtual Machine Connection with Enhanced session enabled

7) To create an external virtual switch on W10-TST, logon to this sever with RDP and run the following PowerShell cmdlet as administrator (customize to your need)

8) To create a nested VM named VM1-NESTED on W10-TST, logon to this VM with RDP and run the following PowerShell script as administrator (customize to your need)

9) Go through the Windows Setup Installation Process on the newly created nested VM named VM1-NESTED on W10-TST

10) If the installation is successful, you should now have a nested VM running like in the screenshot below

This concludes this blog post. Keep tuned and I’ll be back soon.

Wim Matthyssen (@wmatthyssen)

Hi all,

Some time ago a client received following alert on his Microsoft Azure Backup Server (MABS):

“Azure Backup raised the following alert for the subscription in use: (ID 33406). A new version of Windows Azure Backup Agent is available. You can review details about the new version and download it from http://go.microsoft.com/fwlink/p/?LinkId=229525. (ID 100083) More information”

Like you all can read this alert was raised because there is a new version of the Azure Backup Agent available. In the Event Viewer on the MABS server you can also find following Warning message under the Application and Services Logs, CloudBackup, Operational:

“A newer version of Microsoft Azure Recovery Services Agent is required.”

To install this new agent the following steps were taken:

1) Check the current Azure Backup Agent Version. To do so open the MABS console and click Management. Under Online you can find the Azure Backup agent version. Like you can see in the screenshot below for the moment version 2.0.9032.0 is installed

2) Download the latest version of the agent via following link: https://support.microsoft.com/en-us/kb/3162327 . Go to the section Update information were you can find the update package for agent version 2.0.9037.0 In my example I saved it under the Temp folder

3) Go to the Temp folder and Run the MARSAgentInstaller as administrator

4) If the UAC screen pops up, click Yes

5) To continue installing the update, click Next

6) If all required software is in place, click Upgrade. This will start the upgrade process

7) When the Upgrade is successful click Finish

8) If you check the Azure Backup Agent version again, you can see version 2.0.9037.0 is installed

9) You can also verify the current version by opening Run and typing appwiz.cpl to open Programs and Features. Look for the Microsoft Azure Recovery Services Agent which should have version 2.0.9037.0

10) Be aware that by default the Warning message will stay there for 30 days. To clear this message after the update you can inactivate it by right clicking the message and selecting Inactivate alert or by rebooting the MABS server several times (3 times at least)

This concludes this blog post, hope it helps!

Wim Matthyssen (@wmatthyssen)