Shulou(Shulou.com)06/02 Report--

Collect Active Directory information by PowerShell.

It is found that it is often impossible to arrange to go to the site to obtain information about the infrastructure environment, and the customer's maintenance staff sometimes do not know what information to help collect. In the words of trinket, we have to decide what to do and what to win. So we need to see if there is a way to collect some information without people on the scene.

After writing a paragraph to collect the PowerShell of the Exchange architecture, because Exchange is very dependent on AD, I feel the need to gather more information about AD. So try to add some AD scripts. In general, understanding AD can be divided into several parts: forest and domain, site and subnet, replication, inter-domain trust, and organizational units.

Forest and domain

Collecting the situation of the forest mainly requires the forest name, root domain, functional level, host role and contains the site and other information.

Collecting domain information mainly requires domain name, functional level, host role and other information.

Get five host roles with two commands.

Get-ADForest | fl RootDomain,ForestMode,DomainNamingMaster,SchemaMaster

Get-ADDomain | fl Name,DomainMode,InfrastructureMaster,RIDMaster,PDCemulator

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

It's a bit messy, so just look at the name, domain, operating system version (or you can add Build Number), and site.

Of course, you can count by site or something else.

Sites and subnets

Understanding of sites and subnets is often one of the starting points for optimizing AD use, such as slow login and frequent errors. Using the default Get-ADSite command directly, there is no relationship between the site and the subnet we want.

Therefore, a skillful operation is needed. Using Get-ADObject, query the desired AD object directly.

For example, to view sites and associated subnets, we can filter the AD object whose object type is Site directly from the AD configuration, and then look at the subnet information recorded in this object.

I'm sure anyone must be a little confused when they write it for the first time, even if you're an old AD driver. It doesn't matter. Let's take out AD's artifact, ADExplorer. This is the tool made by the great god Mark many years ago, and it accompanied me from youth to greasy old age.

Find the site where we want to collect information, click on the site object, and we can see that it actually contains subnet information, which is in the attribute siteObjectBL, so we can use specific filtering to filter out this information from the vast amount of AD information.

The filter is written as' objectClass-eq "site'. To avoid searching the entire AD, we add the starting search location, that is, 'CN=Configuration,DC=contoso,DC=com'. The name of DC can be modified according to the actual domain name.

I found that the result was not very pleasing to the eye, so I showed the corresponding site from the subnet instead. Of course, there is no problem with this. 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

If you link to the site, a simple PowerShell will be done. You can use FormatList/fl to make the output look refreshing.

AD replication

Get-ADReplicationConnection

Get-ADReplicationSite

Get-ADReplicationSiteLink

Get-ADReplicationSiteLinkBridge

Get-ADReplicationSubnet

Get-ADReplicationFailure

There is only one DC in the test environment. Leave it first.

Trust relationship

Get-ADTrust

The test environment is not multi-domain for the time being, so leave it.

Organizational unit

Think of more than ten years ago, using VB script plus recursive query OU. Usually, when you get an initial understanding of AD information, it is rare to collect OU, users, groups, and other information right away, because the number is too large. If you need to collect, of course, it is not impossible.

First use the complex, ADObject, and use the filter to display only objects of type Organizational Unit. So we got a list of all the OU.

Similarly, you can get consistent results by using a simple Get-ADOrganizationalUnit directly.

Get-ADObject-Filter 'objectclass-eq "organizationalunit"'-SearchBase 'DC=contoso,DC=Com' | fl DistinguishedName

Get-ADOrganizationalUnit-Filter * | other fl DistinguishedName

In theory, all the information needed in AD can be obtained through Get-ADObject. You just need to figure out in advance what kind of filter to use and what kind of object attributes to extract.

I remember that when I deployed the System Center Configuration Manager architecture in the past, I needed to confirm a container under AD's System. In the past, it is difficult to describe with those who do not know AD, so most of them need to use tools to check it out. It's easy now.

For example, we can confirm whether there is a container for CN=RpcServices under CN=System with a simple command.

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

For further information on how to use Get-ADObject, please refer to: https://docs.microsoft.com/en-us/powershell/module/addsadministration/get-adobject

The syntax for using filters is the same as PowerShell:

Therefore, you can use wildcards to get multiple results ~

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.