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.

Exchange Online Hybrid: Fixing free/busy issues

Now, I’m just going to come out and say it – this is NOT the only fix for free/busy issues when configuring Exchange Online Hybrid with an on-prem Exchange server. If you’re reading this, then it’s more than likely that you (like me), have been reading countless TechNet articles, blog posts, forum posts, etc. Well, at the end of it all, this was the fix for my free/busy issues, and I thought others might benefit by finding this ahead of time, and hopefully cut out some of the Googling Binging… 😉

The Problem:

Pretty straightforward – users on prem could not see the free/busy status of users in Office 365. I worked my way through every setting I could think of, including (but not limited to) Autodiscover, DNS, permissions, certificate settings, Exchange CU level, to no avail!

Also, if you haven’t seen this before, the hybrid environment free/busy troubleshooter was actually a great help in systematically working your way through potential problem spots.

The Solution:

Eventually, I came across this TechNet blog post which gave me the answer I needed – now, I will say that I’ve never had to set this before, and never noticed this setting missing on previous hybrid configs, but anyway…

In my on-prem environment, the TargetSharingEpr setting was blank, like so:

Thankfully, the fix for this is simple – run the following from an elevated PowerShell prompt:

Get-OrganizationRelationship | Set-OrganizationRelationship -TargetSharingEpr https://outlook.office365.com/ews/Exchange.asmx

This is what it should look like when you’re done:

I also checked my Exchange Online org settings and found that the TargetSharingEpr was also blank:

Now, I wasn’t having any issues with free/busy in this direction, but I thought I’d go ahead and update it anyway – just in case. Make sure that this time around, you’re connecting to Exchange Online, and not your on-prem Exchange, and point it back to your EWS endpoint:

Get-OrganizationRelationship | Set-OrganizationRelationship -TargetSharingEpr https://hybrid.mydomain.com/ews/exchange.asmx

(I don’t have to tell you that hybrid.mydomain.com needs to be updated to your own hybrid namespace, do I?) 😛

When you’re done, it should look like this:

There you have it – hope this helps someone else solve some free/busy issues without having to spend hours of frustrating trying everything else!

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 https://portal.azure.com or https://login.microsoftonline.com 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 (@outlook.com), and my Office 365 account (@microsoftonline.com). 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!

Distribution Groups, Naming Policies and You!

Office 365 Groups: Next Gen Distribution Lists?


Lately Microsoft has been putting a lot of focus on Office 365 groups as an ad hoc, user driven collaboration platform. These Office 365 Groups are also used for Microsoft Planner, as each Office 365 Group creates a plan, and every time a user creates a new plan a group is spun up in the background to handle all the collaboration and messaging pieces. Even going into the Exchange Online Portal and creating a new distribution groups will create an Office 365 Group by default – you need to select the option to create a regular distribution list instead.


These groups perform the job they were designed for quite admirably, and I’m a big fan of the user experience and control – however, where I feel these Groups are lacking is in the admin controls. To date, there is no way to export that mailbox data if you need to archive or delete the group, which makes it a pretty big gap in management (in my opinion at least).

Self Service: A Two-Edged Sword

One of the big selling features of these groups is that users can create their own groups – either in Outlook 2016 or Outlook on the Web. Now, this feature is great for allowing users some of the control that IT typically owns, and allowing them to quickly get some collaboration going – the downside is that it’s harder for IT to control and manage, and your directory can quickly become messy with groups users are creating to just test things out, or play around with the features. Thankfully, Microsoft has recently added the capability for users to delete groups that they own (something that was missing when groups where introduced).

Group Naming Policy

In order to keep a reign on the chaos of users creating and deleting groups, admins can implement a group naming policy in EAC, which will help to at least standardize the group naming structure, and highlight a few keywords that you want to keep off the naming roster.

