Outbound Email Via Exchange Online Protection When Using Hybrid Exchange Online

Posted on Leave a commentPosted in dmarc, EOP, exchange, exchange online, Exchange Online Protection, Exchange Server, hybrid, mailbox, spf

In a long term hybrid scenario, where you have Exchange Online and Exchange Server configured and mailboxes on both, internet bound email from your on-premises servers can route in two general ways.

The first is outbound via whatever you had in place before you moved to Office 365. You might have configured Exchange Online to also route via this as well.

The second is to route Exchange Server outbound emails via Exchange Online Protection. Your Exchange Online configuration does not need to be adjusted for this to work, as the default route for all domains to the internet (or the * address space as it is known) is via EOP as long as you create no alternative outbound connector for *.

This blog post looks at configuring Exchange Server so that your on-premises mailboxes also route out via Exchange Online Protection, and does it without changing the connectors made by the hybrid wizard. If you change the hybrid wizard connectors and then run the wizard again, it will reset things to how it wants them to be, which will remove your configuration changes.

This configuration setup results in a single new send connector created on-premises in Exchange Server (or one connector per site is you route emails from more than one Active Directory site). This new connector is not the Outbound to Office 365 connector that the hybrid wizard creates and so changes here do not break hybrid and changes to the hybrid wizard do not impact outbound mail flow.

This blog post also assumes you already have a working route outbound for all internet emails and you are swapping over to outbound via EOP, so these steps work though ensuring that is correct and will work before changing the route for *.

Examine the hybrid send connector to Office 365

[PS] C:\ExchangeScripts\pfToO365>Get-SendConnector out* | fl

AddressSpaces:                  {smtp:domainuk.mail.onmicrosoft.com;1}
AuthenticationCredential :
CloudServicesMailEnabled :      True
Comment : ConnectedDomains :    {}
ConnectionInactivityTimeOut :   00:10:00
DNSRoutingEnabled :             True
DomainSecureEnabled :           False
Enabled :                       True
ErrorPolicies :                 Default
ForceHELO :                     False
Fqdn :                          mail.domain.uk
FrontendProxyEnabled : 	        False
HomeMTA :                       Microsoft MTA
HomeMtaServerId :               SERVER01
Identity :                      Outbound to Office 365
IgnoreSTARTTLS :                False
IsScopedConnector :             False
IsSmtpConnector :               True
MaxMessageSize :                35 MB (36,700,160 bytes)
Name :                          Outbound to Office 365
Port :                          25
ProtocolLoggingLevel :          None
RequireOorg :                   False
RequireTLS :                    True
SmartHostAuthMechanism :        None
SmartHosts :                    {}
SmartHostsString :
SmtpMaxMessagesPerConnection :  20
SourceIPAddress :               0.0.0.0
SourceRoutingGroup :            Exchange Routing Group (DWBGZMFD01QNBJR)
SourceTransportServers :        {SERVER02, SERVER01}
TlsAuthLevel :                  DomainValidation
TlsCertificateName :            <I>CN=GlobalSign Organization Validation CA - SHA256 - G2, O=GlobalSign 
                                nv-sa, C=BE;<S>CN=*.domain.uk, O=Acme Limited, L=London, S=London, C=GB
TlsDomain :                     mail.protection.outlook.com
UseExternalDNSServersEnabled :  False

The above PowerShell from the on-premises Exchange Management Shell shows you the hybrid send connector. As you can see this is set to route emails only for your hybrid address space (domainuk.mail.onmicrosoft.com in this example)

The other important attributes for EOP mail flow here are AddressSpaces, CloudServicesMailEnabled, DNSRoutingEnabled, Fqdn, RequireTLS, SmartHosts, and TLSAuthLevel. Setting these correctly on a new send connector will allow you to route other domains to EOP and then onward to the internet.

Create a new send connector

This blog is based upon information found in https://technet.microsoft.com/en-us/library/dn751020(v=exchg.150).aspx but it differs from the scenario described there within. In this scenario, as you have already run the hybrid wizard, the connector to the cloud from on-premises and from the cloud to your servers already exists. Therefore all we need to do is create an additional send connector on-premises to route all the other domains to EOP and the internet.

New-SendConnector -Name <DescriptiveName> -AddressSpaces testdomain1.com,testdomain2.com -CloudServicesMailEnabled $true -Fqdn <CertificateHostNameValue> -RequireTLS $true -DNSRoutingEnabled $false -SmartHosts <YourDomain_MX_Value> -TlsAuthLevel  CertificateValidation -Usage Internet

In the above, the connector is originally created being able to route for two test domains (written as testdomainx.com above, comma separated in the list with no spaces). This ensures that you do not break your existing mail flow but allows you to test that the connector works and then later change the connector to support * address space. The “YourDomain_MX_Prefix” is the same value as you would use in your MX to route emails to Exchange Online (tenant-prefix-com.mail.protection.outlook.com for example).

Testing the connector

In the above new send connector, testdomain1.com is a domain hosted in a different Office 365 tenant. Testdomain2.com is a domain who’s email is not hosted in Office 365 at all. You need both test scenarios, as routing to domains inside Office 365 is more likely to work if the connector is not configured properly.

So from a mailbox on-premises, send an email to a recipient at both testdomain1.com and testdomain2.com. Do not set the connector up to use gmail or Outlook.com, as that will impact other senders within your organization. Use domains that no one else is likely to want to email.

Ensure that you do not get any NDR’s and check the recipient mailboxes to ensure delivery. Note that you are possibly likely to need to update your SPF record for the sending domain to additionally include the following:

  • include:spf.protection.outlook.com
  • ipv4:w.x.y.z (where w.x.y.z is the external IP address(es) of your on-premises Exchange transport servers)

Updating the connector

Once your mail flow tests work, and you can check the route by pasting the received message headers into http://exrca.com you should see that email routes into your Office 365 tenant, then leave EOP (the word “outbound” will be in one of the FQDNs – this server is on the external edge of EOP), then routed inbound to your email provider (or back into your recipient tenant).

Once mail flow works, you can either add more recipient domains to increase the scope of the test – for example add a domain that you email occasionally, such as the partner helping you with this work and a few other domains. Once all your testing is ready change this connector to have * as the address space and not list specific domains.

As your other connector for * is still up and running you will find that 50% of your email will use the new connector and 50% the old. Then you can disable the old connector to go 100% email outbound through EOP (you need an EOP licence per sender to do this, or if you have an Exchange Online licence for each user you are already covered).

Finally when you have been routing on-premises email through EOP for a few weeks with the old connector disabled, you can delete the old connector and tidy up the configuration rather than leaving disabled connectors around.

Duplicate Exchange Online and Exchange Server Mailboxes

Posted on 4 CommentsPosted in duplicate, EOP, exchange, exchange online, Exchange Online Protection, Exchange Server, mailbox, MX, Office 365

With a hybrid Exchange Online deployment, where you have Exchange Server on-premises and Exchange Online configured in the cloud, and utilising AADConnect to synchronize the directory, you should never find that a synced user object is configured as both a mailbox in the cloud and a mailbox on-premises.

When Active Directory is synced to Azure Active Directory, the ExchangeGUID attribute for the on-premises user is synced to the cloud (assuming that you have not do a limited attribute sync and not synced the Exchange attributes – as that is required for Exchange Online hybrid). The Exchange Online directory takes a sync of information relating to Exchange from Azure Active Directory (Azure AD), which is known as forward sync. This ensures that the ExchangeGUID attribute from the on-premises mailbox is synced into your Exchange Online directory.

When a user is given an Exchange Online licence, it becomes the job of Exchange Online to provision a mailbox for this user. When Exchange Online needs to provision a new mailbox, it will not do so where the ExchangeGUID attribute already exists. The existence of this attribute tells the provisioning process that the mailbox already exists on-premises and will be migrated here later and so not to create a conflicting mailbox. A cloud user who does not have an ExchangeGUID attribute synced from on-premises will get a mailbox created by the Exchange Online provisioning process upon a licence being assigned, and on-premises users that do not have a mailbox on-premises (who also have no ExchangeGUID attribute) will also find that granting them an Exchange Online licence will trigger the creation of a mailbox for them.

This is all well and good, and the above is what happens in most cases. But there is an edge case where an on-premises user with a mailbox (and therefore has the ExchangeGUID attribute populated) will also get a mailbox in Exchange Online. This happens where the organization manually created cloud mailboxes before enabling AADConnect to sync the directories, and these cloud users match the on-premises user by UserPrincipalName and they are given an Exchange Online licence.

In this above case, because they are cloud users with an Exchange Online licence they get a mailbox. Deleting the cloud user and then enabling sync will cause the original mailbox to be restored to the user account as the UserPrincipalName matches.

