de-DEen-GB
 
MVP - Most Valuable Professional
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.

Exchange Server extends the Active Directory schema during the PrepareSchema step during setup. The steps PrepareAD, PrepareDomain, or PrepareAlLDomains create Active Directory containers and objects that are crucially important for a stable operation of Exchange Server.

There are different Active Directory objects that are used to determine, if Active Directory has a proper Exchange Server configuration up and running.

Forest level

At Active Directory forest level the following attributes are used to determine the Exchange Server release:

  • rangeUpper attribute of the ms-Exch-Schema-Version-Pt schema object 
  • msExchProductId attribute of the Exchange organization object in the configuration partition
  • objectVersion attribute of the Exchange organization object in the configuration partition
  • objectVersion of the Microsoft Exchange System Objects (MESO) container 

Domain level

At Active Directory domain level the following attribute is used to determine the Exchange Server release:

  • objectVersion of the Microsoft Exchange System Objects (MESO) container 

 

I have written a PowerShell script to fetch all required information for all domains in an Active Directory forest. The script simplifies the process of gathering the data.
Read more about the script here.

 

Schema versions

Exchange

Forest (rangeUpper)

Forest (objectVersion)

Domain (objectVersion)

Exchange Server 2000

2000 RTM

4397

N/A

4406

2000 SP3

4406

N/A

4406

Exchange Server 2003

2003 RTM

6870

6903

6936

2003 SP2

6870

6903

6936

Exchange Server 2007

2007 RTM

10637

10666

10628

2007 SP1

11116

11221

11221

2007 SP2

14622

11222

11221

2007 SP3

14625

11222

11221

Exchange Server 2010

2010 RTM

14622

12640

12639

2010 SP1

14726

13214

13040

2010 SP2

14732

14247

13040

2010 SP3

14734

14322

13040

Exchange Server 2013

2013 RTM

15137

15449

13236

2013 CU1

15254

15614

13236

2013 CU2

15281

15688

13236

2013 CU3

15283

15763

13236

2013 SP1

15292

15844

13236

2013 CU5

15300

15870

13236

2013 CU6

15303

15965

13236

2013 CU7-CU9*

15312

15965

13236

2013 CU10-CU20*

15312

16130

13236

Exchange Server 2016

2016 Preview

15317

16041

13236

2016 RTM

15317

16210

13236

2016 CU1

15323

16211

13236

2016 CU2

15325

16212

13236

2016 CU3

15326

16212

13236

2016 CU4-CU5*

15326

16213

13236

2016 CU6

15330

16213

13236

2016 CU7-CU9*

15332

16213

13236

 

*Note
It is recommended to always run the Active Directory preparation using Setup.exe /PrepareAD before applying an new cumulative update. Even though that the schema version might not have changed from the previous version preparing Active Directory applies any updates or changes to the default RBAC configuration.

 

Links

 

Enjoy Exchange Server!

Read More »

Exchange Server 2010Exchange Server 2013Exchange Server 2016PowerShellDescription

This script reads the Exchange schema version from the Active Directory schema partition.

The Exchange organization name is fetched from Active Directory automatically.
  
The script fetches at forest level:

  • objectVersion of MESO Container
  • rangeUpper of ms-Exch-Schema-Version-Pt 
  • msExchProductId of Exchange Organization container
  • objectVersion of Exchange Organization container

The script fetches at domain level:

  • objectVersion of MESO Container

 

Examples

Code Samples

# Fetch all version information in the Active Directory forest
.\Get-ExchangeServerVersionInfo.ps1

Sample Output:

PS D:\Scripts> .\Get-ExchangeServerVersionInfo.ps1

Exchange Server Schema and Object Information for forest [VARUNA.ROOT]
Exchange Organization Name        : VARUNA-GROUP
Active Directory Schema rangeUpper: 15332

Working on VARUNA.ROOT
MESO Container objectVersion           : 13236
Exchange Configuration msExchProductId : 15.01.1466.003
Exchange Configuration objectVersion   : 16213

Working on VARUNAGROUP.DE
MESO Container objectVersion           : 13236

Version History

  • 1.0, Initial community release

Links

Follow

 

Enjoy Exchange Server!

Read More »

You might have the requirement to authenticate mobile devices and authorize user access to on-premises Exchange Server mailboxes using a multi-vendor strategy. This blog post focuses on the configuration of a Kemp LoadMaster located in an internal network segment. The Kemp LoadMaster ESP functionality is used to allow ActiveSync connections for members of a dedicated security group only.

This results in the following authentication and authorization endpoints:

  • MobileIron access policies
  • Kemp LoadMaster ESP security group membership validation
  • Exchange Server ActiveSync client access allowance 
  • Exchange Server mobile device policy

 

Overview

The following diagramm shows a simplified overview for mobile devices connecting to an on-premises Exchange Server. The perimeter and internal network segments are omitted for simplification reasons.

Mobile Device Connect to Exchange Server using Sentry and LoadMaster

  1. A MobileIron managed device connects to MobileIron Sentry which validates access with MobileIron policies
  2. If a MobileIron policy allows access the device connects to Kemp LoadMaster ESP
  3. Kemp LoadMaster ESP configuration validates the security group membership of the authenticating user
  4. If the user is a member of the security group the device connects to Exchange Server
  5. Exchange Server authenticates the user an checks, if the ActiveSync protocol is enabled and the device complies with Exchange Server MDM configuration

 

Kemp LoadMaster Virtual Service

The following screenshots illustrate a working setup for a virtual service load balancing mobile device connections from MobileIron Sentry to Exchange Server. It's assumed that you've already configured the following:

  • SSO Domain settings for connecting to a domain controller to authenticate users

 

SSL Properties

The SSL Traffic is offloaded and re-encrypted as we need to authenticate the user with ESP. Ensure to select a Cipher Set thta does not provide any weak or unsecure cipher suites. In this example I've selected the predefined set BestPractices.

Kemp Virtual Service | SSL Properties

 

ESP Options

Enable ESP to activate the ESP configuration section. The settings are as follows:

  • Client Authentication Mode: Basic Authentication
    Be aware that this setting requires that MobileIron users are provisoned using DOMAIN\SamAccountName notation and not the UPN Name
  • SSO Domain: An exisiting SSO Domain configuration for user authentication
  • Allowed Virtual Hosts: The FQDN matching the Load Master virtual service IP address accessed by MobileIron Sentry to connect to Exchange Server
  • Allowed Virtual Directories: Can be limited to /Microsoft-Server-ActiveSync otherwise leave the default /*
  • Permitted Groups: The name of the Active Directory security group containing the allowed users
  • Server Authentication Mode: Basic Authentication

 

Kemp Virtual Service | ESP Options

 

Real Servers

In the Real Servers section you add all member servers of your Exchange Server DAG. Ensure to use the HTTPS protocol the health checks and ensure to query the /Microsoft-Server-ActiveSync/healthcheck.htm document.

Kemp Virtual Service | Real Servers

 

Using this configuration you've added your Kemp LoadMaster as an additonal authentication endpoint to secure mobile device access to Exchange Server mailboxes.

Enjoy!

Read More »

Exchange Server 2010Exchange Server 2013Exchange Server 2016PowerShellDescription

When migrating to new version of Exchange Servers you must move your internal SMTP relay endpoints. This can be a challeging tasks as application owners mostly ignore your requests for such changes. 

You can use the information provided in the receive connector log files to identify remote clients (MTAs / MTUs) connecting to the legacy infrastructure. The assumption is that protocol logging is enabled. You can easily active protocol logging across all receive connector fo a single server using the following EMS PowerShell one-liner:

Get-ReceiveConnector -Server EX01 | Set-ReceiveConnector -ProtocolLoggingLevel Verbose

The scripts searches the log files for the connection's EHLO response which containes the remote name or remote IP-address of the system connecting to the receive connector.

You can either search

  • Legacy Exchange Servers (aka Exchange Server 2010)
  • Modern Exchane Servers 
    • Frontend Transport
      or
    • Backend Transport (aka Hub Transport)

For more information read the readme.md file at Github.

Note

You need to adjust the log file path to suit your IT infrastructure. A next releas will contain a more automatic solution.

Examples

# Search legacy Exchange servers SMTP receive log files for the last 4 days and save search results in a single CSV file

.\Get-RemoteSmtpServers.ps1 -Servers SRV01,SRV02 -LegacyExchange -AddDays -4 -ToCsv

Version History

  • 1.0, Initial community release 
  • 1.1, Fixed Issue #2

Links

Follow

 

Read More »
This article was originally posted on April 1st 2018


The latest downloadable build of Exchange Server 2016 Cumulative Update 9 disclosed an information that was previously shown accidently to the public by Greg T. during his breakout session BRK3249 - Modern Authentication for Exchange Server On-Premises at Microsoft Ignite 2017.  

BRK3249 - Modern Authentication for Exchange Server On-Premises

As part of the global harmonization of the product name space of the well established Outlook brand the next release of Exchange Server will be named Outlook Server 2019.

This name change was mentioned originally on this slide:

BRK3249 - Modern Authentication for Exchange Server On-Premises - Leak

 

Give it a thought and you'll realize that this change makes absolute sense as different product names for the same software function distract customers and users. 

  • Outlook
  • Outlook for iOS
  • Outlook for Android
  • Outlook on the web
  • Outlook Server

Another reason for renaming Exchange Server is a new functionality for integrating personal mailbox files (PST). It was and still is a tedious task for administrators to get hold of all those PST files in use by end users. Instead of implementing a complex and data protection safe process to import PST files to the primary users mailbox the new Outlook Server 2019 offers synchronized PST folders. A functionality we've waited for for years.

Two new functions are introduced as part the new modern Outlook Server 2019

  • PST Sync
    Synchronized PST files across DAG member servers
  • Linked PST Files
    New Outlook function to connect to server based PST files advertised by AutoDiscover

How does it work?

  • The  $env:ExchangeInstallPath contains a new folder named PSTSync
    The new folder can be accessed by end users using https://<your OWA FQDN>/PSTSync 
  • Add new subfolder for each user with PST files, assign Owner access to the subfolder and inform the users to upload their PST files using that link
  • The uploaded PST files are automatically renamed andf synchronized between the DAG member servers using PSTSync
  • Exisiting PST files are automatically advertised by AutoDiscover as LinkedPSTFile when queried by a modern Outlook version

The following diagram illustrates the new functionality in a simple Outlook Server 2019 setup:

The new Outlook Server functionality

The following screenshot illustrates the new PSTSync folder and some sample PST file for a user with SAMAccountName JohnDoe

PSTSync Sample for JohnDoe

 

It's good the see that there is a future for a email server product like Exchange Server and that after so many years of cloud only an on-premises only feature got added.

 

Links

 

Enjoy the day and Happy Easter!

 

 

Read More »