yobyot

I can be on the same local network -- sitting next to the Mac I am attempting to connect to -- and I experience issues. In production use, I need to connect via VPN. But that's why I tested on the same network: to eliminate the possibility it's a VPN issue.

BTW, I just tried RDM Mac to connect via ARD to another Mac; it hangs. Before terminating it, I opened a screen sharing session using the Mac built-in VNC connection. Perfect.

I am trying to use RDM Windows to connect to Macs running macOS 10.12 on which Remote Management has been enabled. The option to permit VNC connections is also enabled.

The problem is ARD in RDM is unstable. It hangs RDM on the local Win10 (1703) machine; it's slow; sometimes the remote Mac hangs (which never occurs when using another Mac to to connect to the target via ARD). VNC (either connection type) is even less stable or performant.

I have two questions:

1). Are other users experiencing these issues?

2). Why even have ARD support in the product if it's going to be so error-prone?

Sigh...I only come back to RDM Mac once in a while because it's so buggy. 4.1.0.0 apparently doesn't respect certs from DigiCert...a major CA. If RDM Mac is using the keychain (as Google Chrome does on the Mac -- and it has no problems with this cert), why doesn't RDM Mac understand it?

Just an update: I've been working all day in at least five different sessions and had no problems using "on remote computer." What a relief. THANK YOU!

For the record, this is using Parallels 12 with Windows 10 1607. Who'd have thought a keyboard setting would make everything go haywire. I don't know how, if or when the VM setting changed away from "optimize for games." I was throwing bricks in the wrong place -- I assumed it was RDM under Win 10 1607 -- because after the VM was upgraded to the anniversary date, things went south. Anyway, I really appreciate the help.

Now, if only RDM Mac didn't send the Windows key to both the local and remote sessions...

Whoa! Seems _much_ better. Uppercase works; Windows key works. Let me run for a day or two like this and see if anything else is affected.

Thanks! I was going crazy.

Months have gone by -- and no real solution. Let me ask you guys: have you ever tried to manage/maintain Windows Server 2012 _without_ use of the Windows key?

if I select "on local computer" I can't use a Windows key remotely. In the Mac version, the Windows key is mapped to the Mac cmd key and when pressed, sends both a local Mac cmd key press _and_ a remote Windows key press.

Catch-22. Something happened to RDM keyboard handling and it's driving me crazy.

What can I do about this?

