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

• Edited by Tim-KGS 14 hours 46 minutes ago add test note

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.as

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 13 hours 14 minutes ago

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.

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

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?

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 pro

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. 

It works fine for me on WS2012R2.

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. 

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!

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.

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.

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.

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.

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.

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