The Category List Manager is a C# Visual Studio Solution that allows you to connect to a source mailbox which is either hosted on an on-premises Exchange Server or in Exchange Online using Exchange Web Services (EWS).
You can use AutoDiscover or a static Url to connect to the Exchange Server or Office 365. By default the solution uses the credentials of the user executing the program. These credentials are referred to as default credentials. You can use the Settings form to set dedicated credentials of an user with appropriate access rights to the mailbox(es).
The program helps you to
The supported target mailbox types are:
The GUI comes with an easy-to-use UI. The execuable works a command line tool as well and can be used for automation purposes.
Use CategoryManager.exe -help to get the most recent command line help information.
Watch the presentation held at the Exchange User Group Berlin Meetup on May 31st 2018.
Additional credits go to Henning Krause
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.
At Active Directory forest level the following attributes are used to determine the Exchange Server release:
At Active Directory domain level the following attribute is used to determine the Exchange Server release:
Enjoy Exchange Server!
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:
The script fetches at domain level:
# Fetch all version information in the Active Directory forest
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
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:
The following diagram 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.
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:
The SSL Traffic is offloaded and re-encrypted as we need to authenticate the user with ESP. Ensure to select a Cipher Set that does not provide any weak or unsecure cipher suites. In this example I've selected the predefined set BestPractices.
Enable ESP to activate the ESP configuration section. The settings are as follows:
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.
Using this configuration you've added your Kemp LoadMaster as an additional authentication endpoint to secure mobile device access to Exchange Server mailboxes.
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
For more information read the readme.md file at Github.
You need to adjust the log file path to suit your IT infrastructure. A next releas will contain a more automatic solution.
# 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