I have received numerous emails and comments from people having issues running the Active Directory (AD) documentation script in a forest that contains multiple domains. I finally got off my lazy rear end and took the time to figure out the issue and solution.

I created a forest with two domains for my testing.

• Webster.local
• Child1.Webster.local

The forest is at the 2012 R2 Forest Functional Level.

Running the script in a regular PowerShell session from the parent domain using an account with Enterprise Admin rights, I can get all the hardware, services, time server, AD files and DCDNSINFO for all domain controllers in all domains. As expected since Enterprise Admins have rights to all domains in a forest.

Running the script in a regular PowerShell session from the child domain using an account with Enterprise Admin rights, I can get all the hardware, services, time server, AD files and DCDNSINFO for all domain controllers in all domains. Again, as expected since Enterprise Admins have rights to all domains in a forest.

Running the script in a regular PowerShell session from the parent domain using an account with Domain Admin rights in the parent domain, I do not get all the hardware, services, time server, AD files and DCDNSINFO for all domain controllers in both domains. I don’t even get the information from the domain I have Domain Admin rights. This is stated in the help text:

.PARAMETER Hardware

Use WMI to gather hardware information on: Computer System, Disks, Processor and Network Interface Cards

Will be used on Domain Controllers only.

This parameter requires the script be run from an elevated PowerShell session

using an account with permission to retrieve hardware information (i.e. Domain Admin).

Selecting this parameter will add to both the time it takes to run the script and size of the report.

This parameter is disabled by default.

Running the script in an elevated PowerShell session from the parent domain using an account with Domain Admin rights, I can get all the hardware, services, time server, AD files and DCDNSINFO for the domain controllers in the parent domain. I do get all the other AD information in the report for all domains.

Running the script in the child domain exposed a bug in the Get-ADDomainController cmdlet. In V2.0 of the script, I am working around that bug so the script will run. Running the script in the child domain with an account with child domain domain admin rights, I do not get all the hardware, services, time server, AD files and DCDNSINFO for the domain controllers in the parent domain. I do get that information for the domain controllers in the child domain. I do get all the other AD information in the report for all domains.

Version 2.0 of the script is almost complete. It adds gathering information on Time Server and AD database, logfile and SYSVOL locations. Those require access to the registry on each domain controller. Gathering that information means the script must be run from an elevated PowerShell session with an account with a minimum of domain admin rights. I have changed the 2.0 script to only process those two sections if the user has domain admin rights.

Bottom Line:

• Always run the script from an elevated PowerShell session.
• For the script to work properly in a forest with multiple domains requires Enterprise Admin rights.

I have added this information to the help text of both versions of the AD documentation scripts.

What I will try my best to do in version 2.1 of the script is find a way to allow the script to run for a specific domain and not force the entire forest to be processed.

Thanks

Webster