For example, the below shows a user being created in the cloud called “twomailboxes@domain.com”:

image

The user is granted a full Office 365 E3 licence, so this means the user has an Exchange Online mailbox. There is no AADConnect sync in place, but the UPN matches a user on-premises who has a mailbox.

In Exchange Online PowerShell, once the mailbox is provisioned we can see the following:

image

PS> get-mailbox twomailboxes | fl name,userprincipalname,exchangeguid



Name              : twomailboxes
UserPrincipalName : twomailboxes@domain.com
ExchangeGuid      : d893372b-bfe0-4833-9905-eb497bb81de4

Repeating the same on-premises will show a separate user (remember, no AD sync in place at this time) with the same UPN and a different ExchangeGUID.

image

[PS] >get-mailbox twomailboxes | fl name,userprincipalname,exchangeguid



Name              : Two Mailboxes
UserPrincipalName : twomailboxes@cwh.org.uk
ExchangeGuid      : 625d70aa-82ed-47a2-afa2-d3c091d149aa

Note that the on-premises object ExchangeGUID is not the same as the cloud ExchangeGUID. This is because there are two seperate mailboxes.

Get-User in the cloud will also report something useful. It will show the “PreviousRecipientTypeDetails” value, which is not modifiable by the administrator, in this case shows there was not a previous mailbox for the user but this can show that a previous mailbox did exist. For completion we also show the licence state:

image

PS > get-user twomailboxes | fl name,recipienttype,previousrecipienttypedetails,*sku*



Name                         : twomailboxes
RecipientType                : UserMailbox
PreviousRecipientTypeDetails : None
SKUAssigned                  : True

Now in preparation for the sync of the Active Directory to Azure Active Directory, the user accounts in the cloud are either left in place (and so sync will do a soft-match for those users) or they are deleted and the on-premises user account syncs to the cloud. In the first case, the clash on the sync will result in the cloud mailbox being merged into the settings from the on-premises mailbox. In the second case, there is no user account to merge into, but there is a mailbox to restore against this user. And even though the newly synced user has an ExchangeGUID attribute on-premises that is synced to the cloud, and they have a valid licence, Exchange Online reattaches the old mailbox associated with a different GUID.

The impact of this is minor to massive. In the scenario where MX points to on-premises and you have not yet moved any mailboxes to the cloud, this cloud mailbox will only get email from other cloud mailboxes in your tenant (there are none in this scenario) or internal alerts in Office 365 (and these are reducing over time, as they start to follow correct routing). It can be a major issue though if you use MX to Exchange Online Protection. As there is now a mailbox in the cloud for a user on-premises, inbound internet sourced email for your on-premises user will get delivered to the cloud mailbox and not appear on-premises. Where the invalid mailbox has no email, recovery is not required. Finally, where there is a duplicate mailbox, move requests for those users for onboarding to Exchange Online will fail:

image

This reads “a subscription for the migration user <email> couldn’t be loaded”. This occurs where the user was not licenced and so there was not a duplicate mailbox in the cloud, but the user was later licenced before the migration completed.

Where the invalid duplicate mailbox exists in the cloud and is getting valid emails delivered to it, the recovery work described below additionally will involve exporting email from this invalid mailbox and then removing the mailbox as part of the fix. Extraction of email from the duplicate mailbox needs to happen before the licence is removed.

To remove the cloud mailbox and to stop it being recreated, you need to ensure that the synced user does not have an Exchange Online licence. You can grant them other licences in Office 365, but not Exchange Online. I have noticed that if you do licencing via Azure AD group based licencing rules then this will also fail (these are still in preview at time of writing) and that you need to ensure that the user is assigned the licence directly in the Office 365 portal and that they do not get the Exchange Online licence. After licence reconciliation in the cloud occurs (a few minutes typically) the duplicate mailbox is removed (though I have seen this take a few hours). The Get-User cmdlet above will show the RecipientType being a MailUser and not Mailbox.

You are now in a position where your duplicate cloud mailbox is gone (which is why if that mailbox had been a target to valid emails before now, you would need to have extracted the data via discovery and search processes first).

Running the above Get-User and Get-Mailbox (and now Get-MailUser) cmdlets in the cloud will show you that the ExchangeGUID on the cloud object now matches the on-premises object and the duplication is gone. You can now migrate that mailbox to the cloud successfully.

