8

Is it possible to define AD DS domain/forest functional levels from domain joined workstation? Preferably through CLI/PS and if possible w/o Domain Admin rights... How I can accomplish it?

5 Answers 5

11

The following Powershell does not require admin or domain admin access, I've tested as a limited user on a domain-joined workstation with Powershell v2/v3. It does not require any third party tools or Powershell modules.

$dse = ([ADSI] "LDAP://RootDSE")

# Domain Controller Functional Level
$dse.domainControllerFunctionality

# Domain Functional Level
$dse.domainFunctionality

# Forest Functional Level
$dse.forestFunctionality

The values returned will represent a distinct functional level:

Value  Forest        Domain             Domain Controller
0      2000          2000 Mixed/Native  2000
1      2003 Interim  2003 Interim       N/A
2      2003          2003               2003
3      2008          2008               2008
4      2008 R2       2008 R2            2008 R2
5      2012          2012               2012
6      2012 R2       2012 R2            2012 R2
7      2016          2016               2016

References:

3

Just a complementary solution to the accepted answer, as I ended up here more or less with the same need. The difference is one gets the level name decoded:

Import-Module ActiveDirectory
$ForestRoot = 'top.domain'

(get-adforest -identity $ForestRoot).ForestMode

(get-adforest -identity $ForestRoot).Domains |
ForEach-Object {Get-ADDomain -Identity $_ |
ft DNSRoot,DomainMode -AutoSize}
3
  • 1
    +1. Worth noting yours requires the Microsoft Powershell AD Module. The ADSI example does not.
    – jscott
    Jun 10, 2015 at 11:08
  • Right you are, editing it in..
    – ErikE
    Jun 10, 2015 at 11:09
  • Minor improvement. You don't actually need to include the -identity $ForestRoot portions of the get-adforest commands when you're running it from a machine joined to the forest you're trying to query. The cmdlet will just pick up the current machine's info. Jun 15, 2016 at 19:21
2

You just want to check it or actually change it? Changing it would require certain administrative rights on the domain/forest.

The easiest way I can think of without dsquery or PS Get-ADDomain (which would require importing the AD module) is to use Joeware's ADFIND command.

http://www.joeware.net/freetools/tools/adfind/

adfind -rootdse domaincontrollerfunctionality domainfunctionality forestfunctionality

Example output from my domain:

AdFind V01.47.00cpp Joe Richards ([email protected]) October 2012

Using server: DOMAIN-DC1.hahaha.local:389

Directory: Windows Server 2008 R2

dn:

domainFunctionality: 4 [Windows Server 2008 R2 Domain Mode]

forestFunctionality: 4 [Windows Server 2008 R2 Forest Mode]

domainControllerFunctionality: 4 [Windows Server 2008 R2 Mode]

1 Objects returned

1

For a GUI-based approach you can use Active Directory Explorer. Right-click on domain top node, click Properties and check the value of domainControllerFunctionality, domainFunctionality or forestFunctionality. They have integer values corresponding to:

0 = Win 2000
1 = Win 2003 mixed/interim
2 = Win 2003
3 = Win 2008
4 = Win 2008 R2
5 = Win 2012
6 = Win 2012 R2
7 = Win 2016

0

You need to ask this question a little differently, because I'm not sure what you are trying to do- The way this reads is that you want a powershell script or batch file that can perform extremely administrative tasks without running as a user that is able to perform those tasks. If that's what you are asking, it's not possible, by design.

However, if you are asking about administering AD from a workstation, by handing a user a script that can run commands the user otherwise would not be able to (i.e. you want to query AD from an unprivileged service account), we would need to know what version of Powershell you are using, and what version of Server you are using.

You might also consider AD web services for one-at-a-time tasks that you wish to delegate.

From a TechNet post: Run The below DSQUERY

Dsquery * CN=Partitions,CN=Configuration,DC=Mydomain,DC=com -scope base -attr msDS-Behavior-Version

Output: msDS-Behavior-Version 2

The attributes that indicates DFL and FFL: - Forest level setting

Name: msDS-Behavior-Version Path: CN=Partitions, CN=Configuration, DC=, DC=com

Value: 0 or not set=mixed level forest

1=Windows Server 2003 interim forest level 2=Windows Server 2003 forest level 3=Windows Server 2008 forest level

  • Domain level setting

Name: msDS-Behavior-Version Path: DC=, DC=, DC=com (domain root) Value: 0 or not set=mixed level domain

1=Windows Server 2003 domain level 2=Windows Server 2003 domain level 3=Windows Server 2008 domain level

  • Mixed/Native mode setting

Name: ntMixedDomain

Path: DC=, DC=, DC=com (domain root)

Value: 0=Native level domain 1=Mixed level domain

I'm not sure about the role requirements of the user to run this, but you're not changing anything with it and it's all using DSQUERY (From the RSAT, free download from Microsoft). Comment if we need to look at that end of it.

3
  • My question was for a situation when let's say member of IT department who not a domain admin needs quickly verify/double check domain/forest functional levels w/o bothering domain admins who should know than & have all appropriate consoles & tools to check it... Any quick & simply method would do for me
    – Mike
    May 31, 2013 at 13:42
  • 1
    I get that this question is an exercise in "how can this be done", but nevertheless I can't think of a single scenario where an IT team member who doesn't have the appropriate rights would need to do this in the course of their job.
    – joeqwerty
    May 31, 2013 at 14:02
  • I worked at a large firm, and this kind of information would be useful at such a company. Here's an example: your location has a domain with aging DC's and you need to implement a feature of a newer FL to fulfill a ticket request. You may not be chummy with the already overburdened domain admin. To make the case for needed upgrades, you have to put together the process, which is purely research so you can get the change request together- this is an ITIL requirement. This would be very useful in such a situation. May 31, 2013 at 14:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .