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 LogIf 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:
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.
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 GroupThat 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.