We can take a look at what we see in remote PowerShell here:

Recall from above that there were two different ExchangeGUIDs, one in the cloud and one on-premises. These in my example where:

Cloud duplicate ExchangeGuid      : d893372b-bfe0-4833-9905-eb497bb81de4

On-premises mailbox ExchangeGuid  : 625d70aa-82ed-47a2-afa2-d3c091d149aa

Get-User before licences removed in the cloud, showing a mailbox and that it was previously a mailbox as well:

image

PS > get-user twomailboxes | fl name,recipienttype,previousrecipienttypedetails,*sku*



Name                         : Two Mailboxes
RecipientType                : UserMailbox
PreviousRecipientTypeDetails : UserMailbox
SKUAssigned                  : True

Get-Mailbox in the cloud showing the GUID was different from on-premises:

image

PS > get-mailbox twomailboxes | fl name,userprincipalname,exchangeguid



Name              : Two Mailboxes
UserPrincipalName :
twomailboxes@domain.com

ExchangeGuid      : d893372b-bfe0-4833-9905-eb497bb81de4

Once the licence is removed in Office 365 for Exchange Online and licence reconciliation completes (SKUAssigned is False) you will see that Get-User shows it is not a mailbox anymore:

image

PS > get-user twomailboxes | fl name,recipienttype,previousrecipienttypedetails,*sku*



Name                         : Two Mailboxes
RecipientType                : MailUser
PreviousRecipientTypeDetails : UserMailbox
SKUAssigned                  : False

And finally Get-MailUser (not Get-Mailbox now) shows the ExchangeGUID matches the on-premises, synced, ExchangeGUID value:

image

PS > get-mailuser twomailboxes | fl name,userprincipalname,exchangeguid



Name              : Two Mailboxes
UserPrincipalName : twomailboxes@domain.com
ExchangeGuid      : 625d70aa-82ed-47a2-afa2-d3c091d149aa

Note that giving these users back their Exchange Online licence will revert all of the above and restore their old mailbox. As these users cannot have an Exchange Online licence assigned in the cloud, for risk of their old mailbox returning you need to ensure that within 30 days of their on-premises mailbox being migrated to the cloud you do give then an Exchange Online mailbox. Giving them a licence after migration of their on-premises mailbox to the cloud will ensure their single, migrated, mailbox remains in Exchange Online. But giving their user a licence before migration will restore their old cloud mailbox.

For users that never had a matching UPN in the cloud and a cloud mailbox, you can licence them before you migrate their mailbox as they will work correctly within the provisioning system in Exchange Online.

Enable Report Message Add-In For Office 365

Posted on Leave a commentPosted in add-in, EOP, exchange online, Exchange Online Protection, Office, Office 365, Office 365 ProPlus, phish, phishing, spam

There is a new add-in available for Outlook and OWA in Office 365 that can simplify spam and phishing reporting to Microsoft for content in your mailbox. I recommend rolling this add-in out to everyone in your Office 365 tenant and for Office 365 consultants to add this as part of the default steps in deploying a new tenant.

This can be done with the following steps:

In the Exchange Control Panel at https://outlook.office365.com/ecp/ go to the Organization > Add-Ins section

image

Click the + icon and choose “Add From Office Store”.

In the new tab that appears, search for “Report Message” via the search bar top right:

I’ve noticed that a set of search results appear, then the website notices I am logged in, logs me in and presents a second smaller list of results. It is in this small list that you should see Report Message by Microsoft Corporation

image

I’ve noticed that clicking “Get it now” does not seem to work all the time (the popup has a Continue button that does nothing)! So if that happens, cancel the popup, click the card for the app and install the add from the Get it now button rather than the get it now link on the card. The Report Message app page is shown below with a “Get It Now” button to the left:

image

Either the link or the button should work, and you should get this popup:

image

Click Continue. You are taken to Office 365 to continue. This is the step I eluded to above that sometimes does not work

image

You are asked to confirm the installation of the App into Office 365

image

Click Yes and wait a while. I’ve noticed also that sometimes you need to refresh this page manually for the process to continue, though waiting (with no indication that anything is happening for one or two minutes is usually enough as well)

image

The message above says that the add-in is now visible in the gray bar above your messages. For this add-in this is not correct as this add-in extends the menu in Outlook (2013 and later, as add-ins are not supported in Outlook 2010) and also the app is disabled by default.

