Despite Active Directory having been around for more than 10 years, I still find new implementations proceeding without directory service access auditing enabled.  For me, auditing of who does what, where and when in your directory is crucial information.  I can’t fully fathom why Microsoft doesn’t have it enabled with some sensible defaults out of the box, but maybe that’s just me.  If you download and install Microsoft’s Security Compliance Manager 3.0, the Domain Controller baseline contains good auditing defaults.  Anyway, here is a quick “how to” guide for enabling basic directory service access auditing in Windows Server 2012 R2 Active Directory.

Getting auditing going is done in two key steps.

1. Configuring Group Policy with the appropriate auditing settings
2. Configuring the System Access Control List (SACL) at the appropriate level(s) in the directory

Ok, let’s get started with the first item (Group Policy).  For this, you will need a GPO linked to the Domain Controllers OU.  You can either use the Default Domain Controllers Policy or create a new one specifically for auditing.  My preference is to leave the DDCP at its defaults and create a new GPO with the settings.

Before the days of granular auditing settings you would configure your directory service access auditing under:

Computer Configuration->Policies->Windows Settings->Security Settings->Local Policies->Audit Policy

These settings belong to the dark days of pre-Windows Server 2008 when only the 9 auditing categories were available.  You don’t want to use this setting.  Instead you want to use the more granular auditing sub-categories introduced first in Windows Server 2008.

The first thing you need to do is enforce the use of the sub-categories in case someone unwittingly turns on the legacy auditing mentioned above.  To do this, enable the following setting:

Computer Configuration->Policies->Windows Settings->Security Settings->Local Policies->Security Options->Audit: Force audit policy subcategory settings….[it goes on a bit, but you get the picture]

Now we need to enable auditing for the specific sub-categories we are interested in.  To do this go to:

Computer Configuration->Policies->Windows Settings->Security Settings->Advanced Audit Policy Configuration->Audit Policies->DS Access

… and enable Audit Directory Service Access.  I would also enable Audit Directory Service Changes as that can provide you with complementary audit events, including before and after information for changed attribute values (really very useful).  Success and Failure?  Perhaps, but unless you have firm requirements to capture failure events then  just choosing Success can save the reduce the number of events generated.

Right, remember to link your new GPO to the Domain Controllers OU and that’s it for the GPO side of things.  You might be thinking that’s all you need to do, but unless you’ve done part 2 you won’t see the required events generated.

Now you might be interested in just certain parts of your directory, but if you don’t have an obvious place to begin, consider turning on audit records from the top of your domain partition.   To do this, open the Active Directory Administrative Centre (dsac).  Yes, yes, you could use dsa.msc or adsiedit.msc too.

Right-click the top of the domain tree (“contoso” in my case) and bring up the properties.  Under Extensions you will see the Security tab.  From there select Advanced and then choose the Auditing tab.  If you want to be comprehensive, I would select the Everyone security principal, set Type to Success and Applies to: This object and all descendant objects.  For the permissions, again if you want to be comprehensive, set the following:

• Write all properties
• Delete
• Delete subtree
• Modify permissions
• Modify owner
• All validated writes
• All extended writes
• Create all child objects
• Delete all child objects

Once you have applied the changes you’re pretty much ready to go.  You should now start to see comprehensive directory access events as well as the before and after values for changed objects.

One thing you might not be aware of is that there was a bug in the RTM version of Windows Server 2012 R2 which meant that the directory service change information events did not get captured.  Of course, by now you will have your R2 servers fully patched, but just in case you are still running RTM be aware that you will need the download from KB2887595 for the change information to be available.

Bear in mind that, if you have a lot of auditing going on in your security logs on your DCs, the events are going to be overwritten pretty regularly even if you beef up the size of your security event log.  As part of defining your audit strategy you should work out your requirements for storing key events.  There are a number of ways to do that, including leveraging some kind of centralised audit collection system (or SIEM), but that’s beyond the scope of this article.

I had an interesting one recently when submitting a certificate request to a Windows Certificate Authority using certreq.exe.  The error that came back was:

The disposition message is “Error Parsing Request The request subject name is invalid or too long. 0×80094001 (-2146877439)”

I found several links to possible solutions but, as it turns out, the problem in my case was the subject name (specified an X.500 DistinguishedName) was too long.  It seems that the CA limits the subject name field to 64 characters.  Mine was around 80 characters, which is not unusual for a DN.

The workaround is to remove the 64 character limit by running the following command:

certutil -setreg ca\EnforceX500NameLengths 0

The CA service needs to be restarted after running the command.

The Microsoft TechNet article that provides more detail can be found here.

When you install a new version of Exchange or apply a Cumulative Update certain AD attributes are updated to reflect the change.  The updates are made in three different directory partitions (also known as naming contexts): Schema, Configuration and Domain.  The following Microsoft TechNet article is a good reference for the different versions and the corresponding attribute values.

http://technet.microsoft.com/en-us/library/bb125224(v=exchg.150).aspx

You can check the values manually….or you could do it the easy way with Powershell.  Here’s a Powershell sample to give you values across the three partitions (assumes a single domain forest):

# Exchange Schema Version
$sc = (Get-ADRootDSE).SchemaNamingContext
$ob = "CN=ms-Exch-Schema-Version-Pt," + $sc
(Get-ADObject $ob -pr rangeUpper).rangeUpper

# Exchange Object Version (forest)
$cc = (Get-ADRootDSE).ConfigurationNamingContext
$fl = "(objectClass=msExchOrganizationContainer)"
(Get-ADObject -LDAPFilter $fl -SearchBase $cc -pr objectVersion).objectVersion

# Exchange Object Version (domain) - assumes single domain forest
$dc = (Get-ADRootDSE).DefaultNamingContext
$ob = "CN=Microsoft Exchange System Objects," + $dc
(Get-ADObject $ob -pr objectVersion).objectVersion

The output will looking something similar to screenshot shown below (showing the values for Exchange Server 2013 CU5):

There was in interesting discussion the other day on the ActiveDir.org mailing list. Someone asked how many values can be stored within the proxyAddresses mutlivalued attribute in Active Directory. The responses were reasonably consistent, with most people indicating that in Windows 2000 the number was in the range of approximately 800 to 850 and from Windows 2000 the range is approximately 1200 to 1300.

This begs the question of why we can’t be specific about the number. Well, it comes down to how the data is stored within the Active Directory database (ntds.dit). Most of the attribute data for an individual object is stored within a single row in the Data Table within the database. I say “most” because linked attribute data (e.g. member/memberof, manager/directReports, etc.) is kept in a separate table (the Link Table). The AD schema determines how many attributes are available for a particular object and this obviously varies a lot from forest to forest, as does which of those possible attributes actually have populated values. There are also some overhead requirements that vary. All this combines to make it impossible to determine with any accuracy how many values an individual multivalued, nonlinked attribute can have.

Because I have an enquiring mind (some would say “nosey bastard”), I decided to try and hit the limit in my test lab. I did this by running a Powershell script to keep adding SMTP addresses to the proxyAddresses attribute for a user until an exception was thrown. I got to 1192 before I got the “The administrative limit for this request was exceeded” error (see below).

As Don Hacherl (former dev lead for AD at Microsoft) pointed out to me on the mailing list, the non-linked attribute limit is a limit across all non-linked attributes on the object. So for example, if I had added a telephone number before running the script then I would have only got to 1191 values on proxyAddresses.

Don also made is clear that under normal circumstances you shouldn’t need to be anywhere near the limit. In his words…

“The limit is supposed to be high enough that the only time you’ll hit it is when you have made an architectural error in your schema usage. Asking questions about the exact number of a limit that you have not yet hit is often a warning sign of your burning desire to make an architectural error in the future.”

I found a Powershell script on Experts Exchange that seemed to be useful for detecting errant objects that have a high number of values within an individual multivalued attribute. I’ve hacked with it a bit and have ensured that it now excludes linked values. Here it is for anyone that is interested.

#########################################################
#
# Name: Find-BloatedObjects.ps1
# Author: Tony Murray
# Version: 1.0
# Date: 18/09/2014
# Comment: PowerShell 2.0 script to
# find objects with an unusually large number of values
# within a non-linked multi-valued attribute
# Credit: Parts of the script are from a solution posted by 
# footech on Experts Exchange here:
# http://tinyurl.com/md3cvzn
#
#########################################################

Import-Module ActiveDirectory
$queryCount = 1000 # adjust this if you need to
$snc = (Get-ADRootDSE).SchemaNamingContext
$dnc = (Get-ADRootDSE).DefaultNamingContext
$def = "Microsoft.ActiveDirectory.Management.ADPropertyValueCollection*"
$objs = Get-ADObject -Filter * -Properties * -SearchBase $dnc

ForEach ($obj in $objs) {
    #Write-Output "Looking at object $obj.distinguishedname"
    $ADOprops = $obj | gm -MemberType Property `
    | Where { $_.Definition -like $def } `
    | Select -ExpandProperty Name
        foreach ($prop in $ADOprops) {
            #Write-Output "Looking at property $prop"
            $fl = "(&(objectclass=attributeschema)(ldapdisplayname=$prop))"
            $linked = (Get-ADObject -LDAPFilter $fl -SearchBase $snc -pr linkid).linkid
            #Write-Output $linked
            If (($linked -eq $null) -and (($obj.$prop).count -gt $queryCount)) {
                Write-Output "----------------------------------------------"
                Write-Output "AD Object ""$($obj.DistinguishedName)"""
                Write-Output "has attribute ""$prop"" with a count of $($obj.$prop.count)"
            } # end if
        } # end foreach
} # end foreach

Feedback is, as always, very welcome!

If you haven’t heard that extended support for Windows XP ended earlier this year you’ve clearly been in a coma.  There are a number of well-publicised methods for finding out whether you still have XP machines in your environment.  Here is my own humble (and spectacularly over engineered) Powershell offering.

#########################################################
#
# Name: Find-XPStillActive.ps1
# Author: Tony Murray
# Version: 1.0
# Date: 23/09/2014
# Comment: PowerShell 2.0 script to find active
# Windows XP computer accounts
#
#########################################################

## Define global variables
# Export file for storing results
$expfile = "c:\xp_still_active.csv"
# Define the header row for the CSV (we will create our own)
$header = "`"name`",`"os`",`"sp`",`"lastlogondate`""
# Consider any account logged on in the last x days to be active
$days = 60
$Today = Get-date
$SubtractDays = New-Object System.TimeSpan $days, 0, 0, 0, 0
$StartDate = $Today.Subtract($SubtractDays)
$startdate = $startdate.ToFiletime()
# LDAP filter settings
$filter = "(&(lastlogontimestamp>=$startDate)(operatingsystem=Windows XP*))"

## Functions
Function Format-ShortDate ($fdate)
{
        if ($fdate) {
            $day = $fdate.day
            $month = $fdate.month
            $year = $fdate.year
            "$day/$month/$year"
        } # end if

} # end function

## Start doing things
# Import the AD module
ipmo ActiveDirectory
# Tidy up any previous copies of the export file 
if (test-path $expfile) {Remove-Item $expfile}
# Add the header row to the export file
Add-Content -Value $header -Path $expfile
# Create an array of computer objects
$active = Get-ADComputer -LDAPFilter $filter -pr *
# loop through the array
foreach ($xp in $active) {
    # Grab the attribute values we need from the AD object
    $nm = $xp.name
    $os = $xp.operatingsystem
    $sp = $xp.operatingsystemservicepack
    $lt = Format-ShortDate $($xp.lastlogondate)
    $row = "`"$nm`",`"$os`",`"$sp`",`"$lt`""
    # Commit the row to the export file
    Add-Content -Value $row -Path $expfile
} # end foreach

