Merger-friendly Tenant Names

Merger and Acquisition is the new name of the game in the last couple of years. Companies are buying each other, divesting parts, and spinning off departments and renaming themselves according to the latest fashion trends in the business world. By the end of the year of 2017, we are seeing that large number companies are fully deployed in the Office 365.
Tenant name is one of the system names, that is chosen before the company is migrated into office 365 and hardly visible to an outside world. Yet, one of the current limiting factors of the Office 365 tenants is the inability to be renamed. Once name has been reserved it is there to stay perpetually (very much like the NT 4.0 back in the stone ages. Pardon me, I didn’t mean to make anyone feel old). Since the tenant rename is not possible, full content migration must happen during M&A. Moreover, Microsoft’s tools, at this point in time, will not allow you to move content from one tenant to another due to several limiting factors.
While we cannot go back in time (at least not just yet), we can contemplate about what could have been done to avoid the vanity-driven renames. The answer is surprisingly easy, if we have known that Contoso will merge with Fabrikam and new venture will be called Litware we would have not named Contoso’s tenant the and Fabrikam’s tenant the nor we will step on the same rake again and will not name the new tenant the, but rather create something disambiguated from the business name in case our newly created Litware will be purchased by the Northwind company a year or so from now, and you’ll have to start this dance all over again.
It seems that naming your tenant with a generic GUID is a better option than binding it to an actual brand name that is in no longer a constant in the business world but rather a variable.
While GUID idea is pretty darn good from the point of view of uniqueness and will provide you with full disambiguation from any business name, it will likely to drive you, the IT guy, to madness, when you’ll have to log-in into the tenant with the not-so-human-friendly name. So, I would suggest looking into other industries and sources for an inspiration for a naming convention, providing you with some human-friendly, yet generic names for your tenant(s).

One thing comes to mind is hurricane naming. Each new oceanic weather system of a significant size is now named by a mixture of female and name names and destructive hurricane names are not re-used.
Therefore or sounds like an attractive name regardless of the business or current brand name.

Greek Alphabet:
Care to start your own fraternity or sorority of sorts: is a better choice than when it comes to the merger and acquisition.

While modern gods are probably the inappropriate way to name your tenant sounds like a match made in heaven.

And what about the phonetic alphabet? could be a fun name to use, while keeping the Foxtrot as Plan B option.

It’s Elementary:
While diamonds are forever, they are just plain carbon. And, no surprise there, is no longer available. So, we have to settle for the gold and platinum or you can have fun and celebrate with

So, there you have it, ambiguous, yet humanly-usable names assigned to the tenant could be a better way to hedge your IT investment against apparently inevitable business changes.

Cheers to that!

#Office365 #O365 #TenantName #TenantRename #Merger #Acquisition #MnA #M&A #MergerAndAcquisition #NamingConvention


Office 365 Licensing Report

Reporting is not one of those things that people enjoy doing… and under “people”, I mean most people… and under “most people”, I really mean myself. So, when I am asked to produce some kind of report, I rather do the hard work once and try to re-use it later. This time requested reporting was associated with Office 365 Licensing. We have all seen plethora of “assign license” scripts, from one liners, to screens and screen of code. However, once licenses are assigned (or mis-assigned) you might need to pull-down all that licensed user information and analyze it in Excel.
While working with licenses in Office 365, I have found myself being a little nostalgic about times when I was doing much more C# coding than I can afford nowadays. So Office 365 licensing information that you can get with MSOL PowerShell cmdlets is actually quire rich. The challenge is in the way you need to retrieve that licensing information from well-packaged object-oriented model that licensing information is coming at you from PowerShell.
So, below is the script that should allow you to retrieve licensing information from your tenant and present it in CSV format that you can slice and dice for analysis.

— — —