Close this tab in your browser and return to the add-in page in Exchange Control Panel that is open in a previous tab.

Refresh the list of apps to see the new app:

image

From here you can enable the app, select a pilot audience, though this app is quite silent in the users view of Outlook and OWA so a pilot is not needed for determining impact to users, but can be useful for putting together quick documentation or informing the help desk of changes.

Select the app and click the edit button:

image

I recommend choosing “Mandatory, always enabled. Users can’t disable this add-in” and deploying to all users. Unchecking the option to make it available for all users makes it available for none. For a pilot choose “Optional, disabled by default”.

You are now done installing the add-in.

Users will now see the add-in in Outlook near the Store icon when a message is selected open:

image

Clicking the icon allows you to mark a messages as “junk”, “phishing” or “not junk” and options and help. Options gives the following:

image

Where the default is to ask before sending info to Microsoft.

Selecting Junk or Phishing will result in the message being moved to Junk Email folder in Outlook, and if in the Junk Email folder, marking a message “Not Junk” will return it to the inbox. All options will send info on the message, headers and other criteria to Microsoft to help adjust their machine learning algoriths for spam and phishing detection. This add-in replaces the need to email the message as an attachment to Microsoft.

For a pilot, users need to add the add-in themselves to Outlook. Mandatory deployment means it is rolled out to users (usually within a few days). To enable the add-in in OWA, click the options cog to the top right of the OWA interface:

image

Then click Manage Add-Ins and scroll down until you find the Report Message add-in (or search for it)

image

And turn the add-in on to view it in OWA as shown:

image

And also it will appear automatically in Outlook for iOS and Outlook for Android and Outlook (desktop, classic).

Once the app is enabled for all users, and recall the above where it takes a while to appear for all users, then your spam and phish reporting in Office 365 is very simple and easy to do and easy to remove from a helpdesk call and on to the end user directly to report and move messages.

SSPT RRAS VPN with Wildcard Certificate–Client Issues

Posted on Leave a commentPosted in rras, sstp, vpn

If you set up an SSTP VPN on Windows RRAS server and are using a wildcard certificate, there are client settings to fix before the client can connect.

If you run the Windows 10 client through the default setup for a VPN you get the following error.

image

This reads “The remove access connection completed, but authentication failed because the certificate on the server computer does not have a server name specified”

Note that this blog is based on 1709, so the steps are slight different than earlier builds as more of the settings have moved to the modern settings dialogs.

Right click the network/wifi icon on the task bar and choose “Open Network  Internet Settings” (with two spaces in the middle – oops, UI bug)

image

This shows the following dialog in Windows 10 RS3 (1709). If on an earlier build you are now on the old style network settings, which is where we are heading anyway

image

Click Status

image

Click Change adapter options

This is the classic Windows networking screen from a number of versions of Windows

Right-click the network connection for the VPN you are having an issue with and choose Properties

image

Change to the Security tab

Then change your settings as shown below:

image

Data encryption: Require encryption

Authentication: Use Extensible Authentication Protocol (EAP): Microsoft Secured password (EAP-MSCHAP v2) (…)

And finally if your machine is a member of the domain that you are signing into, click properties and check the only option here

Office 365 Advance Threat Protection Attachment Preview

Posted on Leave a commentPosted in Advanced Threat Protection, ATP, dynamic delivery, Office 365, Office 365 Advanced Threat Protection, preview

It is now possible to preview attachments that Advanced Threat Protection (ATP) is currently in the process of checking. This was enabled on my tenant recently and so will come to all tenants soon. It was mentioned at Microsoft Ignite 2017.

It looks like this. You get the email with the standard ATP attachment saying your email is being scanned. For this email you need to have Dynamic Delivery enabled for ATP, which means you need your mailbox in Office 365. If you are on-premises or not dynamic delivery then there is no preview function as you do not know that the email is on its way to you for you to preview.

Open the email whilst it is still an ATP Preview alert, and be quick at doing this, at ATP’s attachment scanning 99th percentile is under 3 minutes and the average scanning time for an ATP attachment is 1 minute. Inside the email you will see:

image

Click the preview link and the attachment opens in your browser, rendered by Office Online viewers (which do more than just Office documents)

image

Configuring Hybrid Device Join On Active Directory with SSO

Posted on 9 CommentsPosted in Azure Active Directory, Azure AD, AzureAD, device, device registration, hybrid

