Jude's Blog

Archive for the ‘Exchange’ Category

Fixing “451 4.7.0 Temporary server error. Please try again later. PRX4”

leave a comment »

Issue

In this scenario we are going to talk about an issue related to Exchange server not being able to accept any inbound SMTP connections. The client had one Edge server and two Exchange 2016 Mailbox servers. Out of nowhere, they have noticed that they are unable to send emails within the Exchange organization as well as all inbound emails from internet seemed to have stopped. In such a scenario, what we should do first is to identify the role that the issue might be at. In our case this is to with the SMTP mail flow thus the Hub Transport service should be involved.

Also, looking at the mail queues in the gateway and exchange servers, the Last Known Error message is shown as below;

451 4.7.0 Temporary server error. Please try again later. PRX4

Step 01:
Our first step should be to make sure that all Exchange Services are running on the servers. You can do this by going to the “Services” or opening up Exchange Powershell and running the below command to ensure that all required services are in “Running” state.

Get-ServerComponentState -Identity <ServerIdParameter>

Step 02:
Now that we know our services are working (at least showing that it’s working) let’s do a telnet and verify. You can do this by sending an email using ‘Telnet‘ from your other hops. In my case;

  • Edge server to Exchange server 01 – Gives error “451 4.7.0 Temporary server error. Please try again later. PRX4”
  • Exchange server 01 to Exchange server 01 – Gives error “451 4.7.0 Temporary server error. Please try again later. PRX4”
  • Exchange server 01 to Exchange server 01 – Gives error “451 4.7.0 Temporary server error. Please try again later. PRX4”
  • Exchange server 02 to Exchange server 02 – Gives error “451 4.7.0 Temporary server error. Please try again later. PRX4”
  • Exchange server 02 to Exchange server 01 – Gives error “451 4.7.0 Temporary server error. Please try again later. PRX4”
  • Exchange server 02 to Edge server 01 – Message relayed successfully
  • Exchange server 02 to Edge server 02 – Message relayed successfully

What does this say? Issue is on my internal Exchange Servers, ditto!

Step 03: Now that we have established where the issue occurs on which service, the next option was to check the AD connectivity. You can do this by checking the event log for “MSExchange
ADAccess” and confirm that Exchange and AD connection is working as expected.

Step 04: Check if the time is correct on all your Exchange servers along with the time of your AD.

Step 05: Verify that the entries in your DNS is correct and working by doing a NSLOOKUP from all Exchange servers.

Step 06: Verify that your certificates are valid and SMTP services are assigned properly.

In my scenario, all steps from 1-5 were perfectly fine except for step 6. I logged into my ECP, went to Servers and Certificates and in my list, I noticed that the certificate Status was showing as ‘Invalid‘. In addition, the certificate properties showed that the SMTP service was also assigned to this certificate.

 

Resolution

We can get an idea on what might the issue be. We have an Invalid certificate with SMTP assigned to it. And our issue is that the Exchange server is rejecting the SMTP connections. This seems to be a valid cause. Now check your other certificates too. In my case the certificate in issue was an older custom created one. But there was a proper certificate that was set to IIS,SMTP,POP,IMAP services. That means we can delete it. However, if the certificate is a built-in certificate or the only certificate that’s assigned to all services, ‘DO NOT DELETE’.

Before deleting, it’s always a good idea to take a backup of the certificate. To do this, follow the steps;

  1. Open MMC
  2. Click File and select Add/Remove Snap In
  3. Under the Available
    snapins, click on Certificates and Add
  4. Under Certificates snap-in select ‘Computer
    account’ and click Finish
  5. Select Local Computer to manage the snap-in
  6. Click OK to add the selected snap-in to console window
  7. Go to the MMC, under Personal Certificates store, right-click on your certificate that should be exported, and select All Tasks and click Export
  8. Proceed with exporting the certificate with the Private key.

Now that we have exported the certificate, we can go back to the ECP and delete the Invalid certificate.

  1. Login to Exchange
    Admin
    Center (ECP)
  2. Navigate to Servers and click on Certificates
  3. Select the server you want to list the certificates from the drop-down menu
  4. Select the certificate which is marked as Invalid that you want to delete
  5. Click on the delete icon (recycle-bin icon)
  6. If you have multiple servers, do steps 2-5

The next step is to restart the Microsoft Exchange Transport related services so that the service will now refresh its certificate and will only use the Valid certificate(s). Do this on all servers that you removed the certificate.

Give your services to run and the mail queues to automatically restart and you will be able to see that the mail Queue will now be delivered.

