Remote Desktop Licensing server can’t update attributes of AD user

Posted on Updated on

It seems in some scenarios users accessing a Remote Desktop Session Host (RDSH) don’t get a license from a Remote Desktop Licensing (RDL) server and an even ID 4105 is logged on the RDL server. This event is talking about a problem, i.e. attributes of an AD user can’t be updated by the licensing server. This article explains what happened and how to fix the issue. But let’s start with some background information first, just to be sure you have the necessary knowledge about this topic. Note this is not a complete manual though, it just explains the things you should know before discussing the actual issue.

What you should know about Remote Desktop Licensing first
When you use Remote Desktop Session Hosts (RDSHs) you need a Remote Desktop Licensing (RDL) server to take care of licensing needs. One exception is when you only use administrative sessions on your RDSHs, but there are not many scenarios out there where you need to set up RDSHs for administrative sessions only. An administrative session is a session for administrative purposes and doesn’t require a license. You can get an administrative session by starting Remote Desktop Connection (RDC; mstsc.exe) with the admin switch, so just like this:
mstsc /admin

Do not try to give your users access through administrative sessions, because

  • That’s not a user friendly way, isn’t it?
  • Isn’t that cheating… actually?
  • Only 2 concurrent administrative sessions are allowed on a certain system, so in almost every case this limit is way too restrictive J
  • By default administrative sessions are only possible for administrator accounts, but not for normal user accounts
  • Some things can’t be achieved during such a session. One example: Aero.

If you are a cheater, don’t care about user friendliness, don’t need to have more than 2 users access the system at the same time, let your users be administrator on the system (except when you configure the system so normal users can use administrative sessions) and don’t need or care about the restrictions, well, OK, than you have an exceptional situation where you don’t need that license server.

Now, let’s assume every RDSH needs such an RDL server. How can an RDSH know which system to use as its licensing server? Well, in the past Terminal Server (TS), the predecessor of RDSH, could discover such a licensing server automatically, but now an RDSH must be configured explicitly to use a set of licensing servers. This way it’s much easier to determine which RDSHs should use which RDL servers. For example, suppose you have 2 RDSHs (A and B) and 2 RDL servers (1 and 2) and you want RDSH A to use RDL server 1 and RDSH B to use RDL server 2. This is easily achieved by configuring RDL server 1 as the licensing server on RDSH A and RDSL server 2 as the licensing server on RDSH B. RDSH A will never use RDL server 2, while RDSH B will never use RDL server 1. With automatic discovery this would be very difficult and/or error-prone to achieve, as RDSH A could discover RDL server 2 and RDSH B could find RDL server 1; even more, this could change over time: one moment RDSH A would use RDL server 1, but later it could use RDL server 2 after a new discovery. On the other hand, automatic discovery is easy: no configuration work at all! IMO a mix of both would have been the best of both worlds actually: if it doesn’t matter, use automatic discovery and if it does, configure the RDL server(s) explicitly. But who am I, right? 😉

Anyway, one way to configure the RDL server(s) on an RDSH is the graphical way: go to the Start menu on the RDSH, then to the menu “Administrative Tools” (if your Start menu is configured to show this menu; if not, open Administrative Tools through Control Panel), then the submenu “Remote Desktop Services” and finally select “Remote Desktop Session Host Configuration”. The window “Remote Desktop Session Host Configuration” opens. Double click something under the “Licensing” section with the left mouse button and the dialog box “Properties” pops up, immediately in the tab “Licensing”. This dialog box lets you configure general Remote Desktop Services (RDS) settings and the Licensing tab targets licensing settings of course. In the section “Remote Desktop License servers” you can add or remove the RDL servers to be used by the RDSH.

There are other ways to configure RDS settings, including the RDL servers to be used. You can change the registry directly or use group policies. In the screenshots below you can see how I start up the “Remote Desktop Session Host Configuration” window and open the Licensing tab of the Properties dialog box. You can clearly see two RDL servers are configured. The licensing settings are grayed out, because I have configured them through group policies.

