Microsoft

MSPortals.io – A List of Microsoft Portals

I thought I should write up a little bit of information on a site I created; msportals.io and how it’s doing:

Being a Microsoft 365 Administrator at the time, I was looking for a list of all the Microsoft portals, particularly from an administrator point of view. A lot of lists were floating around, but nothing that was being maintained or comprehensive enough. I’d asked around a lot around it, others had the idea that they were going to create something – but nothing happened. It was a pretty simple idea and I was hardly the first to have it…

I also had the idea of creating this list on GitHub. I’d already been looking at GitHub Pages to move my blog to, but not being a programmer or developer, I was finding it too difficult to try and work out how to migrate and have feature parity with what I was using on WordPress. However, the GitHub Pages free tier, allowing 500mb of data in a public Github Repository sounded like a perfect fit for me, providing a platform for a list of URLs.

I started to collect and write up a list of portals. Just the name of the portal, and a link to it. I wasn’t using any GitHub client or command line things, purely using the web based interface for GitHub to start putting data in and seeing how it looked on the resulting msportals.github.io site. It seemed fine, so I started asking around for people to tell me of any links I might be missing. People jumped on board pretty quickly to help (read my thanks section here) to provide portals, but also to actually contribute to the project and provide features that would have taken me a very long time to work out myself.

I also bought a domain – msportals.xyz as it only cost a few dollars a year, and GitHub Pages supports bringing in your own domain. I had the site up, started using it.. and though I should throw it out there to see how much criticism it brought. I posted a tweet:

I didn’t expect to get much of a response – it was more of a test so I could properly launch later. Instead, as I expect what often happens on projects like this, it blew up. It turned out to be my most popular tweet of all time, with almost 100k views. My only annoyance of this was that I had no statistics to collect on how much the site was being used! Quickly I had help to add in Google Analytics to the site, so about a week later I had stats.

Since mid November 2020, the site has had 55,000 users hit it. As expected, the engagement time is tiny – you go to the site and click a link.

That peak is when The Register wrote an article on the site. The site changed from msportals.xyz to msportals.io after @SwiftOnSecurity bought it and handed it over, after some discussion around certain firewalls blocking xyz domains under some standard settings:

Updates and suggestions to the the portal of Microsoft portals came think and fast for a while – nice features like a filter so you can just type ‘teams’ and see the link to the Teams portal were implemented by others (mdjx), due to the way open source platforms like GitHub work.

I don’t see as many portal suggestions and updates these days, but they still trickle in. I still use the site frequently, and see people pop up time to time saying how much they like it which is awesome to hear; I really wanted something functional for myself, and if others also liked it, that was a bonus.

I actually had an idea for another site – a list of PowerShell modules with the commands to both install and connect to different things like Exchange Online and Microsoft Teams. Someone had beaten me to it (which is good!), and had done it a similar way; check out https://msshells.net/ by Andrés Gorzelany to have a look at what he’s done.

If you’ve got your own idea for something like this, go for it! You can do it entirely for free if you don’t care about your own top level domain, and it’s an interesting project to try.

Migrating Phone System from Skype for Business to Microsoft Teams

I thought I’d document a few lessons learned in this migration. The migration was from Skype for Business Server 2015 and Skype for Business 2016 clients with Enterprise Voice, moving users across to Microsoft Teams.


The steps to migrate a user for me were:

  1. Add user to AD Group “Azure AD Licensing Telstra Calling for Office 365” as this allocates a Telstra Calling for Office 365 license. These licenses are bought from https://marketplace.telstra.com/ and feed into Microsoft 365. I believe this is unique to Australia.
  2. From Skype for Business Server Management Shell:
    $cred=Get-Credential
    $url="https://adminau1.online.lync.com/HostedMigration/hostedmigrationService.svc" (different links here for different countries)
    Move-CsUser -Identity userupn@contoso.com –Target sipfed.online.lync.com -MoveToTeams -Credential $cred -HostedMigrationOverrideUrl $url

    set-csuser -identity userupn@contoso.com -LineURI $null
  3. Form a machine with the Teams PowerShell Module installed:
    $Session = New-CSOnlineSession -OverrideAdminDomain yourdomain.onmicrosoft.com
    Import-PSSession $session –AllowClobber
    Set-CsOnlineVoiceUser -Identity userupn@contoso.com -TelephoneNumber 61812341234
    Grant-CsTeamsUpgradePolicy -PolicyName UpgradeToTeams -Identity userupn@contoso.com
  4. Configure call forwarding in Gateway (Pilot Users only that were being given a new number out of our normal number range)

