Carl Webster Accessibility Statement

Carl Webster is committed to facilitating the accessibility and usability of its website, carlwebster.com, for everyone. Carl Webster aims to comply with all applicable standards, including the World Wide Web Consortium’s Web Content Accessibility Guidelines 2.0 up to Level AA (WCAG 2.0 AA). Carl Webster is proud of the efforts that we have completed and that are in-progress to ensure that our website is accessible to everyone.

If you experience any difficulty in accessing any part of this website, please feel free to email us at info@carlwebster.com and we will work with you to provide the information or service you seek through an alternate communication method that is accessible for you consistent with applicable law (for example, through telephone support).

  • Running the Active Directory Documentation Script in a Multiple Domain Forest

    August 19, 2016

    Active Directory, Blog, PowerShell

    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







    About Carl Webster

    Webster is a Sr. Solutions Architect for Choice Solutions, LLC and specializes in Citrix, Active Directory and Technical Documentation. Webster has been working with Citrix products for many years starting with Multi-User OS/2 in 1990.

    View all posts by Carl Webster

    3 Responses to “Running the Active Directory Documentation Script in a Multiple Domain Forest”

    1. Sam Says:

      Hi,
      First, thank you for all scripts !
      I ran this script in a forest with parent and two children (Windows 2008 R2 Sp1) with powershell v5.0 and unfortunately there is the same information in the report for the parent domain and the two children; for example, in “Users – Password not changed in last 12 months”, in the parent domain, there is the same accounts that for children domain; maybe I forgot parameters ?

      Reply

    2. Kevin Giertz Says:

      Hi,

      We have one primary domain “mycompany.org” and two child domains “adm.mycompany.org, adm.mycompany.org”. We meet all the requirements but still get errors when the script tries to retrive data:

      WARNING: Error retrieving domain data for domain mycompany.orgadm.mycompany.orgped.mycompany.org.

      As well with:
      “Error retrieving OU data” and “Error retrieving Group data”

      We are running the script as enterprise user on a winserver 2012 domain controller with word 2013 installed.

      We get the same error on different setups. Any ideas what the problem might be?

      Thanks
      //Kevin

      Reply

      • Carl Webster Says:

        There are issues with some of the AD cmdlets. I am trying to find a way to work around those issues. For some multi-domain Forests they work, but for others, not so much.

        Thanks

        Webster

        Reply

    Leave a Reply to Carl Webster