Teams and maillists

After resolving a confusing support ticket we have identified that some University members were adding maillists to Teams: please do not ever try to add a maillist email address to a Team. It won’t do what you want and it has adverse effects.

Why? In part it’s because the Maillist service (Sympa) and Nexus365 are entirely separate. There is no integration at all – they’re run as separate services and they’re managed by different staff within IT Services. We believe that what is happening is someone assumes that adding a maillist’s address to a Team would be a quick and simple way to populate it.

It isn’t, and it doesn’t.

Here’s why:
  1. Maillist/Sympa is an external organisation, as far as Nexus365 is concerned. Any maillist address you add is treated like any other external user account with a non-nexus address. Teams (and other Nexus365 services) do not see a maillist’s address as a bulk list of users. It has no way to expand the list and see its membership. Instead, Nexus365 would assume that you are adding ONE user. It is entirely unaware that the email address you’re adding has any connection with a bulk senders list.
  2. Anyone in the maillist can receive the welcome email from Teams which invites them to join the Team, whether or not they’re part of the University.

This is where the problem begins, particularly if – as has happened in a few of the examples we’ve looked into – that user attempts to specify their own Oxford address as the recipient address for this external account. This is not something we can limit without hindering external collaboration in Teams works for the whole University.

When you add a maillist to a Team, what you’ve actually done is generate a code for that user to join your team, but which has now been emailed to the maillist’s entire membership. So under these circumstances anyone can use that code and take up that presence in your team rather than the genuine Nexus365 account. This causes a conflict which we have to unpick (by deleting the errant account entry).

The maillist account only becomes seriously problematic in a Team IF someone receives the invite, AND goes through the process to validate and join that account in teams. A Team Owner can remove the errant entry (which will show as an external user) from your Team themselves, without IT Services’ intervention. We only need to be involved if a maillist member has responded to the welcome message. 
N.B. To prevent this specific issue recurring the Nexus Team are now pre-emptively blocking the addition of the University’s maillist domain names from being added to a Team’s membership.
If you want to bulk add users to a team, consider using the methods detailed in the Power Automate (Flow) User Group Thread. Microsoft is working on a method of using .CSV imports for Teams and group memberships but there has been no news yet on a date for release. In the meantime the PowerAutomate “join to group” or “Join to team” methods are the only ones available.
Posted in Uncategorized | Comments Off on Teams and maillists

Outlook 2013: last call to keep up with minimum requirements

After 1st November 2021 the oldest supported version of Outlook that will be able to connect to Nexus365 services is Outlook 2013 – as long as it has updates and fixes on top. The number of the oldest supported version is 15.0.4971.1000 (Service Pack 1 with the October 2017 Update).

Microsoft are blocking older versions because of the following reasons:

  • Support for basic authentication is ending, as a way to improve the security of your mailbox’s content.
  • Microsoft are moving towards HTTP/2 – which uses full-duplex communications to decrease latency. Improved header compression and multiplexing help improve throughput even further.
  • Newer versions of Outlook crash less often: Outlook’s reporting means that many of the most frequent causes of crashes have been identified and fixed.
Posted in Uncategorized | Comments Off on Outlook 2013: last call to keep up with minimum requirements

Automated transcription in online meetings

General advice from Peter Kent, Head of IT Governance and Communications, Office of the CIO at JISC.AC.UK:

What follows is a generic example of how you could approach managing the data protection aspects of using this feature. This is not legal advice. Always run any guidance past your internal data protection/compliance teams. Bear in mind that any guidance is usually general, and specific circumstances/contexts should always be considered.

What is live transcription?

Live transcription is a feature in Teams and Zoom meetings which transcribes speech to text. When enabled, the transcribed text will appear as on-screen subtitles, attributed to the speaker. Transcripts can also be shown in separate panels, and feature in recorded meetings too. But there are times when you should not use live transcription or share recorded meetings with transcriptions – more details below.

Why use live transcription?

Live transcription makes online meetings more inclusive, giving any hard-of-hearing meeting participants the opportunity to join in.

How accurate is live transcription?

Live transcription is undertaken by computers and cannot be guaranteed to be accurate. For example, the text displayed may be erroneous, or the text may be attributed to the wrong speaker.
Accuracy will be lower if technical or niche terms (jargon) are used. Accuracy will also suffer if the speaker talks too fast, is talking from a noisy environment, or if more than one person talks at once.

When should live transcription not be used?

Some providers may retain anonymised copies of audio and associated transcripts to improve the accuracy of their technology. This should be made clear to users as part of your obligation to provide privacy information. It may, in some cases, be possible to re-identify participants and cause harm to your organisation and others if the content of the calls provides sufficient context. Given this, and the potential inaccuracies of live transcription you should assess the risks of using the feature when sensitive topics are being discussed.

