Master & Cmd-R

MigrationPermanentException: Cannot find a recipient that has a mailbox GUID

Ran into the following error while attempting to offboard a mailbox (migrate it back on prem from Exchange Online):

MigrationPermanentException: Cannot find a recipient that has mailbox GUID ‘xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx’


This error is usually caused when a mailbox is created directly in the cloud (New – Office 365 Mailbox in Exchange console on prem). The Exchange mailbox GUID doesn’t actually get written back on-prem in this case, so trying to offboard a user results in this error. You can confirm this by connecting to your Exchange Shell on premises and do a Get-RemoteMailbox username | FL ExchangeGUID.


To fix this problem, connect to Exchange Online and find the GUID that’s missing:


Then simply take that GUID and write it back to your on prem remote mailbox object:


Force a DirSync, and all is well with the world!

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!

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 https://manage.windowsazure.com, 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 (manage.windowsazure.com, and account.azure.com).

Instead of going through all that mess, and signing up for an Azure trial you don’t need, simply navigate to https://portal.azure.com, 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: https://aad.portal.azure.com… Shiny!!

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!


Understanding Office 365 ProPlus Servicing

How do updates work in this new paradigm?

In my recent experience with deploying Office 365 Pro Plus, the methodology for deploying updates is still somewhat mystifying for most administrators – diagrams like this one don’t really help us to understand exactly how we want to (or should) apply updates:


I mean, in theory it explains it, but in my experience it’s just gets more confusing trying to understand which updates should be applied, when they should be applied, and how they should be applied.

Let’s break it down:

  1. Individual updates are no longer available for Office 365 Pro Plus – this means you cannot use Windows Updates, WSUS, or SCCM to apply updates the way you used to in the past. (source)
  2. Every month a new build is released – this means that you now update from one build to the next, not applying updates based off the build you installed 6 months ago.
  3. Update Channels – here is where find things get the muddiest… partially, I believe, because Microsoft decided to use a similar yet different naming scheme for Windows 10 update / servicing channels.
  4. Each build is in mainstream support for 1 year – this is as long as you can defer your updates / builds before needing to upgrade to remain supportable and current.

Channels, how do they work?

Let’s talk about what these channels are and what they mean to you as you try to figure out how you’re going to manage Office Pro Plus going forward. First off – bookmark this site, and keep an eye on it to know what Channel, Version, Build, and Release Date is current: https://technet.microsoft.com/en-us/library/mt592918.aspx


This is a screenshot of the most recent update (January 2017) – but check the site for the most recent version.

Here’s how the channels break down:

  1. Current Channel (CC) – this is the channel you’ll be on by default if you log into the portal and click the helpful button that wants you to install Office Pro Plus. The defaults for this channel are to receive a new build from Microsoft on a monthly basis, automatically. You can still control where these updates come from if you want to (more on that later), but this is the channel for early adopters, small companies that like being on the cutting edge, and are willing to put up with frequent changes.
  2. First Release for Deferred Channel (FRfDC) – think about this as being your pilot / testing channel. If you are not just sticking with the Current Channel for your business (and most aren’t), the First Release for Deferred channel will be your power users, IT teams, and whomever you’ve identified as being a good tester in your organization.
  3. Deferred Channel (DC) – this is where most businesses are going to put their users, and this is indeed a good idea. The deferred channel has a nice steady pace of updates (every four months), and these updates will have gone through all the testing of Current Channel users, then First Release for Deferred users before they finally make their way down to the Deferred Channel users. This means that you have about 8 months of folks testing new updates along those various channels before you push them out to your users, allowing for a much smoother update process, with much less chances of changes breaking things in your org.

Basically, the update flow looks like this – using today’s Deferred Release (Version 1605) as a reference:

  • June 6th, 2016: Version 1605 was released to the Current Channel (CC)
    • The current Channel continues to get new builds on a monthly basis
  • June 14th, 2016: FRfDC gets the first Version 1605 build
    • The FRfDC then gets monthly builds of version 1605 until October 11th, when Version 1609 is released to both the CC and the FRfDC.

