Office 365: Script to export to CSV mailboxes without the onmicrosoft.com smtp address

Just recently and when helping drive a Google Suite to Office 365 e-mail migration, I was faced with a problem that affected my mail routing capabilities between the 2 systems: Not all mailboxes in Office 365 had the @tenantid.onmicrosoft.com domain.

Now that can be a problem, specifically because in many coexistence scenarios (including the one I mentioned above), that “tenant.onmicrosoft.com” or the “tenant.mail.onmicrosoft.com” address is used as the forwarding address on the e-mail system coexisting with Office 365.

Here are a couple of articles describing cases where the service or mail routing domain were missing:

“Target mailbox doesn’t have an SMTP proxy matching ‘.mail.onmicrosoft.com'” error when you try to move mailboxes to Exchange Online

User@Domain.onmicrosoft.com disappeared

The main problem in this cases is that you can find that some users don’t have that address, as an additional smtp address, the hard way, which basically is getting an NDR on the source system when it tries to forward that email to Office 365. So to be on the safe side, and because this happened to me a few times, I decided to create a script that identifies all users that don’t have an address from a specific email domain.

Some bullet point instructions for the script:

  • you can download the script here
  • The file you downloaded contains 2 scripts: Export-UsersNoOnMicrosoftAddress.ps1 and Log_Functions.ps1. Copy both into the same folder
  • Open a PowerShell window and run .\Export-UsersNoOnMicrosoftAddress.ps1
  • The script will prompt you to enter your Office 365 credentials
  • The script will prompt you for an email domain (i.e tenant.onmicrosoft.com)
  • All users that don’t have an address with that email domain will be exported to a file called UsersNoOnmicrosoftAddress.csv located in the same folder
  • A log file called ExportUsersOnmicrosoft.log is also created in the same folder, where you can check for any errors after running the script

See screenshot below with the output of the script on the console:

UsersNoOnmicrosoft1

Of course that, if you look at the code, you will easily realize that the script can export users that don’t have an address from any domain you chose. That being said use it as you see fit. To me it helped me a lot on detecting the users with the problem described above.

Just a quick note before I finish this post: there are 2 reasons for this script not to fix the problem, adding those addresses:

  1. AD Connect: blocks you from adding the addresses directly in 365, meaning you will need to resolve the problem on premises and force a sync of the new addresses to 365
  2. Email address policies: it’s ultimately the best way of resolving email address problems in bulk, so that’s the route you so use

As always if you have any questions let me know. Enjoy.

Office 365: Some quick notes on the end of support for Dirsync and Azure AD Sync

Earlier this week Microsoft announced the end of support for the legacy Microsoft Dirsync and Microsoft Azure AD Sync tools. Millions of customers out there use one of those two tools, or the new Microsoft Azure AD Connect, to sync their users, groups, passwords, etc, from their On-Premises Active Directory to the Azure AD.

After quite a few name changes, it looks like the Azure AD Connect major version is here to stay, and now it’s time to end support to the two older major versions, and make sure that all of them are updated and replaced with the AD Connect.

If you haven’t done it already, it’s time to read the Microsoft announcement, and to start planning that upgrade.

Now let’s take the key points of the Microsoft announcement:

  • In April 13th 2016 Microsoft announced the deprecation of both Dirsync and Azure AD Sync
  • The end of support for both versions of the sync tool was planned to be April 13th 2017. That date is now official with the announcement this week and in that day the official support to those tools is gone
  • Azure AD will stop accepting connections from both tools in December 31st 2017

The most relevant thing to take into account is that, either you upgrade those instances, or they will stop working by the end of this year.

Now that you are probably more than convinced to update your instance(s) for your customers or your infrastructure, let’s bullet point some thoughts to have into account when planning the upgrade:

  • Make sure you read the official Microsoft document to upgrade Dirsync to Azure AD Connect
  • Or make sure you read the official Microsoft document to upgrade Azure AD Sync to Azure AD Connect
  • You can only do in place upgrade from Azure AD Sync to AD Connect or from an old to a more recent version of AD Connect. In place upgrades from Dirsync are not supported
  • Microsoft describes the migration done with a parallel server, to replace the existing, as “Swing migration”
  • On a standard Dirsync or AD Sync instance, there’s nothing that you need to backup and restore in the new version. The new Azure AD Connect instance will do a fresh full sync after the installation. That full sync will bring all data from the local and the Azure AD. Replacing a Dirsync or an AD Sync instance should not require restoring data
  • The only exception to the above statement is when you have some type of filtering. Filtering can be done at the AD OU, Domain or attribute level. In those cases you need to make sure you replicate the filtering you have in place, into the new instance.
  • To learn more about Dirsync filtering click here.
  • To learn more about AD Sync and AD Connect filtering click here.
  • If you are not doing an in place upgrade, you need to be aware that the “downtime” on your sync instance has impact in creating new account and replicating changes to the existing ones (that includes password changes, if you have password sync enabled)

And that’s it. As simple as that. Start downloading the AD Connect version and it’s upgrade time! 🙂

Let me know if you have questions.

Office 365: Outbound conditional (per source domain) mail flow routing