## Importing MS Online Module for PowerShell
Import-Module MSOnline;
## Connecting to MS Online Service
## Variables
[System.String]$emptyGuid = [System.Guid]::Empty.ToString();
[System.String]$path = Split-Path -parent $MyInvocation.MyCommand.Definition;
[System.String]$FileName = [System.String]::Format("{0}\{1}{2}{3}{4}{5}{6}-log.csv", $path, [System.DateTime]::Now.Year, [System.DateTime]::Now.Month, [System.DateTime]::Now.Day, [System.DateTime]::Now.Hour, [System.DateTime]::Now.Minute, [System.DateTime]::Now.Second);
## Parsing MSOL User Object for licensing information
function Get-MsolUserLicense{
[Parameter(Position=0, Mandatory = $true, ValueFromPipeline = $true, HelpMessage="Microsoft Online/Azure AD Account object")]
[System.String]$upn = $Identity.UserPrincipalName;
if ($Identity.IsLicensed) {
[System.String]$accountSkuId = $Identity.Licenses[0].AccountSkuId;
$accountServiceStatus = $Identity.Licenses[0].ServiceStatus;
$resultingCollection = @();
ForEach ($license in $accountServiceStatus){
$resultingCollection += Set-Entry -UserPrincipalName $upn -Sku $accountSkuId -ServiceName $license.ServicePlan.ServiceName -PlanId $license.ServicePlan.ServicePlanId.ToString() -Status $license.ProvisioningStatus.ToString();
else {
$resultingCollection += Set-Entry -UserPrincipalName $upn -Sku "None" -ServiceName "None" -PlanId $emptyGuid -Status "None";
return $resultingCollection;
## Create custom PS object to store intermediate results
function Set-Entry {
[Parameter(Position=0, Mandatory=$true, ValueFromPipeline=$true, HelpMessage="UPN of an Azure Active Directory User")]
[Parameter(Position=1, Mandatory=$true, HelpMessage="License SKU")]
[Parameter(Position=2, Mandatory=$true, HelpMessage="License/Plan Name")]
[Parameter(Position=3, Mandatory=$true, HelpMessage="License/Plan GUID")]
[Parameter(Position=4, Mandatory=$true, HelpMessage="License provisioning status")]
$collection = New-Object System.Object;
$collection | Add-Member -Type NoteProperty -Name "UserPrincipalName" -Value $UserPrincipalName;
$collection | Add-Member -Type NoteProperty -Name "SkuId" -Value $Sku;
$collection | Add-Member -Type NoteProperty -Name "ServiceName" -Value $ServiceName;
$collection | Add-Member -Type NoteProperty -Name "ServicePlanId" -Value $PlanId;
$collection | Add-Member -Type NoteProperty -Name "ProvisioningStatus" -Value $Status;
return $collection;
## Getting MSOL User Account
## TODO: Modify scope of accounts to fit your needs
$msolUsers = Get-MsolUser -All | where {$_.isLicensed -eq "True"}
Write-Host ("Found accounts: {0}" -f $msolUsers.Count);
foreach ($msolUser in $msolUsers)
$userCollection += Get-MsolUserLicense -Identity $msolUser;
## Convert intermidiate results into CSV
ForEach ($entry in $userCollection)
$payload += [System.String]::Format("{0},{1},{2},{3},{4}`n`r", $entry.UserPrincipalName, $entry.SkuId, $entry.ServiceName, $entry.ServicePlanId, $entry.ProvisioningStatus);
Out-File $payload;

Federated Authentication Illustrated: The story of an unwise foreign tourist


In an attempt to illustrate how federation relationship between Office 365 and on-premise directory  works, I wanted to put together a “real-life” story that doesn’t involve any IT terminilogy. Let us follow this analogy to explain what is happening during the federated authentication process. At the end of each chapter, I will add a “translation” section that will convert this vaudeville into IT language. So here it goes:

Story of an unwise foreign tourist

Narrator: It was a dark and stormy night. The place was Moscow, Russia. The Universe was… alternative…


Narrator: In a smoky Moscow bar, one man whose name was Dmitry, has just heard of a place full of marvel. That place was Little Rock, AR. Without any hesitation, Dmitry decided to fly to distant Little Rock, to see it for himself. Little did he know that he was about to embark on a worldwide journey.


User typed in his/her browser (alternativly to skip next chapter user could have typed to perform realm-discovery and avoid typing user-name twice)

Knocking at the door

– Knock Knock…

– Who’s there?

It’s Dmitry; he has arrived to the Little Rock airport. To no surprise to us, and to his complete amazement, The Port Authority of Little Rock has told him that he needs to authenticate himself. Being part of the United States, Arkansas does not issue its own passports or visas, instead they would recognize only one form of authentication, from the United States Immigration Services… commonly  known as a visa. Port Authority folks were polite about it (mind you, we ARE in an alternative universe here) and they gave Dmitry the address and directions to the centralized US Border Control office. They also told him to return to Little Rock when his papers are in order.


Since is only accepting authentication from the Office 365 authority, has redirected our user to the Office 365 login page, as it could not authenticate him/her.


Foreign Authority

Narrator: We should note that most foreign countries in our alternative universe have their difficulties with trusting each other. Borders are guarded vigorously. Bureaucracy is erected to protect them. Russia and The United States, in this case, are not an exception. However, both do recognize the fact that their citizens do need to visit the bordering country from time to time. Therefore, they have signed an agreement. That agreement defined that Russian citizens can use Russian-issued passports to identify themselves at the US Border Control office. Each issued passport shall have a unique citizen identifier, and a unique citizen name. The US Border Control shall send all Russian citizens without passports back to the predefined address in Russia.

Dmitry: I am Dmitry from Russia. Here is the paper from Little Rock folks telling me to come here.

US Border Control: Your Russian passport, please.

Dmitry: I don’t have one

US Border Control: According to our agreement with Russia, you must fly back and ask for your passport there. Here is the address in Russia you must visit. Return when you have your passport. Good-bye.


By virtue of the user typing his/her login (RegEx looking at the “right side” from the @ sign of user name OR looking at the URL header such as<%FederatedNamespace%>) Office 365 discovered that the requestor is from a federated namespace, and therefore Office 365 doesn’t have the user’s credentials. It must redirect the user’s browser to a known/predefined on-premise Security Token Service end-point, which will authenticate the user and issue a predefined ticket containing an immutable ID (the unique citizen identifier in the story) and UPN (unique name in the story).

I am who I am! Aren’t I?

Narrator: Dmitry’s flew back to Russia and arrived at the local passport agency office as directed by the US Border control.

Dmitry: I have been sent by the US Border Control office, telling me that I need a passport. Can I have one, please?

Russian Passport Agency: That’s great! Who are you, exactly?

Dmitry: I am Dmitry. Here is my birth certificate. It plainly says that I am Dmitry.

Russian Passport Agency: We have verified your claim with our back-end registry. You are who you say you are. Here’s your passport, we have stamped your federal ID number and your unique name into it. Go back to the US.


The user has landed on the on-premises federation-server user-authentication page (The “Russian Passport Agency” in this story) and has entered his credentials. NOTE: The ADFS will accept the user’s sAMAccountName (the birth certificate in this story) and the password combination OR user’s UPN and the password combination. Once the user is authenticated, ADFS issues a token containing the user’s UPN and unique identifier (default unique identifier is AD GUID in base64 encoded string). It is important to stress and understand that UPN value is not required by the ADFS’s login-page/dialog box to actually authenticate the on-prem user, however it is required to be enclosed into the issued claim that is sent back to a requesting federated party (Office 365 in this case). Once again, the user can actually authenticate with sAMAccountName, yet his/her UPN value will be sent back to Office 365 instead of sAMAccountName as defined during ADFS configuration.


Take Two

Narrator: Armed with a newly minted Russian passport, Dmitry arrives at the US Border Control (again).

Dmitry: I am Dmitry from Russia. Here is the paper from the Little Rock folks telling me to come here for a visa

US Border Control: Your Russian passport, please

Dmitry: Here it is, shiny and new.

US Border Control: Your documents are good. Welcome. Here’s your visa. Now you can fly to Little Rock


Now that user’s browser contains a valid token, the user can be authorized to access Office 365 resources, and therefore redirected yet again to his/her destination with a resource token consumable by Office 365 resources, such as Exchange Online, Lync and SharePoint/SkyDrive Pro.

Final Approach:

Narrator: Armed with his US visa, Dmitry arrives back in Little Rock.

Dmitry: I demand to see Little Rock

Port Authority of Little Rock: Do you have a visa?

Dmitry: Here’s the US Border Control issued visa.

Port of Authority: Excellent! Welcome!


By having a resource token, the user can access target federated resource; in our case it is Exchange Online mailbox.


Although Dmitry’s journey was not straightforward, he arrived at his final destination with the help of a well-defined sequence described by protocols and agreements. If only he would have been smarter, and knew the process he had to follow, he might have saved some time for himself, but that is another chapter for a later time.


The described “choreography” pertains only to the “Passive Requestor Profile” that is primarily used by web-browsers. Rich clients such as Outlook, and clients such as mobile devices, employing ActiveSync, are using other types of profiles (active requestor profile); while Lync is using Metadata Exchange (MEX) protocol. Both of these methods are a little “smarter” than the passive requestor profile sequence and therefore allow for a richer user experience and consequently more features.

Office 365 Road Warrior’s guide to quick and dirty ADFS web-auth page customization

Beautiful it is not, the out-of-the-box ADFS logon page that is. Unless you are late 90s minimalist and don’t care for any kind of web adornments. (I am thinking of an example of white background page with minimum number of controls… Hmm)
Anyhow, every time I am deploying ADFS to authenticate to Office 365 I am being ask to tweak a few things. This posting, is an abridged collection of webpage quick “tweaks” that I’ve accumulated throughout last couple of years. I want to note that this is by no means “pretty” looking tweaks. I don’t go for pretty here. The key words here are: quick and useful. You should talk with your web-designer to get yourself fabulously looking ADFS logon page; However if you are looking for quick and dirty tricks you can deploy in a few minutes without signing SOW, keep reading.


This collection of “beatifications” will satisfy few common requests that I’ve heard from many system admins. Let’s start with obvious and easiest one:

Adding Logo to your ADFS SignIn page:

This is the most basic and most common of all requests. To brand your page with company logo, you will need to:
Place your logo image file (jpg, png or gif) into the root of the ADFS web-site [by default] C:\inetpub\adfs\ls\ In the web.config file (located in the same location) remove comments (like htis one: <!--) around and modify the file name referenced in the web.config to reflect name of your logo file

<add key=”logo” value=”logo.png” />

While you are in the web.config file

Adding legal disclaimer:

Take a look at the legal disclaimer section of the web.config. Uncommenting that section will provide you with out-of-the-box functionality requiring users to acknowledge terms of use/legal agreement before proceeding with authentication.

Removing <%EndPointName%> URL from from SignIn page:

Your published federation end-point might not be something you would like to expose to your end-users. might look cool to a system admin, but it will likely to confuse your end-user and could complicate troubleshooting for your helpdesk folks. To remove that URL “label” form your ADFS logon page you’ll need to do following:
We’ll be modifying master.cs page to comment out line STSLabel.Text = FriendlyName;

This is how it should look like:

using System;
using System.Web.UI;

public partial class MyMasterPage : Microsoft.IdentityServer.Web.UI.MasterPage
protected void Page_Load( object sender, EventArgs e )
PageTitleLabel.Text = Page.Title;
//STSLabel.Text = FriendlyName;

Adding server name:

While installing multiple ADFS nodes/proxy servers behind network load-balancers you might want to display name of the server user is currently connected to. It might not be important to the end-user, but might help you with troubleshooting effort.

in FormsSignIs.aspx :
Insert following above this line </asp:Content>:

<asp:Label Text="DisplayYourServerNameHere" runat="server" />

Don’t forget to do IISRESET after your changes are done

Changing Log-Out “landing” page experience

As a result of federation authentication redirection “ping-pong” your users will land onto default Office 365 login page after they have click log-off button. The reason for it is pretty simple:
a) User askes to log-off in the UI of Office 365
b) O365 knows that user is coming from federated environment and redirects user to the on-prem ADFS server to process that request
c) You on-prem ADFS server receives the request and knows that it came from the Office 365 federated partner. It processes user request to log-off and
d) Faithfully forwarding user back to the originator of the request – the office365
e) Since user is no longer authenticated or technically “known” to Office 365, it present user with default login page in attemt to authenticate him/her
It’s hard to dispute machine logic here, yet in some cases this is not desirable behavior, especially if you are trying to create “walled” experience for your users, such as promoting use of the web-portal(s) to login/access your Office 365 resources, or communicating specific redirection URLs to your user community. Therefore to modify default log-out behavior I’ve came up with this tweak:

a) Locate your default OOTB ADFS sing-out page (default location should be: C:\inetpub\adfs\ls\SignOut.aspx)
b) Edit it with your favorite text editor and insert following JaveScript snippet right above/before the closing tag </asp:Content>. (Which is at the very end of the document) Don’t forget to actually insert your URL into the script

<script type="text/javascript">
window.location = 'http://YourLandingPage';web

c) In command-prompt run IISRESET

JavaScript is very touchy about quotes, single quotes, spaces etc. Cut/Paste from this page might come through with HTML artifacts. Verify your text before inserting into your logout page, and (of course) keep a backup of your original page version.

Modifying “hint” label [domain\username] next to the textbox user name textbox

I have wrote an article explaining the UPN vs. email story. This is somewhat extending on previous story and show you how to change default label on ADFS logon page prompting user to login with UPN. Note that this “tweak” is targeting English language page. Being politically correct and properly written web-site, the default landing page for ADFS is coming with dozens of localizations. Please locate corresponding language resource to make change for every language you wish to support.

In <%drive%>:\inetpub\adfs\ls\App_GlobalResources\CommonResources.en.resx

locate following line:

<data name="UsernameExample" xml:space="preserve">

Note: Do not make a copy/backup of *.resx file into the same folder. If you need to make a copy of original file, move it outside of \App_GlobalResources folder