Changing the local for the Windows key pretty much makes RDM useless. And the Mac version is worse -- hitting the Windows key (if it's enabled in the session settings) sends it to both the local and remote session.

RDM has become a mess for users like me who use the keyboard. I wish you guys would fix this quickly.

Yes, changing keyboard to local produces the correct case -- but it's not the behavior I want nor is it the way it "used to be". I'd like the Windows key CTRL-TAB and the like sent to the remote session andbe able to access "un-CTRL'ed" keys on the US English number digit keys.

In short, something changed -- and I don't want to have to re-train my muscle memory.

Is there any response to this issue? It's extremely frustrating to not be able to, for example, input open parentheses, just the character '9'.

FWIW, the keyboard in RDM Windows running in a Windows 7 VM under Parallels works just fine. I think that narrows the issue to the specific release (1607) of Windows 10.

No luck with this either.

But it brings up one of my continuing frustrations with RDM: the UI makes no sense. An example: several releases ago "delete entry" moved from a context menu of its own to being buried inside of "edit entry" context selection (shades of the "start" button to shutdown Windows). Sure, you can set it back with some random setting splashed somewhere in the options, but that only makes it worse.

RDM is full of strange UIs buried here and there. This dialog which, in nearly two years of use I've never had to use, is a great example. You can reset the default but you must click through each shortcut type and drop down multiple entries in a scrollable (but not resizable!) pane.

Good thing I never saw or used these dialogs when I was evaluating the product. I'd have run screaming back to MSFT's RDP client.

There's no difference between RemoteDesktopManager64.exe and RemoteDesktopManager.exe with respect to the use-shift-key-once-per-boot issue on my machine.

After update to the Windows Anniversary build, RDM running in a Parallels virtual machine "loses" the state of the shift key on a US English keyboard. This happens on the production version RDM, which I believe was 11.6.1 and the latest beta (11.6.6).

I tried numerous attempts to fix this issue:

=> I removed and re-added the US QWERTY profile to Windows

=> Removed and reinstalled the hypervisor's virtualization drivers (Parallels Tools)

=> Tested a variety of other applications in the Windows VM, none of which have this problem.

A screenshot is attached. As you can see, if I start a newly opened session and enter a series of dollar signs, all is well until I stop, released the shift key and then attempt to enter more dollar signs. There after, until reboot of the Windows VM in which RDM is running, all shifted characters are unavailable.

Having just one use of the shift key per Windows boot makes RDM unusable (sigh).

Wait...am I in a beta program of some kind for paying customers?

How about you test RDM Mac before you release it?

I'm astonished that you think this is the third version, fifth release, fourth maintenance release of a "product". Frankly, you should be calling this an extended beta. And it's no more stable than the betas of the product I did test, if memory serves, over 18 months ago. Basic stuff like not sending the Cmd key to the RDP session when it doesn't have the focus -- a mega inconvenience -- still don't work (or at least they didn't the last time this mess was able to start an RDP session).

Sorry, but I don't have time to twiddle this setting and that setting. The product, at this point, should work reliably. At the very least it should be able to open an RDP session.

3.5.4 starts up just fine. One small problem: it doesn't actually work. I deleted all entries and reloaded them. I also deleted the Preferences folder and started fresh.

What a disaster RDM Mac is.

https://www.yobyot.com/wp-content/uploads/2016/06/2016-06-15_20-52-15.png

As you can see in the screenshot below, RDM is driving my i7 MacBook Pro at 100% of CPU. It also takes nearly a minute to launch.

I've removed and reinstalled it.

When is RDM Mac going to stabilize? It's got so many problems -- every time I come back to it from the Windows version, there's another "gotcha". From the keyboard issues to performance, RDM Mac still feels unfinished.

https://www.yobyot.com/wp-content/uploads/2016/06/2016-06-15_18-37-24.png

I get it -- but that's about as natural as pigs flying. You should experiment with Parallels -- it manages Cmd-c/v/y/x perfectly. Works in OS X, works in Windows and doesn't stupidly send the keystrokes to the Windows vm unless it has the focus.

Only an engineer could suggest that it's acceptable to NOT have the Windows clipboard keyboard shortcuts working so that Mac users could "keep their habits."

You suggestion means I a user cannot use ANY keyboard shortcuts to paste something into the Mac RDP session.

For a user accustomed to using the keyboard, this "workaround" (actually, a loss of functionality) renders RDM Mac almost useless.

It's been this way in RDM Mac since the beta. How can't it not have risen to the top of the to-be-implemented features list?

Thanks.

But the right way out of the second problem is to permit the Windows-X (or Cmd-X) key to be mapped to something else. For example, running RDM Windows in Parallels on a Mac, the Cmd-X/V/Y keys are mapped to (Windows) Ctrl-X/V/Y and one can map the "naked" OS X Cmd key to something else (in my case, I use Option-cmd). This allows any Windows + other key combination.

Your suggest to not map the clipboard management keys is like shooting oneself in the foot. It gives one a good excuse for not being able to walk but hurts like hell. Why should an RDM Mac user not either either (broken) Windows key passthrough OR Windows clipboard shortcuts. BOTH are absolutely necessary to effectively use the keyboard with Windows.

For experienced admins, using the mouse slows you down.

In RDM Mac, if the keyboard is set to passthrough the Windows key, when a session has the focus, if a Mac Cmd-key combo, such as Cmd-Space, is entered, RDM also passes the Cmd key through. This is astonishingly annoying and has been this way for many releases. As you can see in the screenshot below, using the Mac keyboard to bring up Spotlight search while a session has the focus also passes (at least) the Cmd key to the session.

Plus, Windows-X (what you'd expect to be Cmd-X) isn't passed at all.

This really needs to be fixed or at least a passable workaround.

Thanks.

On RDM Mac 3.5.1.0 when using RDP sessions through a gateway, I randomly get "peer connection lost" messages followed by a reconnection.

Export the connections, import them to RDM Windows 11.1.0.0 running in a vm on the same computer, same network, same adapter (a "shared" adapter managed by the vm hypervisor) and the connections run perfectly -- you can leave them up for hours without a blip.

I've seen this problem off and on in RDM Mac since the beta. How can we get it stamped out?

No, it's not enabled because it would make no sense. None of the private addresses are "local" (to the client). They are only local to the Amazon VPC.

In both the Mac and the Windows apps, if an internal DNS name is used as the destination session, the RD gateway machine resolves the DNS. The iOS app (apparently) does not resolve destination host names at the gateway, causing connection failures.

We run in AWS and use both a private domain (.aws) and public domain (.com) via Route 53.

Consider the following:

RD Gateway machine DNS name 'rdg.public.com' resolves to a public IP address

Destination machine public DNS 'destination.internal.ourdomain.com' resolves to a private IP address (10.0.0.0/16)

Destination machine private DNS 'destination.ourdomain.aws' resolves to the same private IP address as 'destination.internal.ourdomain.com'

A connection set up to use the RD gateway that specifies the destination publicly-accessible DNS entry with the non-routable address connects. But using the internal, private DNS entry (which resolves to the same address when queried at the RD gateway) fails.

Thanks.

Hello,

I don't know if this is what you are looking for, but could you try Current work area size with Auto Scale Resolution

Best regards,

Thanks, but this still isn't what I want. As you can see in the attached screenshot, this combination of session settings produces a slightly larger than current resolution session. That means more clicking and adjusting.

I don't know why RDM cannot seem to produce a session that is both undocked AND maximized (that is, with the title bar and window controls showing). Also, it would be nice if the documentation on these settings and the results were complete and offered examples.

Undocked.

In my experiments, external mode looked like it simply runs the MSFT RDP client.