etb
Contributor
Joined 9 years ago
User Profile
User Widgets
Contributions
Re: Support for Modern Standby
Thanks, KateG. I ended up getting budget at the end of 2024 to buy new computers for those which won't support Windows 11. So as soon as I finish getting those deployed, it will be about 60% of our computers that can no longer use WoL. It will be 100% after not too long. What actually prompted me to think of this again today is that there might be a remotely similar thing with macOS as well. I noticed in logs of a new M4 Mac Mini (macOS Sequoia) that there are a decent number of 10050 and 10053 errors when the Mac is not in use. I'mguessingthat that might be Mac "Power Nap" (if they still call it that), which seems similar to Modern Standby for Windows. The Mac stilldoesseem to respond to WoL, so I don't think that this really affects the Mac users. But the Central servers will see a lot of connections and disconnections as the Mac periodically shifts between the low power states. I'm not sure if the "voting" system is new, or if I just missed it before. But could we add 2 votes for the previous posters in this thread who had commented ( 2ARM5 and Verricom )? And if we have to choose between Windows and Mac, I definitely choose Windows :-)7Views0likes1CommentRe: macOS Sequoia 15.2 - LMI Run at Boot?
Thanks, Kate. I did hear from Support, and we emailed a few times. I believe I figured it out in the end, so I'm just sharing here in case anyone else runs into this issue in the future and comes across my post. macOS FileVault came enabled by default on this new Mac. From what I've read, services do not start at boot until after a user who has permission to decrypt the drive logs in locally. Once I disabled FileVault, the issue described in my original post above was resolved. I couldn't immediately find conclusive info regarding when FileVault started being enabled by default. But if you want reliable remote access to a Mac, it seems like you would want to disable FileVault. (It could work to keep it enabled, but then if the Mac ever rebooted, you'd lose remote access until you could log in locally again.) And now that I google "logmein filevault", I see the following couple results: https://discussions.apple.com/thread/255052837?sortBy=rank https://community.logmein.com/discussions/pro/unable-to-connect-to-m1-mac/2908119Views0likes1CommentmacOS Sequoia 15.2 - LMI Run at Boot?
I feel like I have to be doing something wrong, but I can't figure it out. We got a new 2024 Mac Mini M4, and I'm working on configuring it to function basically the same as our old/existing 2019 iMac (which runs Ventura 13.7). I got LMI installed on the new Mini, I got all the permissions granted, etc. It works fine - but only after one of the Mac user accounts is logged into locally, and not immediately after system boot. Immediately after system boot, my LMI admin portal still shows the Mac Mini as offline (even though I am physically looking at the machine being online). If I walk over to the Mini and log into any of the Mac user accounts, then the Mini immediately shows as online in my LMI admin portal, and I can remote control as normal. If I then log out of all Mac user accounts (but otherwise leave the Mini powered on), it still shows as online in my LMI admin portal, and I can still access it for remote control. But now if I reboot the Mini, after it finishes booting (and I tried waiting a few minutes), it shows as offline and can't be reached. I wasn't expecting the "switch on" button to do anything at this point, and indeed it doesn't seem to. I tried: double-checking all Security & Privacy permissions, and they all seem to be granted. looking through LMI Control Panel to check for any settings seeming to be about boot behavior. uninstalling and reinstalling the LMI host software. checking for and installing all available software updates. checking for any LMI software updates (nope - host already on 13393) comparing /library/launchdaemons to the older iMac - theyseem to match. using nano to examine the plist, runatload is set to true, as is keepalive. comparing /library/launchagents to the older iMac - the names of the plist files which are present seem to match, although when using nano to view their contents, it seems that they are a different format/structure (totally different content). googling and chatgpt'ing for help. I can't seem to find anyone else experiencing this issue. Can anyone recommend anything I might be doing incorrectly? Or is there any chance that Sequoia 15.2 broke something which needs to be fixed now?Solved73Views0likes3CommentsRe: Support for Modern Standby
Hi GlennD and/or KateG , Can I ask if there is an update about adding this support for modern standby? We are making the bigger push I mentioned last time to replace our workstations which cannot support Windows 11 (in preparation for Windows 10 EOS). So we have an increasing percentage of new computers for which wake on LAN through LMI doesn't work because of modern standby. Thanks, etb17Views0likes1CommentRe: Hardware Accelerated Video?
HiKateG, May I ask if you ever heard back from the product team about this? (We are more and more in the market for new computers, so I'd like to optimize as much as possible. I didn't want to follow up earlier, because I know there were a couple instances of bigger deals in the past ~6 weeks.)205Views0likes1CommentRe: Host Version 15512 - New "Keystrokes" Permission Defaults to Disabled?
HeyDBedford, May I ask for my own purposes if your affected users are on host version 15512 or 15530? Per Glenn's post above, hosts should have stopped getting updated to 15512 as of June 21st. But I checked the release notes again today, and I see that new version 15530 was released June 27th (today), and it is indicated for 15530 that this issue should be fixed. None of my hosts have been automatically updated to 15530 yet, so I don't know, but I'm just looking to plan accordingly as needed. For your purposes, please don't take my word for it because I'm just a random guy, but maybe a workable solution could be to force the affected hosts to update to 15530? We can trigger hosts to update from the Central admin control web interface.693Views0likes1CommentRe: Host Version 15512 - New "Keystrokes" Permission Defaults to Disabled?
Okay, I chanced getting locked out of this computer in question, and I tested these new permissions by checking/unchecking them for my own user account. If I uncheck the "Keystrokes" permission, I am no longer able to type through LMI. (Although I can still access the on-screen keyboard.) Once I re-check the permission, I can type again. If Iuncheck the "Ctrl-Alt-Del" permission, the ctrl-alt-del button no longer functions. Once I re-check the permission, it works again. I actually didn't bother testing the "blank screen" permission, because it seems straightforward. I havenotyet been able to ask my originally affected user to try again, so I can't be 100% certain that this was the cause of their issue, but it seems like it probably is. So...yeah. Unless my experience is somehow unique, you probably won't want 15512 until maybe these new permissions can default to being enabled for users who already have remote control permissions. Sorry for the uninvited "at", but since this seems kind of urgent...KateG?882Views0likes3CommentsHost Version 15512 - New "Keystrokes" Permission Defaults to Disabled?
I have 1 user who reported today that they could no longer log in to their computer through LMI. They could still hit the control-alt-delete button to log in, but after doing that, they were unable to type anything through LMI. But everything worked perfectly fine for me to remote control their computer using my user account. This is not unlike something that had happened ~8 months ago, so I went about debugging along similar lines as what had worked back then. But then I realized that new version 15512 was released today (link), and it comes with new permissions for Black Screen, Keystrokes, and Ctrl-Alt-Del. I found that the host computer for this 1 affected user had updated already, and theirs is the only 1 of our host computers to get the update so far. And I checked the new permissions for this affected use, and the new permissions all seemingly defaulted to being disabled. The way that the permission descriptions are written (link), it's actually not clear to me whether checking the checkbox of these new permissions enables or disables the ability to use these functions. For example the description for the new Keystrokes permission says "Disable all keystrokes from the client sent to the remote host during remote control". So if I check that checkbox, am I enabling or disabling the user to send keystrokes? When I examine a user that has "full control", these checkboxes are all checked, so for example that makes it seem like checking the checkbox allows the user to send keystrokes. I only really just discovered this a bit ago, so I haven't fully tested yet. But, if these new permissions could effectively default to locking out all non-admin users from using LMI, that might constitute a semi-emergency that should be raised sooner than later. That said, apologies if this winds up being a false alarm.Solved905Views0likes8CommentsRe: Hardware Accelerated Video?
HiKateG, Thanks for not giving up on me yet - I know that walls of text can be brutal 🙂 I don't mean to overexplain this, because I'm definitely very far from an expert, and I could be wrong about details. But basically I'm drawing the parallel to hardware-accelerated video encoding and decoding. An example with which we might be more familiar is like watching videos from the internet. If you would pull an old laptop off the shelf and watch a video, you might find that playing the video uses like 25%+ of CPU and kills the battery quickly. A more modern laptop would have a much easier time playing that same video. The reasons the modern laptop would be so much more efficient with playing the video are many, but one big reason is that the modern laptop would likely have hardware-accelerated video decoding such as Intel Quick Sync, or Nvidia NVDEC, etc. As long as the software being used supports using hardware acceleration, and as long as the hardware supports the codec in use, the specialized hardware can be used to very efficiently decode the video (low CPU/GPU usage). So, tying it back to my question here: is there some particular hardware which can run Screen Blanking notably more efficiently - similar to how hardware with Quick Sync or NVDEC can play videos much more efficiently? Maybe the GoTo developers might say that LMI is using a certain codec, or that Screen Blanking is most optimized for a certain API, and so therefore a particular generation of graphics cards (or newer) would run things notably more efficiently?894Views0likes4CommentsRe: Hardware Accelerated Video?
I ended up having a little time to tool around tonight. Possibly some interesting findings: On myhostcomputer with the "Blank Screen" option enabled, and the "Display Accelerator" enabled, and nothing running on the host other than task manager (and LMI): LMI Remote Control Application process is using about 8-9% CPU and 0% GPU Desktop Window Manager process is using ~5-6% CPU and ~18-22% GPU On myhostcomputer with the "Blank Screen" option disabled, and the "Display Accelerator" enabled, and nothing running on the host other than task manager (and LMI): LMI Remote Control Application process is using about 0-3% CPU and 0-8% GPU. 0.3% GPU when fully idling, or up to 8% GPU when there is more motion on the host screen. Desktop Window Manager process is using ~0% CPU and ~0% GPU I tried turning "Display Accelerator" off and rebooting the host and testing again. The CPU and GPU usage percentages were still the same as above (both when Blank Screen on and Black Screen off). On myclient computer with the "Blank Screen" option enabled, and nothing running on the host other than task manager (and LMI): LogMeIn Client process is using about 10-18% CPU and ~0% GPU Client Server Runtime process is using about ~0% CPU and 10-25% GPU (mostly around ~18% GPU, and only momentary spikes to ~25% GPU when there is a lot of motion on the host screen) Desktop Window Manager process is using ~2% CPU and ~0% GPU On myclient computer with the "Blank Screen" option disabled, and nothing running on the host other than task manager (and LMI): LogMeIn Client process is using about 1-8% CPU and ~0% GPU Client Server Runtime process is using about ~0% CPU and 0-15% GPU (mostly around ~0.5% GPU, and only momentary spikes to ~15% GPU when there is a lot of motion on the host screen) Desktop Window Manager process is using ~0% CPU and ~0% GPU So it seems like it is "Blank Screen" which is comparably very resource-intensive - somehow on both the host and the client. So are there some hardware properties/specs which would be more optimized for use with "Blank Screen"?923Views0likes7Comments