Master & Cmd-R

Resize Azure Managed Disk

I recently was trying to resize the OS Disk of an Azure VM that I had just created, and ran into an error while using these instructions. In case you missed it, make sure you stop/deallocate your VM before trying to update the disk – otherwise it’ll just fail on you.

For the record, this is what the PowerShell looked like that I was trying to use:

$rgName = ‘My-Resource-Group’
$vmName = ‘My-VM’
$vm.StorageProfile.osDisk.DiskSizeGB = 1023

Update-AzureRmVM -ResourceGroupName $rgName -VM $vm

No dice! 🙁

Update AzureRmVM: Managed disk size via virtual machine ‘My-VM’ is not allowed. Please resize disk resource at /pathtomanageddisk/diskname.

Error code: ResizeDiskError

Now, the reason for this is that I had created this new VM using managed disks, and you can’t update those directly using the Update-AzureRmVM command. It took a little bit of digging to figure out how to update that managed disk, so I figured I’d post how I’d done it, in the hopes that it’ll help someone else out.

Since it’s a managed disk, running Get-AzureRmStorageAccount will not show you your disk – instead, you need to run Get-AzureRmDisk.

You can see that my disk size is 127GB, and not the glorious Terabyte I’m hoping to see:

Now that you’ve found your disk, go ahead and grab the name of your disk (or pull it into a variable if you prefer) and then simply update the size of the disk with the following command:

New-AzureRmDiskUpdateConfig -DiskSizeGB 1023 | Update-AzureRmDisk -ResourceGroupName $rgName -DiskName MyVM_OsDisk_1_crazylongnumbers

Verify that your disk looks correct by running

Get-AzureRmDisk -DiskName MyVM_OSDisk_1_crazylongnumbers

Next, Start your VM back up using the following command:

Start-AzureRmVM -ResourceGroupName $rgName -Name $vmName

(or use the Azure portal if you prefer, but c’mon… PowerShell!!)

Once back in your VM, you can see that your disk size is unchanged – this is because Windows knows about the newly available space, but doesn’t auto-expand your disk drive.

Right click on the start menu, and select Disk Management. You can see your disk now has unallocated space to match what you specified in PowerShell:

Go ahead and select the disk and extend it to fill the usable space, and you’re good to go!

Hope this helps – if this helped you, or you have any questions, feel free to shoot me a comment below.

Oops! Access to Azure Active Directory is not available

When trying to access the Azure AD admin portal from within Office 365 recently, I ran into the following error:

Now, this shouldn’t be an actual problem, as Office 365 is built on the Azure AD identity platform, and clicking on the link to the admin portal should just work properly – but then *should* is a funny word, isn’t it?

One of the suggestions I found on the web was to go to, and sign up for a trial subscription:

Well, don’t do this: (it’s not necessary!)

See, the problem comes from the fact that the Azure AD link in Office 365 still goes to the old Azure portal (, and

Instead of going through all that mess, and signing up for an Azure trial you don’t need, simply navigate to, and click on Azure Active Directory: (ignore this error about your dashboard not found, it doesn’t matter)

As you can see, all is right with the world!

Update: All fixed!

Microsoft has now fixed this problem, and the link to Azure AD from the Office 365 portal now properly resolves to a new portal:… Shiny!!

Azure Point 2 Site VPN: DNS config is wrong

Just ran into this issue when I created a P2S VPN on my Azure Virtual Network – I downloaded the client and connected ok, but I realized I could only connect to my servers via IP, not by FQDN.

Checking my local IP settings, I realized that the DNS Server on my VPN connection was set to a public DNS server and not my Domain Controller / DNS server in Azure.

This wasn’t completely unexpected, because when I created the vnet I used Google DNS, and then I went back to the settings and changed it later once I had my DC set up.

It turns out that when you download the P2S VPN client from the Azure portal, it’s not really a client in the traditional sense (like the Cisco AnyConnect client) – it’s actually a number of config files that get installed to %appdata%\Microsoft\Network\Connections\Cm\connection-name\.

You can try editing the phonebook file as I’ve seen suggested around the web, but I don’t really like that solution – in order for this to work, you need to dial through the phonebook (pbk) file, and not just through the built in Windows VPN connection.

The answer, thankfully, is simple – just remove that VPN client and re-download the P2S VPN client from the Azure portal. Install it on your PC as before, and you’re good to go:

All better now!

Add-AzureAccount fails – Your browser is currently set to block cookies

I recently ran into an issue while running Server 2016 attempting to connect to my Azure account through PowerShell – after installing the Azure PowerShell Modules and running Add-AzureAccount, an authentication window opens, allowing you to connect to your Azure account. However, instead of seeing the logon window, I would only get the following error:

“Your browser is currently set to block cookies. You need to allow cookies to use this service.”

Figuring that Edge was blocking cookies due to the default security configuration in Server 2016, I attempted to open Edge so that I could unblock those sites and be able to log in to my Azure account and continue my server configuration. Seems like that’s a dead end as well!

I hadn’t run into this before, but apparently it’s a known issue – I decided to just create another admin account rather than going down the route of editing my registry settings, as I didn’t really want to start poking holes in my brand new server. It might be completely safe, but I figured I’d just leave it as is – I didn’t really see much use for Edge on my default admin account anyway.

However, after creating a new admin account, logging in, and launching Edge, I found that cookies were indeed already enabled, and I was still having the exact same error connecting to my Azure account in PowerShell. It turns out that the culprit is Internet Explorer, and not Edge at all! If you open Internet Explorer (Start – Run – iexplore.exe) and attempt to log in to or you’ll receive a very similar error:

The answer to this strange little conundrum is just to go in and add the following two sites to your trusted sites in Internet Explorer:

Once this was done, I was able to connect to my Azure account using both Microsoft Account (, and my Office 365 account ( Knowing this, I went back to my built in administrator account and added both those sites to my trusted sites in IE, and all was well with the world again.

Long story short… just add the Microsoft authentication sites above to your Trusted Sites in IE 11 (even on your built in admin account), and you’ll be able to connect to your Azure account properly.

Hope this helps save you some time searching for an answer to this weird problem – good luck!

Find which server DirSync is installed on

As consultants, we often find ourselves in environments that haven’t been properly managed, and usually not properly documented – which is generally why we get called in.

In this particular situation, I was asked to install and configure DirSync / AAD Connect for a client – only to find out that it was already installed! The funny part is that the client didn’t know it was installed, and nobody knew what server it was installed on, so I had to do some digging to find it.

Before logging in to every server and checking running services, installed programs, etc., I thought I’d take a look to see if there was a better way. Sure enough, fellow MVP Benoit Hamet suggested this answer on the Office 365 community forums. All props go to him for providing this simple solution:

“The MSOL account has a description which contains the server name on which it’s been installed”

So I checked in AD, and sure enough, this is what I found:


And in the description?

“Account created by the Windows Azure Active Directory Sync tool with installation identifier ‘e80ac210a5e14d6095c0fcea79acc5f9’ running on computer ‘RANDOMSERVER‘ configured to synchronize to tenant ‘‘. This account must have directory replication permissions in the local Active Directory and write permission on certain attributes to enable Hybrid Deployment.”

Brilliant – thanks Benoit!

Creating OME Transport Rules

Once you’ve enabled Azure Rights Management in the Office 365 portal and configured your tenant, your next step is to create transport rules that will encrypt (and optionally decrypt) email messages based on the settings you choose.

Start by going to the Exchange Admin Center, and click on Mail Flow, then Rules. Click the + icon to start creating a new rule, and select Apply rights protection to messages…

Provide a name for the rule, and the initial criteria that will trigger the policy:

Next, you can select the type of RMS policy that will be assigned:

Clicking this *Select one… option allows you to choose one of the RMS templates that you’ve defined.

Or you can choose to use the built in OME option:

The difference between the two options is basically that Office 365 Message Encryption would be considered the basic policy, and choosing an RMS template allows you to specify advanced options.

The decryption option is the reverse of our first policy:

Note that the decryption option ONLY decrypts the replies to emails sent out from this organization. If another organization has their own encryption policies in place to encrypt email sent to your organization, this will not decrypt those messages automatically. The purpose of setting up this decryption is to make the process more user friendly, and seamless for users in your environment.

Tenant changes required for Office Message Encryption

When setting up Office 365 Message Encryption (OME), there are some changes to your tenant’s IRM (Information Rights Management) configuration which requires connecting to Exchange Online through Powershell.

Once connected to Exchange Online, start by checking your existing IRM Configuration by running the following command:


Note that there is no RMS Online Key Sharing Location defined, so you’ll need to perform that step next:

Set-IRMConfiguration -RMSOnlineKeySharingLocation

Next, Import the RMS Online Trusted Publishing Domain:

Import-RMSTrustedPublishingDomain -RMSOnline -name "RMS Online"

This will configure the required settings to enable IRM in your environment, as well as add two default IRM templates: Credential -Confidential, and Credential – Confidential View Only.

If you check your IRM configuration again after performing these steps, you’ll see the configuration changes that were made:

The final configuration step in this phase is to enable Internal Licensing by running the following command:

Set-IRMConfiguration -InternalLicensingEnabled $true

You can then test your IRM Configuration against a user in your environment to confirm that everything is set up properly. Note that at this point, no rules have been defined for encrypting email, but they are now able to be defined.

Test-IRMConfiguration -Sender

Once you’ve completed these steps, you’re ready to define encryption rules in Exchange Online.

New Microsoft Azure portal

The new Microsoft Azure portal was announced today at Build 2014, and I immediately headed over to check it out at I love it! The home page is clean and nicely laid out, very similar to the Windows Start page with live tiles that dynamically update, and give you different options when you click on them:

040314 2125 NewMicrosof1 New Microsoft Azure portal


Clicking on the links on the left open up more features and functions:

040314 2125 NewMicrosof2 New Microsoft Azure portal


As you drill down, more dashboards and functions open up along the right, allowing you to view the status of your Azure properties:

040314 2125 NewMicrosof3 New Microsoft Azure portal


Clicking on the Gallery (bottom left on the home page) allows you to browse all of the available options and quickly provision them. Since the portal is still in preview, you have to return to the existing Azure portal to actually provision a new server or service, but it’s a great indicator of what is coming.

040314 2125 NewMicrosof4 New Microsoft Azure portal


This guy is my favorite so far icon biggrin New Microsoft Azure portal

040314 2125 NewMicrosof5 New Microsoft Azure portal

I’m loving these changes – I’m a big fan of software and user interfaces that are clean and beautiful, and the new Azure portal definitely is both of these.

Alongside of these announcements, changes to the Windows 8.1 interface are in the works – the start page continues to get better and better, and I’m going to be hitting that download as soon as it’s available on April 8th.

It’s a good day to be a fanboy! icon biggrin New Microsoft Azure portal
+Jeremy Dahl

How Windows Azure Heals Itself

Great discussion with Mark Russinovich about how Windows Azure heals itself when it’s sick – this is the magic of Infrastructure as a service (IaaS): it all happens behind the scenes, and you usually don’t even know that it’s happened!


(click on the image to be redirected to the for the video)