Imagine this scenario: You have an anti-spam appliance in front of your Office 365 tenant, and you want outbound mail flow from your tenant to go via that appliance, but depending on what the email domain of the sender is. For example you have domainA.com and domainB.com as two vanity domains in Office 365, and you want User1@domainA.com outbound email to go via the mail appliance, but user2@domainB.com outbound email to go direct to the Internet.

The scenario above requires conditional routing, meaning the outbound mail flow path will be different depending on what the email domain of the source user (the sender) is. The example above is just one of several that might lead you to apply such configuration.

Now the important part: How do you configure it? Well, you can do it via PowerShell or via the UI, and to do the configuration you will need the following:

  • A Transport Rule
  • An Outbound Connector

Create the Outbound Connector

The first thing you need to create is the Outbound connector.

Via Exchange Online PowerShell

To create the connector via the PowerShell, connect to Exchange Online and run the following:

New-OutboundConnector -Name “To Internet Direct” -ConnectorType Partner -UseMXRecord $true -IsTransportRuleScoped $true

The command above creates a connector that goes directly to the Internet and it’s scoped to the transport rule we will create next. If you want to create a connector that goes via an appliance run the following:

New-OutboundConnector -Name “To Internet via Appliance” -ConnectorType Partner -UseMXRecord $false -SmartHosts <Appliance IP> -IsTransportRuleScoped $true

Via the Exchange Online Admin Center

Navigate to Mail Flow > Connectors and click “+”

1

Select Office 365 as source and Partner Organization as destination

2

Enter a name and description

3

Select “Only when I have a transport rule set up that redirects messages to this”

4

Select “Use MX Record” or “route email through these smart hosts” depending on if you want the email to go direct or via an appliance/smart host

5

Remove the always use TLS selection, unless the appliance or server your sending the email to is configured to use TLS

6

Confirm the settings and click next

7

Validate the connector and save

Create the transport rule

Once you have the outbound connector created, you can now create the transport rule.

Via Exchange Online PowerShell

To create the transport rule via the PowerShell, connect to Exchange Online and run the following:

New-TransportRule -Name “UseAppliance” -SenderDomain <Source Domain> -SentToScope NotInOrganization -RouteMessageOutboundConnector “To Internet Via Appliance”

The command above creates a transport rule, that uses the “To Internet Via appliance outbound connector, and that applies when the source domain is specific and the destination recipient is outside of the organization (very important setting).

Via the Exchange Online Admin Center

Navigate to Mail Flow > Rules and click “+ Create a New rule”

8

Click on more options

Give the rule a name

In the Conditions select “Apply this rule if..” > The recipient is located > Outside of the Organization

Click in Add Condition

Select “Apply this rule if..” > The Sender > Domain is > Enter the domain name of the source user

In the “Do the Following…” section select “Redirect the message to..” > The following connector. Select the outbound connector from the drop down list

Make sure the enforce rule option is selected

9

Now that you have both the transport rule and the outbound connector created, lets test and see if it’s being applied.

Test the routing

The first thing you should do is simple: Send an outbound email from the user that should have conditional routing applied to his domain. Make sure the email is to an external recipient.

Once you sent the email, in the Exchange Admin Center go to Mail flow > Message trace, select the sender you want to trace the message for and click on “search”

10

Note: It might take a few minutes after you sent the message before it shows in the message trace

Once you can see the message there, double click on it to see the details

11

In the details you can see if the transport rule was applied and the transport rule name

13

You will also be able to see if the message was delivered, is pending or has failed. This is key for you to troubleshoot the mail flow and see if the correct rules are applied and the correct outbound connectors are being used.

And that’s it. Job done! As always if you have questions let me know.

The complete journey from Google to Exchange Online with Free/Busy rich coexistence

When questioned by partners, on what is the best approach to plan and execute a move of a customer’s email system, from G-Suite to Exchange Online in Office 365, the first questions that I ask are:

How many users do you have to migrate?

Are you going to do a migration in batches (Staged) or cut over all users at the same time?

Usually when there’s a large number of users, the migration in batches is the preferred option. At that point you should consider two things:

  • How can I automate the mail flow changes
  • How can I have free/busy coexistence between G-Suite and Office 365

The answer to both questions above is simple: You can automate the mail flow and have free/busy coexistence if you use BitTitan MigrationWiz to move the mailboxes, and the BitTitan automation processes to help you with the changes you need to do per migration batch.

In the past I wrote an article on how to configure mail flow coexistence between Google Apps and Office 365, that can help you understand the configurations you need to do.

BitTitan also has a very good article on how you can automate the mail flow changes, on a mail migration from Google to Office 365, as well as the entire migration guide.

But I want to focus this article more on the free/busy rich coexistence, between Google and Office 365, the value that it brings to your migration and your customer, a technical overview on how it works, and of course how you can configure it.

What is the value on having free/busy coexistence between G-Suite mail and Office 365 Exchange online

User experience. It’s all about the user experience!!! If you are moving a 20k users company from Google to Office 365, you often get questioned about what the migration journey will mean for the end users, in terms of end user experience. When you provide your customer and their end users the ability to have not only mail flow coexistence (that one is mandatory of course) but also calendar free/busy lookup capabilities, you’re giving them the best experience they can have.

