Forum Discussion
Active Directory Schema Attributes vs Version
Hi all,
i'm searching documentations about the attributes used in active directory schema based on its version.
My versions range is from "Windows 2008 R2" (v47) to "Windows 2019" (v88).
The target of my search is a document/wiki that i can use to check if an attribute exist in my versions range, or, if the usage change in some versions, to prevent exception when a software try to access to it.
At the moment, i find only this wiki: https://docs.microsoft.com/en-us/windows/win32/adschema/attributes-all
Here i can find all attributes vs schema version and the related information (data type, name, access, etc), but seems not cover the newer schema versions.
For example, if i want to check the attribute "department", i can go to the detailed description:
https://docs.microsoft.com/en-us/windows/win32/adschema/a-department
an see the implementation in older versions (typically the newer is windows server 2012).
Exist a list that include newer versions (from windows server 2012 r2 to 2019)?
Thanks for any info
Stefano
1 Reply
For application compatibility, I wouldn't hard-code assumptions such as “Windows Server 2019 means attribute X exists.”
The forest's schema version is stored in objectVersion on the schema container. For reference, Microsoft lists Server 2008 R2 as schema 47, Server 2016 as 87, Server 2019/2022 as 88 and Server 2025 as 91.
You can check the forest schema version with PowerShell:
$schema = (Get-ADRootDSE).schemaNamingContext
Get-ADObject $schema -Properties objectVersion |
Select-Object objectVersion
But for software, an even safer approach is to detect the attribute itself:
$schema = (Get-ADRootDSE).schemaNamingContext
Get-ADObject `
-SearchBase $schema `
-LDAPFilter '(lDAPDisplayName=department)'
The schema contains the authoritative definitions of the object classes and attributes available in that forest.
That approach also handles environments where the schema has been extended by Exchange or another product. Check capability directly rather than assuming availability only from the Windows Server version