## End script

Enjoy!

It’s sometimes interesting to know how old your AD forest is and when the various domains were created.  I recently came across a really useful TechNet Blog with a Powershell snippet to do just this.  My version shown below just has some slightly different formatting.

# How old is the forest?
Get-ADObject -SearchBase (Get-ADForest).PartitionsContainer `
-LDAPFilter "(&(objectClass=crossRef)(systemFlags=3))" `
-pr dnsRoot, nETBIOSName, whenCreated | Sort whenCreated `
| select @{e={($_.DNSRoot)};l=”DomainFQDN”}, `
nETBIOSName, @{e={(get-date $_.whencreated -format dd/MM/yyyy)};l=”whenCreated”} `
| ft -AutoSize

The output should look something like this:

So how old is your forest?

A question came up in the forums today about how to use the AD Powershell cmdlets to find objects with attribute values that contain a single space. It’s a good question and relevant because often your results can be skewed by such values when searching for attributes that are not NULL (a space character is not a NULL). Anyway, here’s an example of how to do it using the LDAPFilter.

Get-ADUser -LDAPFilter "(telephonenumber=\20)"

The “\” is the standard escape character for use in LDAP searches and “20″ is the HEX representation of the space character.

The filter should also work with other LDAP clients (e.g. LDP.EXE).

I came across a weird error the other day while running Exchange Server 2013 CU6 setup with the /PrepareAD switch.  The error (from the Exchange setup logs) was this:

[12/02/2014 01:14:16.0727] [2] [ERROR] Could not find the Exchange Mailbox Administrators Universal Security Group through its well-known GUID 29a962c2-91d6-4ab7-9e06-8728f8f842ea.  Please make sure that Setup /prepareAD has been run.

I sat there scratching my head for a while because what (wtf?) is the Exchange Mailbox Administrators group and what does it have to do with Exchange 2013.  Anyway, after a journey of discovery, here’s what I found out.

For some time, Exchange has used an attribute named otherWellKnownObjects on the Exchange container in the Configuration partition of AD to store information about the location of certain Exchange objects, including the default groups.  One of these entries corresponds to the Organization Management group (as shown below).

The strange-looking string next to the DN for the Organization Management group (C262A929D691B74A9E068728F8F842EA) is a Hex representation of a GUID.  To get to the string representation I found a handy function called Convert-OctetStringToGuid.  The result was as follows:

The resulting GUID string (29a962c2-91d6-4ab7-9e06-8728f8f842ea) matches that shown in the original error.  So, basically the setup error was saying that it couldn’t find the Organization Management group.  The guff about the Exchange Mailbox Administrators group must be a legacy piece of code referencing an earlier version.  Once I had the new information I had a look to see if the group actually existed (it did).  I then concluded that maybe AD replication hadn’t finished by the time setup got to looking for the group.  I then made the executive decision to run setup with the /PrepareAD switch again.  Lo and behold it finished successfully.

I thought this write-up might help if you find yourself in the same boat.

Another quick one to finish the year off.  Here’s a script that runs an LDAP query against all of the DCs in the forest and reports back the time it has taken for each.  The intention is to identify any DCs that are responding slowly for some reason.  In the example below, I’ve chosen to run my query against the schema partition as this will be consistent across all DCs in the forest, regardless of domain.  If you have a single domain forest, you might want to change this for a really inefficient query against something in the domain partition.

The script uses WinRM to query each DC directly.  I did it that way to remove network latency as an influence on the response timings.  If you don’t have all Windows Server 2012 (or later) DCs then you will need to explicitly enable WinRM to allow the script to talk to the DCs.

#########################################################
#
# Name: Get-LDAPSearchTimings.ps1
# Author: Tony Murray
# Version: 1.0
# Date: 29/11/2014
# Comment: PowerShell script to
# obtain LDAP search times from all DCs in the forest
#
#########################################################

Import-Module ActiveDirectory # Imports the AD module (if required)

$domains = (Get-ADForest).domains
$dcs = @()
foreach ($domain in $domains){
    [string]$ddc = (Get-ADDomainController -DomainName $domain -Discover).hostname
    $ddcs = Get-ADDomainController -Filter * -Server $ddc
    foreach ($srv in $ddcs) {
       $name = $srv.hostname
       $dcs += $name
    } # end foreach
} # end foreach

foreach ($DC in $DCs) {
    $sc = {
        ipmo ActiveDirectory
        $sb = (Get-ADRootDSE).schemaNamingContext
        #$sb = (Get-ADRootDSE).DefaultNamingContext
        $fl = "(adminDescription=*name*)"
        #$fl = "(title=*manager*)"
        $ex = {Get-ADObject -LDAPFilter $fl -searchbase $sb -server localhost}
        (Measure-Command -Ex $ex).TotalSeconds
    } # end script block
    $mc = Invoke-Command -ComputerName $DC -ScriptBlock $sc
    write-host "Search took $mc seconds on $DC in AD Site $((get-addomaincontroller $dc -server $dc).site)"
} # end foreach

The output should look something like this:

I recently had a interesting issue where I was seeing the 1121 error below in the Application log on one of my Exchange 2013 servers every minute.

Log Name: Application

Source: MSExchange Mailbox Replication

Date: 14/01/2015 2:23:34 p.m.

Event ID: 1121

Task Category: Request

Level: Error

Keywords: Classic

User: N/A

Computer: ex1.contoso.com

Description:

The Microsoft Exchange Mailbox Replication service was unable to process a request due to an unexpected error.

Request GUID: '60b5375b-0f27-4561-a0f2-af428dd3c501'

Database GUID: '43ce3977-2c7f-4c6a-937b-b94966c81122'

Error: An Active Directory Constraint Violation error occurred on dc1.contoso.com. Additional information: The name reference is invalid.

This may be caused by replication latency between Active Directory domain controllers.

Active directory response: 000020B5: AtrErr: DSID-03152CB1, #1:

0: 000020B5: DSID-03152CB1, problem 1005 (CONSTRAINT_ATT_TYPE), data 0, Att 9fc1287c (msExchMailboxMoveSourceMDBLink)

--> A value in the request is invalid..

The reference to “msExchMailboxMoveSourceMDBLink” was the only indication the error related to a mailbox move request. Frustratingly, no requests showed up from running Get-MoveRequest.

After some ineffective troubleshooting I eventually found the solution from Exchange MVP Jeff Guillet. The error message he shows in his article is different to mine, but the fix is the same.

I had to run the following command:

Remove-MoveRequest -MoveRequestQueue '43ce3977-2c7f-4c6a-937b-b94966c81122' -MailboxGuid '60b5375b-0f27-4561-a0f2-af428dd3c501'

I still don’t know the cause of the problem, but I have a suspicion it followed a reverse mailbox move from Exchange 2013 (CU6) to Exchange 2007 (SP3 RU13).

Hopefully this helps if you ever come across the same issue.

There are well known methods for setting Access Control Entries (ACEs) on Active Directory objects using Powershell. One example is the following:

http://blogs.msdn.com/b/adpowershell/archive/2009/10/13/add-object-specific-aces-using-active-directory-powershell.aspx

The method relies on you knowing the schemaIDGUID of the schema object classes you are working with (e.g. User, Computer, Group). Unless you know your way around AD it’s not always immediately obvious where to find the schemaIDGUIDs that you need. To help you with this, I’ve thrown to gether a couple of powershell snippets.

# Find schemaIDGuids for all object classes and write to screen
$snc = (Get-ADRootDSE).schemanamingcontext
$fil = "(objectclass=classschema)"
$objs = Get-ADObject -LDAPFilter $fil -pr ldapdisplayname, schemaidguid -SearchBase $snc `
| select ldapdisplayname, schemaidguid | Sort-Object ldapdisplayname
foreach ($obj in $objs) {
    [System.Guid]$sguid = $obj.schemaidguid
    Write-Output "$($obj.ldapdisplayname),$sguid"
} # end foreach

# Find schemaIDGuids for all object classes and write to CSV
$csv = "C:\schemaidguids.csv"
$snc = (Get-ADRootDSE).schemanamingcontext
$fil = "(objectclass=classschema)"
$objs = Get-ADObject -LDAPFilter $fil -pr ldapdisplayname, schemaidguid -SearchBase $snc `
| select ldapdisplayname, @{e={[System.Guid]$_.schemaIDGUID};l="schemaIDGUID"} `
| Sort-Object ldapdisplayname `
| Export-Csv $csv -NoTypeInformation

I’ve also included a dump of the schemaIDGUIDs for a typical AD environment that also has Microsoft Exchange 2013.

ldapdisplayname,schemaIDGUID

account,2628a46a-a6ad-4ae0-b854-2b12d9fe6f9e

aCSPolicy,7f561288-5301-11d1-a9c5-0000f80367c1

aCSResourceLimits,2e899b04-2834-11d3-91d4-0000f87a57d4

aCSSubnet,7f561289-5301-11d1-a9c5-0000f80367c1

addIn,a8df74aa-c5ea-11d1-bbcb-0080c76670c0

addressBookContainer,3e74f60f-3e73-11d1-a9c0-0000f80367c1

addressTemplate,5fd4250a-1262-11d0-a060-00aa006c33ed

addrType,a8df74ab-c5ea-11d1-bbcb-0080c76670c0

adminExtension,a8df74ac-c5ea-11d1-bbcb-0080c76670c0

applicationEntity,3fdfee4f-47f4-11d1-a9c3-0000f80367c1

applicationProcess,5fd4250b-1262-11d0-a060-00aa006c33ed

applicationSettings,f780acc1-56f0-11d1-a9c6-0000f80367c1

applicationSiteSettings,19195a5c-6da0-11d0-afd3-00c04fd930c9

applicationVersion,ddc790ac-af4d-442a-8f0f-a1d4caa7dd92

attributeSchema,bf967a80-0de6-11d0-a285-00aa003049e2

bootableDevice,4bcb2477-4bb3-4545-a9fc-fb66e136b435

builtinDomain,bf967a81-0de6-11d0-a285-00aa003049e2

categoryRegistration,7d6c0e9d-7e20-11d0-afd6-00c04fd930c9

certificationAuthority,3fdfee50-47f4-11d1-a9c3-0000f80367c1

classRegistration,bf967a82-0de6-11d0-a285-00aa003049e2

classSchema,bf967a83-0de6-11d0-a285-00aa003049e2

classStore,bf967a84-0de6-11d0-a285-00aa003049e2

comConnectionPoint,bf967a85-0de6-11d0-a285-00aa003049e2

computer,bf967a86-0de6-11d0-a285-00aa003049e2

configuration,bf967a87-0de6-11d0-a285-00aa003049e2

connectionPoint,5cb41ecf-0e4c-11d0-a286-00aa003049e2

contact,5cb41ed0-0e4c-11d0-a286-00aa003049e2

container,bf967a8b-0de6-11d0-a285-00aa003049e2

controlAccessRight,8297931e-86d3-11d0-afda-00c04fd930c9

country,bf967a8c-0de6-11d0-a285-00aa003049e2

cRLDistributionPoint,167758ca-47f3-11d1-a9c3-0000f80367c1

crossRef,bf967a8d-0de6-11d0-a285-00aa003049e2

crossRefContainer,ef9e60e0-56f7-11d1-a9c6-0000f80367c1

device,bf967a8e-0de6-11d0-a285-00aa003049e2

dfsConfiguration,8447f9f2-1027-11d0-a05f-00aa006c33ed

dHCPClass,963d2756-48be-11d1-a9c3-0000f80367c1

displaySpecifier,e0fa1e8a-9b45-11d0-afdd-00c04fd930c9

displayTemplate,5fd4250c-1262-11d0-a060-00aa006c33ed

dMD,bf967a8f-0de6-11d0-a285-00aa003049e2

dnsNode,e0fa1e8c-9b45-11d0-afdd-00c04fd930c9

dnsZone,e0fa1e8b-9b45-11d0-afdd-00c04fd930c9

document,39bad96d-c2d6-4baf-88ab-7e4207600117

documentSeries,7a2be07c-302f-4b96-bc90-0795d66885f8

domain,19195a5a-6da0-11d0-afd3-00c04fd930c9

domainDNS,19195a5b-6da0-11d0-afd3-00c04fd930c9

domainPolicy,bf967a99-0de6-11d0-a285-00aa003049e2

domainRelatedObject,8bfd2d3d-efda-4549-852c-f85e137aedc6

dSA,3fdfee52-47f4-11d1-a9c3-0000f80367c1

dSUISettings,09b10f14-6f93-11d2-9905-0000f87a57d4

dXASiteServer,a8df74b0-c5ea-11d1-bbcb-0080c76670c0

dXRequestor,a8df74ae-c5ea-11d1-bbcb-0080c76670c0

dXServerConn,a8df74af-c5ea-11d1-bbcb-0080c76670c0

dynamicObject,66d51249-3355-4c1f-b24e-81f252aca23b

encryptionCfg,a8df74b1-c5ea-11d1-bbcb-0080c76670c0

exchangeAdminService,a8df74b2-c5ea-11d1-bbcb-0080c76670c0

fileLinkTracking,dd712229-10e4-11d0-a05f-00aa006c33ed

fileLinkTrackingEntry,8e4eb2ed-4712-11d0-a1a0-00c04fd930c9

foreignSecurityPrincipal,89e31c12-8530-11d0-afda-00c04fd930c9

friendlyCountry,c498f152-dc6b-474a-9f52-7cdba3d7d351

fTDfs,8447f9f3-1027-11d0-a05f-00aa006c33ed

group,bf967a9c-0de6-11d0-a285-00aa003049e2

groupOfNames,bf967a9d-0de6-11d0-a285-00aa003049e2

groupOfUniqueNames,0310a911-93a3-4e21-a7a3-55d85ab2c48b

groupPolicyContainer,f30e3bc2-9ff0-11d1-b603-0000f80367c1

ieee802Device,a699e529-a637-4b7d-a0fb-5dc466a0b8a7

indexServerCatalog,7bfdcb8a-4807-11d1-a9c3-0000f80367c1

inetOrgPerson,4828cc14-1437-45bc-9b07-ad6f015e5f28

infrastructureUpdate,2df90d89-009f-11d2-aa4c-00c04fd7d83a

intellimirrorGroup,07383086-91df-11d1-aebc-0000f80367c1

intellimirrorSCP,07383085-91df-11d1-aebc-0000f80367c1

interSiteTransport,26d97376-6070-11d1-a9c6-0000f80367c1

interSiteTransportContainer,26d97375-6070-11d1-a9c6-0000f80367c1

ipHost,ab911646-8827-4f95-8780-5a8f008eb68f

ipNetwork,d95836c3-143e-43fb-992a-b057f1ecadf9

ipProtocol,9c2dcbd2-fbf0-4dc7-ace0-8356dcd0f013

ipsecBase,b40ff825-427a-11d1-a9c2-0000f80367c1

ipsecFilter,b40ff826-427a-11d1-a9c2-0000f80367c1

ipsecISAKMPPolicy,b40ff828-427a-11d1-a9c2-0000f80367c1

ipsecNegotiationPolicy,b40ff827-427a-11d1-a9c2-0000f80367c1

ipsecNFA,b40ff829-427a-11d1-a9c2-0000f80367c1

ipsecPolicy,b7b13121-b82e-11d0-afee-0000f80367c1

ipService,2517fadf-fa97-48ad-9de6-79ac5721f864

leaf,bf967a9e-0de6-11d0-a285-00aa003049e2

licensingSiteSettings,1be8f17d-a9ff-11d0-afe2-00c04fd930c9

linkTrackObjectMoveTable,ddac0cf5-af8f-11d0-afeb-00c04fd930c9

linkTrackOMTEntry,ddac0cf7-af8f-11d0-afeb-00c04fd930c9

linkTrackVolEntry,ddac0cf6-af8f-11d0-afeb-00c04fd930c9

linkTrackVolumeTable,ddac0cf4-af8f-11d0-afeb-00c04fd930c9

localDXA,a8df74b5-c5ea-11d1-bbcb-0080c76670c0

locality,bf967aa0-0de6-11d0-a285-00aa003049e2

lostAndFound,52ab8671-5709-11d1-a9c6-0000f80367c1

mailConnector,a8df74b6-c5ea-11d1-bbcb-0080c76670c0

mailGateway,a8df74b7-c5ea-11d1-bbcb-0080c76670c0

mailRecipient,bf967aa1-0de6-11d0-a285-00aa003049e2

meeting,11b6cc94-48c4-11d1-a9c3-0000f80367c1

mHSLinkMonitoringConfig,a8df74b9-c5ea-11d1-bbcb-0080c76670c0

mHSMonitoringConfig,a8df74bb-c5ea-11d1-bbcb-0080c76670c0

mHSServerMonitoringConfig,a8df74bd-c5ea-11d1-bbcb-0080c76670c0

msAuthz-CentralAccessPolicies,555c21c3-a136-455a-9397-796bbd358e25

msAuthz-CentralAccessPolicy,a5679cb0-6f9d-432c-8b75-1e3e834f02aa

msAuthz-CentralAccessRule,5b4a06dc-251c-4edb-8813-0bdd71327226

msAuthz-CentralAccessRules,99bb1b7a-606d-4f8b-800e-e15be554ca8d

msCOM-Partition,c9010e74-4e58-49f7-8a89-5e3e2340fcf8

msCOM-PartitionSet,250464ab-c417-497a-975a-9e0d459a7ca1

msDFS-DeletedLinkv2,25173408-04ca-40e8-865e-3f9ce9bf1bd3

msDFS-Linkv2,7769fb7a-1159-4e96-9ccd-68bc487073eb

msDFS-NamespaceAnchor,da73a085-6e64-4d61-b064-015d04164795

msDFS-Namespacev2,21cb8628-f3c3-4bbf-bff6-060b2d8f299a

msDFSR-Connection,e58f972e-64b5-46ef-8d8b-bbc3e1897eab

msDFSR-Content,64759b35-d3a1-42e4-b5f1-a3de162109b3

msDFSR-ContentSet,4937f40d-a6dc-4d48-97ca-06e5fbfd3f16

msDFSR-GlobalSettings,7b35dbad-b3ec-486a-aad4-2fec9d6ea6f6

msDFSR-LocalSettings,fa85c591-197f-477e-83bd-ea5a43df2239

msDFSR-Member,4229c897-c211-437c-a5ae-dbf705b696e5

msDFSR-ReplicationGroup,1c332fe0-0c2a-4f32-afca-23c5e45a9e77

msDFSR-Subscriber,e11505d7-92c4-43e7-bf5c-295832ffc896

msDFSR-Subscription,67212414-7bcc-4609-87e0-088dad8abdee

msDFSR-Topology,04828aa9-6e42-4e80-b962-e2fe00754d17

msDNS-ServerSettings,ef2fc3ed-6e18-415b-99e4-3114a8cb124b

msDS-App-Configuration,90df3c3e-1854-4455-a5d7-cad40d56657a

msDS-AppData,9e67d761-e327-4d55-bc95-682f875e2f8e

msDS-AuthNPolicies,3a9adf5d-7b97-4f7e-abb4-e5b55c1c06b4

msDS-AuthNPolicy,ab6a1156-4dc7-40f5-9180-8e4ce42fe5cd

msDS-AuthNPolicySilo,f9f0461e-697d-4689-9299-37e61d617b0d

msDS-AuthNPolicySilos,d2b1470a-8f84-491e-a752-b401ee00fe5c

msDS-AzAdminManager,cfee1051-5f28-4bae-a863-5d0cc18a8ed1

msDS-AzApplication,ddf8de9b-cba5-4e12-842e-28d8b66f75ec

msDS-AzOperation,860abe37-9a9b-4fa4-b3d2-b8ace5df9ec5

msDS-AzRole,8213eac9-9d55-44dc-925c-e9a52b927644

msDS-AzScope,4feae054-ce55-47bb-860e-5b12063a51de

msDS-AzTask,1ed3a473-9b1b-418a-bfa0-3a37b95a5306

msDS-ClaimsTransformationPolicies,c8fca9b1-7d88-bb4f-827a-448927710762

msDS-ClaimsTransformationPolicyType,2eeb62b3-1373-fe45-8101-387f1676edc7

msDS-ClaimType,81a3857c-5469-4d8f-aae6-c27699762604

msDS-ClaimTypePropertyBase,b8442f58-c490-4487-8a9d-d80b883271ad

msDS-ClaimTypes,36093235-c715-4821-ab6a-b56fb2805a58

msDS-CloudExtensions,641e87a4-8326-4771-ba2d-c706df35e35a

msDS-Device,5df2b673-6d41-4774-b3e8-d52e8ee9ff99

msDS-DeviceContainer,7c9e8c58-901b-4ea8-b6ec-4eb9e9fc0e11

msDS-DeviceRegistrationService,96bc3a1a-e3d2-49d3-af11-7b0df79d67f5

msDS-DeviceRegistrationServiceContainer,310b55ce-3dcd-4392-a96d-c9e35397c24f

msDS-GroupManagedServiceAccount,7b8b558a-93a5-4af7-adca-c017e67f1057

msDS-ManagedServiceAccount,ce206244-5827-4a86-ba1c-1c0c386c1b64

msDS-OptionalFeature,44f00041-35af-468b-b20a-6ce8737c580b

msDS-PasswordSettings,3bcd9db8-f84b-451c-952f-6c52b81f9ec6

msDS-PasswordSettingsContainer,5b06b06a-4cf3-44c0-bd16-43bc10a987da

msDS-QuotaContainer,da83fc4f-076f-4aea-b4dc-8f4dab9b5993

msDS-QuotaControl,de91fc26-bd02-4b52-ae26-795999e96fc7

msDS-ResourceProperties,7a4a4584-b350-478f-acd6-b4b852d82cc0

msDS-ResourceProperty,5b283d5e-8404-4195-9339-8450188c501a

msDS-ResourcePropertyList,72e3d47a-b342-4d45-8f56-baff803cabf9

msDS-ValueType,e3c27fdf-b01d-4f4e-87e7-056eef0eb922

msExchAcceptedDomain,9d71afc6-2c40-4c23-8cd7-e55b7d3129bd

msExchAccountForest,57e05741-c9de-415e-a9b9-a4605f173d9e

msExchActiveDirectoryConnector,e605672c-a980-11d2-a9ff-00c04f8eedd8

msExchActiveSyncDevice,e8b2aff2-59a7-4eac-9a70-819adef701dd

msExchActiveSyncDeviceAutoblockThreshold,086f4013-017e-4183-acf0-2d3f5d6f3aac

msExchActiveSyncDevices,c975c901-6cea-4b6f-8319-d67f45449506

msExchAddressBookMailboxPolicy,b8bef5a3-c582-43f6-babd-f13e4f8fbb1b

msExchAddressingPolicy,e7211f02-a980-11d2-a9ff-00c04f8eedd8

msExchAddressListService,e6a2c260-a980-11d2-a9ff-00c04f8eedd8

msExchAddressListServiceContainer,b1fce95a-1d44-11d3-aa5e-00c04f8eedd8

msExchAddressRewriteConfiguration,5d0017d1-43d9-4a0e-8fbc-2adfc96c29bf

msExchAddressRewriteEntry,997f7363-a2c7-4464-9a75-220a8239ccdc

msExchAdminAuditLogConfig,8be04d21-0820-4263-a287-0e6006005729

msExchAdminGroup,e768a58e-a980-11d2-a9ff-00c04f8eedd8

msExchAdminGroupContainer,e7a44058-a980-11d2-a9ff-00c04f8eedd8

msExchAdminRole,e7f2edf2-a980-11d2-a9ff-00c04f8eedd8

msExchAdvancedSecurityContainer,8cc8fb0e-b09e-11d2-aa06-00c04f8eedd8

msExchAgent,39c9981c-2b54-48f5-ba1f-0fe2f5b3fd0f

msExchApprovalApplication,d7bd16b6-f72f-496c-85ad-f9a50acd2fe7

msExchApprovalApplicationContainer,edb4bf22-4062-49ca-87c9-02cff41f263f

msExchAuthAuthConfig,bc44fd3e-d5cd-4050-b67f-5d01faf5c5a7

msExchAuthAuthServer,42bcd677-ebf8-4f6a-a453-563bbcefc2f3

msExchAuthPartnerApplication,3a0d01d6-0e59-4f68-a3b5-2e162c900a9a

msExchAutoDiscoverConfig,7458633c-1d26-4a9d-a037-bcf12d50a18c

msExchAutoDiscoverVirtualDirectory,966540a1-75f7-4d27-ace9-3858b5dea688

msExchAvailabilityAddressSpace,2b02d9af-bd14-42d0-8f37-7aa5cd7beef9

msExchAvailabilityConfig,e676fec3-dcd0-4565-baea-e25d08698ac1

msExchAvailabilityForeignConnectorVirtualDirectory,63c3d4a1-f208-49d1-ad5e-ae733901229a

msExchBaseClass,d8782c34-46ca-11d3-aa72-00c04f8eedd8

msExchCalendarConnector,922180da-b09e-11d2-aa06-00c04f8eedd8

msExchccMailConnector,e85710b6-a980-11d2-a9ff-00c04f8eedd8

msExchCertificateInformation,e8977034-a980-11d2-a9ff-00c04f8eedd8

msExchChatBan,e8d0a8a4-a980-11d2-a9ff-00c04f8eedd8

msExchChatChannel,e902ba06-a980-11d2-a9ff-00c04f8eedd8

msExchChatNetwork,e934cb68-a980-11d2-a9ff-00c04f8eedd8

msExchChatProtocol,e9621816-a980-11d2-a9ff-00c04f8eedd8

msExchChatUserClass,e9a0153a-a980-11d2-a9ff-00c04f8eedd8

msExchChatVirtualNetwork,ea5ed15a-a980-11d2-a9ff-00c04f8eedd8

msExchClassificationEngineConfig,70b0d395-ce13-42f9-a629-cb849bd174e4

msExchClientAccessArray,f49844ac-d8be-4769-b78d-819321e1610d

msExchClientAccessArrayLegacy,d0e851e9-b4e9-4cdb-b51c-d1ed43a836ba

msExchCmdletExtensionAgent,985ff231-3e3c-4e58-84fb-93b6e6385e7c

msExchCoexistenceRelationship,26a50814-02a8-4124-a48b-2d80d885987d

msExchComputerPolicy,ed2c752c-a980-11d2-a9ff-00c04f8eedd8

msExchConferenceContainer,ed7fe77a-a980-11d2-a9ff-00c04f8eedd8

msExchConferenceSite,eddce330-a980-11d2-a9ff-00c04f8eedd8

msExchConfigSettings,3849cc38-1c78-4e1b-9779-d88d26933001

msExchConfigurationContainer,d03d6858-06f4-11d2-aa53-00c04fd7d83a

msExchConfigurationUnitContainer,d31a8bb6-32c1-4171-8a25-db5defe47682

msExchConnectionAgreement,ee64c93a-a980-11d2-a9ff-00c04f8eedd8

msExchConnector,89652316-b09e-11d2-aa06-00c04f8eedd8

msExchConnectors,eee325dc-a980-11d2-a9ff-00c04f8eedd8

msExchContainer,006c91da-a981-11d2-a9ff-00c04f8eedd8

msExchContentConfigContainer,ab3a1acc-1df5-11d3-aa5e-00c04f8eedd8

msExchControlPointConfig,86dc8dbb-44b7-42a6-855a-a0ccbd247840

msExchControlPointTrustedPublishingDomain,7e942425-f793-4f86-8f5a-a44da9ad161f

msExchCountryList,e7810ab0-dd8d-425c-ba7f-9caa7cc5e435

msExchCTP,00aa8efe-a981-11d2-a9ff-00c04f8eedd8

msExchCustomAttributes,00e629c8-a981-11d2-a9ff-00c04f8eedd8

msExchDataClassificationConfig,d34b0641-e473-4d00-9f89-31dc89d6273b

msExchDeliveryAgentConnector,5b57eaf0-7aed-426c-8696-506d1604b617

msExchDepartment,54933f08-f360-45e6-8732-d16e84622af7

msExchDeviceAccessRule,a0a10355-963d-456f-b797-61607c1cd865

msExchDomainContentConfig,ab3a1ad1-1df5-11d3-aa5e-00c04f8eedd8

msExchDSNMessage,cad3f52a-2888-4da9-9bcb-a335fca35c14

msExchDynamicDistributionList,018849b0-a981-11d2-a9ff-00c04f8eedd8

msExchECPVirtualDirectory,9880b0a7-2d9b-49cc-8d59-3ca836518632

msExchEdgeSyncConnector,9aa495d2-c938-4fdd-8e22-1acc552d3f6b

msExchEdgeSyncEHFConnector,f5b6201a-7a35-4522-b9f0-8790b1595478

msExchEdgeSyncMservConnector,6bfbb991-f11b-4a9f-b85e-6402e33f5390

msExchEdgeSyncServiceConfig,190e1bba-7bf3-4f6d-a93b-3a7f375c23d9

msExchELCContentSettings,bc3d75ac-f92d-40cd-a223-37b43b4232b8

msExchELCFolder,fdb7ddb7-8d54-4fa8-9728-33da6c89bfe4

msExchEncryptionVirtualDirectory,fdbe62ec-92c8-4a58-bbc1-247779ce9ee7

msExchExchangeAssistance,f689cfc2-b7a2-4297-908f-38b4ec1290a4

msExchExchangeServer,01a9aa9c-a981-11d2-a9ff-00c04f8eedd8

msExchExchangeServerPolicy,e497942f-1d42-11d3-aa5e-00c04f8eedd8

msExchExchangeServerRecipient,58b55fb8-ce43-4987-b313-bf94abd81db3

msExchExchangeTransportCfgContainer,3dd5ee65-b529-44cf-99be-64432c81c091

msExchExchangeTransportServer,53fecd2b-bf90-4b78-9944-d369acdba597

msExchFedOrgId,9cd6d525-22a7-4f7f-9d44-3d687f47cef9

msExchFedSharingRelationship,5b134627-ce78-4d08-b31b-974cde19831a

msExchFedTrust,294c5a23-d02c-41f4-ab29-183158ebc593

msExchGenericPolicy,e32977cd-1d31-11d3-aa5e-00c04f8eedd8

msExchGenericPolicyContainer,e32977c3-1d31-11d3-aa5e-00c04f8eedd8

msExchGroupWiseConnector,91eaaac4-b09e-11d2-aa06-00c04f8eedd8

msExchHostedConnectionFilterPolicy,eed2f792-b7ff-439f-a9a4-93312c24f36e

msExchHostedContentFilterConfig,7376d3dd-cc79-4294-8b2f-f23d31cefeaf

msExchHygieneConfiguration,5f602082-d127-4a11-958c-92cf3270838e

msExchIMFirewall,9f116ebe-284e-11d3-aa68-00c04f8eedd8

msExchIMGlobalSettingsContainer,9f116eb8-284e-11d3-aa68-00c04f8eedd8

msExchIMRecipient,028502f4-a981-11d2-a9ff-00c04f8eedd8

msExchInformationStore,031b371a-a981-11d2-a9ff-00c04f8eedd8

msExchIpConfContainer,99f5866d-12e8-11d3-aa58-00c04f8eedd8

msExchJournalingReconciliationRemoteAccount,22997db3-740c-46f3-a17a-7b999b4043b6

msExchKeyManagementServer,8ce334ec-b09e-11d2-aa06-00c04f8eedd8

msExchLoadBalancingSettings,4f43304a-2e38-4415-bc89-08999f4d9edc

msExchMailboxManagerPolicy,36f94fcc-ebbb-4a32-b721-1cae42b2dbab

msExchMailboxRecipientTemplate,79532694-6170-4d79-8444-76b1d2e10389

msExchMailflowPolicy,8927fb99-c485-489f-8d31-a8829b8916d2

msExchMailflowPolicyCollection,41b2bd81-3958-4db3-91f4-e86df50f208b

msExchMailStorage,03652000-a981-11d2-a9ff-00c04f8eedd8

msExchMalwareFilterConfig,665ba098-09dd-4693-8cc3-2001b864bc84

msExchMapiVirtualDirectory,905574c1-7d10-429e-9511-e14752c0d0f1

msExchMCU,038680ec-a981-11d2-a9ff-00c04f8eedd8

msExchMCUContainer,03aa4432-a981-11d2-a9ff-00c04f8eedd8

msExchMDB,03d069d2-a981-11d2-a9ff-00c04f8eedd8

msExchMDBAvailabilityGroup,899c4769-8da3-4248-bd69-a680b876c4d7

msExchMDBAvailabilityGroupConfiguration,458a094e-1eb4-4982-8594-da8b244f43bd

msExchMDBAvailabilityGroupContainer,3a7b0c31-b4e3-46be-a4d2-b843d16846f6

msExchMDBContainer,3573336c-92c4-4f5f-89b5-c369fe1e0285

msExchMDBCopy,4e2a3f96-f552-4d78-921c-e2890089c25e

msExchMessageClassification,a823c5e7-6bba-4d6c-802c-98756f2be468

msExchMessageDeliveryConfig,ab3a1ad7-1df5-11d3-aa5e-00c04f8eedd8

msExchMessageHygieneContentFilterConfig,b7850ff9-a975-4cc0-b358-b866293c42bc

msExchMessageHygieneIPAllowListConfig,a287133a-054a-4e8a-8e2e-c209c95ea24b

msExchMessageHygieneIPAllowListProvider,0a4e0d5a-ec87-4e80-8028-735ed0f7af4a

msExchMessageHygieneIPAllowListProviderConfig,8ece3e9c-053b-4ea4-b503-1db0cc35fcd5

msExchMessageHygieneIPBlockListConfig,3cf2e983-e82c-4d10-8d12-fdefa56c677d

msExchMessageHygieneIPBlockListProvider,37865f31-ac7b-4585-a9be-24deb5181be4

msExchMessageHygieneIPBlockListProviderConfig,f4fb3380-04bb-4288-b024-58a12f2a18bb

msExchMessageHygieneRecipientFilterConfig,fe67dad2-d83b-488a-b320-28a33ce5540e

msExchMessageHygieneSenderFilterConfig,710841fd-db7b-47b5-89d9-f56e02011ca2

msExchMessageHygieneSenderIDConfig,3019e5c5-2de3-4236-9ec2-85c2d21aeda0

msExchMobileMailboxPolicy,a29670e5-7e7d-4c51-8940-4b4563478746

msExchMobileMailboxSettings,e6fabf91-1a22-4bf5-bf2e-0307f461c205

msExchMobileVirtualDirectory,56ba85a5-ad5f-4f8a-b69c-039979afa366

msExchMonitoringOverride,febb8f2c-dcd3-40df-a30a-03dd3da23b33

msExchMonitorsContainer,03f68f72-a981-11d2-a9ff-00c04f8eedd8

msExchMRSRequest,e09bc177-5bd4-4ed0-b7a9-b8ceab904668

msExchMSOForwardSyncCookie,570b9266-bbb3-4fad-a712-d2e3fedc34dd

msExchMSOForwardSyncDivergence,d6754759-55ea-4a10-b8ec-09d4c2790398

msExchMSOSyncServiceInstance,e0ccd78b-1642-41cf-bc45-159c9f318b08

msExchMultiMediaUser,1529cf7a-2fdb-11d3-aa6d-00c04f8eedd8

msExchNotesConnector,04c85e62-a981-11d2-a9ff-00c04f8eedd8

msExchOAB,3686cdd4-a982-11d2-a9ff-00c04f8eedd8

msExchOABVirtualDirectory,457e0398-cafe-43fb-b128-23c9e9f47c20

msExchOmaCarrier,8712d34c-27e5-41b2-976e-482ad8c954e7

msExchOmaConfigurationContainer,db0f9abb-0770-4f09-ba64-7993d91517b7

msExchOmaConnector,4dc9d0b1-594c-407e-a7d2-426e6c20dabb

msExchOmaContainer,863dab20-fb40-43a4-a5e1-825b2071050f

msExchOmaDataSource,dda38a4d-972a-44a2-9244-0acb4b1d34d1

msExchOmaDeliveryProvider,cdbf130d-c7e2-4572-94b0-fc9be7eef953

msExchOmaDeviceCapability,df7af4df-f318-4e2c-ac43-be5b4894711c

msExchOmaDeviceType,ca7a8fb3-21d0-4ea7-af3f-d15c6df7c094

msExchOmaUser,36a0a976-dd8d-4aad-81fd-a1b5d4016ca8

msExchOnPremisesOrganization,301151ef-d1bc-4aec-8aed-2bda0208ae63

msExchOrganizationContainer,366a319c-a982-11d2-a9ff-00c04f8eedd8

msExchOrganizationSettings,c59f7641-e479-4ccc-9c2b-51fc9052bb77

msExchOrganizationUpgradePolicy,c0559396-f797-4ecf-9cd8-29fd1da1b221

msExchOVVMConnector,91ce0e8c-b09e-11d2-aa06-00c04f8eedd8

msExchOWAMailboxPolicy,1f6c0549-b502-4b25-b352-266ba6c28bff

msExchOWAVirtualDirectory,82281ff7-6780-46a6-ae51-17354e8d93fc

msExchPFTree,364d9564-a982-11d2-a9ff-00c04f8eedd8

msExchPoliciesContainer,3630f92c-a982-11d2-a9ff-00c04f8eedd8

msExchPolicyTipMessageConfig,840e7e7c-8990-4da4-b627-2fa69be5b12d

msExchPowerShellVirtualDirectory,a88e9d98-c724-4c8d-805c-4ab1a85012d6

msExchPrivateMDB,36145cf4-a982-11d2-a9ff-00c04f8eedd8

msExchPrivateMDBPolicy,35db2484-a982-11d2-a9ff-00c04f8eedd8

msExchPrivateMDBProxy,b8d47e54-4b78-11d3-aa75-00c04f8eedd8

msExchProtocolCfgExchangeRPCService,ed732f11-d343-436b-8146-d32b5e452f30

msExchProtocolCfgHTTPContainer,9432cae6-b09e-11d2-aa06-00c04f8eedd8

msExchProtocolCfgHTTPFilter,8c7588c0-b09e-11d2-aa06-00c04f8eedd8

msExchProtocolCfgHTTPFilters,8c58ec88-b09e-11d2-aa06-00c04f8eedd8

msExchProtocolCfgHTTPVirtualDirectory,8c3c5050-b09e-11d2-aa06-00c04f8eedd8

msExchProtocolCfgIM,9f116ea7-284e-11d3-aa68-00c04f8eedd8

msExchProtocolCfgIMAPContainer,93da93e4-b09e-11d2-aa06-00c04f8eedd8

msExchProtocolCfgIMAPPolicy,35f7c0bc-a982-11d2-a9ff-00c04f8eedd8

msExchProtocolCfgIMAPSessions,99f58672-12e8-11d3-aa58-00c04f8eedd8

msExchProtocolCfgIMContainer,9f116ea3-284e-11d3-aa68-00c04f8eedd8

msExchProtocolCfgIMVirtualServer,9f116eb4-284e-11d3-aa68-00c04f8eedd8

msExchProtocolCfgNNTPContainer,94162eae-b09e-11d2-aa06-00c04f8eedd8

msExchProtocolCfgPOPContainer,93f99276-b09e-11d2-aa06-00c04f8eedd8

msExchProtocolCfgPOPPolicy,35be884c-a982-11d2-a9ff-00c04f8eedd8

msExchProtocolCfgPOPSessions,99f58676-12e8-11d3-aa58-00c04f8eedd8

msExchProtocolCfgProtocolContainer,90f2b634-b09e-11d2-aa06-00c04f8eedd8

msExchProtocolCfgSharedContainer,939ef91a-b09e-11d2-aa06-00c04f8eedd8

msExchProtocolCfgSIPContainer,7d3bcef5-6500-43cb-b11e-901e033ee7e1

msExchProtocolCfgSIPFEServer,b71b377f-3a7f-4fef-b21a-21ad53d98aaa

msExchProtocolCfgSMTPContainer,93bb9552-b09e-11d2-aa06-00c04f8eedd8

msExchProtocolCfgSMTPIPAddress,8b7b31d6-b09e-11d2-aa06-00c04f8eedd8

msExchProtocolCfgSMTPIPAddressContainer,8b2c843c-b09e-11d2-aa06-00c04f8eedd8

msExchProtocolCfgSMTPPolicy,359f89ba-a982-11d2-a9ff-00c04f8eedd8

msExchProvisioningPolicy,ca98e17d-b310-4d2a-ad9b-6b6221bcd6ba

msExchPseudoPF,cec4472b-22ae-11d3-aa62-00c04f8eedd8

msExchPseudoPFAdmin,9ae2fa1b-22b0-11d3-aa62-00c04f8eedd8

msExchPublicFolderTreeContainer,3582ed82-a982-11d2-a9ff-00c04f8eedd8

msExchPublicMDB,3568b3a4-a982-11d2-a9ff-00c04f8eedd8

msExchPublicMDBPolicy,354c176c-a982-11d2-a9ff-00c04f8eedd8

msExchPushNotificationsApp,42233db6-bea0-48f7-a4c7-b0770d5867bd

msExchPushNotificationsVirtualDirectory,445cfa0d-1370-469c-ae61-58f88d298e4d

msExchRBACPolicy,fa366e2a-6dc4-4931-9d2c-67906572378a

msExchRecipientEnforcementPolicy,f2d5d087-25e1-4b6d-8cc5-ca4a79bf39fc

msExchRecipientPolicy,e32977d8-1d31-11d3-aa5e-00c04f8eedd8

msExchRecipientPolicyContainer,e32977d2-1d31-11d3-aa5e-00c04f8eedd8

msExchRecipientTemplate,05377276-3f2a-4c7a-90d6-10da53e84a62

msExchRecipientTemplatePolicy,6e22acae-365c-4eba-aecc-805297a3f4aa

msExchReconciliationConfig,a6fe99a2-d249-4ca0-beed-28444c9bf224

msExchReplicationConnector,99f58682-12e8-11d3-aa58-00c04f8eedd8

msExchReplicationConnectorContainer,99f5867e-12e8-11d3-aa58-00c04f8eedd8

msExchResourcePolicy,8e071e72-9add-43e6-8e71-3bb059fec7ac

msExchResourceSchema,ad49d311-957c-43cd-b7cd-d005a868abee

msExchRole,1e2f82d7-28c4-479d-9d9f-b9f2e83f726c

msExchRoleAssignment,fce12c55-74e8-4227-80e0-7ae4805b4cd2

msExchRoutingGroup,35154156-a982-11d2-a9ff-00c04f8eedd8

msExchRoutingGroupConnector,899e5b86-b09e-11d2-aa06-00c04f8eedd8

msExchRoutingGroupContainer,34de6b40-a982-11d2-a9ff-00c04f8eedd8

msExchRoutingSMTPConnector,89baf7be-b09e-11d2-aa06-00c04f8eedd8

msExchRpcHttpVirtualDirectory,a5783da9-38f0-4f51-8ed7-d5bd9bfb0fde

msExchSchedulePlusConnector,b1fce946-1d44-11d3-aa5e-00c04f8eedd8

msExchSchemaMapPolicy,348af8f2-a982-11d2-a9ff-00c04f8eedd8

msExchScope,ef339a27-be18-41ca-8436-194716ab7e34

msExchSenderHintConfig,ee1a0b43-0e30-4455-abc5-8b6e2d48e244

msExchSenderReputation,66a31681-cf58-41a8-a725-8361b9e806be

msExchServersContainer,346e5cba-a982-11d2-a9ff-00c04f8eedd8

msExchSharingPolicy,d7cf53c4-7313-49c1-88cd-9db9bf729720

msExchSiteReplicationService,99f5867b-12e8-11d3-aa58-00c04f8eedd8

msExchSmtpConnectionTurfList,7eea7de9-319e-408a-8460-e35e2c9da389

msExchSmtpConnectionTurfListRule,6abadfad-e2f6-4ddb-9820-0da9c47da32c

msExchSMTPInboundConnector,d09c20c9-962a-419e-a574-b344eff9077d

msExchSMTPOutboundConnector,16a83d39-a90d-4a30-8856-13c98eb630e2

msExchSmtpReceiveConnector,44601346-776a-46e7-b4a4-2472e1c66806

msExchSMTPTurfList,0b836da5-3b20-11d3-aa6f-00c04f8eedd8

msExchSNADSConnector,91b17254-b09e-11d2-aa06-00c04f8eedd8

msExchStorageGroup,3435244a-a982-11d2-a9ff-00c04f8eedd8

msExchSyncAccountsPolicy,cf75eb66-d980-46bc-86b5-f0574e383fd4

msExchSyncDaemonArbitrationConfig,3b8bf1d2-affe-4b22-8780-56fd04886641

msExchSystemMailbox,9cf1aa93-b31c-4725-9d50-ab7ab1d3ca1e

msExchSystemObjectsContainer,0bffa04c-7d8e-44cd-968a-b2cac11d17e1

msExchSystemPolicy,ba085a33-8807-4c6c-9522-2cf5a2a5e9c2

msExchSystemPolicyContainer,32412a7a-22af-479c-a444-624c0137122e

msExchTeamMailboxProvisioningPolicy,7085fa04-f3c2-4f53-886a-3142da4f1610

msExchTenantPerimeterSettings,8e11a5b0-5428-4d27-bea6-4dbac4f17ebe

msExchThrottlingPolicy,969ecdf1-a388-4f73-80a5-56a9acc4cde7

msExchTransportResellerSettings,b1b0cbaf-ea35-4648-bf56-3f916a38fdae

msExchTransportRule,fb031bae-baac-4599-8e29-2710df94fa0c

msExchTransportRuleCollection,2230472b-4dc2-46af-9eb9-48f85e86471b

msExchTransportSettings,7dc6b928-c5e8-438a-88b5-5e61551297b0

msExchUce,c5ccdce1-b399-405f-8ab7-bc6434d2e422

msExchUMAutoAttendant,a0849bf5-7741-4422-a22d-ae8b08e156df

msExchUMDialPlan,df0fd94f-126f-42bd-a02f-aa0bac5a31d7

msExchUMHuntGroup,0b41a421-8532-4a93-b1e3-aa0466c0c545

msExchUMIPGateway,2f786350-069f-46a1-a4a2-a92bbc541915

msExchUMRecipientTemplate,c632ff49-d5dd-4e98-94ba-ef992b548b1f

msExchUMVirtualDirectory,c0d365d9-5fca-456a-a0cc-4c794efdf19d

msExchVirtualDirectory,28009b8e-9876-44f3-b907-a3bf06d3cc1f

msExchWebServicesVirtualDirectory,d34e9d76-5269-4ed9-b91a-2f2a4b20a5cf

msExchWorkloadManagementPolicy,df1e337e-2931-4416-bd27-73c404ca1362

msExchWorkloadPolicy,8ca25026-95d9-4d2c-a2bc-5c464a607071

msFVE-RecoveryInformation,ea715d30-8f53-40d0-bd1e-6109186d782c

msieee80211-Policy,7b9a2d92-b7eb-4382-9772-c3e0f9baaf94

msImaging-PostScanProcess,1f7c257c-b8a3-4525-82f8-11ccc7bee36e

msImaging-PSPs,a0ed2ac1-970c-4777-848e-ec63a0ec44fc

msKds-ProvRootKey,aa02fd41-17e0-4f18-8687-b2239649736b

msKds-ProvServerConfiguration,5ef243a8-2a25-45a6-8b73-08a71ae677ce

mSMailConnector,a8df74be-c5ea-11d1-bbcb-0080c76670c0

mSMQConfiguration,9a0dc344-c100-11d1-bbc5-0080c76670c0

msMQ-Custom-Recipient,876d6817-35cc-436c-acea-5ef7174dd9be

mSMQEnterpriseSettings,9a0dc345-c100-11d1-bbc5-0080c76670c0

msMQ-Group,46b27aac-aafa-4ffb-b773-e5bf621ee87b

mSMQMigratedUser,50776997-3c3d-11d2-90cc-00c04fd91ab1

mSMQQueue,9a0dc343-c100-11d1-bbc5-0080c76670c0

mSMQSettings,9a0dc347-c100-11d1-bbc5-0080c76670c0

mSMQSiteLink,9a0dc346-c100-11d1-bbc5-0080c76670c0

ms-net-ieee-80211-GroupPolicy,1cb81863-b822-4379-9ea2-5ff7bdc6386d

ms-net-ieee-8023-GroupPolicy,99a03a6a-ab19-4446-9350-0cb878ed2d9b

msPKI-Enterprise-Oid,37cfd85c-6719-4ad8-8f9e-8678ba627563

msPKI-Key-Recovery-Agent,26ccf238-a08e-4b86-9a82-a8c9ac7ee5cb

msPKI-PrivateKeyRecoveryAgent,1562a632-44b9-4a7e-a2d3-e426c96a3acc

msPrint-ConnectionPolicy,a16f33c7-7fd6-4828-9364-435138fda08d

msSFU30DomainInfo,36297dce-656b-4423-ab65-dabb2770819e

msSFU30MailAliases,d6710785-86ff-44b7-85b5-f1f8689522ce

msSFU30NetId,e263192c-2a02-48df-9792-94f2328781a0

msSFU30NetworkUser,e15334a3-0bf0-4427-b672-11f5d84acc92

msSFU30NISMapConfig,faf733d0-f8eb-4dcf-8d75-f1753af6a50b

msSPP-ActivationObject,51a0e68c-0dc5-43ca-935d-c1c911bf2ee5

msSPP-ActivationObjectsContainer,b72f862b-bb25-4d5d-aa51-62c59bdf90ae

mS-SQL-OLAPCube,09f0506a-cd28-11d2-9993-0000f87a57d4

mS-SQL-OLAPDatabase,20af031a-ccef-11d2-9993-0000f87a57d4

mS-SQL-OLAPServer,0c7e18ea-ccef-11d2-9993-0000f87a57d4

mS-SQL-SQLDatabase,1d08694a-ccef-11d2-9993-0000f87a57d4

mS-SQL-SQLPublication,17c2f64e-ccef-11d2-9993-0000f87a57d4

mS-SQL-SQLRepository,11d43c5c-ccef-11d2-9993-0000f87a57d4

mS-SQL-SQLServer,05f6c878-ccef-11d2-9993-0000f87a57d4

msTAPI-RtConference,ca7b9735-4b2a-4e49-89c3-99025334dc94

msTAPI-RtPerson,53ea1cb5-b704-4df9-818f-5cb4ec86cac1

msTPM-InformationObject,85045b6a-47a6-4243-a7cc-6890701f662c

msTPM-InformationObjectsContainer,e027a8bd-6456-45de-90a3-38593877ee74

msWMI-IntRangeParam,50ca5d7d-5c8b-4ef3-b9df-5b66d491e526

msWMI-IntSetParam,292f0d9a-cf76-42b0-841f-b650f331df62

msWMI-MergeablePolicyTemplate,07502414-fdca-4851-b04a-13645b11d226

msWMI-ObjectEncoding,55dd81c9-c312-41f9-a84d-c6adbdf1e8e1

msWMI-PolicyTemplate,e2bc80f1-244a-4d59-acc6-ca5c4f82e6e1

msWMI-PolicyType,595b2613-4109-4e77-9013-a3bb4ef277c7

msWMI-RangeParam,45fb5a57-5018-4d0f-9056-997c8c9122d9

msWMI-RealRangeParam,6afe8fe2-70bc-4cce-b166-a96f7359c514

msWMI-Rule,3c7e6f83-dd0e-481b-a0c2-74cd96ef2a66

msWMI-ShadowObject,f1e44bdf-8dd3-4235-9c86-f91f31f5b569

msWMI-SimplePolicyTemplate,6cc8b2b5-12df-44f6-8307-e74f5cdee369

msWMI-Som,ab857078-0142-4406-945b-34c9b6b13372

msWMI-StringSetParam,0bc579a2-1da7-4cea-b699-807f3b9d63a4

msWMI-UintRangeParam,d9a799b2-cef3-48b3-b5ad-fb85f8dd3214

msWMI-UintSetParam,8f4beb31-4e19-46f5-932e-5fa03c339b1d

msWMI-UnknownRangeParam,b82ac26b-c6db-4098-92c6-49c18a3336e1

msWMI-WMIGPO,05630000-3927-4ede-bf27-ca91f275c26f

mTA,a8df74a7-c5ea-11d1-bbcb-0080c76670c0

mTACfg,a8df74a8-c5ea-11d1-bbcb-0080c76670c0

nisMap,7672666c-02c1-4f33-9ecf-f649c1dd9b7c

nisNetgroup,72efbf84-6e7b-4a5c-a8db-8a75a7cad254

nisObject,904f8a93-4954-4c5f-b1e1-53c097a31e13

nTDSConnection,19195a60-6da0-11d0-afd3-00c04fd930c9

nTDSDSA,f0f8ffab-1191-11d0-a060-00aa006c33ed

nTDSDSARO,85d16ec1-0791-4bc8-8ab3-70980602ff8c

nTDSService,19195a5f-6da0-11d0-afd3-00c04fd930c9

nTDSSiteSettings,19195a5d-6da0-11d0-afd3-00c04fd930c9

nTFRSMember,2a132586-9373-11d1-aebc-0000f80367c1

nTFRSReplicaSet,5245803a-ca6a-11d0-afff-0000f80367c1

nTFRSSettings,f780acc2-56f0-11d1-a9c6-0000f80367c1

nTFRSSubscriber,2a132588-9373-11d1-aebc-0000f80367c1

nTFRSSubscriptions,2a132587-9373-11d1-aebc-0000f80367c1

oncRpc,cadd1e5e-fefc-4f3f-b5a9-70e994204303

organization,bf967aa3-0de6-11d0-a285-00aa003049e2

organizationalPerson,bf967aa4-0de6-11d0-a285-00aa003049e2

organizationalRole,a8df74bf-c5ea-11d1-bbcb-0080c76670c0

organizationalUnit,bf967aa5-0de6-11d0-a285-00aa003049e2

packageRegistration,bf967aa6-0de6-11d0-a285-00aa003049e2

person,bf967aa7-0de6-11d0-a285-00aa003049e2

physicalLocation,b7b13122-b82e-11d0-afee-0000f80367c1

pKICertificateTemplate,e5209ca2-3bba-11d2-90cc-00c04fd91ab1

pKIEnrollmentService,ee4aa692-3bba-11d2-90cc-00c04fd91ab1

posixAccount,ad44bb41-67d5-4d88-b575-7b20674e76d8

posixGroup,2a9350b8-062c-4ed0-9903-dde10d06deba

printQueue,bf967aa8-0de6-11d0-a285-00aa003049e2

protocolCfg,a8df74c0-c5ea-11d1-bbcb-0080c76670c0

protocolCfgHTTP,a8df74c1-c5ea-11d1-bbcb-0080c76670c0

protocolCfgHTTPServer,a8df74c2-c5ea-11d1-bbcb-0080c76670c0

protocolCfgHTTPSite,a8df74c3-c5ea-11d1-bbcb-0080c76670c0

protocolCfgIMAP,a8df74c4-c5ea-11d1-bbcb-0080c76670c0

protocolCfgIMAPServer,a8df74c5-c5ea-11d1-bbcb-0080c76670c0

protocolCfgIMAPSite,a8df74c6-c5ea-11d1-bbcb-0080c76670c0

protocolCfgLDAP,a8df74c7-c5ea-11d1-bbcb-0080c76670c0

protocolCfgLDAPServer,a8df74c8-c5ea-11d1-bbcb-0080c76670c0

protocolCfgLDAPSite,a8df74c9-c5ea-11d1-bbcb-0080c76670c0

protocolCfgNNTP,a8df74ca-c5ea-11d1-bbcb-0080c76670c0

protocolCfgNNTPServer,a8df74cb-c5ea-11d1-bbcb-0080c76670c0

protocolCfgNNTPSite,a8df74cc-c5ea-11d1-bbcb-0080c76670c0

protocolCfgPOP,a8df74cd-c5ea-11d1-bbcb-0080c76670c0

protocolCfgPOPServer,a8df74ce-c5ea-11d1-bbcb-0080c76670c0

protocolCfgPOPSite,a8df74cf-c5ea-11d1-bbcb-0080c76670c0

protocolCfgShared,a8df74d0-c5ea-11d1-bbcb-0080c76670c0

protocolCfgSharedServer,a8df74d1-c5ea-11d1-bbcb-0080c76670c0

protocolCfgSharedSite,a8df74d2-c5ea-11d1-bbcb-0080c76670c0

protocolCfgSMTP,33f98980-a982-11d2-a9ff-00c04f8eedd8

protocolCfgSMTPDomain,33d82894-a982-11d2-a9ff-00c04f8eedd8

protocolCfgSMTPDomainContainer,33bb8c5c-a982-11d2-a9ff-00c04f8eedd8

protocolCfgSMTPRoutingSources,3397c916-a982-11d2-a9ff-00c04f8eedd8

protocolCfgSMTPServer,3378ca84-a982-11d2-a9ff-00c04f8eedd8

protocolCfgSMTPSessions,8ef628c6-b093-11d2-aa06-00c04f8eedd8

protocolCfgSMTPSite,32f0e47a-a982-11d2-a9ff-00c04f8eedd8

publicFolder,f0f8ffac-1191-11d0-a060-00aa006c33ed

queryPolicy,83cc7075-cca7-11d0-afff-0000f80367c1

rASStack,a8df74d3-c5ea-11d1-bbcb-0080c76670c0

rASX400Link,a8df74d4-c5ea-11d1-bbcb-0080c76670c0

remoteDXA,a8df74d5-c5ea-11d1-bbcb-0080c76670c0

remoteMailRecipient,bf967aa9-0de6-11d0-a285-00aa003049e2

remoteStorageServicePoint,2a39c5bd-8960-11d1-aebc-0000f80367c1

residentialPerson,a8df74d6-c5ea-11d1-bbcb-0080c76670c0

rFC1006Stack,a8df74d7-c5ea-11d1-bbcb-0080c76670c0

rFC1006X400Link,a8df74d8-c5ea-11d1-bbcb-0080c76670c0

rFC822LocalPart,b93e3a78-cbae-485e-a07b-5ef4ae505686

rIDManager,6617188d-8f3c-11d0-afda-00c04fd930c9

rIDSet,7bfdcb89-4807-11d1-a9c3-0000f80367c1

room,7860e5d2-c8b0-4cbb-bd45-d9455beb9206

rpcContainer,80212842-4bdc-11d1-a9c4-0000f80367c1

rpcEntry,bf967aac-0de6-11d0-a285-00aa003049e2

rpcGroup,88611bdf-8cf4-11d0-afda-00c04fd930c9

rpcProfile,88611be1-8cf4-11d0-afda-00c04fd930c9

rpcProfileElement,f29653cf-7ad0-11d0-afd6-00c04fd930c9

rpcServer,88611be0-8cf4-11d0-afda-00c04fd930c9

rpcServerElement,f29653d0-7ad0-11d0-afd6-00c04fd930c9

rRASAdministrationConnectionPoint,2a39c5be-8960-11d1-aebc-0000f80367c1

rRASAdministrationDictionary,f39b98ae-938d-11d1-aebd-0000f80367c1

samDomain,bf967a90-0de6-11d0-a285-00aa003049e2

samDomainBase,bf967a91-0de6-11d0-a285-00aa003049e2

samServer,bf967aad-0de6-11d0-a285-00aa003049e2

secret,bf967aae-0de6-11d0-a285-00aa003049e2

securityObject,bf967aaf-0de6-11d0-a285-00aa003049e2

securityPrincipal,bf967ab0-0de6-11d0-a285-00aa003049e2

server,bf967a92-0de6-11d0-a285-00aa003049e2

serversContainer,f780acc0-56f0-11d1-a9c6-0000f80367c1

serviceAdministrationPoint,b7b13123-b82e-11d0-afee-0000f80367c1

serviceClass,bf967ab1-0de6-11d0-a285-00aa003049e2

serviceConnectionPoint,28630ec1-41d5-11d1-a9c1-0000f80367c1

serviceInstance,bf967ab2-0de6-11d0-a285-00aa003049e2

shadowAccount,5b6d8467-1a18-4174-b350-9cc6e7b4ac8d

simpleSecurityObject,5fe69b0b-e146-4f15-b0ab-c1e5d488e094

site,bf967ab3-0de6-11d0-a285-00aa003049e2

siteAddressing,a8df74d9-c5ea-11d1-bbcb-0080c76670c0

siteConnector,a8df74da-c5ea-11d1-bbcb-0080c76670c0

siteLink,d50c2cde-8951-11d1-aebc-0000f80367c1

siteLinkBridge,d50c2cdf-8951-11d1-aebc-0000f80367c1

sitesContainer,7a4117da-cd67-11d0-afff-0000f80367c1

storage,bf967ab5-0de6-11d0-a285-00aa003049e2

subnet,b7b13124-b82e-11d0-afee-0000f80367c1

subnetContainer,b7b13125-b82e-11d0-afee-0000f80367c1

subSchema,5a8b3261-c38d-11d1-bbc9-0080c76670c0

top,bf967ab7-0de6-11d0-a285-00aa003049e2

tP4Stack,a8df74db-c5ea-11d1-bbcb-0080c76670c0

tP4X400Link,a8df74dc-c5ea-11d1-bbcb-0080c76670c0

transportStack,a8df74dd-c5ea-11d1-bbcb-0080c76670c0

trustedDomain,bf967ab8-0de6-11d0-a285-00aa003049e2

typeLibrary,281416e2-1968-11d0-a28f-00aa003049e2

user,bf967aba-0de6-11d0-a285-00aa003049e2

volume,bf967abb-0de6-11d0-a285-00aa003049e2

x25Stack,a8df74de-c5ea-11d1-bbcb-0080c76670c0

x25X400Link,a8df74df-c5ea-11d1-bbcb-0080c76670c0

x400Link,a8df74e0-c5ea-11d1-bbcb-0080c76670c0

The default location for newly provisioned user and computer objects are (respectively) the Users and Computers containers.  Since Windows Server 2003 Active Directory the option has been available to redirect these to OUs that you specificy.  Why would you want to do this?  Well, the Users and Computers containers are just that – container objects and not OUs.  You can apply Group Policy to OUs but not to containers. 

 As an example, you might have important security settings such as AppLocker application whitelisting that you apply to your computers via GPOs.  If you have computer objects in the default Computers container they will not be picking up those policies.

 I recommend to all my customers that they redirect the Users and Computers containers to OUs that are locked down with highly restrictive Group Policies.  This measure effectively forces the admins to move those objects to where they should be located in the OU structure.  The most well-known method of performing the redirection is to use the redirusr and redircmp utilities that are built-into the operating system.  The process is described on Technet (https://technet.microsoft.com/en-us/library/cc772758(v=ws.10).aspx). 

 Of course we now have PowerShell as an alternative option.  I thought it would be fun to see how easy it would be to perform the redirection using a script.  Here’s what I came up with (seems to do the job).

## Specify the new targets for redirection
$dnc = (Get-ADRootDSE).DefaultNamingContext
# Users
$newusers = "OU=Redirected Users," + $dnc
# Computers
$newcomps = "OU=Redirected Computers," + $dnc

# Get the current targets (from wellKnownObjects attribute)
$wkos = Get-ADObject -Identity $dnc -pr wellKnownObjects `
| select -ExpandProperty wellKnownObjects

