Mid Server issue after clone and upgrade: "Unable to subscribe to AMB channel: /mid/server/"Issue <!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } When finding the warning "Unable to subscribe to AMB channel: /mid/server/<sys_id>", specially if the error is present with all the mid servers in the same Environment after an upgrade following a clone. Agent log message will look like below: 2020-02-18 09:08:43 (019) StartupSequencer Initializing AMB client...2020-02-18 09:08:43 (023) AMBClientProvider Connecting AMB client to instance......2020-02-18 09:08:43 (796) StartupSequencer StartupSequencer: setting sysId: <sys_id>, command: sudo, password prompt: as default privileged command...2020-02-18 09:08:43 (930) AMBClientProvider WARNING *** WARNING *** Unable to subscribe to AMB channel: /mid/server/<sys_id>...2020-02-18 09:09:50 (264) ECCQueueMonitor.40 WARNING *** WARNING *** Reconnecting AMB channel.. And repeats again... 2020-02-18 09:09:50 (265) ECCQueueMonitor.40 Initializing AMB client...2020-02-18 09:09:50 (272) AMBClientProvider Connecting AMB client to instance...Release<!-- /*NS Branding Styles*/ --> .ns-kb-css-body-editor-container { p { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } span { font-size: 12pt; font-family: Lato; color: var(--now-color--text-primary, #000000); } h2 { font-size: 24pt; font-family: Lato; color: var(--now-color--text-primary, black); } h3 { font-size: 18pt; font-family: Lato; color: var(--now-color--text-primary, black); } h4 { font-size: 14pt; font-family: Lato; color: var(--now-color--text-primary, black); } a { font-size: 12pt; font-family: Lato; color: var(--now-color--link-primary, #00718F); } a:hover { font-size: 12pt; color: var(--now-color--link-primary, #024F69); } a:target { font-size: 12pt; color: var(--now-color--link-primary, #032D42); } a:visited { font-size: 12pt; color: var(--now-color--link-primary, #00718f); } ul { font-size: 12pt; font-family: Lato; } li { font-size: 12pt; font-family: Lato; } img { display: ; max-width: ; width: ; height: ; } } Any release that uses AMB (Helsinki and later, which is when the AMB Channel was implemented).This issue is related to the clone performed in the instance combined to the version upgrade of the MID server.Cause One possible cause if this is only seen after an instance clone and upgrade, is a encryption key mismatch between the instance and mid server. However it is more likely that there were already AMB Channel connection issues in the mid server agent logs before, and that is likely tio be caused by netowrk infrastructure on the customer's sice. For example a proxy or firewall dropping sessions. Resolution The solution to this issue is to rekey the MID server, using the steps described in Rekey a MID Server. That's now only possible to do with a MID Server using basic auth and a username and password. That's not a solution for MID Servers's using iPKS or mTLS authentication with the instance. Causes and workaround for when this issues is caused intermittently at other times are discussed in this article, which has this subject because a slight delay in realising there are new jobs in the queue is really the only impact of an AMB channel not working.KB0695359 Why do my integrations via MID Servers sometimes take up to 40 seconds longer to run, or timeout? If integrations are designed to cope with small (and long) delays in the ECC Queue, which is to be expected, especially during upgrades when all mid servers are down, then AMB Channel issues are not a problem. For designing REST/SOAP integrations so that they can run truly asynchronously, and not be waiting or timing out, see:KB0694711 Outbound REST Web Services RESTMessageV2 and SOAPMessageV2 execute() vs executeAsync()The section "RESTMessageV2: MID Server, executeAsync(), setEccParameter('skip_sensor', 'true'), setEccCorrelator()" at the end is the only way a MID Server sould be used with the RESTMessageV2/SOAPMessageV2 APIs.