Interacting with devices (and drivers) via RDP session uses redirection so what shows on one PC appears on another’s display. A quick look at the Display control in Settings shows what I mean:
Notice the text in red that reads “The display settings can’t be changed from a remote session.”
In a similar vein, the Output Device under Sound → Output is labeled “Remote Audio” (and no other output options appear in that pulldown list). In general when using RDP, you have to understand that certain resources that are normally purely local — display, keyboard, mouse, audio, and so forth — get mapped from the remote host PC (the one to which another PC connects remotely) to the RDP client (the PC through which the remote connection is handled). This means that managing those resources really means working on the client side of the connection. Thus, there are things you can’t do remotely that you can do easily and directly when working at the keyboard of the remote host PC.
But Wait! There’s more…
In Devices and Printers for the Remote host on the RDP client, certain devices double up in that view. Notice, for example, the doubled and redirected entries here for Fax, Print to PDF, XPS document writer, and so forth. The remote connection “sees” RDP client local and RDP host remote devices and shows them all.
Because there’s a local copy on the RDP client as well as the Remote Host printer entries double up when remoting into another PC inside Devices & Printers. (Notice the word “redirected” appears.)
[Click image for full-sized view.]
In general, if you want to work with devices or drivers in an RDP session proceed with care. Some of this kind of thing either won’t work at all, or won’t run to completion remotely. If so, you must switch to local, direct access. Once you do that, such things usually work without issues or problems.
Annoyingly, some applications or processes won’t run, or run to completion in an RDP session
Alas, the same thing is true for some applications. Older versions of the Lenovo System Update utility, for example (prior to version 5.1), would launch in a remote session, but the application window would never fully open. Thus, it didn’t work in a remote session. As soon as the affected PC is accessed locally, however, the utility does its thing quite happily. I’ve often longed for a master list of applications “Apps that don’t work with RDP” but have never found anything like that. Such knowledge comes through trial and error. Once such an error is identified, one learns to avoid using the balky or uncooperative application in RDP thereafter.