# Find the Users container value in the attribute
$curuwko = $wkos | ? {$_ -like "*CN=Users,*"}
# Split the value into its constituent parts
$datusers = $curuwko.split(":")

# Find the Computers container value in the attribute
$curcwko = $wkos | ? {$_ -like "*CN=Computers,*"}
# Split the value into its constituent parts
$datcomps = $curcwko.split(":")

# Build the new value for Users
$newuwko = $datusers[0] + ":" + $datusers[1] + ":" + $datusers[2] + ":" + $newusers
# Build the new value for Computers
$newcwko = $datcomps[0] + ":" + $datcomps[1] + ":" + $datcomps[2] + ":" + $newcomps

## Replace the old values with the new
$dc = (Get-ADDomainController).name
Set-ADObject $dnc -add @{wellKnownObjects = $newuwko} `
-Remove @{wellKnownObjects = $curuwko} -Server $dc
Set-ADObject $dnc -add @{wellKnownObjects = $newcwko} `
-Remove @{wellKnownObjects = $curcwko} -Server $dc

You now have the ability to provide product feature requests and changes relating to Windows Server that go direct to the Product Group.  Not only that, but you can build a base of voter support to drive your suggestions across the line.

windowsserver.uservoice.com

I really like this concept as it removes the difficulties associated with getting your voice heard by those that really matter.

