In anticipation of rolling out MFA to our Office 365 users I was looking at the setup page (aka.ms/MFASetup) and I noticed that the Office Phone area was showing some of my information, but not the correct information.
Let's track that down, figure out how it works, talk about the Standards, and push a correctly formatted Office Phone to all the users
Finding the Source of mysterious Office Phone
347 is my extension in our on-premises Phone System, yes, but since we do not use Microsoft for our phones, there is no chance it will know how to reach me with just an extension.So, can we find where the "Office Phone" is connected to and do something useful with it... maybe even populate the Country Code, phone number, and extension. But we are not going to do it from here, Office 365 greys out the fields and warns about missing Country Code
After some research, I found there are numerous "phone" fields synced to Azure AD depending on your feature set and what you have enabled. You can find details here.
Exchange Online phone attributes synced. Note: Screenshot edited to remove unrelated attributes |
So, Azure AD Connect in a default configuration with Exchange Online syncs the following "phone" numbers
- Fax number + other fax numbers
- Home number + others
- "Telephone" number + others
- Telephone number for an Assistant
- Pager Number
- Mobile Number
Interestingly, there are a few "phone" fields that are left out here, but are included in other areas
- personalPager + Other pager numbers
- IPPhone + other IpPhones
Other phone attributes. Note: Screenshot edited to remove unrelated attributes |
When I pulled my information in AD, I had the IPPhone and TelephoneNumber fields populated, both with the 347.
Through some experimenting (and waiting for Synchronizations - thank goodness for Start-ADSyncSyncCycle ) I determined that the "Office Phone" is linked to telephoneNumber
That makes sense, since the -OfficePhone parameter of Set-ADUser is tied to telephoneNumber
Following the Standards
Now I had successfully set my phone number to 8288675309, but there the Country Code still wasn't populated and, as usual, there are specifications for these kind of things. There are a few standards that are recommended and widely used E.164 and E.123 from the ITU-T Standardization Sector being the most widely used, from my research.
E.164 is the The international public telecommunication numbering plan - PDF
E.123 is the Notation for national and international telephone numbers, e-mail addresses and Web addresses
In short, though E.164 defines a general format for international phone numbers and numbering, E.123 actually defines a specific format for the international number, including important things like separating the country code by a space. You might think that "Surely E.164 came after E.123 and supersedes it, 164 is higher!" but it isn't a ordinal thing. It is codified by the type of recommendation. Take a poke around this tree to see what I mean.
E.164 is the The international public telecommunication numbering plan - PDF
E.123 is the Notation for national and international telephone numbers, e-mail addresses and Web addresses
In short, though E.164 defines a general format for international phone numbers and numbering, E.123 actually defines a specific format for the international number, including important things like separating the country code by a space. You might think that "Surely E.164 came after E.123 and supersedes it, 164 is higher!" but it isn't a ordinal thing. It is codified by the type of recommendation. Take a poke around this tree to see what I mean.
In particular, it looks like Microsoft usually uses E.123, with some tweaks, mostly that you should put parentheses around the area code, so that it can be specifically determined
Now, spaces, parentheses, and dashes are ignored when dialing, so this means that E.123, E.164, and Microsoft Canonical Notation are going to be pretty much equivalent
Through my testing and waiting, all three variations shown above worked and populated the office field on aka.ms/MFASetup. I am going to follow the MS Canonical format, since it should be equivalent to the others at dial-time and provides additional information when displayed.
Phone Number Format Main Points
There are a few specifics to hit whichever format you are using.
- Start with the Country Code from E.164 - Look up your country code
- Put a space after the country code to separate the Country Code and let it get parsed
- Surround the Area Code with parentheses
- From my testing the space between Area Code and Local Phone Number isn't required
- From my testing dashes between the portion of the Local Phone Number are not required
Separate Direct-Dial numbers for each person
If you have enough Direct-Inward-Dial (DID) numbers that you can specify for each person, that can be your solution. Just apply the various DIDs for the people to that AD User and let it Sync up through Azure AD Connect. Either of the below commands will set the TelephoneNumber attribute.
Set-ADUser -Identity $username -OfficePhone "+1 (828)2451234"
Set-ADUser -Identity $username -Replace @{'telephoneNumber'="+1 (828)2451234" }
I like the second because there is no Office Phone area in the user editor of AD Users and Computers or AD Administrative Center, it's labeled Telephone Number, and that also clearly shows which attribute you are modifying.
No Direct-Dial numbers, you need to use extension
If you do not have direct dial numbers, then you will need to use extensions. Despite scouring E.123, E.164, and the articles on Microsoft Canonical Format, I could not find a definitive answer to how to delineate extensions in a phone number.
In other services I found examples like below, but none of them worked.
1234567890#123,
1234567890#ext=123,
1234567890;123,
1234567890;ext=123
1234567890 ext123
And you may have used the semicolon method before. It is a popular feature that many phones support to have the phone wait, ready to send the extension. An example shown below.
In the end I found a few formats that worked to parse the extension, keeping in mind the main points mentioned above
+1 1234567890 x 347
+1 1234567890x347
+1 (123)4567890x347
1234567890x347
1234567890 x 347The most telling was one of the failures from the above.
I put in (828)29236 ext347 and got out
The only character missing is the 'x'
From there it didn't seem to matter much whether there were spaces or dashes or parens in the Area code and Local Phone Number part. If you did not include the country code, then it will not let you use that number, at all. Stating "Country Code Required" and not letting you edit it here.
Office Numbers with Extensions
In the end, I recommend you use the format below, as it clearly delineates the Country Code, Area Code, Local Number, and the Extension. And it also pulls into the aka.ms/MFASetup cleanly.+1 (123) 4567890x347
I also checked that their side would be able to correctly dial the numbers even when it had the parens and extension, and it worked perfectly. To set the number, use one of the commands below, just like before.
Set-ADUser -Identity $username -OfficePhone "+1 (123)1234567x347"
After a bit for it to Sync up and Sync around Office 365, you should have the proper phone number showing up at aka.ms/MFASetup!Set-ADUser -Identity $username -Replace @{'telephoneNumber'="+1 (123)1234567x347"}
Where can I put my extensions?
The phone system we are looking at can provision phones and information like directories off of AD information. In preparation for that I had loaded all of the extensions into their respective users telephoneNumber field, which started this whole thing.
The Office Phone MFA field being filled is very useful, so I want to relocate the existing extension information to another property, and set the telephoneNumber to the correctly formatted number for it to be parsed. This might be useful if you had something like a user that had a direct dial number from outside, but also had an extension you could use inside the phone network.
Here is a little script that I wrote to do just that.
No comments:
Post a Comment