A Closer Look at Preparing Active Directory for Exchange 2007 (Part 5)

Introduction

This is the fifth and final part of an article series covering the preparation of Active Directory to receive the first Exchange 2007 server. So far in this article series we’ve covered the preparation of legacy permissions, the schema and Active Directory. This just leaves the final part which is the preparation of the Active Directory domains that will contain either Exchange 2007 servers or Exchange 2007 users.

Preparing The Domains

So here we are at the very last part of the process, namely the preparation of the Active Directory domains to receive Exchange 2007. If you have deployed legacy versions of Exchange you may remember the DomainPrep process that existed with Exchange 2000 and Exchange 2003. Well, preparing the domains for Exchange 2007 is similar in that the process must be performed in two locations:

In each domain that you will install an Exchange 2007 server into
In each domain that will contain mail-enabled users

To prepare a domain you use the setup /PrepareDomain command, or setup /pd for short. This prepares the domain from where you are running the command, although as I said earlier in this article the setup /p process prepares the domain in which the setup /p process was run so you don’t need to repeat this process in that domain. You can also choose to prepare a specific domain by adding the Fully Qualified Domain Name (FQDN) of that domain to the command, such as:

setup /pd:sales.neilhobson.com

To successfully complete this process you must be running the command from an account that has Domain Admin rights. You may be thinking that this could be a laborious process if you have many domains across your Active Directory infrastructure. Fortunately, you can prepare all domains in one go via the setup /PrepareAllDomains command, or setup /pad for short. Obviously, to prepare all domains the account you use must be a member of the Enterprise Admins group.

Running the setup /pd process for just the sales.neilhobson.com domain can be seen in Figure 28.

Figure 28: Running The Setup /pd Process

Note the warning message which, in this case, has occurred because I have not configured a domain Recipient Update Service in the root domain.

What exactly does the domain preparation process do and how can you check for success? Essentially the process assigns various permissions and also creates additional objects that you can check visually. For example, in the domain that has been prepared you will see a new group called Exchange Install Domain Servers. To see this group, bring up the Active Directory Users and Computers snap-in and make sure that advanced features are being displayed by selecting the Advanced Features option from the View menu. Select the Microsoft Exchange System Objects container from the left-hand pane and in the right-hand pane you should be able to locate the Exchange Install Domain Servers group as you can see from Figure 29.

Figure 29: Exchange Install Domain Servers Group

Back in your root domain, locate the Exchange Servers group found in the Microsoft Exchange Security Groups Organizational Unit and bring up its properties. On the Members tab, confirm that the Exchange Install Domain Servers group from the child domain that has just been prepared is a member of this group, as you can see from Figure 30.

Figure 30: Membership of The Exchange Servers Group

You will notice in Figure 30 that the root domain’s Exchange Install Domain Servers group is already a member of the Exchange Servers group. This is because the setup /p process, which had to be run in the root domain, automatically prepared this domain. As you can see, the presence of the Exchange Install Domain Servers group is a good indication that the domain preparation process has run and has completed successfully.

However, there are other things that you can check to be sure. The domain preparation process also updates one of the properties of the Microsoft Exchange System Objects container as you are about to see. By running ADSIEdit and connecting to a domain controller in the child domain, it’s possible to bring up the properties of the Microsoft Exchange System Objects container as you can see from Figure 31. I won’t detail all the steps for doing this as use of ADSIEdit is covered in the previous parts of this article. All I will say is that you need to connect to the domain naming context, locate the Microsoft Exchange System Objects container, right-click it and choose Properties from the context menu. In the resulting window, scroll down until you find the objectVersion attribute.

Figure 31: objectVersion Attribute

In Figure 31 you can see a value of 6936 which is the value assigned after Exchange 2003 RTM has been installed. Once you have performed the Exchange 2007 domain preparation process you should see this number change. For Exchange 2007 RTM it’s 10628 whilst for Exchange 2007 SP1 it’s 11221.

Finally, there is one last check that you can make which Microsoft does detail in its documentation. After the domain preparation process for Exchange 2007, the Exchange Servers Universal Security Group is granted permission on the Manage Auditing and Security Log found in the domain controller’s security policy.
To locate this, perform the following steps:

Choose Start and then Administrative Tools

In the Administrative Tools folder, choose Domain Controller Security Policy.

Under Security Settings, expand Local Policies and then select User Rights Assignment. In the right-hand pane you should now see the policies and the policy settings listed as shown in Figure 32.

Figure 32: User Rights Assignment

Scroll down the list of policies until you reach the policy called Manage auditing and security log. Double-click this policy which brings up the properties window and note that the Exchange Servers Universal Security Group now has permissions set as shown in Figure 33.

Figure 33: Exchange Servers USG Permissions

Summary

There you have it, all four Active Directory preparation steps covered; how to perform the steps and what to look for. I must admit that I have taken the time to write these four steps over five parts of this article which does seem a lot. However, I’ve felt that it has been useful to explain the preparation processes in some depth with plenty of screen shots since these processes are vital to a successful deployment of Exchange 2007. If you’ve still to deploy Exchange 2007, hopefully this should help you understand what is going on during these processes. If you’ve already deployed Exchange 2007 but not yet taken any of the Microsoft exams, note that the skills being measured include Active Directory preparation.

A Closer Look at Preparing Active Directory for Exchange 2007 (Part 4)

Introduction

This is the fourth part of an article series covering the preparation of Active Directory to receive Exchange 2007. So far in parts one to three we’ve looked at the preparation of the legacy permissions, followed by the preparation of the schema. Throughout these three parts we’ve also looked at how to confirm each step has completed successfully, using additional tools such as log files, LDP.EXE and ADSIEdit. Some administrators consider it important to confirm that the various processes have completed successfully rather than just relying on ‘success’ messages given at the end of each step.

