Since the last upgrade to 7.3.5240, if I have a scheduled backup task that needs to be deferred because the computer was offline at the time, Site Manager just fails it and then defers the next offline computer instead.
I have three computers in total and all three of them are in the same single schedule created to backup their system drives. The rules I have in the schedule for deferring the job only seems to apply to the second and third PCs. I have tried deleting the schedule and recreating it but still the same issue.

Anyone else been experiencing this?

Hi,

It's possible that what may be happening here is that the connecting computer connects and negotiates with the site manager server, then the site manager server sends it an update that requires a reconnect - this would result in the backup being released from the deferred state but dropping offline before the backup can be started on it.

This should only ever happen when there are configuration changes like an updated passphrase or Site Manager update - not on every connection, so it looks like there's something unusual going on here. Would you mind using the support portal to report this case so we can gather logs and try to determine what's happening? https://www.macrium.com/support . If you include a link to this forum post in the case, I will make sure it gets to the right place.

Kind Regards,

Alex

Macrium Development

See our reviews on

Thanks Alex. You've given me an idea that I'm going to experiment with first to be sure of the culprit.

I have stopped the Macrium Agent Service on the offending PC to verify that Site Manager no longer sees that computer connected. Then I will wait to see what happens with the scheduled task later tonight when I get home. If it defers accordingly, my next test will be to power the PC up and then shut it down again when I'm physically connected to the local network as opposed to being connected over a VPN.

This will prove to be a vital clue as to what the trigger is, in case if when disconnecting the VPN, there is no opportunity for the PC's agent to negotiate the disconnection from the Site Manager and the connection then stays in limbo until the task starts and then it realises what's going on.

+x

 

Artstar - 6 November 2020 1:01 AM

Thanks Alex. You've given me an idea that I'm going to experiment with first to be sure of the culprit.

I have stopped the Macrium Agent Service on the offending PC to verify that Site Manager no longer sees that computer connected. Then I will wait to see what happens with the scheduled task later tonight when I get home. If it defers accordingly, my next test will be to power the PC up and then shut it down again when I'm physically connected to the local network as opposed to being connected over a VPN.

This will prove to be a vital clue as to what the trigger is, in case if when disconnecting the VPN, there is no opportunity for the PC's agent to negotiate the disconnection from the Site Manager and the connection then stays in limbo until the task starts and then it realises what's going on.

Hi,

thanks for looking into it further! It is possible that there's a difference when there's a graceful or abrupt disconnection. In normal operation, the agent disconnection status is detected on the server by the TCP socket closing. Since this is a negotiation, sudden power off or network disconnections can leave the connection in a 'half open' state. You can see if this happens as the agent would stay 'connected' on the computers page after disconnection.
To remedy this, the Site Manager server does periodic 'keep alive' messages to the agent and vice-versa so it can detect that a TCP socket that appears open has actually closed. When it detects that case, it closes the connection and reports the computer as being disconnected. This can take up to 10 minutes though.

Kind Regards,

Alex

Macrium Development

See our reviews on

The experiment with the VPN failed. If I were to stop the Agent service on the affected PC, wait for Site Manager to indicate that the connection dropped out, then close the VPN connection, it still failed about six hours later when it was scheduled.

Next test will be to repeat the experiment on the weekend (since I need to use the laptop for work during the week) working strictly with the LAN (i.e. no VPN) and see if it yields the same results or not. I'm wondering if the change in IP has anything to do with it, in that while my laptop has a VPN IP, Site Manager sees the VPN IP earlier in the day being reported by the Agent but as it only knows of the LAN IP in the server itself, there's some confusion created there?

Anyway, all theories on my uneducated part. Let's see what the results are this weekend.

Hi,

The IP addresses reported in the Site Manager server are mostly informational - they are the result of DNS/broadcast lookups for information purposes. Since the Agent initiates the Site Manager connection, the IP address doesn't matter too much to the server - the Agent connects, authenticates with the server and tells the server which computer it is and the rest of the communications proceed through that established connection.

Here's the info from one of our test Agents -

The top three IP addresses are the IP address for the computer as determined by the Site Manager server - they are only used for Remote Install, they're included here for information to help diagnose connection issues. The Transport Layer Address is the address that the Agent connected from - the odd format is because the Site Manager server deals with IPv4 and IPv6 connections.

I've conducted some tests on our systems here at Macrium and am having some trouble reproducing - it seems that there's some combination of conditions on your setup that are triggering this bug. We'd like to get it sorted out, so if your weekend tests are inconclusive, we'd appreciate it if you could contact support and get your config sent to us so we could investigate.

Kind Regards,

Alex

Macrium Development

See our reviews on

Sadly no joy. I powered up the laptop and desktop to perform their scheduled backups at 9pm (nightly incremental) and then 1am (weekly differential). Then powered them both down and left them that way for all of Sunday. Laptop still failed the following 9pm time slot.

I'll open a support ticket and provide logs, which I hope are the right ones.

+x

 

Artstar - 16 November 2020 1:13 AM

Sadly no joy. I powered up the laptop and desktop to perform their scheduled backups at 9pm (nightly incremental) and then 1am (weekly differential). Then powered them both down and left them that way for all of Sunday. Laptop still failed the following 9pm time slot.

I'll open a support ticket and provide logs, which I hope are the right ones.

Hi,

Just wanted to confirm that we've received the logs via support and are investigating now.

Kind Regards,

Alex

Macrium Development

See our reviews on

For anyone else reading this thread, this matter has been resolved and will be made available in an update later, whenever that may be. The devs did really well to resolve it in a short space of time and for just a lowly home user like me!

Thanks for reporting back! If anyone else is experiencing similar issues, the fix we deployed for this will be released in a bugfix release of Site Manager in the next week or so, depending on test and QA.

Kind Regards,

Alex

Macrium Development

See our reviews on