To configure your naming policy, log into the Exchange online portal (https://outlook.office365.com/ecp), navigate to recipients – groups, and then click on the three dots to open up the context menu.

Click on Configure group naming policy:


Your first option is a prefix, which can be either an Attribute or Text:


One idea would be to prefix these user-created groups with an identifier, like “O365-“, but you can obviously make this whatever you want.


And then again, you can add suffix(es) if you want – again, you can use whatever you want, but an idea would be to use the city attribute of the user creating the group:


This policy will apply to all user created groups, whether created in Outlook or OWA – groups created from the admin portal will bypass this setting.

The Problem with Synced Groups

Oddly enough however, groups created through PowerShell or DirSync will still end up with this naming policy applied. This can become a problem, because a distribution group created on premise might be named “My New Group”, while the synced group will be named “O365-My New Group-Vancouver” (or whatever your policy is).

Here’s how you get around that problem:


<# .SYNOPSIS Script to create distribution groups and bypass the Exchange Online group naming policy. .PARAMETER GroupName This parameter is required - if spaces are required in the Group name, make sure to put the name in quotes. .NOTES File Name : create-DistributionGroup.ps1 Author : Jeremy Dahl (jdahl@masterandcmdr.com) .EXAMPLE .\create-DistributionGroup.ps1 -GroupName MyGroup Creates a group named "MyGroup", with a primary SMTP address of mygroup@mydomain.com .EXAMPLE .\create-DistributionGroup.ps1 -GroupName "My Group" Creates a group named "My Group", with a primary SMTP address of mygroup@mydomain.com #>
 
param (
    [Parameter(Mandatory=$true,ValueFromPipeline=$false)]
    [string] $GroupName = ""
    )

$smtpDomain="@mydomain.com" # Change this field to match your smtp domain
$exchangeServer="ExchangeServer" # Input your on premise Exchange Server here
$aadConnectServer="AADConnectServer" # Input your AAD Connect Server here
$GroupOU="OU=Managed Groups,DC=mydomain,DC=com" # Pick an OU for your groups to be created into - can be moved once the group is synced up.

$exchangeURI="http://$exchangeServer/PowerShell/"
$primarySMTP = $GroupName + $smtpDomain
 
# -- Connect to Office 365 -- #
$credential = Get-Credential
Connect-MsolService -Credential $credential
$ExchangeSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $credential -Authentication Basic -AllowRedirection
$importresults = Import-PSSession $ExchangeSession -AllowClobber
 
<# -- Create Group in Exchange Online -- #>
New-DistributionGroup -Name $GroupName -DisplayName $GroupName -PrimarySmtpAddress $primarySMTP -IgnoreNamingPolicy
Remove-PSSession $ExchangeSession
 
 
<# -- Create a local Exchange session and import session for use -- #>
$LocalSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri $exchangeURI -Authentication Kerberos
Import-PSSession $LocalSession -AllowClobber
 
<# -- Create Group On Premise -- #>
New-DistributionGroup -Name $GroupName -OrganizationalUnit $GroupOU

<# -- Get Credentials and run AADSync remotely -- #>
$adCreds=Get-Credential
Invoke-Command -ComputerName $aadConnectServer -ScriptBlock {Start-ADSyncSyncCycle -PolicyType Delta} -Credential $adCreds
Write-Host "Initiated Azure AD Sync - Delta" -ForegroundColor Green

Download the script: 

This script can be run on premise, and only requires the Group Name as a parameter. It then connects to Exchange Online and creates the group, ignoring the naming policy. From there, it connects to Exchange on premise, and creates the same group, using the same group name. Once AAD Sync runs, it matches the group together, and treats it as a single group going forward.

 

Once the groups have synced up, I’ve confirmed that you can add members to it from on premise as normal, and even delete it on premise (removing it from the cloud as well) if necessary.

That’s it – problem solved!


On Premise attributes not updating properly

I’ve run into this problem a few times during recent migrations, so I’ve started incorporating the script blocks below into my migration scripts to make sure that I have a consistent experience with moving shared mailboxes, and enabling archive mailboxes.

Issue:

Sometimes msExchange attributes are not properly updated when a mailbox is moved in Exchange. This affects shared mailboxes, as well as creating archives on user mailboxes: https://support.microsoft.com/en-us/kb/2710029. This issue can also cause the mailboxes to show up with the wrong icons in the Exchange console on prem, which can be quite confusing!

Resolution:

Use the following script blocks to update the msExchRemoteRecipientType and the msExchangeRecipientTypeDetails – once these attributes are updated and DirSync has run, mailboxes will show up properly both on premise, and in Office 365. Update $samAccountName with the username you want to update.

Update user attributes to enable archiving:

Set-AdUser $SamAccountName -Replace @{msExchRemoteRecipientType=“3”}

Set-AdUser $SamAccountName -Replace @{msExchRecipientTypeDetails=“2147483648”}

Update AD attributes to disable user account and convert to a shared mailbox:

Disable-AdAccount $SamAccountName

Set-AdUser $SamAccountName -Replace @{msExchRemoteRecipientType=“100”}

Set-AdUser $SamAccountName -Replace @{msExchRecipientTypeDetails=“34359738368”}

This article was a great resource for listing all the different recipient types: http://memphistech.net/?p=457. Hope this helps you solve any mailbox weirdness you run into during migrations!