EHR Error on Teams Portal

We can’t get details of EHR usage. Please try again. If you continue to have problems, contact Microsoft customer support.

Seeing this error everywhere on the Teams Admin portal, unsure what the cause/fix is yet. It ended up disappearing by itself after a few weeks *shrug* – you’ll see this theme is common around portal errors.


Dial Plans error


We can’t get the effective dial plan so the dial plan can’t be tested.

Going into any Dial Plan brings up this admin portal error, as well as trying to run a Test Dial plan test:

Something went wrong while testing this phone number. If you continue to have problems, contact Microsoft customer support.

This problem was another portal issue – logged a case which Microsoft confirmed was at their end, and a few weeks later they’d resolved it.


Create Resource Account error

We can’t save changes to ___

When creating a Resource Account used for Auto Attendant or Call queues, I was getting a very unhelpful error. I believe this is because I’m running in hybrid mode, so Teams can’t create an account on my primary domain – changing the domain to @contoso.onmicrosoft.com then let me create the Resource Account.

This problem also disappeared later and now I can create accounts on my primary domain – put it down to another portal issue.


Desk Phones requiring PIN

Phones would be registered in Intune, because they’re running Android – and that means any ‘all user’ Android policy would apply.

I’ve since created Dynamic Device Groups and filtered by DeviceModel and DeviceOSType – only testing the Poly CCX500 at this stage, but will add more models as we get them. Also filtering by OStype which is not really necessary, but does make sure it’s only Android devices affected.

(device.deviceModel -eq "CCX500") and (device.deviceOSType -eq "Android")

If you use a test account 20 times, that account will hit its device limit in azure and get locked out.


Skype for Business users unable to call Teams users

Early in migration, we tested interoperability between the two platforms, as it wasn’t going to be an overnight company wide migration. A Skype for Business user trying to call a migrated to Teams user would instead get diverted elsewhere. This was because we had Unassigned Number range rules in place, that were designed to send calls somewhere if it wasn’t allocated to anyone. Removing these rules immediately fixed this issue.


Home Screen on Desk Phones Laggy

The default experience if the phone supports it, is to show a home screen. More details on what the Home Screen is here. This is in CsTeamsIPPhonePolicy with the default value ‘AllowHomeScreen’ set to ‘EnabledUserOverride’. Changing this to Disabled via the PowerShell command:

set-CsTeamsIPPhonePolicy -allowhomescreen Disabled

removed this. I like the idea of the Home Screen, but not at the cost of a fast functioning phone vs a slow one.

I later found out this is due to the 1GB RAM on some devices, and Teams now (at the time of writing) uses > 1GB RAM, and then the Home Screen uses even more RAM. Trying a phone model with 2GB RAM this all worked perfectly.

I believe this is also fixed now, but it took Microsoft about 5 months to resolve.


New Desk Phones not signing in

Testing the Poly CCX500 model, some wouldn’t sign in to Teams out of the box. As soon as I tried to sign in, they’d say:

‘Error Could not sign in. You will need to sign in again. If you see this message again, please contact your company support. OK’

I spent so long on this, unsuccessfully trying to update the firmware via USB etc. In the end, turning off the ‘DHCP Time’ setting under ‘Device Settings’ made it work – I assume it had some problems contacting a NTP server (settings appeared correct in the DHCP scope of the phone). Someone else found the same issue here, but this was due to the phone running a very old v1 firmware. This shouldn’t affect most people, but worth noting.


Update UPN from AD to Azure AD

When there was a name change in Active Directory (AD), we used to update the Universal Principal Name (UPN) in AD, then separately run the Set-MsolUserPrincipalName command to update Azure AD to the same UPN. Except, it no longer worked – I was now getting an ‘Access Denied’ message.

When trying to update the UPN via the Microsoft 365 admin center, it would correctly advise that the object was homed in AD, so changes needed to be made there. Except, they were, and Azure AD Connect was even reporting that it had seen the update and sent it off to Azure AD, no errors.

After some investigation, I found that there is now an option to allow ‘Synchronize userPrincipalName updates‘ which is off in older tenants. To check and update this:

In PowerShell, first install and connect to MSOLService. Then to check the status if UPN updates will sync and update:

Get-MsolDirSyncFeatures -Feature SynchronizeUpnForManagedUsers

If it’s $true, you’re already set. If it’s $false, update the value to $true with this command:

Set-MsolDirSyncFeature -Feature SynchronizeUpnForManagedUsers -Enable $true

In my testing, running another Azure AD Sync (both delta and full) did not resolve any already updated UPNs. I had to change the UPNs to a temporary value, sync, then change them back to the original value I wanted, and sync again. The update was instant in Azure AD once the sync had run each time.

SMTP to Exchange Online

SMTP is still needed by certain applications and devices, such as printers, which don’t support Modern Authentication and instead require legacy authentication to talk to a SMTP server.

You are able to use Exchange Online as an SMTP server, but this can be tricky to set up if you’ve hardened your environment by requiring Multi-factor authentication through Security Defaults or Conditional Access.

Microsoft have good documentation on “How to set up a multifunction device or application to send email using Microsoft 365 or Office 365” with the recommended approach to use SMTP, but you may need to poke some security holes through your environment.

Assuming you can get out through your firewalls on port 587 or 25 for SMTP, you’ll need to turn off Azure AD Security Defaults if you have them on. If you do this, understand what you’re turning off and rebuild those same settings in Conditional Access. If you have them off, then you should have Conditional Access policies already.

Personally, I have a ‘Block Legacy Authentication’ conditional access policy which as it says, blocks legacy authentication. For an account I want to send emails from via SMTP, I add it as an exception to this policy.

I then have a second policy ‘Allow Legacy Authentication Internal Only’ which I then target this user at, which still blocks legacy auth unless it’s coming from a trusted IP address. These two rules together then block all users from legacy auth, except the ones on the second policy, and then only if they’re coming from inside my network. The goal of this is to prevent anyone externally using spray attacks against accounts to gain a username and password – although they couldn’t log in anywhere beyond SMTP due to MFA policies, they could still start sending emails that would be from a legitimate email address.

If you have IPs restricted on Exchange Online connectors, that does not appear to affect SMTP auth and you shouldn’t need to add your internal IPs there.

The account you want to use for SMTP sending must have a mailbox license, I use ‘Exchange Online Plan 1’ for one of the cheaper options that is pure mailbox. The SMTP settings are listed here.

You also need to allow SMTP auth across your organisation (not ideal), or on a per account basis (much better security wise, plus it overrides the org default – so you can disable at org level and allow at account level). Microsoft Docs covers this in detail but the command (which requires connecting to Exchange Online via PowerShell first) to allow on a single mailbox is:

Set-CASMailbox -Identity sean@contoso.com -SmtpClientAuthenticationDisabled $false

Once these policies and licenses is in place, you can test. The easiest way I found was a 1 liner PowerShell command. You must use the source mailbox’s account as the from address:

Send-MailMessage –From account@contoso.com –To test@contoso.com –Subject "Test Email" –Body "Test SMTP Service from Powershell on Port 587" -SmtpServer smtp.office365.com -UseSsl -Port 587 -credential $madeupvariable

When testing, I found that after changing the Conditional Access rules to let a specific account go through as legacy auth took several minutes. Azure AD logs also take several minutes to show auth attempts, so don’t rush and change too many things at once trying to do this.

Ideally, nobody would be using SMTP – but in the real world we still have to, so the above will at least keep login records in Azure AD, and limit it to trusted IPs, certain accounts, or any other Conditional Access rules you can come up with to reduce the risk of allowing this.

PowerShell Slow to Load and AutoFill

I had this problem on a server for a while – when first launching PowerShell, it would take ~20 seconds or so to accept input. Also, when pressing tab to auto-complete a command, it would again take ~20 seconds to start, like it was freezing. These were one time problems when launching PowerShell, after that it would work fine until a new session was launched.

A lot of searching didn’t help me work it out, so I logged a Microsoft case. After a few task manager executable dumps, they worked out the delay was on a path I had in an environment variable. Somehow in my account’s user variable, I had a github desktop path that was mapping to a network share, using a PC name that was decommissioned (e.g. ;\\pcname\c$\Users\AdamFowler\AppData\Local\GitHubDesktop\bin.

I expect that this name was timing out, and PowerShell was waiting a while before giving up. In case you have the same symptoms as me, check the environment variables – user variables paths if it’s only your account affected, or the system variables if it’s all users. Click on the path value, then click edit, and remove anything that shoudn’t be there (take a backup of the text if you aren’t sure, it’s easy to put back in if you keep a copy).

To get to Environment Variables, depending on the OS version, get to System Properties, the Advanced tab, and then the Environment Variables button:

Hope that helps someone else with the same problem!