Remote Support
Remote Access
Monitoring and Management
Presentation
Remote Work
Standard
Business
EnterpriseBear in mind, the devs do not monitor this forum. If you haven’t already, you should file a support ticket. 
1 Like
From the tech app, I just drag the computer to the folder it needs to be in.
1 Like
@Tony - would be useful if you could maybe update your original post to contain a summary of the issues? 
Does Discourse has pinned messages?
I think adding new favourites is broken, i.e. add a new favourite works but it’s not saved when you exit the technician client and re-load.
1 Like
Yes, confirmed on two technician PCs. Support ticket raised.
Supplemental problem - anyone else getting a gray display on connecting? A reconnect fixes it:
1 Like
This has been reported Rob. I think they are working on a fix for this issue. I’ve submitted several logs to the support team with examples of the issue. Hope to hear a fix being released soon! 
1 Like
Anyone successfully installed the Remote Access Client on a M1 Mac with OSX monterey?
Every time I start the app, it creates a process called GenericUpdateLoader which uses approx. 50mb of memory, and keeps repeating this process with a new process until the system runs out of memory and becomes fully unresponsive.
The remote access client seems to work fine with the windows 10 machines I have tested.
Also should note that I can remote into this M1 Mac no problems, until the memory is completely used (about a 20min time period).
The simple help 5.3 server is also installed on this same M1 machine. (Mac mini).
I have created a support ticket, but wondering if anyone else is running M1 access clients with no issues?
I briefly installed it the other day, but didn’t leave it on my mac long enough to find out. I’ll try again. Does it eat up memory even when you’re not doing a remote access to the machine?
If the Remote Access app is open, it does not eat memory. However once you start the service, and it says running, then a “GenericUpdaterLaunch” Process starts and consumes approx. 50mb of memory. This process keeps repeating itself with a new process, each time taking another 50ish mb.
I even installed on a separate M1, same setup as my server running Simple-Help, and it does the exact same thing.
This process will keep creating new processes until the service is Stopped. (Dosn’t matter if the Remote access app is just open or not. Has to be Running).
And it does it when not remoted into the computer.
Note: Support just replied to my case, and said they plan on having a fix out today. Will update on how that goes.
I hope we get a new version soon… nearly two weeks now.
Check for updates, it was released today.
2 Likes
Spooky timing - will check it out ASAP. Had another weird quirk last night - was unable to connect to a client laptop, just a black screen with cursor. This client also has RemotePC on there for their own use and I was able to connect that way. Re-installed SH client to no avail. It was appearing in the console and monitor was showing the screen.
20211109-130212 AKA 5.3.1 helps a lot on the macOS front … Apple Silicone especially. The Remote Access no-longer installs Intel binaries on M1 systems. So Yay!
BUT … macOS clients absolutely do not connect when they’re at the loginwindow. It seems like they should work as the LaunchAgent does have a “LoginWindow” “LimitLoadToSessionType” login … wait a minute BRB …
(I ran off to test a theory here … I was hopeful I could make it work. Alas, no. But I do think I found the root cause … 
)
5.3.2 released - FYI
1 Like
Have you had chance to work with either of the 5.3.1 or .2 releases?
5.3.1 seems to be good. I haven’t installed .2 yet as we are not affected by the 4 bugs it claims to fix.
So, I took a deeper dive into the macOS issues in 5.3.(0-2). The main thing I’m seeing at the login window is that the lock file for the LoginWindow instance conflicts with the lock file for the new service instance. They both seem to want to use “/Library/Application Support/JWrapper-Remote Access/JWAppsSharedConfig/sgport-root” and “/Library/Application Support/JWrapper-Remote Access/JWAppsSharedConfig/sgport-root.lock”.
Since both the service and the “Remote Access Launcher” and the service run as root at the LoginWindow, the Launcher fails to get a port lock and consequently, no access at the login window.
I’d hoped the issue was a bit less fundamental and could have been solved by splitting the LaunchAgent into a User (LimitLoadToSessionType:Aqua) and Root (LimitLoadToSessionType:Loginwindow) and passing a different set of arguments to Root (LimitLoadToSessionType:Loginwindow). But as it stands, calling Remote Access Service.app with a LoginWindow LaunchAgent will fail.
I could be wrong here and missing something else, but I’ve let support know and hopefully we’ll see a change in behavior. Perhaps something as simple as a different lock-file name for “Remote Access Launcher” vs “Remote Access Service”.
@Peter_K_Knowles 5.3.1 fixes many of the issues with SH on Apple Silicon. Haven’t dove in past the macOS issues.
Not yet… was too busy last night.
Also fixed in v5.3.2