We are now going to continue or look at the overall preparation process by examining what is required for the step known as Active Directory preparation.

Preparing Active Directory

The third of the four steps covered in this article is the step where Active Directory is prepared by the creation of various objects and the assignment of further permissions. As we’ve already seen in the other parts of this article, the running of one particular command will execute the steps of the previous command if that previous command hasn’t been run individually, and the particular command we’re about to discuss is no different. In other words, this command will automatically prepare the legacy permissions and the schema if this hasn’t already been done.

The command to use to prepare Active Directory is setup /PrepareAD or setup /p for short. If you are coexisting with legacy versions of Exchange then the organization container will already exist within Active Directory. If you are installing Exchange for the first time, then you will need to add the /OrganizationName or /on switch and specify the chosen Exchange organization name. For example:

setup /p /on:Exchange

This command will ensure that Active Directory is prepared with an Exchange organization name of Exchange. You can see from Figure 23 what the process of preparing Active Directory looks like.

Figure 23: Running Setup /p

Since this command is not making any schema changes you do not need to be a member of Schema Admins to run it in the same way as you did with setup /ps. However, you still need to be a member of Enterprise Admins so factor this in when considering who will be running this command. Also, like the setup /ps process, you still need to execute this command on a server that is located in the same Active Directory site and domain as that of the schema master. Although you are not making schema changes, the setup /p process writes the changes specifically to the schema master before propagation around the remainder of the domain controllers.

You have seen throughout the other parts of this article that you can use tools such as LDP and ADSIEdit to check that processes have completed successfully. With setup /p, several very visible changes are made that you can see from applications such as Active Directory Users and Computers and Exchange System Manager. For example, in the root domain of your Active Directory infrastructure you will see a new Organizational Unit (OU) created called Microsoft Exchange Security Groups and within that OU you will see the following six security groups:

Exchange Organization Administrators
Exchange Public Folder Administrators
Exchange Recipient Administrators
Exchange Servers
Exchange View-Only Administrators
ExchangeLegacyInterop

You can see this OU and the groups within it in Figure 24. Remember, this OU is only created in the root domain of your Active Directory infrastructure. In my case, this is the neilhobson.com domain so this means that this OU won’t be seen in the sales.neilhobson.com domain.

Figure 24: Microsoft Exchange Security Groups OU

Also, after having performed the setup /p process, it may become very apparent to administrators of Exchange 2000 or Exchange 2003 that something has changed and the upcoming deployment of Exchange 2007 is just around the corner. This is because the new Exchange 2007 administrative and routing groups will now be present in the Exchange System Manager as you can see from Figure 25.

Figure 25: Exchange 2007 Administrative and Routing Groups

The Exchange Administrative Group (FYDIBOHF23SPDLT) and Exchange Routing Group (DWBGZMFD01QNBJR) objects are created to house all Exchange 2007 servers so that legacy versions of Exchange will understand how to contact the new Exchange 2007 servers. You will not see these administrative and routing group objects in the Exchange 2007 Management Console since the concept of administrative and routing groups are deprecated features as far as Exchange 2007 is concerned. Obviously there will be no server objects under the Exchange 2007 administrative group at this stage since we’ve not actually installed an Exchange 2007 server yet, but nevertheless the administrative and routing group objects exist at this time. This is confirmed in Figure 25 where you will notice there is no Servers container directly under the Exchange Administrative Group (FYDIBOHF23SPDLT) object.

Finally, one other easy check you can make at this time is to examine the contents of the Exchange organization container using ADSIEdit. Consider Figure 26 below which is the container contents prior to the running of setup /p. Then compare this to Figure 27 which is the container after the running of setup /p. Note that there are more items in Figure 27, such as the Client Access, ELC and UM containers. These are created as a result of running setup /p.

Figure 26: Organization Container Prior to Setup /p

Figure 27: Organization Container After Setup /p

The setup /p process also configures many additional permissions, far too many for me to list here. Checking the above configuration elements should be enough for you to be sure that the process has completed successfully. As ever, don’t forget that you can check the setup logs for much more additional information.

In the last part of the process which I’ll cover in the final part of this article series we are going to be looking at the preparation of the Active Directory domains. You should note that the setup /p process actually prepares the domain from which it is run, so that’s one less domain to worry about later on.

One word of caution about the setup /p process is the fact that Microsoft states this process must contact all domains within your Active Directory forest, even those that have not had legacy Exchange servers installed into them; you will need to plan for this if you have a large or complex Active Directory infrastructure.

Summary

In this penultimate part of the article series, we have looked at the step of preparing Active Directory and what to check for to make sure that this command has completed correctly. Several key changes are made during this step, such as the creation of the Microsoft Exchange Security Groups OU in the root domain, as well the creation of legacy administrative and routing groups. In the final part of this article we’ll be looking at the last step, namely the preparation of Active Directory domains.

A Closer Look at Preparing Active Directory for Exchange 2007 (Part 3)

Introduction

Over the course of the first two parts of this article we have looked at the first step required when preparing Active Directory to receive Exchange 2007, namely the preparation of legacy Exchange permissions. For those of you that are not coexisting with either Exchange 2000 or Exchange 2003 this step will not be required. However, throughout the first two parts of this article there is extremely useful information that may prove of worth to you in the future, such as using tools such as LDP to determine if the specified permissions have been set correctly. If you have skipped the first two parts of this article because you are not coexisting with either Exchange 2000 or Exchange 2003, I still urge you to read these parts anyway.

Now it is time to move on with the rest of the Active Directory preparation steps, starting with the preparation of the Active Directory schema.

Preparing The Schema