I have also seen more and more companies using the BitTitan Google coexistence tool for permanent free/busy coexistence between G-Suite and Exchange Online, so don’t think about it just like an add-on to a migration project, it can be much more than that.

How can I achieve that with BitTitan

Currently BitTitan will allow you to use the Google coexistence tool for free during 3 months, if you use BitTitan MigrationWiz to move all of the mailboxes. If you want coexistence for more than 3 months, or if you’re not using MigrationWiz, you will be quoted a price per user per month.

Note: The statement above was true when I wrote this article. There no guarantee that will be true when you read it so please contNact BitTitan for more information.

Why do I need a free/busy coexistence tool between Google and Office 365

The answer to this is short and simple: the Google Calendar Interop, which is the tool that you need to configure on your Google tenant to query free/busy from Exchange mail systems, cannot query free/busy information, from an Exchange Online mailbox, via the Exchange Web Services API and the Availability Service. Instead it will try and query free/busy information from an Exchange Public folder. The problem is that the newer versions of Exchange don’t support that method anymore.

So in essence, because the Google Calendar Interop hasn’t evolved to match the changes that the Microsoft Exchange product group implemented in the way the free/busy is queried, specifically on the transition from Exchange 2010 to Exchange 2013, you need a translation tool between Google and Office 365. That translation tool is the BitTitan Google Coexistence tool.

How do I configure the BitTitan Google coexistence tool

The answer is, you don’t. You configure the Google Calendar Interop and Exchange Online by creating an Organization Relationship, both to point to the BitTitan Coexistence service, and you also create a MigrationWiz project in the BitTitan portal, so that you can obtain your authentication token from the BitTitan Support (support@bittitan.com). See here the coexistence setup guide.

This is how the Google calendar interop should look like:

1

And to configure the calendar interop:

  1. login to https://admin.google.com
  2. Go to Apps > G Suite > Calendar > Calendar Interop Management
  3. Enter all the information as per the coexistence setup guide

This is how the Exchange Online Organization Relationship should look like:

2

And to configure the Organization Relationship:

  1. Download the Coexistence script from the BitTitan setup guide
  2. Add the details to the script as per instructions on the setup guide
  3. Open an Exchange Online PowerShell session
  4. run the script
  5. Verify if the Organization Relationship was properly created by running: Get-OrganizationRelationship |fl

Do I need contacts in each organization for the free/busy to work

No, you don’t need a contact in Google for each user from Exchange Online that you want to query the free/busy, nor you need them in Office 365 for each Google user. You should have contacts in both sides, but to make sure you have a unified Global Address list.

To be clear on this:

  • Peter@domain.com is a Google mailbox
  • John@domain.com is an Office 365 mailbox
  • You don’t need to create peter@domain.com as an Office 365 mail contact
  • You don’t need to create john@domain.com as a Google mail contact

But again.. you should.. having a unified GAL is usually mandatory and for sure highly recommended.

How do users query the free/busy information

As they do for any other internal user. They open their calendar app and enter the email address of the user on the other system or search for his contact created on the GAL if it exists.

To wrap this up, and please stay tuned for more blog post on this subject coming soon, the rich coexistence (mail flow and free busy) experience, when you’re migrating your customer from Google to Office 365, is very important and also very easy to achieve.

If you have any questions please feel free to reach out. I can help you understand it better as well as configure it.

As always I hope this post was helpful.

PS- The BitTitan coexistence tool also works between Google and Exchange 2010 Sp2+ on premises.

 

 

 

 

Understanding the admin authentication options when using the EWS API in your migration project

One of the major concerns of the consultant or the project manager, on a migration project, is how long will it take to migrate the mailboxes, and what timelines can they define as reasonable for the migration (or the migration batch) to be finished.

Having that in mind, the conversation around it needs to focus on two major factors:

  • What authentication method should we use
  • How can we minimize (or avoid) throttling

So let’s start by talking about the authentication method.

What are the available authentication methods?

Bittitan MigrationWiz, which of course leverages the Exchange Web Services (EWS) as the API to migrate to and from Exchange 2010+, allows you to use two type of admin authentication methods:

  • Delegation
  • Impersonation

Note: MigrationWiz also allows non admin authentication methods, which we will not discuss on this blog post.

What is delegation and how do I configure it?

Delegation is the authentication method in which the entire migration will be done from the calling account (admin account), that needs to have full access to all of the mailboxes that are being migrated. The requirements for delegation are:

  • admin account needs to be mailbox enabled
  • full access is required to all of the mailboxes being migrated (explicit permissions)
  • a throttling policy should be created and associated with the admin account

In the Bittitan community website you will be able to find instructions on how to configure delegation on the source and target Exchange systems. You can also find there how to create the throttling policy.

By default the MigrationWiz project will try and use delegation, so there’s no other change needed.

What is impersonation and how do I configure it?

Impersonation is the authentication method in which the migration will be done on behalf of the user account, that is being impersonated by the calling account (admin account). For this to happen the admin account needs to be granted rights to impersonate the user accounts being migrated. the requirements for impersonation are:

  • the admin account does not need a mailbox
  • impersonation rights need to be granted to the admin account, over all of the users being migrated
  • a throttling policy is not required but highly recommended

