Get started with the Windows Desktop client

Applies to: Windows 10, Windows 10 IoT Enterprise, and Windows 7

You can use the Remote Desktop client for Windows Desktop to access Windows apps and desktops remotely from a different Windows device.

• This documentation is not for the Remote Desktop Connection (MSTSC) client that ships with Windows. It’s for the new Remote Desktop (MSRDC) client.
• This client currently only supports accessing remote apps and desktops from Windows Virtual Desktop.
• Curious about the new releases for the Windows Desktop client? Check out What’s new in the Windows Desktop client

Install the client

Choose the client that matches the version of Windows. The new Remote Desktop client (MSRDC) supports Windows 10, Windows 10 IoT Enterprise, and Windows 7 client devices.

You can install the client for the current user, which doesn’t require admin rights, or your admin can install and configure the client so that all users on the device can access it.

Once you’ve installed the client, you can launch it from the Start menu by searching for Remote Desktop.

Update the client

You’ll be notified whenever a new version of the client is available as long as your admin hasn’t disabled notifications. The notification will appear in either the Connection Center or the Windows Action Center. To update your client, just select the notification.

You can also manually search for new updates for the client:

1. From the Connection Center, tap the overflow menu (. ) on the command bar at the top of the client.
2. Select About from the drop-down menu.
3. The client automatically searches for updates.
4. If there’s an update available, tap Install update to update the client.

Workspaces

Get the list of managed resources you can access, such as apps and desktops, by subscribing to the Workspace your admin provided you. When you subscribe, the resources become available on your local PC. The Windows Desktop client currently supports resources published from Windows Virtual Desktop.

Subscribe to a Workspace

There are two ways you can subscribe to a Workspace. The client can try to discover the resources available to you from your work or school account or you can directly specify the URL where your resources are for cases where the client is unable to find them. Once you’ve subscribed to a Workspace, you can launch resources with one of the following methods:

• Go to the Connection Center and double-click a resource to launch it.
• You can also go to the Start menu and look for a folder with the Workspace name or enter the resource name in the search bar.

Subscribe with a user account

1. From the main page of the client, tap Subscribe.
2. Sign in with your user account when prompted.
3. The resources will appear in the Connection Center grouped by Workspace.

Subscribe with URL

1. From the main page of the client, tap Subscribe with URL.
2. Enter the Workspace URL or your email address:
   • If you use the Workspace URL, use the one your admin gave you. If accessing resources from Windows Virtual Desktop, you can use one of the following URLs:
     • Windows Virtual Desktop (classic): https://rdweb.wvd.microsoft.com/api/feeddiscovery/webfeeddiscovery.aspx
     • Windows Virtual Desktop: 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 has setup email discovery.
3. Tap Next.
4. Sign in with your user account when prompted.
5. The resources will appear in the Connection Center grouped by Workspace.

Workspace details

After subscribing, you can view additional information about a Workspace on the Details panel:

• The name of the Workspace
• The URL and username used to subscribe
• The number of apps and desktops
• The date/time of the last refresh
• The status of the last refresh

Accessing the Details panel:

1. From the Connection Center, tap the overflow menu (. ) next to the Workspace.
2. Select Details from the drop-down menu.
3. The Details panel appears on the right side of the client.

After you’ve subscribed, the Workspace will refresh automatically on a regular basis. Resources may be added, changed, or removed based on changes made by your admin.

You can also manually look for updates to the resources when needed by selecting Refresh from the Details panel.

Refreshing a Workspace

You can manually refresh a Workspace by selecting Refresh from the overflow menu (. ) next to the Workspace.

Unsubscribe from a Workspace

This section will teach you how to unsubscribe from a Workspace. You can unsubscribe to either subscribe again with a different account or remove your resources from the system.

1. From the Connection Center, tap the overflow menu (. ) next to the Workspace.
2. Select Unsubscribe from the drop-down menu.
3. Review the dialog box and select Continue.

Managed desktops

Workspaces can contain multiple managed resources, including desktops. When accessing a managed desktop, you have access to all the apps installed by your admin.

Desktop settings

You can configure some of the settings for desktop resources to ensure the experience meets your needs. To access the list of available settings right-click on the desktop resource and select Settings.

The client will use the settings configured by your admin unless you turn off the Use default settings option. Doing so allows you to configure the following options:

• Display configuration selects which displays to use for the desktop session and impacts which additional settings are available.
  • All displays ensures the session always uses all your local displays even when some of them are added or removed later.
  • Single display ensures the session always uses a single display and allows you to configure its properties.
  • Select displays allows you to choose which displays to use for the session and provides an option to dynamically change the list of displays during the session.
• Select the displays to use for the session specifies which local displays to use for the session. All selected displays must be adjacent to each other. This setting is only available in Select display mode.
• Maximize to current displays determines which displays the sessions will use when going full screen. When enabled, the session goes full screen on the displays touched by the session window. This allows you to change displays during the session. When disabled, the session goes full screen on the same displays it was on the last time it was full screen. This setting is only available in Select display mode and is disabled otherwise.
• Single display when windowed determines which displays are available in the session when exiting full screen. When enabled, the session switches to a single display in windowed mode. When disabled, the session retains the same displays in windowed mode as in full screen. This setting is only available in All displays and Select display modes and is disabled otherwise.
• Start in full screen determines whether the session will launch in full-screen or windowed mode. This setting is only available in Single display mode and is enabled otherwise.
• Fit session to window determines how the session is displayed when the resolution of the remote desktop differs from the size of the local window. When enabled, the session content will be resized to fit inside the window while preserving the aspect ratio of the session. When disabled, scrollbars or black areas will be shown when the resolution and window size don’t match. This setting is available in all modes.
• Update the resolution on resize makes the remote desktop resolution automatically update when you resize the session in windowed mode. When disabled, the session always remains at whichever resolution you specify in Resolution. This setting is only available in Single display mode and is enabled otherwise.
• Resolution lets you specify the resolution of the remote desktop. The session will retain this resolution for its entire duration. This setting is only available in Single display mode and when Update the resolution on resize is disabled.
• Change the size of the text and apps specifies the size of the content of the session. This setting only applies when connecting to Windows 8.1 and later or Windows Server 2012 R2 and later. This setting is only available in Single display mode and when Update the resolution on resize is disabled.

Give us feedback

Have a feature suggestion or want to report a problem? Tell us with the Feedback Hub.

You can also give us feedback by selecting the button that looks like a smiley face emoticon in the client app, as shown in the following image:

To best help you, we need you to give us as detailed information about the issue as possible. For example, you can include screenshots or a recording of the actions you took leading up to the issue. For more tips about how to provide helpful feedback, see Feedback.

Access client logs

You might need the client logs when investigating a problem.

To retrieve the client logs:

1. Ensure no sessions are active and the client process isn’t running in the background by right-clicking on the Remote Desktop icon in the system tray and selecting Disconnect all sessions.
2. Open File Explorer.
3. Navigate to the %temp%\DiagOutputDir\RdClientAutoTrace folder.

—>

Client server windows applications

This chapter introduces some of the basic principles of client/server applications and explains their advantages over the more traditional monolithic architecture. It also suggests how to divide your application into modules that make the most of client/server architecture, and outlines the platforms on which NetExpress applications can be deployed.

Despite a rapid increase in the deployment of client/server applications, there is still a certain amount of mystique surrounding the term ‘client/server’, especially as the same term is often used to describe a number of different concepts.

In principle, a client/server application consists of a client program that consumes services provided by a server program. The client requests services from the server by calling functions in the server application. In a distributed computing environment, where the client program and the server program execute on different machines and possibly even on different platforms, the client and server communicate through a communications layer that is often called middleware .

Figure 2-1: Basic client/server architecture

Although applications that are running on different machines obviously require those machines to be physically connected in some way — usually by a network (LAN, WAN or Internet) — it is important to distinguish between the network architecture and the client/server application architecture. The client application might run on a network client or a network server. The client and server applications might run on the same machine, which could be a network client or a network server, or neither! A client/server application is described as such solely because of its own architecture, without reference to how it is deployed on a network. For example, the X system used for graphical front-ends on many UNIX systems is a client/server application. However, the server part of the application often runs on the network client machine, with the client part of the application running on the network server! The easiest way to remember which is the client part of an application is to remember that the client is always the requestor of services.

The following are typical features of a client/server application:

A client program can request services from multiple server programs

A client program does not need to be aware of the actual subprograms that provide a service

Multiple subprograms can work together to provide the service

Multiple client programs can request services from a single server program

A server program can provide multiple services

Typically, the server program runs on a machine that is remote from the machine running the client program