Unfortunately Active Directory doesn’t yet provide dynamic security groups in the way that, for example, Exchange provides dynamic distribution groups.  Sometimes it is useful to maintain a group’s membership based on a specific attribute, or set of attributes.  Here’s a quick Powershell example that shows how to maintain the membership based on the presence of a single attribute value.

You can download the script here: AttributeBasedGroupMembership

#########################################################
#
# Name: AttributeBasedGroupMembership.ps1
# Author: Tony Murray
# Version: 1.0
# Date: 18/06/2015
# Comment: PowerShell 2.0 script to manage group 
# membership based on attribute values
#
#########################################################

# Import the AD module
ipmo ActiveDirectory

# Define arrays to be used for matching
$arratt = @()
$arrgp = @()

# Domain controller to be used
$dc = (Get-ADRootDSE).dnshostname
write-host "Using DC $dc for all AD reads/writes"

# Specify the OU where the accounts are located
$OUdn = "OU=Corp Users,DC=Contoso,DC=com"

# Find all the objects that have the specified attribute value
$AttUsrs = Get-ADUser -LDAPFilter "(extensionattribute1=Sales)" -SearchBase $oudn -Server $dc

# Specify the GUID of the group to use
# You could also use name of group (but this can be changed)
$grp = "7bbf64bc-46c7-4a90-9d58-7cb5eca35fce" # i.e. "Sales Team"

