Once an MCM always an MCM

I received the following email last night from the Advanced Certification group.  This saddens me in more ways than I can say.



We are contacting you to let you know we are making a change to the Microsoft Certified Master, Microsoft Certified Solutions Master, and Microsoft Certified Architect certifications. As technology changes so do Microsoft certifications and as such, we are continuing to evolve the Microsoft certification program. Microsoft will no longer offer Masters and Architect level training rotations and will be retiring the Masters level certification exams as of October 1, 2013. The IT industry is changing rapidly and we will continue to evaluate the certification and training needs of the industry to determine if there’s a different certification needed for the pinnacle of our program.

As a Microsoft Certified Master, Microsoft Certified Solutions Master, or Microsoft Certified Architect, you have earned one of the highest certifications available through the Microsoft Certification program. Although individuals will no longer be able to earn these certifications, you will continue to hold the credential and you will not be required to recertify your credential in the future. You will continue to have access to the logos through the MCP site, and your certifications will continue to show in the appropriate section of your transcript, according to Microsoft technology retirement dates. If you are a Charter Member, you will continue to hold the Charter Member designation on your transcript.

Also as a Microsoft Certified Master, Microsoft Certified Solutions Master, or Microsoft Certified Architect, you are a member of an exclusive, highly technical community and you’ve told us this community is one of the biggest benefits of your certification. We encourage you to stay connected with your peers through the main community distribution lists. Although we won’t be adding more people to this community, you continue to be a valued member of it. Over time, Microsoft plans to transition the distribution lists to the community, and, with your consent, will include your information so that it can continue to be a valuable resource for your ongoing technical discussions.

Within the coming weeks, you will receive invitations to an updated community site. This community site will require you to sign in with a Microsoft Account and will replace the need for a Microsoft Partner account as is required today. From this site, you will be able to manage service requests for the Masters and Architects communities – such as ordering welcome kits and managing your contact information for the distribution lists and directory – and accessing training rotation and other community content (if applicable).

If you have not ordered your Welcome Kit, the last day to do so is October 31, 2013. To order your Welcome Kit, please contact the Advanced Cert team at advcert@microsoft.com.

We thank you for your commitment to Microsoft technologies.

Respectfully,

Shelby Grieve

Director, Certification Product Management
Developer & Platform Evangelism


I have invested countless hours and untold effort into Microsoft certifications for my career.  It is very disheartening to see Microsoft discontinue this level of certification.



There are a lot of really smart folks out there with MCSE certifications, which is now the “top tier” certification available.  But there are also a lot of “paper” MCSEs who gained their certifications using “brain dumps”.  Those folks are easily weeded out when the rubber hits the road, but they still cheapen the certification.



One of the most important aspects of the MCM certification program is that we spent three weeks in Redmond training directly with the product group, 7 days a week, 12-20 hours a day.  This was followed by a grueling 3 hour written exam and an 8 hour qualification lab.  Even after all that training, the pass rate was less than 30%.



I will miss not having the opportunity to upgrade in the future, but at least we still have contact info for each other and we still have access to each other through the MCM DL.



And I can still say I’m a Microsoft Certified Master.


How to Share Free/Busy Information Without Using Federated Delegation

If you have a two-way forest trust in place between two organizations, such as during a merger, you can share calendar free/busy information between two Exchange organizations without having to configure federated delegation.



Federated delegation is usually the way to go since it offers more than just free/busy sharing.  With federation using the Microsoft Federated Gateway Server service you can share limited details between business partners.  In addition to free/busy information you can share meeting subjects, attendee, and location information.



Federated delegation works by brokering a trust between two different SMTP domains. The following diagram shows how this brokered trust works between contoso.com and fabrikam.com:



Federated delegation between contoso.com and fabrikam.com

To see more information about federated delegation see my articles, How to Configure Exchange 2010 SP1 Federation and Exchange Federated Free/Busy doesn’t work in one direction.



Because federated delegation relies on different SMTP domains, it won’t work during a merger/migration where both companies share the same SMTP domain (contoso.com).  The answer is to use the Add-AvailabilityAddressSpace cmdlet in both orgs.  



Be aware that the TechNet documentation for the Add-AvailabilityAddressSpace cmdlet is inaccurate/incomplete. It says this cmdlet is only supported on Exchange 2010 SP2 and Exchange 2010 SP3 when it’s actually supported on all versions of Exchange 2007 through Exchange 2013.  It also misses some crucial steps, which I’ve added below.



Here’s how to configure simple free/busy sharing information when both orgs share the same SMTP domain. For the examples below, the source domain is the one retrieving the free/busy info from the target domain. It is assumed that both domains already have a two-way forest trust configured and DNS forwarding is configured.

  • Run the following cmdlet in the target domain:
Get-ClientAccessServer | Add-AdPermission -AccessRights ExtendedRight -ExtendedRights “ms-exch-epi-token-serialization” -User “sourcedomain\Exchange Servers”

  • Run the following two cmdlets in the source domain:
Add-AvailabilityAddressSpace -ForestName targetdomain.com -AccessMethod PerUserFB -UseServiceAccount $true
Export-AutodiscoverConfig -TargetForestDomainController dc.remotedomain.com -TargetForestCredential $Target -MultipleExchangeDeployments $true


After these steps are performed the users in the source domain can see free/busy information for users in the target domain.  Repeat these steps, switching the the source and target domains, to allow bidirectional free/busy look-ups.



Be aware that the source domain relies on Autodiscover and Exchange Web Services (EWS) in the target domain.  If Autodiscover is not configured properly (i.e., missing the autodiscover.targetdomain.com record in DNS) it will not work.  It also relies on the externalUrl property of the WebServicesVirtualDirectory in the target domain.  That must be set to a valid URL and the SSL certificate used by this EWS URL must be trusted by the source domain.



Fixing Sign-On Name for Renamed Users in Office 365

When using DirSync, the user’s userPrincipalName attribute in Active Directory is used to construct the user name in Office 365. The Office 365 user will use this username to login to Office 365 for OWA, Outlook Anywhere, and ActiveSync for mobile devices, so you’ll usually want this UPN to match Active Directory.



In a recent project I performed a staged migration from Exchange 2003 to Office 365.  There were several users whose names changed over the years due to marriages.  Their pre-Windows 2000 AD logon name was changed as well to reflect their new name.  However, these dirsynced users were getting an Office 365 user name based on their old name from a non-updated userPrincipalName in AD.



For example, here’s what Mary Smith’s user account looks like in Active Directory:



UPN is unchanged from Mary Osgood



Mary has been logging in as contoso\mary.smith ever since she got married and her account was changed.  However, when DirSync was run Mary’s account in Office 365 was set to the UPN, mary.osgood@contoso.onmicrosoft.com. 






You’ll notice that you cannot change the user name field in Office 365 and the display shows, “This user is synchronized with your local Active Directory. Some details can be edited only through your local Active Directory.”



You can change the UPN in AD, but it will not update the user name in Office 365 when DirSync runs. The Office 365 username is configured once during the initial sync and will not be updated.  The only way to change it is by using Windows Azure Active Directory Module for Windows PowerShell.



Login to Windows Azure Active Directory Module for Windows PowerShell with Office 365 administrator credentials and run the following command:

Set-MsolUserPrincipalName -UserPrincipalName mary.osgood@contoso.onmicrosoft.com -NewUserPrincipalName mary.smith@contoso.com

This cmdlet will change the Office 365 user name from mary.osgood@contoso.onmicrosoft.com to mary.smith@contoso.com.  You can change the UPN to any valid domain.