Jump to content
Sign in to follow this  
n.armonis

Exchange Server 2016 CU11 on Windows Server 2019 horror...

Recommended Posts

Dear Autoexec Friends,

I am writing this post in English since the experience describes an error found in very recent products of Microsoft and it might help other people around the globe with the same issue.

 

The story begins with a working and healthy installation of Exchange Server 2016 CU3 on a Windows Server 2016. The Exchange was configured with all available roles and it was part of an AD running on a different Windows Server.

 

After a nice CU11 upgrade which worked like a charm updating the Exchange to the latest version, the virus of upgrading to the Exchange Server 2019 was consuming my head. So, I searched for the prerequisites of Exchange 2019 which was definitely Windows Server 2019.

 

!!!Before reading further, I advise you to do something I did not!!!

Please use Windows Backup and get a full VSS backup of your machine running Exchange

 

After mounting the ISO file, I did an in-place upgrade from Windows Server 2016 to 2019. It took like 1 hour to complete with all restarts and etc keeping all existing files and programs.

 

The system was running flawlessly and all services were started including the ones from Exchange. By then, I was happy and took the car for a short drive from Athens to Tripolis for a nice portion of Rost Pig!!!

 

Some hour later, coming back to Athens (with the pig), I checked my emails and found out that there was no new message since I left. Curious, I started searching the root cause ending at Windows Event Viewer which had thousands of new errors repeatedly about Transport Service re-starting after error.

 

Using the Toolbox, I could see all new messages were routed to the Poison Queue.

 

Spending a good 10 hour straight trying-to-debug-horror, I found out that there was an "Access Denied" error that was keeping Exchange Transport Service to write on the Registry key:

Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\AssistantsQuarantine

 

The issue came up because even though the Transport Service is using the Network Service built-in account, the Registry item and its "children" did not have this account configured with Full Control in their permissions.

 

After that, even without a restart, just a service restart, emails where flowing like water!

 

Please share this post to other people so they can leave the horror behind!

 

Best regards,

Nickolas Armonis

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

×
×
  • Create New...