While having Public Folder access in 365 set as remote in the Organization Config, point some users to the Exchange Online Public Folders

Some key things you should have in mind, when you’re moving your Exchange Organization from On Premises to Office 365, and Public Folders are in scope:

  • Before moving the Public Folders to Exchange Online, you need to move all of your users (at least you should move all of the ones that require Public Folder access). Users in Exchange On Premises cannot access Public Folders in Exchange Online.
  • You need to follow the Microsoft Official guidance to configure legacy on premises Public Folders under a hybrid deployment.
  • You can (and should in some scenarios) point some mailboxes to the online Public Folders and that’s what this blog post is all about

Now lets look at how a Hybrid Public Folder Organization Config looks like:

PFOrg1

As you can see above, the Public Folders in 365 are configured as remote (step 5 in the guide mentioned above), and an on premises public folder mailbox is defined as their mailbox (created in step 2 of the guide).

What this does is very simple: at the mailbox level, for each mailbox, it will set the parameter “EffectivePublicFolderMailbox” to the mailbox “OnPremPFMBX”, which is a synced mailbox object from on premises, as you can see below:

PFOrg2

And how do we change this, per user?

The answer is simple, you run a set-mailbox cmdlet, to one or multiple users, and you define the -defaultpublicfoldermailbox parameter, to a 365 Public Folder mailbox, that you of course need to have created before hand.

set-mailbox <Mailbox> -DefaultPublicFolderMailbox 365PFMBX

The command above is what you need to run, and you can adapt if to multiple users. Let me know if you need help with that.

Before closing this blog post lets just discuss one last thing: creating the Office 365 Public Folder mailbox.

A Public folder mailbox created under a Hybrid scenario, where public folder access is set to remote, will be set by default to a HoldForMigration state. Follow this excellent BitTitan article to understand why and resolve that issue. You need to resolve it before you can create new public folders in Exchange Online.

And while doing that don’t forget that, the best tool out there to migrate your Public Folders is the BitTitan MigrationWiz tool, so while you’re in our help center go ahead and read our migration guides and ask for a quote from our sales team.

Advertisements

BitTitan PowerShell Tips: How to connect the BitTitan SDK to the German instance

As many of you might know, the BitTitan SaaS has multiple instances across the globe, such as:

If you’re using the BitTitan SDK, to automate most, if not all of your project tasks, keep in mind the following:

  • By default, the BitTitan SDK connects to the global instance
  • There is no specific version of the SDK to connect to a different instance
  • There are 2 cmdlets that allow you to connect to the German instance:
    • Set-BT_Environment -Environment Germany
    • Set-MW_Environment -Environment Germany
  • You need to run the cmdlets above before you create the BitTitan PowerShell ticket

The BitTitan SDK interacts with both our MSPC platform – for tasks such as managing customers, endpoints, DeploymentPro, etc – and with our MigrationWiz platform, to manage your migration projects among many other things. Depending on the platform you want to interact with, you’ll need to run one of the commands above, or both. The “BT” commands applies to MSPC and the “MW” command applies to MigrationWiz.

See below the sample code screenshot.

BTSDK1

On a side note, if you’re wondering what a BitTitan PowerShell ticket is (mentioned multiple times in this blog post), all of the BitTitan cmdlets are backed by a ticket, that determines which environment we’re connecting into (MSPC or MigrationWiz), which workgroup/account and has the credentials to access it.

For much more information on how to code with the BitTitan SDK, go here or ping me an email via the blog contact form.

[Updated Version] Office 365: Script to bulk change the UserPrincipalName to match the Email Address

As I was seeing a lot of feedback in my original post, regarding how the scripts below had issues, I decided to post this new updated version. I will underline the updates  to be easier to follow, but if you never read the original post, please try not to skip any parts in this one.

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.