# Find all the group members
$grpusers = Get-ADGroupMember -Identity $grp -Server $dc

# Build arrays using the DN attribute value
$AttUsrs | % {$arratt += $_.distinguishedname}
$grpusers | % {$arrgp += $_.distinguishedname}


# Add to group membership (newly assigned attribute value)
foreach ($usr in $arratt) {
    if ($arrgp -contains $usr) {
        write-host "User $usr is a member of the group"
    }
    else {
        write-host "User $usr is not a member of the group - adding..."
        Add-ADGroupMember -Identity $grp -Members $usr -Server $dc
    } # end else
    Remove-Variable -ErrorAction SilentlyContinue -Name usr    
} # end foreach

write-host "`n"

# Remove from group (no longer has attribute value or has been manually added to group)
# Assumption here is that the attribute value is authoritative for the group's membership
foreach ($mem in $arrgp) {
    if ($arratt -contains $mem) {
        write-host "User $mem still has the attribute value.  Nothing to do"
    } # end if
    else {
        write-host "User $mem does not have the attribute value.  Removing from membership..."
        Remove-ADGroupMember -Identity $grp -Members $mem -Server $dc -Confirm:$false
    } # end else
    Remove-Variable -ErrorAction SilentlyContinue -Name mem
} # end foreach

To ensure the script is run regularly, you would likely want to call it from a scheduled task.