Like legacy versions of Exchange such as Exchange 2000 and Exchange 2003, Exchange 2007 requires updates to the Active Directory schema in order to operate. Therefore, you will need to ensure that the account you use for the following process is a member of the Schema Admins group. In addition, the account also needs to be a member of the Enterprise Admins group to successfully complete the schema update process. You will likely need to plan ahead for making this change since, in secure environments, it is likely that membership of these groups is not given out at a moment’s notice. Finally, note that you must have access to the Active Directory domain controller running the schema master role to run this process since you are making changes to the schema. Specifically, run the schema preparation process from a server that is located in the same Active Directory site and domain as that of the schema master. If you don’t, the organization checks portion of the schema update process will fail with this descriptive error:

Setup needs to contact the Active Directory schema master but this computer is not in the same Active Directory domain as the schema master (DC=domain,DC=com).

Setup encountered a problem while validating the state of Active Directory: Exchange organization-level objects have not been created, and setup cannot create them because the local computer is not in the same domain and site as the schema master. Run setup with the /prepareAD parameter on a computer in the domain {domain} and site {site name}, and wait for replication to complete.”

In parts one and two of this article we have already prepared the legacy permissions via the setup /pl command since we are coexisting with Exchange 2003. However, if for some reason you have not issued this command and you are going to coexist with legacy versions of Exchange, note that it will be performed as part of the schema update process that I am about to cover.

In this article we are coexisting with Exchange 2003 so it is worth pointing out that the Exchange 2007 schema update also includes the schema updates applicable to both Exchange 2000 and Exchange 2003.

To prepare the schema with the Exchange updates, you use the following command:

setup /PrepareSchema

As with the command used for the preparation of the legacy permissions there is a shortened version of the schema update command. It is:

setup /ps

In my example environment I am going to run setup /ps on the root domain controller called AD-ROOT. You can see the result of running this command in Figure 15 where the updates have been successful.

Figure 15: Successful Schema Update

Updating the schema can take a few minutes. If you want to check that the process is running, then during the Extending Active Directory schema portion of the process navigate to the TEMP folder of the user account that you are using to perform the schema update process. By default, the user’s TEMP location will be the %USERPROFILE%\Local Settings\Temp folder. You can see what this looked like during my schema update in Figure 16.

Figure 16: Contents of The TEMP Folder

As you can see from Figure 16 there are three temporary files in this location at the time I captured the screen shot. The file of interest is highlighted, namely ldif.log. This file, at the time of the screen capture, contained the contents of one of the specific LDIF files from the Exchange 2007 source files and was the LDIF file being imported at the time. If you monitor the contents of the TEMP folder during the schema update process, you will see the ldif.log file alternate between 0KB and around 3KB as the different LDIF files are processed. Figure 17 shows you the contents of the ldif.log file at a specific point in time during the schema update process.

Figure 17: Contents of LDIF.LOG

Active Directory Replication

It is recommended that you check Active Directory has replicated the changes throughout your environment once you have made the changes in any of the steps in this article series. To confirm whether the schema update has been applied to your domain controllers, you can check the value of rangeUpper on the ms-Exch-Schema-Version-Pt attribute using ADSIEdit when connected to a specific domain controller. This attribute is used to track the version of the schema that has been installed and since the rangeUpper value for Exchange 2007 SP1 is 11116 that is the value we need to look out for. If you are reading this article and Microsoft has released a new service pack for Exchange 2007, this value will be different so be sure to check out what the new value should be. Here’s how to confirm that a domain controller has this value set. This process assumes you’ve installed the Windows Support Tools since that’s where you obtain ADSIEdit.

Run ADSIEdit.msc

In the left-hand pane of the main ADSIEdit window, expand the Schema object and then select the next Schema object that appears below it.

In the right-hand pane, locate the CN=ms-Exch-Schema-Version-Pt attribute, right-click it and select Properties from the context menu.

In the resulting properties window, scroll down the list of attributes until you reach the rangeUpper attribute. Check that the Value column shows 11116 as you can see in Figure 18.

Figure 18: Value of rangeUpper

Another tool supplied with the Windows Support Tools that is useful for checking Active Directory replication is the Active Directory Replication Monitor, replmon.exe. Here is what to do to use this tool:

Run Replmon.exe and you will be presented with the main Replmon window as shown in Figure 19.

Figure 19: Replmon Main Window

In the left-hand pane, right-click Monitored Servers and choose Add Monitored Server… from the context menu. The Add Monitored Server wizard opening window appears.

In this opening window, select the relevant option to either add the domain controller by name or search a specific domain. Since I only have a few domain controllers in my lab, I’ll choose to add the server by name.

In the Add Server to Monitor window, the option available is Enter the name of the server to monitor explicitly and therefore in this field I enter the Fully Qualified Domain Name (FQDN) of a domain controller to monitor as you can see in Figure 20.

Figure 20: Adding a Specific Server

After you click Finish, you will be back at the main Replmon window but this time a connection has been made to the chosen domain controller. Repeat this process for other domain controllers as required and you should see a screen similar to the one shown in Figure 21.

Figure 21: Replmon With Monitored Servers

It is now possible to check the replication of the various containers by expanding them and checking the information presented in the right-hand pane. For example, look at Figure 22 where you can see that replication was failing before the successful update.

Figure 22: Replication Failure and Success

You may remember that in part one of this article we briefly covered the fact that Exchange creates setup log files during the various Active Directory preparation tasks. If you have looked again in the C:\ExchangeSetupLogs folder during the steps listed in part two of this article, you may have noticed that the schema update process also creates the PowerShell script called Install-ExchangeOrganization-{DATE}-{TIME}.ps1. Examining the contents of these programmatically generated PowerShell scripts can help your understanding of the Exchange setup process, so it’s worth checking them out.

Summary

Here in part three of this article we have covered a very important part of the Active Directory preparation process, namely the preparation of the schema. It can be said that all parts of the preparation process are vital to the successful running of Exchange, but there is always that something extra about updating your schema. It is important to verify that the schema has updated correctly so use the steps in this article to do so.

A Closer Look at Preparing Active Directory for Exchange 2007 (Part 2)

Introduction

In part one of this 5-part article, we started our look at the four steps required to prepare Active Directory to receive Exchange 2007. The first step is the preparation of the legacy Exchange permissions in situations where you are coexisting with legacy versions of Exchange, such as Exchange 2000 or Exchange 2003. In part one we got as far as running setup /pl only to be presented with a few issues that need resolving before the process can complete. These issues were presented to us within the command window but as you will see there are other ways to see what has occurred when running these preparation commands.

Setup Log Files

As with all the preparation processes that we will cover in this article, log files are created that you can examine after the process has completed should there be any issues. The file to examine is the ExchangeSetup.log file that is created in the C:\ExchangeSetupLogs folder as you can see from Figure 3.

Figure 3: Exchange Setup Log

If you open the ExchangeSetup.log file in notepad you will see the same errors and warnings in the text file that you saw in the command window that was shown in part one of this article. These errors are highlighted in Figure 4:

Figure 4: Inside The Exchange Setup Log

You should note that some errors ‘hide’ other errors that may be present within your legacy Exchange organization. For example, once I have added the account that I am using to the Enterprise Admins group and also switched the legacy Exchange organization to native mode, re-running the setup /pl command produces a new error that you can see in Figure 5. Here I am informed that one or more Exchange 2003 servers in the legacy environment does not have Exchange 2003 Service Pack 2 installed on it. The moral of the story here is to make sure that you have fully documented your legacy Exchange environment and fixed any issues that may prevent the preparation of the legacy Exchange permissions prior to running this command. If you have not, be prepared to run this command many times to discover any issues that you may have missed.

Figure 5: Exchange 2003 SP2 Missing Error

Eventually you should be able to run the setup /pl command through to successful completion as shown in Figure 6, although note in this case the warning regarding .NET Framework 2.0 SP1 is still there which proves that in this case the warning message does not actually prevent you from proceeding.

Figure 6: Successful Legacy Permissions Process

Examining the Permissions Set

So how might you go about proving that the legacy permissions preparation has completed successfully? Well, the first thing to remember is that the log files are your friends here as we discussed in part one of this article. Firstly, check through the ExchangeSetup.log file and check that the processes complete without errors.

Next, note that within its documentation Microsoft has provided detailed information on the Access Control Entries (ACEs) that are added by this process. The question remains on how we can determine if these ACEs have been added. Let’s look a bit more closely at the ExchangeSetup.log file produced during the setting of the legacy Exchange permissions. An extract is shown in Figure 7. Note that I have set Notepad with the Word Wrap option so that you can see the whole of each entry in the log file.

Figure 7: ACE Entries in ExchangeSetup.log

What you can see in Figure 7 is the various ACEs that have been applied. Taking the first entry listed, you can see that a WriteProperty ACE has been added to the domain itself (DC=neilhobson,DC=com). Also of interest is the Globally Unique Identifier (GUID) that you can see at the end of the entry as you shall see later in this article. This GUID is 1f298a89-de98-47b8-b5cd-572ad53d267e. If you look further down the log file you can see that a ReadProperty and WriteProperty ACE has been applied to the AdminSDHolder object.

Microsoft has detailed in various whitepapers a method for confirming that these ACEs exist and so for article completeness I will go over that process here to demonstrate in my lab environment what to do. You can use the LDP tool that is supplied as part of the Windows Support Tools to check the ACEs that are added by the legacy permissions preparation process. I will not cover all the ACEs that are added but rather I will focus on the two that I mentioned in the previous paragraph, namely the WriteProperty on the domain object and the WriteProperty/ReadProperty set on the AdminSDHolder object. Let’s start with the ACE added to the domain object:

Run LDP.EXE.

At the main LDP window, click Connection then Connect…

In the Connect window, enter the name of the root domain controller and then click OK. This window is shown in Figure 8.

Figure 8: LDP Connect Window

Back at the main LDP window, click Connection then Bind…

In the Bind window, enter the username, password and domain of a user account that has permissions, such as the root domain Administrator account. This window is shown below in Figure 9.

Figure 9: LDP Bind Window

The right-hand pane should now inform you that you have been authenticated. Click View and then Tree and in the Tree View window, just leave the BaseDN field blank and click OK.

Back at the main LDP window, you should see your root domain listed at the top of the left-hand pane as shown below in Figure 10.

Figure 10: LDP Tree View

Before you go any further, clear the contents of the right-hand pane by clicking Connection and then New. This just makes reading the information in the next step much easier.

Right-click the domain at the top of the left-hand pane and choose Advanced, then Security Descriptor from the context menu as shown in Figure 11.

Figure 11: Security Descriptor Menu Option

In the resulting Security Descriptor window, leave the Dn field as it is and select OK.

The right-hand pane will now fill with lots of information detailing the ACEs. In my lab there were a total of 40 ACEs defined. Your screen should look similar to that shown in Figure 12.

Figure 12: ACEs Displayed

If you scroll through the list of ACEs you should find the entry for the WriteProperty ACE set on the domain object as you can see from Figure 13. Here you can see the fact that this is a WriteProperty ACE (from the text ACTRL_DS_WRITE_PROP) and that the security identifier granted this entry is the Exchange Enterprise Servers group. Also note that the GUID listed earlier is present.

Figure 13: Domain ACE For The Exchange Enterprise Servers Group

Let’s now confirm whether we can see the ACE set on the AdminSDHolder object. Leave LDP open where it was and follow these steps:

