Install Remote Desktop Licensing 1) In Server Manager, open the Manage menu and click Add Roles and Features. 2) Click Next until you get to the Server Roles page. Check the box next to Remote Desktop Services and click Next. 3) Click Next until you get to the Role Services page. Check the box next to Remote Desktop Licensing and click Next. 4) Click Add Features if prompted.
5) Then finish the wizard to install the role service. Activate Remote Desktop Licensing 1) After RD Licensing is installed, in Server Manager, open the Tool menu, expand Terminal Services and click Remote Desktop Licensing Manager. 2) The tool should find the local server. If it does not, right-click All servers, click Connect and type in the name of the local server. Once the local server can be seen in the list, right-click the server and click Activate Server. 3) In the Welcome to the Activate Server Wizard page, click Next.
Evaluation Remote Desktop Services Client Access Licenses (RDS CALs).Find answers to frequently asked questions about Azure Virtual Machine licensing in. Licensing FAQ. CALs are entitled to Remote Desktop Services CAL.Overview of RDS CALs and user CALs, as well as which Windows Server roles require these. Locate “Windows Server R2 Remote Desktop Services connections” and click the “Get a Key” button. For example, if you’re using RDS on Windows Server 2012 R2 and your deployment uses user CALs, choose “Windows Server 2012 Remote Desktop Services user connections (50)”. Five keys of each type are available.
4) In the Connection Method page, click Next. 5) In the Company Information page, enter the required information and click Next. 6) All of the fields on the Company Information page are optional so you do not have to enter anything. 7) In the Completing the Activate Server Wizard page, uncheck the box next to Start Install Licenses Wizard now and click Finish.
Since the session hosts will be configured to pull Per User licenses, there is no need to install licenses on the RD Licensing Server. 8) In RD Licensing Manager, right-click the server and click Review Configuration. 9) Ensure you have green check marks. If the person installing Remote Desktop Licensing does not have permissions to add the server to the Terminal Server License Servers group in Active Directory, ask a domain admin to do it manually.
If you have the proper permissions, click Add to Group. 10) Click Continue when prompted that you must have Domain Admins privileges. 11) Click OK when prompted that the computer account has been added. 12) Click OK to close the window. Remote Desktop Licensing Configuration Do the following on your 2012 R2 Remote Desktop Session Hosts.
The only way to configure Remote Desktop Licensing is using group policy (local or domain). 1) For local group policy, run gpedit.msc. 2) Go to Computer Configuration Administrative Templates Windows Components Remote Desktop Services Remote Desktop Session Host Licensing. 3) Double-click Use the specified Remote Desktop license servers.
Change it to Enabled and enter the names of the XenDesktop Controllers. 4) Double-click Set the Remote Desktop licensing mode. Change it to Enabled and select Per User. 5) In Server Manager, open the Tools menu, expand Terminal Services and click RD Licensing Diagnoser. 6) The Diagnoser should find the license server and indicate the licensing mode. It’s OK if there are no licenses installed on the Remote Desktop License Server. Hi Carl, Once again, you are right on point.
That worked great. Yes, you do need to install the RD Licensing Diagnoser feature to use that tool as it is not installed with the VDA installation. Also, it seems a bit lame that they removed the old configuration tool for the listener and license server/type and made it only GPO based. If they wanted to do that, the VDA installer should address the settings. You kind of spin your wheels for a bit after you installed the VDA (which does enable the RDS session host role) and you get the warning saying that you are still in grace on the RDS license. Cheers, Steve. Also have XenApp 7.6 running on MCS machines-for the last 18 months or so-and all of a sudden recently users were unable to log in due to RDS grace period having expired.
Initially, I thought it was an issue with a corrupt RDS License Server database, so I followed Microsoft's article on how to rebuild the RDS database. Strangely, this didn't exactly fix the problem.after rebooting the XenApp servers, the users were able to log in, but there was still a message about the grace period for the server having expired. In addition, I noticed that when I first booted the XenApp servers, the local policy was correctly writing out the specified terminal server and licensing mode keys in the registry at: HKEYLOCALMACHINE SOFTWARE Policies Microsoft Windows NT Terminal Services but after a period of time, say an hour or so, the XenApp server must've tried to check in with the RDS Licensing server and that registry key would disappear. I don't know if this is expected behavior, but it doesn't seem normal. So at that point, I cracked open the XenApp vDisk image/put in maintenance mode, quickly deleted the hardware ID and subkeys in HKEYLOCALMACHINE SOFTWARE Microsoft MSLicensing as I read you were supposed to do after changing the RDS Licensing server.
I also deleted the RDS grace period 'time bomb' key at HKEYLOCALMACHINE SYSTEM CurrentControlSet Control Terminal Server RCM GracePeriod Also, despite these two things seemingly correctly pushed via the recommended Citrix local policy, I set LicensingMode dword to per-user here HKEYLOCALMACHINE SYSTEM CurrentControlSet Control Terminal Server RCM Licensing Core and put in my RDS licensing server in the SpecifiedLicenseServers key here HKEYLOCALMACHINE SYSTEM CurrentControlSet Services TermService Parameters LicenseServers Then I closed up the vDisk and put in testing mode. Now, I'm no longer receiving the 1130 Event ID warning the RDSH server does not have an RDS License server specified in the XenApp's event logs, users are able to log in as usual-things seem back to the way they were from the user-facing side of things. However, if I run the command wmic / namespace: root CIMV2 TerminalServices PATH Win32TerminalServiceSetting WHERE (CLASS! = ' ) CALL GetGracePeriodDays it shows that I've got 120 days remaining in the grace period, this decrements to 119 days over the course of the day after booting the XenApp server, the Grace Period 'time bomb' registry key is recreated at some point in the day, and the registry values set by the local policy for specifying RDS license server and CAL type still disappear after an hour or so of uptime.
Finally, I should also mention that I temporarily installed the RDS License Diagnoser role/feature on the XenApp vDisk and it correctly shows the RDS Licensing server, has green checkmarks, shows an accurate count of CALs issued and remaining and shows no problems. So, what, in the heck, is going on? Is it possible my XenApp image was never configured quite right or working correctly since day one of my original master vDisk image and that over the last year and a half of periodically opening the vDisk in maintenance mode for updates and such, that the 120 day grace period happened to finally expire on me the other week?