What Is Global Catalog? | MicrosoftВ® Windows PowerShell(TM) Step By Step (Step By Step (Microsoft))

As you become more proficient in writing your scripts, and as you begin to work your magic on the enterprise on a global scale, you will begin to wonder why some queries seem to take forever and others run rather fast. After configuring some of the parameters you looked at earlier, you might begin to wonder whether you’re hitting a Global Catalog (GC) server. A Global Catalog server is a server that contains all the objects and their associated attributes from your local domain. If all you have is a single domain, it doesn’t matter whether you’re connecting to a domain controller or a GC server because the information will be the same. If, however, you are in a multiple domain forest, you might very well be interested in which GC server you are hitting. Depending on your network topology, you could be executing a query that is going across a slow WAN link. You can control replication of attributes by selecting the Global Catalog check box. You can find this option by opening the Active Directory Schema MMC, highlighting the Attributes container. The Active Directory Schema MMC is not available by default in the Administrative Tools program group. For information on how to install it, visit the following URL: http://technet2.microsoft.com/WindowsServer/en/library/1033.mspx?mfr=true.

In addition to controlling the replication of attributes, the erstwhile administrator might also investigate attribute indexing (Fig. 8-1.) Active Directory already has indexes built on certain objects. However, if an attribute is heavily searched on, you might consider an additional index. You should do this, however, with caution because an improperly placed index is worse than no index at all. The reason for this is the time spent building and maintaining an index. Both of these operations use processor time and disk I/O.

image from book
Figure 8-1: Heavily queried attributes often benefit from indexing

Querying a global catalog server

Open the BasicQuery.ps1 script in Notepad or another Windows PowerShell editor and save the file as yourname QueryGC.ps1
On the first noncommented line of your script, declare a variable called $strBase. This variable will be used to control the connection into the global catalog server in Active Directory. To do this, instead of using the LDAP moniker, we will use the GC moniker. The rest of the path will be the same because it uses the Distinguished Name of target. For this procedure, let’s connect to the OU called MyTestOU in the NwTraders.msft domain. The line of code to do this is shown here:
```
 $strBase = <GC://ou=MyTestOU,dc=nwtraders,dc=msft>
```
On the next line, create a variable called $strFilter. This variable will be used to hold the filter portion of the query. The filter will be used to return only objects from Active Directory that have the objectCategory attribute set to User. The line of code that does this is shown here:
```
 $strFilter = "(objectCategory=user)"
```
Create a variable called $strAttributes that will be used to hold the attributes to retrieve from Active Directory. For this script, we are only interested in the Name attribute. The line of code that does this is shown here:
```
 $strAttributes = "name"
```
Create a variable called $strScope. This variable will hold the string oneLevel that is used to tell Active Directory that we want the script to obtain a list of the users in the MyTestOU only. We do not need to perform a recursive type of query. This line of code is shown here:
```
 $strScope = "oneLevel"
```
Modify the $strQuery line so that it uses the four variables we defined for each of the four parts of the LDAP dialect query. The four variables are $strBase, $strFilter, $strAttributes, and $strScope in this order. Make sure you use a semicolon to separate the four parts from one another. Move the completed line of code to the line immediately beneath the $strScope-“oneLevel” line. The completed line of code is shown here:
```
 $strQuery = "$strBase;$strFilter;$strAttributes;$strScope"
```
Save and run your script. It should run without errors. If it does not produce the expected results, compare your script with the QueryGC.ps1 script.
This concludes the querying a global catalog server procedure.

Querying a specific server

Open the QueryGC.ps1 script in Notepad or your favorite Windows PowerShell script editor, and save the script as yourname QuerySpecificServer.ps1.
Edit the string assigned to the $strBase variable so that you use the LDAP moniker instead of the GC moniker. After the ://, type the name of the server. Do not use CN=, as would normally be used for the Distinguished Name attribute. Instead, just type the name of the server followed by a forward slash (\). The completed line of code is shown here:
```
 $strBase = "<LDAP://London/ou=MyTestOU,dc=nwtraders,dc=msft>"
```
Save and run your script. If your script does not work properly, compare it with the QuerySpecificServer.ps1 script.
This concludes the querying a specific server procedure.

Querying a specific server by IP address

Open the QuerySpecificServer.ps1 script in Notepad or your favorite Windows PowerShell script editor and save it as yourname QuerySpecificServerByIP.ps1.
Edit the string that is assigned to the $strBase variable so that you are supplying the LDAP moniker with an IP address instead of a Host name. The revised line of code is shown here:
```
 $strBase = "<LDAP://192.168.1.1/ou=MyTestOU,dc=nwtraders,dc=msft>"
```
Save and run your script. If your script does not run properly, compare it with the QuerySpecificServerByIP.ps1 script.
This concludes the querying a specific server by IP address procedure.

Using the base search scope