In the Bittitan community website, you will also find instructions on how to configure impersonation on the source and target Exchange systems. The instructions to create the throttling policy are the same you can find on the section above.

The default behavior from MigrationWiz is not to use impersonation, so please make sure you follow the MigrationWiz steps of the article above, to configure impersonation at the project level.

Should I use Delegation or Impersonation?

Now that I described what is Delegation and what is Impersonation, let’s discuss which one should you use for each scenario.

In my professional opinion, that I will detail below and explain why, this is what you should do:

  • If the Exchange system is Exchange Online (Office 365) use Impersonation
  • If the Exchange system is Hosted Exchange (online but not in Office 365) use Delegation
  • If the Exchange system is on premises use Delegation

So now let’s break it down per system.

Exchange Online (Office 365)

The main reason that you should use Impersonation when authenticating against Exchange Online is simple: You cannot create a throttling policy in Office 365 and impersonation is less subject to throttling than delegation. 

I don’t think I need to explain why you can’t create a throttling policy in Office 365, but why is impersonation less subject to throttling? Well the explanation is logic: The subscriptions will be charged against the throttling budget of the target mailbox and not the calling account (admin account), which in other words means that the admin account is doing the migration impersonating each target account and the throttling is being charged to the target accounts, making the limits much more flexible and the migration faster.

Another good thing about Exchange Online is that when you set the impersonation rights, you are of course setting them within the boundaries of your tenant, which is not necessarily true for hosted Exchange systems, as you’ll see below.

Hosted Exchange (not in Office 365)

Now when we look at a hosted Exchange and what admin authentication methods we can have, the main thing you need to keep in mind is that, we will have what the Hoster is willing to configure. And what might that be? Short answer will be Delegation.

Don’t get me wrong, if you manage to get a Hoster (or if you are part of a Hoster Exchange management team and you’re also driving the migration) to either create a throttling policy or configure impersonation associated with a management scope, then what I recommend is:

  1. If you can create a throttling policy then use Delegation and associate that throttling policy to the admin account
  2. If you can’t create a throttling policy but you can enable impersonation with a scope (explanation below) than enable and use Impersonation
  3. If none of the above is possible, then use Delegation

Note: when you set impersonation, if you don’t use a management scope, that will allow the admin account to impersonate any account on that hosted Exchange. That might (and should) be considered a security breach by the Hoster and therefore not possible to configure. Although possible, many Hosters might not be willing to configure impersonation with a management scope, or configure impersonation at all.

On Premises Exchange

Finally when the system is on premises Exchange, you will be able to do all necessary tasks, so why use delegation?

To be able to reach maximum speeds you will still have to create a throttling policy (if you can), so between impersonating and using delegation I do think that delegation and a throttling policy is the best way to go.

Remember when I said “Impersonation is the authentication method in which the migration will be done on behalf of the user account, that is being impersonated by the calling account (admin account).”? Well that’s not 100% true in all cases. Depending on your Exchange version, the subscription might be charged to the calling account, which in essence makes impersonation as effective as delegation in terms of throttling. See the table below:

Exchange version EWSMaxSubscriptions throttling budget accounting
Exchange Online Charged against the target mailbox.
Exchange 2013 Charged against the target mailbox.
Exchange 2010 SP3 Charged against the target mailbox.
Exchange 2010 SP2 Charged against the calling account. Starting with Exchange 2010 SP2 RU4, the budget is charged against the target mailbox.
Exchange 2010 SP1 Charged against the calling account.
Exchange 2010 Charged against the calling account.

Source: EWS throttling in Exchange

From the above table you will see that if you have an Exchange system older than Exchange 2010 SP2 RU4, impersonation and delegation will have the same impact from the throttling perspective. We know that Exchange Online does have a version newer than the one just mentioned, but that is not necessarily true for Hosted Exchange or Exchange On Premises, so have that in mind when planning the authentication methods.

So let me outline the reasons that should make you choose delegation when migrating from an on premises Exchange:

  • the speed of the migration will be highly dependent on the throttling policy, that you can and should create, as well as monitor the Exchange performance during the migration
  • Implementing delegation is easier, specially in cases where you want the admin account to just have rights over a subset of the mailboxes. It’s much easier to just give full access to some mailboxes when compared to give impersonation rights to just some users
  • the way throttling reacts when using impersonation and delegation is different. In my opinion when using impersonation you’re more likely face ErrorServerBusy errors (if you go over the limit of concurrent migrations) and that causes normally more migrations to fail. When using delegation the failures are more likely to happen on the accounts that caused the admin account to over the maximum subscriptions allowed

I know that the explanation above might be a little confusing, specially the last bullet point, but I do highly recommend that you read the EWS throttling in Exchange article, and if you have another idea on what method to use feel free to share it.

I do think that impersonation makes sense only on those scenarios where you cannot fully implement proper delegation, with throttling policies and processes defined to monitor the Exchange server resources during the migration window.

Some useful articles around this subject

The importance of EWS impersonation while using an application account: you will can read the author outline how impersonation is better from an application perspective, and delegation is more oriented towards user access. I also mentions that user access can be controlled and revoked by the end user, which can be true. But on a migration project MigrationWiz will use user access to get into the mailbox and move the data to a destination mailbox, which is exactly what delegation provides you. He also outlines how less complex and global the impersonation setting can be, which is true, but on a project when you only need to migrate a subset of the mailboxes, and where you don’t want to give global access, impersonation will be significantly more complex. In essence this article is a good read that outlines the positives of impersonation and why it’s a good option for application level access and not user level access.

Impersonation and EWS in Exchange: This is an excellent article and a must read, that details how application level impersonation works in Exchange.

So what is the bottom line? At the end of the day it’s still your decision of whether to use delegation or impersonation. I’d say that for some scenarios like Office 365, the decision is a no-brainer (impersonation of course), and in some other scenarios it will depend on what can you configure and what is the simpler and more effective configuration.

Like I stated above I am always more inclined to decide for delegation against Exchange on premises and hosted Exchange, and impersonation against Office 365.

As always I hope this article is helpful, and feel free to share your thoughts.

Understand and script the Get-MailboxFolderStatistics cmdlet

This blog post is going to give you some insight on how you can script the Get-MailboxFolderStatistics cmdlet, but also how to understand it’s output, as well as how is it important to plan a mailbox migration project.

Why are the mailbox folder statistics important to plan a migration project?

That is indeed the first thing you need to consider: Why do I need those statistics? To better answer that let me start by showing you an output of the command.

1

What you see above is the output of a mailbox, where I filtered the Folder Path, the number of items in the folder and sub folders, as well as the size of each folder. So let me bullet point why is this important for a migration project planning:

  • It will give you item counts per user and per item type (Mail, calendar, contacts). Those numbers are important, specially if extremely large, to estimate migration timelines when using the Bittitan MigrationWiz mailbox migration.
  • It will show you the size of every folder as well as the entire mailbox size. This is important to identify which folders are larger on a very big mailbox. I’ve seen examples of some of those folder being considered irrelevant for a migration (i.e deleted items, sent items) and with a flexible tool like the Bittitan MigrationWiz you can filter them out.
  • It will show you not only the folders visible to the end user, but also the recoverable deleted items folder. This might be very important in scenarios where you have in place hold active. It will give you the exact estimate of how many items are under in place hold on the recoverable items, that you will eventually need to move to the same folder on the destination mailbox.

So in summary, and giving a quick example, if you’re moving 1000 mailbox from Exchange Online tenantA to tenantB, you should use the Bittitan MigrationWiz tool, that will be not only fast but also flexible on what you can include and exclude in the migration, leveraging the Exchange Web Services API. To do that the insight of what’s in the mailbox is fundamental to plan the entire migration. You can plan the timelines and how long it will take, what type of licensing you will need at the destination tenant and many other important variables for the project.

How can I filter the output per item type?

When running the cmdlet you need to use the “-FolderScope” parameter to filter the output per item type. That parameter allows you to enter many different folder scope types, the most common being:

  • All
  • Calendar
  • Contacts
  • RSSSubscriptions
  • RecoverableItems

See the entire list in the official Technet article of the Get-MailboxFolderStatistics cmdlet.

Some cmdlet examples

See below some examples on how to obtain specific data:

Get total number of items in the mailbox (does not include recoverable deleted items):

Get-MailboxFolderStatistics user@domain.com | Where-Object {$_.foldertype -eq ‘root’} |ft folderpath, itemsinfolderandsubfolders, folderandsubfoldersize

2

Get total number of contacts in the mailbox:

Get-MailboxFolderStatistics user@domain.com -FolderScope Contacts |ft folderpath, items*, folderandsubfoldersize

3

Note: the above will work for calendar items if you change the folder scope from “Contacts” to “Calendar”

Get total number of items in the Recoverable deleted items folders:

Get-MailboxFolderStatistics user@domain.com| where {$_.FolderType -eq ‘RecoverableItemsRoot’}|ft folderpath, itemsinfolderandsubfolders, folderandsubfoldersize

4

And finally… the script that exports all of this to a csv:

Now that we discussed how important it is to get the statistics, and I gave you same examples on how to run some one line commands to get some insight on the mailbox, I will share with you a script that was done by me and my colleague and friend Alberto Nunes.

Below are the details of what the script does:

  • The script will run the statistics against a list of users that needs to be specified on a file called users.csv (see csv format below). The file needs to be on the same folder as the script.
  • The script runs Exchange PowerShell commands, so make sure you’re connected to the Exchange PowerShell (online or on premises)
  • The script will export the results to a file statistics.csv
  • The script will ask you for a source or destination parameter. The statistics for the recoverable deleted items folders will only be included if you select Destination.
  • This script is provided as is and there’s no guarantee that it will work in your environment.

The Users.csv file:

5

Note: Make sure you name the column A “EmailAddress”

The Script:

Copy the text below (in red) to a notepad. Save it as .ps1 and run it from a PowerShell session connected to Exchange.

