Get started with the macOS client

Applies To: Windows 10, Windows 8.1, Windows Server 2012 R2, Windows Server 2016

You can use the Remote Desktop client for Mac to work with Windows apps, resources, and desktops from your Mac computer. Use the following information to get started — and check out the FAQ if you have questions.

• Curious about the new releases for the macOS client? Check out What’s new for Remote Desktop on Mac?
• The Mac client runs on computers running macOS 10.10 and newer.
• The information in this article applies primarily to the full version of the Mac client — the version available in the Mac AppStore. Test-drive new features by downloading our preview app here: beta client release notes.

Get the Remote Desktop client

Follow these steps to get started with Remote Desktop on your Mac:

1. Download the Microsoft Remote Desktop client from the Mac App Store.
2. Set up your PC to accept remote connections. (If you skip this step, you can’t connect to your PC.)
3. Add a Remote Desktop connection or a remote resource. You use a connection to connect directly to a Windows PC and a remote resource to use a RemoteApp program, session-based desktop, or a virtual desktop published on-premises using RemoteApp and Desktop Connections. This feature is typically available in corporate environments.

What about the Mac beta client?

We’re testing new features on our preview channel on AppCenter. Want to check it out? Go to Microsoft Remote Desktop for Mac and select Download. You don’t need to create an account or sign into AppCenter to download the beta client.

If you already have the client, you can check for updates to ensure you have the latest version. In the beta client, select Microsoft Remote Desktop Beta at the top, and then select Check for updates.

Add a workspace

Subscribe to the feed your admin gave you to get the list of managed resources available to you on your macOS device.

To subscribe to a feed:

1. Select Add feed on the main page to connect to the service and retrieve your resources.
2. Enter the feed URL. This can be a URL or email address:
   • This URL is usually a Windows Virtual Desktop URL. Which one you use depends on which version of Windows Virtual Desktop you’re using.
     • For Windows Virtual Desktop (classic), use https://rdweb.wvd.microsoft.com/api/feeddiscovery/webfeeddiscovery.aspx .
     • For Windows Virtual Desktop, use https://rdweb.wvd.microsoft.com/api/arm/feeddiscovery .
   • To use email, enter your email address. This tells the client to search for a URL associated with your email address if your admin configured the server that way.
3. Select Subscribe.
4. Sign in with your user account when prompted.

After you’ve signed in, you should see a list of available resources.

Once you’ve subscribed to a feed, the feed’s content will update automatically on a regular basis. Resources may be added, changed, or removed based on changes made by your administrator.

Export and import connections

You can export a remote desktop connection definition and use it on a different device. Remote desktops are saved in separate RDP files.

To export an RDP file:

1. In the Connection Center, right-click the remote desktop.
2. Select Export.
3. Browse to the location where you want to save the remote desktop RDP file.
4. Select OK.

To import an RDP file:

1. In the menu bar, select File >Import.
2. Browse to the RDP file.
3. Select Open.

Add a remote resource

Remote resources are RemoteApp programs, session-based desktops, and virtual desktops published using RemoteApp and Desktop Connections.

• The URL displays the link to the RD Web Access server that gives you access to RemoteApp and Desktop Connections.
• The configured RemoteApp and Desktop Connections are listed.

To add a remote resource:

1. In the Connection Center select +, and then select Add Remote Resources.
2. Enter information for the remote resource:
   • Feed URL — The URL of the RD Web Access server. You can also enter your corporate email account in this field – this tells the client to search for the RD Web Access Server associated with your email address.
   • User name — The user name to use for the RD Web Access server you are connecting to.
   • Password — The password to use for the RD Web Access server you are connecting to.
3. Select Save.

The remote resources will be displayed in the Connection Center.

Connect to an RD Gateway to access internal assets

A Remote Desktop Gateway (RD Gateway) lets you connect to a remote computer on a corporate network from anywhere on the Internet. You can create and manage your gateways in the preferences of the app or while setting up a new desktop connection.

To set up a new gateway in preferences:

1. In the Connection Center, select Preferences > Gateways.
2. Select the + button at the bottom of the table Enter the following information:
   • Server name – The name of the computer you want to use as a gateway. This can be a Windows computer name, an Internet domain name, or an IP address. You can also add port information to the server name (for example: RDGateway:443 or 10.0.0.1:443).
   • User name — The user name and password to be used for the Remote Desktop gateway you are connecting to. You can also select Use connection credentials to use the same user name and password as those used for the remote desktop connection.

Manage your user accounts

When you connect to a desktop or remote resources, you can save the user accounts to select from again. You can manage your user accounts by using the Remote Desktop client.

To create a new user account:

1. In the Connection Center, select Settings >Accounts.
2. Select Add User Account.
3. Enter the following information:
   • User Name — The name of the user to save for use with a remote connection. You can enter the user name in any of the following formats: user_name, domain\user_name, or user_name@domain.com.
   • Password — The password for the user you specified. Every user account that you want to save to use for remote connections needs to have a password associated with it.
   • Friendly Name — If you are using the same user account with different passwords, set a friendly name to distinguish those user accounts.
4. Select Save, then select Settings.

Customize your display resolution

You can specify the display resolution for the remote desktop session.

1. In the Connection Center, select Preferences.
2. Select Resolution.
3. Select +.
4. Enter a resolution height and width, and then select OK.

To delete the resolution, select it, and then select —.

Displays have separate spaces

If you’re running Mac OS X 10.9 and have disabled Displays have separate spaces in Mavericks (System Preferences > Mission Control), you need to configure this setting in the Remote Desktop client using the same option.

Drive redirection for remote resources

Drive redirection is supported for remote resources, so that you can save files created with a remote application locally to your Mac. The redirected folder is always your home directory displayed as a network drive in the remote session.

In order to use this feature, the administrator needs to set the appropriate settings on the server.

Use a keyboard in a remote session

Mac keyboard layouts differ from the Windows keyboard layouts.

• The Command key on the Mac keyboard equals the Windows key.
• To perform actions that use the Command button on the Mac, you will need to use the control button in Windows (for example Copy = Ctrl+C).
• The function keys can be activated in the session by pressing additionally the FN key (for example, FN+F1).
• The Alt key to the right of the space bar on the Mac keyboard equals the Alt Gr/right Alt key in Windows.

By default, the remote session will use the same keyboard locale as the OS you’re running the client on. (If your Mac is running an en-us OS, that will be used for the remote sessions as well.) If the OS keyboard locale is not used, check the keyboard setting on the remote PC and change it manually. See the Remote Desktop Client FAQ for more information about keyboards and locales.

Support for Remote Desktop gateway pluggable authentication and authorization

Windows Server 2012 R2 introduced support for a new authentication method, Remote Desktop Gateway pluggable authentication and authorization, which provides more flexibility for custom authentication routines. You can now try this authentication model with the Mac client.

Custom authentication and authorization models before Windows 8.1 aren’t supported, although the article above discusses them.

To learn more about this feature, check out https://aka.ms/paa-sample.

Questions and comments are always welcome. However, please do NOT post a request for troubleshooting help by using the comment feature at the end of this article. Instead, go to the Remote Desktop client forum and start a new thread. Have a feature suggestion? Tell us in the client user voice forum.

Web Dev — Windows(Native/WSL), Mac-OSX or Linux?

Recently at Auquan, I had to make a choice between Windows, OSX and Linux operating systems. It took me a few weeks to try out all the operating systems and and there were quite a few factors that went into the final decision. In this article, I will break down my experiences, the decision making process and how we finally arrived at Windows(WSL) as the operating system of choice.

Context

Auquan is currently a team of 5 engineers and the number is expected to grow to 10+. We have a MERN(Mongo-Express-React-Node) stack and so far as a seed stage startup we were able to get away with everyone working on their personal laptops. However, it was becoming clear that we need to get our engineers work machines so that the team can have a standard dev environment. Our current state was: 2 of us were on OSX, 1 on Windows(native) and 2 on Linux. So started the long debate of which OS should we go with.