Open the QuerySpecificServer.ps1 script in Notepad, or some other Windows PowerShell script editor. Save the script as yourname SearchBase.ps1.
Change the $strScope line so that it will point to base instead of oneLevel. This revised line of code is shown here:
```
 $strScope = "base"
```
Because a base query connects to a specific object, there is no point in having a filter. Delete the $strFilter line, and remove the $strFilter variable from the second position of the $strQuery string that is used for the LDAP dialect query. The revised $strQuery line of code is shown here:
```
 $strQuery = "$strBase;;$strAttributes;$strScope"
```
Because the base query will only return a single object, it does not make sense to perform a do … until loop. Delete the line that has the opening Do, and delete the line with the Until ($objRecordSet.eof).
Delete the opening and the closing curly brackets. Delete the $objRecordSet.MoveNext() command because there are no more records to move to.
Go to the $strAttributes variable and modify it so that we retrieve both the objectCategory and the Name attributes. The revised line of code is shown here:
```
 $strAttributes = "objectCategory,name"
```
Copy the $objRecordSet.Fields.item("name") |Select-Object value line of code, and paste it just below the first one. Edit the first $objRecordSet.Fields.item line of code so that it will retrieve the objectCategory attribute from the recordset. The two lines of code are shown here:
```
 $objRecordSet.Fields.item("objectCategory") |Select-Object value $objRecordSet.Fields.item("name") |Select-Object value
```
Save and run your script. If it does not perform correctly, compare it with the Search Base.ps1 script.
This concludes the using the base search scope procedure.

Using the SQL Dialect to Query Active Directory

For many network professionals, the rather cryptic way of expressing the query into Active Directory is at once confusing and irritating. Because of this confusion, we also have an SQL dialect we can use to query Active Directory. The parts that make up an SQL dialect query are listed in Table 8-5. Of the four parts that can make up an SQL dialect query, only two parts are required: the Select statement and the from keyword that indicates the base for the search. An example of this use is shown here. A complete script that uses this type of query is the SelectNameSQL.ps1 script.

 Select name from 'LDAP://ou=MyTestOu,dc=nwtraders,dc=msft'

Table 8-5: SQL Dialect
Open table as spreadsheet
Select	From	Where	Order by
Comma separated list of attributes	AdsPath for the base of the search enclosed in single quotation marks	Optional Used for the filter	Optional. Used for server side sort control. A comma separated list of attributes

The Where statement is used to specify the filter for the Active Directory query. This is similar to the filter used in the LDAP dialect queries. The basic syntax of the filter is attributeName = value. But as in any SQL query, we are free to use various operators, as well as and, or or, and even wild cards. An example of a query using Where is shown here (keep in mind this is a single line of code that was wrapped for readability). A complete script that uses this type of query is the QueryComputersSQL.ps1 script.

 Select name from 'LDAP://ou=MyTestOu,dc=nwtraders,dc=msft'where objectCategory='computer'

The order by clause is the fourth part of the SQL dialect query. Just like the Where clause, it is also optional. In addition to selecting the property to order by, you can also specify two keywords: ASC for ascending and DESC for descending. An example of using the order by clause is shown here. A complete script using this query is the QueryUsersSQL.ps1 script.

 Select adsPath, cn from 'LDAP://dc=nwtraders,dc=msft' where objectCategory='user'order by sn DESC

The SQLDialectQuery.ps1 script is different from the BasicQuery.ps1 script only in the dialect used for the query language. The script still creates both a Connection object and a Command object, and works with a RecordSet object in the output portion of the script. In the SQLDialectQuery.ps1 script, we hold the SQL dialect query in three different variables. The $strAttributes variable holds the select portion of the script. $strBase is used to hold the AdsPath attribute, which contains the complete path to the target of operation. The last variable used in holding the query is the $strFilter variable, which holds the filter portion of the query. Using these different variables makes the script easier to modify and easier to read. The $strQuery variable is used to hold the entire SQL dialect query. If you are curious to see the query put together in its entirety, you can simply print out the value of the variable by adding the $strQuery line under the line where the query is put back together.

SQLDialectQuery.ps1

 $strAttributes = "Select name from " $strBase = "'LDAP://ou=MyTestOu,dc=nwtraders,dc=msft'" $strFilter = " where objectCategory='computer'" $strQuery = "$strAttributes$strBase$strFilter" $objConnection = New-Object -comObject "ADODB.Connection" $objCommand = New-Object -comObject "ADODB.Command" $objConnection.Open("Provider=ADsDSOObject;") $objCommand.ActiveConnection = $objConnection $objCommand.CommandText = $strQuery $objRecordSet = $objCommand.Execute() Do {     $objRecordSet.Fields.item("name") |Select-Object Name,Value     $objRecordSet.MoveNext() } Until ($objRecordSet.eof)  $objConnection.Close()