LA Readiness Considerations
- Internet Access
Access to Exchange Online is over the Internet and so your applications will need the ability to access the relevant IP addresses through the network which may require local firewall or other network changes.
- Exchange Web Services (EWS) Autodiscover
If your application can use Autodiscover, this should be enabled. This will allow the application to detect that the mailbox has moved and the new EWS URL.
- Hard Coded EWS URL Change
If your application does not support Autodiscover, then you will need to update the EWS URL in your application to continue accessing the mailbox after it is moved. The new EWS URLs will be based on the domain outlook.office365.com.
It is recommended that the use of hardcoded addresses is avoided where possible. Using Autodiscover will ensure any future changes to EWS URLs will automatically be identified.
Legacy & Exchange ActiveSync hostnames
Please note that, with the migration to Exchange Online, the following legacy hostnames are due to be phased out :
- imap.nhs.net
- pop.nhs.net
- smtp.nhs.net
- eas.nhs.net
- mail.nhs.net
- outlook.nhs.net
Any applications or configurations that are hard coded to use any of these URLs should be updated to use outlook.office365.com.
It is recommended that the below guidance is followed. There will however be scenarios unique to your local organisation that may need to be further investigated by local IT.
eas.nhs.net:
Use cases could include old clients or devices that do not support automatic updates to server settings through Autodiscover, for example, older Android or Apple devices with a legacy EAS configuration on the device. It is recommended that you:
- Ensure the end user device is up to date and using a supported software version
- Check any Mobile Device Management (MDM) policies, specifically to ensure the device is configured to use outlook.office365.com
- If the above is correctly configured, it may be that the device is attempting to access the legacy URL in the background. This shouldn’t prevent mail access
mail.nhs.net and outlook.nhs.net:
Most of this traffic is being generated from Mac OS clients, which will have been hard coded to access mail through these legacy URLs. It is recommended that you:
- Audit Mac clients connecting from your organisation
- Update the current server settings to point to the correct O365 URL
- Request impacted users create a new mail profile on their Mac device. Steps on how they can do this can be found here.
Please contact the NHSmail helpdesk if you have any queries.
POP, IMAP & SMTP Proxy
Organisations should point applications directly to the Exchange Online addresses below. For any high-sending accounts it is recommended that send.nhs.net is used, further detail is included in the High-Sending section below.
|
Protocol |
Purpose | Hostname | Port | Encryption |
Auth Required |
|
IMAP |
Receiving Email | outlook.office365.com | 993 | SSL |
Yes |
|
POP |
Receiving Email | outlook.office365.com | 995 | SSL |
Yes |
|
SMTP |
Sending Email | smtp.office365.com send.nhs.net |
587 | TLS |
Yes |
EWS Impersonation
Any application accounts set up to use EWS with impersonation to access other mailboxes should continue to work after they have been migrated to Exchange Online.
However, it is important to note that EWS will only work for applications that use Autodiscover to locate the correct Exchange EWS URL for each mailbox. If an application uses hardcoded EWS URLs, the application will fail when trying to access any users who have been migrated.
High-Sending Accounts
Exchange Online has a limit for the maximum rate at which emails can be sent per account. Accounts which are identified as routinely sending higher volumes of email than this limit are classified as “High Sending” and will have their SMTP traffic automatically directed to a separate set of SMTP servers which will allow higher throughput to avoid the Exchange Online limit.
It is important that Local Administrators (LAs) do not change the SMTP address for high-sending accounts. The on-premise send.nhs.net hostname should continue to be used.
There is no central solution for high receiving applications (above 3,600 messages received per hour) or applications that breach the standard Microsoft limits (e.g. 1,000 recipients per email). Local Administrators (LAs) must review the previous guidance on limits and ensure their applications comply with these requirements.
Transport Layer Security (TLS)
As communicated previously, Microsoft are currently deprecating TLS versions 1.0 and 1.1. Any application that uses these legacy protocols and requires connectivity to Exchange Online and O365 will stop working following the deprecation. Local Administrators (LAs) must update their applications to support TLS 1.2.
Microsoft guidance on how to enable TLS 1.2 can be found here.