Throughout these four months, the Current Channel has received Versions 1606, 1607, 1608, and 1609 with various iterations of builds throughout. Every quarter, all these updates get rolled into a single release and pushed out to both channels, and then CC starts to iterate again for another quarter.

  • January 10th, 2017: Version 1605 is now released to the Deferred Channel (DC)CC is already on Version 1611, and FRfDC has started using Version 1609

The big takeaway here is that if you stick with the DC for your broader user base, you’ll be deploying updates that were first released around 8 months ago – giving lots of time for these updates to be tested, bugs reported and squashed, and feedback given to Microsoft on features and changes. This channel gives you the safest, slowest update path possible, while still ensuring that your Office installations are being kept up to date.

Don’t forget that security updates are still being applied monthly, so it’s not like your 8 months behind on security, just on features and changes.

All good? Let’s move on to the how of things…

How do I actually manage this?

Glad you asked! One of the biggest changes that admins often miss is that Office Updates no longer roll out with Windows Updates. This means Windows Update, WSUS, and SCCM cannot be used to update and manage Office the way they used to.

Instead,

There are three ways that admins can apply updates for Office 365 ProPlus:

  • Automatically from the Internet
    • This is the default setting for Office 365 ProPlus
    • Monthly builds / updates are installed automatically
    • No additional user or administrative input is required
    • Can be used for updates even if the Office Deployment Tool is used to install Office
    • Least amount of administrative effort, least amount of control

As I mentioned above, if you’re already agile enough to be on the Current Channel, you’ll probably want to just leave these settings to default, and let users apply updates automatically from Microsoft servers as new builds are pushed out. If this is you, congratulations! You’re helping to test updates and make sure they’re all good before they get released to the masses in the DC 😉

  • Automatically from an on-premises location
    • More admin effort, more control
    • Use the ODT to download the monthly build to a network share
    • Computers are configured through the ODT or GPO to install updates automatically from that share
    • Group Policy and the ODT specify a network location for updates

This option is where you go if you want to still keep people updating automatically, but you want a little more control over the version they’re getting – the TechNet links below layout the process of how you can automate this if desired, and basically bridges the gap between convenience and control in your environment. This option will also allow you to maintain a steady cadence of updates, as you only need to configure your installs to update from a specific location, and then download whichever version you want into that updates folder.

  • By installing an updated version of Office 365 ProPlus
    • Most admin control, greatest amount of effort required
    • Use the ODT to download and install the latest / required version
    • This option reinstalls ProPlus, but only new or changed files are downloaded to the user’s computer
    • Using this option disables automatic updates

This final option gives you the greatest amount of fine grained control – Office Updates are disabled entirely, and users will only get the versions that you deploy to them. Use this methodology if rigid change control is required, or if you want to make sure that everyone (except your pilot/test users of course) is holding to the same version, and helps to keep your environment standardized.

More information (and full details) available here: https://technet.microsoft.com/en-us/library/dn761707.aspx

It’s important to note that updates do not require local admin rights as they run under the system context, so if you’re trying to prevent users from running updates, just removing local admin privileges won’t stop these updates from applying. This also means that it’s a lot easier to manage these updates going forward, as you won’t have to go around type in an admin password in order for users to get their updates.

Given the nature of these channels (multiple release stages), it’s important that you implement a solid testing methodology in your environment. Designate a number of flexible and competent users, and put them on the FRfDC so that you know what updates are coming in your environment before they get pushed out to mission critical systems. This will allow you to defer updates if you need more testing / development time, or give you more time to prep your users for feature changes that will impact their day to day life. Once you’re comfortable that the updates are not going to cause problems in your environment, move them into the Deferred Channel and let them be released to the rest of your users.

Here’s some additional reading resources for extra credit:

Accessing mail options on a resource mailbox

I ran into an issue recently where I needed to access the mail options on a resource mailbox, which of course has no license, and can’t be logged into directly. After a bit of looking around, I found I was able to access the mail options directly using the following URL: https://outlook.office.com/owa/mailbox@domain.com/?path=/options/mail

Just replace mailbox@domain.com with the actual mailbox you need to manage, and you’re good to go! You can bookmark that link for easy access to the options, and save yourself several extra clicks.

To access these options manually on a mailbox, open OWA, and then click on your account name in the top right corner, and then select Open another mailbox…


