Today I noticed for the first time, that the MyAnalytics emails that were coming through weekly, showing where your time was being spent, emails you may need to respond to etc had been replaced by Microsoft Viva. There’s also a post in TechCommunity covering this in detail.
The previous MyAnalytics emails would come in weekly, and be broken up into different editions – Wellbeing, Focus, Collaboration or Network edition. This new monthly digest indicates Microsoft Viva is the way forward. Note that this still works the same way as MyAnalytics where the contents of the email are private to you, and do not come as a normal email that would be trackable (more details in my MyAnalytics article)
That ‘Learn more’ link takes you here: https://www.microsoft.com/en-au/microsoft-viva/insights/?s=mya with some details around Microsoft Viva. One of the main links there takes you to Viva Insights on Teams, which is the Insights addin option that’ll show up on the left menu and take you to the Viva Insights Home page.
The Stay Connected tab is worth checking out, as it will highlight email conversations it thinks are things you need to do, or highlight people (team members for me) that you don’t have a 1 on 1 meeting scheduled for the next twk weeks.
Going back to the web page for Microsoft Viva, there’s a lot more content then when I looked when it first launched. One section I thought was notable was under Network, you can see your Top Collaborators and their read percent and response time of emails.
My point on all this, is that there’s a lot going on here. People may find it and have questions around it, especially when these emails are generated to all staff by default. Someone may have stumbled across the ‘Delay Delivery enabled’ option and turned it on, then forgotten about it later, complaining about emails being slow to get to customers or clients:
What we’re seeing above with Microsoft Viva and MyAnalytics (now Viva Insights) is only a part of the full Microsoft Viva solution too – there’s also Viva Connections, Viva Topics and Viva Learning:
Viva Connections and Viva Insights are generally covered under an existing license, but Viva Topics and Viva Learning are at an extra cost.
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:
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.
Form a machine with the Teams PowerShell Module installed: $Session = New-CSOnlineSession -OverrideAdminDomain yourdomain.onmicrosoft.com Import-PSSession $session –AllowClobber Set-CsOnlineVoiceUser -Identity [email protected] -TelephoneNumber 61812341234 Grant-CsTeamsUpgradePolicy -PolicyName UpgradeToTeams -Identity [email protected]
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
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
Going into any Dial Plan brings up this admin portal error, as well as trying to run a Test Dial plan test:
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
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.
DeskPhones 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:
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.
As per Microsoft Documentation , there’s Intune device limits, and Azure device limits. Intune / EndPoint Manager has a maximum of 15 devices, where Azure has a default of 20, but can be changed to a few different values, including ‘unlimited’.
To remove devices from a user, and admin should use Azure Active Directory and go to Users > Find the user > then under Manage, choose ‘Devices’. Any old device (check by the activity date) can be selected and deleted.
After removing enough devices here, you should be able to register the new device via the Intune Company Portal app again – and in my testing, this was next to instant.
Such a basic thing, but great to see. As per this Forms Uservoice suggestion, Microsoft Forms now has a ‘shorten URL’ option. It’s still rolling out right now (March 2021) but it turned up in my tenants. You’ll find it under the Share menu, and then under ‘Send and collect responses’ :
The tick box is called ‘Shorten URL’:
Before ticking this box, the Forms URL for sharing looks like this:
Impersonation Protection in Microsoft Defender for Office 365 is part of the Anti-phishing policies, designed to take action if an external email comes in with a match, or near match, to the display name of an employee.
The actions you can take when a match is made are:
Redirect message to other email addresses
Move message to the recipient’s Junk Email folders
Quarantine the message
Deliver the message and add other addresses to the Bcc line
Delete the message before it’s delivered
Don’t apply any action
What I wanted to do, was deliver the message and add other addresses to the bcc line. This could be used to send a copy of the email to helpdesk for investigation, as Impersonation Protection tends to get a lot of false positives from services that like to use people’s actual names from emails they generate, or from people using a personal account to email other employees.
What I found was that the action was applied, but the email was then delivered to the Junk Email folder. If I wanted that to happen, I would have selected the ‘Move message to the recipient’s junk email folders’ option. After logging a case with Microsoft, I found out why.
Any time an email is detected as an Impersonation Protection, and the mail is still allowed to flow through, it will set the header as SCL 5. As per Office 365 standards, this will deliver the email to the recipient’s junk mail folder.
It makes the choices on what actions to take in the Impersonation Protection settings rather misleading; but there is one option that’s still reasonable – Quarantine the message. This should trigger a fairly quick quarantine digest to the recipient for review, allowing them to review and decide if it should be released. If released, it will then deliver to the Inbox rather than Junk Mail.