Happy tweaking!

Permanently deleting Office 365 accounts from the Recycle Bin

After long pause in my posts, I want to return with this simple Office 365 script I found to be useful.

Since introduction of soft-delete functionality the “Microsoft Online Services Module for Windows PowerShell” was updated with new switch. Namely –RemoveFromRecycleBin switch was added to Remove-MsolUser cmdlet.

Soft-delete is a great failsafe feature allowing an administrator some time to reconcile accidental deletes. Let’s say you’ve accidently deleted or moved out of Dirsync’s scope AD user; your best friend DirSync faithfully synchronized your change (delete) into the office 365. Shortly thereafter, your favorite user calls you and reports that his mailbox is no longer there. Oops! Good news is that you can restore the account and move on to your next cup of coffee.

However, while you are testing and setting things up, soft-delete can be a little bit of an annoyance. When you really really want to kill those test accounts and recreate them again (and again). Or whatever the reason is, but you want those accounts gone for good. DirSync will NOT help you there, all deletes form current version of DirSync are “soft-deletes” therefore you have to connect with Powershell and remove your deleted accounts from the recycle bin. When you are dealing with more than handful of those deletes, you will probably want to have some automation to the process, unless you are enjoying typing too much.

I want to add this EXPLICIT DISCLAIMER to the post:
Neither the author of this script and article nor his employer, are responsible for any action(s), operation(s) or consequences of those action(s) and/or operation(s) or any loss of data, productivity, profits or other kind of  event(s). By using it you are taking full responsibility for whatever this script is about to do with your data, and all consequences of those modification. After all, we are talking about killing perfectly good user account. Please think twice before just running this script.
Thank you!


