Support for Modern Standby

Hey etb ,

Thank you for your suggestion. Can you please contact our support, get debug level logging set up on your given hosts (that cannot be woken up with WoL packets) and ensure that we get these logs? This way we can investigate what changes needs to be done in order to support Modern Standby with LMI.

Hi ProCentPM ,

Thank you very much for looking into this. 

Sure - I can send logs.  I can work with Support to actually enable that logging, but would you say that there should be any particular scenario that you would want to see demonstrated?  Naturally nothing is being logged when the computers are powered down and the LMI servers believe that they are unable to be remotely switched on.  So do you maybe just want to see:

1. Enable logging
2. Start remote control session just for a baseline
3. End remote control session just for a baseline
4. Shut down the computer
5. Start the computer up again by either pressing the physical button on the tower or using some other tool (not LMI) to WoL
6. Collect and send logs to Support
7. Anything else?

Just for clarity - these computers can be switched on with WoL packets if I generate the WoL packet using any other tool.  In other words, if the network cards of these computer receive a magic packet, they do wake up.  It seems that it's just that the LMI servers think that the computers cannot be remotely switched on, and so the web portal or remote LMI client software gray out the option to switch on.

Hey etb ,

Thank you for your reply. I think debug level logging shall be enabled and then a generated WoL packet shall be sent towards the host that is capable of waking up your computers that already has Modern Standby "forced", if this makes sense. We would like to see the ethernet frame and basically the packet contents plus the host side as well in order to work out a solution that can be used in LogMeIn Central to support machines with Modern Standby. 

Hi ProCentPM ,

Sorry for the delay getting back to you.  Tonight I enabled the debug-level logging and reproduced the issue through a few shutdowns, remote control sessions, and reboots.  I took a copy of the LogMeIn log, and I have it ready to send to you.

I had asked GoTo Support if I could send the log file to them and they could get it to you, but they said that I should send it to you directly 😕.  But I'm not sure that it's even possible for me to attach a file here, and I wouldn't want to post it publicly anyway.  Is there some way that I can send you this log reasonably securely?

Hey etb ,

No worries, we'll find a way. 🙂 I'll reach out to you in private. 

I am seeing the same issue, the wake function from the LogMeIn Client sent to some target Dell machines no longer works (nor does it on a handful of Lenovo V520 devices and one HP deskpro model) despite there being other active machines with the LogMeIn controls in the remote network.

The WoL feature in the client routers however is able to send such a signal to all these affected devices and trigger them to start back up.

This suggests something is not working in the LogMeIn Client program when used as an admin support tool, ideally could this not be fixed to use both the current process and to trigger other machines in the remote network to send a standard WoL packet so that the "best of both worlds" approach would ensure the target machine starts back up.

Currently the extra steps in having to remotely connect and send this info is time consuming and such a feature would be really good to have restored to full functionality on all hardware platforms.

Hi ProCentPM,

Just checking in.  Is this still under consideration?  [fingers crossed]

Hi etb ,

Absolutely. Currently we are busy finalizing all roadmap items for the year. We will be dealing with this request the soonest possible, it is at the top of our backlog. We'll get there. 

Hi ProCentPM ,

Is there any update on this?

For full disclosure, I have not needed to deploy any new non-workstation computers recently, so I do not know to what extent Dell has continued forcing Modern Standby on newer BIOS (UEFI).  In other words, I have not run into the issue recently, although I assume it is only a matter of time.

etb  This was looked at earlier in the year and the amount of work required meant it wasn't feasible at this time. We plan to review this again soon and reevaluate the effort involved.