Click Connection then New to clear the right-hand pane.

In the left-hand pane, expand the domain object and then double click the System object. Directly under the System object you will see the AdminSDHolder object.

Click Connection then New to clear the right-hand pane again.

Now right-click the AdminSDHolder object and choose Advanced and then Security Descriptor exactly as you did earlier in this article.

At the resulting Security Descriptor window, leave the Dn field as it is and choose OK.

You will again be presented with lots of ACE information in the right-hand pane. You can now scroll through the list of entries and find the one that sets the ReadProperty and WriteProperty for the Exchange Enterprise Servers group as you can see from Figure 14.

Figure 14: AdminSDHolder ACE For The Exchange Enterprise Servers Group
That completes our look at the setting of the legacy Exchange permissions. I know that I have spent a lot of article space on preparing the legacy permissions but hopefully this is warranted in that this section gives you plenty of information on how to confirm how you can check whether ACEs have been applied or not.

As you will see throughout this part and the next part of the article, you really should wait for Active Directory replication to occur before proceeding with the next portion of setup and there are ways to check this. I will detail this process after the next step, preparing the schema, since some readers of this article may have skipped this article and part one of the article series if they are not coexisting with legacy versions of Exchange.

Summary

Here in part two of this article we’ve finished our look at preparing the legacy Exchange permissions, covering how to tell that the process completed correctly. In part three we will look at the steps required to prepare the Active Directory schema and cover how to tell that this step has completed successfully along with how to check Active Directory replication.

Using Exchange Server 2007 Built-in Scripts - Part 2: Generating Transport AntiSpam Agent Reports

Introduction

In our last article we saw some built-in scripts related to Public Folder management. We also saw that all Exchange default scripts are located under the scripts folder within the Exchange Server installation folder.

In this article we are going to go over some scripts that enable administrators to get some reports from anti-spam agents and we are also going to use some extra scripts to improve the admin experience in order to create better reports.

Generating HTML output from the Exchange Management Shell …

First of all, let’s use the PowerShell Scriptacular that is a set of useful scripts that can be used with PowerShell and also with the Exchange Management Console. This set of scripts was developed by Vivek Sharma and Mihai Jalobenau during their work on Exchange Management Shell.

To download this pack we can check the viveksharma.com: techlog where you can download the latest version. The current Scriptacular has the following scripts:

Addfakeservers.ps1
removefakeservers.ps1
balancemailboxes.ps1
generate.ps1
cleanup.ps1
initvars.ps1
mailstorm.ps1
mailstorm2.ps1
multi-matrix.ps1
out-email.ps1
out-html.ps1
out-ie.ps1

In order to install Scriptacular just download the zip file from Vivek’s web site and extract all the content into the Scripts folders of the Exchange Server 2007 installation path. If you installed Exchange Server using the default settings it should be at c:\program files\Microsoft\Exchange Server\Scripts folder.

In this article we are going to work with the last two scripts of that list which are: out-html.ps1 and out-ie.ps1. Both of these can be used with an extra (pipe) at the end of any PowerShell commandlet, the first one generates the output in HTML format and the second one gets the output and displays it in an Internet Explorer session.

Now, that we know how to install it and which scripts we are going to work on, let’s see how to use them. Let’s say that we create a daily report of our Mailbox statistics and we have been running Get-MailboxStatistics select DisplayName,ItemCount Export-csv c:\report.csv. Now, let’s improve the output format using Scriptacular by just adding the following two extra commands:

Get-MailboxStatistics select DisplayName,ItemCount out-html out-ie

Now you can compare both outputs as shown in Figure 01 and Figure 02.

Figure 01: Output created by out-html out-ie

Figure 02: Output created by Export-csv cmdlet

We can go a little bit further and create a script to generate an html report using some scripts that we have just seen. The following three lines can be saved as a .ps1 extension and it can be executed daily, the result will be a file name containing month and day of the execution in the name, the content of this file will be the output of Get-MailboxStatistics.

$VarDay = (Get-Date).day

$VarMonth = (Get-Date).month

Get-MailboxStatistics out-html out-file c:\reports\MailboxStatistics-$VarMonth-$VarDay.html

Creating Anti-spam usage reports…

Before diving in the built-in scripts about anti-spam agents we have to be aware of how the transport agents record their actions in Exchange Server 2007. All operations performed by some anti-spam agents are recorded in text files in the directory AgentLog and this folder can be found at \TransportRoles\Logs\AgentLog\, and by default any Hub Transport and Edge Transport Server writes information in that folder. The only transport agents that are able to write in this folder are: Connection Filter, Content Filter, Edge Rules, Recipient Filter, Sender Filter and Sender ID agents.

The content of the AgentLog folder is a bunch of log files in a circular logging mode which means that when they reach the age limit of 30 days or 250MB (whichever comes first) in total they will be automatically removed. They are generated by day or 10MB whichever comes first, as well. An Exchange Administrator can enable or disable the AgentLog files but there is no way to configure path, age limit, maximum individual size, and maximum size for the directory. Each agent log file has the following data information:

Timestamp
SessionId
LocalEndpoint
RemoteEndpoint
EnteredOrgFromIP
MessageId
P1FromAddress
P2FromAddresses
Recipient
NumRecipients
Agent
Event
Action
SmtpResponse
Reason
ReasonData
Diagnostics

We can use notepad to open the log files (Figure 03) and all the information can be read from that file, we can also use Excel to separate the content in different columns.

Figure 03: Agent Log file opened in notepad

There is another way to read and sort information from those log files easily which is by using the Get-Agentlog cmdlet (Figure 04). The agent-log will display the same information but in a better way. We can take a closer look at the output of the get-AgentLog output and we are able to check who sent the message, who was supposed to receive the message, the action taken, and also the SMTP Response and Reason why the message was not delivered.