Figure 1

Figure 2

Now, suppose some shithead in your company has installed an RDSH behind your back and wants to use one of your RDL servers. Even if he (or she) doesn’t have administrator permissions on those RDL servers, he is still able to use them for his/her RDSH. You can tighten the security though, by configuring your RDL servers to only accept specific RDSHs. Yes, this means extra configuration work, but it also means better security! In some environments it’s not that important, i.e. when RDSH and RDL admins are the same persons; but even then it could mean an extra layer of security and it could also prevent RDSHs to use a certain RDL server by mistake (for example, you deploy a new RDSH, which gets several GP settings, including the RDL servers to use, while this RDSH has been put into the wrong OU by mistake, so getting not the desired GP settings and thus perhaps not the right RDL servers). Personally I use this extra protection layer, but of course it’s up to you whether to do the same or not.

On the Licensing tab of my last screenshot we saw another interesting setting: the Remote Desktop licensing mode. You can use a per device or per user licensing model. It’s simple: “per device” means that every client device using your RDSH infrastructure must have a license (a so-called Remote Desktop Services Client Access License or RDS CAL), while “per user” means every user using your RDSHs must have a license. If you have 100 users sharing about 50 client devices to get access to your RDSHs, it’s better for your wallet to choose for the per device licensing model. In most cases though there are more client devices than users, so the per user model is probably the most interesting model for most companies and organizations. It’s possible to set this model through group policies, as is the case in my example; that’s why these settings are grayed out on the Licensing tab.

If a user logs on and is assigned a license successfully, the RDL server keeps track of it. You can create a report on the RDL server, telling you which users have got a license and when this license will expire. Open the Remote Desktop Licensing Manager (RD Licensing Manager) on the RDL server or from a remote machine, which can be done by going to the Start menu, Administrative Tools and then Remote Desktop Services and finally select Remote Desktop Licensing Manager. The RD Licensing Manager windows opens and in the left pane you can see the name of the RDL server you’re connected with and of course you can change this to another one. If no server is mentioned here, this means you’re not connected to an RDL server.

Figure 3

Figure 4

Now, select the name of the RDL server in the left pane (see figure 4) and right-click with the mouse. Choose for the submenu “Create Report” and select “Per User CAL Usage…”. The “Create Per User CAL Usage Report” dialog box pops up. From here we can create a report which tells us which users (“Per User”) have got a license (CAL, i.e. an RDS CAL) from the RDL server.

Figure 5

Figure 6

If you want such a report for every user of the domain your RDL server belongs too and for whom the RDL server has issued a license, choose the first option (“Entire domain (The domain in which the license server is a member.)”). There are other possibilities, but let’s keep it with a simple example here, because it’s just my intention to show you how you can create such a report and not to explain everything about this topic. If everything goes well, you see the following dialog box and when you click “OK”, the tree in the left pane is expanded (if that wasn’t the case already) and you can see the node “Reports” under the server name.

Figure 7

Figure 8

If the Reports node is selected you the the created reports in the right pane. Select the report you like to investigate, right-click it with the mouse and select “Save As” from the context menu.

Figure 9

Save the report as an csv file and open it. Then you get a list of the issues CALs.

Now what’s the problem?

Let’s assume we have chosen the per user licensing model. A user logs on to an RDSH and needs a license from an RDL server. So far, so good. But… it could be that the following event is logged in the System event log of an RDL server:

Event ID: 4105
Description: The Remote Desktop license server cannot update the license attributes for user “USER” in the Active Directory Domain “DOMAIN”. Ensure that the computer account for the license server is a member of Terminal Server License Servers group in Active Directory domain “DOMAIN”.
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.
Win32 error code: 0x80070005
Source: TerminalServices-Licensing
Level: Warning
User: N/A
Computer: YOUR_RDL_SERVER
Logged: DATE_AND_TIME
Task Category: None
Keywords: Classic
OpCode: Info