COBOL applications request services by using the CALL statement. The request for a service is actually a call to a function implemented in a procedure. Although CALL statements are usually associated with local functions — that is, procedures that execute on the same machine as the calling program — they can equally be associated with remote functions that execute on a different machine. When a CALL is used in this way, it is often referred to as a remote procedure call , or RPC. A key requirement for the rapid development of client/server applications is that remote procedure calls should be handled independently of the network protocol in use; this enables you to concentrate on coding your application rather than handling the underlying network. NetExpress is supplied with a simple RPC mechanism called client/server binding, which provides a straightforward network-independent communications layer between client and server programs.

Most of the benefits of using client/server architecture for enterprise applications relate to flexibility of deployment and relative ease of maintenance. For example, using client/server architecture you can typically:

• Re-use existing legacy code for the business logic
• Run each functional layer of the application on the platform most suited to the task
• Distribute the processing and network loads
• Quickly and easily change business logic procedures without changing the client program or user interface
• Provide simple and convenient delivery of the application and any updates to end-users
• Provide alternative client user interfaces to the same server-side program
• Use development tools that are designed to work together

To maximize the potential value of using a client/server architecture, you should adhere to some basic design guidelines. These are outlined below.

To gain the most benefit from using a client/server architecture for new applications or as a conversion exercise when updating existing applications, it is essential to logically (and often, physically) separate the different layers of functionality in the application so that they are not indiscriminately mixed together. A typical approach is to split the logical functions of the application into three:

• User interface logic (screen handling)
• Business logic (data processing)
• Data access logic (file or database handling)

Conceptually, each of these three areas of functionality — or layers — are handled by separate programs. The user interface logic is always handled by the client application. If the client application handles only the user interface logic, it is called a thin client . Sometimes some, or even all, of the business logic is also handled by the client application; this is called a thick client .

When you create a client/server application, it makes a lot of sense to apply this conceptual division of functionality to the actual program code, so that you create physically separate programs for handling each of the three layers. In a distributed computing environment, each of these programs might run on different machines — but they would work equally well if they were all running on the same machine.

A Web application is the ultimate thin client. The user interface is handled entirely by the user’s Web browser. Although the definition of the interface is provided as an HTML form which resides on the Web server, it is downloaded temporarily under the control of the Web browser.

NetExpress is designed to enable you to create 32-bit Web-based and network-based client/server applications that can be deployed on the following platforms:

• Operating systems supported directly:
  • Windows NT V4.0 with Service Pack 3 or Service Pack 4
  • Windows 98
  • Windows 95

  
  
• Operating systems supported in conjunction with Object COBOL for UNIX V4.1:
  • Most SVR4-based UNIX systems, including:
    • SCO
    • AIX

  (Applications created with Internet Application Wizard are not suitable for deploying on UNIX)

• Network protocols supported:
  • TCP/IP
  • Microsoft Network
  • IPX (Novell NetWare)
  • NetBEUI

  
  

We have tested the following platforms and believe them to be generally compatible with NetExpress Web applications:

• Web servers:
  • Microsoft Information Server V4.0
  • Microsoft Personal Web Server (as supplied with FrontPage 97)
  • Netscape FastTrack Server V2.01
  • Netscape Enterprise Server
  • Apache web server (on UNIX)

  
  
• Web browsers:
  • Microsoft Internet Explorer V4.0
  • Netscape Communicator V4.01

  
  
• HTML Painters:
  • Microsoft FrontPage 97
  • NetObjects Fusion
  • Sausage Software HotDog
  • Softquad HotMetal Pro

  
  
• Middleware:
  • IONA Technologies Orbix V2.3c
  • IONA Technologies OrbixWeb V3.0
  • IBM CICS Client V2.0.04 External Call Interface (ECI)
  • IBM Transaction Server
  • Microsoft Transaction Server
  • Oracle Pro*Cobol V8.0 database precompiler
  • Sybase Open Client Embedded SQL/COBOL precompiler V11.0.1
  • XDB ExpressLane V2.0

  
  
• Databases:
  • Oracle V7 and V8
  • Sybase V11.0.1
  • Informix V7.20
  • Microsoft SQL Server V6.5
  • Microsoft Access V7
  • IBM DB2 V5.0

  
  
• Source code control systems:
  • INTERSOLV PVCS Version Manager V5.3 and V6.0
  • Microsoft Visual SourceSafe

As Web applications created by NetExpress conform to the relevant international, platform-independent standards, it is highly likely that they will work correctly when deployed on other TCP/IP-capable client platforms with appropriate Web browsers. However, as each application has individual requirements, we advise you to test your application thoroughly on all target systems before deployment.