. © 2011-2012 Dmitry Kazantsev, Microsoft. All rights reserved.
. This sample script is not supported under any Microsoft standard support
. program or service. The sample scripts are provided AS IS without warranty of
. any kind. Microsoft disclaims all implied warranties including, without
. limitation, any implied warranties of merchantability or of fitness for a
. particular purpose. The entire risk arising out of the use or performance of
. the sample scripts and documentation remains with you. In no event shall
. Microsoft, its authors, or anyone else involved in the creation, production,
. or delivery of the scripts be liable for any damages whatsoever (including,
. without limitation, damages for loss of business profits, business
. interruption, loss of business information, or other pecuniary loss) arising
. out of the use of or inability to use the sample scripts or documentation,
. even if Microsoft has been advised of the possibility of such damages.

Import-Module MSOnline;
Write-Host ("Collecting admin credential");
$cred = Get-Credential;

Write-Host ("Connecting to your Office 365 tenent");
Connect-MsolService -Credential $cred;

Write-Host ("Enumerating users in the Recycle Bin");
$users = Get-MsolUser -ReturnDeletedUsers -All;

Write-Host ("Total number of accounts found: " + $users.Count);
[int]$index = 1;
[System.String]$message = "You are permanently deleting " + $users.Count + " user(s). Do you want to proceed? [Y] or [N]";
$responce = Read-Host -Prompt $message;

