Tag Archives: Exchange 2010

Moving from Exchange 2010 to Office 365 Part III

Exchange 2010 hybrid and Edge Transport Server

In two previous blog posts I explained how to setup an Exchange 2010 hybrid environment. In these blog posts I used the Exchange 2010 (multi-role) server for the hybrid configuration, so both the Exchange Web Services (used for free/busy, Mailbox Replication Service, OOF, mail tips) and the SMTP connection between Exchange Online and Exchange 2010.

Now that Exchange 2010 end of support is getting closer (less than a year!) I get more questions regarding the move from Exchange 2010 to Exchange Online. And several questions include the use of an Exchange 2010 Edge Transport server in front of the Exchange 2010 multi-role server.

This configuration will look something like this:

exchange 2010 hybrid edge transport

Inbound mail from Internet is getting through Exchange Online Protection and when the mailbox is still on Exchange 2010 it is routed via the Edge Transport Server to the internal Exchange organization. Outbound mail is leaving the organization via the Edge Transport server or via Exchange Online Protection, depending of the location of the mailbox.

The challenge when configuring this in Exchange 2010 is shown in the following screenshot:

missing edge transport server

Compared to running the HCW on Exchange 2013 or Exchange 2016 there’s no option to configure the Edge Transport server for secure mail transport in Exchange 2010!!
The only option right now is to run the Hybrid Configuration Wizard, configure it using the Client Access and Mailbox servers option, but use the data for the Edge Transport where needed.

So, run the Hybrid Configuration Wizard, and when you need to enter the public IP address of the transport servers, enter the Public IP address of the Edge Transport server and not the public IP address of the load balancer VIP pointing to the Exchange 2010 internal servers). In my environment, the webmail.inframan.nl points to 176.62.196.253 and the Edge Transport Server smtphost.inframan.nl points to 176.62.196.245. This is the IP address I am going to use as shown in the following screenshot:

hcw public ip address

The next step is to select the certificate that’s used on the Edge Transport Server. By default, the HCW will only look at the internal Exchange 2010 server, so it won’t find any certificate installed on the Edge Transport server. To overcome this, I have imported the certificate of the Edge Transport Server in the certificate store of the internal Exchange 2010 server used by the HCW. In the HWC, click on the drop down box and select the certificate of the Edge Transport server, in my environment the smtphost.inframan.nl certificate:

hcw loading certificates

The last step is where the FQDN of the organization needs to be entered. I have a lot of discussion here because most admins want to enter something like ‘hybrid.domain.com’, but the FQDN of the transport server needs to be entered here, so in my environment this is the FQDN of the Edge Transport Server, i.e. smtphost.inframan.nl. This FQDN is used (together with the certificate information) to create a Send Connector from Exchange Online to the Edge Transport server.

hcw organization fqdn

Finish the Hybrid Configuration Wizard. It will be configured in Exchange 2010 and in Exchange Online and after a short time you can close the HCW:

hcw configure organization relationship

Now, when looking at the Exchange Management Console you can see the Send Connector from Exchange 2010 to Exchange Online. It is configured with the FQDN smtphost.inframan.nl as expected, but the source server of the Send Connector is still the internal Hub Transport server as shown in the following screen shot:

outbound to office 365 connector

Remove the Hub Transport server entry and add the Edge Transport server instead. If you have an Edge Synchronization in place you will see it immediately when you click the Add button.

In Exchange Online, the Receive Connector that’s created will check for any certificate with a wildcard like name, so the smtphost.inframan.nl certificate will automatically be accepted. The Send Connector is also created correctly. The FQDN of the Edge Transport server is used as the server to route message to, and the CN of the certificate that was selected in the HCW is also configured as shown in the following screenshot:

office 365 send connector certificate

We’re almost there. The only thing that needs to be done is to configure the Receive Connector on the Edge Transport Server for TLS from Exchange Online. You should have already configured the Edge Transport Server with the correct 3rd party certificate and when setting up an inbound connection it should use the 3rd party certificate. You can test this using the https://checktls.com tool online.