#Start Script
Param
(
[Parameter(Position=0,Mandatory = $true)][ValidateSet(‘Source’,’Destination’,’MigrationWiz’)][String]$Location,
[Parameter(Mandatory = $false)][String]$Folder = “.”,
[Parameter(Mandatory = $false)][String]$UsersCSV = “Users.csv”,
[Parameter(Mandatory = $false)][String]$OutputCSV = “Statistics.csv”
)
Get-Date
$ErrorActionPreference = “SilentlyContinue”
$SourceFile = $Folder + “\” + $UsersCSV
$OutputFile = $Folder + “\” + $OutputCSV
$mailboxes = Import-Csv -Path “$SourceFile”
$CSV = @()
Foreach ($mailbox in $mailboxes)
{
Write-Host “Working on $($mailbox.EmailAddress)”

$AllStats = Get-MailboxFolderStatistics $($mailbox.EmailAddress)| Where-Object {$_.foldertype -eq ‘root’}

$ContactStats = Get-MailboxFolderStatistics $($mailbox.EmailAddress) -FolderScope Contacts
$TotalContactsItems = ($ContactStats | select -expand ItemsInFolder |Measure-Object -Sum).Sum

$CalendarStats = Get-MailboxFolderStatistics $($mailbox.EmailAddress) -FolderScope Calendar
$TotalCalendarItems = ($CalendarStats | select -expand ItemsInFolder |Measure-Object -Sum).Sum

$RSSFeeds = Get-MailboxFolderStatistics $($mailbox.EmailAddress) -FolderScope RssSubscriptions -ErrorAction SilentlyContinue
If ($RSSFeeds)
{
$TotalRSSFeeds = ($RSSFeeds | select -expand ItemsInFolder | Measure-Object -Sum).Sum
}
Else
{
$TotalRSSFeeds = 0
}

# In the source, we don’t need to know the Size of the RecovableItems
If ($Location -eq “Destination”)
{
$recoverableItems = Get-MailboxFolderStatistics $($mailbox.EmailAddress)| where {$_.FolderType -eq ‘RecoverableItemsRoot’}
[double]$recoverableSize = $recoverableItems.FolderAndSubfolderSize.TrimEnd(” bytes)”).Split(“(“)[1].replace(‘,’,”) |%{“{0:N2}” -f ($_ /1mb)}
}

$TotalMailItems = $AllStats.ItemsInFolderAndSubfolders – $TotalContactsItems – $TotalCalendarItems – $TotalRSSFeeds

$ISSize = $AllStats.FolderAndSubfolderSize.tostring()
[double]$ISSize =$ISSize.TrimEnd(” bytes)”).Split(“(“)[1].replace(‘,’,”) |%{“{0:N2}” -f ($_ /1mb)}

$Output = New-Object PSObject
$Output | Add-Member -MemberType NoteProperty -Name “User” -Value $mailbox.EmailAddress
$Output | Add-Member -MemberType NoteProperty -Name “Location” -Value $Location
$Output | Add-Member -MemberType NoteProperty -Name “TotalItems” -Value $AllStats.ItemsInFolderAndSubfolders
$Output | Add-Member -MemberType NoteProperty -Name “MailboxSize MB” -Value $ISSize
$Output | Add-Member -MemberType NoteProperty -Name “TotalContactItems” -Value $TotalContactsItems
$Output | Add-Member -MemberType NoteProperty -Name “TotalCalendarItems” -Value $TotalCalendarItems
$Output | Add-Member -MemberType NoteProperty -Name “TotalMailItems” -Value $TotalMailItems
$Output | Add-Member -MemberType NoteProperty -Name “TotalRSSFeeds” -Value $TotalRSSFeeds
If ($Location -eq “Destination”)
{
$Output | Add-Member -MemberType NoteProperty -Name “RecovableSize in MB” -Value $recoverableSize
$Output | Add-Member -MemberType NoteProperty -Name “RecovableItems” -Value $recoverableItems.ItemsInFolderAndSubfolders
$Output | Add-Member -MemberType NoteProperty -Name “Total Mailbox Size including Recovable” -Value $($ISSize + $recoverableSize)
$Output | Add-Member -MemberType NoteProperty -Name “Total Mailbox Count including Recovable” -Value $($AllStats.ItemsInFolderAndSubfolders + $recoverableItems.ItemsInFolderAndSubfolders)
}
$CSV += $Output
Write-Host “Completed $($mailbox.EmailAddress)” -ForegroundColor Green
}

$CSV | export-CSV “$OutputCSV” -NoTypeInformation
#End Script

To run the script you need to specify the location parameter:

.\MailboxFolderStats.ps1 -Location Source

.\MailboxFolderStats.ps1 -Location Destination (includes recoverable deleted items statistics)

As always I hope the above is helpful. Thanks for reading.

Office 365 tip: Enable Directory Sync via PowerShell

There’s no easy way to say this. The new Office 365 admin Portal comes with a new way to enable Directory Sync, a wizard that tries to guide you through with a series of questions and suggestions. The end result is bad, to say the least.

 

ADSyncWiz1

The wizard is confusing and the end result is sometimes not the expected. It happened to me several times finishing the wizard just to find out that Directory Sync was still disabled.

In my opinion things like finishing the wizard if you select “1-10” in the number of users of your organization, assuming of course that you don’t want Directory Sync, are not welcome. I understand the “dummy proof” idea behind it, but let’s face it not everything needs to be designed in such way.

ADSyncWiz2

As you can see above once you run the wizard you’ll get a summary report of the results, and links to download  AD Connect and the IdFix tool.