if ([System.String]::Equals("Y", $responce, [System.StringComparison]::OrdinalIgnoreCase))
Write-Host ("License to kill has been granted...")
foreach ($user in $users)
Write-Host ("Removing user " + $index + " of " + $users.Count + " | with UPN:'" + $user.UserPrincipalName + "' from the Recycle Bin");
# TODO: You will need to uncomment following line, to confirm that that you are dead-certain about killing all those innocent user accounts
#Remove-MsolUser –RemoveFromRecycleBin –UserPrincipalName $user.UserPrincipalName -Force -Verbose;
Write-Host ("Ufff... I thought that you were kidding");

Once again. Dont hurt yourself accidently.

TEC 2012 in San Diego, CA

I am heading to San Diego to present on Quest’s annual “The Expects Conference” 2012 (TEC 1212). I’ll be speaking about deployments of Office 365 in large enterprises this Tuesday, May 1, 2012.

I’ll dedicate entire hour to “notes from the field” topics about Office 365 architectural and deployment details that large customers likely to touch. Thanks to very early exposure form inside of Microsoft to the BPOS, Live@edu and Office 365 I’ve collected plenty of experiences that I’ll be sharing with public. I hope that my firsthand “field” exposure to Office 365 deployments for the last couple of years will help you down the road.

Looking forward to see few of my readers in person!

Dude, what is my UPN… or wait… is it an email address?

On several several several occasions I have been asked by confused customers about UPN renames and email address changes during initial Office 365 ADFS farm setup and directory clean-up effort. Today’s question produced a little story, which I wanted to share in attempt to demystify email and UPN correlation when ADFS is in the mix

Let’s start with defining constants

User Principal Name (UPN) is a single-value attribute [in AD attribute name is ‘userPrincipalName’] and to confuse you even further in ADUC UI is it not presented as a single-field attribute, but rather split into two parts with a drop-down to select the ‘right’ part, which is your AD domain name and possible additional suffixes, and string value that you can enter manually on the left. ADUC often “suggests” to use value of sAMAccountName that is listed in ADUC UI as “pre-Windows 2000 logon name”, yet you are free to type whatever you wish to type or leave that field/attribute blank all together.

Proxy Addresses is a multi-valued attribute [AD attribute name is ‘proxyAddresses’] . It is an extended attribute, which you will only have if you have extended AD schema while installing Exchange Server. Some version of ADUC UI can display it, some can’t, however it’s easy enough to use PowerShell or ADSI editor to see/edit the value of that and other attributes. Of course, you also have an option to use Exchange 2007/2010 console, which exposes many Exchange-related attributes as well.

that proxyAddresses attribute contain more than just SMTP addresses and that formatting (including capitalization) is important for values of that attribute. For example capitalized prefix 'SMTP:' signifies that address is “primary”, and non-capitalize value 'smtp:' signifies that address is an additional address. You can only have one primary address, and as many secondary addresses as you wish. Since it is an Exchange attribute, Exchange Management Console is taking care of uniqueness verification when you set values for that attribute with the console. However, if and when you will modify that attribute directly in AD (outside of Exchange Management Console) you will need to ensure that uniqueness and formatting of that attribute is preserved. Failure to do so will likely to result in NDRs. Active Directory by itself will be happy to accept any values to store in the attribute, since it defined simply as multi-valued string. In other words, AD will not save you from being negligent.

Confusion of those attributes (along with ‘mail‘, ‘targetAddress‘ and sometimes mail alias aka ‘mailNickName‘ and ‘sAMAccountName‘) is relatively common occurrence, as the value of those attributes is often (but not necessarily) the same