Figure 04: Get-Agentlog cmdlet output

Okay, now that we know how the anti-spam agents record the information and we also know how to use out-html and out-ie we can add one more item to our mix: anti-spam scripts that generate some reports about anti-spam activity .

The following anti-spam scripts can be used to gather information from Agentlog, as follows:

SCL Histogram: We can retrieve the information logged by the Content Filter agent and group it by SCL value. In order to sort the output, we can use the following cmdlet (Figure 05)

.\get-antispamSCLHistogram.ps1 sort-object Name

Figure 05: SCL Histogram

Top Blocked Sender Domains: Lists the top N sender domains that were blocked by anti-spam transport agents and we also need to specify if this information is coming from p1 or p2, where P1 information comes from message envelope (from header field) and p2 comes from message header (from header field). We can use the following command, as shown in Figure 06.

.\get-AntispamTopBlockedSenderDomains.ps1 p1

Figure 06: Top Blocked Sender Domains

Filtering Report: This script allows the administrator to list which agents are responsible for any of these options:

MessagesRejected
MessagesDeleted
MessagesQuarantined
Connections
Commands

For example, let’s use the following command to retrieve a list of the agents that are rejecting messages, as shown in Figure 07.

.\get-AntispamFilteringReport.ps1 messagesrejected

Now we know that the Content Filter is responsible for 546 messages blocked in our organization.

Figure 07: Filtering Report

Top Blocked Sender IP: Using this script we can list the top N blocked Sender IP, we can use the switch –top and specify how many entries we want to see in the output of the script, in the following script (Figure 08) we are retrieving the 20 top IPs that were blocked by our anti-spam agents, as follows:

.\Get-AntispamTopBlockedSenderIPs.ps1 –top 20

Figure 08: Top Blocked Sender IP

Top Blocked Senders: Shows a list of the top N blocked senders, we also have to specify if we are listing from p1 or p2 field, as shown in Figure 09.

.\get-AntispamTopBlockedSenders.ps1 p1

Figure 09: Top Blocked Senders

Top RBL Providers: Will list the top N Real time Block List Providers, the default value for top is 10 which is not applicable in the current environment because I am using only 2 RBLs, as shown in Figure 10.

.\Get-AntiSpamTopRBLProviders.ps1

Figure 10: Top RBL Providers

Top Recipients: This script gets the top N recipients that were blocked by anti-spam agents. To get the top 10 the following command can be used, as shown in Figure 11.

.\Get-AntispamTopRecipients.ps1

Figure 11: Top Recipients

Validating the Exchange Server installation

There is also a script which improves the reading of Exchange Setup Logs. During the installation process the setup creates a folder called C:\ExchangeSetupLogs and adds a lot of information that is being processed in the background into the ExchangeSetup.log file. We can go over that file using any text editor because it is a simple text file, however we can use GetSetupLogs.ps1 to see the same information. The difference is that it shows the warning and critical errors in different colors and it may help you in understanding installation troubleshooting issues.

To validate the setup installation log using the built-in script, just run .\Get-SetupLog.ps1 from the Scripts folder, as shown in Figure 12.

Figure 12: .\Get-SetupLog.ps1

There are some switches that may be helpful, such as:

tree: where the output will be in a tree format
error: only errors and warnings will e displayed

Conclusion

In this article we saw how the built-in anti-spam scripts gather information from agentlog to create some reports, we also saw how to use Scriptacular package to enable html and Internet Explorer output from a PowerShell session.

Finally, we can combine the out-html and out-ie with any of the scripts shown in this article in order to get better view of the anti-spam transport agents.

A Closer Look at Preparing Active Directory for Exchange 2007 (Part 1)

Introduction

Before you dive in and start installing Exchange 2007, you should take the time to understand the steps required to prepare your Active Directory environment to receive Exchange 2007. In this four-part article I will be taking a more in-depth look at what these preparatory steps are and, perhaps more importantly, what tools and processes you can use to determine whether they have completed successfully or not.

Before we get going there are one or two important things to discuss first. One statement that I’m sure you must have heard by now is that Exchange 2007 is only supported on 64-bit hardware. You are probably also aware that there is a 32-bit version of Exchange 2007 available for non-production scenarios such as training and lab environments. As you will see later in this article, some of the commands required to prepare Active Directory for Exchange 2007 must be run on specific servers that aren’t typically Exchange 2007 servers and could therefore be running on 32-bit hardware. If that’s the case and it’s known that Exchange 2007 isn’t supported on 32-bit hardware, how can these commands be performed with full support from Microsoft? In these cases, you should be aware that Microsoft does support the use of the 32-bit version of Exchange 2007 for performing specific Active Directory preparation tasks, such as extending the schema. With that in mind, make sure you have a copy of the 32-bit version of Exchange 2007 handy if you know that you have, say, only 32-bit domain controllers throughout your environment.

You will note throughout the steps in this article that it’s possible to have the process you are currently running perform the previous processes if they have been omitted. For example, if you forget to prepare the legacy permissions first, this step will be automatically performed when the schema is updated. You might wonder, then, if it’s better to just perform as few steps as possible rather than do each step individually. Personally I prefer to perform each step individually, based largely on the notion that I can check each step along the way, confirming that each process has completed correctly and resolving any errors as I go. Additionally, since some of the steps require different permissions levels, it’s possible to perform each step with the minimum permissions required, something that can be useful in larger and more secure environments.

Let’s look at the sample environment that I’ve constructed for this article. The environment consists of an empty forest root domain, neilhobson.com, and a single child domain, sales.neilhobson.com. The child domain contains an Exchange 2003 server and the associated user accounts that have mailboxes on this Exchange 2003 server. A new Windows 2003 server has been deployed into the child domain and will become the first Exchange 2007 server installed into this particular organization.

