de-DEen-GB
 
rss

Just can't get enough of IT

This blog is about mostly anything in IT. But the primary focuses are Microsoft Technologies like Exchange, Office 365, Azure and Cloud Security.

This blog post focusses on an issue where your Exchange Online users are not able to send emails to other Exchange Online recipients outside of your organization when using a 3rd Party Centralized Email Flow Setup. The term 3rd Party Centralized Email Flow Setup describes a solution where you not follow the preferred hybrid architecture proposed by the Exchange product group, but use a 3rd party software as a centralized email gateway.

Problem

You have followed the recommendation to secure the Exchange Online inbound connector for your on-premises email servers by using a certificate name or the remote IP address of your on-premises email gateway.

Assumption

The on-premises email security gateway utilizes a self-signed certificate to secure TLS connections. The gateway is configured to use two different send connector setups:

  • Internet Connector
    Use receipients domain MX records
    Use self-signed certificate
    Target address space: *
     
  • Office 365 Connector
    Use tenant.mail.protection.outlook.com to route internal email messages
    Use self-signed certificate
    Target address space: tenant.mail.onmicrosoft.com

In this case Exchange Online Protection (EOP) will not be able to differentiate between tenant internal inbound mail flow and mail flow targeted to other tenants. Therefore, email messages sent from your Exchange Online users to recipients located in other Exchange Online tenants will be discarded.

Interestingly enough, this will happen silently. Your gateway solution will log a successful delivery to Exchange Online Protection. The tenant administrator of the recipient domain will not find an any information in the Exchange Online message tracking logs.

The following diagram illustrates the setup.

Broken mail flow to other Exchange Online tenants

Solution

The solution for this problem is pretty simple. Just use dedicated certificates for each connector targetting Exchange Online.

Change the Internet Connector to fully trusted 3rd party certificate. In this case you are not required to modify the existing Exchange Online inbound connector setup.

The new connector configurations are:

  • Internet Connector
    Use receipients domain MX records
    Use 3rd party certificate
    Target address space: *
     
  • Office 365 Connector
    Use tenant.mail.protection.outlook.com to route internal email messages
    Use self-signed certificate
    Target address space: tenant.mail.onmicrosoft.com

The following diagram illustrates the new setup:

Workign mail flow to other Exchange Online tenants

 

Links

Enjoy!

 

 

Read More »

Exchange Server 2013Exchange Server 2016Problem

Out-of-Office (OOF) messages have to follow the compliance rules as regular email communication. This is not necessarily a known fact to end users.

If a company does have a strict compliance policy regarding external OOF messages you can use the following solution to establish a strict and simple to use OOF configuration. 

Only specific employees are supposed to send OOF messages to external recipients. All other employees are supposed to send internal OOF messages only.

Solution

The solution consists of two PowerShell scripts.

The first script is used to remove any exisiting OOF rules created by a user using the Outlook OOF Rule Wizard. This is required to avoid any strange behaviours in regards to OOF messages being sent even if OOF is deactivated. The most common reasons for such a behaviour are migrated OOF rules created by previous Exchange Server versions.

  1. Remove-OOFRule.ps1

    This script finds and removes all OOF rules for all users using Exchange Web Services (EWS).
    This script is supposed to be executed in preparation for the next script.  
     
  2. Set-ExternalOOF.ps1

    This script sets the ExternalOofOptions attribute of a user mailbox depending on an Active Directory group membership. After cleaning up all OOF rules in step one, you will be able to control the OOF settings by group membership. 

You can read more about scripts here:

You can use the follow command line example, if you want to automate the execution of script 2 using a scheduled task.

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -version 3.0 -command ". 'D:\Program Files\Microsoft\Exchange Server\V15\bin\RemoteExchange.ps1'; Connect-ExchangeServer -auto; "D:\Scripts\Set-ExternalOOF\Set-ExternalOOF.ps1 -RemoveRights"

 

Follow

Read More »

Exchange Server 2013Exchange Server 2016Description

This script searches for OOF rules created by users using the Outlook rule-tab in the OOF assistant and deletes exisiting OOF rules.

In preparation to configure compliant Out-Of-Office (OFF) settings for users, any existing OOF rule needs to be deleted. The script will use either an exisiting Exchange Server EWS library or the Managed EWS library installed using the default file path.

This is the first of two scripts for the complete solution. Find the second script here.

The script access the mailbox rules using Exchange Web Services. Therefore the account executing the script either needs to have ApplicationImpersonation rights or full access to the user mailbox.

Requirements

Examples

# EXAMPLE 1
# Find any existing OOF rule and write results to log file
Remove-OOFRule 

# EXAMPLE 2
# Find and delete any existing OOF rules in all user mailboxes and write delete actions to log file
Remove-OOFRule -Delete

# EXAMPLE 3
# Find and delete any existing OOF rules for user SomeUser@varunagroup.de and write delete actions to log file
Remove-OOFRule -Mailbox SomeUser@varunagroup.de -Delete

Version History

  • 1.0, Initial community release

Links

Additional Credits

Rhoderick Milne (https://blogs.technet.microsoft.com/rmilne)

Follow

 

 

Read More »

Exchange Server 2013Exchange Server 2016Description

This script sets the mailbox ExternalOofOptions to 'External' for members of a given security group.

ExternalOofOptions for users that are NOT a member of the security group will be set to 'InternalOnly'. If required the script will set the ExternalAudience to None and will delete an existing OOF message.

Controlling the ExternalOofOptions and ExternalAudience settings has been implemented to follow dedicated company compliance rules.

This is the second of two scripts for the complete solution. Find the first script here.

Requirements

Examples

# EXAMPLE
# Run script with default settings
.\Set-ExternalOOF.ps1

Version History

  • 1.0, Initial community release

Links

Follow

 

Read More »
On May 21, 2017
0 Comment
737 Views

Troubleshooting Active Directory Federation Services is a tedious tasks for any administrator. Therefore, I've started this blog post to have a comprehensive overview of information sources.

The following list provides links for Active Directory Federation Services troubleshooting:

Additonal information about AD FS can be found here: 

If you know of other AD FS troubleshooting information, please use the comments section below to share.

 

 

Read More »