On the Edge Transport server, execute the following command in the Exchange Management Shell:

Get-ReceiveConnector "smtphost\Default internal receive connector SMTPHOST" | Set-ReceiveConnector -Fqdn smtphost.inframan.nl -TlsDomainCapabilities mail.protection.outlook.com:AcceptOorgProtocol

This will make sure the cross-premises email will be treated as internal email (SCL=-1). If you omit this step, there’s always the risk the email will be treated as external (I’ve seen SCL=5 in my environment) and will end up in the user’s Junk Email Folder.

Summary

When configuring an Exchange 2010 hybrid configuration it is not possible to configure an Edge Transport Server in the Hybrid Configuration Wizard. It is possible to configure this in the HCW for Exchange 2013 and Exchange 2016, but for Exchange 2010 this needs some manual changes.

In this blogpost I showed you the steps needed to configure an Edge Transport Server for secure messaging between Exchange Online and Exchange 2010. When configured this way cross-premises email will be seen as internal email and thus treated accordingly.

 

The version of the Client Access server selected is not supported

When running the Hybrid Configuration Wizard in an Exchange 2010 environment (I reproduced this with Exchange 2010, but didn’t try this with Exchange 2013 or Exchange 2016) the following error message is generated:

unsupported version

The version of the Client Access server selected, <ServerName>, is not supported. Please go back and select a server that is supported or upgrade the server to a supported version. If Exchange Server 2010, please install the wizard on the same machine.

Note. The HCW is not run on the Exchange 2010 since it requires .NET Framework 4.6.2 and this version of .NET Framework is not supported on Exchange 2010. Even worse, I’ve seen issues with Exchange 2010 after installing .NET Framework 4.6.2 so it’s a bad idea after all.

Running Exchange 2010 on a server with .NET Framework 4.5.x installed is fully supported, but the HCW won’t install on such an Exchange 2010 server since HCW depends on .NET Framework 4.6.2 and the following error message is generated:

unable to install or run this application

So, we are in a deadlock situation. HCW requires .NET Framework 4.6.2 which is not supported on the Exchange server, and when running the HCW on a non-Exchange 2010 server with the correct version of .NET Framework it fails with an error message.

We have been working with Microsoft CSS (product support) on this case. While it should be fixed in the HCW in the first place, under supervision of CSS the following workaround is available.

If you have HCW open and face this error, press F12 and a few other options appear as can be seen in the following screenshot:

HCW Error

If you click Open Logging Folder you get to the folder where the HCW Logs are stored. If you open the correct logfile and search for *ERROR* you can find something similar to:

server error

Obviously the HCW does an incorrect version check (at least when not running on the Exchange 2010 server itself) so it stops. Version checking is something that was built recently into the HCW so Microsoft can check for N-2 version of the implemented Exchange version.

Back to the error message, if you click Open Process Folder a new HCW command prompt is opened on the correct location:

HCW Prompt

Now when you start the Hybrid Configuration Wizard from the Command Prompt you can use the /dv switch (Microsoft.Online.CSE.Hybrid.App.exe /dv) and now the HCW will not do a version check and continue running and finish successfully.

Important note. This was done under the supervision of Microsoft CSS and should not be done by customers directly. If you are running into this issue, please contact Microsoft support to get the right support. Before you know things break beyond repair (and beyond support).

More information

Updated: December 6, 2018

 

Exchange 2010 and TLS 1.2

In a previous blogpost I discussed an issue I had with Outlook 2010 and TLS 1.2. At the same time this reminded me that Microsoft will remove support for TLS 1.0 and TLS 1.1 in Office 365 on October 31, 2018 as communicated in https://support.microsoft.com/en-us/help/4057306/preparing-for-tls-1-2-in-office-365. This means that when you have communication issues with Office 365 because of an older and weaker protocol, you won’t get any support. Time to do some research….

Existing Exchange 2010 environment

As you may have seen on this side, I still am a big fan of Exchange 2010 and also have an pure Exchange 2010 hybrid environment up-and-running and it looks like this:

Inframan-hybrid

MX records is pointing to my Exchange 2010 Edge Transport Server (running on Windows 2008 R2), webmail and Autodiscover are routed via an F5 LTM load balancer to an Exchange 2010 CAS/HUB/Mailbox server (also running on Windows 2008 R2), and hybrid is configured directly on Exchange 2010 (for hybrid mail flow I’m using a separate FQDN, o365mail.inframan.nl) without any Exchange 2013 or Exchange 2016 server.

So, how do you test which TLS version is used by your Exchange 2010 server? In Exchange 2010 this should be done using the protocol logfiles. Message headers in Exchange 2010 do not contain enough information for showing this TLS information. So, you must enable protocol logging for the appropriate Receive Connectors and Send Connectors. In my environment this means the Default Receive Connector on the Exchange 2010 Edge Transport server (for O365 traffic from other tenants), the Default-First-Site-Name to Internet Send Connector, and both connectors between the Exchange 2010 server and Office 365 for hybrid. Analyzing the protocol logfiles can best be done in Excel (import as CSV files). When analyzing, look for a string like TLS protocol SP_PROT_TLS1_0_SERVER (when receiving) or TLS protocol SP_PROT-TLS1_0_CLIENT (when sending). When TLS 1.2 is used, look for a string like TLS protocol SP_PROT_TLS1_2_SERVER and TLS protocol SP_PROT-TLS1_2_CLIENT.

Continue reading Exchange 2010 and TLS 1.2

Exchange Resource Forest and Office 365 – Part IV

In the past three blogposts I’ve showed you the basics of Linked Mailboxes in a Resource Forest, how to implement Azure AD Connect is this environment and how to setup Exchange Hybrid in a Resource Forest model.

Another challenge is how to provision users in a Resource Forest setup, especially when it comes to provisioning mailboxes directly in Office 365.

In a normal, single forest environment you would create a new user in Active Directory and execute the Enable-RemoteMailbox command in Exchange PowerShell to directly create a Mailbox in Office 365. In a Resource Forest model you will run into some issues though….

In this blogpost I will show you how to manually create Linked Mailboxes and the accompanying user accounts and how to create a Linked Mailbox, but directly in Office 365. I’ll show you the unsupported way using ADSI Edit (for educational purposes) and the supported way to achieve this.

Provision a Linked Mailbox

To provision a Linked Mailbox a new user account in the Account Forest need to be created and a (somewhat) identical, but disabled user account need to be created in the Resource Forest.

The most basic option to do this is to execute the following commands in PowerShell on a Domain Controller in the Resource Forest:

Import-Module ActiveDirectory
$AccountsCred = Get-Credential Accounts\administrator
$Password = ConvertTo-SecureString -String "P@ss1w0rd!" -AsPlainText -Force

New-ADUser -Name "C.Smith" -Server ACCDC01.accounts.local -Credential $AccountsCred -UserPrincipalName C.Smith@exchangefun.nl -GivenName Clyde -Surname Smith -DisplayName "Clyde Smith" -Path "OU=Users,OU=NL,DC=Accounts,DC=Local" -AccountPassword $Password -Enabled:$TRUE

This will create a new user account in the Accounts Forest. Next is to create a similar, but disabled user account in the Resource Forest by executing the following command:

New-ADUser -Name "C.Smith" -Server RESDC01.resources.local -UserPrincipalName C.Smith@resources.local -GivenName Clyde -Surname Smith -DisplayName "Clyde Smith" -Path "OU=Users,OU=NL,DC=Resources,DC=Local" -AccountPassword $Password -Enabled:$FALSE

To create a new Linked Mailbox for this user account, we can execute the Enable-Mailbox with the -LinkedDomainController and -LinkedMasterAccount options against this new user account in the Resource Forest. This should be executed in the Exchange Management Shell, but you can also start a Remote PowerShell session in the current regular PowerShell window using the following commands:

$AdminCred = Get-Credential resources\administrator
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://RESEXCH01/PowerShell/ -Authentication Kerberos -Credential $AdminCred
Import-PSSession $Session