But the purpose of this blog post is to explain you how to get away from the wizard and on a simple command activate Directory Synchronization. Here it goes:

  1. Download and install the Windows Azure Active Directory Module for Windows PowerShell
  2. Connect to Office 365 and run the cmdlets below

ADSyncWiz3

Enable Directory Sync:

Set-MsolDirSyncEnabled -EnableDirSync $true

Verify Directory Sync state:

(Get-MsolCompanyInformation).DirectorySynchronizationEnabled

I hope the above is helpful. As always, any questions please let me know.

 

Office 365: Script to bulk change the UserPrincipalName to match the Email Address

When you are preparing your local Active Directory, to be synced with Office 365, one of the things you should consider is to make the UserPrincipalName of each user you are syncing to match the user’s email address. Why? Because that is going to be his UserPrincipalName and his primary SMTP address on Office 365.

So there are different ways of achieving this, some more manual than others. The procedure I am going to outline today on this blog post is a two step procedure:

Step 1: Export all UserPrincipalNames and Email Addresses from the local AD to a CSV File.

Step 2: Use that CSV file to bulk change the UserPrincipalNames to match those Email Addresses.

Like I said there are different ways of doing this, and I will probably develop a more elaborated script that can do this in a single step. The reason I went for this two step process is because most of the times customers want to check the CSV generated on step 1, and remove all the users that they don’t want to change the UPN, because those users will not be synced to Office 365.

Before we detail the steps above, make sure that you’ve added additional UPN domain suffixes for all the primary SMTP domains that you will have. See the article “How to add UPN suffixes to a forest” for more information.

Also have a detailed read on the article “Prepare to provision users through Directory Synchronization to Office 365”, to fully understand all the tasks you have to do to prepare your local Active Directory.

Making the UPN’s match the email addresses and have a domain that is validated on Office 365 is just one of the several tasks you have to do.

Now back to the two step process to change those UPN’s.

Step 1:

On step one all you have to do is open a PowerShell module on your local AD, and run the cmdlet below.

#Make sure you Import the Active Directory Module into your PowerShell session before you run the cmdlet

Import-Module ActiveDirectory

#Run the cmdlet to export all the users to a CSV. Change the CSV name and path as appropriate

Get-AdUser -Filter * -Properties UserPrincipalName, Name, EmailAddress | Select-Object UserPrincipalName, Name, EmailAddress | Export-CSV -Path C:\MyADUsers.csv -NoTypeInformation

After you run the cmdlet you should get a CSV like the one shown below:

ChangeUPN1

On the example above you can see that the UserPrincipalName does not match the user’s email address, and therefore needs to be changed.

Once you get the CSV check all users that you want to change and remove from that CSV the ones that you don’t.

Step 2:

Now that you have the CSV with all the users you want to change, all you have to do on step 2 is run the script below. The script will change all the UPN’s to match the email address, based on the CSV file you will use.

#Script to Change the UPN on the Active Directory#
#This script should run from an Active Directory Module for Windows PowerShell#
#Version 1.0 – 06/30/2015#
#Author: Antonio Vargas#

$UserCount = 0

Import-Csv -Path C:\MyADUsers.csv | ForEach-Object {

$UPN = $_.UserPrincipalName
Write-Host “Working on user:” $UPN
Get-ADUser -Filter {UserPrincipalName -Eq $UPN} | Set-AdUser -userprincipalname $_.EmailAddress
$usercount = $usercount +1
}
Write-Host “Number of users on your CSV: $UserCount”
Write-Host “UPN’s Changed”

Copy the entire content above into a notepad, and save it as a .ps1 file.

The script above is a very simple script that will read from the CSV. Before you run the script make sure you import the Active Directory module, as described on step 1, into your PowerShell session.

I highly recommend running the script first against a small group of up to 5 users, and then make sure that the changes were applied successfully. Also you need to take into account that you are changing the UserPrincipalName of the user on your local Active Directory, so make sure to test the access to all internal systems that rely on AD for authentication, before you replicate the change to all of your users.

As always, if you have any questions please let me know.

Office 365 AADSync Password Sync failed: Event 611 System.MissingMethodException

Just recently I installed the Microsoft Azure Active Directory Sync, and faced a strange issue: Password Sync was not working. When a password was updated on premises, those changes were not being replicated to Office 365. I was installing AADSync on a Windows 2008 R2 Operating system.

The Microsoft Azure Active Directory Sync tool event ID’s, that you can see on your server event viewer, are actually very good and make the job of troubleshooting the tool much easier. There is a Microsoft support article on how to troubleshoot AADSync that has all the event ID’s and if you’re having problems with the tool you should definitely have a look into it.

On my scenario, I went to the event viewer and immediately detected the event ID 611, that was stating that the Password Sync was failing for my internal domain, as shown below:

PassSync1

I started trying to understand why, and here’s what I looked at:

  • I had no firewalls between the AADSync Server and the AD Domain controllers
  • Both servers were on the same subnet and with the local firewall disabled
  • AADSync was communicating with the Domain Controllers and all other tasks were working, except the Password Sync feature

So there was no way that this was about networking. So I circled back to the prerequisites of AADSync and found out what the problem was:

I had installed Microsoft .Net Framework 4.5, and it actually was good enough to allow me to install AADSync, and you can actually find a lot of guides out there that state that the 4.5 version is good enough, but when you’re installing on a Windows 2008 R2 it’s not, and I needed to install Microsoft .Net Framework 4.5.1.

Once I upgraded the .Net Framework to 4.5.1 everything started to work.

Enable-MailUser errors: “Exchange GUID is mandatory on User mailbox” & “Database is mandatory on User mailbox”

Not long ago I had to prepare an Active Directory to be synced with an Office 365 tenant. The company wanted to have Azure Active Directory Sync installed on premises, and sync all the users (and passwords) to Office 365. The plan was to use several of the Office 365 services, with of course Exchange Online included (it always is, right? ).

Because the company was using Azure Active Directory Sync, part of the preparation of the on premises Active Directory was to install an on premises Exchange 2013 Management Server (see here why should you keep at least one Exchange Management Server on premises when you are using AADSync), and to convert all users that will have a mailbox on Office 365 into mail users on premises, so that they can be manageable from the Exchange tools, and have all Exchange attributes. If you have a Hybrid deployment an Exchange mailbox user on Office 365 should be a Remote Mailbox object on premises, but if that is not the case (and for me it wasn’t) a mail user is enough.

Not let’s go straight to the problem I had and that is mentioned on this article title.

When I tried to enable all the users as mail users, I got the following error for almost all of them:

“Exchange GUID is mandatory on User mailbox”..

“Database is mandatory on User mailbox”..

1

So that got me thinking, and the first thing that came to mind was: What Mailbox? The users I am trying to enable as mail users are not mailboxes.

So I went and checked the users properties on AD, went to the attribute editor and find out that although all the users that I was trying to change were not mailboxes on Exchange, most of them had the msExchHomeServerName attribute populated with the LegacyExchangeDN of the server that was probably hosting their mailbox before it was disabled. Something clearly went wrong on the process of disabling those mailboxes in the past, and I needed to remove those attributes.

When I identified that attribute as the possible cause, the next thing I did was to remove that attribute from a single user, and tried to run the Enable-MailUser Exchange cmdlet only against that user. It worked, that was the attribute causing the issue. By the way I highly recommend that you follow the same approach and don’t go and remove an attribute for hundreds of users without making sure that it is the attribute that is causing you the issue.

One other thing that I need to stress here is that those users from which I removed the msExchHomeServerName attribute were NOT mailboxes on my Exchange on premises. DO NOT remove that attribute from production mailboxes!

Not let me tell you how I automated the process to remove the attribute from all my faulty users.

First I needed to have a CSV file with all the users that had the issue. In my case no user on premises had a mailbox, except my admin user, so all I had to do was take a full list of the users and exclude the admin before using the CSV to delete the attribute. On the Exchange Management Shell I ran:

Get-ADUser –filter * -Properties msExchHomeServerName | where-object {$_.msExchHomeServerName –ne $null} |ft userprincipalname, msExchHomeServerName

2

And to export the result to CSV:

Get-ADUser –filter * -Properties msExchHomeServerName | where-object {$_.msExchHomeServerName –ne $null} |Select-object Userprincipalname, msExchHomeServerName | Export-CSV C:\Scripts\UsersToChange.csv –NoTypeInformation

3

4

And again I can’t stress this enough, if you do have some mailboxes on premises you might want to either filter the CSV you get as an output or put an “-And” on the where-object statement above to exclude the mailboxes using an attribute that the users with problems don’t have (i.e msExchRecipientType)

Not that I had the CSV I needed a script to read from that CSV and delete that attribute on all the users with problems. I found this excellent script on the TechNet Gallery that removes Exchange Attributes using PowerShell. But the script had two problems:

  • It removed more attributes that I wanted/needed to
  • It prompted you to enter the users one by one, and I had hundreds

So I created king of a version 2.0 of the script, but to my own purpose of course, so that the script could read from the CSV and automatically remove the attributes from all the users in it.

See below the part that manners on the script, that you need to copy into a notepad and save as .ps1:

Write-host

Remove Exchange Attributes

—————————-

Remove Exchange 2013 Attributes for a Corrupted Active Directory Account

This Script will use a CSV as baseline

Caution : Mailbox Will Go Disconnected and Exchange Attributes will be Removed” -ForeGround “Cyan”

$AllAccounts = Import-Csv -Path C:\Scripts\UsersToChange.csv

foreach ($Account in $AllAccounts) {

$ADaccount = Get-User $Account.Userprincipalname

$FullDistinguishName = “LDAP://” + $ADaccount.distinguishedName

$AccountEntry = New-Object DirectoryServices.DirectoryEntry $FullDistinguishName

$AccountEntry.PutEx(1, “msExchHomeServerName”, $null)

$AccountEntry.SetInfo()

write-host “Changes made to account” $Account.userprincipalname

}

Make sure you edit the path and the file name of the CSV, and you are ready to run the script.

5

Once it’s done go to the user’s attribute editor on Active Directory and see if the value of the msExchHomeServer attribute is null.

6

And re run the Enable-MailUser Exchange cmdlet for all your users again.

7

Job done! Any questions let me know.