Should I tell speakers and meeting participants that live transcription is enabled?

Yes. Tell meeting participants that their speech will be live transcribed and attributed to their name. If this is an external event, you could include this detail in the privacy notice for the event. Give them the opportunity to submit any comments or questions via a chat panel rather than by talking, so you can read those out without attributing them to anyone.

Can I share recorded meetings with live transcriptions enabled?

The following data protection restrictions are in place to protect individuals and your organisation from the potential accuracy issues highlighted above.

External meetings (those hosted by your organisation but having non-organisation participants) featuring live transcriptions can be recorded and shared only if one of the following three conditions is met:

  1. The transcripts are amended prior to sharing (learn how to edit transcripts Zoom recordings and Teams recording):
    · The transcript content is verified and corrected as necessary.
    · Where the meeting has been advertised with speakers’ names (for example, to boost participation with a popular speaker), these speakers can be referred to by their first name and/or initials in any speaker attribution.
    · Any non-advertised speakers and all other participants can be referred to as [participant] in any speaker attribution.
  2. The transcripts are removed prior to sharing. The easiest way to do this is to download the recording files from Zoom or Teams and then share only the video (.mp4) file via Onedrive or Sharepoint. Please note – if a recording is being shared publicly (for example on the organisation website or on Youtube) it should include a transcript to comply with accessibility legislation.
  3. The recording is being shared with a defined group of identifiable individuals, and the inclusion of full names in any speaker attribution is required to facilitate discussion (such as for subscriber group meetings). In situations such as this, names may be used but the participants must be made aware of this beforehand.

Internal meetings (those hosted by your organisation and only having your organisation participants) featuring live transcriptions can be recorded and shared within your organisation without restriction.

Who can I talk to about a use case that might need to be treated differently?

If you have a use case that might be a bit different to those listed here, or you have a query about naming participants or privacy notices, please get in touch with your organisation’s data protection team.

How do I enable live transcriptions in my meeting?

Use this link to learn how to enable live transcriptions in your Teams meeting.

Posted in Uncategorized | Comments Off on Automated transcription in online meetings

Fixed: Outlook Shared Calendar notifications

The Microsoft Exchange team have announced that an update to shared calendar notifications is now leaving preview and entering production. These improvements are gradually being made available for Outlook-on-the-web (a.k.a OWA), Outlook for Mac and mobile (it’s already rolled out for these two) and, finally, for Outlook on Windows.

The intention is that this is just an improvement – there should be no glaringly-obvious user-noticeable changes beyond snappier performance. There are some minor improvements, but they take the form of more intelligent handling of things like amended meetings, with fewer confusing dialogue boxes needing an answer. As an example, if you amend a long-established recurring meeting Outlook can now update it, leaving historical meetings alone, but allowing future meetings to have revised attendees/dates/times. It doesn’t break them, and most of the confusing user prompts are no longer needed.

To get an overview of what’s new Microsoft have provided this page. For a nice friendly video (which was on that page but now isn’t any more) showing how to enable it, and what’s new, there’s this link: video guide.

What’s changed?

  1. More responsive, faster updates.
    What we’ve all grown used to is shared calendars lagging behind the times – there might be changes that have happened in that calendar which haven’t yet appeared for our view of it. This leads to differing out-of-sync versions. After this change, editing a shared calendar should be as responsive as editing your own.
  2. Meeting organiser improvements.
    You can extend a recurring meeting without impacting any historical exceptions to it. If you modify the meeting’s attendee list, updates are only sent to those you’ve changed. Draft meetings will now appear in your calendar (unsent), rather than your Drafts folder. And if someone accepts a meeting but doesn’t send a response, you can still see they’ve accepted it via the ‘tracking’ tab of the meeting. One potential gotcha is that when you forward a meeting to a new attendee, existing attachments remain but you can’t add new ones. This ensures that all attendees can see all of the original attachments, with the same content.


Technical details of the changes

Attribute Old Model New Model
How a shared calendar is stored A hyperlink-like entry is placed in your mailbox. A new calendar is created within your mailbox containing a copy of the data (going back 12 months)
How a shared calendar is accessed Reads/writes the owner’s mailbox. Reads/writes local copy of the shared calendar.
How a shared calendar syncs Original mailbox is periodically polled. Changes synced instantly to your cached copy. (Push notifications used)
Apps allowing access to a shared calendar Outlook on Windows and Mac, and OWA. Outlook on Windows, Mac, iOS, Android. Also OWA, Calendar for Windows 10, and all REST/EAS apps.