The instructions from Microsoft at https://docs.microsoft.com/en-us/azure/active-directory/device-management-hybrid-azuread-joined-devices-setup are missing some of the steps on setting up hybrid device join to Azure AD. This is a complete list of steps when Pass-Thru auth with SSO is enabled on the domain.

  1. Enable SSO – this is covered elsewhere. You can also do hybrid device join on a federated domain, though this is not covered here.
  2. On your AADConnect server ensure that the MSOnline PowerShell add in is installed – this is the AdministrationConfig-3.msi executable that is needed to run cmdlets like Get-MSOLUser. Is only supported by the MSOnline PowerShell module version 1.1.166.0. To download this module, use this link
  3. Open an administrative PowerShell
  4. cd 'C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep'
  5. Import-Module .\AdSyncPrep.psm1
  6. This will enable the AD module and import some scripts for device writeback and device registration. We are looking at device registration here
  7. $aadAdminCred = Get-Credential

    #Enter a global admin credential

  8. Initialize-ADSyncDomainJoinedComputerSync –AdConnectorAccount [connector account name] -AzureADCredentials $aadAdminCred

    #[connector account name] is the name of your domain (domain.local for example) as shown in the AADConnect Synchronization Service Manager –

  9. You should see the message “Initializing your Active Directory forest to sync Windows 10 domain joined computers to Azure AD.” followed by “Configuration Complete”. Errors about Azure Registration mean you are running the wrong version of the Azure AD PowerShell cmdlets
  10. The required settings in AD (for one forest) are now done. If you have multiple forests, return to the above referenced document and run the script to register the Devices Registration Configuration node to AD
  11. If you have conditional access available (have at least one Azure AD Premium licence assigned to your admin account) then you can add Trusted Sites to Azure AD to control where MFA prompts for device join will happen outside of. Add each office public NATed IP address with /32 (or whatever is needed at the end) into Azure Active Directory (under portal.azure.com) > Conditional Access > Named Locations > New Location
    image
  12. Add the same IPs to the “Configure MFA trusted IPs” link on the same page that you see the IP’s listed above
  13. Your list of devices under Azure Active Directory should now increase as users reboot Windows 10 1703 machines and later. See the above document about the GPO setting needed to role this out to older versions of Windows (Workplace Join settings)

Conversation Red Number in Skype For Business That Won’t Go Away

Posted on Leave a commentPosted in conversation, exchange online, Exchange Server, Outlook, Skype For Business Online, Skype for Business Server

I have had this issue for ages, but could not find any answer for it on the internet that did not involve resetting Skype for Business or other complex stuff when in fact the answer is so easy it hurts! Finding it was one of those Duh! moments.

You have this:

image

Skype for Business shows a red flag in one of the sections that will not go away. In my case it was the Conversation History pane and all the conversations in the view were read!

Then one day in Outlook I noticed the Missed Conversations view in Outlook:

image

Its a Search View and it was already active for me, but look – it also says one conversation. So I scrolled down the list of conversations in Outlook, found the unread one and the issue went away in Skype for Business within seconds.

image

image

This issue will probably be true for Teams as well when Outlook Conversation History functionality moves over to that product as well from Skype for Business Online

Office 365 and ACDC

Posted on Leave a commentPosted in acdc, anycast, cafe, exchange online, Exchange Server, networking, Office 365

The best connectivity to Office 365 is achieved with local internet breakout and local DNS egress. This means things like each branch office should connect directly to the internet and not via the Head Office and then to the internet and that DNS lookups are done local as well. The reason for DNS lookups is to do with AnyCast and DNS resolution. Microsoft see where you make your DNS requests from and return responses to Office 365 that are near where the DNS egress point is. So if you lookup DNS from the head office in a different county, but still have local internet breakout, you might connect to the Office 365 endpoints close to the head office and not the endpoints in your country.

To test this, it used to be the case that you could ping outlook.office365.com and see what FQDN was returned and ensure that it was in the same geography to where you are. At the time of writing this is still the case some of the time, but it is changing.

Therefore, lets say you were located in Europe and you ran “ping outlook.office365.com” – it might return something in the URL that looked like EMEA-WEST. If it returned US anything then you had an issue with DNS and maybe internet egress. An example of how it always used to be was:

image

This was a great test until recently, but in the last few months this DNS lookup has changed to connect to an endpoint called ACDC. For example now it might show:

image