Ahum, what is this all about? Well, sometimes a user logs on, but doesn’t get a license assigned by the RDL server. If this happens, this event is logged for that user. It also means the user isn’t mentioned in a report created by the RD Licensing Manager for the relevant RDL server. The user is able to log in and gets a temporary license instead. The key question is of course: why, oh why, doesn’t the user get a “real” license assigned?

There are a few possible reasons. The first thing to check out is if your RDL server is a member of the “Terminal Server License Servers” Active Directory (AD) group in the user’s domain. This group has a few permissions which are necessary to make everything work as it should be, so the RDL server should definitely be a member of this group. So, if you want a user from a certain domain to access an RDSH and get a license from an RDL server, that RDL server needs to do something in that user’s domain, so it needs the right rights. This can be achieved by giving this RDL server the necessary rights yourself or by making the RDL server a member of the “Terminal Server License Servers” group in the user’s domain, because this group already has the correct permissions.
A second thing to check out is if your RDL server is a domain controller (DC) or not. If it isn’t, ok, no problem. If it is, check if NETWORK SERVICE is a member of the “Terminal Server License Servers” Active Directory (AD) group in the user’s domain, because that’s required in this scenario.

I just told you the “Terminal Server License Servers” group already has the correct permissions. Well, sometimes… Read on and you’ll understand. If an RDL server assigns a license to a user, it does a few things with the user object in the user’s domain. So as said before, the RDL server needs the right permissions to do so and making it a member of the “Terminal Server License Servers” group should be OK, because that group has those permissions already; that is, in theory. Before Windows Server 2008 a user object had one attribute related to TS licensing: “terminalServer”. A pre-WS08 TS licensing server only updated this specific attribute. With the Windows Server 2008 AD schema user objects got a few extra attributes and WS08 TS Licensing servers and WS08R2 RDS Licensing servers not only try to update this attribute, but also those new attributes if the AD schema is at least at WS08 level. Those new attributes are: msTSExpireDate, msTSLicenseVersion and msTSManagingLS.

Starting from Windows Server 2003 every user object gets the terminalServer attribute; not only new user objects at creation, but also existing objects if and when you upgrade a pre-WS03 AD environment to a WS03 environment. This is logical as the WS03 AD scheme is updated with this new attribute, so this implies every (existing or new) user object gets the attribute whatsoever. The same can be said for WS08: starting from Windows Server 2008 every user object gets the terminalServer, msTSExpireDate, msTSLicenseVersion and msTSManagingLS attributes. Again, not only new user objects at creation, but also existing objects if and when you upgrade a pre-WS08 AD environment to a WS08 environment. Again, this is due to the new WS08 AD scheme that’s implemented.

When a new user object is created in a WS03 or WS08 AD environment, the “Terminal Server License Servers” AD group gets the right permissions on those new user objects automatically. So far so good. But what about already existing objects created many years ago in a Windows 2000 AD environment? They don’t have those permissions as at the time of creation this group didn’t exist and the concept behind TS licensing was different. When AD is upgraded to WS03 or WS08 permissions on existing user objects are not updated. This means user objects from the Windows 2000 AD era don’t have an Access Control Entry (ACE) in their Access Control List (ACL) for the “Terminal Server License Servers” AD group (which by default resides in the Builtin container in the root of the domain). So…? So, RDL servers don’t have the right permissions for some user objects, so those users cannot get a license and event ID 4105 is logged whenever such a user logs in.

What you should do, is solve this issue. Of course J But how? Well, by assigning the “Terminal Server License Servers” AD group the right permissions to those users yourself. You could do this manually or in a scripted way. At the same time you can do it per user or on an OU or domain level; in the latter case user objects will typically inherit those permissions. If you assign the permissions on an OU or domain level you introduce something non-default of course, as the permissions are typically only set on a per user level. So I guess it’s best to use a script to set the permissions on a per user level: this is the cleanest way, corresponds to default situations and you don’t have to do any manual work.