Preparation Commands

If you need to confirm the various setup parameters at any time, just run the following command from your Exchange source files:

setup.com /help:PrepareTopology

You can see the output in Figure 1; these are the commands that we will be covering within this article. Note the option for all switches to use a specific domain controller if required.

Figure 1: Setup.com Switches for Preparing Active Directory

With the commands in mind, let’s get going and look at them in detail.

Preparing Legacy Permissions

The first step to consider is whether your Exchange 2007 infrastructure is being installed into an existing Exchange 2000 or Exchange 2003 organization. If it is, you need to prepare legacy permissions. The reason for this centers largely around the Recipient Update Service (RUS) used in Exchange 2000 and Exchange 2003. I’m sure you know what the RUS does and so I won’t go into detail here, but if you don’t happen to know then you can check out Mark Fugatt’s or Rodney Buike’s articles on the subject. Due to a change in Exchange 2007, the RUS does not have the correct permissions to update email attributes belonging to users and therefore the process of preparing legacy permissions described in this section addresses this issue.

To prepare the legacy permissions you need to use the following command:

setup /PrepareLegacyExchangePermissions
That’s quite a lot of typing and the potential is there for you to input a few typing mistakes. Fortunately you can achieve the same result with a shorter command. I don’t know about you but if I can shorten my time at the keyboard and remove the potential for typing mistakes then that’s what I’ll do. Therefore, I’ll be using the shortened version within this article. It is:

setup /pl

Running this command will attempt to update all the domains in your forest. If you only have a single domain or if you want to prepare the legacy permissions in a specific domain, then the command to use is:

setup /pl:

For example, if I want to update the sales.neilhobson.com domain only, then I’d use this command:

setup /pl:sales.neilhobson.com

If you are updating a single domain, then the account you use to run this command must be a member of Domain Admins in the relevant domain and must also have been delegated the Exchange Full Administrator role. For those of you with multiple domains containing legacy Exchange servers, there are additional areas to consider and watch out for. If you have multiple domains containing Exchange 2000 or Exchange 2003 servers, you will have previously run the Exchange 2000 or Exchange 2003 DomainPrep process in each of these domains. It’s in these domains that the legacy permissions process must do its work and therefore the server on which you run the setup /pl command must be able to contact each of these domains. To run correctly in a multiple domain scenario, the account you use must be a member of the Enterprise Admins group.

In my example environment, I’m going to run the setup /pl command from my newly installed member server AD-CHE2K7. You can see the result of doing this in Figure 2.

Figure 2: Setup /pl Organization Checks

As you can see above in Figure 2, organization checks are performed first before the actual permissions are set. These checks ensure that the setting of the permissions can proceed and anything preventing this will be indicated to you on screen. You can see from Figure 2 that there are three issues highlighted:

There is a recommendation that .NET Framework 2.0 SP1 is installed; this is a recommendation only and you can therefore proceed without implementing it. However, you really should be following Microsoft recommendations such as this.

The legacy Exchange organization is not in native mode, something that prevents the setting of the legacy Exchange permissions. This is one of the main requirements of your legacy Exchange environment before introducing Exchange 2007, so make sure that you’ve made the switch to native mode before attempting to set the legacy permissions.

Finally note the information stating that the account Iam using is not a member of the Enterprise Admins group, which is a requirement in this case since I indicated that I wished to update all domains and not any specific domain.

Summary

That is it for the first part of this article. Here I have covered the background requirements for running the command that prepares the legacy Exchange permissions and we have seen a few common issues crop up. In part two, I will complete the look at preparing legacy permissions including examining the setup logs and also how you can determine whether this process ran successfully other than just relying on the setup logs.

Using Exchange Sever 2007 Built-in Scripts - Part 1: Managing Public Folder Replicas and Client Permissions

All scripts shown in this article can be found under the Scripts folder of any Exchange Server 2007 installation folder.
Public Folders is one Exchange feature that offers multiple management options. We will take a look at some of the principal management methods and then use some built-in scripts to demonstrate how we can manage some Public Folder features through them.
With Exchange Server 2007 SP1 we can use a tool called the Public Folder Management Tool which allows an administrator to create and manage Public Folders and System Folders in the same view, as shown in Figure 01.

Figure 01

We can use the Exchange Server 2003 Exchange System Manager to manage Exchange Server 2007 Public Folders. We can install the Exchange System Manager tool in a variety of operating systems (Windows 2000 Server, Windows Server 2003 or Windows XP), we just need to follow some prerequisites which depend on each operating system.
We do not need to have an Exchange Server 2003 in place to install the management tool. Let’s say that we have a pure Exchange Server 2003 and a Windows Server 2003, we just need to install IIS and put the Exchange Server 2003 installation disk on the drive, click on Exchange Deployment Tools, and then click on Install Exchange System Management Tools only. Follow the installation process and make sure that you select Exchange System Management Tools during the components selection.
One last thing to keep in mind to access the Public Folders using Exchange Management Tools is to disable the SSL requirement for the ExAdmin virtual folder.

-Log on to the Exchange Server 2007 box where the Public Folders were deployed.
-Open IIS (Internet Information Services Manager).
-Expand Web Sites.
-Expand Default Web Site.
-Right-click on ExAdmin.
-Click on the Directory Security tab.
-Click on the last button Edit... under the Secure Communications area.
-Uncheck the option Require Secure Channel (SSL).

Now, we can go back to the server which has the Exchange System Manager installed and expand the Public Folders (Figure 02). Do not forget to install Service Pack 2 on top of this installation because it adds a lot of useful Public Folders management resources.

Figure 02

We also have a third good option which is using the PFDavAdmin tool (Figure 03), where we can manage replicas, client permissions, limits, etc. In order to use PFDavAdmin we can download it from the Microsoft Download site.