Type in the name of the mailbox you want to open, and click on it in the search results, then click Open:


Once the mailbox opens, click on the cog, and select mail options. Or, just take the address above, and use the name of the mailbox you need to access, and get at it in one click! 😉

Make sure, of course, that you have Full Access permissions assigned to your account, otherwise you won’t be able to open the mailbox. Just a quick little tip, but I figure any little trick that makes mailbox management easier is worth sharing!

MVP 2017!

I’m so excited to open my email on New Year’s Day to find this email from Microsoft:


It almost sounds cliché to say that I’m humbled and honored, but it is honestly such an amazing feeling to be invited to be a part of this awesome community of passionate, incredibly smart people. I love being able to help people, and whenever I get a comment from someone who has found one of my blog posts helpful, it makes me want to keep going and do more – I’ve been on the receiving end of that generous giving from others in the MVP and tech community, and it’s great being able to give back as well.

Here’s to an awesome 2017 in the cloud!

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!

OneDrive: Deleted user retention

As part of ongoing user management, this question comes up from time to time:

What happens to a user’s OneDrive library when their account is deleted?

The short answer is that user data is retained for 60 days after their account is deleted, and then irretrievable after that. During that time, the data can be retrieved by the user’s manager, or by a secondary site collection admin. It’s important to note that the OneDrive cleanup process ONLY happens on user account deletion, not disabling the account or removing their license(s).

Here’s the process:

  1. By default, when a user account is deleted ownership of their OneDrive library is assigned to their manager. For this to work, however, several things have to be in place beforehand.

     a. The manager field needs to be populated in AD
     b. Access Delegation needs to be enabled in SharePoint Online, as indicated in the following screenshot. Note that this is a global setting that will be applied for all users, and is recommended as a best practice.



     c. A secondary owner or site collection admin can be assigned on this page as well, allowing for further control or access to be provided for a deleted user.
  2. Once a user profile has been deleted, a timer job runs which marks the account for deletion in AD, and flags the OneDrive library for deletion in 30 days. If the Manager field is populated, they will receive a notification at this point that the site will be deleted in 30 days, so they can go and retrieve any data and save it elsewhere. If the Manager field isn’t populated, the notification will go to the Secondary Owner, or Secondary Site Collection Administrator. If none of these 3 fields is filled out, the workflow will continue below, but no email notifications will be sent.
  3. After 23 days, the Manager / Secondary Owner / Secondary Site Collection Admin will receive a final notification that the library will be deleted in 7 days.
  4. 30 days after the user has been deleted from AD, their OneDrive library is deleted, and moved to the Site Collection Recycle Bin.
  5. After another 30 days (60 days from user deletion in AD), the OneDrive library is cleared from the Site Collection Recycle Bin.

More info: https://support.microsoft.com/en-us/kb/3042522

What about if the account is disabled in AD?

 If a user has been disabled in AD (but not deleted), the account status in Office 365 changes to Blocked, and the user’s OneDrive site collection is not accessible until an administrator takes ownership of it.

In the case of my test account, the Manager property wasn’t set, neither was the secondary site collection owner/administrator – if either of those properties were in place, the library would have been available to those people. Since those attributes weren’t set, it required taking ownership manually as a SharePoint admin, at which point I could access the library.

Bottom line: the user’s OneDrive library deletion cycle starts when the account is deleted, not when it is disabled. This is a fairly large distinction, as I’ve seen many environments where user accounts are disabled, and sometimes left in that state for years without clearing them out. However, you need to be careful with this practice – if you disable the user account and move it into a Disabled Users OU (for instance) that is excluded in the Azure AD Sync, this WILL delete the user account in Azure AD and trigger the start of the deletion process.


Block Yammer Access in Office 365

Since April 2016, Microsoft deprecated Yammer Single Sign On capabilities – up until this point, if you wanted to block users from accessing Yammer, you needed to configure a relying party trust in ADFS / SSO, and block all users who are not members of a specific group. While this feature worked well (in my experience), the updated process that Microsoft implemented is way better, and much easier to implement.

Now, instead of configuring Single Sign On, you only need to do three simple steps to prevent users from accessing Yammer:

  1. Enforce Office 365 Identity in Yammer; (more info)
  2. Block Office 365 users without Yammer licenses; and,
  3. Remove the user’s Yammer license in Office 365. (more info)