UPN and Office 365 Federation

Organizations need to update their user’s UPN to be publicly “routable” in order to establish federated partnership with Office 365. There is no “adding” of a secondary value possible, since userPrinciplaName is a single-value attribute [attribute definition].

Simple PowerShell script can replace user’s UPNs in a few minutes, if/when desired.


Some of your existing applications could use UPN to tie-in to a user account in AD, which is a theoretical possibility; therefore changing UPN _could_ break that/those application(s), and therefore you should perform some analysis/testing of internal infrastructure to see whether UPN rename will work with all of your key applications without re-configuration of dependencies. If no dependencies identified the rename of UPN is fast and easy operation to perform. Quick Bing search will provide you with more PowerShell scripts on your hands that than you care to have. 🙂

Proxy Addresses

Aforementioned “ProxyAddresses” attribute could come into play if and when old UPN value was ALSO one of the routable email addresses. That is where confusion most often occurs.


Bear with me, since it is a long story:

  • Let’s say that I am working for Contoso where my UPN is AND my primary email address is also happens to have the value of
  • At one fine day Contoso was purchased by Fabrikam (my heart goes out for those laid-off Contoso employees) and Fabrikam’s IT decided to go to the cloud and got themselves an Office 365 with ADFS deal
  • To “normalize” their joined AD infrastructure they’ve added” as one of the available suffixes to an existing Contoso’s AD and now they want to rename every account in Contoso’s AD to have UPN suffix So they performed the actual rename of existing UPNs with the PowerShell script…
  • The Fabrikam’s half of the company needs no change – they will likely to have their UPN and their primary SMTP match. It will look something like
  • The ex-Contoso half is not so lucky. I have my UPN renamed from to however my primary SMTP remained to be
  • Technically, there is nothing wrong with that scenario. As an ex-Contoso employee I still can login into my mailbox with my UPN; It just so happened that UPN value is _formatted_ the same way as an email address value; it doesn’t have to be equal to my email address. In fact, by itself UPN have nothing to do with my email at all. Yet, I have to use it to login into my new Office 365 mailbox via ADFS. Will I be confused about it? You bet! I’ll be screaming at those IT people who can’t stop changing things on me. Damn you IT department, why can’t you leave me alone?
  • So, naturally, Fabrikam’s IT will want to rename my ex-Contoso employee primary SMTPs to match to my new Fabrikam UPN value. Therefore my mailbox will become; Generally IT folks will provide an explanation like “you will be logging-in into Office 365 mailbox with your email address” which technically is a complete lie, since users are logging-in with their UPN value which just happen to be the same as their primary SMTP address/email.
  • Now we have arrived to “adding a value” part of the story:
  • Since I was giving my Contoso business cards to every person I’ve met at every cocktail party for the last 20 years with my email address being, this unfortunate acquisition by Fabrikam and consequential rename of my login information (UPN) to something else besides my old email address value, just so I can remember how to login into the new system… yes, all that jumbo-mambo IT folks was trying to explain to me — is simply not gonna work for me. I can’t afford to lose all those contacts and future invites to cocktail parties, nor you can expect me to remember how to login into this new cloud thing. Not after the cocktail party, anyways…
  • So I’ll be demanding that Fabrikam’s IT do something about incoming messages to my existing email address. Since they have renamed my primary SMTP to be, all new outgoing emails will be seen as “from” that address, however they [The IT folks]will need to add my ‘‘ email address as a secondary smtp: address into the proxyAddresses collection. By saving my old email address into proxyAddresses they will preserve routablity. That will allow me to continue to drop my old business cards with my old email address into those jars in the hotel lobbies with hopes to win an exuberant amount of points and have an awesome vacation somewhere where I don’t need to login into email account at all. Problem solved.

I hope that make some sense

Office 365 DirSync appliance is now supporting x64 architecture

Quick update: Office 365 DirSync appliance is now supporting x64 architecture

Live@edu has grown 100% year over year and topped 22M user mark!

I wanted to re-share exciting news on my blog. Live@edu has grown 100% year over year and topped 22M user mark!

