Microsoft Stops Set-User Updating Phone Numbers for Azure AD Accounts

Change Made without Warning for Security Reasons

Without any warning, Microsoft seems to have introduced a restriction to the Set-User cmdlet in the Exchange Online management PowerShell module. The change happens when you connect a new PowerShell session to Exchange Online and the cmdlets are downloaded into a session.

Security Problems Updating Work or Mobile Numbers

Any attempt to update a user’s business or mobile phone numbers with Set-User now generates an error saying that for security reasons these properties cannot be updated through Exchange Online. Instead, administrators are forced to update the properties through the Azure AD admin center or by using the Azure AD PowerShell module.

Set-User -id $User -Phone "+1 454 146 1412"
Phone and Mobile Phone for users with Recipient Type Details "UserMailbox" cannot be updated in Exchange Online for security reason. Please do it in Azure Active Directory.
    + CategoryInfo          : NotSpecified: (Jessica.Chen@office365itpros.com:UserIdParameter) [Set-User], ShouldNotUpdate...eInExoException
    + FullyQualifiedErrorId : [Server=AM4PR0401MB2289,RequestId=39d0dbcb-05d1-42e6-b8ea-4bc78fc58816,TimeStamp=10/05/2
   021 22:22:12] [FailureCategory=Cmdlet-ShouldNotUpdatePhoneMobilePhoneInExoException] 1D58FC00,Microsoft.Exchange.Management.RecipientTasks.SetUser
    + PSComputerName        : outlook.office365.com

Set-user -id $User -MobilePhone "+1 464 147 4433"
Phone and Mobile Phone for users with Recipient Type Details "UserMailbox" cannot be updated in Exchange Online for
security reason. Please do it in Azure Active Directory.
    + CategoryInfo          : NotSpecified: (Jessica.Chen@office365itpros.com:UserIdParameter) [Set-User], ShouldNotUpdate...eInExoException
    + FullyQualifiedErrorId : [Server=AM4PR0401MB2289,RequestId=4cffcdc2-5bc0-4d17-83bf-a4d7bb67d2a5,TimeStamp=10/05/2
   021 22:22:21] [FailureCategory=Cmdlet-ShouldNotUpdatePhoneMobilePhoneInExoException] 1D58FC00,Microsoft.Exchange.Management.RecipientTasks.SetUser
    + PSComputerName        : outlook.office365.com

Oddly, Set-User is still able to update other phone numbers such as a user’s phone or alternative number. You can also update someone’s pager number (if they still use one) and their fax number. The fax number also appears as a property for an Azure AD account, so if Microsoft decided to block the business and mobile numbers, it’s strange that they left the fax number alone.

Disruption to Scripts

Set-User has been part of Exchange PowerShell since Exchange 2007. The cmdlet is a method to update account properties stored in Active Directory and Azure Active Directory which are important to Exchange (because they appear in address lists). Changing behavior without warning is disruptive to organizations because it might impact scripts used for production purposes, such as taking a feed from a HR system and updating user accounts.

Microsoft’s error message implies that the change happened for security reasons, but as they haven’t explained any detail about why it is a security problem to allow Set-User to update phone numbers, it’s hard to assess what’s going on here. If it’s a problem for Set-User to update telephone numbers, why is it OK for Set-AzureADUser to do the same?

Set-AzureADUser -ObjectId Jessica.Chen@office365itpros.com -TelephoneNumber "+1 550 771 1314" -Mobile "+1 466 146 1453"

Roles and Permissions

Accounts need different permissions to run the two cmdlets. Accounts holding the Exchange administrator role can update mailbox properties (some of which synchronize with Azure AD) but can’t do so using Azure AD interfaces like the Azure AD PowerShell module. It could be that Microsoft wants to tighten the ability of users with workload-specific roles to update Azure AD.

Although I can’t prove this, I suspect that the tightening is at the heart of problems reported with the Set-CsUser cmdlet since the release of V2.3.0 of the Microsoft Teams PowerShell module last month (see this Microsoft Technical Community post for some details of user issues).

Communications Failure

Microsoft is much better at communicating change within Office 365 today than they used to be, notably through the Microsoft 365 roadmap and the notifications posted to the Microsoft 365 admin center. This change came out of the blue and landed without warning. People don’t like surprises and always react better if the logic behind an update is clearly explained. Everyone will get behind a change which helps to improve security – unless they find out when their scripts stop working.