Licensing server Event 4105 continues
Every time a user logs on to my new Windows 2008 terminal server, I get a 4105 error indicating that the license attributes for the user could not be updated. This is a Windows 2008 member server in a Windows 2003 domain. I have tried to follow the steps in the thread below, but I am still getting this error. Also, my domain is not Windows 2008 and my terminal server is not a DC, so my situation is somewhat different than what's described in the thread:
http://social.technet.microsoft.com/Forums/en-US/winserverTS/thread/4fa27bdd-0b9e-440f-a7c7-146a7484a028
The terminal server licensing configuration info on the server itself shows no errors. I also have a Windows 2003 terminal server (also a member server) on the domain, but it will eventually go away. Both servers are in per user licensing mode.
Laurie
Answers
- Hi,
Looks like you updated your schema to 2008. Please grant rights at the OU level for those three user properties (msTSmanagingLS, msTSLicenseVersion, msTSExpireDate) just like you did for terminalServer in an earlier post. Under 2003 schema, terminalServer is used, for 2008 schema, those three properties are used.
I think you are close, please let me know what happens.
Thanks.
-TP- Marked As Answer bySYNOFF Wednesday, November 18, 2009 3:31 PM
- That appears to have done the trick. I'm now showing in my licensing manager that there are 2 user CALS in use - I presume one for the user I just tested and one for the Administrator account that I'm currently logged on with. I didn't see any error message in the event log either. Thanks for your help!
Deb- Marked As Answer byLionel Chen - MSFTMSFT, ModeratorThursday, November 19, 2009 5:24 AM
All Replies
- Your domain has to be updated to the Win2k8 schema. Have you done that?
- Proposed As Answer byKristin L. GriffinMVP, ModeratorThursday, November 05, 2009 5:17 PM
- Well, I think that is supposed to be done automatically when installing Windows 2008 server, isn't it? I didn't manually run the adprep command, but I didn't see any errors or problems while installing either server (this one was the second Windows 2008 server I installed into the same domain). Know any way I could check to see if the schema was actually updated?
BTW, I posted the wrong link in my OP; the thread I read was actually this one:
http://social.technet.microsoft.com/Forums/en-US/winserverTS/thread/1dc6a51e-c204-4323-95f9-e77abe3bad85
Deb - No, installing a Win2k8 server does not automatically run adprep or update the schema. Unless you have run adprep, then you have not updated the schema.
- Hmmm, well if you say so. I have installed Windows 2008 member servers in several other domains, though, and I read a lot of documentation very carefully before doing my first installation. Of course, I can't find the specific document right now, but it definitely stated, and I definitely experienced the results, that if you did not run adprep manually, and assuming that the infrastructure master domain controller was able to be contacted, that the schema would be updated automatically when you installed the first Windows 2008 server into the domain. However, at this point, it makes sense just to run it manually and see if it fixes the problem, so that's what I'm gonna do!
Deb Hi,
Have you checked that all of your security is set properly? There is no need to update the schema to 2008. Here are some items to check:
- Is your TS licensing server a member of the Terminal Server License Servers group?
- Does the Terminal Server License Servers group have read/write access to the terminalServer property on each user account object? You can verify this using ADSIedit.
You can run install/run adsiedit.msc on your 2008 or 2003 server. I will provide instructions for installing/running it on your 2003 domain controller:
1. Download and install the windows support tools on your 2003 DC:
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=96a35011-fd83-419d-939b-9a772ea2df90
2. Start--Run--adsiedit.msc
3. In the left pane, navigate to the OU where your user accounts are located and select the OU.
4. In the right pane, right-click on a user object and choose Properties.
5. On the Security tab, click the Advanced button
6. Scroll down the list and select Terminal Server License Servers, then click the Edit button
7. On the Properties tab, scroll down the list and see if Read terminalServer and Write terminalServer are set to Allow
Please let me know what you find. For example, if Terminal Server License Servers is not listed on the user object's access control list, then that is a problem. Please check multiple user objects, newly-created user objects versus old ones, etc.
You may need to grant the Terminal Server License Servers group Read/Write access to the terminalServer property at the OU level, using the Add button on the Advanced Security settings dialog you used above.
Thanks.
-TP- Proposed As Answer byTP [] Thursday, November 05, 2009 7:38 PM
- Ok - now we're getting down to where I was when I started this thread. I have tried several times to do as you described, but the previous set of instructions I found were not as clear as yours, or I didn't understand them as well, anyway. I cannot find any property named anything like "Read Terminal Server" or "Write Terminal Server" anywhere on the list of properties in the security of the Users OU (which is where all my users are located). I think the mistake I made previously was to try to find this attribute on a security group object, and it's not there either. I was finally able to find these properties only on the actual user objects themselves, so I guess that means I have to set this individually for each user. That is RIDICULOUS, IMO. If this permission is required to use a terminal server license server, then how come it's not added automatically? Of course, I suppose I could go along blithely without having the TS users licensed - but how long would that last?
Anyway, that may be irrelevant, since I just edited the user I have been testing to add the properties you described, and I'm still getting the licensing error message on the TS....maybe it takes some time? I only have 2 DCs in the domain, with about 60 users or so, and all at the same physical site, so I sort of doubt it.
Deb Hi,
Thank you for responding. You did not answer my first question:
Is your TS Licensing server a member of the Terminal Server License Servers group? After making any group membership changes you need to restart the TS Licensing service.No, you do not have to set the allow read/write terminalServer on each individual user object, you can set this at the OU level and the user objects will inherit the rights. You are correct, the permission should be there automatically, however, in your case it is not so we need to fix it. Here are the steps to set it on the User OU:
1. Logon to your 2003 DC as an administrator
2. Start--Run--adsiedit.msc
3. In the left pane, navigate to where your Users OU is located
4. In the left pane, right-click on CN=Users and choose Properties
5. On the Security tab, click the Advanced button
6. Click the Add button, type Terminal Server License Servers and click OK
7. On the Properties tab, select User objects in the Apply onto box
8. In the Permissions box, select Allow for Read terminalServer and select Allow for Write terminalServer
9. Click OK, and click OK again to save your changes
Thanks.
-TP- Proposed As Answer byTP [] Friday, November 06, 2009 12:13 AM
- Thank, TP, but I know very well how to edit the security properties of AD objects using adsiedit.msc. However, I did exactly as you described and as I said in my last post, I could not find any Read TerminalServer or Write TerminalServer property on the Users OU. That's what I was complaining about, and why I said that I would have to edit each individual user's security settings. I have just double-checked this to be sure my eyes weren't crossed yesterday, which was a distinct possibility given how many times I had already read through these lists of properties on different objects, but those two properties are definitely not there on the Users OU. Do you think this indicates something wrong in AD? I suppose it would be possible to add the property manually, but I've never done that, so I'm not sure how to go about it or whether there are dangers in doing this.
As to you other question - Yes, this is the first thing I checked when I found the original error messages, and the terminal server is a member of the Terminal Server License Servers group.
Deb Hi,
Did you change the Apply onto box to User objects? (Step#7) If not, the read/write terminalServer will not be in the list.
-TPOne small step for a woman, one giant leap for administrator-kind! #7 was the step I was missing - thanks. BTW - it's reading as "Descendant User objects" on the newer versions of AD. I noticed that change, I think it was with Windows 2003 R2, not sure. Now it remains to be seen if that actually fixes the issue. I will not be working on this over the weekend, so we'll probably not get around to checking this out until Monday.
DebHopefully this will take care of the issue for you.
My instructions called for the work to be done under 2003, so that is why they read the way they do in regards to not having Descendant in front of the child objects.
Please come back and let us know if the issue is resolved or not. If it still is a problem we can work on it more. If not, great--let us know so that people in the future will know what steps to take.Thanks.
-TP- Hello Deb,
How's the result of the test?
Please share with us and we'll try to assist you further in this case.
Thanks.
Lionel ChenTechNet Subscriber Support in forum
If you have any feedback on our support, please contact tngfd@microsoft.com
- Bad news - I am still getting the license errors in the system log each time a user logs on. At this point, it doesn't seem to be affecting the users, but I imagine it will start doing so eventually. Right now, we have not rolled this out to the users, so everyone is still using the old Windows 2003 terminal server. Is it possible that the fact that there is another terminal server on the domain that is running Windows 2003 and that it is also running the terminal server licensing service is interfering somehow with the 2008 terminal server licensing? I did specify in the group policy for the new terminal server for it to use itself only for licensing.
Deb Hi,
Please configure auditing so that we can see details of the failures. I will go over the basics on how to configure this, if you have questions please let me know.
Enable Directory Service Access Auditing
- Logon to a DC
- Open the Domain Controller Security policy
- Make sure at least failure auditing is enabled here:
Security Settings\Local Policies\Audit Policy
Audit directory service access Success, Failure
- On all of your DCs, open up a cmd prompt and type gpupdate /forceEnable Failure Auditing for a Test user account
- Using ADSIedit, open the Properties of a user account you will be testing with
- On the Security tab, click the Advanced button
- On the Auditiing tab, click the Add button
- Enter everyone, and then click OK
- Select Failed for Full Control, click OK, click OK again to save
- Connect to all DCs on your network using ADSIedit, and verify that the audit entry has propagated
Test logon
- Logon to your 2008 TS using the test user account
Check Results and Post Here
- Logon to your DCs, open Event Viewer
- In the left pane, click Security
- Look in the list for Failure Audits around the time the Test user logged on
- Double-click on each entry and use the Copy button so that you can Paste the entry here for us to review. Please post all entries. In my tests three failure audits are generated for a 4105.
Thanks.
-TPI only saw two directory service access errors; here they are:
Event Type: Failure Audit
Event Source: Security
Event Category: Directory Service Access
Event ID: 566
Date: 11/13/2009
Time: 1:48:33 PM
User: DOMAIN\TERMINALSERVER$
Computer: DOMAINCONTROLLER
Description:
Object Operation:
Object Server: DS
Operation Type: Object Access
Object Type: user
Object Name: CN=USERNAME,CN=Users,DC=DOMAIN,DC=com
Handle ID: -
Primary User Name: DOMAINCONTROLLER$
Primary Domain: DOMAIN
Primary Logon ID: (0x0,0x3E7)
Client User Name: TERMINALSERVER$
Client Domain: DOMAIN
Client Logon ID: (0x0,0x79EB2CE9)
Accesses: Write Property
Properties:
---
Terminal Server License Server
msTSManagingLS
msTSLicenseVersion
msTSExpireDate
userAdditional Info:
Additional Info2:
Access Mask: 0x20
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.Event Type: Failure Audit
Event Source: Security
Event Category: Directory Service Access
Event ID: 566
Date: 11/13/2009
Time: 1:48:33 PM
User: DOMAIN\TERMINALSERVER$
Computer: DOMAINCONTROLLER
Description:
Object Operation:
Object Server: DS
Operation Type: Object Access
Object Type: user
Object Name: CN=USERNAME,CN=Users,DC=DOMAIN,DC=com
Handle ID: -
Primary User Name: DOMAINCONTROLLER$
Primary Domain: DOMAIN
Primary Logon ID: (0x0,0x3E7)
Client User Name: TERMINALSERVER$
Client Domain: DOMAIN
Client Logon ID: (0x0,0x79EB2CE9)
Accesses: Write Self
Properties:
---
Terminal Server License Server
msTSManagingLS
msTSLicenseVersion
msTSExpireDate
userAdditional Info:
Additional Info2:
Access Mask: 0x8
For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.
I replaced the terminal server computer name with TERMINALSERVER, the domain controller computer name with DOMAINCONTROLLER, the user's name with USERNAME and the domain name with DOMAIN, just for purposes of privacy.
Deb- Hi,
Looks like you updated your schema to 2008. Please grant rights at the OU level for those three user properties (msTSmanagingLS, msTSLicenseVersion, msTSExpireDate) just like you did for terminalServer in an earlier post. Under 2003 schema, terminalServer is used, for 2008 schema, those three properties are used.
I think you are close, please let me know what happens.
Thanks.
-TP- Marked As Answer bySYNOFF Wednesday, November 18, 2009 3:31 PM
Hi,
Were you able to resolve the problem by granting the Terminal Server License Servers group read/write access to the the three properties at the Users OU level?
Please give us an update when you have a chance.Thanks.
-TP- That appears to have done the trick. I'm now showing in my licensing manager that there are 2 user CALS in use - I presume one for the user I just tested and one for the Administrator account that I'm currently logged on with. I didn't see any error message in the event log either. Thanks for your help!
Deb- Marked As Answer byLionel Chen - MSFTMSFT, ModeratorThursday, November 19, 2009 5:24 AM
