Collecting AD information using PowerShell

Collect Active Directory information by PowerShell.

??? The discovery is often scheduled to come to the site to get information about the infrastructure environment, and the customer's maintainer sometimes does not know what information to help collect. In the words of Wei Xiaobao, we have to work out what to do and what to win. So see if there's any way to collect some information without people on the spot.

??? After writing a section of PowerShell to collect the Exchange architecture, I felt it necessary to collect more ad information because Exchange was very dependent on ad. So try adding some ad scripts. In general, understanding the situation of ad can be divided into several parts: forest and domain conditions, site and subnet scenarios, replication scenarios, inter-domain trusts, and organizational units.

• Forest and Domain

??? The forest is collected primarily by the name of the forest, the root domain, the functional level, the host role, and information such as the containing site.

??? The situation of collecting domain mainly requires domain name, function level, host role and other information.

??? Get five host roles and use two commands.

Get-ADForest |fl RootDomain,ForestMode,DomainNamingMaster,SchemaMaster
Get-ADDomain |fl Name,DomainMode,InfrastructureMaster,RIDMaster,PDCemulator

??? Of course, the information for each domain controller is also required.

??? It's a bit messy, so just look at the name, domain, OS version (plus build number), and the site you're on.

??? Of course, you can follow the site or other to remember the number.

• Sites and subnets

??? The understanding of sites and subnets is often one of the starting points for optimizing ad usage, such as slow logon and frequent errors. Instead of using the default Get-adsite command directly, there is no association between the site and the subnet we want.

??? Therefore, a tricky operation is required. Use Get-adobject to directly query the desired AD object.

??? For example, in order to view the site and associated subnets, we can filter the object type from the ad configuration directly to the ad object of site, and then view the subnet information recorded in the object.

?? I believe that anyone who writes for the first time must be a little confused, even if you are an old ad driver. Okay, let's take out the ad artifact Adexplorer. This was the tool that the great God Mark had done many years ago, and I walked from youth to greasy old ...

??? Find the site we want to collect information, click on the Site object, you can see, in fact, it contains the subnet information, the information in the attribute siteobjectbl, so you can use a specific filtering, the information from a vast network of ad information filtered out.

??? The wording of the filter is ' objectclass–eq ' site ', in order to avoid searching the entire ad, we add the initial search location, that is ' cn=configuration,dc=contoso,dc=com '. The name of the DC is modified according to the actual domain name.

???? I found the result is not very pleasing to the eye, so I changed from the subnet to display the corresponding site. It's certainly not a problem. Write the filter as ' objectclass–eq ' subnet ', and then collect the attribute siteobject:

Get-ADObject -Filter ‘objectClass -eq "subnet"‘ –SearchBase ‘CN=Configuration,DC=contoso,DC=Com‘? -Properties siteObject | FT Name,siteObject

??? Site link, a simple PowerShell will be done. You can use FORMATLIST/FL to make the output look fresher.

• AD Replication

Get-adreplicationconnection

Get-adreplicationsite

Get-adreplicationsitelink

Get-adreplicationsitelinkbridge

Get-adreplicationsubnet

Get-adreplicationfailure

??? The test environment is a DC, let it go.

• Trust relationships

Get-adtrust

?? The test environment is not long-range, put it first.

• Organizational unit

??? Remember more than 10 years ago, with a VB Script plus recursive query ou ... Typically, when you get an initial look at ad information, you rarely collect information about OUs, users, groups, and so on, because the number is too large. If you need to collect it, of course, there is no way.

??? First, with the complex, on Adobject, use the filter only to show that the type is an object of the organizational unit. So we got a list of all the OUs.

??? The same, the direct use of simple get-adorganizationalunit, the same can be achieved consistent results.

Get-ADObject -Filter ‘objectclass -eq "organizationalunit"‘ –SearchBase ‘DC=contoso,DC=Com‘ |fl DistinguishedName
Get-ADOrganizationalUnit -Filter * |fl DistinguishedName

• Other

??? In theory, the information needed in AD can be obtained by Get-adobject. Just need to think ahead of time to use what kind of filter, extract what object properties.

??? I think of the previous deployment of the system Center Configuration Manager architecture, you need to confirm a container under the ad's system. It was difficult to describe the ad in the past, so most of it needed to be viewed by hand. Now it's easy.

??? For example, we need to confirm that there are no cn=rpcservices containers under Cn=system, just a single command.

Get-ADObject -Filter ‘cn -eq "rpcservices"‘ –SearchBase ‘CN=System,DC=contoso,DC=Com‘

??? For further information on how to use Get-adobject, you can refer to: Https://docs.microsoft.com/en-us/powershell/module/addsadministration/get-adobject

???? The use syntax for filters is consistent with PowerShell:

??? Therefore, you can use wildcard characters to get multiple results ~

Collecting AD information using PowerShell