I have a logitech MX518 that has nice forward and back buttons built onto the mouse directly. They work great locally. However anytime over remote desktop these buttons do nothing. This happens both with the Windows Remote Desktop and the Windows Store / Windows Metro Remote Desktop.

The computer I'm remoting to at work has the same mouse, which when at my desk physically the forward and back buttons work fine.

Is there any way to get remote desktop to respect these commands properly?

6 Answers 6


I had a similar problem. I use Microsoft Remote Desktop on my Macbook Pro to connect to a Windows 10 PC. My mouse is an MX Master 3 and it's configured using the Logitech Logi Options software. as @musictomyear noted in his answer the forward/back commands are not transmitted via the Remote Desktop protocol if the driver is not HID-based.

I then tried using Logi Options to map the mouse buttons on the MacOS side to send equivalent Windows key combinations like Alt-RightArrow when using Remote Desktop. This also did not work because Logi Options seems to be generating Control + RightArrow not as separate simultaneous key presses, but as a single key press with a control modifier. The Remote Desktop protocol will not send these special characters either, and hence they don't make it over to the Windows side when connected via RDP.

The workaround I found was

  1. Configure Logi Options map the forward/back buttons to a "standard" keyboard key that I don't need. In my case, I mapped the forward/back buttons to F8 and F9, but set it up so they are only mapped when the active app is Microsoft Remote Desktop so that I can continue to use them normally on the MacOS side.
  2. Install Windows Power Toys from Microsoft. In the Keyboard Manager section of Power Toys, I configured a rule to map F8 and F9 to Alt-Right and Alt-Left, respectively.

Now when I use the forward/back buttons on my Mac-side mouse in Remote Desktop, they work as expected on the remote Windows machine.

It's not ideal, but I don't really use those function keys in my day-to-day work (software development), so it's good enough for me.

Hopefully this helps someone.


This isn't the exact same problem, but it's similar enough that I'm explaining my use case and solution in the hopes it will help somebody else. I've got a Logitech Performance MX (which doesn't let you change keyboard shortcuts for specific apps) with Back and Forward buttons which work great on OSX, but not so much when used through Windows RDP.

Back and Forward on OSX is + and + respectively, which is the equivalent of Windows Key+ and Windows Key+ over a remote desktop connection. Windows expects Alt to be used instead of Windows Key and so instead of Browsing back/forward, it will attempt to pin the browser window to one side of the screen or another. Not what we want.

I tried all sorts of work arounds, including changing the keystrokes that got sent with the forward and back buttons and then redefining the Forward/Back for Chrome on OSX, but everything caused problems.

@LordJair's suggestion got me thinking though, and so I installed AutoHotKey on my Windows machine. It's important not to do this on the host machine using an OSX equivalent because the RDP client will be what's interpreting the keystrokes and things get messy otherwise.

I then created the following AutoHotKey script and now everything works flawlessly through RDP and also on OSX:


For what it's worth, I currently use AutoHotKey to do this. Just like with other hotkeys, when the RDP window is active, I cause the XButton2, for example, to Send {XButton2}. Of course, if you're not already using AHK, then it might be too much trouble to get a script together. For whatever reason, it works.

I have a Logitech M510 mouse and luvz it to pieces!


From here: https://community.wyse.com//forum/showthread.php?2398-Additional-buttons-on-mouse-don-t-work

Those buttons are not HID based. They require a driver. Usually that driver is built into Windows, so you don't see it install. Regular RDP cannot tunnel USB devices that are not HID. HID devices, like mouse and keyboard, are directed into the remote session, but the extra buttons aren't. You will need a USB tunnel for that.

So, a driver will be part of your solution, but a USB tunnel will be necessary as well because the Remote Desktop protocol doesn't even send the necessary information the driver will need.

A quick Google search returned this promising result: http://www.usb-over-network.com/

However, I have not used this solution and so cannot speak to its efficacy.

  • Stupid as this may be, i guess this is reality, as unfortunate as it may be. Commented Jan 3, 2014 at 16:10
  • Yea, it would be nice if RDP/VNC supported non-HID inputs, even just as an option. But it would probably take more resources and would require additional drivers to be loaded on the host machine. Commented Jan 3, 2014 at 16:14
  • As mentioned, these drivers already exist on the host. or do you mean additional drivers to translate known action X over transport back to known action X? Wouldn't this be similar to how printers are shared over RDC anyway (which personally i think is wrong for it do so)? Commented Jan 3, 2014 at 17:22
  • Have you seen the price of USB-over-Network? They must be taking some very potent medication over at FabulaTech.
    – Ken Sharp
    Commented Jul 30, 2018 at 0:05

Just use "Keystroke assignment" instead of the default options from the menu.

There are some key assignments that do not work for me when I "remote desktop".

I was able to get my mouse button configuration to work by using my own commands instead of the ones suggested by the "Logitech Options" program.

For example, to configure a "next track" button:

  1. Go to Logitech Options
  2. Select the button that you want to assign the command
  3. Instead of picking the "Next track" from the dropdown list, select "Keystroke assignment"
  4. A menu will show up where you can type in your Keystroke.
  5. Use your keyboard to hit the "next track" key.
  6. Done!
  • 2
    Can you provide a bit more detail? … … … … … … … … … … … … … … … Please do not respond in comments; edit your answer to make it clearer and more complete. Commented Feb 19, 2021 at 19:28
  • 1
    this worked for me, thank you Commented Mar 7, 2021 at 19:00
  • I use the normal assignment (Copy/Paste) in "Options" and it worked immediately. I also tried this apporach (explicit keystrokes) in "SetPoint" but it didn't help. Commented Jan 7, 2022 at 2:53

My situation:
Win10 (21H2) with mstsc.exe (10.0.19041.1266)
Logitech mice:

  • RX250 (Logitech SetPoint)
  • M535 (Logitech Options)

Tilt Click (mousewheel click)
Left: Paste (Ctrl+V)
Right: Copy (Ctrl+C)

With the M535 configured via Options, it worked immediately.
The RX250 did not work with SetPoint, I tried a lot of "fixes" but nothing helped.
In the end, I installed X-Mouse Button Control and used it to configure the keyboard strokes. It works together with SetPoint, if I set the extra buttons to do nothing, but I uninstalled SetPoint in the end.
Options is still installed.

It works flawlessly with RDP now (and with apps that need admin rights).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .