Office 365: Run a script connected to 2 Exchange online sessions

Have you ever wondered how you can connect to 2 Exchange Online sessions, in the same PowerShell window?

For example, if you want to run a script that connects to 2 tenants, exports all mailbox permissions from one tenant and imports them into the other. Same thing applies to Distribution groups and memberships.

With the Microsoft Tenant 2 Tenant Migrations in high demand, and because there are so much that you might want to bring from one Exchange Online to the other, I thought I should write a quick blog article on how to connect and manage 2 Exchange Online tenants in one PowerShell window, ideal for scripting.

Before you look at the code below, let me outline two key parameters, of the Import-PSSession cmdlet to achieve your goal:

  • Prefix – Specifies a prefix to the nouns in the names of imported commands.
    Use this parameter to avoid name conflicts that might occur when different commands in the session have the same name.
    For instance, if you specify the prefix Remote and then import a Get-Date cmdlet, the cmdlet is known in the session as Get-RemoteDate, and it is not confused with the original Get-Date cmdlet.
  • AllowClobber – Indicates that this cmdlet imports the specified commands, even if they have the same names as commands in the current session.
    If you import a command with the same name as a command in the current session, the imported command hides or replaces the original commands. For more information, see about_Command_Precedence.
    By default, Import-PSSession does not import commands that have the same name as commands in the current session.

Note: Both the definitions above were taken from the Import-PSSession cmdlet official Microsoft article, that you can see by clicking here.

So how does this work actually? Have a look at the code below:

<#
.NOTES
 Author: antonio.vargas@myexchangeltd.co,uk

Date: October 4th 2017
 Version: 1

.SYNOPSIS
 This lines of code will connect 2 PowerShell Exchange Online sessions to 2 different tenants. 
.DESCRIPTION
 By opening 2 PowerShell sessions, using the PREFIX parameter for each one of those sessions it will allow you to manage both tenants at the same time (ideal for tasks where you want to migrate configurations from one tenant to the other)
#>

### Input source and destination credentials

$SourceCred = Get-credential -message "Please Enter your SOURCE tenant credentials"

$DestCred = Get-credential -message "Please Enter your DESTINATION tenant credentials"

### Create Source EXO Session

$SourceSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -AllowRedirection -Authentication Basic -Credential $SourceCred

$result = Import-PSSession $SourceSession -prefix SRC -AllowClobber

### Create Destination EXO Session

$DestSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -AllowRedirection -Authentication Basic -Credential $DestCred

$result = Import-PSSession $DestSession -prefix DST -AllowClobber

### Run a get-mailbox to validate connection to both tenants

Write-Host "Listing mailboxes in the source tenant" -ForegroundColor Green

Start-Sleep -s 5

Get-SRCMailbox -resultsize unlimited |ft alias, *smtp*

Write-Host "Listing mailboxes in the destination tenant" -ForegroundColor Green

Start-Sleep -s 5

Get-DSTMailbox -resultsize unlimited |ft alias, *smtp*

### Showing a count of mailboxes in source and destination

Write-Host "Counting mailboxes in the source tenant" -ForegroundColor Green

Start-Sleep -s 5

(Get-SRCMailbox -resultsize unlimited).count

Write-Host "Counting mailboxes in the destination tenant" -ForegroundColor Green

Start-Sleep -s 5

(Get-DSTMailbox -resultsize unlimited).count

### LISTING PS SESSIONS

Write-Host "Your list of active PS Sessions" -ForegroundColor Green

Get-PSSession |fl

Some considerations of the code above:

  • There’s no logging or error handling in the code. The purpose of the code above is to provide you the insight on how to connect to 2 sessions with the same cmdlets.
  • The code is provided as is and you should test it before you run it in production.
  • The code includes blocks to perform the following:
    • Request input for source and destination credentials
    • Create the source Exchange Online session
    • Create the destination Exchange Online session
    • Code to demonstrate how to run cmdlets in the source and destination tenant (example with get-mailbox)
    • Code to list both PS Sessions created

Now lets see the output of the code:

2sessions

Simple, right? Again this can be very useful for tenant to tenant migrations.

Advertisements

Azure: “CurrentStorageAccountName is not accessible” error when creating a VM via the SDK

I just recently faced an error when doing an Azure lab, that I thought I should blog about, since the resolution is very simple.

Here’s what happened, I was creating a VM via the SDK using the Service Module (Classic – see note below) and the following cmdlet:

New-AzureQuickVM –Windows –ServiceName “AV-AutoSVC” –name “AV-AutoVM” –ImageName $image –Password $password -Location “East US” -InstanceSize “Basic_A0” -AdminUsername avargasadmin

Note: You can create virtual machines both with the service model (classic deployment) or with the Resource manager (new portal). Both methods are available via SDK but the way to connect is different. You use Add-AzureAccount to login to the service model and Add-AzureRMAccount to login to the resource manager. See differences here.

And I got the following error:

Azure01

New-AzureQuickVM: CurrentStorageAccountName is not accessible. Ensure the current storage account is accessible and in the same location or affinity group as the cloud service.

Now after digging a little bit more in my Azure tenant and what might be the cause of the problem I confirmed that I did had the storage account, and even with the -Location parameter in the cmdlet above forcing it to be “East US” (where my storage account is) I was still getting the same error.

Then I decided to run a the following cmdlet:

Get-Azuresubscription

azure02

I then realized that I have no valid storage account associated with my subscription, and the solution to my problem was to run:

Set-AzureSubscription –SubscriptionName <YourSubscriptionName> –CurrentStorageAccount <YourStorageAccountName>

If you don’t know your storage account name run:

Get-Azurestorageaccount |fl storageaccountname, location

Once you do this, re run your New-AzureQuickVM cmdlet (note: this error should happen also when you’re running the New-AzureVM cmdlet) and the error should be gone.

 

No Outlook 2007 in Exchange Online. Be prepared with BitTitan HealthCheck for O365

I just wrote yesterday a blog post about the dead of RPC over HTTP in Exchange Online, and how that terminates Outlook 2007 as a functioning version to connect to the cloud Exchange.

In that article I briefly talked about how you can use the Exchange PowerShell and mailbox audit logging to determine the version of Outlook your users have, but that has some limitations, such as:

  • If you’re moving to 365, from a non Exchange system, or one previous to Exchange 2010, you won’t have mailbox audit logging.
  • Mailbox Audit logging is off by default and in Exchange on premises systems that are very low on resources (hence the possible move to Exchange Online), it’s something that some Exchange administrators might be reluctant to turn on (although the truth is the load is minimal).
  • The report is extensive and includes all connectivity that each user did to Exchange. Identifying the computer with the outdated Outlook in some cases might be tricky (users that have roaming profiles and log into multiple computers).

So in summary, if you are assessing your users mail clients as part of a migration or if your users use multiple workstations, the approach above is not ideal.

That being said, the solution for you is the free BitTitan HealthCheck for Office 365 module, that is part of the BitTitan Device Management Agent software.

From a technical perspective, once the DMA agent is deployed (via email or automated process such as Group Policy), the HealthCheck for Azure module will run a full assessment to the machine. It will provide much more information than just Outlook, such as:

  • Operating System
  • Disk Space, CPU and memory
  • Internet download and upload speed
  • Device specifications
  • Browsers and Outlook versions

As you can see you’ll get a very complete report and it doesn’t require any license.

As a final note the Device Management Agent also has the DeploymentPro module, that you can use to automatically reconfigure the Outlook profile, as part of your migration.

 

Exchange Online: The end of RPC over HTTP

And that’s it, more than 3 years after Microsoft launched MAPI over HTTP (the replacement for RPC over HTTP – aka Outlook Anywhere), now it’s time to announce that in October 31st 2017 the RPC over HTTP feature will be deprecated in Office 365.

Some of my thoughts on this, and things you should consider..

How about Exchange On-Premises?

The deprecation of RPC over HTTP is announced just for Exchange Online. What does that mean to Exchange on premises deployments? Probably that in a future Cumulative Update the feature will be discontinued, but for now, all stays the same with on-premises.

When Microsoft launched Exchange 2016 they listed the RPC over HTTP feature as de-emphasized and not discontinued.  That basically meant that it still works and it’s still supported.

That doesn’t mean that this will always be the case, and with this announcement coming now to Exchange Online, maybe a new Exchange 2016 CU will remove the RPC over HTTP feature, or maybe this is just Microsoft not publishing the rpc virtual directory anymore, in Exchange Online. I guess that at some point we will find out, but for now all supported versions of Exchange also support RPC over HTTP in an on-premises deployment.

My personal opinion is that it won’t take long for RPC over HTTP to be also deprecated i

Check the matrix below for current connectivity supportability:

Product Exchange 2016 RTM Exchange 2013 SP1 Exchange 2013 RTM Exchange 2010 SP3
Outlook 2016 RTM
  • MAPI over HTTP
  • Outlook Anywhere
  • MAPI over HTTP
  • Outlook Anywhere
Outlook Anywhere
  • RPC
  • Outlook Anywhere
Outlook 2013 SP1
  • MAPI over HTTP
  • Outlook Anywhere
  • MAPI over HTTP
  • Outlook Anywhere
Outlook Anywhere
  • RPC
  • Outlook Anywhere
Outlook 2013 RTM Outlook Anywhere Outlook Anywhere Outlook Anywhere
  • RPC
  • Outlook Anywhere
Outlook 2010 SP2 and updates KB2956191 and KB2965295 (April 14, 2015)
  • MAPI over HTTP
  • Outlook Anywhere
  • MAPI over HTTP
  • Outlook Anywhere
Outlook Anywhere
  • RPC
  • Outlook Anywhere
Outlook 2010 SP2 and earlier Outlook Anywhere Outlook Anywhere Outlook Anywhere
  • RPC
  • Outlook Anywhere
Outlook 2007 Outlook Anywhere Outlook Anywhere Outlook Anywhere
  • RPC
  • Outlook Anywhere

Any versions of Outlook being affected?

The simple answer is yes. All versions will be affected. Outlook 2007 will stop working (remember Office 2007 is out of extended support), and all other versions need to be properly updated, to the minimum versions described on the table below:

Office version Update Build number
Office 2016 The December 8, 2015 update
  • Subscription: 16.0.6568.20xx
  • MSI: 16.0.4312.1001
Office 2013 Office 2013 Service Pack 1 (SP1) and the December 8, 2015 update 15.0.4779.1002
Office 2010 Office 2010 Service Pack 2 (SP2) and the December 8, 2015 update 14.0.7164.5002

Read the Microsoft article for more details on the above.

Why MAPI over HTTP?

Let me bullet point some main reasons:

  • Better connection resiliency
  • Additional secure sign-in scenarios (multi-factor authentication)
  • Better foundation for third-party identity providers
  • Less complexity as it doesn’t depend on RPC technology
  • With less complexity the Exchange team can innovate more quickly
  • Fits into today’s reality with clients connecting from all sorts of different networks

So in a nutshell, it’s more secure, more flexible and reliable in terms of connectivity, and it’s less complex.

For more information read this amazing blog post from the Exchange product team, around MAPI over HTTP.

What should an Exchange Online administrator start doing, right now?

Identify the Microsoft Outlook versions and builds that his users have and use to connect to Exchange Online.

How? Using the PowerShell is the best method. Here’s an example command that you can run:

Get-Mailbox | Search-MailboxAuditLog -LogonTypes owner -ShowDetails | ? { $_.ClientInfoString -like “*Outlook*” } | select MailboxOwnerUPN,Operation,LogonType,LastAccessed,ClientInfoString | export-csv .\OutlookConnections.csv

I will write a blog post soon with more details, screenshots and eventually a script to gather and export all if this information.

 

Google Suite: Use GAM to get a list of all users forwarding addresses

A few days ago I wrote a blog post on what domain names to use in Google, to forward email to Office 365. In that article I explained the differences between the user-level forwarding, set by the Google administrator, and the forwarding set at the account settings level, by each user or by you with an automation tool (such as GAM or the BitTitan Management Console).

If you read the article and you agree with me, that setting the forwarding address at the account settings level through automation, is the best option, then read on this one because I am about to explain you how do you, as a Google Administrator, can extract a report to have visibility across the entire Google tenant, on all forwarding addresses that are set per user.

Step 1: If not already, download, install and configure the GAM tool

The GAM tool is a command line tool that allows you, Google Suite administrator, to manage your tenant.

On the GAM tool main page you find instructions on how to download it, install it and configure it, with all the appropriate permissions into your Google tenant.

Step 2: Export the forwarding addresses

Once you have the GAM tool installed you can use it to print the forwarding addresses.

With the command prompt open (and the GAM tool installed and configured of course), do the following.

You can print one user by running:

gam user <Username> print forwardingaddresses

GAM1

Or you can print for all users by running:

gam all users print forwardingaddresses

GAM2

As you can see, it’s a simple process. It will export the user, the forwarding email and the verification status of that forwarding.

To get the results exported you have two options.

Export directly to CSV from the command prompt:

gam all users print forwardingaddresses > C:\GAM\MyUsers.csv

GAM3

Export the result to Google Drive from where you can download as an Excel file:

gam all users print forwardingaddresses todrive

GAM4

Note: Follow the link to the Google Drive, provided on the command line. Once you have the document open, go to File > Download > Excel (xlsx)

Step 3: Export the forward configurations

Once you have all of the addresses, you should also think about exporting the forward configurations, which are the options you can select when you set the forward, to what happens to the message on Google (keep|archive|delete|markread).

I won’t go over the export options again, as they are the same as in step 2 of this post. Check below the commands to export for one or all of the users.

You can print one user by running:

gam user <Username> print forward

GAM5

Or you can print for all users by running:

gam all users print forward

GAM6

Note: As you can see above the option names don’t match (i.e keep=leaveInInbox and trash=delete) but they are very self explanatory. 

And that’s it, you now know exactly which per user setting, in terms of forwarding, each one of your users has configured.

Thank you for visiting my blog!

 

 

 

Google Suite to Office 365: Forwarding email address options

When migrating your email from Google Suite to Office 365, or simply having mail flow coexistence between the two systems, I am usually asked the same question: Which email domains can I use as forwarding addresses in Google, to forward email to Office 365?

The answer is not very straightforward, and first and foremost it’s important to understand that in Google, per user email forwarding can be done in two ways:

For more information you can check the Google Suite Forwarding options article.

Now lets cover both options and what domains can be used.

Forwarding domain options: User Level Routing

Basically, with this option, the administrator can select whatever domain he wants to be the forwarding address. A very common scenario is to choose the onmicrosoft.com address, as the example below.

Google1

Above you can see the forwarding in the Google Admin portal, to the address user10@myexchlab22.onmicrosoft.com. The SMTP envelope will remain intact and no copy will be saved in the Google mailbox.

Google2

And the user primary SMTP address on Google.

Google3

The list of SMTP addresses in Office 365, for User10.

Google4.JPG

And the email sent to User10@myexchlab.com, that was forwarded to Office 365.

Google5

Finally a quick look at the email headers. Some considerations on that:

  • you can see that the email is initially received by Google, coming from Office 365 (the sender is from a completely independent 365 tenant)
  • You can then see that the email is forwarded to User10 in my Office 365 test tenant. You will see it’s received in 365, coming from Google.
  • Finally a quick note on the SPF failure. It’s a soft fail and one that you can’t control. What it basically says is that Google is not a permitted sender for the senders domain.

Summary:

The summary of this method is that it has no limitations, but, the catch is, stamping forwarding addresses in the Google admin console is not something that you can automate, to make it scale, i.e there’s no good method (to the best of my knowledge) to stamp addresses in 1000+ users, which is a huge manual task.

Forwarding domain options: Forward email to another account via mailbox settings

The second option can be done by the end user, but can also be automated. With this option you’re a bit more limited in terms of what domain names you can use for forwarding. Why? Let me show you.

google6

Above you can see a forwarding set, in the tab “Forwarding and POP/IMAP” of the mailbox settings. To set the forwarding all I needed to do was add a forwarding address and select the “Forward a copy…” option. But my forwarding above is done to the O365.myexchlab.com domain, which is a sub-domain of a domain that my Google tenant owns. What does that mean exactly? That Google knows for a fact that if I own the domain myexchlab.com I also own the forwarding domain O365.myexchlab.com, and therefore does not ask me for any validation.

Makes sense? Now lets see when I try to forward to a domain that is not on Google, nor it’s a sub-domain of one that it is.

google7

As you can see Google is going to send a confirmation code to the destination address, in order for you to prove ownership.

google8

And the address won’t be available until you confirm it.

Now what’s the biggest problem with this? It doesn’t scale. Which means that with this method you will need to use the sub-domain method. Automation tools to add those addresses, like the GAM tool or the BitTitan SDK, won’t work in such scenario with those forwarding email domains.

Summary:

This is by far my preferred method. The only drawback with this, in my opinion, is that administrators have no visibility to the forwarding configurations, via the UI. But they can export them via the GAM tool.

Bottom line

If you are planning to configure mail flow coexistence between Google and Office 365, I’d recommend that you create a sub-domain in Office 365 (i.e O365.mydomain.com – mydomain.com must be valid in Google), don’t forget to add all DNS records such as MX and SPF, and use that sub-domain in your forwarding addresses.

If you want to automate the configuration (and you should), you can either use the GAM tool, or even much better, use the BitTitan Management Console, part of the BitTitan SDK that comes with an option to manage forwarding addresses on Google, and you won’t have to bother learning how to use the GAM tool, that believe me it’s not easy.

I will soon be writing a blog post on how to use the GAM tool to get a list of forwarding addresses from Google.

As always if you have questions let me know.

Office 365: How to scope impersonation when migrating to and from Exchange Online

When you’re migrating to or from a Microsoft Exchange system, using an awesome tool like the BitTitan MigrationWiz, that leverages the Exchange Web Services (EWS) for the migration, you have 2 main options for administrator access to the mailboxes you’re migrating to and/or from: Impersonation and Delegation.

The best option depends on if the Exchange server is the online version (Office 365 multi tenant) or on premises. For Exchange on premises you should use delegation and for Exchange Online you should use impersonation. Why? Because you can’t create throttling policies in Exchange Online and impersonation is much less subject to throttling, when compared with delegation.

It’s important to understand that impersonation will also be subject to throttling, just not as much as delegation. When you’re migrating with delegation, all actions are done on behalf of the admin account, as opposed to when you’re migrating with impersonation, where actions are made on behalf of the account that is being migrated and impersonated.

Now that we can all agree that impersonation is the best authentication method for Exchange multi tenant systems (by the way this also applies to hosted Exchange systems outside of Office 365, but setting up impersonation on those systems might be somethings Hosters won’t do, unless they scope it, which they usually don’t), lets discuss the topic of this post: How can you scope impersonation? What exactly does that mean? And when will this be useful?

The answer for the first question is that you can scope impersonation by using management scopes and management role assignments.

As for the second question, scoping the impersonation rights means basically that the admin account will only be able to impersonate the accounts you define within that scope filter.

Finally the third question: this is useful when, for security reasons, you (or someone from the security team of the source or destination tenant) don’t want the admin account, that will perform the migration, to have access to impersonate all users in the tenant. This is a very common scenario in mergers, acquisitions and divestitures, where the admin user doesn’t need access to users that are not part of the migration.

Now lets translate all of this into a step by step guide of what you need to do, in order to scope impersonation in your Office 365 tenant.

Step 1: Create a distribution group

There are many different ways to apply a filter into a scope, and limit a management role assignment such as Application Impersonation, to a specific scope. I will teach you a simple way: via group membership.

You can create the group via the 365 management console or via the PowerShell. I recommend that you create a simple @tenantname.onmicrosoft.com group as shown below (apologies, my current Office 365 tenant is in Portuguese, but I guess you can all recognize and understand the UI 🙂 ):

Group1

TIP: If you create this group just for the purpose of scoping impersonation, I recommend that you hide the group from the Global address list.

Now that the group is created, lets retrieve its DistinguishedName property:

Get-DistributionGroup -Identity AllowImpersonationDistributionGroup |fl name, dist*

group2

Note: In the command above use your own Distribution group name, as you created it, or just run the Get-DistributionGroup without specifying the identity, and grab the DistinguishedName from the correct group (all will be listed).

Step 2: Create a Management Scope

Create a new management scope, use the “RecipientRestrictionFilter” parameter and the “MemberOfGroup” filter:

New-ManagementScope RestrictedMigrationScope -RecipientRestrictionFilter {MemberOfGroup -eq ‘CN=AllowImpersonationDistributionGroup,OU=tenantname.onmicrosoft.com,OU=Microsoft Exchange Hosted Organizations,DC=EU
RP193A002,DC=PROD,DC=OUTLOOK,DC=COM’}

group3

Note: To run the command above you might need to enable the Organization customization in your Office 365 tenant.

Step 3: Create the Management Role Assignment

Now that we have the scope created the last step is to create the management role assignment and associate it with the admin migration account:

New-ManagementRoleAssignment -Name:MyMigration -Role:ApplicationImpersonation -User:user10@
myexchlab.com -CustomRecipientWriteScope:RestrictedMigrationScope

group4.JPG

Note: In the command above use the scope name and the admin account that you are using for the migration. For my migration the admin is user10@myexchlab.com

And that is it, job done. Lets do some testing.

Below you can see users 1 to 5, that I will be migrating, and user10 that I will use as an admin.

group5

