Just a quick post on SPF and DMARC when you have a domain that’s not used for email. In this scenario mail will never be sent out by any mailserver. If someone does send out email, it is most likely malicious email and can be ignored.
You can add the following records to your DNS:
SPF:
V=spf1 -all
DMARC:
v=DMARC1;p=reject;sp=reject;pct=100
Receiving mail servers that check for SPF and DMARC will see that it’s not valid and will reject the message.
Recently users started to complain that free/busy information was not available, more specifically users that had their mailbox in Exchange Online were not able to retrieve availability information from their colleagues or meeting rooms that were still in Exchange 2010 on-premises.
Complaints came from multiple users from multiple countries, there are multiple sites with multiple Exchange 2010 servers with multiple breakout points to the Internet, so the issue was consistent and not really related to only one Exchange 2010 server. And it was only happening cross-premises, and only from Exchange Online to Exchange 2010. From Exchange 2010 to Exchange Online it was working flawlessly, so was between mailboxes in Exchange 2010.
You see this happen often right after configuring an Exchange hybrid configuration with the HCW, but in my case it had been working fine for quite some time, so it had to be related to something we had changed recently. We had WLAN changes (new provider), Windows Update, Exchange 2010 rollup updates, SSL certificates, new Send and Receive Connectors, but nothing that immediately pointed in the right direction. To make things worse, the Remote Connectivity Analyzer (your first stop when troubleshooting) didn’t see any issues, everything worked well. Autodiscover returned the correct information from mailboxes in Exchange Online and Exchange 2010, and the free/busy test in RCA worked well.
Note. A lot of people don’t know this feature, but in the Remote Connectivity Analyzer you can check free/busy in a hybrid environment. Just select the Free/Busy radio button under the Office 365 tab as shown in the following screenshot:
My mailbox was in Exchange Online and I also did experience the issue, but at the same time I was able to open the calendar cross-premises. Ok, this is Outlook Anywhere and not Exchange Web Services (which is used for free/busy) but at least it ruled out a firewall issue.
When running the Get-OrganizationRelationship command, I could verify the TargetAutodiscoverEpr property, which was set to the correct Autodiscover URL. Using the TargetSharingEpr property instead of the TargetAutodiscoverEpr property didn’t help.
Get-FederationInformation command with the -DomainName switch… all looks good.
Security on the Virtual Directory? Running these commands often solve unexpected issues:
Get-AutodiscoverVirtualDirectory | Set-AutodiscoverVirtualDirectory -WSSecurity $true Get-WebServicesVirtualDirectory -Server WPGREXC01 | Set-WebServicesVirtualDirectory -WSSecurity $True
Again, no success… Time for deeper troubleshooting. At this moment Microsoft support was already involved as well….
When testing I could see the request entering the Exchange 2010 server in the IIS logs, but the servers returned a 500 Error, so something in the request was causing issues on the Exchange server:
2019-10-14 06:45:06 192.168.25.119 POST /ews/exchange.asmx/WSSecurity – 443 – 52.97.155.157 ASProxy/CrossForest/Directory/https/15.20.2347.020/MailTips – 500 0 0 31
2019-10-14 06:45:33 192.168.25.119 POST /ews/exchange.asmx/WSSecurity – 443 – 52.97.140.165 ASProxy/CrossForest/Directory/https/15.20.2347.020/MailTips – 500 0 0 31
2019-10-14 06:45:51 192.168.25.119 POST /ews/exchange.asmx/WSSecurity – 443 – 52.97.139.125 ASProxy/CrossForest/Directory/https/15.20.2347.020/Freebusy – 500 0 0 15
2019-10-14 06:45:51 192.168.25.119 POST /ews/exchange.asmx/WSSecurity – 443 – 52.97.158.5 ASProxy/CrossForest/Directory/https/15.20.2347.020/MailTips – 500 0 0 31
2019-10-14 06:45:51 192.168.25.119 POST /ews/exchange.asmx/WSSecurity – 443 – 52.97.139.125 ASProxy/CrossForest/Directory/https/15.20.2347.020/MailTips – 500 0 0 31
The next step to try was to recycle the AutodiscoverAppPool and the ExchangeServicesAppPool in the IIS Manager, but unfortunately this didn’t help.
After looking out of the window what might be the issue I had another look at the eventlog on the Exchange server, and found the following certificate warning:
Log Name: Application
Source: MSExchange Common
Date: 10/16/2019 9:28:59 AM
Event ID: 403
Task Category: Configuration
Level: Error
Keywords: Classic
User: N/A
Computer: Exchange.contoso.com
Description:
The certificate named ‘791BC6AD9893AA570DF03452B4F8069C8A743C29’ in the Federation Trust ‘Microsoft Federation Gateway’ is expired. Please review the Federation Trust properties and the certificates installed in the certificate store of the server.
This rings a bell. The certificate with the thumbprint mentioned in the error message is not on the Exchange server, but it’s in the Microsoft Federation Gateway. I didn’t see this earlier, but when checking the federation with Get-FederationTrust | FL you can see certificate information, and one certificate expired some time ago. July 2019 to be precise.
You can also run the Test-FederationTrust on the Exchange server. If you ran into this issue, you should see an error message like Failed to validate delegation token in the TokenValidation section.
Fixing this is easy, just run the following command:
Get-FederationTrust | Set-FederationTrust -RefreshMetadata
After running this command it works like a charm.
This only happens in Exchange 2010 (in Exchange 2013 and higher it is fixed automatically), and looking at the support chances are you are not running Exchange 2010 anymore when other certificates are renewed. You can running the command mentioned before on a regular basis, or you can use a scheduled task to perform this automatically on a regular basis.
Schtasks /create /sc Daily /tn FedRefresh /tr “C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
-version 2.0 -command Add-PSSnapIn Microsoft.Exchange.Management.PowerShell.E2010;
$fedTrust = Get-FederationTrust;Set-FederationTrust -Identity $fedTrust.Name -RefreshMetadata” /ru System
So why didn’t we notice this in the first place? The certificate change was announced by Microsoft and other community blogs, but this was summer holiday time. Also lack of resources in IT Staff didn’t help either. Too bad, but in the end it was fixed (with help of Microsoft support 😊)
There are lots of organizations running Exchange 2010 hybrid, but with the upcoming end-of-life of Exchange 2010 it’s time to move on. Sometimes it’s not always possible to move everything to Exchange Online, so then you must migrate from Exchange 2010 hybrid to Exchange 2016 hybrid.
When preparing Active Directory for Exchange 2016 using the /PrepareSchema swith the following error is (sometimes) raised:
A hybrid deployment with Office 365 has been detected. Please ensure that you are running setup with the /TenantOrganizationConfig switch. To use the TenantOrganizationConfig switch you must first connect to your Exchange Online tenant via PowerShell and execute the following command: “Get-OrganizationConfig | Export-Clixml -Path MyTenantOrganizationConfig.XML”. Once the XML file has been generated, run setup with the TenantOrganizationConfig switch as follows “/TenantOrganizationConfig MyTenantOrganizationConfig.XML”.
If you continue to see this this message then it indicates that either the XML file specified is corrupt, or you are attempting to upgrade your on-premises Exchange installation to a build that isn’t compatible with the Exchange version of your Office 365 tenant. Your Office 365 tenant must be upgraded to a compatible version of Exchange before upgrading your on-premises Exchange installation. For more information, see: http://go.microsoft.com/fwlink/?LinkId=262888
For more information, visit: http://technet.microsoft.com/library(EXCHG.150)/ms.exch.setupreadiness.DidTenantSettingCreatedAnException.aspx
(unfortunately the last link doesn’t show any useful information, and it hasn’t been updated since the early Exchange 2013 days).
Note. I’m not sure when and why this message pops up. Right now, it looks like it only happens in older tenants where Exchange 2010 hybrid is already running for some time. If you have more information about this, please feel free to leave a comment.
As stated in the error message you must run the following command in an Exchange Online PowerShell window:
Get-OrganizationConfig | Export-Clixml -Path C:\Install\MyTenantOrganizationConfig.XML
This retrieves the organization configuration from Exchange Online and exports it to an XML file. When opening the XML you can read the organization configuration as shown in the following screenshot:
There’s a pitfall when continuing, the /TenantOrganzationConfig switch that’s in the message is a switch that can only be combined with the /PrepareAD switch, it cannot be used with the /PrepareSchema switch. If you do, it will raise a “The parameter ‘tenantorganizationconfig’ is not valid for current operation ‘PrepareSchema’” Error message.
So, you must continue with the following command:
Setup.exe /PrepareAD /TenantOrganizationConfig C:\Install\TenantOrganizationConfig.XML /IAcceptExchangeServerLicenseTerms
Note. Running the /PrepareAD switch will automatically trigger the/PrepareSchema switch.
Now you can continue with the /PrepareDomain switch, followed by the installation of your first Exchange 2016 server in the existing Exchange 2010 environment.
Office 365 Message Encryption (OME) is a Microsoft solution to send mail safely, fully encryption with multiple layers of protection. Instead of sending an email to a recipient via SMTP, the message is encrypted and stored on a Microsoft viewing portal. An informational message is sent to the recipient with a one-time password which the recipient can use to logon to the viewing portal and read the (decrypted) message as shown in the following picture:
To configure OME you have to enable Azure Rights Management first. To do this, open the Office 365 Admin portal and select Settings | Services & Add-ins. In the details pane select Microsoft Azure Information Protection. Click Manage Microsoft Azure Information Protection Settings as shown in the following screenshot:
Click Activate and after a few moments you will see a confirmation.
If you open Exchange Online Powershell and execute Get-IRMConfiguration you will see that AzureRMS is enabled as shown in the screenshot below. Please note that the LicensingLocation is empty, this is important in subsequent steps.
According to Microsoft documentation you should now be able to test the IRM configuration using the Test-IRMConfiguration command, but this will fail with a “Failed to acquire RMS templates” error as shown in the following screenshot:
The reason for this (took me some time to figure out) is that the LicensingLocation property is empty. To populate this property, we can retrieve the correct value from the Azure AD Right Management service using PowerShell. This can be installed using the Install-Module AIPService command.
After installing, open the Exchange Online PowerShell module and execute the following commands:
PS C:\> $RMSConfig = Get-AadrmConfiguration
PS C:\> $RMSConfig
PS C:\> $LicenseUri = $RMSConfig.LicensingIntranetDistributionPointUrl
PS C:\> $LicenseUri
PS C:\> Set-IRMConfiguration -LicensingLocation $LicenseUri
PS C:\> Set-IRMConfiguration -InternalLicensingEnabled $true
Note. The only reason for executing the $RMSConfig and $LicenseUri commands is to check is there are any values in these variables. The output is shown in the following screenshot:
When you execute the Test-IRMConfiguration command again you will see it succeeds:
So how do you know this works?
The easiest way is to use OWA. To create an additional “encrypt” button in OWA, execute the following command in the Exchange Online PowerShell window:
PS C:\> Set-IRMConfiguration -SimplifiedClientAccessEnabled $true
Now when creating a new message in OWA this button is clearly visible. Send a new message (to your own test account for example in Gmail) and click the Encrypt button. A message will appear that this message is encrypted, nice to know, the recipients cannot remove the encryption, only the sender of the message can change this. You can use the change permissions button to change it from encrypt only to do not forward or confidential.
After a few second the email will appear in Gmail, but not directly. You have to open the decrypted message on the viewing portal. A one-time password can be used (which is sent to the same email address, i.e. the Gmail address we used here) or you can use the Gmail account to logon. The latter is also true if the recipient is a hotmail mailbox or even nicer, an Office 365 mailbox.
When you click Read the message it will be opened on the viewing portal.
A message is displayed again that this is an encrypted message. When you reply to the message, an encrypted message is returned to the original sender. If you have selected do not forward in the permissions drop down box earlier, the recipient does not have this option and can only reply to the message.
It also works fine in Outlook (I have tested this with Outlook 2016 Click-2-Run, still have to test other versions). If you create a new message and select Options, you can select Connect to Rights Management Server and get templates under Permissions as shown in the following screenshot:
This will retrieve the RMS templates from Exchange Online that were created earlier in this blog post. In a few seconds you will see the following options:
When you select Encrypt Only as shown in the following screenshot an encrypted message will be sent to the intended recipient:
From this point the behavior will be the same as with Outlook Web App as discussed earlier in this blog post.
Outlook Message Encryption as outlined in this blog post is a way to send encrypted messages to recipients. It’s not encryption in transit like TLS or S/MIME, but the encrypted message is stored on a Microsoft server. The recipient will receive an email that an encrypted message is waiting, and the recipient can logon to a special website using a one-time password (or using a Microsoft or Gmail account).
Since the RMS (Rights Management Service) templates are used it is also possible to use additional features like do not forward (the forward button is greyed out) or tag a message as confidential. This can be used in combination with transport rules to add additional features or mail flow when it comes to confidential information, functionality that’s not available when using good old email.
Every now and then we get a call from end users that they cannot login at Microsoft Teams and they get an error message “The request is not properly formatted” and “The parameter ‘login_hint’ is duplicated.“, especially after changing the user password. The error message is (partly in Dutch) shown in the following screenshot:
This error message is recurring, so it’s not possible to logon anymore. It looks like there’s something stored in a cache related to the user’s old credentials. To resolve this, you can follow these steps:
When all files are deleted you can start the Teams client again and it should logon successfully.