This is a connection to the ACDC endpoint, which is AnyCast DNS Cafe, where Cafe is the Client Access Front End service, or the Front Door service to Exchange Online. Not the data location, but a service endpoint close to you to do SSL connectivity and work out where your mailbox is and to connect to that endpoint. In the last year by changing to the ACDC endpoint technology, Microsoft have reduced latency to cloud hosted Exchange Online in the region of 100ms.

Unfortunately this means a simple test for local internet egress has stopped working and you need to investigate further the route taken to reach the Microsoft network. A suggestion simple test for this is tracert. For this you need to run “tracert outlook.office365.com”. This has the risk of being blocked at the firewall, as ICMP is often restricted even though it is used to help modulate TCP window size and other useful network packet adjustments, but an idea can be got from running tracert to the same location as the ping.

For example, ping outlook.office365.com for me was returning an RTT (round trip time) of 17ms. Tracert showed similar:

image

In my case I was getting the following:

Tracing route to outlook.ms-acdc.office.com [40.101.72.194]
over a maximum of 30 hops:

  1     1 ms    <1 ms     2 ms  192.168.0.1
   2     1 ms     2 ms     1 ms  192.168.5.1
   3     *        *        *     Request timed out.
   4     9 ms     9 ms     9 ms  oxfd-core-2a-xe-003-0.network.virginmedia.net [62.254.128.161]
   5     *        *        *     Request timed out.
   6     *        *        *     Request timed out.
   7    12 ms    11 ms    13 ms  tcma-ic-2-ae9-0.network.virginmedia.net [62.253.174.178]
   8    12 ms    12 ms    12 ms  213.104.85.230
   9    20 ms    20 ms    19 ms  be-71-0.ibr02.dbb.ntwk.msn.net [104.44.9.180]
  10    19 ms    18 ms    18 ms  104.44.10.150
  11     *        *        *     Request timed out.
  12     *        *        *     Request timed out.
  13     *        *        *     Request timed out.
  14     *        *        *     Request timed out.
  15    22 ms    17 ms    18 ms  40.101.72.194


Trace complete.

From this we can see 18ms to the first hop on Microsoft’s network. Full RTT and latency for Outlook can be found on the Connection Status dialog, as this includes the processor time in Exchange Server/Exchange Online and the network RTT to the server that contains the data and not just the Microsoft Front Door CAFE service.

Outlook Authentication Broken–Username and Password Missing

Posted on Leave a commentPosted in Authentication, windows 10, windows 7

I came across an issue recently where the Outlook security dialog box popup was broken. Rather than looking as below, the username and password fields where missing:

windows_security.jpg

The dialog box appeared as:

image

Notice that the username and password fields are missing! Also missing, and the key to this issue, is the picture is missing too. This is usually an empty box, but for some companies they use Group Policy to push out a different graphic.

That image is a bitmap stored in “C:\ProgramData\Microsoft\User Account Pictures”.

At a client of mine, the marketing department had requested the company logo replace the user picture and provided at 1MB file for this purpose. The file was deployed to all machines and overwrote the user.bmp by way of GPO preferences. Resizing user.bmp to under 48K in “C:\ProgramData\Microsoft\User Account Pictures\” on a single machine resolved the issue for users on that computer. We then changed the source of the image to under 48K centrally to fix all users.

Note that this was Windows 7 – different file sizes and dimensions exist for different versions of Windows. For example a user.bmp file on Windows 10 can be 448×448 and the default is just under 600KB. So again, the 1MB file mentioned above might also break Windows 10, but to fix the issue on that OS I probably dont need to reduce the file size so small.

Unexpected Security and Compliance Center Changes

Posted on Leave a commentPosted in Advanced Threat Protection, ATP, EOP, malware, Safe Attachments, Safe Links, Security and Compliance Center, Threat Management

In the last few days the layout of the Security and Compliance Center with regard to the Threat Management section appears to have changed.

In the middle of the week just gone, and for a long while previously, you could access Mail Filtering, Anti-malware, and DKIM from Security and Compliance > Threat Management and see these items as entries on a menu:

For example, Advanced Threats

image

For example, Mail Filtering

image

But in the last two days there has rolled out across a number of tenants without any notice a change to the Threat Management menus. Now all you see if Review and Policy. The below picture shows the Review area:

image

Policy area: This contains the previous menu items such as anti-malware, ATP Safe Links etc.

image

Depending upon your licences, this will appear different. For example the below is what an EOP only tenant would see from today:

image