Master & Cmd-R

Unable to connect to Exchange Online Shell

Access Denied (No soup for you!)

I’ve been using this script to streamline my connection to the Exchange Online Shell, and it’s been working well for me – until recently when I ran into this weird “Access Denied” error:


As you can imagine, I started out by troubleshooting issues with my account, trying to figure out why I was being denied access, including stuff like what this article talks about (bad username/password, not being an Exchange Online admin).

I knew however, that this was not my issue – I confirmed my password, and my account was a global admin in Office 365. Turns out, the issue was caused not by any specific access being denied on my user account, but more specifically because I was connecting to an Exchange Online tenant that was configured for Multi Factor Authentication! If you’re getting the access denied error connecting through the old way, it’s time for a bit of a change.

The Fix:

There are two ways to resolve this issue, depending on how you want to use your scripts – I use the connection script above quite frequently in my other scripts to connect to Exchange Online, and so I wanted to be able to keep using it.

Fix 1: Use an account that is not enabled for MFA

The first fix is more of a workaround than a fix – simply use a global admin account (or an account with the Exchange Admin role) that is not enabled for multi-factor authentication. This is a good place to set up a cloud only admin account, and connect using admin-user@tenantdomain.onmicrosoft.com, or simply use an on-prem account with MFA disabled – either/or.

Connect using MFA:

If instead you want to start connecting to the Exchange Online shell using MFA and Modern Auth, you’ll need to install the Exchange Online Remote PowerShell Module, and follow the instructions here.

You know you’re using the right module, because it has a blue Exchange icon, and it also gives you this information in yellow text when it loads.


Like it says, you initiate a connection by using Connect-EXOPSSession, like so:


You can see that you’re greeted by a Modern Auth prompt instead of your typical basic auth prompt:


Which then passes on to your MFA approval flow:


For the record, if you’re still getting this credential prompt:


You’re still using basic auth in your connection and are going to run into the “Access Denied” error.

So, there you go – the problem is not with your account, but how you’re connecting to the Exchange Online Shell. Using one of these two options here should get you up and running, and back into your admin shell. I haven’t yet updated my management scripts to leverage this new module, so I’m still using an account with MFA disabled – but that’s up next!


Uniqueness violation. Property: SourceAnchor

I’ve run into this error in Azure AD Connect (DirSync), and I thought I’d share how I fixed it – as is often the case with sync errors, the solution is not always obvious and requires some digging!

To start us off, this is what the error looks like: attributes associated with this object have values that may already be associated with another object in your local directory services.


Since the error message helpfully points out the duplicate proxy addresses, that seems like a good place to start; however, clearing out the proxy addresses on prem (or changing it if you prefer) didn’t resolve the problem. Instead, it caused my error message to change from duplicate proxy addresses to duplicate UPN values!

Now, under normal circumstances, I’d just delete the synced object in Office 365, and let AAD Connect put things back together – however, in this situation, I was dealing with accounts that were already in production, and I needed to make sure I could match these accounts up with their on-prem counterparts without causing data loss. If you’re just setting things up, and you’ve got cloud accounts that were created by mistake, or even if they’re not in production yet, you can resolve these issues by deleting the offending cloud accounts, and resyncing from your Active Directory.

Looking back in Office 365/Azure AD, I can see my duplicate accounts – now to figure out which one is the rogue, and which one needs to be kept!


There is an excellent TechNet article that gives us a command we can use to generate the immutable ID on premise, like so:

ldifde -f export.txt -r “(Userprincipalname=*)” -l “objectGuid, userPrincipalName”

(hint: the objectGuid that is output by the command above is your ImmutableID in Office 365)

Using PowerShell, we can look for the account matching that Immutable ID, like so:


Confirmed that this is NOT the account that has a mailbox attached:


Checked again, just to be sure:


Tried changing Immutable ID to null – no problems there:

Set-MsolUser -UserPrincipalName account@domain.onmicrosoft.com -ImmutableId “$null”

The meeting rooms did not have an immutable ID, but adding one would give me the dreaded uniqueness violation error


Now that we know which account is which, go ahead and delete the duplicate account, and remove it from the Recycle Bin. Once the duplicate account is gone, I was able to update the Immutable ID on the production account, so that the DirSync could perform a hard match the next time it ran.

It’s possible that you might run into the issue reported here, and be unable to remove the object in Azure AD, due to it now being a lonely orphan – to get past this hurdle, you’ll need to disable DirSync on your tenant before you can clear out the objects.

Disable DirSync using the following command:

Set-MsolDirSyncEnabled -EnableDirSync $false

Note that you’ll need to wait a while (MS says up to 72 hours – it can happen quicker, but it can definitely take a while, so plan to do this in an outage window, or over the weekend, when you can expect little or no changes to be taking place in your AD).

You can check the progress in PowerShell, which always seems to be quicker than the admin portal, by using

the following commands:

(Get-MSOLCompanyInformation).DirectorySynchronizationEnabled

This one gives you a True or False – obviously we’re looking for it to be false before we proceed.

(Get-MSOLCompanyInformation).DirectorySynchronizationStatus

This command will either be PendingDisabled, Enabled, or Disabled. Once DirSync has been disabled, you should be able to delete the offending account, update your immutable ID on the account that you need to keep, and then turn DirSync back on again.

Once this was done, my accounts synced up again, and I was back in business… hope this helps!

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!