How to access the Microsoft Stream Admin settings

While reading up on Live events (preview) in Microsoft Stream, I noticed a mention off the Stream Admin settings.

I was not able to locate this in the Microsoft Stream web interface, so went to the Microsoft 365 Admin center instead. But no reference to Stream here either…

Turns out that the Stream Admin settings are only accessible through Stream. In order to access the Admin settings the following is required:

• Microsoft Stream license
• Global Admin or Stream admin role

The Stream admin role can be assigned in the Stream Admin settings portal, unfortunately the is no Azure AD admin role that can be delegated nor can this role be assigned through Privileged Identity Management (PIM) currently.

If you’re following security best practices and use a separate admin account for administrative tasks, this probably means that a license for Microsoft Stream needs to be assigned to your admin account as well. A Stream license is required in order to access the Stream web interface.

Any user that meets the prerequisites can now access the Admin settings through the

First thing that you want to do is delegate Stream admin permissions to either admin or regular user accounts. Any account this is listed here no longer has to be a Global Administrator.

Let’s hope that Microsoft will streamline (pun intended) the Streams admin experience and bring both access as permission requirements in line with the other Microsoft 365 workloads.

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.

Project Honolulu and Exchange servers

Recently Microsoft announced a new web-based server management console, it’s called Project Honolulu. Looking at the documentation and screenshots this is going to be a huge step forward from the native sever management consoles that we have seen from Server 2008-2016.

A technical preview of Project Honolulu is already available for download: https://aka.ms/HonoluluDownload Project Honolulu can be used to manage servers with Windows Server 2012, 2012 R2 and Server 2016. However, there is a requirement to install PowerShell v5 on those older servers. From the documentation:

Honolulu requires PowerShell features that are not included in Windows Server 2012 and 2012 R2. If you will manage Windows Server 2012 or 2012 R2 with Honolulu, you will need to install Windows Management Framework (WMF) version 5.0 or higher on those servers.

Unfortunately Microsoft does not support installing newer versions of WMF on servers that have Exchange installed. The Exchange Supportability Matrix says the following about the supported versions of WMF on servers running Exchange:

Version of Windows Management Framework built into the release of Windows Server you're installing Exchange on.

This means that installing PowerShell 5 on Server 2012 or Server 2012 R2 is not supported for servers running Exchange, effectively making it impossible to use Project Honolulu to manage Exchange servers. The only exception is Exchange 2016 running on Server 2016 because this OS was released with PowerShell v5 natively and meets the Project Honolulu requirements.

Exchange Remote PowerShell behind a proxy server

Today I ran into the following issue. I tried to open a Remote PowerShell session to Exchange Online but the module failed to load with the error message:

New-ExoPSSession : Create Powershell Session is failed using OAuth

Initially I suspected that the customer’s firewall performed some kind of traffic inspection or recognized and denied the traffic as a blocked ‘application’. I was able to browse the internet from this computer and after all Remote PowerShell is just https traffic.

However, the culprit was the proxy server. More specific, I configured a proxy server in the Internet Explorer settings but did not verify if Remote PowerShell observed the same connection settings. And the answer is no, the console does not use the IE settings but falls back to the winhttp configuration. In this environment the firewall configuration did not allow outbound traffic unless it passes through the proxy.

Telling PowerShell to use the proxy server is easy. Open an elevated prompt and use the following command to configure winhttp to use a proxy server and port:

netsh winhttp set proxy proxy.network.tld:8080

To import the settings that where configured in IE:

netsh winhttp import proxy source =ie

And important, to remove the proxy configuration for winhttp:

netsh winhttp reset proxy

Configuring the proxy for winhttp fixed my issue and I was able to connect to Exchange Online with PowerShell successfully.