#If needed 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 | ? {$_.UserPrincipalName -notlike "DiscoverySearchMailbox*" -and $_.UserPrincipalName -notlike "HealthMailbox*" -and $_.UserPrincipalName -notlike "SystemMailbox*" -and $_.UserPrincipalName -ne $null} | Select-Object UserPrincipalName, Name, EmailAddress | Export-CSV -Path C:\MyADUsers.csv -NoTypeInformation
UPDATE: I’ve added some additional filtering in this cmdlet, specifically to filter out users that don’t have a UserPrincipalName, or users for some types of Exchange system mailboxes such as the discovery search or health mailboxes. You do not want to run the script to change UPNs for system users or any user which is not a regular user that will be syncing up to Office 365. Make sure you filter the output file appropriately before you use it to change the UPNs. Below some example of users that you might still need to filter out from the output CSV.
UPNUpdate1

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 2.0 - 06/22/2018

#Author: Antonio Vargas - antonio.vargas@myexchangeltd.co.uk

#Disclaimer: All scripts and other powershell references on this blog are offered "as is" with no warranty. While these scripts are tested and working in my environment, it is recommended that you test these scripts in a test environment before using in your production environment.

#Import the AD Module

Import-Module ActiveDirectory

#Static properties (change where needed)

$CSVPath = "C:\MyADUsers.csv"

#Count variables

$usersprocessed = 0

$userswitherrors = 0

$usersskipped = 0

#Import CSV

Try {

$CSV=Import-Csv-Path $CSVPath-ErrorAction Stop

}

Catch {

Write-Host"ERROR: Cannot import the CSV file. The script will abort. '$($Error[0].Exception.Message)'"-foregroundcolor Red

Exit

}

Write-Host "INFORMATION: The CSV was imported and you have '$($CSV.count)' users to be processed." -foregroundcolor Green

ForEach ($line in $CSV) {

$UPN=$line.UserPrincipalName

$Email=$line.EmailAddress

if($UPN-eq$Email) {

Write-host"SKIPPING: The UPN '$($UPN)' matches the email address"-foregroundcolor Yellow

$usersskipped++

}

Else {

try {

$ADUser=Get-ADUser-Filter {UserPrincipalName -eq$UPN-and Enabled -eq$true} -ErrorAction Stop

If($ADUser-eq$null) {

write-host"SKIPPING: The user '$($UPN)' is disabled or cannot be found."-foregroundcolor Yellow

$usersskipped++

}

Else {

Write-Host"Working on User '$($AdUser.UserPrincipalName)'"-foregroundcolor Yellow

try {

$result=Set-ADUser-Identity $ADUser.SamAccountName-Userprincipalname $Email-ErrorAction Stop

$usersprocessed++

Write-Host"SUCCESS: UPN Changed from '$($AdUser.UserPrincipalName)' to '$($Email)'."-foregroundcolor Green

}

catch {

Write-Host"ERROR: Cannot change the UPN of the user '$($AdUser.UserPrincipalName)'. '$($Error[0].Exception.Message)'."-foregroundcolor Red

$userswitherrors++

}

}

}

Catch {

Write-Host"ERROR: Cannot retrieve user '$($UPN)'. '$($Error[0].Exception.Message)'."-foregroundcolor Red

$userswitherrors++

}

}

}

write-host "`n"

write-host "############################# REPORTS ####################################" -foregroundcolor Green

Write-Host "REPORT: Total number of users processed with success '$($usersprocessed)'" -foregroundcolor Green

Write-Host "REPORT: Total number of users that were skipped for not meeting the criteria '$($usersskipped)'" -foregroundcolor Yellow

Write-Host "REPORT: Total number of users that failed to process '$($userswitherrors)'" -foregroundcolor Red

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

Some changes done to the script from the original blog post:

  • Error handling added
  • the script imports the Active Directory module
  • added count for users done with success, skipped or failed
  • small report at the end
  • the entire logic of the code on when to process users was changed 

Disclaimer: All scripts and other PowerShell references on this blog are offered “as is” with no warranty. While these scripts are tested and working in my environment, it is recommended that you test these scripts in a test environment before using in your production environment.

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.

For large environments, if you want a version of the script that exports to CSV all the user results (i.e changed, skipped, failed) feel free to send me an email via the blog.

Go ahead and test the script with its new changes and let me know how that goes.

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

Exchange Public Folders: Export item count, per item type, of your public folder structure

