Archive for the ‘ Exchange ’ Category

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.

Note
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.

Note:

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.

Example

Bear with me, since it is a long story:

  • Let’s say that I am working for Contoso where my UPN is dmitry@contoso.com AND my primary email address is also happens to have the value of dmitry@contoso.com
  • 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 @fabrikam.com” 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 @fabrikam.com. 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 username@fabrikam.com
  • The ex-Contoso half is not so lucky. I have my UPN renamed from dmitry@contoso.com to dmitry@fabrikam.com however my primary SMTP remained to be dmitry@contoso.com
  • Technically, there is nothing wrong with that scenario. As an ex-Contoso employee I still can login into my dmitry@contoso.com mailbox with my dmitry@fabrikam.com 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 dmitry@fabrikam.com; 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 dmitry@contoso.com, 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 dmitry@contoso.com email address. Since they have renamed my primary SMTP to be dmitry@fabrikam.com, all new outgoing emails will be seen as “from” that address, however they [The IT folks]will need to add my ‘dmitry@contoso.com‘ 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

Advertisements

Archiving Exchange Mailboxes to .PST files

Update:

Rather than deleting this old entry, I wanted to update it with a simple link to “Microsoft Exchange PST Capture 2.0”: http://aka.ms/pstcapture2

It might help more than an original technique described below

PST files

Somehow I always manage to hit problems that are poorly documented and I have to spend hours of installing/re-installing software, adding features and patches… and reading posts that are somewhat relevant but not 100% covering the issue.

So my task of de jure was to assist our IT Admins to off-load user mailboxes form local Exchange server to PSF files for archiving purposes. I’ve volunteered for it thinking that – hey, what can be difficult about that. So after several hours of trying to figure out what is that I need here is definitive path that worked for me.

  • Install “Windows 7 x86” (32 bit version is important detail) [I’ve virtualized this machine]
  • Install Outlook 2010 x86 [You’ll need MAPI protocol from it… ]
  • W7 comes with PowerShell (just make sure that you have it installed/enabled)
  • Install Remote Server Administration Tools for Windows 7
    [Exchange Management tools (which we’ll install later) will need it. It is not really documented all that well or throws an obvious error that tells you – hey you are missing a pre-requisite. That would be easy… Exchange installer goes through the install verifies something and tell you that everything is fine… and shortly thereafter fails with odd error “An error occurred. The error code was 3221684226. The message was The system cannot find the file specified ” Gotta love it!)
  • Enable Active Directory Domain Services Tools (that is an Add Remove Programs\Windows Features)
  • To avoid error “The log file directory ‘C:\Program Files\Microsoft\Exchange Server\Logging\MigrationLogs’ does not exist” you need to:
    a) Create that folder AND (if you still having the error)
    b) Create a registry key HKEY_LOCAL_MACHINE\Software\Microsoft\Exchange\Exchange Migration
  • Add your admin account to “Enterprise Adminis” group and to “Exchange Organization Administrators” group
  • Now you can download and install the “Microsoft Exchange Server 2007 Management Tools (32-Bit)” You’ll need to identify your version of Exchange with currently installed SP by looking at “About” dialog box of your exchange server and then looking here: http://support.microsoft.com/kb/158530
  • Now you are ready to off-load your users into PSTs with TWO PowerShell consecutive commands
    1) Firstly you need to grant yourself right to access the mailbox to avoid this misleading error:
    Export-Mailbox : Error was found for because: Error occurred in the step: Movingmessages. Failed to copy messages to the destination mailbox store with error: MAPI or an unspecified service provider. ID no: 00000000-0000-00000000, error code: -1056749164
    To grant yourself right you’ll need to execute following cmdlet:
    Add-mailboxpermission -identity -accessrights fullaccess -user
    2) And lastly you can execute this command:
    Export-Mailbox –Identity -PSTFolderPath
    Note: Make sure that your path for your destination PSF is pre-created…

I think this pretty much documents several several hours of my life.

Happy codding