Note. You can also execute Import-Module ActiveDirectory in an Exchange Management Shell window on the Exchange server, but my Exchange 2010 server is running on Windows 2012. This is PowerShell 2.0 and generates an error when importing the Active Directory module.

So, the command to create the Linked Mailbox and user the user account we’ve just created in the Accounts Forest should be:

Get-User C.smith | Enable-Mailbox -LinkedCredential $AccountsCred -LinkedDomainController ACCDC01.accounts.local -LinkedMasterAccount "C.Smith"

With commands shown in the previous blog on Linked Mailboxes we can check the objectSID and the MsExchMasterAccountSID:

image

Azure AD Connect will make sure (just like in the previous blog posts) based on the objectSID and MsExchMasterAccountSID that the new user account and mailbox information will be synchronized with Azure Active Directory and it will appear in the Office 365 address book.

Now we can move this Mailbox to Office 365, but it’s not the most efficient way to create new Mailboxes, especially when the new Mailboxes should be created in Azure Active Directory.

Enable-RemoteMailbox in a Resource Forest with ADSI Edit (Not Supported)

The Enable-RemoteMailbox PowerShell command seems like a much more efficient way to provision Mailboxes in Office 365. The problem however is to connect the user account in the Account Forest with the disabled account in the Resource Forest. Let’s give it a try…

Create two users, one regular account in the Account Forest and one disabled account (acting as a placeholder) in the Resource Forest. When Azure AD Connect kicks in you’ll see two user accounts appear in Office 365 for this user.

image

The unlicensed account originates from the Account Forest, the blocked account originates from the Resource Forest. This is treated as two separate accounts because Azure AD Connect cannot create the joined identity as it does with a regular Linked Mailbox, because there’s no objectSID value stamped on the MsExchMasterAccountSid property. There’s no MsExchMasterAccountSid at all since there’s no Linked Mailbox, and we’re at this point not planning to create a Linked Mailbox either, sigh…

An option (but totally unsupported) to overcome this is to stamp the objectSID value of the regular user account on the MSExchMasterAccountSid property of the disabled account, prior to the next synchronization cycle of Azure AD Connect. When properly set, Azure AD Connect connects the two accounts and synchronizes only the regular user account with Azure AD Connect and only this user account will appear in Azure Active Directory.

You can try this by copy-and-paste this value using ADSI Edit, it gladly accepts the hexadecimal value as shown in the following figure:

image

Using PowerShell is easy for scripting, but involves a bit more work. Right after creating the two user accounts you have to retrieve the objectSID value of the user account in the Account Forest using the following commands:

$objectSID = Get-ADUser -Filter {SAMAccountName -eq "j.doe"} -properties * -server accdc01.accounts.local -Credential $AccountsCred | Select SID

The command $objectSID.SID.Value will show the value of the objectSID:

image

Setting the objectSID on the MsExchMasterAccountSid using Set-ADUser works with the -replace option. Use the previous command to retrieve the user account, and use the pipe command to parse it into the Set-ADUser command (only the Set-ADUser command is shown here):