Now looking at the group membership you can see that only user1, user3 and user5 are withing the scope, which means that user10 won’t be able to impersonate users 2 and 4.

group6

Finally the result in MigrationWiz, in a project configured to use impersonation and with user10 as the source admin.

group7

As you can see above, users 2 and 4 failed, and here’s the detailed error.

group8

Bingo… MigrationWiz failed to impersonate at the source. Of course now that you read this that error will never happen to you!! 🙂

Happy migrations and as usual if you have any questions let me know.

 

Public Folders to Office 365 groups, anyone?

Just recently, the Microsoft Exchange Team reached out to the public again asking if partners or customers out there are interested in moving from the well known ancient Exchange Public Folders (and yes they can be modern or legacy) to the new Office 365 groups.

In the Microsoft Exchange Team Blog they state that the main focus will for now be to migrate mail and calendar items, but they do leave the “door open” to future support to be extended to other item types. How awesome would it be to convert Public Folder posts into OneNote in the Office 365 groups, right? 🙂

As a final note, they also state that, this will be focused in source Public Folders that can be on-premises or in Office 365.

Now before we look at all migration (and in some cases conversion) options, lets look at all the item types that you can have in when you create a Public Folder:

  • Mail and Post
  • Calendar
  • Contact
  • Note
  • Tasks
  • Journal
  • InfoPath forms
  • Documents

So what can you move to Office 365 groups and how? Ideally you would migrate mails and calendars into the Office 365 group mailbox, documents into the Office 365 group document library and Posts into OneNote. That I’d say would cover a huge percentage of the Public Folder usage we have out there today, don’t you agree? Hopefully if you’re reading this post, and thinking on doing the conversion from Public Folders to Office 365 groups, the Public Folder usage of your organization is focused in mail, calendars, contacts, posts and documents.

So now your question might be: is there any option out there that can migrate at least part of this content, from Public folders to Office 365 groups? And the answer is YES!

BitTitan MigrationWiz will help you do the following migrate from Public Folders (Exchange 2007+ on premises or Exchange Online) into Office 365 groups. Not all content will be moved, due to limitations in the EWS API, currently used by MigrationWiz to migrate Public Folders as a source, but here’s what you should expect:

  • Emails get migrated from mail enabled Public Folders into the Office 365 group mailbox. They will show in the conversation section.
  • Posts get migrated from Public Folders into the Office 365 group mailbox (attachments included). They will show in the conversation section.
  • Calendar items get migrated from the Public Folder calendar into the Office 365 group mailbox calendar.
  • Office 365 groups do not have a way of showing shared contacts and tasks, therefore you should not try and migrate them.
  • Documents do not get migrated from Public Folders to the Office 365 group SharePoint library.

Migrating data between different systems (Public Folders vs Office 365 groups) is not all about the question “Can the data be migrated or not?”. A good example is what I highlighted above about the tasks and contacts, why?

  1. MigrationWiz can migrate the tasks and the contacts
  2. The tasks and the contacts, after being migrated, will show up in the statistics of the mailbox (that you can extract via PowerShell)
  3. The design of the Office 365 groups won’t allow your users to see those tasks and contacts in any of the clients where you can use to access the groups
  4. That makes migrating contacts and tasks a pointless exercise

Finally some high level tasks on how to perform the migration:

  1. Create MigrationWiz Public Folder project
  2. Edit the advanced options a change the destination to shared mailbox
  3. add in the advanced support options: RemoveFilterBasedOnFolderType=1
  4. Add one line item per item type: One for email and one for calendars
  5. Add folder mapping to each line item to map the items into the correct folder in the destination (i.e FolderMapping=”^.*$->Calendar”)

Like stated in the disclaimer below, BitTitan does not have currently a migration guide for this scenario. If you want more detailed steps please leave a comment and I will reach out.

Disclaimer: To migrate from Public Folders to Office 365 groups I used the BitTitan feature of migration from Public Folders to Shared mailboxes. Technically an Office 365 group has a mailbox in many ways similar to a shared mailbox, but with some differences.

BitTitan does not have a migration guide nor it states (at the day and time that this blog was written) that it supports the migration from Public Folders to Office 365 groups.

This blog post was written after careful testing and verification and the migration worked without any issues. If you are interested in using MigrationWiz to migrate from Public Folders to Office 365 groups I highly recommend that you contact BitTitan and engage in a POC (proof of concept).

As always, any comments are welcomed and let me know how that migration went.

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.