We’ve had a number of queries recently relating to the Room Finder. The key thing to be aware of is that this information, although some of your rooms’ info may be in the address list, the Room Finder data is generated via a query of specific values set at the server (via the set-place cmdlet), regardless of what the address list details are.

To appear in the Room Finder your meeting rooms must have been added to a special group, known as a Room List. This will usually be the name of the building. If you wish the Nexus Team to make one of your rooms visible to the Room Finder we must therefore be told, as a minimum, which Room List it should be added to, or what name should be given to a new Room List if it doesn’t already exist.

If you would like us to retrospectively populate your rooms’ data in bulk, a spreadsheet containing the appropriate info from the list below would be useful to us.

Some of the values which can be set, and are searchable options in the Room Finder:

– audiodevicename (text value)
-building (text)
-capacity (integer)
-city (text)
-CountryOrRegion (text)
-displaydevicename (text)
-floor (integer)
-floorlabel (text)
-geocoordinates (integer)
-iswheelchairaccessible (true/false)
-label
-postalcode (text)
-phone
-state (text)
-street (text)
-tags (text)
-videodevicename (text)

Example command to configure those:

Set-Place -Identity "Logon name of a room somewhere in Oxford in aaaa1111@ox.ac.uk format" 
-CountryOrRegion "UK" -City "Oxford" -Floor 99 -FloorLabel "99th Floor" -Capacity 7000 
-IsWheelchairAccessible $true -Street "9999 VeryShort Street" 
-GeoCoordinates "51.752022; -1.257726" -Building "Not Rex" -State Oxon -PostalCode "OX1 1EG"
 -Phone “+441865 1234567" -Label "Training Room" -VideoDeviceName "Big telly" 
-AudioDeviceName Microphone -Tags Training, Development, Videoconference

Based on the last 90 days’ data:

• The busiest day to try and book a meeting in one of our Teams rooms is Tuesday.
• The most-occupied meeting time is the 11am to noon timeslot, closely followed by 10am to 11am and 2pm to 3pm.
• No Teams Room is used more than 37% of the available time.
• Many booked timeslots are not used.
• Seven meeting rooms had zero utilisation and zero reservations.
• The two most utilised rooms had 100% utilisation and were reserved for 100% of the time.

Teams Rooms utilisation over the last 90 days

Since I first implemented DMARC back at the beginning of the year I wanted to tighten the policy we had initially set. The idea behind DMARC is to allow recipients of email to better differentiate genuine content from spammers who spoof email addresses for nefarious and malicious purposes. Our policy has cautiously (and slowly) evolved from the bare-minimum towards today’s more typical DMARC value: email which fails legitimacy checks should be delivered to recipients’ spam folder.

The ultimate aim is that everything that is sent out from a genuine Oxford email address should be verifiable with a legitimate source, be provably unaltered in transit, and therefore always delivered to recipients’ inboxes. Meanwhile, spammers who impersonate our email addresses should no longer have their email treated with the same degree of respect, they’ll fail the validation checks, and will thus see their messages sent to recipients’ “junk” folders.

The challenging part of this has been a number of mass-mailing services being used within the University that sent out valid messages, using Oxford email addresses, but which had not been configured with SPF and DKIM to allow for validation checking to take place. It has taken some time to try and track those down, find the people who manage those services – many of whom are not technical – and work with them to get SPF and DKIM in place so that their outgoing email is verifiable and legitimate. There may still be some services within the University which we have not yet found. I will be continuing to look at DMARC logs to identify those where possible but please log a support ticket with central IT Services if you believe that your genuine mailshot will fail these validation checks. Ask for help configuring SPF and DKIM and please name the service you’re using (Adestra, Mailchimp, Blackbaud etc. in the ticket).

Our policy’s evolution:

The bare minimum: yes, we have a DMARC policy, no please don’t take any action:

v=DMARC1; p=none

A slight improvement: we’d like you to quarantine messages which fail authentication checks, but please undertake those checks on zero percent of our messages.

v=DMARC1; p=quarantine; pct=0

And today’s value:

v=DMARC1; p=quarantine

For the curious, our DMARC values have also included a section which uses the National Cyber-Security Centre’s MailCheck service to analyse recipients’ DMARC outcomes for us.

rua=mailto:dmarc-rua@dmarc.service.gov.uk

In their infinite wisdom, Microsoft have enabled the Clipchamp service plan – by default – for academic licences prior to the necessary back-end functionality being in-place to provide that service. Until this is resolved it should be expected that Clipchamp will not be available to actually use for Nexus365 users.
The rollout is currently scheduled to complete by the end of September so, at the time of writing, October 2024 is when one can expect it to be available. We might see it sooner…

An IT admin at Tyne Coast College raised a support call with Microsoft to clarify the situation and received the following:

Thank you for your quick revert. As of now that is the expected behavior because Clipchamp is still getting rolled out as I mentioned in my initial email. I would not recommend trying every other day as it will not work and great user dissatisfaction.

 As of now only SKU is getting enabled and the product access is still not being enabled, hence the error which is appearing is expected one. Deadline to complete the Clipchamp rollout for all M365 A3 and A5 tenants is Sep,24. So, start of Oct, 24 is when you will be able to use Clipchamp as expected when the rollout is completed.

If you are bulk-sending to Gmail you need to be fully aware of their sender guidelines. Be aware that non-compliance with these rules will now result in messages being sent to spam folders, at best, or rejected, at worst. There are no exemptions and failure to comply could impact delivery for other parts of the University: our reputation as a sender is predicated on email we send not being marked as spam by the recipient.

For a short period Gmail will send a message back detailing why a message was rejected. It is paramount that you take action immediately to address that issue: failure to do so could hinder ongoing delivery.

The temporary failure messages include error codes that indicate which sender requirement is causing the failure:

Last October Google announced that they would be tightening up their standards for what is acceptable in terms of large quantities of email from a single sending domain. Yahoo! made a similar announcement at the same time.

The first key point to be aware of is that Google and Yahoo have chosen to publicly announce that they’re tightening up their email acceptance  criteria. Not every organisation will necessarily be issuing a press release announcing that fact – bulk-email/spam can be such an annoyance to everybody. So we can be confident that other organisations will be making similar decisions, depending on their perceived scale of the problem, at a time that suits them. We have limited tools available to us to ensure consistent and reliable delivery to our recipients’ inboxes, other than following industry best-practice (which is all they’re asking us to do). It is entirely possible for one part of the University bulk-sending email carelessly to cause the rest of the collegiate University to have their outgoing email sent to spam folders, or rejected entirely. In theory only of course: we’re all far too professional for that to happen, right?

It is therefore vital that all IT Support Staff, in all parts of Oxford, consider and account for these requirements, particularly where they are using any kind of private or third-party bulk sending method. The Email Security Project is endeavouring to apply settings on behalf of the widest possible scenarios and situations but we know that edge-cases exist that may fall outside our visibility, scope, and remit.

Yahoo’s published requirements for bulk-senders

They have not specified a threshold above which these restrictions will apply. Email which fails these checks/requirements will either go to the recipients’ spam folders, or be rejected entirely. In that event a non-delivery report will be sent back to the sender. Spoofed email WILL count against their threshold.

• Email must be authenticated with SPF and DKIM.
• Your domain must have a published DMARC policy.
• ‘From’ headers in outgoing email must be aligned with either the values set in your SPF record, your DKIM record, or both.
• You must include a functional ‘list-unsubscribe’ header supporting one-click unsubscribing (RFC 8058 is recommended).
• A visible unsubscribe  link must be visible in the email’s body text (which can direct to a mailing preferences page).
• Unsubscribe requests must be honoured within 48 hours.
• Spam complaint rates must be below 0.3% (based on Google’s Complaint Feedback Loop service where users mark undesirable inbox content as spam).

Google’s published requirements for bulk-senders

 This is not an exhaustive list and Google’s other standard anti-spam recommended actions still apply.

• A threshold of 5000 emails per day. In our case this will be totalled across all ox.ac.uk subdomains which send outbound email.
• Email must be authenticated with SPF and DKIM.
• Your DNS must contain PTR records for sending domains.
• Your domain must have a published DMARC policy.
• You must include a functional ‘list-unsubscribe’ header supporting one-click unsubscribing (RFC 8058 is recommended).
• Unsubscribe requests must be honoured within 48 hours.
• Senders must remain under a ‘spam rate threshold’ (0.1% in Postmaster Tools) to ensure delivery to Gmail recipients.
• TLS connections must be used for transmitting email.
• Messages must be IME-formatted (RFC 5322).
• Don’t hide HTML or CSS content within your emails.
• Message From headers should only include one email address.

The Email Security Project has already comprehensively tested DKIM and DMARC (with basic SPF records already extant), both in a test environment, and for one subdomain.
The intention is to enable full DKIM and DMARC protection for the entire collegiate University in the next few days, well in advance of Google and Yahoo’s 1st February deadline.

Every migration is different, so the best method will differ too.  But the use of standard protocols, and Microsoft’s vested interest in getting more people onto their platform, mean that migrating into  Nexus365 is usually straightforward, reliable, and simple.

Third-party migration tools also exist, which may be able to bring across more than just messages, but those would need to be managed by the ITSS in charge of the source data.  It should also be noted that some parts of the University have simply self-migrated by configuring Outlook to open both mailboxes side-by-side: users can drag-and-drop content from one to the other.

There are a few considerations to bear in mind whatever migration method will be used:

• Email routing and the timing of changes will need to be considered carefully – if the old mailbox is removed prior to the routing being updated, new incoming email could disappear into a black hole. To ensure this doesn’t happen the timing of routing changes, and user communication, is crucial.
• Users may need support in reconfiguring email clients on the day of any routing changes. We strongly advise ITSS to show users how to access Nexus365 webmail (‘OWA’) ahead of time, since that will give mailbox access from any web browser without the need for special reconfiguration.
• There may be forwarding configured on the Nexus365 mailbox to redirect email to the previous departmental system: those forwards will need to be removed on a carefully-managed schedule to avoid creating mail loops.
• Depending on exactly when in the migration process a user connects to Nexus365, they may find their mailbox empty: their old content is ‘backfilled’ into the new mailbox. Setting user expectations for this saves many support issues! Where migration delays would be unacceptable a user could self-import content via a PST file, or equivalent, rather than wait for the migration to finish.
• Existing content, such as calendar appointments, may lose the ‘friendly name’ of the person arranging the meeting once the old server is disconnected (the old address book won’t be available for lookups). We usually advise people to try to generate new items rather than attempt to edit historical ones, in an effort to minimise this effect.
• Users should be made aware that not all content can be migrated (a non-exhaustive list could include: rules, out-of-office messages, tasks, notes, signatures, auto-complete addresses, etc.) A migration from another Microsoft Exchange version will be the most complete.
• Nexus365 mailboxes are sized by the assigned licence, either 50GB or 100GB. Mailboxes in excess of the available space will either need to be assigned an A3 licence (users only; not shared mailboxes) or they will need to request an archive mailbox in which to store the excess content. The archive will usually have an assigned policy moving the oldest content into the archive automatically.
• Users with shared mailboxes will need to document and reconfigure any permissions which allow someone else access to their mailbox’s content. All shared mailboxes on Nexus365 must have a clearly-defined owner responsible for its content.
• Distribution groups and delegated group management will need to be considered and, perhaps, updated to use a different technology, such as a Sympa Mail-List, or a Microsoft Team.
• Resource mailboxes, such as parking spaces or meeting rooms will need to be re-created. Historical meetings migrated into a meeting room’s mailbox may lose their association with their original owner.
• Teams Rooms devices will need to be updated to use a new account, via a service request, which also requires a cost-code to which the associated licence’s purchase cost can be assigned.
• Migration capacity – the migration process creates a lot of simultaneous connections and can overwhelm modest hardware. You should ensure that the migration is timed or batched in such a way that your source server isn’t DDOS’d by the migration process itself.

To improve delivery of our outgoing email DKIM and DMARC were enabled for the it.ox.ac.uk domain on Thursday 16th November, as a proof-of-concept that these technologies are beneficial and don’t create new message delivery issues. Generally it’s SPF records that are the ones that cause issues, since a list of authorised servers is always going to flag up any unofficial ones that might be present…

Naturally for the first few days I’m keeping a close eye on message reporting and identifying anything which can be fine-tuned or improved. Here’s how the first three days with active DKIM and DMARC have gone so far. The University’s weekend email traffic is always significantly down on weekday usage, so there’s only one full working day with useful data to analyse so far:

• Fully trusted
  SPF and DKIM are both successful; DMARC checks pass.
• Partially trusted
  Either the SPF or the DKIM check succeeds; DMARC checks pass. These messages will still be delivered for all three DMARC policy settings. This is also the group to concentrate on to strengthen SPF or DKIM.

  The next three categories all comprise DMARC failures, because SPF and DKIM checks have both failed. The exact outcome will depend upon your selected DMARC policy. In all three cases these will help identify if the failures relate to a system under your domain’s remit which requires reconfiguration, or if it is due to email being spoofed. Or both…

• Untrusted
• Quarantined – These emails are sent to the spam folder.
• Rejected – These emails are not delivered to the user.

Initial observations

There were 254 messages flagged as ‘untrusted’, which is 17.6% of the total sent.

158 of those were from the LISTSERV mailing list platform.
100% of messages failed DMARC from the LISTSERV platform, likely because the current DMARC policy is ‘none’. Jiscmail’s handler automatically detects a DMARC policy of ‘reject’ or ‘quarantine’ and ensures successful delivery.

28 of those were untrusted but were still successfully delivered due to ARC being able to assert that DKIM was valid up to the last intermediate provider in the email delivery chain.

The proposed plan is therefore, as a next step, to move to a DMARC policy of ‘quarantine’ but with a percentage value of zero (pct=0). This has an effective outcome identical to the ‘none’ policy, but LISTSERV will cease spoofing our domain.

Sorry about that.

We are currently in a ‘grace period’ where Microsoft allows Teams Rooms devices without a valid device-specific licence to still continue to work. This represents an extension of 90 days from the original deadline, which was going to be 1st July 2023.

We can see that there are a number of unofficial Teams Rooms devices in use within the University, mostly operating via a normal user’s login. Doing that is a potential breach of University regulations, as well as a potential breach of licencing terms. I therefore urge you to legitimise these devices via the official service request process as soon as possible, and ideally well before the end of September 2023: this is when the current grace period ends and represents the point at which these devices will cease to work.

The Nexus Team will not be operating any special expedited process to register devices which have been operating outside the rules which are caught out by this long-advertised and significantly-postponed change in licencing rules.