How To Decide?

First things first, I decided to give each one a fair shot. I was actively working in OSX and I had a native windows environment as well that I had used on and off over the past year. For a linux environment I fired up an AWS machine as it would serve well for purposes of evaluating. It was around this time that I remembered something like WSL exists and had enjoyed quite the hype when it first arrived. For the uninitiated, WSL is Windows Subsystem For Linux and it lets you have bash support without having to install linux as a separate partition. I added WSL to the mix of contenders and now we had 4 environments to evaluate. Following are the factors we were considering:

Ease of Setup

Before you can start using an environment you have to set it up so it is important the setup is easy and smooth. For each of the factors I will talk about my experience.

Windows(Native): I did the setup through installers and it was fairly simple to get the environment up and running. I did not install a local version of MongoDB so I cannot speak to simplicity of that.

Mac-OSX/Linux: Absolutely simple once you have xcode/brew setup. Just run a bunch of commands in terminal, clone your repository and you are good to go.

WSL: Getting WSL setup is the added cost here, but you can pick up any guide and you will be set up in

30 mins 25 of which will be the download time, i.e. its super simple to set up WSL. Afterwards installing node is just like linux but setting up mongoDb required a bit more research as WSL is still very new. It took me exponentially more time than either of the other OS’s to set this configuration up but once I figured out the steps the complexity becomes same as the Windows(native) set up. I will make another post with a full rundown of how to set up a web env on WSL.

Ease of Use / Support Issues

This factor was to do with how good is the tooling around our environment. Will we need to repeatedly deal with unsupported libraries or minor issues that make the development process harder.

Windows(Native): The support framework leaves a lot to be desired. Most new things have to be installed separately and the cmd line just feels lacking. Powershell has improved upon that but for our use case it did not seem to deliver. However considering office/excel is also a part of our workflow windows had the clear edge there and the GUI exploration is just better.

Mac-OSX: Great command line and tools around it. iterm has to be the best terminal app and everything you need is a command away. The rest of the OS however did not feel as powerful as windows for our use case of exploring big data sets using GUI or general tooling.

Linux: Once again great command line and tooling. The GUI has improved over the years but compared to other 2 it is still lagging behind.

WSL: This is where WSL shone, we could get the linux command line while keeping the windows GUI. What’s there to lose? Well, possibly quite a bit. WSL is new and does not have extensive support documentation so you may find yourself on wild goose chases every once in a while. However, most of the issues I dealt with had solutions that were applicable for linux and more importantly there always WAS a solution even if it was not officially supported.

Learning Curve

If people have to switch OS’s it always comes with an added cost of learning the new OS/env. It slows you down from getting to the bits that actually matter. I am yet to meet a person who has not used a windows machine ever. Possibly the younger engineers have not but people in their 20’s have all grown up with windows and the OS is very familiar to everyone. So windows was a clear winner here over OSX or Linux.

Associated Hardware

Macs are expensive, the quality of hardware justifies some of that cost but a entry level 15 inch Macbook Pro will still cost you

$2600 with taxes. To top it the current generation Macbook keyboard is just lackluster and the touch bar is one of the worst gimmicks I have ever experienced. You can easily obtain out performing and great looking hardware from HP/Dell for sub $1500 range. And if you want absolutely beautiful looking hardware just look at HP Spectre or Dell Xps but they will run you a little more.

Final Conclusion

After working with WSL for over a month I could not find any reasons to not choose it as my environment of choice. Once I installed cmder I got close to having an iterm like experience and all my everyday commands in WSL just seemed to work. There were a couple gotchas here and there, mostly to do with how the file system operates but a quick google search always gave me answers I needed. My experience, coupled with the linux command line, windows interface and

$1500 saving on every machine we got led us to choose Windows + WSL as our environment. Next, I will be doing a detailed post on how to set up a MERN environment on WSL but in the meantime let me know your thoughts.