Shadow redundancy eventID 22004 keep happening after Exchange 2013 CU17 upgrade RRS feed

  • Question

  • Hi all 

    We have 2 exchange 2013 servers (all roles servers). One called mbx01 contain production mailbox databases and the other one mbx02 only contain archived mailbox databases

    We have a receive connector that configure in mbx01 for any internal application to relay email to and it seem to work alright

    It is coincident that after we upgraded to Exchange 2013 CU17 we suffer duplicate email sent out to staff whenever they use relay email. For instance the HR application usually send out email to staff for their payslip and they receive original email fine but later on (after around 3 hours) they receive the same email

    We track down and can see the shadowredundancy eventID 22004 pop up which complain the periodic heartbeat to primary server failed (mbx01 and mbx02 are in the same server subnet without firewall). 

    we checked and we have not made any change to receive connectors and it was working before

    I just dont know if the latest exchange 2013 CU17 cause this issue?

    Currently I have to disable the shadowredundancy in the transport config in mbx02 and it fixed the issue but I believe it is not recommended 

    Hope someone in here will shed some light onto it

    Monday, July 17, 2017 5:57 AM

All replies

  • Hi,

    Based on my research, I don't get any similar feedback after upgrade Exchange 2013 to CU17.
    I suppose it's an individual issue, and I want to confirm:
    1. Does this issue occur on the message which send from internal application by relay connector?
    2. Would you please check the queue status (Get-Queue) in those two Exchange servers? Ensure whether there're lots of emails stuck in Shadow redundancy queue.

    Meanwhile, please run below command and output the results:
    Get-ReceiveConnector | FL name, auth*, perm*, bind*, remote*, iden*, transport*, *port*, *fqdn*,Server,*TimeOut*
    Get-TransportConfig | FL Identity,*Shadow*

    Please ensure there's no wide range of remote IP addresses for receive connector (especial relay connector).
    If so, please set the proper IP address for internal application in remote IP address range, then restart Exchange transport service for testing.


    Allen Wang

    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    If you have feedback for TechNet Subscriber Support, contact

    Tuesday, July 18, 2017 8:30 AM
  • Hi Allen,

    I also get the 22004 error message in the event log and i am seeing a shadow redundancy issue.

    If I enable shadow redundancy emails are delayed as exchange try to send shadow email to another server. The second server was installed two week ago. The old one has a popcon receive connector (still discussing to put it away with the customer). CU17 is installed during the installation of the second server so I did not know if is an cu issue - could be available before too.

    Message tracking for two messages - first without shadow - second email shadow is enabled:

    Timestamp           Source      EventId        ConnectorId                               MessageSubject
    ---------           ------      -------        -----------                               --------------
    04.08.2017 05:47:41 STOREDRIVER RECEIVE                                                  Testemail 20170804-0547
    04.08.2017 05:48:41 SMTP        RECEIVE        WIN-Exchange\Default WIN-Exchange   Testemail 20170804-0547
    04.08.2017 05:48:41 STOREDRIVER SUBMIT                                                   Testemail 20170804-0547
    04.08.2017 05:48:41 AGENT       AGENTINFO                                                Testemail 20170804-0547
    04.08.2017 05:48:42 STOREDRIVER DELIVER                                                  Testemail 20170804-0547
    04.08.2017 05:48:42 SMTP        SEND           Organisationsinterner SMTP-Sendeconnector Testemail 20170804-0547
    04.08.2017 05:52:57 STOREDRIVER RECEIVE                                                  Testemail 20170804-0552
    04.08.2017 05:55:04 SMTP        HAREDIRECTFAIL                                           Testemail 20170804-0552
    04.08.2017 05:55:04 SMTP        RECEIVE        WIN-Exchange\Default WIN-Exchange   Testemail 20170804-0552
    04.08.2017 05:55:04 STOREDRIVER SUBMIT                                                   Testemail 20170804-0552
    04.08.2017 05:55:04 AGENT       AGENTINFO                                                Testemail 20170804-0552
    04.08.2017 05:55:04 STOREDRIVER DELIVER                                                  Testemail 20170804-0552
    04.08.2017 05:55:04 SMTP        SEND           Organisationsinterner SMTP-Sendeconnector Testemail 20170804-0552

    On the old server was a disabled receive connector which is already removed:

    Identity                                                    Bindings                                                    Enabled
    --------                                                    --------                                                    -------
    WIN-ES0FN69669R\Client Frontend WIN-Exchange             {[::]:587,}                                     True
    WIN-ES0FN69669R\Client Proxy WIN-Exchange                {[::]:465,}                                     True
    WIN-ES0FN69669R\Default WIN-Exchange                     {, [::]:2525}                                   True
    WIN-ES0FN69669R\Outbound Proxy Frontend WIN-Exchange     {[::]:717,}                                     True
    WIN-ES0FN69669R\Connector Empang Mails                      {}                                        False
    WIN-ES0FN69669R\Default Frontend WIN-Exchange            {[::]:25,}                                       True
    WIN-ES0FN69669R\PopCon_neu                                  {}                                          True
    VSRVMXS02\Default Exchange02                                 {, [::]:2525}                                   True
    VSRVMXS02\Client Proxy Exchange02                            {[::]:465,}                                     True
    VSRVMXS02\Default Frontend Exchange02                        {[::]:25,}                                       True
    VSRVMXS02\Outbound Proxy Frontend Exchange02                 {[::]:717,}                                     True
    VSRVMXS02\Client Frontend Exchange02                         {[::]:587,}                                     True

    Any ideas?



    Friday, August 4, 2017 4:18 AM
  • OK, there was an external DNS server which cause the issue...

    Now everthing looks fine...



    Monday, August 7, 2017 8:12 AM