The Legacy of BPOS when you migrate to O365

Had an interesting one come over the fence the other day.

A site is migrating into Office 365 but HAD been in BPOS before they started the migration process.  They were having problems with their conference rooms.

Conference rooms and resources were validating fine but no data was coming into the calendars for them.

Why should this be, we wondered?

Turns out it was an artifact of their BPOS installation.

They had the rooms set up in BPOS previously and had deleted them.  However, creating what they thought were new rooms (just with the old names) resulted in SMTP addresses like:

G9c5........a5962b@company.com

instead of 

Room_101@company.com

The alternate names were validating but email was being lost in the bowels of hosted Exchange when we tried to actually insert (remember our main recommendations: test, test, test). 

The first time when they created the rooms with the OWA user console (log in and go to Options > See all options > Manage my organization > Mailboxes). Rooms created this way using the same name values that were previously used in BPOS (say Room_101), would have  the email SMTP value assigned as Room_101@company.com and the UPN as the secondary.  BUT when you checked the same account name in the Admin console, only the UPN would be present. 

To make a migration work in this situation you have to give the rooms a NEW unique name that was never used for the SMTP address to be assigned as the primary for users to see the calendars.  In setting up your MM_Exchange_User_Map for these resources, copy the UPN name assigned as the account name and use that SMTP address.  You still have the hellacious hexadecimal as a UPN, but the method will work.


Worked like a champ.

And remember to use the UPN when setting defaults for rooms prior to migrating.  I.e., you want to NOT enforce a horizon and you want to allow conflicts.  Example:


PS C:\Windows\system32> Set-CalendarProcessing 
     -Identity  G9c5........a5962b@company.com
     -AutomateProcessing None
     -EnforceSchedulingHorizon $false
     -AllowConflicts $true



And to see what your settings are:

PS C:\Windows\system32> Get-CalendarProcessing
     -Identity   G9c5........a5962b@company.com  | fl


RunspaceId                          : 304a36b7-NNNNNNNNNNN
AutomateProcessing                  : None
AllowConflicts                      : True
BookingWindowInDays                 : 180
MaximumDurationInMinutes            : 1440
AllowRecurringMeetings              : True
EnforceSchedulingHorizon            : False
ScheduleOnlyDuringWorkHours         : False
ConflictPercentageAllowed           : 0
MaximumConflictInstances            : 0
ForwardRequestsToDelegates          : True
DeleteAttachments                   : True
DeleteComments                      : True
RemovePrivateProperty               : True
DeleteSubject                       : True
AddOrganizerToSubject               : True
DeleteNonCalendarItems              : True
TentativePendingApproval            : True
EnableResponseDetails               : True
OrganizerInfo                       : True
ResourceDelegates                   : {}
RequestOutOfPolicy                  : {}
AllRequestOutOfPolicy               : False
BookInPolicy                        : {}
AllBookInPolicy                     : True
RequestInPolicy                     : {}
AllRequestInPolicy                  : False
AddAdditionalResponse               : False
AdditionalResponse                  :
RemoveOldMeetingMessages            : True
AddNewRequestsTentatively           : True
ProcessExternalMeetingMessages      : False
RemoveForwardedMeetingNotifications : False
MailboxOwnerId                      : _4th Floor
Identity                            : _4th Floor
IsValid                             : True

As always, this is why we stress testing early and often.

Train hard -- fight easy.