Figure 03

By default any Exchange Server 2007 installation has a subfolder called Scripts where we can find a lot of useful scripts to help us out in some daily administrative tasks. In this article we are going over the scripts related to Public Folder management. These are all scripts that we are going to use in this article:

-AddReplicaToPFRecursive
-RemoveReplicaFromPFRecursive
-ReplaceReplicaOnPFRecursive
-MoveAllReplicas.ps1
-AddUsersToPFRecursive.ps1
-ReplaceUserWithUserOnPFRecursive.ps1
-ReplaceUserPermissionOnPFRecursive.ps1
-RemoveUserFromPFRecursive.ps1

We will test these scripts in a scenario where we have three servers (srv-ex01, srv-ex02 and srv-ex03) and all of them have the Mailbox Server role installed and a Public Folder Database mounted and operational. We have some Public Folders hosted on the srv-ex01 server and in this article we are going to configure replication among these servers. The Public Folder in place is on the first server and has three Public Folders (Finance, IT and Sales), the top folder IT has four extra additional folders. The Public Folder structure can be seen in Figure 04.

Figure 04

Before using these scripts, let’s go over the general usage instructions. First of all, you can edit them and create your own scripts, you can also use the switch –help to get help and examples on how to use the script, and finally always use “./” plus the script name to run it through an Exchange Management Console session.
A last warning is to use them against Exchange Server 2007, the parameter Server in all of the scripts must be an Exchange Server 2007 box.

Managing Public Folder Replicas

The Public Folder hierarchy is replicated among all servers, but the content replication must be defined by the Exchange Administrator. We are going to use the AddReplicaToPFRecursive.ps1 script to add another server into the replication list of a top folder and all sub folders, that way all the information will be available in both servers. The following syntax can be used, as follows:
.\AddReplicaToPFRecursive.ps1 –server srv-ex01 –TopPublicFolder “\IT” –ServertoAdd srv-ex02

Time to validate if the script worked as expected, let’s use the Exchange Management Shell to get such information. We can use Get-PublicFolderStatistics –Identify “\IT” fl cmdlet and look at Replicas attribute (Figure 05) and we will see the two Public Folder databases where the information is being hosted. Both machines srv-ex01 and srv-ex02 have the same Public Folder Database name.

Figure 05

We can also remove replicas from a folder and its subfolders, using the following syntax:
./RemoveReplicaFromPFRecursive.ps1 –server -ToPublicFolder “\FolderName”-ServerToRemove

Sometimes an Exchange Admin has a replication in place with two servers and a new server joins the organization to remove one of the existent servers. We can use the following example where we have srv-ex01 and srv-ex02 replicating and we want to remove srv-ex02 and add srv-ex03 into the current replica list, as follows:

./ReplaceReplicaOnPFRecursive.ps1 –Server srv-ex01 -TopPublicFolder “\Foldername” –ServerToRemove srv-ex02 –ServerToAdd srv-ex03

And the last but not the least script is the MoveAllReplicas.ps1 where we can move all the Public Folders from one server to another. This operation will remove the server from all replicas tab. It is a very useful script when we are decommissioning a server. The syntax is pretty simple:

./MoveAllReplicas.ps1 –Server srv-ex02 –NewServer srv-ex03

Note:When using the MoveAllReplicas.ps1 script the System Folders are moved as well.

Managing Users Permissions on Public Folders

Okay, in the last section we saw how to configure Public Folder Replication, now we are going to configure some client permissions on Public Folders. Let’s use the Public Folder structure shown in Figure 06.

Figure 06

Let’s say that we have to add a user as Publishing Editor in all IT Public Folders and subfolders, we can do that using the AddUsersToPFRecursive.ps1 script, and where we just need to specify a set of parameters where we define which folder, user, and permission will be configured. This syntax can be used:

.\AddUsersToPFRecursive.ps1 –Server srv-ex01 –TopPublicFolder “\IT” –User Anderson.patricio –Permissions {PublishingEditor}

Using the cmdlet above the user Anderson.patricio will be assigned as Publishing Editor in all folders and subfolders of the IT folder structure. We can define a customized set of permissions in a public folder, such as CreateItems, ReadItems, CreateSubfolders and so forth. We can also define permissions based on Roles. Each role has a set of pre-defined permissions to be applied.

To validate if the permissions are in place, we can run this cmdlet:
Get-PublicFolderClientPermission \IT fl

Both steps are shown in Figure 07.

Figure 07

We can change the user permission in a folder structure using the script called ReplaceUserPermissionOnPFRecursive.ps1. Let’s say that we want to change the recent user that we have just added to be PublishingAuthor instead of Publishing Editor, in order to do that we can use the following syntax:

./ReplaceUserPermissiononPFRecursive.ps1 –TopPublicFolder “\IT” –User anderson.patricio –Permissions {PublishingAuthor}

We are also able to remove a user from a Folder and subfolder using the RemoveUserFromPFRecursive.ps1 script, as follows:

./RemoveUserfromPFRecursive.ps1 –TopPublicFolder “\FolderName” –user UserNametobeRemoved

You will be asked in each folder if you are sure you want to remove the specified user. Just say Y and hit enter to confirm.

Another possible option is to replace a current user listed on the Public Folder permissions for another user. This script does not play with the permission just changes one user for another. All permissions in place will not be changed.

./ReplaceUserWithUserOnPFRecursive.ps1 –TopPublicFolder “\FolderName” –UserOld UsertobeReplaced –NewUser NewUserName

Conclusion
In this article we have seen how to use the built-in scripts that come with Exchange Server 2007 to manage Public Folders. Using such scripts we are able to manage Public Folder replicas and client permissions using a single line script command.