Ben’s Tech Blog

We recently noticed that there were some blank entries in the GAL, in other words, there was a completely blank line between some objects in the GAL. If I double-clicked on any of these blank entries I’d receive the following message:

The properties dialog box could not be displayed. Internal MAPI error: An unsupported interface was requested of an object property. Contact your administrator.

The blank entries where only included in the ‘online’ GAL, offline address books were not affected, as well as Outlook Web Access and Outlook Mobile Access.

It turned out that someone had modified the security ACL of an OU, and Exhange no longer had access to view these users. The OU contained user objects for users who had left, but they were still mail-enabled, although interestingly enough, hidden from address lists. Once I set the permissions of the OU back to the default (which includes rights for the Exchange Domain Servers and Exchange Enterprise Servers, and rebuilt the domain RUS object the blank entries disappeared.

The Windows Server 2003 Active Directory Users and Computers snap-in (ADUC) includes the ‘Saved Queries’ feature which allows you to save queries for future use. One of the nice things about this feature is that once you save the query you can view the actual LDAP query string. You can then proceed to customize the string, or copy and paste it into a script for example.

The biggest shortfall that I see with the ADUC find/search utility, is when it comes to selecting a Condition, and this is where you may need to customise a LDAP query. The drop-down allows you to choose from Starts with or Ends with etc, but what about Contains? If you want to search all users to find a description for example that contains a word or phrase anywhere in the description you can’t using the standard method. This is where using a saved query comes in handy.

The easiest way to construct a custom query is to start by creating a query that is close to what you would like to search for. In this case you could construct the query by using either Starts with or Ends with as the condition, and then modify the query string once its saved. I’ll run through this now.

1. Right click on Saved Queries, then Select New -> Query.
2. Give the query a name, then click on Define Query
3. In this example, we’ll just search users, so select Custom Search from the drop-down.
4. Click on the Field button and select User -> Description.
5. Select Starts with and enter the text that you want to search for, e.g “test lab”, then click on Add.
6. Click on OK. Notice that the Query string field is now populated. Highlight and copy the Query string text and click on Define Query again.
7. Higlhight the criteria that you added before and click on Remove.
8. Click on the Advanced tab, and then paste in the query text
9. At this point you can now customise the query text. To search for descriptions that contain “test lab”, you need an asterix (*) on either side of the text. So you need to add an asterix to the end of the search text so that it looks like the text in the image below.

10. Click on OK, then OK again.
11. Right click on the Saved Query and click on Refresh. You’ll see that users with “test lab” anywhere in the description will be listed, for example, a user with “Sydney test lab user account” as the description would be listed in the results.

Of course, customizing your LDAP searches can allow you to do a lot more than what I just demonstrated. If you start exploring ADSI Edit you’ll find more attributes of objects that you can search on that aren’t listed in the ADUC search fields. For example, if you wanted to search for all users that have mailboxes on a particular Exchange server, you could use the msExchHomeServerName attribute. Your LDAP query would like something like this:

(&(&(objectCategory=user)(msExchHomeServerName=/o=OrgName/ou=AdminGroupName
/cn=Configuration/cn=Servers/cn=ServerName)))

The LDAP queries that you construct aren’t limited for use in ADUC, you can implement them in scripts that perform LDAP queries or third-party software that performs LDAP lookups for example. The ADUC saved queries feature just allows you to construct the basic query, from there you can modify it to do what you need. I should point out that you can also construct LDAP queries and view the LDAP string when you create Query-based distribution lists, or Exchange Address Lists/GALs.

We recently had hundreds of users leave our organization due to a takeover and we needed to remove each user from all of their distribution lists and security groups. Although we wanted to remove the users from all groups, I wanted to ensure that we had a record of what groups they were members of in case we needed to add them back in. The script that I created removes the user from all of their groups, but first records the list of groups they are member of and exports the list into a report file. We’ve already had two cases where we disabled a user and removed them from all groups and was later informed that the user’s termination date had been moved forward so their account needed to be reinstated. The user’s previous group membership listed in the report file made it very easy for us to add them back into the groups that they should belong to while they are still with the company.

I’ve added the script here.

When decommissioning Exchange servers, I like to stop the Exchange services or shut the server down for a week or so before uninstalling Exchange from the server; that way if I have overlooked anything and an issue arises I can bring the server back online very quickly. This week I was planning the removal of an Exchange 2003 public folder server. I re-homed all of the public folders and waited until they had all disappeared from the public folder instances container for the pubic store on the server in question. The next day I shut the server down and after a while noticed that there was mail queuing on the front-end servers to the public folder server that I had shut down.

At first, it didn’t make sense to me why the mail was queuing for the public folder server that I had shut down - there were no public folder replicas on the server, so in my mind there was no reason for any mail to be delivered to that server at all. After closer inspection of the messages in the queues, I could see that the messages were queuing for public folders that never had replicas on the server in question, which led me to believe that the server was playing some type of ‘bridgehead’ role that I didn’t know about.

I came across this Technet article that explains how public folder routing works and it cleared up the confusion that I had. In summary, when a message is received by a front-end server (or any Exchange server that doesn’t contain a public store), the server queries Active Directory for a public folder server that contains a copy of the public folder hierarchy. The transport then delivers the message to the server that contains the hierarchy based on the result of the AD query. The server with the copy of the hierarchy then determines which server or servers contain a replica of the public folder that the message is addressed to and passes it on to the appropriate public folder server containing the replica.

As the article explains, the query result will always be the most recently deployed public folder server for the routing group. This was consistent with the issue that I had – the server that I shut down was in fact the most recently commissioned public folder server, so it made sense why the messages were queuing up. Of course, I powered the server back on to allow the messages to deliver, and then began to look at how I should approach the situation.

Uninstalling Exchange would had been the easiest fix, but I still wanted to keep the server offline for a few days before uninstalling Exchange. The article mentions that you can modify the msExchOwningPFTree attribute on the public store object, and this is the solution that I decided to go with:

“Editing the msExchOwningPFTreeBL attribute directly is not possible, because it is a back link. However, you can delete the msExchOwningPFTree attribute on a specific public store object. If you delete the msExchOwningPFTree attribute on the public store object that is unavailable, the msExchOwningPFTreeBL back link attribute will be automatically removed from the back link list. By changing the msExchOwningPFTree attribute, you change the list in the msExchOwningPFTreeBL list, and thus alter the public folder routing decision.”

The article doesn’t explain how to atually edit the attribute so I thought I’d post the solution here so that others could refer to it. Note that after I cleared the attribute I wasn’t able to mount the store without putting the attribute back in place again. Also, you can avoid this scenario by mounting an empty public folder store on each front end server. The solution below however provides an easy way overcome a mail routing issue similar to the scenario that I had, particularly if you have already shut down the server and can’t bring it back up immediately.

If you want to temporarily prevent a particular public store from being used as the initial delivery point for messages destined for public folders in a routing group, you need to clear the msExchOwningPFTree attribute on the public folder store object using ADSI Edit:

• Launch mmc.exe
• Add the ADSI Edit snap-in to the console
• Right click on the ADSI Edit container and click on Connect to
• Choose the Select a well known Naming Context option and select Configuration from the drop-down list, then click on OK.
• Expand the Configuration container, then expand out each container as follows: CN=Services then CN=Microsoft Exchange then CN=YourExchangeOrg then CN=Administrative Groups then CN=AdminGroupofyourPFServer then CN=Servers then CN=YourPFServer then CN=InformationStore and then click on CN=StorageGroupContainingYourPFStore.  In the pane on the right you see the public store object listed.  Right click on the object and click on properties. 

  

• In the list of attributes, double click on the msExchOwningPFTree attribute and then click on Clear and and then OK

  . 

  

Once I cleared the msExchOwningPFTree attribrute I shut the server down again.  I sent some test messages and monitored the queues on the front-end servers.  The messages were delivered to the public folders, and no messages queued on the front-end servers. When it came time to remove Exchange, I put the attribute back in place so that I could mount the public store, take a final backup and uninstall Exchange.

I’ve added 2 scripts that I created recently to the scripts page. Check out the links below.

VBScript - Export a list of Mail Enabled Public Folders visible in the GAL
VBScript - Export a list of all Mailboxes with their home Server, Storage Group and Database.

In my opinion, the biggest shortfall of the Group Policy Editor is the inability to search for the group policy setting that you’re after.  In a lot of cases I know that a setting exists but I find myself navigating through the structure to find it.  Recently I discovered a better way.

The Group Policy Settings Reference is an Excel spreadsheet available for download from the Microsoft website.  It lists the majority of the settings that are available when creating a GPO including the newer settings released with Windows Server 2003 SP1.  The settings that it doesn’t include, according to the overview, are “settings that exist outside of the Security Settings extension (scecli.dll), such as Wireless Network extension, Public Key Policies, or Software Restriction Policies.”

Once you download the spreadsheet it’s easy to use the Excel Find function to search for the setting that you’re looking for.  Although a search function would be handy in the actual Group Policy Editor, this spreadsheet almost makes up for it.

The windows scripting host (WSH) allows administrators to execute scripts to automate administrative tasks, execute network login scripts and query systems for information - just to name just a few of it’s benefits.  I regularly write and run scripts; in fact I sometimes wonder how I got by before I ventured into the scripting realm.  The problem with the windows scripting host however is that it can be a launch-pad for malicious code.  Some administrators choose to disable the use of WSH on workstations and servers to prevent malicious code from executing.  While this makes a lot of sense from a security standpoint, it severely cripples your ability to automate admin tasks, and if you’re using vbscript based login scripts then you’re going to have a real problem. 

A far better approach is to use software restriction policies to dictate which scripts are permitted to run.  Software restriction polices are a new feature available in Windows Server 2003 and Windows XP that are set via Group Policy.  You’ll find the software restriction policy under Computer Configuration/Windows Settings/Security Settings/Software Restriction Policy. 

Software restriction policies are designed to control the execution of all executables, not just scripts.  There are 4 types of software restriction rules; I’m going to focus on the 3 that are beneficial to locking down the Windows scripting host.  To implement the rules, you simply create them in the Additional Rules folder.  Note that the folder already contains 4 default rules.

Path Rules:

Perhaps the simplest to implement, path rules let you either allow or disallow executables to run based on the path that they are launched from.  For example, you could disallow the execution of .vbs files (and the various extensions associated with script files) but permit those files that are in particular network share to run.

In this Example, you would create the following rules:

You could also use path rules to disallow vbscript files from running but allow them to run from your netlogon shares so that vbscript based login scripts could run:

Note that Microsoft’s recommendation is to avoid using environment variables where possible, as environment variables can be changed by the user to point to a different path.  If you choose not to use the %logonserver% environment variable you may want to consider using your domain controllers’ names instead. This may be cumbersome if you have a large number of DCs, but you do have the ability to use wildcards in path rules, so if all of you domain controllers where named DC1 - DC100 you could implement a policy similar to the following:

I’m comfortable in using the %logonserver% variable, and would be happy to use the first example in a production environment.

Hash Rules:

Hash rules have their advantages, however for locking down WSH they don’t provide too much flexibility.  Using a hash rule, you can allow or disallow the execution of files based on their content.  When you create a hash rule, a “hash” of the file is calculated.  Each time an executable is run, a hash of the file is compared with the hash stored in the policy.  In the case of locking down WSH, you could create a path rule to disallow all vbscript files, and then create a hash rule for each script that you want to allow.  While this may be suitable if you are using a single login script that rarely changes, or if you use only a handful of admin scripts that rarely change, it isn’t ideal for environments where scripts frequently change or like me you write new scripts every week.  The advantage to using hash rules over path rules though is that you can modify the filename and the hash will not change.  You can also run the script from any path;  as long as you don’t change the actual script itself you won’t need to modify the rule.

Example of hash rule to allow approved scripts:

Certificate Rules:

Certificate rules are an excellent way to lock down WSH to only allow approved scripts to run.  With a certificate rule, you import a digital certificate into a rule and then digitally sign each script that you want to approve with the same certificate.  The advantage to using certificate rules over path or hash rules is that the contents, path or filename of the script can change without preventing the approved script from running. 

The downside to using certificate rules is that you either need to purchase a digital certificate from a trusted public CA or install your own CA server and issue a certificate from there.  In both cases, the CA needs to be defined in the ‘Trusted Root Certification Authorities’ on your workstations and servers.

Importing the certificate

Once you have obtained a certificate to sign your scripts, you need to import the certificate into the rule.  This is fairly straight forward, you simply create the rule, then browse to the certificate file (*.cer, *.crt).

Signing Scripts

Strangely enough, you actually need to use a script to signs scripts.  The following is an example of a script that signs the C:\Scripts\script.vbs script with a certificate called Ben Christian.  The certificate must first be imported into the certificate store of the machine that you run the script on.

set objSigner = WScript.CreateObject(”Scripting.Signer”)
objSigner.SignFile “C:\Scripts\script.vbs”, “Ben Christian” 

Like the other rules, to implement a certificate rule to allow signed scripts to run, you would first create path rules to prevent the various script extensions from running.

Example of a certificate rule to allow approved scripts:

Using Certificate rules is probably the most secure way to lock down WSH with software restriction policy.  If certificate rules seem too cumbersome to implement, path rules are a good way to go.  In any case, implementing software restriction policies to lock down WSH on your client and server machines is better than doing nothing, and is an ideal balance between security and convenience.

I created a new script today to force AD replication between a number of servers.  I’ve explained how the script works on the script page, check it out if you’re interested.

VBScript - Force AD Replication