Updated Connectors section in Exchange Online admin center

Update July 13th, 2008: It looks like Microsoft reverted this change for now.

“Constant change is here to stay.” Office 365 administrators may have noticed that Microsoft is revamping the Connectors area of the Exchange Admin Center. This section used to be a single list that displayed all connectors, which meant that it could be hard to identify the connector you were looking for.

The biggest visual enhancement is that this list now is split into two sections: Inbound and Outbound connectors. Inbound and outbound in this example is from the perspective of EOP. An inbound connector is created to accept email FROM a 3rd party system, an outbound connector defines how to route email TO another system.

But there’s more. New connector creation is no longer wizard-driven but uses a single form now to collect the required information. This actually makes a lot of sense. The process to create a connector is quite simple and especially with the distinction between outbound and inbound connectors, there’s not much business logic involved that would warrant a wizard to guide us through the process.

The new form is very clean and the wording for certain settings was updated to make it more clear what a feature does or what an admin can expect. See this example where the description of the setting now clearly mentions CBR and the help balloon is used for clarification.

And finally, Microsoft removed the validation of outbound connectors. Validation was a process where a test email had to be sent before saving the connector, a feature designed to prevent people from creating non-working connectors that could result in huge queues with undeliverable messages.

Validation was sometimes challenging, for instance when creating a connector that’s not ready to enable or when the admin does not have a valid recipient address available to validate against.

Even though I preferred a change notification on the Message Center, it’s certainly a good thing seeing Microsoft to invest in and improve the Exchange admin interfaces.

How to monitor a log file in real-time

Recently I was working on a task where I had to monitor the log files from a ftp server. At one point I had to find out if a certain client had downloaded a file with a specific name, or look for entries from a client with a certain IP address.

One way to do this is opening the log file with a text editor and use the search function. Unfortunately this approach is not an easy way to detect updates, and the file has to be reopened every time the content gets changed. Luckily there are better ways to do this.

One of my all-time favorite tools is Baretail. This is a GUI alternative for the Unix program tail -f that allows you to read the last part (tail) of a file and follow (-f) updates in real-time. One of the many benefits it has to offer is color coding where you can easily highlight a line that contains a string that you may be interested in.

An alternative is the PowerShell command Get-Content with the -Wait switch, which gives the exact same result as tail -f. First of all this is a native PowerShell command so it works on systems where you can’t or won’t install 3rd party software. But more important, it’s PowerShell and thus extremely flexible and extensible.

One example that I used today is this: Get-Content .\fzs-2018-05-22.log -Wait | Select-String -Pattern '10.54.64.162'

Get-Content -Wait reads the content of the file and keeps doing so when new data gets added. Select-String accepts the objects from the pipeline and the -Pattern switch selects only the lines that match the specified pattern, in this case the IP address of a client that I’m interested in.

The best thing of course, is that the output is objects so you can do anything you want with it. Select, filter, trigger a work-flow are even color coding the output on the screen. Have fun!

Microsoft Teams not working for K1/F1 users

I recently ran into an issue where some users could not access Microsoft Teams, even though a license was assigned. This only happened to users with a Microsoft Teams license from the ‘Deskless Worker’ suite, also known as the Kiosk, K1 or F1 SKU.

The reason for this is that the tenant-wide control to enable or disable Microsoft Teams by default does not include Deskless Workers. An admin has to enable Microsoft Teams for this SKU type explicitly.

The switch can be found in the Office 365 Admin Portal, navigate to Settings, Service & add-ins, Microsoft Teams. Use the drop-down list to select Deskless Worker (Kiosk) and enable the feature.

Do not forget to click the Save button to apply the updated settings.

Exchange Admin Center can’t handle duplicate display names

If you’re managing a larger organization, or even a smaller one, chances are that some of your coworkers share the same name. From an Exchange perspective this is not supposed to be an issue as the displayName attribute does is not required to be unique. End-users who try to locate the right person in their address book can look at the additional properties such as department or email address to find the correct ‘John Smith’ or ‘Pradeep Gupta’.

The Exchange Admin Center (EAC) in Exchange Online unfortunately does not handle this very well. There’s many places where an admin picks a user from the list, for instance to create a condition or exception in a mail flow rule, but where EAC uses the display name to identify the Exchange object. Which is not a problem, until there happens to be more than one object with that display name.

There are multiple recipients matching the identity "Display Name". Please specify a unique value.

In case you’re wondering, the ‘click here for help…’ link goes to a generic error landing page.

Microsoft is aware

I worked with Microsoft Premier Support on this issue and after a lot of communication (“why don’t you use a group instead of a user, put that user in a group”) we were just about to file a DCR, until we were informed that the product group is already aware of this design flaw. According to Premier Support a fix is scheduled but without an ETA.

I can only assume that this will require significate code changes so expect that this will be part of a next major redesign of the EAC. After all we have seen very little updates in this area since the last 5 years.

If you run into this issue, please work with Microsoft Support to gain more visibility on this issue. The PG needs to be aware of that this is a proper bug and every time and admin runs into this issue, it costs a lot of time and effort to work around it.

Work around

That said, there is of course a way to work around the issue. The bug is caused by the way that EAC handles the objects, but this does not apply when using PowerShell directly.

In case of creating or editing a mail flow rule the work around is to select a placeholder object with a unique display name and then edit the properties in Exchange PowerShell with Set-TransportRule.

Repro steps

If you’re interested in this bug, follow these steps to reproduce it on your own tenant:

• Create two mailboxes and a transport rule

