none
Get-Aduser collecting attribute property whenCreated

    Question

  • Hi,

    I'm having some weird behavior (in my opinion) when collecting  the whencreated attribute values from my active directory.

    Windows 2016 Active directory

    I'm using the following command to collect the whenCreated attribute:

    Get-ADUser -Filter * -Properties Name, whenCreated | select Name, whenCreated

    When I run this command on a Domain Controller under a member of the Domain Admins group without elevated privileges. Not all created dates are returned. For some users they are but not all.

    When I run this command on a Domain Controller under a member of the Domain Admins group with elevated privileges. All created dates are returned as expected.

    When I run this command on a Domain Controller under a regular user using the -credential. Not all created dates are returned. For some users they are but not all.

    Now when I'm using the same command on a Windows 10 workstation with a regular user account, without elevated privileges. All the created dates are returned as expected

    Does anybody has seen this behavior before? My goal was to run this script as a regular user on the domain controller. The Active Directory modules are all ready loaded there. Without elevated privileges.

    And an explanation to why this is happening would awesome.

    Kind Regards Rene


    • Moved by jrv Friday, February 24, 2017 5:23 PM More of an AD issue than a PowerShell issue.
    Friday, February 24, 2017 11:48 AM

Answers

  • Hi all,

    Just found a workaround, but just once more the issue I'm seeing on my dc's

    When collecting extended attributes from your active directory not all values are collected. In my case it was the employeeType and the WhenCreated value. Some do return values and some don't.

    If you elevate the powershell command you will see all the values returned from the active directory.

    If you perform the same command from a workstation without an elevated command, all the values are returned.

    The problem is that somehow I'm not allowed to retrieve this values without an elevated prompt from the domain controller I'm running the command on.

    So in my case I have 2 domain controllers dc1 and dc2
    If I perform the following command on DC1 I will not get all the values from my domain controller.

    get-aduser -server DC1 -Filter * -Properties Name, WhenCreated | Select name, whenCreated

    The -server makes sure it's querying the DC1 domain controller (Where I also execute the command)

    Now if I perform the query on the DC2 from the DC1 I do retrieve all values
    So on the DC1 I perform the following command

    get-aduser -server DC2 -Filter * -Properties Name, WhenCreated | Select name, whenCreated

    The -server is now targeting the DC2 for it's query.

    When logging on to the DC2 I get the exact same results.

    My workaround is just make sure your not executing your query against the domain controller you're logged on/executing your script from: 

    $DomainController = (Get-ADGroupMember 'Domain Controllers' | Where {$_.name -ne $($env:computername)} | Select-Object Name -First 1 ).Name
    (get-aduser -Server $DomainController -LdapFilter "(whenCreated=*)" | measure).count
    Where {$_.name -ne $($env:computername)

    Selects all domain controllers except the one running your script on.

    Select-Object Name -First 1

    Makes sure you only get one domain controller and not the complete array.

    I still believe this shouldn't be necessary, that's why I call it a workaround. And I know there can be issues when one of your domain controllers is down for maintanance.

    And a one liner to check if all dc's are returning the same number of values. (This should be run on a DC to check if you have the same issue as me) If the dc's return the same number all is working fine and you don't have the issue I described in this thread. In a normal situation they should be equal.

    Get-ADGroupMember 'Domain Controllers' | ForEach{"$($_.Name): " + (get-aduser -Server $_.Name -LdapFilter "(whenCreated=*)" | measure).count}

    • Edited by Rene5380 Monday, March 6, 2017 2:42 PM
    • Proposed as answer by Wendy JiangModerator Wednesday, March 15, 2017 1:37 AM
    • Marked as answer by Rene5380 Monday, March 20, 2017 1:12 PM
    Monday, March 6, 2017 2:04 PM
  • If you only have one Domain controller, for now execute your command elevated or install the RSAT tools on a domain member and execute your command from there.
    Monday, March 6, 2017 2:07 PM

All replies

  • Many objects in AD are protected and many aren't.  A user object that has been created by the AD install or by some software packages may be protected.  User objects created later may not be protected.


    \_(ツ)_/

    Friday, February 24, 2017 1:14 PM
  • Hi jrv,

    That still doesn't explain for me why a regular user without any administrative privileges is able to retrieve all the creation dates from an other machine. And an domain admin can't collect all the information from the domain controller it self without elevated privileges.

    Friday, February 24, 2017 1:38 PM
  • I can't reproduce your issue.  Post in the Directory Services forum to see if others have noticed this.  It is not really a scripting issue.

    My guess is that it has to do with what groups the user belongs to and how AD has been modified. 


    \_(ツ)_/

    Friday, February 24, 2017 2:20 PM
  • The only explanation I can think of is that the attribute is not replicating to all DC's.

    Richard Mueller - MVP Enterprise Mobility (Identity and Access)

    Friday, February 24, 2017 3:24 PM
  • The only explanation I can think of is that the attribute is not replicating to all DC's.

    Richard Mueller - MVP Enterprise Mobility (Identity and Access)

    Possible but I doubt it.  Why would one fundamental attribute not replicate???  If the account exisits on the DC in question then the attribute would be there.  No??


    \_(ツ)_/


    • Edited by jrv Friday, February 24, 2017 3:28 PM
    Friday, February 24, 2017 3:26 PM
  • Richard,

    If I target the command at the same server I get the same results. So replication should not be the issue.

    jrv

    The comment about specific groups a user belongs to got me thinking. I have multiple OU's, but the outcome of get-aduser is OU independent of the users OU. From all OU's I have users with and without without creation dates. I found some other users with the same issue but there marked answer was run elevated.
    Maybe this has something to do with the Domain Controller policies. The policies are unmodified, default policy. 

    thx for thinking with me on this,

    Weekend for now,

    Friday, February 24, 2017 4:02 PM
  • There is no policy in AD that controls this.  It is either some form of corruption or the admin account is not directly getting the correct permissions.  Place the Admin account directly in Domain Users and tru again.  Also inspect which groups users belong to.  I have seen strange behaviors when admins attempt to change permissions on AD without understanding how to do it safely and correctly.

    It is not a scripting issue. 


    \_(ツ)_/

    Friday, February 24, 2017 4:07 PM
  • jrv,

    The admin account is in the default Domain users group, the user account however is not not. So I created a new admin account in the same OU as the user but still got the same results.

    About the policy, I was thinking about UAC policy that maybe more strict on a DC than on a workstation. Not sure however I'm no expert on policies.

    I will post the issue in the Directory Services forum next monday.

    Have good weekend.

    Friday, February 24, 2017 4:21 PM
  • I have never heard of a case where whenCreated does not have a value, as long as the object exists on the DC that services the query.

    Richard Mueller - MVP Enterprise Mobility (Identity and Access)

    Friday, February 24, 2017 4:22 PM
  • Richard,

    The whenCreated has a value for all users. If I check the attributes field in the console all is there. When I use get-aduser from a workstation it's returning all the whenCreated values (No elevation or Domain admin required). Only on the domain controler the Get-ADuser does not return all the values just some. Only when I elevate my powershell window I am able to retrieve all the values on a domain controller. And that's not what I want if I don't really have to


    • Edited by Rene5380 Friday, February 24, 2017 4:42 PM
    Friday, February 24, 2017 4:32 PM
  • Rene - I have moved this thread to the DirectoryServices forum.  by Monday you may have more information.

    \_(ツ)_/

    Friday, February 24, 2017 5:24 PM
  • Thank you jrv have a nice weekend
    Friday, February 24, 2017 5:28 PM
  • A little update,

    I've build an test environment windows 2016 domain controller and got exactly the same results.  So corruption is ruled out.

    Monday, February 27, 2017 6:15 AM
  • Hi,
    According to the result which you described, what comes into my mind is UAC setting, so please follow the article as below to check if any group policy is configured to set UAC and you could directly check the registry related to UAC on the DC, please see:
    UAC Group Policy Settings and Registry Key Settings
    https://technet.microsoft.com/en-us/library/dd835564(v=ws.10).aspx
    Best regards,
    Wendy

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Monday, February 27, 2017 9:34 AM
    Moderator
  • Hi Wendy,

    I checked the UAC settings on the Domain Controller versus the Windows 10 workstation, And there exactly the same.

    And if it was a UAC setting I would expect non of the whenCreated values to be returned.

    One other thing I tried was Unblock-File in powershell to disable the prompt after executing the  script. This didn't change the results.

    Monday, February 27, 2017 12:08 PM
  • It's not only on the whenCreated attribute but also for the EmployeeType atribute that returns an empty value for some users.
    Monday, February 27, 2017 12:35 PM
  • Some more testing. Seems I'm not retrieving the information for a lot of users

    On the DC:

    PS C:\> (Get-ADUser -LDAPFilter "(whenCreated=*)" | measure).Count
    8
    
    PS C:\> (Get-ADUser -LDAPFilter "(name=*)" | measure).Count
    53
    On the workstation:

    PS Z:\> (Get-ADUser -LDAPFilter "(whenCreated=*)" | measure).Count
    53
    
    PS Z:\> (Get-ADUser -LDAPFilter "(name=*)" | measure).Count
    53
    
    PS Z:\> 


    Monday, February 27, 2017 2:18 PM
  • Hi,

    Do you have another working DC in your environment? If yes, please have a try the same command on that DC and see if the same result is returned. If you do get different results, you may have a replication issue.

    Best regards,

    Wendy


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Thursday, March 2, 2017 2:24 AM
    Moderator
  • Actually, you can use the -Server parameter of Get-ADUser to target different DC's (as long as they are Windows Server 2008 R2 or above). No need to be at different computers. If you get different results targeting different DC's, then I suspect some kind of replication problem.

    In principal, just because you run a script on a DC doesn't necessarily mean you actually target the copy of AD on that machine. The only way to be sure is to use the -Server parameter.


    Richard Mueller - MVP Enterprise Mobility (Identity and Access)

    Thursday, March 2, 2017 3:04 AM
  • Hi Richard Wendy,

    Already tried that the day I posted this issue. It's not a replication issue. If I run the command elevated I do get the whencreated dates for all users.

    The thing is I don't want to execute the script elevated. In my opinion it's not required because any domain user can retrieve this information from there workstation without an elevated command.

    I was aware of the -server parameter that's the one I used in the previous test.

    We want to run this script on multiple domains at multiple customers. I've tested some of them and Windows 2008 domain controllers seem to do OK with running this command without an elevated prompt.


    • Edited by Rene5380 Thursday, March 2, 2017 11:54 AM
    Thursday, March 2, 2017 11:53 AM
  • Hi,

    Maybe, we could use process monitor or network monitor tool to capture some information when you run the script with and without an elevated prompt, and compare the difference to see what is causing the different behavior.

    Process Monitor v3.31 https://technet.microsoft.com/en-us/sysinternals/processmonitor.aspx

    Network monitor tool https://www.microsoft.com/en-sg/download/details.aspx?id=4865

    Best regards,

    Wendy


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Monday, March 6, 2017 2:03 AM
    Moderator
  • Process Monitor and Network Monitor cannot do this.  The issue is on AD and is a result of newer security restrictions, which, in this case, seem to not be working as expected.


    \_(ツ)_/

    Monday, March 6, 2017 2:32 AM
  • Hi all,

    Just found a workaround, but just once more the issue I'm seeing on my dc's

    When collecting extended attributes from your active directory not all values are collected. In my case it was the employeeType and the WhenCreated value. Some do return values and some don't.

    If you elevate the powershell command you will see all the values returned from the active directory.

    If you perform the same command from a workstation without an elevated command, all the values are returned.

    The problem is that somehow I'm not allowed to retrieve this values without an elevated prompt from the domain controller I'm running the command on.

    So in my case I have 2 domain controllers dc1 and dc2
    If I perform the following command on DC1 I will not get all the values from my domain controller.

    get-aduser -server DC1 -Filter * -Properties Name, WhenCreated | Select name, whenCreated

    The -server makes sure it's querying the DC1 domain controller (Where I also execute the command)

    Now if I perform the query on the DC2 from the DC1 I do retrieve all values
    So on the DC1 I perform the following command

    get-aduser -server DC2 -Filter * -Properties Name, WhenCreated | Select name, whenCreated

    The -server is now targeting the DC2 for it's query.

    When logging on to the DC2 I get the exact same results.

    My workaround is just make sure your not executing your query against the domain controller you're logged on/executing your script from: 

    $DomainController = (Get-ADGroupMember 'Domain Controllers' | Where {$_.name -ne $($env:computername)} | Select-Object Name -First 1 ).Name
    (get-aduser -Server $DomainController -LdapFilter "(whenCreated=*)" | measure).count
    Where {$_.name -ne $($env:computername)

    Selects all domain controllers except the one running your script on.

    Select-Object Name -First 1

    Makes sure you only get one domain controller and not the complete array.

    I still believe this shouldn't be necessary, that's why I call it a workaround. And I know there can be issues when one of your domain controllers is down for maintanance.

    And a one liner to check if all dc's are returning the same number of values. (This should be run on a DC to check if you have the same issue as me) If the dc's return the same number all is working fine and you don't have the issue I described in this thread. In a normal situation they should be equal.

    Get-ADGroupMember 'Domain Controllers' | ForEach{"$($_.Name): " + (get-aduser -Server $_.Name -LdapFilter "(whenCreated=*)" | measure).count}

    • Edited by Rene5380 Monday, March 6, 2017 2:42 PM
    • Proposed as answer by Wendy JiangModerator Wednesday, March 15, 2017 1:37 AM
    • Marked as answer by Rene5380 Monday, March 20, 2017 1:12 PM
    Monday, March 6, 2017 2:04 PM
  • If you only have one Domain controller, for now execute your command elevated or install the RSAT tools on a domain member and execute your command from there.
    Monday, March 6, 2017 2:07 PM
  • A partial explanation: whenCreated is not an extended property exposed by PowerShell. It is an Active Directory attribute. If you use a Get-AD* cmdlet with -Properties *, and retrieve more than one object, only the AD attributes you specify where the first object in the results has a value will be included. For example, if the first object retrieved has no value for the pager attribute, then none of the objects will include this attribute, even if the attribute has a value.

    That does not explain why you get values for some users and not for others. And even if the results are in a different order when you elevate, it doesn't help explain different results when you use admin credentials.

    Still, what happens when you specify the Created extended property instead. If I recall correctly, if you specify an extended property, you get all values for all users (that have values). Created is an extended property that retrieves the value of the whenCreated AD attribute.

    Edit: The more I think of it, being an attribute rather than an extended property does not explain. Still, it would be interesting to see if results are different if you specify Created.

    My explanation of the difference between default properties, extended properties, and AD attributes here:

    https://social.technet.microsoft.com/wiki/contents/articles/12031.active-directory-powershell-ad-module-properties.aspx


    Richard Mueller - MVP Enterprise Mobility (Identity and Access)


    Monday, March 6, 2017 3:34 PM
  • The same results Richard

    PS Z:\> (get-aduser -filter * -Properties created | Where {$_.Created -ne $null} | Select name, created).count
    8
    
    PS Z:\> (get-aduser -filter * -Properties created | Where {$_.Created -eq $null} | Select name, created).count
    52
    
    PS Z:\> (get-aduser -filter * -Properties created | Select name, created).count
    60

    Monday, March 6, 2017 3:44 PM
  • THe property is "whenCreated" and not "created"


    \_(ツ)_/

    Monday, March 6, 2017 6:02 PM
  • Both JRV ;-)
    Monday, March 6, 2017 6:56 PM
  • Hi,
    I am checking how the issue is going, if you still have questions, as the limitation in the forum, I would suggest you open up a case with Microsoft Technical Support to see if they could get another ideas about the problem: https://support.microsoft.com/en-us/contactus/?ws=support
    And if the replies as above are helpful, we would appreciate you to mark them as answers, and if you resolve it using your own solution, please share your experience and solution here. It will be greatly helpful to others who have the same question.
    Appreciate for your feedback.
    Best regards,
    Wendy

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Thursday, March 9, 2017 1:53 AM
    Moderator
  • Hi Wendy,

    Sorry for the late reply, The workaround I posted is working for me. It"s not the solution but it works for now.

    Let's hope we don"t have customers with only one domain controller.

    Thanks for all the suggestions and help

    Tuesday, March 14, 2017 7:33 AM
  • Hi,
    Great share and we appreciate that, if possible, could you please help to mark it as answers? As it will helps others who have the same problem to find the workaround clearly.
    Thank you again for the feedback.
    Best regards,
    Wendy

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Wednesday, March 15, 2017 1:39 AM
    Moderator