Disabling Forwarding for an Outlook Live domain and Removing Forwarding Options from the OWA

Note: Good friend and colleague of mine Jim Muir wrote an article on how to disable forwarding in Live@edu. I’ve volunteered to re-publish it, so all credits for this content are going to Jim!

User Driven Options

Users can create inbox rules to automatically forward messages to e-mail addresses
outside an organization. Depending on an customer’s policies, they may choose
to prevent the forwarding of all such messages or to prevent the delivery of a
subset of auto-forwarded messages.

Administrator Driven Options

Disabling Forwarding for an Outlook Live domain

To accomplish this, IT Admins must first disable forwarding in the domain using Powershell. For instructions to install Powershell and connect it to the Outlook Live service, follow the online
Once connected, use the -AutoForwardEnabled parameter which controls automatic message forwarding to remote domains.

Set-RemoteDomain Default -AutoForwardEnabled $false

If a rollback is required, use the same Powershell command with the parameter for –AutoForwardEnabled to $true.

Removing Forwarding Options from the OWA UI

There are three locations in the OWA UI that pertain to forwarding e-mail.

The first location

for forwarding appears in the OWA UI in the account section under the section called Shortcuts to other things you can do as shown here:

The second location

is within the “My Account” options page. When a user clicks on the “Forward your e-mail” link, the “My Account” options appear with the Forwarding section enabled. In the Forwarding section, there is a field to enter the address to forward the e-mail to and a tick box to enable a user to keep a copy of the forwarded message in the Outlook Web App.

The third location

appears as in the Organize E-Mail section when a user clicks the New drop down menu and selects the option Create a new rule for arriving messages which creates a new inbox rule. In the New Inbox Rule window, an option appears for Redirect the message to…

In order to remove these options from the user interface, IT Admins need to use Windows Powershell. IT Admins should remove the forwarding options from all three locations. If an IT admin wishes to turn off forwarding for all users in their domain, they should edit the DefaultMailboxPlan policy. If an IT admin wishes to apply this role to a small number of users, they will need to explicitly create a role assignment policy instead of using the default assignment policy.

In the example provided below, the default mailbox plan policy is used to turn off the forwarding features for all users. Assuming that the IT admin is connected to the service with Windows Powershell , follow these instructions:

  1. Create a new custom role name and base it off the default mailbox plan
    New-ManagementRole -Parent MyBaseOptions_DefaultMailboxPlan -Name
  2. Remove the DeliverToMailboxAndForward, ForwardingAddress and ForwardingSmtpAddress parameters from the mailboxes for the role Set-ManagementRoleEntry \Set-Mailbox -Parameters DeliverToMailboxAndForward,ForwardingAddress,ForwardingSmtpAddress –RemoveParameter
    NOTE: Outlook Live administrators have additional RBAC roles assigned. If you need to turn off the forwarding feature for an administrator account, you will need to clean up the DeliverToMailboxAndForward, ForwardingAddress and ForwardingSmtpAddress parameters for each role assignment.
  3. Remove the ForwardAsAttachementTo, ForwardTo and RedirectTo parameters from the inbox rules for the role
    Set-ManagementRoleEntry \New-InboxRule -Parameters ForwardAsAttachmentTo,ForwardTo,RedirectTo –RemoveParameter
    NOTE: Removing the ForwardAsAttachementTo, ForwardTo and RedirectTo parameters from the inbox rules also removes the option to set an inbox rule to forward the message as a text message.
  4. Assign the role to the default mailbox plan policy
    New-ManagementRoleAssignment -Policy RoleAssignmentPolicy-DefaultMailboxPlan -Role
  5. Remove the previous management role assignment
    Remove-ManagementRoleAssignment MyBaseOptions_DefaultMailboxPlan-RoleAssignmentPolicy-DefaultMail
  6. The administrator is asked to confirm the removal. Type Y to remove.

Once confirmed

the OWA UI will not display the forwarding options in the three locations outlined above

  1. My Account user interface
  2. Connected Accounts user interface
  3. New Inbox Rule interface

If a rollback is required, use the same PowerShell commands but instead of using the -RemoveParameter switch, use –AddParameter.