Is this enabled for me yet?

Ways to check:

  1. Can you see the shared calendar on a mobile phone’s copy of Outlook?
  2. Is ‘Turn on shared calendar improvements’ ticked? (Find this in File>Account Settings> Account Settings> [your email account] >Change > More Settings > Advanced)
  3. Admins can check group policy restrictions: HKCU\Software\Policies\Microsoft\Office\16.0\Outlook\Options\Calendar
    The value ‘SharedCalendarImprovements’  controls this setting and will be set to 1 if enabled; zero if it’s disabled.
  4. Check the ‘calendar properties’ dialogue box. You will need ‘editor’ or ‘delegate’ permission to do this. If the type has changed from ‘Type: Folder containing Calendar items (MAPI)’ to ‘Type: Folder containing Calendar items (REST)’ then it is enabled.
  5. Admins can check using Powershell – use the Get-MailboxCalendarFolder  cmdlet and check the ExtendedFolderFlags lookikng for a ‘SharedIn’ value.
  6. MFCMAPI will show the shared calendar in the calendar subtree and there will be an entry in the ‘common views > associated contents’ table called ‘SharingCalendarGroupEntryAssociatedLocalFolderId’.

Can I force an update?

Requirements: the shared calendar owner is hosted in Exchange Online, and you have specifically been granted you permissions to their calendar.

The simple solution is to ask the calendar’s owner to re-share the content with you, which they can do from any Outlook application. You can accept the invitation using an updated version of Outlook to force the update to this new calendar model. To do this without the user’s intervention:

  1. Navigate to the Calendar module and find the shared calendar you want to upgrade.
  2. Right-click on the shared calendar and select Delete Calendar.
  3. Close and restart Outlook.
  4. From the Home ribbon in the Calendar module: Choose Open Calendar > Open Shared Calendar
  5. Enter the name of the person who has shared their calendar with you
  6. Click OK to close the dialog.
  7. The shared calendar will reappear in your Calendar list and should now be upgraded.

Note that there may be a short delay for the first synchronisation as the content is copied but future content changes should appear near-instantly.


Further reading: Microsoft calendar sharing

Page was amended 2nd June as Microsoft have updated the page to which I linked, and removed the video guide from their page. A new link has been added for the video.

Posted in Uncategorized | Comments Off on Fixed: Outlook Shared Calendar notifications

Email loops – what happens, when, and why.

The following headers are preserved, unmodified, by all default Exchange implementations:

  • X-MS-Exchange-Inbox-Rules-Loop
  • X-MS-Exchange-Transport-Rules-Loop
  • X-MS-Gcc-Journal-Report
  • X-MS-Exchange-Moderation-Loop
  • X-MS-Exchange-Generated-Message-Source
  • X-LD-Processed
  • X-MS-Exchange-ForwardingLoop
  • X-EOPAttributedMessage
  • X-EOPTenantAttributedMessage


This header represents the number of times a message can be redirected, forwarded, or processed by an automatic-reply. In Nexus365 this is set to only allow this to happen once. On-premises installations of Exchange allow up to three instances of redirection, forwarding, or auto-response before stepping in to prevent mail from looping.

When viewing headers the giveaway looks like this – if the value is 1/1 then the message will be silently dropped:

event_id: THROTTLE
reference: XLoopHeaderCount:1/1


This header is set if mail is redirected, or recipients are added, via an Exchange transport rule. This also has a limit of one.
In this instance the sender would receive a non-delivery report message sent back to them with this in the explanation:

550 5.7.128 TRANSPORT.RULES.RejectMessage; Transport rules loop count exceeded and message rejected.


You’ll only see this header when a message has been forwarded for the purposes of approval – in such circumstances the header will include the arbitration mailbox’s email address. Since there is a limit of one for this header type the approval message will be silently dropped if this header is already found to be present.


Used internally by Microsoft to detect looping on a per-tenant basis, permitting up to three loops per tenant for either an external email address or a forwarding address.


Present when forwarding is set on a mailbox. If the mailbox is set to deliver-and-forward there will be two copies of the message: one in the local mailbox and one sent externally via the forwarding address. The forwarded message will include the GUID of the original recipient’s tenancy, and the original email address:

X-MS-Exchange-ForwardingLoop:;<guid goes here>

This header allows the system to detect loops where an email is forwarded and the destination recipient has another forward which sends it back to the source.


This checks for loops in system-generated messages, which is only used if an auto-reply via an inbox rule is in effect. The following headers are stamped:

X-Auto-Response-Suppress: All
 auto-submitted: auto-generated
 X-MS-Exchange-Generated-Message-Source: Mailbox Rules Agent


Shows how many times the message has been processed by the Exchange Online Protection process in that tenancy. This value is reset if a message is forwarded from one tenancy into another. The precise value at which the message will no longer be processed is variable, and subject to change, but Microsoft currently state that the total hops permitted is seven, or three within one tenant’s environment. If that value is exceeded the following SMTP response will be sent (with ATTR1 for the total hop limit, and ATTR34 for total hop limit within a tenancy):

554 5.4.14 Hop count exceeded - possible mail loop ATTR1

Should the ATTR value be 39 or 40 we can log a support ticket with Microsoft to look into if the issue is with quarantine or spam-processing.

Posted in Uncategorized | Comments Off on Email loops – what happens, when, and why.

Last call for Calibri as Microsoft’s default font.

Microsoft have announced that Calibri will no longer be the default font in their applications. Those of you with long memories may recall that Calibri replaced Times New Roman as the default way back when Office 2007 was first released. Now they’ve decided it’s time for another change.

The new font is merely taking over default duties where Calibri is the incumbent, such as with Microsoft’s 365 apps. Whichever new font ends up declared as the winner will replace Calibri in that role.

To answer some of the queries:

  • Calibri will remain available as an option – it’s being demoted, not removed entirely.
  • Office 2019 will display these fonts natively. For correct display in older versions of Office apps you should embed the fonts in the options of the ‘save’ dialogue box.
  • Segoe UI will remain the font-of-choice for Microsoft’s Windows and Web UIs
  • You may need to enable ‘optional connected experiences’ in your Office apps to make the new fonts available to you.

There are five contenders and, if you want to influence the decision, you have a chance to do so here.

The choices are shown in the graphic below. Sadly, despite a few wags already suggesting them, Times New Roman, Wingdings, and Comic Sans are not going to make the cut as the new default.

You can read more about these fonts, their designers, and their inspirations, here.

Posted in Uncategorized | Comments Off on Last call for Calibri as Microsoft’s default font.

Block BCC messages sent to distribution groups

By default inbox-processing rules don’t process the BCC line, for privacy reasons. This means that if you have a carefully-crafted rule in your mailbox to divert Distribution Group messages to a subfolder, the rule won’t work if someone’s doing a reply-all via a BCC.

However Microsoft’s Exchange Team have now come up with a new powershell cmdlet which can resolve this behaviour. They’ve introduced a new ‘blockbcc’ switch to the set-distributiongroup cmdlet. Once set this will ensure that anyone trying to reply to a group via BCC will get a non-delivery report saying that they’re not allowed to do that.

It has user-friendly text:

The group [distribution group name] doesn’t accept messages sent to it as a BCC recipient.
How to fix it:
The message wasn’t delivered to the group because it doesn’t support sending to it as a BCC recipient. To fix this, try one of the following:
-Remove the group from the BCC adress box and add it to the To or the Cc box instead.
-Ask the owner of the group to change the setting to allow sending messages to it as a BCC recipient.
This bounce message only applies to the group or groups mentioned here. Unless you’ve gotten other bounce messages for other recipients, anyone else you sent the message to should have received the message’.


From a Nexus-team perspective, we need to do the following PowerShell to make this happen:

Set-DistributionGroup -Identity [group's name] -BlockBCC $true

Or to check:

Get-DistributionGroup -identity [group's name] | fl BccBlocked
Posted in Uncategorized | Comments Off on Block BCC messages sent to distribution groups

TLS 1.0 and 1.1: Last call!

I wrote on this subject back in July 2018 but, after a number of extensions to the deadline, the plug is finally being pulled on these outdated and insecure protocols.

Microsoft are now under way rolling out updates that will prevent acceptance of email connections from external sources using TLS 1.0 or 1.1. Nexus365 will NEVER use those versions of TLS to send secure outbound email.

It’s important to be aware that Nexus365 uses TLS opportunistically – email which does not use encryption (or if the TLS negotiation fails) Exchange Online will still accept messages unencrypted (if the sending server permits this). Likewise for outgoing email, if the receiving server does not issue a STARTTLS response.

Nexus365 will always attempt to negotiate the highest possible version of TLS which the communicating server supports. Once negotiated in the handshake, that TLS level will be held for the duration of the connection. Should TLS fail Nexus365 will not renegotiate a lower standard: delivery will instead be reattempted without TLS.

If you believe that TLS is the cause of any message-delivery issues, please let us know the SMTP errors logged (for example: “TLS negotiation failed with error SocketError”) and in particular the version of TLS being attempted from the protocol field.


Posted in Uncategorized | Comments Off on TLS 1.0 and 1.1: Last call!

Multifactor authentication: where next?

Now that the University is beginning to roll out multi factor authentication (MFA) it is worth reviewing the reasoning behind it, and what future authentication might look like for staff and students at Oxford.

Bear in mind that I’m not critiquing the concept of MFA here: it is a vital step to improve security at a time when Universities are being actively sought as a hackable target, with potentially huge rewards for the malicious. So what I’m writing about here is considering the best second-factor one should use, of all the available MFA options.

By far the easiest way to compromise someone’s account is social engineering – persuading a user to volunteer their information. Adding a second factor, beyond just a password, adds complexity and challenges for the nefarious. It’s far less likely that a user will be persuaded. More specifically it also ensures that both password and MFA have to happen at the same place and time, returning some semblance control to the legitimate user even when their password has been compromised.

“…the rate of compromise of accounts using any type of MFA is less than 0.1% of the general population.”
Alex Weinert (Director of Identity Security at Microsoft.)

TL;DR: You should use an authentication app on your preferred device.

Here’s why:

Text Messages
The underlying design of SMS has no capability to add encryption or verification. The need for backwards compatibility on billions of existing users’ devices, and vendors choosing to cease providing software updates after a couple of years, means that retro-fitting improved security can’t be done. The hardware to spoof a number is already out there, SMS signals can be intercepted, and it’s conceivable that anyone within range of a compromised user’s phone could generate fraudulent texts directed at that individual, or redirected elsewhere. SIM-swap fraud, where a ne’er-do-well impersonates you, to obtain a Porting Authority Code (PAC) to steal your phone number, is already a fairly common tactic.
The message size limit of 160 characters, roughly halved for some encoded languages, also limits the amount of information which can be transmitted at a time. And, finally, SMS lacks a mechanism to confirm delivery, or retry: messages can be delayed in transit or simply lost entirely.

Phone call
The public switched telephone network (PSTN) is similarly vulnerable: no encryption and no simple way to add any. The same issues of number spoofing exist and eavesdropping on a call is not beyond the capability of the determined criminal. The simplicity of the telephone system, based on well-known international standards, make it vulnerable to a whole host of attack vectors. Phone redirection is also simple and easy in most organisations, and is not (yet) widely recognised as an attack vector: it may be easier to socially engineer a telecoms department to get a user’s phone calls sent elsewhere. It’s probably that this could be done without the eyebrow-raising that asking for a password would provoke.

Hardware tokens
These are far more secure than PSTN or SMS second-factor authentication but have to be purchased. And if their security is ever compromised in the future it’s next to impossible to resolve that without simply having to replace them en masse.

App-based auth
The authentication app can take advantage of encryption and security features that are simply absent from the other authentication methods, and it’s updateable as new threats, or future vulnerabilities are discovered. Microsoft have already updated their authentication app several times this year – Microsoft’s Alex Weinart again:

“In just the last year, we’ve added app lock, hiding notifications from the lock screen, sign-in history in the app, and more – and this list will have grown by the time you plan your deployment, and keep growing while SMS and voice keep sitting still.”



Posted in Uncategorized | Comments Off on Multifactor authentication: where next?

Teams Telephony Trial

Microsoft Teams has slowly been taking over all of the functionality that was previously reserved for Skype. And I’m delighted to be able to say that we now have a very limited trial running that enables Nexus365 users to make calls to fixed landlines, mobile phones, and other conventional phone numbers.

For the purposes of this trial we have purchased 15 licences (all of which have been allocated: sorry!)

For users on the trial:

Once enabled for calling your Chorus phone number will be diverted to Teams. Please be aware that this will have the effect of removing any pre-existing Chorus forwards you might have in place.

The Teams client will now have a dialling pad on the ‘calls’ tab.

You can dial either by clicking the numbers on screen, by typing a number, or by entering a name that’s known to the system: it can resolve a name to a number.

The ‘History’ tab shows all your calls, inbound and outbound, and the ellipsis button on the far right gives you a menu including options to either add callers to your speed dial, or to block them.

The ‘Voicemail’ tab will show any messages which have been left, with an automatically generated transcription of what the caller’s message is. Of course you can also play back the message from here too: 


From the server-side we also have some great diagnostic tools to troubleshoot call-related issues:

I’m liking this functionality very much, particularly now that we’re enabling MultiFactor authentication – it’s wonderfully simple to receive a second-factor phone call from within the Teams app I’m already logged into, rather than search for a text message, look up a code on a hardware dongle, or install an app on another device.


Posted in Uncategorized | Comments Off on Teams Telephony Trial