New-Mailbox -Shared -Name displayname1 -DisplayName Shared
New-Mailbox -Shared -Name displayname2 -DisplayName Shared
New-TransportRule "test rule to reproduce issue" -SubjectContainsWords "thisneverhappens" -RejectMessageReasonText "rejected because of the following Mail Flow Rule: test rule to reproduce issue"

• Add both mailboxes as an exception to the rule

Open de Mail Flow Rule in EAC and add an exception "The sender is this person". In the people picker, select the one of the two test mailboxes and click Add, Ok. Now click Save to reproduce the error.

What about Exchange Server?

My troubleshooting was focused on Exchange Online, but I assume it’s in Exchange Server as well. Please let me know if you can confirm.

Office 365 Phone System numbers, how to convert from User to Service?

When porting numbers to Office 365 Phone System, the admin has to specify if the number should be a service number or a user number. The same applies when new numbers are requested. What’s the difference between the two number types, you may ask. The answer is easy.

A user number is assigned to a single user.

A service number is connected to a call queue, a conference bridge or an auto attendant and is capable of handling simultaneous calls.

A common issue for new Office 365 Phone System customers is where they port an entire number block as user numbers, including the organization’s main number. Soon they discover that the main number should’ve been used with a Call Queue or an Auto Attendant but those features require a the number to be configured as a service number instead.

If you’re searching for information on how to convert the number type you’ll find many outdated articles stating that this is not possible, requires opening a support incident or recommend to port the number away from Microsoft and then port it back.

The situation has now, end of February 2018, much improved. All you have to do is send an email to Microsoft’s Skype for Business Number Porting Team. They need the following information to be able to process the request:

• The number that needs to be converted
• The requested number type: user or service
• When do you want the conversion to take place?

My experience with a number that’s currently not assigned, so no downtime to communicate with the end users, is that it was converted within 30 minutes after confirming the details through email.

To start the process, simply send an email with the required information to ptn@microsoft.com for North America or ptneu@microsoft.com for Europe.

Please let me know in the comments if you’re experience was as smooth as mine.

Disable voicemail on a Skype meeting room accounts

If you ever had to create user accounts for modern meeting room devices such as Microsoft’s Surface Hub or 3rd party devices such as the Polycom Trio 8800 you may have noticed that process is basically the same. Create a Room Mailbox with an enabled account and a password, then enable the account for Skype for Business with the Enable-CsMeetingRoom cmdlet.

Recently a coworker transferred a Skype call to a meeting room and when the person in the room wasn’t quick enough to respond, the call ended up in the conference room voicemail box. Understandably she requested us to disable voicemail on this account.

After investigation we found that Azure Voicemail was enabled when we added licenses for Office 365 Phone System and Calling Plan. Disabling voicemail is easy. Either sign-in with the username and password of the meeting room and visit the web based advanced settings: https://aka.ms/vmsettings. Then clear the checkbox for Activate Voicemail.

Alternatively an admin can disable the voicemail feature in Skype for Business Online PowerShell:

Set-CsMeetingRoom <SIP address> -HostedVoiceMail:$false

Reference:

Check Skype for Business voicemail and options

How to Set up and configure Cloud Voicemail for Skype for Business Online users

HCW does not ‘remember’ mail transport configuration

Centralized mail transport (CMT) is a hybrid mail flow scenario where all outbound email from Exchange Online is routed through on-premises servers first before sending it to the internet. It’s not really common but there are organizations with specific requirements that can be met with centralized mail transport.

As you probably know, when the HCW is run for the first time, the entered configuration is stored on the local hybrid configuration AD object. When an admin starts the HCW again, the HCW will read the configuration form the AD object and use it to pre-populate the wizard with the information that was entered previously.

Last week I was working with a customer with an Exchange 2013 CU19 environment where we built a hybrid configuration. When everyting was setup and tested I re-ran the HCW to add more email domains. In this specific instance I noticed that the checkbox for centralized mail transport was not present:

Continuing with the wizard would effectively break mail flow for this customer because the HCW would disable the centralized mail flow feature and route outbound messaged from Exchange Online to the internet directly.

First I verified the actual configuration in EOP and found that is was set up correctly:

Next I verified the information stored in the local hybrid configuration AD object and found that CentralizedTransport was listed under Features:

After opening a support incident with Microsoft Support the engineer confirmed that this behavior was ‘by design’. I won’t bother you with the argumentation because it made no sense at all. Unfortunately this customer did not have a Premier Support and there were very limited options to escalate the issue.

This is bad and I can think of at least three reasons why. First of all this feature by default is not displayed on the HCW page. The admin has to click on Advanced… for the CMT configuration to appear on the HCW page:

This means that it’s almost impossible to spot the problem. Second problem is that this behavior is simply inconsistent, it doesn’t make sense that the HCW caches all information EXCEPT thing single setting.

But third and biggest problem that I have with this issue is the impact. When discussing this with Microsoft the engineer told me that the impact is minimal because outbound email will still be delivered to the receiving mail server. This demonstrates a huge lack of understanding of why organizations choose to use CMT. Having to explain to your legal department why sent emails are missing from the archive is not a fun job.

And that’s one other problem that I have with this experience. The engineer did not investigate the HCW log files, did not agree with the fact that this is an impacting issue and an inconsistency and did not offer any escalation path. This reminded me of how difficult it can be to work with Microsoft Support if you do not have access to higher support tiers or a TAM.

I realize this is a rare scenario, but if you’re using CMT and run into the same issue, please open a service request and escalate if possible. This should be fixed.