Just recently, I was asked to help investigate which Exchange cmdlets would help a partner the I work with, do an item count in an on premises Exchange Public folder structure. Their specific ask was to get, per folder, the number of contact items.

So starting with the best command to do this, it’s easy to get to the conclusion that it will be the Get-PublicFolderItemStatistics, and the first thing that you need to know about that cmdlet is that it’s only available in Exchange 2010+.

The second thing you need to focus on is, in which folders do you want to run the count on? All of them? And if not all, do you want to run the count based on folder type? i.e do you want to just count calendar items on folders of type calendar? How can we achieve this?

Lets break this down:

  • To be able to select the folders you want to count the items for, you need of course to start with the Get-PublicFolder cmdlet
  • If you want to filter just one or multiple folder type (i.e Calendar, Contacts, etc) you need to do it using the “FolderClass” attribute.

Note: The “FolderClass” attribute doesn’t exist in all versions of Exchange. I haven’t checked in detail but at least apparently in Exchange 2010 you won’t be able to leverage this attribute to filter just the folders you want. Worst case scenario you can always run a count against all folders. Also note that as you can see below, not all folders have a “FolderClass”.

PFCount1

And finally the code to grab all the folders you want.

With the FolderClass attribute filtering:

#Get all folders
$folders = get-publicfolder \ -recurse -resultsize unlimited | ? {$_.FolderClass -like “IPF.Contact”}
And without:
#Get all folders
$folders = get-publicfolder \ -recurse -resultsize unlimited

 

Note: The Where-Object filtering (? sign in the command above) in PowerShell caches all its results into memory, so if you have a very large public folder structure you might want to have that in mind and run the commands in a machine with enough resources.

Now that we know how to grab all the folders we need, lets look at how to do the folder count:

  • The command used to do the folder count is, as mentioned above in this post, the Get-PublicFolderItemStatistics
  • Because all you want to do is count items of a certain type, you will leverage the “ItemType” attribute in your filtering
  • Don’t forget that the Get-PublicFolderItemStatistics is an Exchange 2010+ cmdlet

Below see the output of an item count of a specific folder.

PFCount2

Now, finally, the entire script (in bold the item count):

PFCount4

(and the copy/paste version)
#Get all folders
$folders = get-publicfolder \ -recurse -resultsize unlimited | ? {$_.FolderClass -like “IPF.Contact”}
#Process All folders
Foreach ($folder in $folders){
$ContactCount = 0
$Contacts = get-publicfolderitemstatistics $Folder.Identity|? {$_.ItemType -like “IPM.Contact”}
If($Contacts -eq $null){
Write-Host”The folder ‘$($Folder.Identity)’ has 0 Contacts”
}
Else{
foreach($Contact in $Contacts){
$ContactCount++
}
Write-Host”The folder ‘$($Folder.Identity)’ has $($ContactCount) Contacts”
}
}
Lets break down the script above:
  • we start by getting all folders of class contact. Again you can do this filtering or not, depending on the Exchange version and what you need exactly.
  • we then enter a loop where, for each folder, we will grab all items of type contact and count them
  • once that is done we write the output into the console

This script is very simple and doesn’t have error handling, logging and output to CSV. If you want those features feel free to contact me via the blog and I can build you a very complete version of the script.

Running the simple version of the script in a large environment can make the results difficult or impossible to analyse, however, with the code above gives you an insight in how to filter and count Public folders, by type and class.

As always I hope this is helpful.

Azure AD Connect: A quick way to check (online) the last time the sync ran

I was just doing some work in a devops work tenant, that usually has a Hybrid setup created and Azure AD Connect installed and running, and I realized that I needed to check when was the last time that:

  • the Directory synchronized successfully
  • Passwords synchronized successfully

As this is a very simple process I thought I should write a 5min blog post about it.

All you have to do is connect to the Azure Active Directory of your tenant and execute the Get-MSOLCompanyInformation.

ADConnectSyncTime

The 3 parameters that you want to look at are:

  • DirectorySynchronizationEnabled (this one is not mentioned above. It shows if the tenant has the synchronization enabled or not)
  • LastDirSyncTime
  • LastPasswordSyncTime

Hope that this information is helpful.

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.

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!