RDS License Server - remove Temp licenses
-
@Mike-Davis said:
@Dashrender So you have to switch the licensing mode of the server to match your licenses?
That is my understanding, yes.
-
A single License server can have both types of licenses, but the RDS servers themselves I think have to be one or the other depending on your needs.
You might have 10 computers that need RDS with 100 users, then you might have 10 users who use 5 different computers each... so this situation is best served with two different RDS servers, Device with 10 licenses limited to those 10 PCs... and a second one with 10 user licenses with unlimited devices for those 10 users.
-
They are not being denied in either case. Just events in event viewer. The error is:
The Remote Desktop license server cannot update the license attributes for user "admin" in the Active Directory Domain "contoso.com". Ensure that the computer account for the license server is a member of Terminal Server License Servers group in Active Directory domain "contoso.com".
If the license server is installed on a domain controller, the Network Service account also needs to be a member of the Terminal Server License Servers group.
If the license server is installed on a domain controller, after you have added the appropriate accounts to the Terminal Server License Servers group, you must restart the Remote Desktop Licensing service to track or report the usage of RDS Per User CALs. -
so all the things mentioned are in the groups mentioned?
-
@Dashrender Yes, the terminal server is in the terminal server license servers group, and it's not a domain controller. In addition I followed these steps: (from https://support.microsoft.com/en-us/kb/2030310)
Use the Delegate Control Wizard to add the permissions to add read\write permissions to the terminalServer attribute or to the Terminal Server License Server attribute of the “user object” by the Terminal Server License Servers group. To do this, follow these steps:
Right-click the domain in Active Directory Users and Computers, and then click Delegate Control.
In the Users and Groups dialog box, click Add. Type Terminal Server License Servers, and then click OK. In the Users and Groups dialog box, click Next.
In the Tasks to Delegate dialog box, click Create a custom task to delegate, and then click Next.
In the Active Directory Object Type dialog box, click Only the following objects in the folder. In the list, click User objects (the last entry that is in the list), and then click Next.
Do one of the following, according to the operating system that the domain controller is running:
For forests that are running Windows Server 2008 or newer Schema:In the Permissions dialog box, make sure that only the General check box is selected. In the Permissions list, click to select the Read and Write Terminal Server license server check box, and then click Next.
In the Completing the Delegation of Control Wizard dialog box, click Finish. -
@Mike-Davis said:
@Dashrender Yes, the terminal server is in the terminal server license servers group, and it's not a domain controller. In addition I followed these steps: (from https://support.microsoft.com/en-us/kb/2030310)
OK so you added the TS itself - how about the License server?
Ensure that the computer account for the license server is a member of Terminal Server License Servers group in Active Directory domain <domain name>.
-
Both roles are on the same box.
-
I figured out what was triggering the 4105 error. It was only triggering that error when the user account that was logging in was not in the default Users OU. If the user account was in another OU outside of Users, it would allow them to login, but trigger that error, and not increment them in the user report. Basically switching the server licensing mode from device to user and making sure the AD attributes for terminal server had been give write delegation by the terminal server license server took care of the original issue.
-
How did you track that down?
-
After doing everything the articles said and rebooting the server, when it still wasn't working, I wondered if it had something to do with not being able to write to those attributes, so I created a test account in the users OU, and it worked. Checking the license log, I noticed that the server had been giving out licenses properly, but not for all accounts. Then I went through the log again and discovered that all the 4105 errors were generated by accounts that were not in the default Users OU.
