According to
https://blogs.technet.microsoft.com/askperf/2012/10/30/windows-8-windows-server-2012-remote-desktop-management-server/
Welcome to Day 9 of our launch series, and the first of 4 covering RDS. In todays post, we are going to cover the “Remote Desktop Management Server” (RDMS) interface for creating and managing a Windows Server 2012 Remote Desktop environment.
What is RDMS?
In Windows Server 2008 R2, admins have had to use at least four different MMCs to manage a Remote Desktop Environment. These include the following:
- Remote Desktop Services Manager (tsadmin)
- Remote Desktop Services Configuration (tsconfig)
- Remote Desktop Connection Manager (sbmgr)
- RemoteApp Manager (remoteprograms)
In Windows Server 2012, a single interface, Remote Desktop Management Server (RDMS), replaces all above snap-ins and provides centralized management of the Remote Desktop infrastructure. RDMS is a plug-in to the new Server Manager in Windows Server 2012.
Additionally, Windows Server 2012 includes a new installation type, “Remote Desktop Services installation”. This new installation type makes deploying and managing your RDS infrastructure much simpler. Connection Broker is a critical role in an RDS infrastructure that is installed when using the new type. The RDMS service is also installed on the Connection Broker when the new method is used. The RDMS service is the engine behind the new UI and cannot be installed using the classic “Role-based or feature-based installation” type.
Important: You should use the new RDS installation method, even in the case of a single Remote Desktop Session Host. This is because RDS deployments can now only be managed through RDMS or via Windows PowerShell. Standalone RDS implementations are possible, but they must be managed exclusively using Powershell.
We will not walk you through the installation process here, but it is pretty straightforward:
- Add the servers to which you want to deploy the RDS roles to All Servers group or a new server group.
- Select that group in the navigation pane and run the Add Roles and Features Wizard.
- Choose the installation type “Remote Desktop Services installation”.
- Select “Standard Deployment” (Quick Deployment is used to quickly deploy all of the needed roles to a single server and then create a very simple collection. To have more control, we recommend using Standard Deployment).
- Choose “Virtual Machine based deployment” or ” Session-based desktop deployment”.
- The wizard will ask you which server you want each role installed to and will perform the installations and restart the servers as needed.
After installing the RD Connection Broker role and the RDMS service using the new “Remote Desktop Services installation” type of installation, the RDMS UI can be accessed from Server Manager by choosing “Remote Desktop Services” in the navigation pane.
When you select Remote Desktop Services, there are three options in the middle pane:
- Overview
- Servers
- Collections
Let’s look at all three of them one by one.
OVERVIEW:
Once the RDS Roles are installed on the Session Host servers and RD web access servers, we see the graphical description of our environment, the roles installed on each of the servers and the FQDN names of each server on the Overview page:
From this page additional servers can be added to the deployment and additional roles can be installed using the Deployment overview/Deployment Servers right-click options. The Gateway and RD Licensing options are reflecting in Green as these roles are not yet installed but can be installed by clicking the Green Plus sign.
In order to add certificates, configure licenses and RD gateway settings we can “Edit Deployment Properties”. Instead of touching every host that’s part of an RDS deployment, the RDMS server accepts a certificate and pushes it to each of the hosts for you.
SERVERS:
The “Servers” page enables us to manage all of the servers belonging to the RDS Environment:
A variety of remote management tasks can be performed including adding roles and features.
COLLECTIONS:
Collection is a logical grouping of Remote Desktop Servers that provides either session-based or virtual machine-based (VDI) deployments.
Note Each Session host that’s a member of an RDS collection is limited to only participating in one collection.
In this example we’ve named the RDS Collection “RemoteApp”. On the Collections Page we can see the number of connections, the connection states, which users have remote sessions and the servers on which the sessions are established:
If no Remote Apps are created for the collection, then on the RDWeb page users will see the icon with the name of our collection to take a full RDS session to the session host servers:
There is no separate Remote APP Manager snap-in to publish or modify remote app settings. In Server 2012 we use the “Publish RemoteApp Programs” on the Collection Page to publish the remote apps.
To modify Remote App programs, there is an “Edit Properties” option under Tasks. We can also right-click to reach this same Edit Propertiesoption. On the User Assignment screen admins can now create a folder in which the Remote Apps will be saved. Prior to Server 2012, in large environments user would see all the remote apps listed on the main RDweb Page. However, with the folder creation option, admins have the option to segregate the remote apps based on different criteria.
Here we have created two folders to differentiate between the Admin Apps (Server Manager) and User Remote Apps (Calculator).
Note After publishing Remote Apps, users no longer see the full desktop icon for RemoteApp (the name of the collection). In Server 2008, users could see the remote apps as well the “remote desktop Icon” on the RDweb page if we checked the option “Show a remote Desktop connection to the RD session host server in RD web access” in the Remote App Manager.
In order to create a full desktop session to a server that is part of a collection that has RemoteApps published from the RDweb page, there are two options.
- Use the tab “connect to remote PC”
- Publish “Remote Desktop Connection” as a remote app
Configuring load balancing weight, security, encryption levels, Client settings and session limits can all be done from the Edit Collection Properties page.
RDMS is one-stop centralized management for RDS environments and is sure to help ease the administrative overhead by simplifying both the rollout and configuration of Remote Desktop Services for everyone.
This concludes part one of what’s new in RDS. Tomorrow we take a close look at deploying Remote Desktop VDI environments!
Remote Desktop Services in Windows Server 2012, Step-by-Step Guides
According to
Remote Desktop Services in Windows Server 2012 is awesome. With highlights like huge performance improvements and an incredibly simplified deployment process, you’re going to want to see what this can do for your business and you can, for free! Microsoft has the Windows Server 2012 Release Candidate available which you can download and install today. I’ll show you how you can set up several scenarios.
- Quick and Easy, RemoteApp on a single server
- Quick and Easy, RemoteApp using three servers
- Adding a Gateway and Configuring Certificates
- Adding a Licensing Server
- Adding a Windows Server 2008 R2 RemoteApp source
- Configure a Virtual Desktop Infrastructure Pool and PVD
- Building and Maintaining VDI Personal Virtual Desktops
- Delivering RemoteApp to end users via RSS Subscription
RDCB – Remote Desktop Connection Broker. This is the “hub” of the RDS environment. It ensures that all user connections that are established to the various Session Hosts are maintained through disconnects and reconnects and play a key role in simplifying the single sign on experience | |
RDWA – Remote Desktop Web Access. A web site that simply hosts the list of available resources that can be reached through RDS. It also hosts an RSS feed that can be used in various places. | |
RDSH – Remote Desktop Session Host. The server that actually runs the user processes. This is what people sometimes refer to as a Terminal Server, although that term has officially been depreciated. When a user runs a RemoteApp or connects to a Desktop, it’s running on a Session Host. |
RDGW – Remote Desktop Gateway. Another web site that is actually used as a way of tunneling RDP traffic over HTTPS to allow users who are outside the corporate network to gain access to internal resources. I usually like to co-locate this role on the RDWA server, and I end up referring to RDGW as the “Gateway and Web server”. | |
RDVH – Remote Desktop Virtualization Host. A new role for Windows Server 2012, this is a physical server running Hyper-V and is used to deploy and manage Virtual Machines for VDI. | |
RDLI – Remote Desktop Licensing. Installing RDS will give you 120 days to try it out, but if you decide to keep it you’ll need to get licensing from Microsoft, and the license key gets installed on the RDLI server. I usually like to co-locate this role on the RDCB. |
- A Connection Broker and License Server
- A Gateway and Web Access server
- A Session Host / RemoteApp server
1- Quick and Easy, RemoteApp on a single server
RDS8 - Quick and Easy, RemoteApp on Windows Server 2012
I’ll show you how you can set up RemoteApp publishing using a single server in less time than it takes to watch an episode of your favorite drama! Honestly, you should be able to hammer this out in less than an hour if you are at all familiar with the new Windows Server Manager. It’s madness (in a good way!). There two things that you will need in place before you start your stop watch:
- RDS in Windows Server 2012 requires Active Directory, 2003 or newer.
- One server running a fresh and updated install of Windows Server 2012 joined to that domain.
Once you’ve got that, break out your stop watch. I’ll race you! From the new Server Manager, click the Manage menu and select Add Roles and Features.
One of many new features that the new Server Manager offers is the introduction of scenario-based installation. Remote Desktop Services is the only scenario installation type available, and that’s exactly what we want to do.
If you really want to see the power of Scenario-Based deployments you’ll want to set up three servers and then try the Standard Deployment method, but to get this done quickly we’ll just use the Quick Startdeployment which will put everything on one server.
The Virtual Desktop Infrastructure (VDI) scenario will be used to allow each user to have their very own virtual machine, but we want to deploy the Session Virtualization scenario which is analogous to what everyone thinks of with Terminal Services; multiple user sessions working independently on one server.
The local server you’re connected to should be added to the Selected list by default. Make sure that’s the server you are going to deploy all of the RDS roles onto and click Next.
On the Confirmation page you’ll have to check the “Restart” option as the installation of the Session Host role requires a reboot. Then click Deploy.
After the reboot, log back into the server and the Server Manager should resume to show you the status: Succeeded! Click the link at the bottom of the page to view the list of available RemoteApps.
When connecting to the RDWeb page, you’ll get a certificate warning because the quick deployment uses a self-signed certificate which can be replaced later, so click Continue to this web site for now.
You’ll also be prompted to run an Active-X Control which is the mechanism that allows the web site to launch the Remote Desktop client. You can click Allow here, but a Group Policy can be made to allow this automatically.
Once connected, you’ll see a huge list of applications that are published already. This is a result of using the Quick Start deployment, and we’re not going to want to publish all of these Apps, so let’s take care of that right away.
Return to the Server Manager and click on the new “Remote Desktop Services” page on the left, then click on Collections. “Collections” is a new term that describes a set of services that the RDS deployment offers such as a collection of RemoteApps, Desktop Sessions or Virtual Desktops.
The Quick Start deployment already created a collection for us, but we’ll want to remove it and start from scratch. Right click the QuickSessionCollection and click “Remove Collection. Then from the Tasks button, select Create Session Collection.
Enter a Collection Name, something clever like RemoteApps works well.
Now select your Session Host server and click the arrow to add it to the Selected list. There should only be the one server available here so it’s pretty straight forward.
The default group of users that are allowed to access the applications in this collection will be Domain Users. You can be more specific if you wish, but you can also be more specific on an individual application bases as you publish them later.
To keep things moving quickly, let’s skip the User Profile Disks for now. This is a very cool new feature of Windows Server 2012 (8 beta) that allows users on the session host to have their “local” data get automatically redirected to a different virtual hard drive instead of getting written to the actual session host server, but you can configure that later.Click Next then Create to finish the Collection wizard.
When it’s done, you can click Close.
Now it’s time to publish the applications you really want to give users access to. From the Remote Desktop Services page, select the new RemoteApps collection you made and then from the Tasksbutton by RemoteApp Programs, select Publish RemoteApp Programs.
You can select a program from the list or click “Add Another Program” to browse to an executable.
When you’re happy with your selection click Publish, then Close.Now refresh the RDWeb page and you’ll see only the applications that you selected.
Click on one of them to connect to the RemoteApp. This prompt is Internet Explorer warning you that the Web Site is trying to start a program on your computer. It’s using the Active-X Control to launch the local RDP client (mstsc.exe). This warning can be suppressed by Group Policy once the web site certificate is replaced, but for now just click Connect.
Once connected, the application would look just like any locally installed application, but you’ll notice a new system tray icon that show you are connected to a Remote Work Place.
And there you have it, RDS, Quick and Easy on one server in less than an hour.
Now you can install new applications and publish them to your Collection. Just like Windows 2008 R2, you can deliver these RemoteApps from RDWeb or by subscribing to the RemoteApp RSS feed. If you want to make these applications available outside of your organization, the next step will be to deploy the RD Gateway role, or if you want to go bigger, try doing a Standard Deployment to break the roles out to separate servers and add more Session Hosts, the equivalent to a RDS Farm. N’joy!
RDS8 - Standard 3-Node RemoteApp Deployment on Windows Server 2012
I’ll show you how you can set up RemoteApp publishing environment using three servers in about as much time as it takes to do it watch an episode of Dexter! As crazy as it might sound, setting up a three server environment really doesn’t take much longer than a single server deployment but it offers you some fantastic flexibility and growth options. There two things that you’ll need in place before you start your timer:
One of the great new features of the new Server Manager is that you can mange multiple servers from the one console. There is no better example of the power that this offers than in deploying and managing Remote Desktop Services. From the new Server Manager, click the Manage menu and select Add Servers. Search for your three servers that will be used for RDS and add them to the selected list by using the right arrow button. Once they’ve been added to the Server Manager, click on the Manage menu and select Add Roles and Features. In addition to being able to manage more than one server now, the new Server Manager also introduces scenario-based installation. Remote Desktop Services is the only “scenario” installation type that is available, but that’s exactly what we want to do. In order to use more than one server for RDS, we’ll do a Standard deployment. The Virtual Desktop Infrastructure (VDI) scenario will be used to allow each user to have their very own virtual machine, but we want to deploy the Session Virtualization scenario which is analogous to what everyone thinks of with Terminal Services; multiple user sessions working independently on one server. The next screen will just explain the various roles that will be deployed by using this wizard. First we’ll select the Connection Broker Then the Web Access server. Notice that you are given the option to install the RDWA on the Connection Broker server. This would allow you to do a Standard deployment with as few as two servers, but I prefer to leave the RDCB and RDWA on their own servers and later deploy the Gateway role to the same server running RDWA. And finally we’ll select the Session Host server. On the Confirmation page you’ll have to check the “Restart” option as the installation of the Session Host role requires a reboot. Then click Deploy. After the roles are deployed and the session host reboots, the Server Manager should show you the status: Succeeded! After clicking Close, you’ll see a new “Remote Desktop Services” page on the left. Select that then click on Collections. “Collections” is a new term that describes a set of services that the RDS deployment offers such as a collection of RemoteApps, Desktop Sessions or Virtual Desktops. From the Tasks button, select Create Session Collection. Enter a Collection Name, something clever like RemoteApps works well. Now select your Session Host server and click the arrow to add it to the Selected list. There should only be the one server available here so it’s pretty straight forward. The default group of users that are allowed to access the applications in this collection will be Domain Users. You can be more specific if you wish, but you can also be more specific on an individual application bases as you publish them later. To keep things moving quickly, let’s skip the User Profile Disks for now. This is a very cool new feature of Windows Server 2012 (8 beta) that allows users on the session host to have their “local” data get automatically redirected to a different virtual hard drive instead of getting written to the actual session host server, but you can configure that later. Click Next then Create to finish the Collection wizard. When it’s done, you can click Close. Now it’s time to publish the applications you really want to give users access to. From the Remote Desktop Services page, select the new RemoteApps collection you made and then from the Tasks button by RemoteApp Programs, select Publish RemoteApp Programs. You can select a program from the list or click “Add Another Program” to browse to an executable. When you’re happy with your selection click Publish, then Close. And that really completes the set up the Standard deployment. You now have a Web Access, Broker and Session Host deployed with applications published via RemoteApp. Way to go you! So how to you test it out? If you want to test it from one of your new servers, let’s first, let’s turn off the IEESC. From the Server Manager, select the Local Server page and click the link next to IE Enhanced Security Configuration and set it to Off. Now open Internet Explorer (run c:program files (x86)internet exploreriexplore.exe) and enter the HTTPS url for your RDWA server, appending /rdweb to the hostname. For this example… https://rede-rdgw-01.techrede.net/rdweb This can be made easier to remember for you users by creating a DNS alias (CNAME) and even set up HTTP redirection later on. After passing the certificate warning you’ll be promoted to run an ActiveX Control. Allow that to run and then log in. Once connected you should see your custom list of applications that are available, so click on one of them to launch the RemoteApp. You’ll be prompted by Internet Explorer with a warning that the Web Site is trying to start a program on your computer. It’s using the Active-X Control to launch the local RDP client (mstsc.exe). This warning can be suppressed by Group Policy once the web site certificate is replaced, but for now just click Connect. Once connected, the application would look just like any locally installed application, but you’ll notice a new system tray icon will show that you are connected to a Remote Work Place. And there you have it, RDS, Quick and Easy on three servers in about an hour. Now you can install new applications and publish them to your Collection. Just like Windows 2008 R2, you can deliver these RemoteApps from RDWeb or by subscribing to the RemoteApp RSS feed. If you want to make these applications available outside of your organization, the next step will be to deploy the RD Gateway role, or if you want to go bigger, try adding more Session Hosts, the equivalent to a RDS Farm. N’joy!
- RDS in Windows Server 2012 requires Active Directory.
- Three servers running a fresh and updated install of Windows Server 2012 joined to that domain.
RDCB | RDWA | RDSH |
Remote Desktop Connection Broker.This is the “hub” of the RDS environment. It ensures that all user connections that are established to the various Session Hosts are maintained through disconnects and reconnects and play a key role in simplifying the single sign on experience. | Remote Desktop Web Access. A web site that simply hosts the list of available resources that can be reached through RDS. It also hosts an RSS feed that can be used in various places. | Remote Desktop Session Host. The server that actually runs the user processes. This is what people sometimes refer to as a Terminal Server, although that term has officially been depreciated. When a user runs a RemoteApp or connects to a Desktop, it’s running on a Session Host. |
RDS8 - Gateway and Certificates on Windows Server 2012
As the name implies, Remote Desktop Services is a way of delivering services for desktops that are not “local”. However, the Quick and Standard deployments of RDS do not include a key component that makes these services available from outside your organization: the RDS Gateway. This role is acts at a proxy over HTTPS to allow a client to tunnel over SSL to your internal resources, limiting exposure and securing communications. In Server Manager, if you want to deploy a separate server for the RDGW role, you’ll want to add that new server to the console which is already managing the rest of your RDS environment. I like to use the manager on the RDCB for this, but any Server Manager console that is managing all of your RDS hosts will work just the same.
In this example I am going to be adding the role to the same server that is already running the RDWA role, so the RDGW and RDWA will be on one server. From the Remote Desktop Servcies area just click on the big green + above RD Gateway to get started.
Select the server that you want to install the role and add it to the Selected list on the right.Pick a DNS name that clients will connect to in order to use the Gateway
This should be the External DNS name that can be resolved to an IP address that will NAT port 443 to the RDGW server. NOTE: In this example the RDGW and RDGA roles are on the same server, both of which use port 443. However, if you also NAT port 80 then the RDWA server will redirect web browsers from HTTP to HTTPS. Without access to port 80 your users will have to remember to type https:// when accessing the RDWA. It’s just being nice to your users really. Also notice that the wizard mentions a Self-Signed Certificate. We will change this in just a moment, so click Next.
On the Confirmation page just click Add if you’re happy with the config.
Once completed successfully click Close.
Notice the warning that a certificate must be configured. You can click on Configure certificate, but if you click Close you can still manage the certificate by selecting “Edit Deployment Properties” under the Overview Tasks.
At this point you can decide to create a new Self-signed certificate that you would apply to all roles or if you’re going to be putting this into production I would suggest that you should be using a 3rd party certificate that all clients will trust be default. I prefer a wildcard certificate for the external domain name being used for the RDWA and RDGW roles.
When you click “Select existing certificate” you will want to select a .pfx file that contains the Private Key of the certificate. Without the Private Key, the server will not be able to use the certificate. Once you’ve entered the password and checked the box to allow it to be added to the trust root CAs, click OK and then Apply the changes.Once you apply the certificate, do it again for all the remaining roles.
Now your client computers can use the Gateway setting found under More Options / Advanced / Connect from anywhere Settings. Under Server Name simply punch in the external FQDN of the gateway server.
With that set you can now try connecting to the internal name of any server on your company network. When you are prompted for credentials you’ll notice the broker name is listed as one of the servers in the connection path.
And you’re all set! Now you can use RemoteApp and Desktops from anywhere. N’joy!
RDS8 - Add a 2008 R2 Session Host
It’s not talked about very much but there is a somewhat hidden feature in Windows Server 2012 Remote Desktop Services that allows you to include a Windows Server 2008 R2 Session Host in the 2012 environment, and it’s really easy! Why would you do this? Why would you want to have a mix of Server 2012 and Server 2008 R2? Perhaps you want to do migrate from an existing 2008 R2 RDS environment rather than do a complete cut over. Or perhaps you find an application that requires Server 2008 R2 for support reasons. Or maybe you just want to publish an older version of Internet Explorer (you could publish IE8 or IE9 this way). Whatever the reason, Microsoft has included a line in the web.config file of the RDWeb server that allows you to access applications (or the desktop) on a 2008 R2 RDSH server. Nothing to install nor even a service to restart. Just edit the file, list the server and poof, your done! In case you haven’t set up a 2008 R2 session host before, I’ll show you how to do that and how to configure it to allow the 2012 RDWA server to read the list of available applications. Let’s get started.
Set up the 2008 R2 Session Host
Build yourself a server with Window Server 2008 R2 SP1 and join your domain. then open the Server Manager and start the Add Roles wizard. We want to set up Remote Desktop Services And select the Remote Desktop Session Host All the other role services will be managed by the Windows 2012 servers. You can pick “Do not require NLA” if you want to allow older clients like XP to connect to RDS, but if you’re going to be a Windows 7 and Windows 8 shop, you may want to consider using NLA to provide better security. You can worry about licensing later, or if you’ve already added a RDLI server you may want to select the mode now. Per User is most common. Select the group of users that should have access to this RDS Server. Note: this should be a pretty generic group, like Domain Users or a smaller list of users that you allow to access RDS. You can later get more granular about who has access to specific applications. This group determines who can access the environment as a whole. If you want to allow this Session Host to play audio and video, then check the first box. this will install the “Desktop Experience” feature which includes a set of codecs, audio support and other apps that are typically found only on desktop operating systems (like the clipping tool, etc). You may want to include the Desktop Composition option as well if you want to “chrome” on RemoteApps to look more like a Windows Client application would (the Aero curved corners and transparency) . Review your selections and click Install. When it’s finished you’ll need to reboot. After the restart, make sure you log in as the same user that initially installed the Role to complete the installation. If you have already assigned certificates to be used on your Server 2012 environment then you should import that certificate on the 2008 R2 server now. Just open the Certificates MMC for the local computer account and import it to the Personal store. Make sure you have the Private Key as well! From the Server Manager, open the Local Users and Groups and double click the “TW Web Access Computers” group. You want to add the Computer account of your Server 2012 RDWA server. In my example, the RDGW and RDWA roles are on the same computer, thus the name in the screen shot is my “Gateway and Web” server. Under Roles, select the RD Session Host Configuration and double click the RDP-Tcp connection. Here you can select the Certificate you imported earlier. From the RemoteApp Manager, click the Change link near “Digital Signature Settings” to select the certificate that should be used to sign the RemoteApp files. If you have a windows 2012 Remote Desktop Gateway server, then you should also click the Change link for RD Gateway Settings and enter the external FQDN of the Gateway as this values gets written into the RDP files so external users can connect to the session host.Publish an Application
Now it’s time to publish an app! From the RemoteApp Manager, right click in the RemoteApp Programs area and select Add RemoteApp Programs. You can either select an app that’s already listed, but for this example I want to publish Internet Explorer. So click Browse and navigate to the location of the EXE file. You may find that the location gets sent to a UNC path, just make sure you set the local drive path. In this particular case I also want to make sure I publish the 32-bit version, and I also like to set the Name and Alias to something more friendly like “IE9”. I’ve also found that sometimes the icon does not appear in RDWeb when using the x86 path to program files, so picking from the x64 exe seems to correct that. And you’re done! This Windows Server 2008 R2 session host is ready to go.Set up the 2012 Web Access server
And now for the easy part… On your Windows Server 2012 RDWA server, open C:WindowsWebRDWebWeb.config in notepad and search for “ws2008r2rdserver” and set the value to the FFQDN of your 2008 R2 RDSH. When you try to save the file you might not be able to write it because it’s under the Windows folder and it’s protected by UAC, so save it to your desktop and then copy it from there back to the RDWeb folder. You’ll be prompted for admin rights to do it, and to overwrite the original file. And you’re done! If you load up your RDWeb page you should see your new application listed right along with all the other apps that are on you other 2012 Session Hosts. Neat trick, thanks Microsoft! N’joy…
Q: How do I use Server Manager to set the Remote Desktop Licensing mode for Windows Server 2012 RDS deployment?
A: Remote Desktop Services management is fully integrated into Server Manager with Windows Server 2012; however, setting the RDS licensing mode isn't obvious, initially.
- Open Server Manager.
- Navigate to the Remote Desktop Services navigation area.
- Select the Overview branch.
- Under the Deployment Overview area, select Edit Deployment Properties from the Tasks menu.
- Select the RD Licensing page of the displayed dialog.
- Specify the licensing mode and the license server, then click OK.
IT Consultant incoreporation.com
No comments:
Post a Comment