Set-ADUser  -replace @{msExchMasterAccountSid = $objectSID.SID.Value

Now the two accounts are tied together (when it comes to Azure AD Connect) and you can execute the Enable-RemoteMailbox command:

Get-User -Identity j.doe | Enable-RemoteMailbox -RemoteRoutingAddress j.doe@exchangefun.onmicrosoft.com

Again, this works fine but it is not supported. I primarily explained this to show what’s going on under the hood.

Enable-RemoteMailbox the supported way

A better and most likely supported way (thanks to fellow MVP Mike Crowley) is to create a Remote Mailbox and connect the disabled user account in the Resource Forest to the user account in the Account Forest using the Set-User command (with the -LinkedMasterAccount option) before Azure AD Connect runs and synchronizes the information to Azure Active Directory.

All steps would be:

  1. Create a user account in the Account Forest
  2. Create a disabled user account in the Resource Forest
  3. Enable-RemoteMailbox this disabled user account
  4. Set the LinkedMasterAccount properties

In PowerShell this would be:

Import-Module ActiveDirectory
$AccountsCred = Get-Credential Accounts\administrator
$ResourceCred = Get-Credential resources\administrator

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://RESEXCH01/PowerShell/ -Authentication Kerberos -Credential $ResourceCred
Import-PSSession $Session

$Password = ConvertTo-SecureString -String "P@ss1w0rd!" -AsPlainText -Force

# Create the user account in the Account Forest
New-ADUser -Name "Clyde Smith" -SAMAccountName C.Smith -Server ACCDC01.accounts.local -Credential $AccountsCred -UserPrincipalName C.Smith@exchangefun.nl -GivenName Clyde -Surname Smith -DisplayName "Clyde Smith" -Path "OU=Users,OU=NL,DC=Accounts,DC=Local" -AccountPassword $Password -Enabled:$TRUE

# Create the disabled account in the Resource Forest
New-ADUser -Name "Clyde Smith" -Server RESDC01.resources.local -SAMAccountName C.Smith -UserPrincipalName C.Smith@resources.local -GivenName Clyde -Surname Smith -DisplayName "Clyde Smith" -Path "OU=Users,OU=NL,DC=Resources,DC=Local" -AccountPassword $Password -Enabled:$FALSE

# Create a Remote Mailbox for this user (in the Resource Forest)
Get-User "C.Smith" | Enable-RemoteMailbox -RemoteRoutingAddress C.Smith@exchangefun.mail.onmicrosoft.com

# Set the LinkedMasterAccount properties
Get-User "C.Smith" | Set-User -LinkedCredential $AccountsCred -LinkedDomainController ACCDC01.accounts.local -LinkedMasterAccount "Clyde Smith"

Now two user accounts are set, the Remote Mailbox in Office 365 is created, the account in the Resource Forest is linked to the account in the Account Forest. All set and fully supported!

Summary

When using an Exchange Resource Forest with Linked Mailboxes and you want to provision new Mailboxes in Office 365, the most common way is to create a Linked Mailbox and move the empty Mailbox directly to Office 365. While this works will it is not the most efficient way and moving mailboxes can be time consuming, even when they’re empty.

Another way is to create two user accounts and fiddle around with ADSI Edit and create a Remote Mailbox in Office 365. This is fun to do in a lab environment, but not supported.

The best way to achieve this is to create two user accounts, and create a Remote Mailbox on the disabled account in the Resource forest. Once created use the Set-User command with the -LinkedMasterAccount option to link the Remote Mailbox to the user account in the Account Forest. The only catch here is to run all commands before Azure AD Connect kicks in, otherwise you will get unexpected results (i.e. multiple accounts in Azure Active Directory).

Exchange Resource Forest and Office 365 – Part II

In my previous blog post I’ve explained more about the Exchange resource forest model where user accounts are located in a dedicated forest with only the user account (and their regular resources) and where Exchange is installed in a resource forest. There’s a forest trust between the resource forest and the account forest, and the mailboxes are configured as linked mailboxes. This is shown in the following figure:

image

In this blogpost we will add an Azure AD Connect server to enable synchronization between the on-premises Active Directories and Office 365.

Exchange Resource forest and Azure AD Connect

If we want to create a hybrid scenario with our resource forest and Exchange Online we have to implement Azure AD Connect first. Azure AD Connect will synchronize account information from the account forest, and linked mailbox information from the resource forest. To achieve this, we have to setup a multi-forest synchronization model (which is also fully supported by Microsoft).

The Azure AD Connect server will be installed in the account forest. To retrieve the information about the mailboxes from the resource forest, a service account will be used as shown in the following figure:

image

In a typical environment there’s only one Active Directory containing both user accounts and exchange servers. As such, the user accounts have the corresponding Exchange properties. In a Resource Forest scenario there are two user accounts, where the user account in the Resource Forest is disabled and this disabled account contains the Exchange properties.

The Azure AD Connect server (which is running in the Account Forest) combines the two accounts based on the objectSID and MSExchMasterAccountSid and synchronizes this ‘joined’ account information to Azure Active Directory, as shown in the following figure:

image

The prerequisites for Azure AD Connect is a Resource Forest scenario are the same as for a regular environment, so I won’t go into too much detail about this. Of course you need an internet routable domain for your accounts (i.e. don@accounts.local won’t work, so this needs to be changed to don@exchangefun.nl), your accounts need to be checked for inconsistencies with the IDFix tool and of course you have to configure your tenant in Office 365. For more information regarding the process, please check my blog Implementing Directory Synchronization. It’s a somewhat older blog, but the steps remain the same.

You can download the latest version of Azure AD Connect from the Download Azure AD Connect. I will only show the most important screenshots when running the Azure AD Connect wizard.

Azure AD Connect can be installed using an Express setup, this is the default setting and is sufficient if you have a single forest environment with less than 100,000 objects in Active Directory and where using SQL Express is sufficient. In our Resource Forest environment we have multiple Active Directory forest, so a custom setup is needed, so select Customize in the Express Settings window:

image

Continue with the wizard until you reach the User Sign-in window. Here you have to select which authentication method is used when users sign-in into Office 365. Make your selection and click Next to continue.

image

After entering the (Global) tenant administrator credentials, the forests need to be added to the Azure AD Connect wizard. In the Connect your directories window the Active Directory forest where your Azure AD Connect server resides will appear. To add this directory, click Add Directory:

image

The Add Forest Account window will appear. Here you can select if a new service account for Azure AD Connect will be created, or that an existing service account will be used. An Enterprise Admin Account will be used to create this service account, and configure Azure AD Connect for first use. It must be an Enterprise Admin account because information is written into the Configuration partition of Active Directory. Enter the credentials of the Enterprise Admin (in your Account Forest) and click OK to continue.

image

Repeat these steps for the Resource Forest, so enter the forest name, select the radio button to create a new service account and enter the Enterprise Admin credentials in the Resource Forest as shown in the following two figures:

image

image

Continue with the wizard, select the Domain/OU filtering options for both Forest and make sure you select the containers containing the user accounts in the Account Forest and the corresponding Mailboxes in the Resource Forest as shown in the following two figures:

image

image

The Uniquely identifying your users is the most important window in the Azure AD Connect wizard. This is where the user account in the Account Forest and the corresponding mailbox in the Resource Forest are tied together. In the previous blogpost I’ve explained the objectSID and the msExchMasterAccountSID, so this option is selected.

image

Continue the Azure AD Connect wizard, and in the Optional Features select the Exchange Hybrid Deployment checkbox and click Next to continue.

image

You’re now ready with the Azure AD Connect wizard. In the Ready to configure window you can chose to start the synchronization immediately, or enable the Azure AD Connect server in staging mode. In this mode it will collect all information and fill the SQL Express database with data, but it won’t write any data to Azure Active Directory until you’ve checked everything. Select the option you want and click install to finish the wizard and install/configure Azure AD Connect.

image

At the configuration complete window there are some recommendations and/or remarks for your reference, click Exit to stop the Azure AD Connect wizard.

image

Now, when you logon to the Microsoft Portal you’ll see that synchronization has occurred:

image

And when you expand the users option you’ll see which users are synchronized.

image

When you logon to the Exchange Admin Console in Exchange Online and check the Recipients | Contacts folder, you’ll see the users appear here. This makes sense, since the on-premises Mailboxes are represented as Mail-Enabled Users in Exchange Online.

image

Summary

In this blogpost I’ve showed you how to implement Azure AD Connect in an existing Exchange Resource Forest model. The Azure AD Connect server combines the user account from the Account Forest with the mailbox from the Resource Forest and synchronizes this to Azure Active Directory.

In my next blog I’ll create a hybrid environment based on the Exchange resource forest model.

Ps. a special thanks to ‘Trekveer Harry’ for his continuous brainstorm sessions and good ideas Smile