How to Report Active Directory Schema Changes Using PowerShell

Changes to the Active Directory (AD) schema can result in operational problems. In general, the schema shouldn’t change. But if a new application is installed that relies on Active Directory, like Microsoft Exchange Server, then the schema must be updated to support the application. To protect the integrity of AD, it’s worth checking that only approved changes to the schema are made.

Using PowerShell, it’s easy to generate a report of AD schema changes. But before you run the code in this article, install the PowerShell module for Windows Server Active Directory. The Active Directory PowerShell module is installed on domain controllers (DC) by default. But it is best practice to perform everyday administration tasks from a domain-joined Windows 10 PC.

Install the Windows Server Active Directory PowerShell module

The AD PowerShell module is part of the Remote Server Administration Tools (RSAT) for Active Directory Domain Services. To install the RSAT AD tools, open a PowerShell prompt with local administrator privileges and run the following command:
PowerShell

Once the tools have installed, you can close the elevated PowerShell window. To run the rest of the commands in this article, you need only be logged in to Windows 10 with an account that’s a member of the Active Directory ‘Domain Users’ group.

For more information on installing RSAT in Windows 10, see How to Install the Remote Server Administration Tools in Windows 10 on Petri.

Report AD schema changes using PowerShell

Using the Get-ADObject cmdlet, we can display schema changes. But first we need to provide Get-ADObject with a search base, or in other words, an area of the directory to search. We want to search the schema, so we need to know our directory’s schema naming context. Luckily, that’s easy to retrieve using the Get-ADRootDSE cmdlet. If you run Get-ADRootDSE without any parameters, you will see the path for the directory’s schemaNamingContext in the output.Image #Expand 

PowerShell makes it easy to pull out any property, like schemaNamingContext, by using a period and parentheses as shown below:
PowerShell

We can use the above code as the value for the -SearchBase parameter in the Get-ADObject cmdlet. But there are a couple of other parameters we need to add. -SearchScope should be set to OneLevel, which searches the immediate child objects of the path provided in the -SearchBase parameter. A wildcard, *, is used as the value of the -Filter parameter to return everything.

Finally, we use the -Properties parameter to specify the properties we want returned as part of the output. As you can see, I’m going to pull out the objectClass, name, whenChanged, and whenCreated properties.
PowerShell

We want to group the data returned by date. To do that, we need the whencreated date without the time information. We can use the Select-Object cmdlet and a calculated property to create a new object with the data we need in the right format. In the expanded command below, you can see I have piped the object generated by Get-ADObject to the Select-Object cmdlet. @ indicates a calculated property, which has a label, ‘Event’, and an expression that returns just the date from the whenCreated property in short form.
PowerShell

Next, we’re going to pipe the object created by Select-Object to Sort-Object. And have it sort the object data by the whenCreated property.
PowerShell

Finally, let’s pipe the object to the Format-Table cmdlet. It will display the properties in a table, grouped by Event, that we created using the Select-Object cmdlet.
PowerShell

Image #Expand 

PowerShell

If we run all the code together, we will see schema changes listed in the command prompt window. In my directory, Exchange Server was installed, so we can see lots of changes to the schema.

Reference: https://petri.com/how-to-report-active-directory-schema-changes-using-powershell