Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Here's the rundown on the server:

  • Server 2008 Standard running as a member server in a Server 2003 domain
  • Running Terminal Services for 5 users that need to access a POS application using RemoteApp
  • Running it's own licensing server:
    • 5 TS Per User CALs are installed
    • The "Configuration Review" gives me a splat complaining that the licensing server is not installed on a DC.
    • The server is a member for the "Terminal Server License Servers" group in AD
    • It does not seem to be handing out licenses, although users can log in fine.

I receive the following error when users login:

The Terminal Services license server cannot update the license attributes for user "[username]" in the Active Directory Domain "[domainname]". Ensure that the computer account for the license server is a member of Terminal Server License Servers group in Active Directory domain "[domainname]". 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 Terminal Services Licensing service to track or report the usage of TS Per User CALs. Win32 error code: 0x80070005

This appears to be causing some issues with the RemoteApp users. The session seems to disconnect then leave a completely black screen on their system. They can't close the black screen -- I have to log them off remotely using Terminal Services Manager. It also forces them to load the RemoteApp in the "Show Details" window that shows when the user is logging into the Terminal Server (that's hard to describe -- I'll grab a screenshot if anyone needs one).

I've read this thread and this one on technet, and both point to the following security keys:

  • msTSExpireDate
  • msTSLicenseVersion
  • msTSManagingLS

I've searched high and low to find these keys so that the licensing server can adequately license the users, but I can't find them anywhere. I'm selecting my OU for my user accounts and attempting to change the security there, but I can't find the keys to change.

This domain was upgraded to Server 2003 from Server 2000, so that might be why the keys aren't there. A few people have mentioned doing adprep from the Server 2008 machine to write the correct security keys to the users, but would that cause problems with my existing Server 2003 domain controllers? I don't plan to upgrade my domain controllers to Server 2008 until later in the year.

Does anyone know how I can add the security keys manually to the 5 users that are using this terminal server? Is there anything else I can do to fix this?

Thanks!

EDIT: I'd specifically like to know if running adprep from a Server 2008 MEMBER SERVER in a Server 2003 domain will fix this or cause other problems. Does anyone have any insight?

share|improve this question
add comment

3 Answers

up vote 1 down vote accepted
+550

According to this link and this one, the attributes you mention were first introduced with Windows Server 2008; so, yes, upgrading the AD schema to 2008 level should fix your problem.

It's a totally safe operation, even if you don't plan to add any 2008 DC to the domain any time soon. Just ensure all your DCs are online, replication is properly working, the DC holding the Schema Master role is accessible and you have Enterprise Admin and Schema Admin rights.

BTW, you should run ADPREP on one of your existing 2003 domain controllers, not on a 2008 member server.

share|improve this answer
add comment

adprep, schema update, etc would not solve your problem i think. upgrading schema is no prob, cause you would have to do this also if new dcs come in.

in my case i have native 2008 r2, sure migrated from 2000 to 2003, to 2008 r2, and also 2008 r2 ts, ts lic, everything nazive in 2008 r2.

but same effect. do not see any problems in real environment but also logging this information on the ts license server.

so if you would look deeper in your infrastructure, you will see that - newly created user account - some of your accounts do have the several msTS Attributes.

i see actually that all of the user accounts in the organizational units with the missing attributes are in the same groups. Same OU. so i think that this problem occurs on self created org units where one problem exists, such a missing inheritable rights setting, missing security setting.

im testing this one now.

what i want to say to everyone:

your system in this error environment has not to be updated, adprep, schemaprep, etc. look at security setting on your ous, user objects.

mathias rühn - kopyczynski

add on: solution was to grant security rights on the user objects who are missing the three msTS attributes: READ and "WRITE Terminal Server license server" for the terminal-licenseserver group.

if you log on again though remote desktop or citrix the three attributes are created on the specific user and filled with information.

also newly created ous had the problem in one of my infrastructures. i had to manually do this setting on the second level ous.

share|improve this answer
add comment

The "security keys" you mention appear to be LDAP attributes (I'm not personally familiar with these ones, but they follow the standard naming convention) so you'll need to use adsiedit.msc (available in the Windows Server 2003 Resource Kit) to get at them.

The schema upgrade via adprep is a good idea. As well as bringing on these attributes it will give the new schema a bedding in period before you make the move to 2008 DCs. As Massimo said, it's a safe operation, but make sure that you have a viable backup of your AD before doing it (and also that you know that you can restore from it!) in case you get a power failure or something else nasty happens part-way through.

As well as the schema upgrade - did you move the TS box to a new OU at any point in time? Several MS Services become unhappy when you do this, and - if you haven't restarted the services or rebooted the box - may give erratic behaviour. I'd consider it a general good practice to restart any services that interact with AD following a Computer move operation.

share|improve this answer
    
Great. I'll give this a try this weekend and let everyone know. –  Russ Warren Feb 12 '10 at 19:39
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.