none
Different results on the DC RRS feed

  • General discussion

  • Hello

    I created a script and tested it from my workstation, only to find that some expected return values no longer worked when running it on the DC.

    The values that come up missing are EmployeeID and EmployeeNumber (employeeType doesn't work properly either, but I am not interested in it for this script).  To test, I went to Powershell and ran commands individually.

    I am running as a service account, so did my testing as that service account from both my workstation and the DC.  The script and the manual commands all work on the workstation and fail on the DC.

    First to run in the context of the service account:
    Start-Process powershell.exe -Credential "Domain\ServiceAccount"

    This opens a new window where I enter the command that I am having issues with:
    Get-ADUser Bob.Smith -Properties * | fl Name,Employee*

    On the workstation (and on a member server), it returns:
    Name        :  Bob Smith
    EmployeeID    :  123456
    EmployeeNumber    :  987643
    EmployeeType    :  Employee

    On the DC, it returns (NOTE - employeeType doesn't return at all):
    Name        :  Bob Smith
    EmployeeID    :  
    EmployeeNumber    :  

    Any ideas are appreciated!

    Thanks

    UPDATE NOTE:  I also tested on a member server and the results are the same as the workstation, so the issue appears to be isolated to the DC
    Friday, August 28, 2015 4:16 PM

All replies

  • Only default properties are exposed by Get-ADUser, unless you specify others with the -Properties parameter. Both EmployeeID and EmployeeNumber are extended properties, so they must be requested with -Properties. The employeeType attribute is not a property, so it also must be requested with the -Properties parameter in order to be retrieved.

    Edit: The concepts of default and extended properties, and attributes, and the -Properties parameter, are documented in this Wiki: http://social.technet.microsoft.com/wiki/contents/articles/12031.active-directory-powershell-ad-module-properties.aspx


    Richard Mueller - MVP Directory Services


    Friday, August 28, 2015 5:52 PM
    Moderator
  • Exactly why I used "-Properties *" in the command.  Same command works fine on member servers and my workstation, just not on the DC.

    • Edited by Tim-KGS Friday, August 28, 2015 5:57 PM
    Friday, August 28, 2015 5:57 PM
  • Sorry, I missed that you used -Properties *. If you specify -Properties *, the Get-AD* cmdlets that support this parameter will retrieve all default and extended attributes, whether or not they have values, plus all Active Directory attributes that have values. That might explain your problems with employeeType.

    The only explanation I can think of for the different results on different clients is that they retrieve from a different DC and there are replication problems.


    Richard Mueller - MVP Directory Services

    Friday, August 28, 2015 6:07 PM
    Moderator
  • It works fine for me on AD 2008R2 and later.  It won't work on a WS2003 server.

    "EmployeeType" will only display if it actually exists.

    PS C:\scripts> Get-ADUser testuser01 -Properties * | fl Name,Employee*
    
    
    Name           : Test User01
    EmployeeID     :
    EmployeeNumber :
    employeeType   : staff
    
    
    


    \_(ツ)_/

    Friday, August 28, 2015 6:08 PM
  • Here is the result of an account with no employeeType set.

    PS C:\scripts> Get-ADUser jsmith -Properties * | fl Name,Employee*
    
    
    Name           : JSmith
    EmployeeID     :
    EmployeeNumber :
    

    Note that all settings are blank and that employeeType is missing.

    This cannot be due to replication but may have to do with problems with one or more DCs.  Perhaps the net framework is not up to date or is damaged.

    What version of the  running and what DC versions?


    \_(ツ)_/

    Friday, August 28, 2015 6:14 PM
  • Sorry, I missed that you used -Properties *. If you specify -Properties *, the Get-AD* cmdlets that support this parameter will retrieve all default and extended attributes, whether or not they have values, plus all Active Directory attributes that have values. That might explain your problems with employeeType.

    The only explanation I can think of for the different results on different clients is that they retrieve from a different DC and there are replication problems.


    Richard Mueller - MVP Directory Services

    No problem.  I ran the Get-ADUser command with the "-server" parameter as well and confirmed results were identical when querying all DCs. 

    Friday, August 28, 2015 6:17 PM
  • All DC are 2012 R2 consistent (baselined) builds and up to date.

    Running with the "-server" parameter against all DCs from the member server or workstation yield consistent and successful results. 

    Friday, August 28, 2015 6:20 PM
  • It works fine for me on WS2012R2.


    \_(ツ)_/

    Friday, August 28, 2015 6:33 PM
  • If these are upgrades and not new installs then you may be missing schema updates.  Did someone do a partial WS2003 to WS2012 migration. 

    I can think of no reason why a 2012 DC would behave this way.  I just tested on a brand new 2012 AD server in anew domain.  (VM) and it works exactly as above. 


    \_(ツ)_/

    Friday, August 28, 2015 6:40 PM
  • All servers are fresh builds (no upgrades).  Schema is up to date.  Replication looks good.
    Friday, August 28, 2015 6:42 PM
  • I just repeated this command sequence on all DCs.  In every case it fails to get results. 

    Then I tested with the "-Server" parameter on all DCs and it works as long as you reference a DC that you are not running the script from. 

    Example - Run on DC-A with "-Server DC-A" fails, but with "-Server DC-B" or "-Server DC-C" works fine.  Same holds true executing from B or C.

    So I have a workaround, that is likely not as efficent as running on the same system the script is executing from.  Not ideal, but functional.

    I would still like to figure out why this is happening.

    Thanks!

    Friday, August 28, 2015 7:06 PM
  • In all cases you are running PowerShell directly by clicking on the icon.  You should not run with credentials or run elevated. 

    If this still does not work look at the permissions on those attributes.  If nothing is out of place then you need to contact MS support to get guidance.


    \_(ツ)_/

    Friday, August 28, 2015 7:13 PM
  • To start, that is correct.  I just run powershell - no right-click options. 

    After that window opens though, I run "Start-Process powershell.exe -Credential "Domain\ServiceAccount" " in order to open a Powershell window as the service account to run commands.  This is necessary to ensure that my script running as the service account get's the same results that testing yields.

    Based on my findings in my last post, I updated my script to force it to read from a DC that the script is NOT running on and it works.  Again, not ideal to query over the network instead of the host that it is running on.

    Friday, August 28, 2015 7:17 PM
  • Don't use alternate credentials.  You need to log in as an admin and just run PowerShell and call the CmdLets.

    If you are running as a service account  then you will not likely  have correct permissions to view all items and you don't want to make the service account a full AD admin either.

    If AD is working correctly then grant the service account Access to the employee items.  They are protected. 

    YOU may want to contact MS support to get a clearer explanation of why the difference.  You can also post in the Directory Services forum for a more comprehensive explanation.


    \_(ツ)_/

    Friday, August 28, 2015 7:23 PM
  • I'm using the same process to test from other servers and workstations.  The service account has adequate permissions to query the objects since it works from everywhere else.

    Testing a script with my credentials is not a valid test since I am not going to set up the script to use my credentials.  I have a service account for this purpose intentionally so the account has permissions limited to only what it needs.

    The query just won't return the extended attributes on the same DC that you run it from.  It returns them for all alternate DC, and when run on a member server or workstation, it returns them when run against every DC.  All using the service account.

    Friday, August 28, 2015 7:30 PM
  • Yes.  I understand that.  I still recommend posting in the Directory Services forum as this is clearly not a scripting issue. It is a behavior of using a service account which is an account with no profile or interactive user. My guess is that you need to set it to be trusted for delegation but that is a guess without a clear reason behind it.


    \_(ツ)_/

    Friday, August 28, 2015 7:44 PM
  • If you are creating service accounts you might be interested in this: http://blogs.technet.com/b/askpfeplat/archive/2012/12/17/windows-server-2012-group-managed-service-accounts.aspx


    \_(ツ)_/

    Friday, August 28, 2015 7:50 PM