Like that hipster beard you grew last summer, all good things must eventually come to an end. You will likely be aware that the end of extended support for Windows Server 2003 finishes on July 14th 2015. If you don’t know whether you still have 2003 boxes lurking in the dark recesses of your AD domain, you could try running the handy script below to flush them out.

The script looks for Window Server 2003 machine accounts that have logged on to the domain some time within the past 60 days – a good indicator that they are still active. It produces a CSV output for your perusal.

#########################################################
#
# Name: Find-W2K3StillActive.ps1
# Author: Tony Murray
# Version: 1.0
# Date: 25/06/2015
# Comment: PowerShell 2.0 script to find active
# Windows Server 2003 computer accounts
#
#########################################################

## Define global variables
# Export file for storing results
$expfile = "c:\w2k3_still_active.csv"
# Define the header row for the CSV (we will create our own)
$header = "`"name`",`"os`",`"sp`",`"lastlogondate`""
# Consider any account logged on in the last x days to be active
$days = 60
$Today = Get-date
$SubtractDays = New-Object System.TimeSpan $days, 0, 0, 0, 0
$StartDate = $Today.Subtract($SubtractDays)
$startdate = $startdate.ToFiletime()
# LDAP filter settings
$filter = "(&(lastlogontimestamp>=$startDate)(operatingsystem=Windows Server 2003*))"

## Functions
Function Format-ShortDate ($fdate)
{
        if ($fdate) {
            $day = $fdate.day
            $month = $fdate.month
            $year = $fdate.year
            "$day/$month/$year"
        } # end if

} # end function

## Start doing things
# Import the AD module
ipmo ActiveDirectory
# Tidy up any previous copies of the export file 
if (test-path $expfile) {Remove-Item $expfile}
# Add the header row to the export file
Add-Content -Value $header -Path $expfile
# Create an array of computer objects
$active = Get-ADComputer -LDAPFilter $filter -pr *
# loop through the array
foreach ($w2k3 in $active) {
    # Grab the attribute values we need from the AD object
    $nm = $w2k3.name
    $os = $w2k3.operatingsystem
    $sp = $w2k3.operatingsystemservicepack
    $lt = Format-ShortDate $($w2k3.lastlogondate)
    $row = "`"$nm`",`"$os`",`"$sp`",`"$lt`""
    # Commit the row to the export file
    Add-Content -Value $row -Path $expfile
} # end foreach

