Exchange 2016 CU20 Schema Update setup.exe /preparead fail because of case sensitivity of OWA APP Policy

by butsch 19. April 2021 15:57

ISO/PATCH: ExchangeServer2016-x64-cu20

Cumulative Update 20 for Exchange Server 2016 (microsoft.com)

 Problem:

Exchange 2016 CU20 Setup.exe /preparead (Version 15.1.2242.4 Fails) on Server 2016 (1607)

Step Configuring Microsoft Exchange Server Organization Preparation results FAILED

Exchange 2016 CU 20 need and fails to update Active Directory Schema to newer Version (setup.exe /prepareschema works setup.exe /Preparead fails) if you have renames Outlook Web App Policy Default/default/DEFAULT.

We had a case in a Mother / Child Domain setup where we had to update Active Directory of the Mother domain of the company with commandline to a new Schema Version. This was related to the second Exchange 2016 Breach/Hotfix and we wanted to uplift Exchange 2016 from CUMU 19 to 20 urgently.

Prepareschema worked but the second command preparead failed.

 

 Schema Versions

 

 ERROR you see during the setup.exe /preparead

 Error from Powershell

The following error was generated when "$error.Clear();

$policyDefault = Get-OwaMailboxPolicy -DomainController $RoleDomainController | where

{$_.Identity -eq "Default"};

 if($policyDefault -eq $null)

{

New-OwaMailboxPolicy -Name "Default" -DomainController $RoleDomainController

}

" was run:

"Microsoft.Exchange.Data.Directory.ADObjectAlreadyExistsException: Active

Directory operation failed on NOVCHVOLDCW1.novartis.com. The object

'CN=Default,CN=OWA Mailbox Policies,CN=migros,CN=Microsoft

Exchange,CN=Services,CN=Configuration,DC=migros,DC=net' already exists. --->

System.DirectoryServices.Protocols.DirectoryOperationException: The object exists.

at System.DirectoryServices.Protocols.LdapConnection.ConstructResponse(Int32

messageId, LdapOperation operation, ResultAll resultType, TimeSpan

   

   

Source of problem:

   

   

You can see the OWA APP Policy you have with following:

Get-owamailboxpolicy –Domaincontroller Butschdcw1 | Fl identity

Notice the case Sensitivity of the IDENTITY "Default/default/DEFAULT"

   

Error full:

Workaround:

Change the identity name of Outlook Web app Policy back to Default

  1. Go into Exchange 2016 GUI (Exchange Administrative Center)
  2. Permission / Berechtigung
  3. Outlook Web App-Policy/Outlook Web App-Richtlinien
  4. Mark the "Default/default/DEFAULT" and click the PENCIL/EDIT
  5. Change the name to Default (D large rest small chars)
  6. On DOS replicate the DC's with repadmin.exe /syncall

After that you can run setup.exe /preparead and update the Schema for Exchange 2016 CU

   

   

   

   

Check the Schema after replication with repadmin.exe /syncall

CHECK OBJECTVERSION:

$RootDSE= ([ADSI]"").distinguishedName

([ADSI]"LDAP://cn=swiss,cn=Microsoft Exchange,cn=Services,cn=Configuration,$RootDSE").objectVersion

CHECK RANGEUPPER:

$RootDSE= ([ADSI]"").distinguishedName

([ADSI]"LDAP://CN=ms-Exch-Schema-Version-Pt,CN=Schema,CN=Configuration,$RootDSE").rangeUpper

   

16220 > OBJECTVERSION

15333 > RANGEUPPER

   

   

Some further reading why this could have happened

https://devblogs.microsoft.com/scripting/weekend-scripter-unexpected-case-sensitivity-in-powershell/

https://superuser.com/questions/720037/powershell-if-statement-case-insensitive

 

Final note on this issue:

We have seen several other such related issues with 2016/2019 Exchange. Something does not update or install simply because something is case sensitive or some argument is missing or there where it should not be. Mainly in long history customer which where over 15 years on Exchange in several version.

We know how to fix but always say "And then? Next Update or when it runs same? Does it run?" And sometimes Tier 3 from Microsoft does nothing else. They compare what's different with the customer to their reference and then change the Attribute with ADSIEDIT and close the case. That's it, no explanation.

Still the above mentioned gives me some bad feeling. The patch was released ASAP and it was the second patch. If the tested the patch to death someone else would have come again and said why do they keep the patch back so long? (For IT > It was because they had to discuss so long with NSA on how to turn things back).

If you read the story about the FBI who could change your Exchange settings by court you know what happened if you are not a naive IT-world geek.
Cloud Office 365 was not affected because their NSA backdoor works in another way (Read more on Google or search MSDN TechNet

 

 

 

 

Tags:

Exchange 2016 | Hotfixes / Updates

Comments are closed

Werbung von Drittfirmen (Nicht Butsch Informatik):

Werbung von Drittfirmen via Google Adsense: