none
Mailboxes are quarantined under new Exchange 2019 server RRS feed

  • Question

  • Hi,


    So I had created this post related to the steps of migrating from Exchange 2013 to Exchange 2019.

    https://social.technet.microsoft.com/Forums/en-US/420c6352-fd43-4cf7-8438-360b45c5bffe/migration-stepbystep-microsoft-exchange-2013-to-microsoft-exchange-2019?forum=Exch2019

    I had talked about my issue in it but it will be easier for follow ups under this new post.

    I am having a serious issue with Exchange 2019. Many mailboxes are getting quarantined when they are transfered to this new server or even created directly on it. Not only User Mailboxes but Arbitration Mailboxes also.

    At first, we thought it was related to Migration issues coming over from the Exchange 2013 environment. We thought maybe USER1 was corrupted and would make the Exchange 2019 go wild.

    Test #1 :

    - Migrate USER1 (4gb) from Exchange 2013 to Exchange 2019 (with and without the ForceOffline switch)

    Result #1 :

    - The mailbox gets put in Quarantine. When it is removed from Quarantine, it stays up for 2 minutes and is quarantined again. In the process, some Arbitration Mailboxes are quarantined as well.

    *** To make sure we are on a completely clean database, we deleted our MailBoxDatabase and created a new one for the following test .***

    Test #2 :

    - Run a complete New-MailboxRepairRequest on USER1's mailbox.

    - Migrate USER1 (4gb) from Exchange 2013 to Exchange 2019 (with and without the ForceOffline switch)

    Result #2 :

    - The mailbox gets put in Quarantine. When it is removed from Quarantine, it stays up for 2 minutes and is quarantined again. In the process, some Arbitration Mailboxes are quarantined as well.

    *** To make sure we are on a completely clean database, we deleted our MailBoxDatabase and created a new one for the following test .***

    Test #3:

    - We exported a PST from a user's outlook from a completely different organisation.

    - We created a new user 'USER2' in the domain and created a mailbox for him on Exchange 2013.

    - We imported the PST into USER2's mailbox and waited for it to upload to the Exchange 2013.

    - Run a complete New-MailboxRepairRequest on USER2's mailbox on Exchange 2013.

    - Migrate USER2 (1gb) from Exchange 2013 to Exchange 2019 (with the ForceOffline switch)

    Result #3 :

    - The mailbox gets put in Quarantine. When it is removed from Quarantine, it stays up for 2 minutes and is quarantined again. In the process, some Arbitration Mailboxes are quarantined as well.

    *** To make sure we are on a completely clean database, we deleted our MailBoxDatabase and created a new one for the following test .***

    Test #4 :

    - We created a mailbox for USER3 directly on the Exchange 2019.

    - We imported some data from a PST into USER3's mailbox.

    Result #4 :

    - The mailbox gets put in Quarantine during the import. When it is removed from Quarantine, it stays up for 2 minutes and is quarantined again. In the process, some Arbitration Mailboxes are quarantined as well.

    *** To make sure we are on a completely clean database, we deleted our MailBoxDatabase and created a new one for the following test .***

    Test #5 :

    - We added RAM to the machine and added CPU cores

    - We created a mailbox for USER4 directly on the Exchange 2019.

    - We imported some data from a PST into USER4's mailbox.

    Result #5 :

    - The mailbox gets put in Quarantine during the import. When it is removed from Quarantine, it stays up for 2 minutes and is quarantined again. In the process, some Arbitration Mailboxes are quarantined as well.

    - RAM usage is at 50% and CPU's are sleeping.

    =============================================================

    So the recap :

    - We have tried 2 different Exchange 2019 on two different sets of hardware.

    - Install steps followed are the ones described in : https://social.technet.microsoft.com/Forums/en-US/420c6352-fd43-4cf7-8438-360b45c5bffe/migration-stepbystep-microsoft-exchange-2013-to-microsoft-exchange-2019?forum=Exch2019

    - I am ALWAYS face with mailboxes being quarantined. Not only after migration but brand new mailboxes.

    - There is no A/V and Windows Defender has been disabled on the server.

    - I have tried to repair the mailboxes BEFORE the move (when they were on 2013) and AFTER the move (once they are on 2019).

    - This occurs whether a mailbox is moved from Exchange 2013 to Exchange 2019 or even if the mailbox is brand new on Exchange 2019.

    - I have tried multiple combinations where the system mailboxes reside with the user mailboxes on the same mailbox database, or if the system mailboxes have their own mailbox database. I have created and moved my stuff between new databases for every single test.

    - I do not have the expected Event Logs describing the Mailbox Quarantine actions.

    - The mailboxes that were tried for these tests are running absolutely fine under Exchange 2013.

    My questions :

    - Is there anyone on this forum that can tell me they are running on 100% production on Exchange 2019?

    - Is there anyone on this forum that has faced this mailbox quarantine issue? If yes, how did you get out of it?

    - I have seen that Exchange 2016 had trouble with the newest Framework versions and caused unstable EDBs. However, the minimum requirement for Exchange 2019 IS the newest Framework version. Could it be related?

    Any help would be GREATLY appreciated.






    Monday, January 21, 2019 4:49 PM

Answers

  • Hi everyone,

    After opening a ticket with Microsoft paid-support, and my case going up to the lead Exchange 2019 developer,  I was finally able to fix my issue once and for all (I hope so...)

    When running get-transportconfig, you need to be ABSOLUTELY sure that the value for maxreceivesize or maxsendsize is not unlimited. This was supported with past versions of Exchange but is now causing MAJOR issues with the newer Exchange 2019 environment. The moment the unlimited was changed to 35MB, all my problems were gone. I have not had one single mailbox go into quarantine ever since. None of my databases 

    Even though Microsoft refuses to call this a 'bug', they should be releasing a KB concerning this issue very soon. I would have never expected such a simple setting (that works absolutely fine under 2016 and all previous Exchange versions) to have such a destructive impact on Exchange 2019. 

    Personally, I have no idea what these values are used for as I have size restrictions on my Receive/Send Connectors and they work very well. I am just VERY happy that I have found a way around this issue that has been blocking my migration since DECEMBER.

    Thank you to everyone for all your help

    Wednesday, April 24, 2019 4:02 PM
  • Thank you for this. I have been fighting with a 2016 (CU14) to 2019 (CU3) migration for two days, the mailboxes work fine on 2016 but as soon as moved to 2019 everything starts crashing and quarantining.

    I checked and maxreceivesize was unlimited, maxsendsize wasn't, so I left that one alone

    I have implemented your fix in the midst of trying to move everything back to the 2016 server, one mailbox failed move and is still on 2019 but is now accessible and nothing is quarantined. I shall let it run like this for a day or two and thoroughly test that mailbox, before starting to move things back in the 2019 direction.

    The fix specifically for me was:

    1. set-transportconfig -maxreceivesize 35MB

    2. restart the "Microsoft Exchange Transport" service

    Wednesday, November 13, 2019 12:07 AM

All replies

  • Hi,

    Even though it is listed as 100% compatible, I have yet to find an accurate step by step guide for a 2013 to 2019 migration. Here is a summary of the steps I have done in my lab thus far.

    #0 - Bring up the Microsoft Exchange 2013 to the latest CU.

    #1 - Add Anti-Virus Exceptions on the server as mentionned in Microsoft Document + Disable Windows Defender using Powershell
    #2 - Install Visual C++ Redistributable Package for Visual Studio 2012 (x64)
    #3 - Install Visual C++ Redistributable Package for Visual Studio 2013 (x64)
    #4 - Microsoft Unified Communications Managed API 4.0
    #5 - Install the required Windows features (Powershell)
    #6 - Make sure user has required AD rights for Exchange installation and management
    #7 - Install Microsoft Exchange 2019
    #8 - Verify Exchange Installation
    #9 - Launch Windows Updates
    #10 - Activate the Microsoft Exchange 2019 Server
    #11 - Configure the freshly created default Mailbox Database (quotas, name, etc.)
    #12 - Transfer Exchange Certificate to Exchange 2019
    #13 - Exchange 2019 Assign Services to Certificate
    #14 - Confirm that the new certificate is in place.
    #15 - Deploy the Backup Agent, test backups and restores.
    #16 - Configure the Outgoing Firewall rule for port 25 for Exchange 2019.
    #17 - Configure all the Receive Connectors on 2019 just like the ones on 2013
    #18 - Add Exchange 2019 to the Send Connector.
    #19 - Create a user on Exchange 2019 and do some tests.
    #20 - Set the OWA Virtual Directory Configuration (URL)
    #21 - Set the ECP Virtual Directory (URL)
    #22 - Set the Outlook Anywhere (URL)
    #23 - Set the ActiveSync Virtual Directory (URL)
    #24 - Set Exchange Web Services Virtual Directory (URL)
    #25 - Set OAB Virtual Directory (URL)
    #26 - Set the AutoDiscover Virtual Directory (URL)
    #27 - Set the MAPI Virtual Director (URL)
    #28 - Test in/out mails.
    #29 - Configure rules on Firewall to point OWA to Exchange 2019
    #30 - Change the internal A Record to point to the new Exchange 2019
    #31 - Change the Antispam Mail Destination to the Exchange 2019 server.
    #32 - Launch some tests.
    #33 - Move the System Mailboxes
    #34 - Move the Public Folders
    #35 - Move User Mailboxes

    QUESTIONS :

    A : How many ARBITRATION MAILBOXES does a Microsoft Exchange 2013 server normally have? I currently have 5 which I will switch over to the Microsoft Exchange 2019 server, which has already 2 of them on a new install.

    B: During step #33, moving my Arbitration Mailboxes, my Exchange 2019 server seems to become a bit flaky, the 'Get-MoveRequest | Get-MoveRequestStatistics' command will sometimes output an error saying the database is offline. Is this behavior normal? After I have moved all the Arbitration Mailboxes, server seems to be OK.

    C: During co-existence, can the URLs from #20 to #27 stay the same on BOTH servers (mail.domain.com/xxx)? Do I have to change the URLs on the 2013 servers to something like legacy.domain.com)

    D: Has anyone successfully managed a Exchange 2013 to Exchange 2019 migration? If so, how do the steps differ from mine?



    Thursday, January 3, 2019 8:53 PM
  • Truly say there is not much difference between Exchange 2013 to Exchange 2016 and Exchange 2013 to Exchange 2019 migrations.
    Please take note on that Exchange 2019 allows you to proxy traffic from Exchange 2013 Client Access servers to Exchange 2019 mailboxes. So you can have same url's on both Exchange 2013 and Exchange 2019.
    Steps are fine to me.


    Thanks, Ashish MCITP, MCT, MCSE

    Thursday, January 3, 2019 10:19 PM
  • Hi,

    Even though it is listed as 100% compatible, I have yet to find an accurate step by step guide for a 2013 to 2019 migration. Here is a summary of the steps I have done in my lab thus far.

    #0 - Bring up the Microsoft Exchange 2013 to the latest CU.

    #1 - Add Anti-Virus Exceptions on the server as mentionned in Microsoft Document + Disable Windows Defender using Powershell
    #2 - Install Visual C++ Redistributable Package for Visual Studio 2012 (x64)
    #3 - Install Visual C++ Redistributable Package for Visual Studio 2013 (x64)
    #4 - Microsoft Unified Communications Managed API 4.0
    #5 - Install the required Windows features (Powershell)
    #6 - Make sure user has required AD rights for Exchange installation and management
    #7 - Install Microsoft Exchange 2019
    #8 - Verify Exchange Installation
    #9 - Launch Windows Updates
    #10 - Activate the Microsoft Exchange 2019 Server
    #11 - Configure the freshly created default Mailbox Database (quotas, name, etc.)
    #12 - Transfer Exchange Certificate to Exchange 2019
    #13 - Exchange 2019 Assign Services to Certificate
    #14 - Confirm that the new certificate is in place.
    #15 - Deploy the Backup Agent, test backups and restores.
    #16 - Configure the Outgoing Firewall rule for port 25 for Exchange 2019.
    #17 - Configure all the Receive Connectors on 2019 just like the ones on 2013
    #18 - Add Exchange 2019 to the Send Connector.
    #19 - Create a user on Exchange 2019 and do some tests.
    #20 - Set the OWA Virtual Directory Configuration (URL)
    #21 - Set the ECP Virtual Directory (URL)
    #22 - Set the Outlook Anywhere (URL)
    #23 - Set the ActiveSync Virtual Directory (URL)
    #24 - Set Exchange Web Services Virtual Directory (URL)
    #25 - Set OAB Virtual Directory (URL)
    #26 - Set the AutoDiscover Virtual Directory (URL)
    #27 - Set the MAPI Virtual Director (URL)
    #28 - Test in/out mails.
    #29 - Configure rules on Firewall to point OWA to Exchange 2019
    #30 - Change the internal A Record to point to the new Exchange 2019
    #31 - Change the Antispam Mail Destination to the Exchange 2019 server.
    #32 - Launch some tests.
    #33 - Move the System Mailboxes
    #34 - Move the Public Folders
    #35 - Move User Mailboxes

    QUESTIONS :

    A : How many ARBITRATION MAILBOXES does a Microsoft Exchange 2013 server normally have? I currently have 5 which I will switch over to the Microsoft Exchange 2019 server, which has already 2 of them on a new install.

    B: During step #33, moving my Arbitration Mailboxes, my Exchange 2019 server seems to become a bit flaky, the 'Get-MoveRequest | Get-MoveRequestStatistics' command will sometimes output an error saying the database is offline. Is this behavior normal? After I have moved all the Arbitration Mailboxes, server seems to be OK.

    C: During co-existence, can the URLs from #20 to #27 stay the same on BOTH servers (mail.domain.com/xxx)? Do I have to change the URLs on the 2013 servers to something like legacy.domain.com)

    D: Has anyone successfully managed a Exchange 2013 to Exchange 2019 migration? If so, how do the steps differ from mine?



    The URLs for the virtual directories should be set immediately after installation and the cert installed and applied to the services should have the correct subject names to match the hostnames set in the virtual dirs.

    Personally, I think its too soon to do this in prod. Testing is fine of course

    Thursday, January 3, 2019 10:42 PM
    Moderator
  • Hi,

    A: How many ARBITRATION MAILBOXES does a Microsoft Exchange 2013 server normally have? I currently have 5 which I will switch over to the Microsoft Exchange 2019 server, which has already 2 of them on a new install.

    It is a normal behavior, in a coexist environment, it will recreated some system mailboxes automatically:


    -----------------------------------------------------------------------

    B: During step #33, moving my Arbitration Mailboxes, my Exchange 2019 server seems to become a bit flaky, the 'Get-MoveRequest | Get-MoveRequestStatistics' command will sometimes output an error saying the database is offline. Is this behavior normal? After I have moved all the Arbitration Mailboxes, server seems to be OK.

    Consider it in conjunction with another question, I guess there may exist some issue about the default database on your Exchange 2019:

    I would suggest you try to create a new database to replace it then delete the default database.

    If this phenomenon still exist,  there may exist bad points on the disk that host your Exchange 2019’s database, please try to create database on other disk.

    -----------------------------------------------------------------------

    C: During co-existence, can the URLs from #20 to #27 stay the same on BOTH servers (mail.domain.com/xxx)? Do I have to change the URLs on the 2013 servers to something like legacy.domain.com)

    You can set them use the same external URL, then point DNS to any of them. You can also use different URLs for them. Those articles will be useful to you(Exchange 2019 coexist with Exchange 2013 is same as Exchange 2016 coexist with Exchange 2013): 

    Client Connectivity in an Exchange 2016 Coexistence Environment with Exchange 2013

    Understanding Proxying and Redirection

    -----------------------------------------------------------------------

    D: Has anyone successfully managed a Exchange 2013 to Exchange 2019 migration? If so, how do the steps differ from mine?

    It is same as migrate from Exchange 2013 to Exchange 2016.

    Regards,

    Kyle Xu


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Teams.

    Friday, January 4, 2019 8:45 AM
    Moderator
  • Hi,

    Concerning Question B : 

    I get the same result with another database. I also get the error on the Web UI with the new interface..

    New Question / Issue E: 

    Also, a new issue which I seem to be having repeatedly. 

    When I migrate a certain mailbox from 2013 to 2019, it gets instantly put into a Quarantined State. The Mailbox seems to be working absolutely fine with 2013. When the Mailbox is transfered to 2019, the 2019 server gets errors, and I get ESE logs saying that the Database was unmounted then mounted. I find it hard to believe that the Maibox runs absolutely fine on 2013 and causes major issues on 2019.

    When I try the MailboxRepairRequest commands, they fail and cannot complete because the database on which the mailbox is located is unstable when it is removed from quarantine. 

    I created a new database on 2019 and have moved the system mailboxes to it. I have disabled the user's problematic mailbox on 2019 and restored a backup PST to a new mailbox on 2013. 

    I am going to try repairing the mailbox on 2013 BEFORE doing a MoveRequest on it. I will also add the ForceOffline parameter to the MoveRequest. I will keep you guys posted with the results.

    Question F: 

    Is it a good practice to proceed with a MailboxRepairRequest of all the mailboxes before migrating them? If in production my 12 first mailbox migrations work well and then the 13th makes the destination server go wild, all 13 users are going to be facing major problems.

    Friday, January 4, 2019 6:57 PM
  • One more thing which I want to share is that Exchange 2019 only support TLS 1.2. So you have to prepare older versions and other applications which are going to connect to Exchange 2019 should have TLS 1.2 enabled.

    Question F:- There is no need to run repair request until you don't see any corruption issue on mailbox.

    Question E:- Please make sure that Exchange is excluded from Antivirus scanning. I didn't face such issue when I migrated from Exchange 2016 to exchange 2019. You need to check logs why mailbox got quarantined. Whenever any mailbox gets quarantined a event (Event id 10018) generates under event viewer which contains reason behind quarantine.


    Thanks, Ashish MCITP, MCT, MCSE

    Friday, January 4, 2019 7:16 PM
  • Here is an update on my tests.

    SITUATION : We had a problematic mailbox (JSmith). When the mailbox (JSmith) resided on 2013, there were absolutely no issues to report. When JSmith was migrated to 2019, the 2019 database would not behave normally after the migration, crash and put the mailbox in quarantine. It would also even put some other user mailboxes in quarantine. Logs would tell us that the database would get detached and re-attached for no reason.

    TEST #1 : We tried to repair the JSmith's Mailbox while it was on 2019. However, when we took it out of quarantine and tried the repair, the Exchange Database went wild and detached itself. Therefore, our repair would never manage to go through. We disabled that JSmith's mailbox, created a new one for him on 2013 and restored a backup to it.

    TEST #2 : We exported the JSmith's mailbox to PST. We created a TestUser1 and restored the PST to it. We moved TestUser1 to the Exchange 2019 Database and the same issues started happening again. We disabled TestUser1's mailbox, created a new one on 2013 and restored the PST to it again.

    TEST #3 : We ran a New-MailboxRepairRequest on the TestUser1 Mailbox while it still was on 2013. Once that finished, we moved it to 2019. After the migration, no issues at all and server was OK.

    What this seems to to tell us : Even though our original user JSmith had absolutely no issues accessing his mailbox and working with it, it seems as if some corruption in his items was causing 2019 to have database crashes. It is quite scary. Since our 2019 server has been stable with TestUser1's mailbox, which is in fact a restore from JSmith's PST, we will be officially moving JSmith to Exchange 2019 tonight after running a New-MailboxRepairRequest on his mailbox on 2013.

    I am really starting to believe that the safest way would be to repair all my mailboxes in their original location prior to migration. How can a perfectly working mailbox on 2013 make a 2019 server crash this much after being migrated?

    Scary ....

    Monday, January 7, 2019 5:07 PM
  • Can you please make sure that antivirus not scanning Exchange on Exchange 2019?

    Also try to create new mailbox database on Exchange 2019 and then try.

    Database corruption also can cause mailbox quarantine.


    Thanks, Ashish MCITP, MCT, MCSE

    Monday, January 7, 2019 5:19 PM
  • Monday, January 7, 2019 5:44 PM
  • Can you please make sure that antivirus not scanning Exchange on Exchange 2019?

    Also try to create new mailbox database on Exchange 2019 and then try.

    Database corruption also can cause mailbox quarantine.


    Thanks, Ashish MCITP, MCT, MCSE


    Hi, to make sure it wasn't an issue, Windows Defender has been uninstalled from 2019 and Antivirus is not installed. Since it was a lab and we wanted to make sure the basics were working, we confgured with only Exchange software and its prerequisites. We have tried to create new databases between the steps. The "non-repaired" mailbox would make every database crash.
    Monday, January 7, 2019 5:50 PM
  • Hi,

    Concerning Question B : 

    I get the same result with another database. I also get the error on the Web UI with the new interface..

    New Question / Issue E: 

    Also, a new issue which I seem to be having repeatedly. 

    When I migrate a certain mailbox from 2013 to 2019, it gets instantly put into a Quarantined State. The Mailbox seems to be working absolutely fine with 2013. When the Mailbox is transfered to 2019, the 2019 server gets errors, and I get ESE logs saying that the Database was unmounted then mounted. I find it hard to believe that the Maibox runs absolutely fine on 2013 and causes major issues on 2019.

    When I try the MailboxRepairRequest commands, they fail and cannot complete because the database on which the mailbox is located is unstable when it is removed from quarantine. 

    I created a new database on 2019 and have moved the system mailboxes to it. I have disabled the user's problematic mailbox on 2019 and restored a backup PST to a new mailbox on 2013. 

    I am going to try repairing the mailbox on 2013 BEFORE doing a MoveRequest on it. I will also add the ForceOffline parameter to the MoveRequest. I will keep you guys posted with the results.

    Question F: 

    Is it a good practice to proceed with a MailboxRepairRequest of all the mailboxes before migrating them? If in production my 12 first mailbox migrations work well and then the 13th makes the destination server go wild, all 13 users are going to be facing major problems.

    I would suggest you delete “Migration.8f3e7716-2011-43e4-96b1-aba62d229136” from Exchange 2016, then recreate it in Exchange 2019

    Then use command below to remove all old migration request:

    Get-MoveRequest | Remove-MoveRequest

    Then, try to migrate mailbox from one database to other database within Exchange 2016, then migrate mailbox from one database to other database within Exchange 2019. Check whether mailbox could be migrated within Exchange server rather from Exchange 2016 to Exchange 2019.

    Please note:  For other users to search and reference, our forum is "One issue one thread", if you have more confusion about Exchange, I would suggest you open a new thread and post it in it.

    Regards,

    Kyle Xu


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Teams.

    Tuesday, January 8, 2019 8:45 AM
    Moderator
  • Can you please share evnt id 10018 and 10027 from exchange 2019?


    Thanks, Ashish MCITP, MCT, MCSE

    Tuesday, January 8, 2019 11:05 PM
  • Can you please share evnt id 10018 and 10027 from exchange 2019?


    Thanks, Ashish MCITP, MCT, MCSE


    None of these appear.
    Monday, January 21, 2019 4:16 PM
  • I really don't get why my posts were merged under a single one.

    I think the subjects were quite different :

    1 - The Step by Step Migration Process from Exchange 2013 to Exchange 2019.

    2 - Problems with mailboxes being quarantined under Exchange 2019

    Tuesday, January 22, 2019 2:37 PM
  • Hi andrewgarcalopes,

    About New-MailboxExportRequest stuck in queued status, I think this article will be useful to you. I would recommend that you first try to migrate a small size mailbox, then check whether it could be migrated successfully.

    This issue may by caused by quota on database, it also may be caused by this large load task.

    Regards,

    Kyle Xu


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Teams.

    Wednesday, January 23, 2019 2:06 AM
    Moderator
  • Hi Andrew, we're expericing exactly the same issue regarding quarantined mailboxes. Any suggestions to fix it ?

    Many Thanks in advance,

    Wednesday, March 27, 2019 2:50 PM
  • Hi Andrew, we're expericing exactly the same issue regarding quarantined mailboxes. Any suggestions to fix it ?

    Many Thanks in advance,

    Hi Affx,

    No, absolutely NOT FIXED and I would love if we could have a chat over this. I do not find anyway for me to send you a private message on this site with my contact information. I would even be available for a phone call for us to discuss our environments and try to find any similarities!

    Wednesday, March 27, 2019 3:00 PM
  • Hi,

    Do you see event id 1014 whenever mailbox getting quarantined?

    It will generate on Server where user mailbox database mounted.


    Thanks,

    Ashish

    MCITP, MCT, MCSE

    “Tell me and I forget, teach me and I may remember, involve me and I learn.”

    Note:- Please remember to vote and mark the replies as answers if they help.

    Disclaimer: This posting is provided "AS IS" with no warranties or guarantees and confers no rights.

    Wednesday, March 27, 2019 5:19 PM
  • I'm doing testing for a 2013 to 2019 migration in a lab environment (so they are very "clean" source mailboxes as i just created them and made 100 or so dummy messages by replying to a bunch of emails). No such quarantine seen. Although i'm very interested in this thread as my next step is my prod environment, which obviously has many years of history to the source mailboxes. 

    Wednesday, March 27, 2019 5:23 PM
  • Update on my experience. I've now moved 10 mailboxes, including some that were 100GB (i know, i know). No quarantines on my side.
    Wednesday, April 24, 2019 3:54 PM
  • Hi everyone,

    After opening a ticket with Microsoft paid-support, and my case going up to the lead Exchange 2019 developer,  I was finally able to fix my issue once and for all (I hope so...)

    When running get-transportconfig, you need to be ABSOLUTELY sure that the value for maxreceivesize or maxsendsize is not unlimited. This was supported with past versions of Exchange but is now causing MAJOR issues with the newer Exchange 2019 environment. The moment the unlimited was changed to 35MB, all my problems were gone. I have not had one single mailbox go into quarantine ever since. None of my databases 

    Even though Microsoft refuses to call this a 'bug', they should be releasing a KB concerning this issue very soon. I would have never expected such a simple setting (that works absolutely fine under 2016 and all previous Exchange versions) to have such a destructive impact on Exchange 2019. 

    Personally, I have no idea what these values are used for as I have size restrictions on my Receive/Send Connectors and they work very well. I am just VERY happy that I have found a way around this issue that has been blocking my migration since DECEMBER.

    Thank you to everyone for all your help

    Wednesday, April 24, 2019 4:02 PM
  • Thanks for your sharing.

    Regards,

    Kyle Xu


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Teams.

    Thursday, April 25, 2019 8:19 AM
    Moderator
  • Thank you for this. I have been fighting with a 2016 (CU14) to 2019 (CU3) migration for two days, the mailboxes work fine on 2016 but as soon as moved to 2019 everything starts crashing and quarantining.

    I checked and maxreceivesize was unlimited, maxsendsize wasn't, so I left that one alone

    I have implemented your fix in the midst of trying to move everything back to the 2016 server, one mailbox failed move and is still on 2019 but is now accessible and nothing is quarantined. I shall let it run like this for a day or two and thoroughly test that mailbox, before starting to move things back in the 2019 direction.

    The fix specifically for me was:

    1. set-transportconfig -maxreceivesize 35MB

    2. restart the "Microsoft Exchange Transport" service

    Wednesday, November 13, 2019 12:07 AM
  • Thank you, thank you, thank you.

    That's been a setting on our server since Exchange 2003 or 2007 ... Never been an issue till 2019.

    I've spent many hours on it till hitting this post.


    Regards, Mike Lazarus GL Computing https://about.me/GLComputing

    Saturday, December 28, 2019 11:19 PM