## End script

Enjoy!

I’m sometimes asked what the best practice is surrounding the Default Domain Policy and Default Domain Controllers Policy. Microsoft has some good guidance on this topic, but it’s not always clearly and consistently stated. Here’s a quick Q&A that might help.

Q. Is it ok to make changes to the DDP and DDCP GPOs, or should I leave them alone and create new policies?

A. The best practice recommendation from Microsoft is as follows:

• ·    To accommodate APIs from previous versions of the operating system that make changes directly to default GPOs, changes to the following security policy settings must be made directly in the Default Domain Policy GPO or in the Default Domain Controllers Policy GPO:
• ·    Default Domain Security Policy Settings:
  • o    Password Policy
  • o    Domain Account Lockout Policy
  • o    Domain Kerberos Policy
• ·    Default Domain Controller Security Policy Settings:
  • o    User Rights Assignment Policy
  • o    Audit Policy

Source: Best Practice Guide for Securing Active Directory Installations (https://technet.microsoft.com/en-us/library/cc773164(v=ws.10).aspx)

So, that’s it!  If you want to apply other settings at the domain root level or to the Domain Controllers OU then you should create new GPOs and link them to the appropriate scope of management. The ordering of the GPOs shouldn’t really matter as you should have no overlapping settings. As a general rule of thumb, however, I would recommend assigning any new GPOs a higher precedence in case someone starts using the default GPOs for settings that are not on the “approved” list above. That way the new GPOs will win in any conflict.

Another reason to limit the settings in the default GPOs is to allow them to be re-created with minimal re-work in scenarios where they have gone missing or are corrupt and you don’t have a good backup.  The method by which you can re-create the GPOs is using a tool called DCGPOFIX.EXE (https://technet.microsoft.com/en-us/library/hh875588.aspx).  Bear in mind that this tool is a last resort following a major issue or disaster and you should really ensure you have good GPO backups, as per this article:

If you are in a disaster recovery scenario and you do not have any backed up versions of the Default Domain Policy or the Default Domain Controller Policy, you may consider using the Dcgpofix tool. If you use the Dcgpofix tool, Microsoft recommends that as soon as you run it, you review the security settings in these GPOs and manually adjust the security settings to suit your requirements. A fix is not scheduled to be released because Microsoft recommends you use GPMC to back up and restore all GPOs in your environment. The Dcgpofix tool is a disaster-recovery tool that will restore your environment to a functional state only. It is best not to use it as a replacement for a backup strategy using GPMC. It is best to use the Dcgpofix tool only when a GPO back up for the Default Domain Policy and Default Domain Controller Policy does not exist.

Source: https://support.microsoft.com/en-us/kb/833783

Q. We have disabled our DDP and DDCP GPOs and replaced them with new GPOs. Is that OK?

A. No, that’s not ok.  The GPOs have a fixed GUID and can be targeted directly using these by the “legacy APIs” mentioned above. 

31b2f340-016d-11d2-945f-00c04fb984f9: Default Domain Policy

6ac1786c-016f-11d2-945f-00c04fb984f9: Default Domain Controllers Policy

One well known application that directly modifies the Default Domain Controllers Policy is Microsoft Exchange.  The installer adds the Exchange Servers group to the “Manage Auditing and Security Log” User Right (also referred to as SACL right). So, if you disable or unlink the GPO this right (and potentially others like it) it will go missing and will cause problems for Exchange.

Q. Is it OK to rename the DDP and DDCP GPOs?

A. If you feel you must do this I don’t believe it will have any impact, other than it might confuse people when they look for them. I’ve seen some customers rename the GPOs to align them with their in-house naming convention. As mentioned above, these GPOs are targeted using their well-known GUIDs, which is why the rename shouldn’t cause an issue. 

You can find the renamed GPOs quite easily using the Group Policy cmdlets, e.g.

# Find the Default Domain Policy

Get-GPO -Guid 31b2f340-016d-11d2-945f-00c04fb984f9

# Find the Default Domain Controllers Policy

Get-GPO -Guid 6ac1786c-016f-11d2-945f-00c04fb984f9

Conclusion

Use the default GPOs for the approved specific purposes only.  If you have other settings you need for the same scope of management, create new GPOs and link them with higher precedence than the default GPOs. Under no circumstances should you disable or unlink the GPOs.  If you rename the default GPOs there should be no impact, but your mileage may vary.

Qasim Zaidi has an old but really good blog entry on enabling change notification for Active Directory site links.  For a long time now I’ve encouraged my customers (those with decent bandwidth between sites) to enable change notifications on site links rather than wait the 15 minutes (minimum) for replication between sites.

Qasim’s blog references a Powershell one-liner to enable change notification for all site links.  For some reason it didn’t work for me, so I wrote my own. Here it is for those that might be interested.

### Enable change notification on all site links
$nc = (Get-ADRootDSE).configurationnamingcontext
$sb = "CN=IP,CN=Inter-Site Transports,CN=Sites," + $nc
$fl = "(objectclass=sitelink)"
Get-adobject -LDAPFilter $fl -SearchBase $sb -properties options `
| set-adobject –replace @{options=$($_.options –bor 1)}

OK, the title has a whole bunch of acronyms which may not be entirely familiar. Actually…if we’re being really picky I should probably say a whole bunch of initialisms, but that would digress into a whole different article when a perfectly good Wikipedia article already exists for that.

Anyway, PTA is the accepted short form of Pass-Through Authentication – one of the range of authentication options available with Azure Active Directory.

AADJ stands for Azure Active Directory Domain Join(ed).  This is a state for a Windows 10 machine in which it is joined to Azure Active Directory for a given tenant organisation.  It is materially different to Azure AD Device Registration and Hybrid Azure AD Join, as neatly described here.

If you’re already set up with Azure AD Connect, have AADJ devices and are using PTA for your user sign-ins then you should be aware of an important limitation with respect to the “User must change password at next log on” flag.  The flag itself is set on the user object in on-premises Active Directory.  If you’ve been around a while, you’ll already be familiar with the setting - it looks like this:

The setting is used in a number of organisations to deal with the following situations:

• User has forgotten their password and the Service Desk assigns them a temporary password to get them going again
• New hires who are assigned a temporary password to start them off

So what’s the problem with setting this flag in our PTA, AADJ scenario?  Well, quite simply the user won’t be able to sign-in to their Windows 10 machine.  Instead of the user being prompted to change their password when entering the credentials that include the temporary password, the user sees the generic, “The user name or password is incorrect. Try again”.

Hopefully Microsoft will provide a resolution to this in the near future.  At the time of writing the behaviour is seen as “by design” in so far as the error generated on the DC to which the credentials have been passed cannot be successfully translated back to the point where the sign in attempt occurs.

One of my customers is using Password Hash Synchronisation (PHS) as their Azure Active Directory authentication method for users synced from on-premises AD. Not having had much experience with PHS, I was a little surprised to learn recently that PHS users have cloud passwords that do not conform to the default AAD 90 day expiry. Instead, password expiry is disabled for synchronised users when PHS is enabled. How can you check this? Well, with a little Powershell.

Get-AzureADUser -ObjectId tony.murray@contoso.com | Select-Object @{N="PasswordNeverExpires";E={$_.PasswordPolicies -contains "DisablePasswordExpiration"}} 

If you want to get a comprehensive report about password expiry for all user Azure AD users, then I can recommend this one from the Technet Gallery: PwdExpiryReport.ps1

I think the reason why the cloud user passwords are set to never expire with PHS enabled is that it removes the potential negative impact of mismatched password policies between on-premises AD and Azure AD. For example, it would very confusing for a user if their AAD password expired while their on-premises AD password was still valid.

The post PHS and Password Expiry appeared first on Cloud Azzurri.