Tag Archives: exchange server

Public folder mailboxes cannot be moved while public folder migration is in progress

After moving all public folders to Exchange Online, the old public folder mailboxes are still on Exchange 2016. During the retention period of 180 days we wanted to consolidate them on new Exchange 2019 servers. But how to move them? Using a New-MoveRequest command fails with the following error:

[PS] C:\>get-mailbox -PublicFolder -Identity mailbox8 | New-MoveRequest -TargetDatabase DB001
Public folder mailboxes cannot be moved while public folder migration is in progress.
    + CategoryInfo          : InvalidOperation: (contoso.com/Users/Mailbox8:MailboxOrMailUserIdParameter) [New-MoveRequest], RecipientTaskException
    + FullyQualifiedErrorId : [Server=EXCH01,RequestId=d0b7d4c3-2392-4132-a70b-4ccaa385b312,TimeStamp=14-11-2022 18:08:10] [FailureCategory=Cmdlet-RecipientTaskException] 9A85A258,Microsoft.Exchange.Management.Migration.MailboxReplication.MoveRequest.NewMoveRequest
    + PSComputerName        : Exch01.contoso.com
[PS] C:\>

As shown in the following screenshot:

This is caused by the fact that the old public folders are locked and thus invisible. To move the public folder mailboxes to other mailbox databases, open them using the following commands on the Exchange server:

[PS] C:\> Set-OrganizationConfig -PublicFolderMailboxesLockedForNewConnections $false
[PS] C:\> Set-OrganizationConfig -PublicFolderMailboxesMigrationComplete $false
[PS] C:\> Set-OrganizationConfig -PublicFoldersEnabled: Local

After executing these commands the public folders mailboxes can be moved to other (new) mailbox databases. Another thing is that you can access the old public folders using Outlook to retrieve data from them in case of some sort of disaster recovery (like users deleting items from public folders in Exchange Online that cannot be found anymore).

Be aware though that you are not the only one that can ‘suddenly’ see the old public folders. If you have outlook users connecting to a mailbox in Exchange server, the public folders will magically appear for them too.

When done, close the public folders again using the following commands:

[PS] C:\> Set-OrganizationConfig -PublicFolderMailboxesLockedForNewConnections $True
[PS] C:\> Set-OrganizationConfig -PublicFolderMailboxesMigrationComplete $True
[PS] C:\> Set-OrganizationConfig -PublicFoldersEnabled: Remote

Exchange Server OWA and ECP not working

Since a couple of days my OWA and ECP are not working anymore. This happens on both Exchange 2019 CU11 and Exchange 2016 CU22, in two AD sites both with external access. I didn’t notice before since Outlook Mobile and Outlook on the desktop continue to work. After logging in, the Something went wrong message appears, in the navigation bar you can see it is an Error 500 message.

I think (but I’m not sure) that this started after applying the latest November 2021 Security Updates and this is usually caused by starting the Security Update without elevated privileges. There’s an Microsoft article about this: OWA or ECP stops working after you install a security update – Exchange | Microsoft Docs.

I am pretty sure that I installed the Security Update with elevated privileges, but also after reinstalling the Security Update (with elevated privileges!) the error continues. The Microsoft article also mentions settings in IIS Manager (Application settings > BinsearchFolder), but that was not the issue (settings were ok).

When authentication fails, two entries are written in the Application Eventlog, EventID 1003 (MSExchange Front End HTTP Proxy) and EventID 1309 (ASP.NET 4.0.30319.0). The latter clearly shows it has something to do with certificates:

It turned out that the Exchange Server Auth Certificate was expired, just a few days ago. You can see this when running the following command:

[PS] C:\>(Get-AuthConfig).CurrentCertificateThumbprint | Get-ExchangeCertificate | Format-List

AccessRules        : {System.Security.AccessControl.CryptoKeyAccessRule,
                     System.Security.AccessControl.CryptoKeyAccessRule,
                     System.Security.AccessControl.CryptoKeyAccessRule}
CertificateDomains : {}
HasPrivateKey      : True
IsSelfSigned       : True
Issuer             : CN=Microsoft Exchange Server Auth Certificate
NotAfter           : 11/28/2021 12:23:07 AM
NotBefore          : 12/24/2016 12:23:07 AM
PublicKeySize      : 2048
RootCAType         : Unknown
SerialNumber       : 268E6FB9B7312AB24AAA6BA76D06190D
Services           : SMTP
Status             : Invalid
Subject            : CN=Microsoft Exchange Server Auth Certificate
Thumbprint         : A7F9CAA2C9016DB2A80F1E2972E2ED0E2FAE089D

As shown in the following screenshot:

Use the New-ExchangeCertificate command to create a new self-signed certificate for authentication purposes:

[PS] C:\>New-ExchangeCertificate -KeySize 2048 -PrivateKeyExportable $true -SubjectName "cn=Microsoft Exchange Server Auth Certificate" -FriendlyName "Microsoft Exchange Server Auth Certificate" -DomainName @()

Confirm
Overwrite the existing default SMTP certificate?

Current certificate: 'D7081FC32B9BFBEF0C0581584976F690D5F86E74' (expires 11/30/2026 5:21:19 PM)
Replace it with certificate: '309263C8C5B2DA9612E8A6FA9FFFCDEBAC93335D' (expires 11/30/2026 9:00:56 PM)
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [?] Help (default is "Y"): n

Thumbprint                                Services   Subject
----------                                --------   -------
309263C8C5B2DA9612E8A6FA9FFFCDEBAC93335D  ....S..    CN=Microsoft Exchange Server Auth Certificate

As shown in the following screenshot:

When the certificate is created, the AuthConfig needs to be configured, it needs to be published and the old (and expired) certificated needs to be removed. Use the Set-AuthConfig command to achieve this:

[PS] C:\>Set-AuthConfig -NewCertificateThumbprint 309263C8C5B2DA9612E8A6FA9FFFCDEBAC93335D -NewCertificateEffectiveDate (Get-Date)

Confirm
The new certificate effective date is not at least "48" hours in the future and may not be deployed on all necessary
servers. Do you wish to continue?
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [?] Help (default is "Y"): y
[PS] C:\>Set-AuthConfig -PublishCertificate
[PS] C:\>Set-AuthConfig -ClearPreviousCertificate

As shown in the following screenshot:

Restart the Microsoft Exchange Service Host service and perform an IISRESET. If you cannot run IISRESET you can also recycle both the OWA and ECP App pool:

[PS] C:\> Restart-WebAppPool MSExchangeOWAAppPool
[PS] C:\> Restart-WebAppPool MSExchangeECPAppPool

The certificate is stored in Active Directory in CN=Auth Configuration, CN=, CN=Microsoft Exchange, CN=Services,DC=, DC= as shown in the following screenshot:

Since it is published in Active Directory, the new certificate will be automatically available for all Exchange servers in your organization. It can take up to an hour before it is fully published and available, so don’t worry when it doesn’t work immediately.

Please be aware that you do this only on one Exchange server. If you (accidentally) do this on multiple Exchange servers, you will see multiple Auth Certificates appear on your Exchange server. But only the last one created will be active though.

Only two steps remain:

  • Remove the old Auth Certificate on all Exchange servers. You can do this using EAC or using PowerShell (Remove-ExchangeCertficate -Server -Thumbprint <old certificate).
  • Run the Hybrid Configuration Wizard again to update the new certificate in Azure Active Directory.

This computer is a member of a database availability group (DAG)

When uninstalling an Exchange server that is part of a Database Availability Group, you perform several steps to remove the server from the DAG and maybe even delete the DAG itself.

So, after decommissioning the DAG I wanted to uninstall Exchange, but the readiness check failed with the following error message:

This computer is a member of a database availability group (DAG). It must be removed from the DAG before you can uninstall Exchange. For more information, visit: http://technet.microsoft.com/library(EXCHG.150)/ms.exch.setupreadiness.CannotUninstallClusterNode.aspx

Unfortunately this link has not been updates since 2015, and does not contain any useful information.

I decommissioned the DAG earlier as you can see in the following screenshot, but it still failed the readiness check:

When using the Get-DatabaseAvailabilityGroup command nothing showed up, and also when checking Active Directory with ADSI Edit (CN=Organization, CN=Administrative Groups, CN=Exchange Administrative Group (FYDIBOHF23SPDLT), CN=Database Availability Groups) nothing is shown.

The DAG is using bits of Windows failover clustering, so the culprit must be there. When executing the Get-ClusterNode and Get-Cluster commands in PowerShell, some DAG leftovers (on this particular machine) showed up:

Something must have gone wrong during decommissioning of the DAG, although no error were shown on the console.

To remove the cluster node (and thus the cluster) from this machine, execute the following command in PowerShell:

PS C:\> Remove-ClusterNode EXCH12 -Force

After this step uninstalling Exchange succeeds.

Office 365 Directory Synchronization without Exchange server Part II

The question in my previous blog post was “Can we decommission our Exchange servers after moving to Office 365?” and the blunt answer was “No, you cannot decommission your last Exchange server on-premises”.

In this previous blog post I showed you what happens if you synchronize a user to Azure Active Directory from your on-premises Active Directory, and how to create a Mailbox in Exchange Online with a proper primary Email address. At the same time, it was only possible to set only one Email address, and there’s no possibility to add multiple Email addresses, nor is it possible to change any other Exchange related setting.

In this blog post I’ll discuss how to extend Active Directory with Exchange attributes to unleash more functionality and management options in Exchange Online. Please note that the solution in this blog works fine, but it is not recommended and not supported by Microsoft. Continue reading Office 365 Directory Synchronization without Exchange server Part II

How to brand OWA in Exchange 2013

This page is updated with information on Exchange 2016 and Exchange 2019.

A long time ago, Jeff Guillet wrote an excellent post on his EXPTA {blog} on how to brand the OWA logon page in Exchange 2007 and Exchange 2010, which is perfect when testing load balancing solutions. You can find this post here: http://www.expta.com/2010/03/how-to-brand-owa-2007-and-2010-with.html.

For testing OWA in Exchange 2013 and higher, the process is somewhat similar. On the Exchange 2013 Client Access server or Exchange 2016/2019 Mailbox Server, navigate to the C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth directory and open the logon.aspx page with (for example) Notepad. If you are running Exchange 2019 on Windows Server Core you can use the following command:

Notepad “C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\logon.aspx”

In this file, scroll down to the div class=”logonContainer” section and add the servername text just before the UserNameLabel variable, as shown in the following screenshot (click to enlarge)

OWA Logon.aspx

Save the file and in your browser navigate to the Exchange Server to see the results:

owa branding

Warning. When upgrading to a new CU, the logon.aspx is overwritten and you have to make these changes again.

And another warning…. I’m not so sure if this is fully supported by Microsoft 😊

Last Updated on February 27, 2019