Advertisements

Written by judeperera

October 11, 2019 at 11:28 am

[Script] Shared Mailbox Convert and Enabling Sent Items Copy

leave a comment »

This is a simple script that will allow an administrator to achieve the below tasks;

  1. Convert a User mailbox to a Shared Mailbox
  2. Enable Messages sent from the shared mailbox to be saved to the Sent Items folder of the shared mailbox

Let’s take the below scenario;

User Mailbox – user@contoso.com
Shared Mailbox – shared@contoso.com (user@contoso.com has SendAs and FullAccess permissions)

In a case where if user(user@contoso.com) tries to send an email with SendAs/SendOnBehalfOf permissions for ‘shared@contoso.com‘, the sent email will only be available in the primary users ‘Sent Items‘ ONLY. In a business requirement where the mail should also be present in the ‘shared@contoso.com‘ shared mailbox, we would require the below permissions to be enabled. Once done, the email with SendAs/SendOnBehalfOf permission will be in both user@contoso.com and shared@contoso.com mailboxes’ Sent Items.

The MessageCopyForSendOnBehalfEnabled parameter specifies whether to copy the sender for messages that are sent from a mailbox by users that have the “send on behalf of” permission. In this script we will be enabling this by setting the value to $true; where when a user sends a message from the mailbox by using the “send on behalf of” permission, a copy of the message is sent to the sender’s mailbox.

The MessageCopyForSentAsEnabled parameter specifies whether to copy the sender for messages that are sent from a mailbox by users that have the “send as” permission. In this script we will be enabling this by setting the value to $true; where when a user sends a message from the mailbox by using the “send as” permission, a copy of the message is sent to the sender’s mailbox.

Want to give a try? you can get the script here..


 

Restore a Deleted User Mailbox

leave a comment »

Issue

In this scenario we are going to take an on-premise environment with a Windows Server 2012 R2 Active Directory and an Exchange Server 2016 environment. In our case, a user was accidentally deleted from the OU itself. (NOTE: It is always a best practice to enable ‘Protect object from accidental deletion‘ for your AD Objects.

You can also recover a deleted mailbox using backups. However, note that backups are not current. This will lead to restoring but will not give you the latest data once recovered.

Prerequisites

  1. First, we need to get the AD account restored. For this, you should have the Active Directory Recycle-bin enabled in your environment. If you don’t have this enabled already, you are in tough luck.
  2. Secondly, we need to make sure that you are within the time duration mentioned in the ‘Keep deleted mailboxes for (days)’ under Exchange database properties where the user was. In our case, it was 30 days as shown below;

Solution

  1. Restore the AD account from Active Directory
  2. Ensure that restored user accounts ‘User logon name‘ has the correct domain mentioned.
  3. Go to AD User properties page, note down the ‘Display Name‘ of the user (ex: Jude Perera).
  4. Open Exchange Control Panel (ECP), go to Recipients > Mailboxes. Click More
    Options icon, and then click Connect mailbox

  5. Click the deleted mailbox that you want to connect.
  6. Note down the ‘Display Name‘ of the user you want to restore (ex: Jude Perera).
  7. Open the Exchange PowerShell and run the below command;
    Connect-Mailbox -Identity "Jude Perera" -Database DB01 -User "Jude Perera" -Alias jude

    NOTE: The Identity parameter specifies the display name of the deleted mailbox retained in the mailbox database provided. The User parameter specifies the Active Directory user account to connect the mailbox to. Alias is what the users email alias is.

    Now we must get the identity and user attributes from the noted in steps 3 and 6 which is as below;

    Connect-Mailbox -Identity "Jude Perera" -Database DB01 -User "Jude Perera" -Alias jude

  8. Once you run the above command the mailbox will now be connected.
  9. To verify, go to the Exchange Admin Center and search for the user mailbox in the ‘Recipients‘. Your reconnected user will be shown.

Tip: In case you receive an error ‘Property expression “jude” isn’t valid. Valid values are: Strings that includes ‘@’, where ‘@’ cannot be the last character.’ Navigate to the AD user properties, select the ‘Account’ tab and verify that the User logon name has the domain selected properly.

Written by judeperera

March 22, 2019 at 10:45 am

Step by Step Guide for Installing Exchange Server 2019 Preview

with 4 comments

The following section describes a step-by-step guide for the installation of Microsoft® Exchange Server 2019 Preview. The installation considers a single server deployment of Exchange Server 2019. Additional details of the topology and architecture of the lab environment which was used in the installation is described here;

Active Directory Domain Controller(s)
Operating System Windows Server 2019 preview
Forest Functional Level Windows Server 2019 preview
Domain Functional Level Windows Server 2019 preview
Exchange 2019 server(s)
Operating System Windows Server 2019 preview
.Net Framework Version 4.7.2 (default)

 

 

Exchange 2019 prerequisites

Domain Controller Support

The following Active Directory writable Domain Controller(s) are supported;

  • Windows Server 2012 R2
  • Windows Server 2016 (Core and Desktop Experience)
  • Windows Server 2019 preview (Core and Desktop Experience)

Operating System Support

  • Windows Server 2016 (Core and Desktop Experience)
  • Windows Server 2019 preview (Core and Desktop Experience)

.Net Framework Support

Other requirements

 

Active Directory preparation

The first task in the installation of any version of Exchange is to prepare the Active Directory environment where the Exchange Server will be placed. However, prior to the preparation, it should be checked against the above Domain Controller support prerequisites mentioned earlier. Once the above requirements are verified for consistency, proceed with the following preparation tasks on the server/computer which will be used to prepare the Active Directory.

We will be using the Exchange Server itself to prepare the Active Directory.

  1. Install .NET Framework 4.7.1 or .NET Framework 4.7.2 as supported by your Operating System (mentioned above)

    Note: .Net Framework 4.7.2 is already included and is not required to download or install with Windows Server 2019 preview

  2. Once the installation is complete perform a reboot.
  3. Open a Windows PowerShell
  4. Run the below command to install Remote Administration tools

    Install-WindowsFeature RSAT-ADDS


  5. Run the below command to install the server prerequisites

    Install-WindowsFeature NET-Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Clustering-CmdInterface, RSAT-Clustering-Mgmt, RSAT-Clustering-PowerShell, Web-Mgmt-Console, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation, RSAT-ADDS


Prepare Active Directory and domains

To prepare the active Directory and the Domains for Exchange 2019, follow the following steps. To execute the commands, the commands should be run using the Schema Admins group and the Enterprise Admins group membership.

  1. Mount the Exchange Server 2019 Preview Installation Media
  2. Open up a Command Prompt
  3. Navigate to the Exchange Installation media path
  4. Run the following command to extend the schema.

    Setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms

  5. Once the setup completes successfully, run the following command

    Setup.exe /PrepareAD /OrganizationName:”<organization name>” /IAcceptExchangeServerLicenseTerms


  6. Run the below command to prepare each of the Active Directory domains

    Setup.exe /PrepareAllDomains /IAcceptExchangeServerLicenseTerms


    Now that your Active Directory forest and the domains are prepared, we can finally get running the Exchange Installation Wizard

Install Exchange Server 2019

If you’re installing the first Exchange 2019 Preview server in the organization, and the Active Directory preparation steps have not been performed, the account you use must have membership in the Enterprise Administrators group. If you haven’t previously prepared the Active Directory Schema, the account must also be a member of the Schema Admins group.

  1. Mount the Exchange Server 2013 Preview Installation Media
  2. Start Exchange 2019 Preview Setup by double-clicking Setup.exe
  3. On the Check for Updates page, select whether you want Setup to connect to the Internet and download product and security updates for Exchange 2019 Preview and click Next

  4. Once you click Next, the setup will copy the installation binaries to the local drive and prepare for the installation

  5. Once completed, you will be prompted with the Introduction Page
  6. The Introduction page gives additional guidance for the installation procedure. Review the content and Click Next to continue

  7. On the License Agreement page, review the terms. If you agree to the terms, select I accept the terms in the license agreement, and then click next

  8. On the Error Recommended Settings page, select whether you want to use or not the recommended settings such as error checks and usage feedback etc. and then click next

  9. As you can see, just like Exchange 2016, Exchange 2019 only has a Mailbox role and Edge role only. Proceed with your requirement and to be sure, make a tick on the “Automatically install windows server roles and features…” Although we have covered this initially, running this will ensure that if we have missed anything, the setup will install it for us

  10. On the Installation Space and Location page, either accept the default installation location or click Browse to choose a new location with adequate storage space, click next to proceed

  11. If installing the Mailbox role a Malware Protection Settings page will appear. Choose whether to enable or disable malware scanning and click Next. (For demo purposes, I will be proceeding with Yes)

  12. On the Readiness Checks page, view the status to determine if the organization and server role prerequisite checks completed successfully. If unsuccessful, perform the required tasks and click Back, and Next to run the Readiness check again. If successful, click install to proceed with installing Exchange Server 2019

  13. Now the installation will proceed, note that this will take time depend on your environment

  14. Once the setup completes the installation, on the Completion page, click Finish

  15. Now that the Exchange installation is complete, it’s always good to reboot your server

Review Exchange Installation

Once all the above tasks are performed, proceed with the below steps to verify the installation using the Exchange 2019 Administrative Center and PowerShell.

The Exchange Administration Center (EAC) is the web-based management console in Microsoft Exchange Server 2019 Preview that allows for ease of use and is optimized for on-premises, online, or hybrid Exchange deployments. To navigate to the Exchange Admin Center;

  1. Open the web browser.
  2. Navigate to the bellow URL, provide your credentials and then click sign in.

    https://localhost/ecp


  3. Review the tabs and sections in the new Admin Center

There you go. Time to play! Hope this guide helped you. Don’t forget to keep on checking for some exiting new posts on how to play around with the all new Admin Center as well as a step by step guide for installing Skype for Business Server 2019 preview in the next couple of days.

Really appreciate all your comments, especially if i have missed anything or made a mistake regarding the installation. 🙂

(c) Copyrights Reserved! Do not share or use any content in any way without approval from poster!

Written by judeperera

August 6, 2018 at 5:44 pm

Move Transport Database Files in Exchange 2013/2016 Step by Step

leave a comment »

Issue:

In terms of sizing an Exchange Server environment, it is always advised and recommended to follow the Microsoft Sizing guides, this specifically means that you need to go through the Exchange Sizing Calculator. The tool gives you estimated values of how your databases, logs and transport queues are going to grow. So, if you do not properly plan these sizes, you might end up getting your disks full.

The scenario which I’m going to talk about is such situation where the free space of the C Drive almost got full. While digging in what’s being eating up the storage, we found out that the Exchange Transport queue, or Mail.que file is the culprit.

Exchange Transport Queue

A queue is a temporary holding location for messages that are waiting to enter the next stage of processing or delivery to a destination. Each queue represents a logical set of messages that the Exchange server processes in a specific order. In Exchange 2016, queues hold messages before, during and after delivery. Queues exist in the Transport service on Mailbox servers and on Edge Transport servers.

File Description
Mail.que This queue database file stores all the queued messages.
Tmp.edb This temporary database file is used to verify the queue database schema on startup.
Trn*.log Transaction logs record all changes to the queue database. Changes to the database are first written to the transaction log and then committed to the database. Trn.log is the current active transaction log file. Trntmp.log is the next provisioned transaction log file that’s created in advance. If the existing Trn.log transaction log file reaches its maximum size, Trn.log is renamed to Trn nnnn.log, where nnnn is a sequence number. Trntmp.log is then renamed Trn.log and becomes the current active transaction log file.
Trn.chk This checkpoint file tracks the transaction log entries that have been committed to the database. This file is always in the same location as the mail.que file.
Trnres00001.jrs
Trnres00002.jrs
These reserve transaction log files act as placeholders. They’re only used when the hard disk that contains the transaction log runs out of space to stop the queue database cleanly.

Solution:

In simple, we can move the Mail.que database and log files associated to a different location. The below step by step guide will take you through how you can achieve this.

Before going ahead, here are some tips when it comes to moving your queue database.

  • Ensure that the destination disk/drive has enough and additional buffer space, remember that during peak times, this can grow. If it’s possible to attach a separate disk for this, go ahead. It’s even better.
  • The move process requires the Exchange Transport service to be stopped until the data is moved to the new location. This means that there will be a downtime where mail flow on the server will be interrupted.
  • The transport queue files are located in the below path
    %ExchangeInstallPath%TransportRoles\data\Queue

Once you have the disk and the downtime planned, we can start the procedure.

  1. Navigate to the location that you would will be moving the data to.
  2. Create a folder where the queue database and transaction logs will be moved. In my case, I’m moving the data do the below path;
    "F:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\data\Queue"
  3. Right click on the above folder “Queue”, select Properties
  4. Navigate to Security tab, click on Edit under Change permissions

  5. Under Permissions verify that the below accounts are listed and the shown permission level is present. It not, add the user/service account and assign permissions
    1. Network Service: Full Control
    2. System: Full Control
    3. Administrators: Full Control
  6. Click OK to apply the permissions to the folder.
  7. Open Notepad using Run as Administrator
  8. Using notepad, click Open and Navigate to the below path

    %ExchangeInstallPath%Bin\

  9. Open the EdgeTransport.exe.config file (you may want to take a backup of the file in case something goes wrong)
  10. On the config file lookup for the following content;
    <add key="QueueDatabasePath" value="<CurrentLocation>" />
    <add key="QueueDatabaseLoggingPath" value="<CurrentLocation>" />
  11. Now we need to modify the <CurrentLocation> and replace it with the new path for the queue files. In our case this will be as below;
    <add key="QueueDatabasePath" value="F:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\data\Queue" />
    <add key="QueueDatabaseLoggingPath" value="F:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\data\Queue" />

  12. Save and close notepad.
  13. Open Services.msc
  14. Stop the Microsoft Exchange Transport Service.

  15. Navigate to the below path where the old queue files are located at;
    %ExchangeInstallPath%TransportRoles\data\Queue
  16. Take a backup of all the files in the folder into a different location just in case.
  17. Move existing database files (Mail.que, Trn.chk, Trn.log, Trntmp.log, Trn nnnnn.log, Trnres00001.jrs, Trnres00002.jrs, and Temp.edb) to the new location. This is the location you mentioned in Step 11.

  18. Go to Services.msc and Start the Microsoft Exchange Transport service.

  19. Monitor the status of the new location and the files.
  20. Verify that the old path is empty and no new files are being created.
  21. Send a few mails with attachments to verify and monitor mail flow.

450 4.7.320 Certificate validation failed

with one comment

Issue


The environment was running Exchange Server 2016 (n-1)CU with Office 365 in a hybrid mode. The issue came up when users on-prem noticed that they are unable to receive emails from their own O365 cloud users. Looking more into this, figured out the following user mail flow scenarios;

  • On-prem users can send/receive mails within on-prem and to/from internet users
  • O365 cloud users can send/receive mails within O365 and to/from internet users
  • On-prem users cannot send/receive emails to/from O365 users

So obviously, this had to do something with the hybrid connector since that’s the tunnel that bridges the two environments.

So back to the basics, lets trace down the error messages and see if we can get a clue. In order to see where our mails are stuck, you need to first check the delivery reports. Log in to the O365 Exchange ECP as administrator and navigate to Message Tracing. On the message tracing log, you will see something like below;

11

We’re almost there now. The above indicates that why O365 is not delivering the mails to on-prem environment is because as on the first item, we have configured to use TLS between the hybrid environments. Thus due to whatever reason, the certificate presented from the on-prem public IP does not match the certificate that is been binded in the Hybrid Configuration. Now in order to validate this, we need to look at two points;

  • Ensure that the certificate is not expired
  • Check Hybrid Configuration certificate settings: To validate that you have the correct certificate open up the Exchange PowerShell module on your on-prem and run the below command;

Get-HybridConfiguration

12

Now as you can see, the Hybrid configuration is configured with the correct certificate. So nothing to worry on that.

  • Exchange Connector TLS settings: The next connection point would be our internal Exchange Server receive connector. Why this connector is important is that when O365 is trying to connect with the exchange server for mail delivery, it will try out TLS for authentication. This is because we have TLS enabled; meaning we should have the correct certificate binded to the corresponding Receive Connector. In many cases this would be the Default FrontEnd connector. Run the below command and ensure that the property tlscertificatename is set correctly and is the same as the above certificate.

Get-ReceiveConnector -Identity “<ExchangeServerName>\Default Frontend <ExchangeServerName>” | fl

In my case, the certificate was all fine and is set for the one as expected.

So, the certificate itself, exchange setup and office 365 hybrid setup is all configured as expected. Yet somehow, Office 365 is telling me that the certificate is not correct.

This is where we would need to properly test TLS in a more informative manner. We will now see how we can use a method where we can see the TLS communication that is made to our on-premises.

Enter CheckTLS web testing provider. The provider has many tools to check TLS mechanisms but in our case, we are looking at the receiving part. Thus we will head over here.

https://www.checktls.com/TestReceiver

What it does?

TestReceiver performs all the steps that Internet email systems go through to send email. It records every command and byte of data it sends and every answer and byte of data that the other email system sends. TestReceiver never actually sends an email, it just gets as close as possible, learning as much about the remote system as it can.

Because CheckTLS focuses on security, TestReceiver tries to establish a secure (TLS) connection with the recipient’s system. Along with recording everything, it looks at the security of the recipient’s system for things like: certificate contents and signers, encryption algorithms, key lengths, hostname mis-matches, incorrect wild-card usage, weak cyphers, etc.

So is this safe? absolutely. Since it only checks whatever is already published by your organization. It doesn’t grab your email ID, username or passwords.

  1. So head over to the site and under the Input fields, type your domain name in the eMail Target
  2. Ensure that under the Output Format you have selected Detail (this will provide you a verbose log of the connection status, more meaningful)
  3. Click Run Test.
  4. Give it some time to run the test and notice the logging which happen in the background. This is the session initiation that happens in real time.
  5. Once the test is completed, look in the detailed log.13

 

And we have found the culprit. Just have a closer look at the above image. You can see that the TLS authentication does start however the certificate validation fails. The reason is that the issuing certificate is not our Exchange Certificate, but a self signed certificate by the barracuda appliance which is front-ending to external connections.

When Office 365 tries to initiate a TLS session, it is getting this self signed certificate thus the required URLs are not found (mail.domain.com) hence it drops the connection and throws out;

450 4.7.320 Certificate validation failed.

If this is your case, bump up your network team and ask them to bind the correct certificate from the appliance. Once its configured properly, run the below tests again to validate that everything is all good.

  • CheckTLS Receive validation – Ensure correct certificate is thrown out
  • Office 365 Connector Validation

If everything is successful, send out couple of emails and you will see that mailflow is working as expected. For the mails that were queued, give some time and it’ll start flowing.

Got any inputs? Please feel free to let me know your ideas.

Cheers..

Field Report: Edge Fails with “454 4.7.0 Temporary authentication failure”

leave a comment »

Issue


There was a scenario where it was noticed that outbound mails were not getting delivered. The environment had 2 Edge Servers together with 2 CAS/Mailbox servers, both being Exchange 2013. Upon checking the mailbox queue on the internal servers, it was noticed that the mails were stuck in the queue on the Send connector that was responsible for outbound mail delivery with Edge Server.

The Error reported the following.

451 4.4.0 Primary target IP address responded with: “454 4.7.0 Temporary authentication failure.”  Attempted failover to alternate host, but that did not succeed.  Either there are no alternate hosts, or delivery failed to all alternate hosts”

Additionally, the following tests were done.

  • System Clock was checked between all Edge, Mailbox/CAS and domain controllers. They were in the same time.
  • Checked for any replication issues between the domain controllers. No issues were found.
  • Checked for communication related issues between the Edge Server and the Internal Exchange Servers for the below ports. All required ports were open.
Network interface Open port Protocol Note
Inbound from and outbound to the internal network 25/TCP SMTP This port is required for mail flow to and from the Exchange organization.
Local only 50389/TCP LDAP This port is used to make a local connection to AD LDS.
Inbound from the internal network 50636/TCP Secure LDAP This port is required for EdgeSync synchronization.
Inbound from the internal network 3389/TCP RDP Opening this port is optional. It provides more flexibility in managing the Edge Transport servers from inside the internal network by letting you use a remote desktop connection to manage the Edge Transport server.
  • Checked the EdgeSync for Edge Server 01: The following results were noted.

    EdgeSync service cannot connect to this subscription because of error “No EdgeSync credentials were found for Edge transport server ED01.contoso.com on the local Hub Transport server. Remove the Edge subscription and re-subscribe the Edge Transport server.”

  • Upon checking the Event viewer, the following errors were thrown;
    • Event ID 1032

      Microsoft Exchange EdgeSync can’t find the replication credential on %1 to synchronize with Edge server %2. This may happen if %1 joined the current Active Directory site after subscription for %2 was established. To have this Hub Transport server participate in EdgeSync, re-subscribe %2 to the current Active Directory site.

Resolution


So basically, we see that the Edge Sync is not working as it should be. At the same time, we see that there’s a certificate issue as well. Upon checking the certificate, we identified that it’s from a local CA. So the next steps we would do is to;

  1. Re-assign Exchange services to the existing certificate
  2. Re run Edge Synchronization
  3. Verify

However, upon doing the service re-assigning to the existing services, the following error was thrown.

The internal transport certificate for the local server was damaged or missing in Active Directory. The problem has been fixed. However, if you have existing Edge Subscriptions, you must subscribe all Edge Transport servers again by using the New-EdgeSubscription cmdlet in the Shell.

Though it said the problem has been fixed, we were still unable to get Edge Sync working. So the final thought was to;

  1. Generate new Exchange Server certificate
  2. Assign services to new certificate
  3. Re-run Edge-Sync

Viola!!! No more errors!!

Written by judeperera

January 10, 2017 at 11:46 am