The first two of these steps takes less than 5 minutes to complete, but it has an immediate and potentially large impact, so you need to make sure that these changes are planned and the impact accounted for before you do this. If you’re users are not using Yammer yet, all the better – click away!

Enabling Office 365 Identities in Yammer:

Log into your Yammer network, and select Network Admin – Security Settings. You need to be a network admin in order to even see these settings, and if you’re a Global Admin in Office 365, you’ll also be a Network Admin in Yammer, so you should be good to go.

On the Security Settings page, you’ll see a section for Enforcing Office 365 Identity in Yammer. If you’ve never selected either of these fields before, here’s what to expect:

  1. When you enforce Office 365 Identities in Yammer, anyone who logged into Yammer with a Yammer account (or created one on their own), will no longer be able to log into your network in Yammer. This is a great way to start consolidating identities, as Yammer used to allow a combination of both Yammer and Office 365 accounts, and a user could have either, or both – quite messy!

Once you select the option to Enforce Office 365 Identities, you’ll be able to immediately log all users out, and force them to sign back in, this time with their Office 365 accounts. This is useful if you want to implement an immediate change, but keep in mind that users will be logged out immediately, so communicate this change, or you could have some unhappy users on your hands.

  1. Once you are enforcing Office 365 Identities, you can go ahead and click the option to block Office 365 users without Yammer licenses. Once again, you’ll have the option to log all users out of Yammer, so plan your changes and communication accordingly. Note that you can enable both of these options at the same time – you don’t need to wait in between selecting the different options.


If you want to go for a softer approach, leave the option unchecked to log out all current users, and these users will be able to continue to use Yammer until the next time they try to log in, at which point, they will require a valid Office 365 account, and a Yammer license assigned to their account.


You still need to click Save before these setting take effect, so you have one last chance to back out if you’re not sure if you’re ready to kick everyone out of Yammer or not!


  1. Now that you’ve got your identities consolidated to Office 365, and are blocking Office 365 users without Yammer licenses, simply log back in to Office 365, deselect the Yammer Enterprise option, and click Save.


Now when a user without a Yammer license attempts to connect to Yammer by logging in at http://yammer.com, this is what they’ll see:


Note that if you go about this from the opposite direction, removing a user’s license won’t prevent them from accessing Yammer if you haven’t done the first two options. Once you’ve got steps 1 and 2 completed, they will be immediately blocked from logging into Yammer, and will see the error message above.

Remove Yammer licenses globally through PowerShell:

Microsoft provides a script for removing a single user’s Yammer license through PowerShell, but here’s how you would achieve this if you wanted to disable Yammer for all users:

# Connect to the MSOL Service
$credential = Get-Credential
Connect-MsolService -Credential $credential
 
# Gather all licensed users into a variable
$yammerUsers = Get-MsolUser -All | Where {$_.IsLicensed -eq $true}
 
foreach ($y in $yammerUsers){
$LicenseDetails = (Get-MsolUser -UserPrincipalName $Y.UserPrincipalName).Licenses
 
foreach ($License in $LicenseDetails) {
 
 $DisabledOptions = @()
 $License.ServiceStatus | ForEach {
 
 If ($_.ProvisioningStatus -eq "Disabled" -or `
 $_.ServicePlan.ServiceName -like "*YAMMER*") {
 $DisabledOptions += "$($_.ServicePlan.ServiceName)" 
 
    } 
 
 }
 
 $LicenseOptions = New-MsolLicenseOptions -AccountSkuId $License.AccountSkuId -DisabledPlans $DisabledOptions
 Set-MsolUserLicense -UserPrincipalName $y.UserPrincipalName -LicenseOptions $LicenseOptions
 
    }
 } 

Please note that this script will remove all Yammer licenses globally, and no-one will be able to log into Yammer until you have gone back and re-enabled their Yammer Enterprise license. The good news is that this change doesn’t delete anything in Yammer, and once a license has been reassigned in Office 365, users can log back in as normal. As always, scripts are provided without warranty or guarantee – be smart and test scripts before releasing them in the wild and making global changes to your tenant!