Let’s have a look on what permissions are granted or denied for Terminal Server License Servers in a WS03 AD environment. By default those permissions are present on user objects, no permissions are denied and those 2 permissions are granted:”Read terminalServer” and “Write terminalServer”. This may not surprise you, isn’t it? With those permissions every RDL server has read and write permissions on a user object for the “terminalServer” attribute, the only attribute for TS licensing on a user object in an WS03 AD environment.

Now let’s examine the different mechanisms one by one:

  1. Open ADSI Edit, select a user that’s missing the right permissions and add an ACE to the user’s ACL. The ACE should give Terminal Server License Servers the Allow permissions “Read terminalServer” and “Write terminalServer” (in an WS08 AD environment this should be extended with “Read msTSExpireDate”, “Write msTSExpireDate”, “Read msTSLicenseVersion”, “Write msTSLicenseVersion”, “Read msTSManagingLS” and “Write msTSManagingLS”). Repeat this for every user missing those permissions. Good luck, because in some environments this could take you months. Literally.
  2. Open ADSI Edit, select an OU (or even the domain) containing users which are missing the right permissions and add an ACE to the ACL. The ACE should give Terminal Server License Servers the Allow permissions “Read terminalServer” and “Write terminalServer” (in an WS08 AD environment this should be extended with “Read msTSExpireDate”, “Write msTSExpireDate”, “Read msTSLicenseVersion”, “Write msTSLicenseVersion”, “Read msTSManagingLS” and “Write msTSManagingLS”). The permissions should only be for Descendant User objects. If you don’t assign the permissions at some high level which targets every user with the missing permissions, repeat the same steps for other OUs, so every user with missing permissions has been targeted. This can be easy, simple and fast, but it introduces new, non-default settings, as OUs or the domain normally shouldn’t have those permissions assigned…
  3. Through a command line tool. Run it for every user with the missing permissions, but just as option 1, this could take you months!
    1. For WS03: dsacls “CN=XXXX,OU=XXXX,OU=XXXX,OU=XXXX,DC=XXXX,DC=XXXX,DC=XXX” /G “BUILTIN\Terminal Server License Servers:WPRP;terminalServer”
    2. For WS08: dsacls “CN=XXXX,OU=XXXX,OU=XXXX,OU=XXXX,DC=XXXX,DC=XXXX,DC=XXX” /G
      “BUILTIN\Terminal Server License Servers:WPRP;Terminal Server License Server”
  4. Through a command line tool. Run it for a domain or one or more OUs, till every user inherits the correct permissions. It’s over in a minute, but just as option 2 it introduces non-default stuff…
    1. For WS03: dsacls “OU=XXXX,DC=XXXX,DC=XXXX,DC=XXX” /I:S /G
      “BUILTIN\Terminal Server License Servers:WPRP;terminalServer;user”
    2. For WS08: dsacls “OU=XXXX,DC=XXXX,DC=XXXX,DC=XXX” /I:S /G
      “BUILTIN\Terminal Server License Servers:WPRP;Terminal Server License Server;user”
  5. Through the Delegate Control Wizard, but this only works for WS08 schemes.
  6. Through a script that looks for every user with the missing permissions and fixes this. Now this seems the way to go for me, as it’s simple, easy and fast. And it only adds what should have been there already by default, so it doesn’t introduce any non-default stuff. The only problem is it’s not easy to write such a script; and of course it’s time consuming too… Oh well, actually it’s not that bad, you know. Go ahead, you can “DOS script” based on solution number 3.
  7. Or wait! You can script through PowerShell. And you know what? This is your lucky day, as you can just copy and paste it from here:
    1. For WS03 (replace the path on the first line; it doesn’t have to be the root of a domain):

      $URL = “LDAP://DC=DOMAIN,DC=TLD”;
      $root = New-Object DirectoryServices.DirectoryEntry $URL
      $ds = New-Object DirectoryServices.DirectorySearcher
      $ds.SearchRoot = $root
      $ds.filter = “objectCategory=Person”
      $src = $ds.FindAll()
      Write-Host $src.Count ” user objects found.`n”
      $src | %{
      $de = $_.GetDirectoryEntry()
      $accessrules = $de.get_ObjectSecurity().GetAccessRules($true, $false,[System.Security.Principal.SecurityIdentifier]) | ?{$_.IdentityReference -eq “S-1-5-32-561”}
      if ((Measure-Object -inputobject $accessrules).Count -eq 0)
      {
      $ar = New-Object System.DirectoryServices.ActiveDirectoryAccessRule([System.Security.Principal.SecurityIdentifier]”S-1-5-32-561″, “ReadProperty, WriteProperty”, “Allow”, [guid]”6db69a1c-9422-11d1-aebd-0000f80367c1″)
      $de.get_ObjectSecurity().AddAccessRule($ar)
      $de.CommitChanges()
      Write-Host -f yellow (“Added:`t” + $de.properties[“sAMAccountName”])
      Start-Sleep -m 200
      }
      else
      {
      Write-Host -f green (“Unchanged:`t” + $de.properties[“sAMAccountName”])
      }
      }

    2. For WS08 (replace the path on the first line; it doesn’t have to be the root of a domain):

      $URL = “LDAP://DC= DOMAIN,DC=TLD”;
      $root = New-Object DirectoryServices.DirectoryEntry $URL
      $ds = New-Object DirectoryServices.DirectorySearcher
      $ds.SearchRoot = $root
      $ds.filter = “objectCategory=Person”
      $src = $ds.FindAll()
      Write-Host $src.Count ” user objects found.`n”
      $src | %{
      $de = $_.GetDirectoryEntry()
      $accessrules = $de.get_ObjectSecurity().GetAccessRules($true, $false,[System.Security.Principal.SecurityIdentifier]) | ?{$_.IdentityReference -eq “S-1-5-32-561”}
      if ((Measure-Object -inputobject $accessrules).Count -eq 0)
      {
      $ar = New-Object System.DirectoryServices.ActiveDirectoryAccessRule([System.Security.Principal.SecurityIdentifier]”S-1-5-32-561″, “ReadProperty, WriteProperty”, “Allow”, [guid]”5805bc62-bdc9-4428-a5e2-856a0f4c185e”)
      $de.get_ObjectSecurity().AddAccessRule($ar)
      $de.CommitChanges()
      Write-Host -f yellow (“Added:`t” + $de.properties[“sAMAccountName”])
      Start-Sleep -m 200
      }
      else
      {
      Write-Host -f green (“Unchanged:`t” + $de.properties[“sAMAccountName”])
      }
      }

  8. If you really want, you can use other scripting languages or even program an application to do this job. But I guess PowerShell (and after that DOS scripting and VBScript) is the best choice for this simple job, isn’t it?

Some background information
It could be you have never experience a problem while using a WS03 TS and licensing server. This is because the “Per User” licensing model isn’t really enforced (although you should still obey the licensing rules of course!). Read more about this at the bottom of http://technet.microsoft.com/fr-fr/library/cc772900(v=ws.10).aspx.

The SID of the built-in domain group “Terminal Server License Servers” (DOMAIN\Terminal Server License Servers or BUILTIN\Terminal Server License Servers) is S-1-5-32-561. In WS03 a user object implements the property “terminalServer” represented by the AD object “Terminal-Server” (CN=Terminal-Server,CN=Schema,CN=Configuration,DC=DOMAIN,DC=TLD with DOMAIN your domain name and TLD your top-level domain name; if you use subdomains the path should be adapted a little bit to include your subdomain(s)), which has a schema GUID 6db69a1c-9422-11d1-aebd-0000f80367c1. In WS08 a user object implements a property set named “Terminal Server License Server ” instead though, this time represented by an AD object with schema GUID 5805bc62-bdc9-4428-a5e2-856a0f4c185e.

WPRP is a concatenation of “WP” and “RP” and represents permissions: WP stands for “Write Property” and RP for “Read Property”. After “WPRP” a string defines which kind of object or property (set) WPRP is valid for (in this case we’re dealing with a property (set)). The word “user” means the permissions are only added to user objects.

In ADSI Edit you can check the complete (!) security of an AD object. There are 2 tabs when you check the settings of an Access Control Entry (ACE): Object and Properties. On the Object tab you can see for which objects (in a generic sense, except for a peroperty) which permissions can be set. For example, “Modify owner” is a permission which consists of a permission “type” (this is a word I’m using here), i.e. “modify”, and an object which can make modifications for, i.e. “owner”. Otherwise said: it determines if you can modify the owner of the object you’re checking the security for. Note that the last 2 times I used the word “object” I’m not talking about the same object or kind of object. Confusing heh? J Anyway, on the Properties tab we have the same situation, but only for properties instead of “generic objects”. For example, “Read terminalServer”. This deals with a “read” for the property “terminalServer”. The names of objects and properties you see in this GUI are the ones you need when using dsacls.

Be aware that when changing the security through the GUI you need to refer to the group via the DOMAIN domain, while in dsacls this needs to happen through the BUILTIN “domain”.

The PowerShell script for WS08 is not completely my own work. Luckily some brave hero had already made it, although I have changed it a little bit. I also had to change it for a WS03 domain (the original script used the schema GUID for WS08), otherwise it won’t really work the way it should be. Note that this script should be finetuned if necessary. First of all you should customize the LDAP path on the first rule. Secondly you should delete some lines if you don’t want to count the number of user objects for example. Thirdly, you can change the way output should occur. Or, number 4, you can change the way it should determine if it should add the permissions or not (in my version of the script I checked if there is already an ACE for Terminal Server License Servers, but theoretically this is not always the best way; for example, it could be that you have already added another ACE for this group, independent of the content of this article). Fifth… No, seriously, you can change a lot in the script, depending on what you want. But at least I think you have a very good base to build on (and I guess 99% of the people will just re-use it as-is, except for the LDAP path).

The issue is described in KB2030310 (http://support.microsoft.com/kb/2030310), but not as complete as it must have been, so I guess my article extends Microsoft’s one. Well, at least I hope so J

Greetz,
Pedro

Advertisements

11 thoughts on “Remote Desktop Licensing server can’t update attributes of AD user

    Christian Fenneberg said:
    12/11/2012 at 17:09

    Hi Pedro

    Great blog!!! and nice scripts as well 🙂

    Are you missing some parts in the Windows 2008R2 script?? it seems that only the Terminal Server read/write permission is granted, i think that the other 3 settings are not applied.
    I might be totally wrong as I am not an expert 🙂

    Kind regards
    Christian

      Padre Pedro said:
      12/11/2012 at 20:44

      Hi Christian, the attributes “msTSExpireDate”, “msTSLicenseVersion” and “msTSManagingLS” in WS08(R2) also belong to the same property set as the attribute “terminalServer” belongs to. That property set is defined by a GUID. The script uses a different GUID for WS08, so it targets all 4 attributes. With other words, the script for WS08 as noted in the blog post also takes care of the other, new attributes. Please understand WPRP tells the system to check the read as well as the write versions of those attributes (WPRP does not refer to the attribute “terminalServer”; perhaps you were thinking that?)? If this is still not clear to you, please don’t hesitate to ask me for more information again! Ciao! Pedro

        Christian Fenneberg said:
        12/11/2012 at 21:03

        Pedro – you are my hero – thanks for the quick reply.

        I modified the URL to match a test OU in our domain, ran the script and noted that the 3 other properties in the ACE for the users in that OU had not been set. but the TerminalServer attribute has been set. I now understand that the Attributes belong to the same property GUID but fail to understand why the attributes are not all set to the same READ/WRITE allow value.

        I have tested with method 2 in your blog, it seems to set all 4 correctly, but its late and soo I might be wrong. I will check tomorrow.

        Kind regards
        Christian

        Padre Pedro said:
        12/11/2012 at 22:15

        Christian, first of all, I’m not a hero, but thanks anyway 🙂 Secondly, you have a WS08R2 AD domain, right? Which script had you ran? The first one or the second one?
        Information about the GUID can be found here: http://msdn.microsoft.com/en-us/library/windows/desktop/ms684408(v=vs.85).aspx You see this property set contains the 4 attributes for WS08(R2) and even WS2012. I must admit I’ve never executed the 2nd script (for WS08), because our domain was still WS03 at the time of writing. But the Original script I’ve found just had this WS08 GUID (instead of the GUID for WS03) and it also seems logical to me (especially if you see my theory confirmed by the information form the link). So I can’t really explain your issue when running the 2nd script for your WS08R2 domain… So that’s why I’m asking you if you indeed have a WS08R2 domain and if you have executed the 2nd script and not the first one…?
        Ciao!
        Pedro

        Christian Fenneberg said:
        13/11/2012 at 11:27

        Sorry for the wrong reply, should have been in the same thread.

        Its seems that if EITHER of the 4 attributes are set before the script run on WS08R2 then no changes will be done on the User Object. No matter what GUID is used.

        I will proberly modify the script a bit and send “my” edition of it to you asap.

        //C

    Christian Fenneberg said:
    13/11/2012 at 11:07

    Hi Pedro

    Its the second script. I ran it with the GUID for the TerminalServer attribute, and with the GUID for each of the 3 others, no success. I did run the second script, and on a WS08R2 domain.
    Will try some more and let you know the result.

    Adios 🙂
    Christian

    Leonidas said:
    20/11/2013 at 20:18

    Hey, Fantastic post!!
    I was trying to run it on my W2k8 server but it assumed that all users where correct. After checking a little more I found out that the ACL entry was there with no permissions. Since your script just look if the ACL is listed or not it was assuming that everything was OK.

    What I did was adding |? {$_.AccessControlType -eq ‘Allow’} to the end of the line 10. This was the script verify the ACL entry and if it has an allow permission.

    This solved my problem

    Thank you Very much!!!

      Japsurd said:
      04/02/2014 at 14:36

      This script saves me lots of time! Fantastic! I had the same problem as Leonidas and his solution didn’t work for me. Adding | ?{$_.AccessControlType -eq “ReadProperty, WriteProperty”,”Allow”} to the end of line 10 did, however.

    Marko Huovinen said:
    15/02/2017 at 08:50

    Superb post! You just saved my day, Pedro.

    One thing, I had to run the dsacls command in Powershell, as CMD gives “The parameter is incorrect” error.

    Mohammed said:
    31/08/2017 at 03:40

    Great post, explaning exactly the situation and ways to take care of.

    Gerald said:
    05/09/2017 at 09:37

    Hello Pedro,
    congratulations on this post. Unfortunatly the WS08 script is not working for me 😦
    I changed the OU Path and executetd the script in Powershell ISE. It shows some Errors as this:

    At line:13 char:133
    + … -1-5-32-561″, “ReadProperty, WriteProperty”, “Allow”, [guid]”5805bc62-bdc9-4428- …
    + ~~~~~~~~~~~~
    Unexpected token ‘ReadProperty’ in expression or statement.
    At line:13 char:133
    + … -1-5-32-561″, “ReadProperty, WriteProperty”, “Allow”, [guid]”5805bc62-bdc9-4428- …
    + ~
    Missing closing ‘)’ in expression.
    At line:21 char:70
    + Write-Host -f green (“Unchanged:`t” + $de.properties[“sAMAccountName”])
    + ~~~
    The string is missing the terminator: “.
    At line:12 char:2
    + {
    + ~
    Missing closing ‘}’ in statement block.
    At line:8 char:9
    + $src | %{
    + ~
    Missing closing ‘}’ in statement block.
    + CategoryInfo : ParserError: (:) [], ParentContainsErrorRecordException
    + FullyQualifiedErrorId : UnexpectedToken

    I am not an expert in scripting. Could you help me finding the problem?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s