Creating a Journal Rule in Exchange 2007

Creating a Journal Rule in Exchange 2007

 

Enabling the Journaling Agent

The process of creating a journal rule is fairly straightforward, but before any of the rules that you create will work, you must enable the Journal Agent. To do so, you must open the Exchange Management Shell and enter the following command:

Get-TransportAgent

When you enter this command, you will see a summary indicating which transport agents are enabled, as shown in Figure A.

Figure A - You must enable the Journaling Agent prior to using Journal Rules.

When you look at this report, you should see that the Journaling Agent is enabled, but if not, then enter the following commands to enable it:

Enable-Transport Agent

You should now be prompted as to which transport agent you want to enable. Type Journaling Agent and press Enter. Now, enter the Get-TransportAgent command one more time to verify that the agent has been enabled.

Now that the Journaling Agent is enabled, we can move forward with creating a journaling rule. Begin the process by going to your Hub transport server and opening the Exchange Management Console. Now, navigate through the console tree to Organization Configuration -> Hub Transport.  When you do, the results pane should display a number of different tabs.

Select the Journaling tab, and then click the New Journal Rule link found in the Actions pane.  When you do, the console will launch the New Journal Rule wizard, shown in Figure B. You will notice in the figure that I have already filled out the wizard's various fields. I have done this to make it easier to understand what I am talking about as you read the rest of this article.

Figure B - The New Journal Rule wizard allows you to create a new journal rule

The first thing that this wizard requires you to do is to enter a name for the new rule that you are creating. You can call the rule anything that you want, but I recommend using a descriptive name.

Next, click the Browse button and you will see a list of all of the mailboxes in the Exchange organization. Choose the mailbox that you want journaling reports to be sent to, and then click OK.

Now, you must choose the rule's scope. You have the option of using a global scope (journal all messages), and internal scope (journal internal messages only), or an external scope (journal messages to or from external users).

The next thing that you must do is to specify which user's messages will be journaled. To do so, select the Journal Messages for Recipient check box, and then click the Browse button located beneath it. When you click the Browse button, you will see a list of all of the organization's mailboxes, distribution groups, and public folders. Unless you are trying to single out a specific user, it's usually best to create a distribution group that you can use for journaling. Make your selection and click OK.

Finally, verify that the Enable Rule check box is selected, and click New. When you do, the Exchange Management Console will display the new rule, and will show it as being enabled, as shown in Figure C.

Figure C - The new journaling rule is displayed within the Exchange Management Console

Conclusion

In this article, I have explained how to create journal rules in Exchange Server 2007 that can be used to journal content related to specific users, distribution groups, or public folders. the vastly improved journaling functionality is one of the valuable new features of Exchange 2007 Server.

Creating a Journal Rule in Exchange 2007

Creating a Journal Rule in Exchange 2007

 

Enabling the Journaling Agent

The process of creating a journal rule is fairly straightforward, but before any of the rules that you create will work, you must enable the Journal Agent. To do so, you must open the Exchange Management Shell and enter the following command:

Get-TransportAgent

When you enter this command, you will see a summary indicating which transport agents are enabled, as shown in Figure A.

Figure A - You must enable the Journaling Agent prior to using Journal Rules.

When you look at this report, you should see that the Journaling Agent is enabled, but if not, then enter the following commands to enable it:

Enable-Transport Agent

You should now be prompted as to which transport agent you want to enable. Type Journaling Agent and press Enter. Now, enter the Get-TransportAgent command one more time to verify that the agent has been enabled.

Now that the Journaling Agent is enabled, we can move forward with creating a journaling rule. Begin the process by going to your Hub transport server and opening the Exchange Management Console. Now, navigate through the console tree to Organization Configuration -> Hub Transport.  When you do, the results pane should display a number of different tabs.

Select the Journaling tab, and then click the New Journal Rule link found in the Actions pane.  When you do, the console will launch the New Journal Rule wizard, shown in Figure B. You will notice in the figure that I have already filled out the wizard's various fields. I have done this to make it easier to understand what I am talking about as you read the rest of this article.

Figure B - The New Journal Rule wizard allows you to create a new journal rule

The first thing that this wizard requires you to do is to enter a name for the new rule that you are creating. You can call the rule anything that you want, but I recommend using a descriptive name.

Next, click the Browse button and you will see a list of all of the mailboxes in the Exchange organization. Choose the mailbox that you want journaling reports to be sent to, and then click OK.

Now, you must choose the rule's scope. You have the option of using a global scope (journal all messages), and internal scope (journal internal messages only), or an external scope (journal messages to or from external users).

The next thing that you must do is to specify which user's messages will be journaled. To do so, select the Journal Messages for Recipient check box, and then click the Browse button located beneath it. When you click the Browse button, you will see a list of all of the organization's mailboxes, distribution groups, and public folders. Unless you are trying to single out a specific user, it's usually best to create a distribution group that you can use for journaling. Make your selection and click OK.

Finally, verify that the Enable Rule check box is selected, and click New. When you do, the Exchange Management Console will display the new rule, and will show it as being enabled, as shown in Figure C.

Figure C - The new journaling rule is displayed within the Exchange Management Console

Conclusion

In this article, I have explained how to create journal rules in Exchange Server 2007 that can be used to journal content related to specific users, distribution groups, or public folders. the vastly improved journaling functionality is one of the valuable new features of Exchange 2007 Server.

Defining an Exchange 2007 E-Mail Address Policy, Part 1

Defining an Exchange 2007 E-Mail Address Policy, Part 1

 

In Exchange Server 2007, the Recipient Update Service has been replaced by a new synchronous process that assigns e-mail addresses to Active Directory accounts immediately via the EmailAddressPolicy command.  Of course one of the side effects to this change is that the method for creating a new e-mail address policy has changed.  The process is still simple, and straight forward, but it is quite a bit different from the process used in Exchange Server 2003.

Accepted Domains

Before you can create an e-mail address policy, you must first define at least one excepted domain.  Accepted domains are generally domains for which the Exchange organization should be authoritative for.  In some cases though, an accepted domain can be a domain in a different Active Directory forest within the organization, or an external domain.

When you deploy the first hub transport server in your Exchange Server organization, Exchange configures the forest root domain as an accepted domain by default.  This works fine if your internal and external domain names match, but it causes problems if you use separate domain names.  For example, in my organization my production network uses an internal domain name of production.com.  However, my external domain name is BrienPosey.com. By default, Exchange is aware of the production.com domain, but not of the BrienPosey.com domain name.

Creating a New Accepted Domain

Creating a new accepted domain is a simple, but essential process. To do so, open the Exchange Management Console and navigate through the console tree to Organization Configuration | Hub Transport. Now, click the New Accepted Domain link, found in the console's Actions pane. When you do, you will be taken to the screen shown in Figure A. As you can see, you must enter a name for the new domain, and the accepted domain name. Generally, these can be one in the same. You must also specify whether the new domain is an authoritative domain, an internal relay domain, or an external relay domain. When you are done, click the New button, and the new accepted domain will be added to the Accepted Domains tab, as shown in Figure B.

Figure A You must enter a display name and the name of the new accepted domain.

Figure B The new accepted domain appears on the Accepted Domains tab.

An Alternative Method for Defining an Accepted Domain

In case you are wondering, you can use the Exchange Management Shell to define an accepted domain. The command that you would use for doing so is:

New-AcceptedDomain –Name "brienposey.com" –DomainName "brienposey.com" –DomainType "Authoritative"

As you can see, the New-AcceptedDomain command shown above uses the exact same parameters as the New Accepted Domain Wizard does. Simply use the –Name and the –DomainName parameters to supply the display name and the domain name respectively. Notice in the command above that the actual display name and display name are enclosed in quotation marks.

In this particular case, I have set the domain type to Authoritative. However, I could have specified InternalRelay or ExternalRelay instead as a way of defining an internal or an external relay domain.

As you can see, the New-AcceptedDomain command is one of the easier Exchange Management Shell commands to use. Even so, some people seem to have a mental block when it comes to performing actions from the command line. If you need additional help with the New-AcceptedDomain command, you can enter the following command into the Exchange Management Shell to get the command's full syntax:

Help New-AcceptedDomain

Conclusion

In this article, I have explained that defining an accepted domain is a prerequisite to creating an E-mail address policy. I have also walked you through the process of creating an accepted domain. In Part 2, I will conclude the series by showing you how to create an E-mail address policy.

Got a question? Post it on our Exchange Server Forums!

Planning for an Exchange 2007 Migration

Planning for an Exchange 2007 Migration

 

Assessing the Exchange Features that Your Organization Needs

Generally speaking, if you're migrating from Exchange Server 2003 to Exchange Server 2007 then the migration process tends to be fairly painless. Even so, it important to keep in mind that there are some features that existed in Exchange Server 2003 that do not exist in Exchange Server 2007. Discontinued features are even more of an issue though if you are going to be migrating from Exchange 2000.

My advice is that before you even think about performing a migration, you need to take a look at the features that have been discontinued, and see if any of the discontinued features impact your organization. If you do happen to be using any of the features that have been discontinued, then you will have to figure out if you can live without the feature, or how you can implement the feature in a different way. In some cases you can maintain access to feature just by keeping a legacy Exchange Server in the Exchange organization. In other cases though, some of the discontinued features are completely unsupported in Exchange 2007 organizations.

There is no way that I can possibly talk about all of the features that have been discontinued within the confines of an article, but Microsoft does provide a list of the features that have been de-emphasized or discontinued. You can find the list here.

The nice thing about this particular list is that it not only tells you which features have been discontinued, it tells you how to work around the issue if the discontinued feature happens to be something that you still need access to. One thing to keep in mind though is that the list is not comprehensive.

The list seems to be adequate for organizations that are going to be migrating from Exchange 2003 or mixed Exchange 2000 / 2003 environments. If an organization currently only has Exchange 2000 deployed though, then there are some discontinued features that are not on the list. For example the instant messaging feature was removed in Exchange 2003, and is now a part of Office Communications Server.  You can read about the Exchange 2007 features that were removed in Exchange 2003 here.

Performing a Trial Migration

One thing that I strongly recommend doing is performing a trial migration in a lab environment prior to installing Exchange 2007 in your production environment. Setting up a migration lab can be a lot of work, but in my opinion it is well worth it, because a trial migration can help you to gain experience with the migration process, and because it will help you to find out about any "surprises" ahead of time.

The key to performing a test migration is to create a lab environment that closely mimics your production network, but on a smaller scale. What I recommend doing is getting a few high end PCs with plenty of disk space and then using them to create a miniature version of your network.

You should set these computers up in a small network that is completely disconnected from your production network. You can restore full, system state backups of your production servers to the lab machines in order to get them to match your production machines as closely as possible. Of course you will probably have to do some amount of reconfiguring in order to compensate for differences in hardware.

Particular attention should be paid to the lab network's domain controller. The lab network will not work properly unless the domain controller that you use contains the various FSMO roles, and has been designated to act as a global catalog server. Your test network will also need a DNS server to facilitate Active Directory functionality. In most cases when an organization creates an Active Directory forest, the DNS services, global catalog functionality, and all of the FSMO roles are installed on the first domain controller in the forest. Assuming that you have a domain controller that is configured in this manner, then consider using a backup of that domain controller to create the domain controller for your lab network.

Conclusion

In this article, I have talked about some things that you can be doing to prepare for an Exchange 2007 migration. In the next article in this series, I will discuss some more aspects to the planning process.

Got a question? Post it on our Exchange Server Forums!

Planning for an Exchange 2007 Migration

Planning for an Exchange 2007 Migration

 

Assessing the Exchange Features that Your Organization Needs

Generally speaking, if you're migrating from Exchange Server 2003 to Exchange Server 2007 then the migration process tends to be fairly painless. Even so, it important to keep in mind that there are some features that existed in Exchange Server 2003 that do not exist in Exchange Server 2007. Discontinued features are even more of an issue though if you are going to be migrating from Exchange 2000.

My advice is that before you even think about performing a migration, you need to take a look at the features that have been discontinued, and see if any of the discontinued features impact your organization. If you do happen to be using any of the features that have been discontinued, then you will have to figure out if you can live without the feature, or how you can implement the feature in a different way. In some cases you can maintain access to feature just by keeping a legacy Exchange Server in the Exchange organization. In other cases though, some of the discontinued features are completely unsupported in Exchange 2007 organizations.

There is no way that I can possibly talk about all of the features that have been discontinued within the confines of an article, but Microsoft does provide a list of the features that have been de-emphasized or discontinued. You can find the list here.

The nice thing about this particular list is that it not only tells you which features have been discontinued, it tells you how to work around the issue if the discontinued feature happens to be something that you still need access to. One thing to keep in mind though is that the list is not comprehensive.

The list seems to be adequate for organizations that are going to be migrating from Exchange 2003 or mixed Exchange 2000 / 2003 environments. If an organization currently only has Exchange 2000 deployed though, then there are some discontinued features that are not on the list. For example the instant messaging feature was removed in Exchange 2003, and is now a part of Office Communications Server.  You can read about the Exchange 2007 features that were removed in Exchange 2003 here.

Performing a Trial Migration

One thing that I strongly recommend doing is performing a trial migration in a lab environment prior to installing Exchange 2007 in your production environment. Setting up a migration lab can be a lot of work, but in my opinion it is well worth it, because a trial migration can help you to gain experience with the migration process, and because it will help you to find out about any "surprises" ahead of time.

The key to performing a test migration is to create a lab environment that closely mimics your production network, but on a smaller scale. What I recommend doing is getting a few high end PCs with plenty of disk space and then using them to create a miniature version of your network.

You should set these computers up in a small network that is completely disconnected from your production network. You can restore full, system state backups of your production servers to the lab machines in order to get them to match your production machines as closely as possible. Of course you will probably have to do some amount of reconfiguring in order to compensate for differences in hardware.

Particular attention should be paid to the lab network's domain controller. The lab network will not work properly unless the domain controller that you use contains the various FSMO roles, and has been designated to act as a global catalog server. Your test network will also need a DNS server to facilitate Active Directory functionality. In most cases when an organization creates an Active Directory forest, the DNS services, global catalog functionality, and all of the FSMO roles are installed on the first domain controller in the forest. Assuming that you have a domain controller that is configured in this manner, then consider using a backup of that domain controller to create the domain controller for your lab network.

Conclusion

In this article, I have talked about some things that you can be doing to prepare for an Exchange 2007 migration. In the next article in this series, I will discuss some more aspects to the planning process.

Got a question? Post it on our Exchange Server Forums!

Defining an Exchange 2007 E-Mail Address Policy, Part 1

Defining an Exchange 2007 E-Mail Address Policy, Part 1

 

In Exchange Server 2007, the Recipient Update Service has been replaced by a new synchronous process that assigns e-mail addresses to Active Directory accounts immediately via the EmailAddressPolicy command.  Of course one of the side effects to this change is that the method for creating a new e-mail address policy has changed.  The process is still simple, and straight forward, but it is quite a bit different from the process used in Exchange Server 2003.

Accepted Domains

Before you can create an e-mail address policy, you must first define at least one excepted domain.  Accepted domains are generally domains for which the Exchange organization should be authoritative for.  In some cases though, an accepted domain can be a domain in a different Active Directory forest within the organization, or an external domain.

When you deploy the first hub transport server in your Exchange Server organization, Exchange configures the forest root domain as an accepted domain by default.  This works fine if your internal and external domain names match, but it causes problems if you use separate domain names.  For example, in my organization my production network uses an internal domain name of production.com.  However, my external domain name is BrienPosey.com. By default, Exchange is aware of the production.com domain, but not of the BrienPosey.com domain name.

Creating a New Accepted Domain

Creating a new accepted domain is a simple, but essential process. To do so, open the Exchange Management Console and navigate through the console tree to Organization Configuration | Hub Transport. Now, click the New Accepted Domain link, found in the console's Actions pane. When you do, you will be taken to the screen shown in Figure A. As you can see, you must enter a name for the new domain, and the accepted domain name. Generally, these can be one in the same. You must also specify whether the new domain is an authoritative domain, an internal relay domain, or an external relay domain. When you are done, click the New button, and the new accepted domain will be added to the Accepted Domains tab, as shown in Figure B.

Figure A You must enter a display name and the name of the new accepted domain.

Figure B The new accepted domain appears on the Accepted Domains tab.

An Alternative Method for Defining an Accepted Domain

In case you are wondering, you can use the Exchange Management Shell to define an accepted domain. The command that you would use for doing so is:

New-AcceptedDomain –Name "brienposey.com" –DomainName "brienposey.com" –DomainType "Authoritative"

As you can see, the New-AcceptedDomain command shown above uses the exact same parameters as the New Accepted Domain Wizard does. Simply use the –Name and the –DomainName parameters to supply the display name and the domain name respectively. Notice in the command above that the actual display name and display name are enclosed in quotation marks.

In this particular case, I have set the domain type to Authoritative. However, I could have specified InternalRelay or ExternalRelay instead as a way of defining an internal or an external relay domain.

As you can see, the New-AcceptedDomain command is one of the easier Exchange Management Shell commands to use. Even so, some people seem to have a mental block when it comes to performing actions from the command line. If you need additional help with the New-AcceptedDomain command, you can enter the following command into the Exchange Management Shell to get the command's full syntax:

Help New-AcceptedDomain

Conclusion

In this article, I have explained that defining an accepted domain is a prerequisite to creating an E-mail address policy. I have also walked you through the process of creating an accepted domain. In Part 2, I will conclude the series by showing you how to create an E-mail address policy.

Got a question? Post it on our Exchange Server Forums!

versions

 

If you are running into environments and working on aspects of them such as Exchange, OCS, PKI, or other Active Directory integrated applications, you will encounter situations where you may need to update the AD schema. Of course, the first question is, what version am I at today?

Here's a handy way to find out:

Query for the objectVersion attribute of the CN=Schema,CN=Configuration,DC=yourdomainhere of your Active Directory domain and compare the value to the table below.

I've provided links to the schema update information (where available), if you are curious as to what is updated in each.

objectVersion
AD Schema Update

13 - Windows 2000 Server

30 - Windows Server 2003 **

31 - Windows Server 2003 R2

44 - Windows Server 2008

** The Windows Server 2003 upgrade from 2000 also adds the CN=Windows2003Update,CN=ForestUpdates,CN=Configuration,DC=yourdomainhere and sets its revision attribute to 9. This hasn't been used again, yet.

Exchange Server saves the current version of its schema updates in an attribute of two locations.

For /forestprep operations, query the rangeUpper attribute of the CN=ms-Exch-Schema-Version-Pt,CN=Schema,CN=Configuration,DC=yourdomainhere object.

For /domainprep operations, query the Microsoft Exchange System Objects object in each domain for its objectVersion value.

The table below provides the number to version translation.

Value
Exchange Version

4406 - Exchange 2000 Server

6936 -  Exchange Server 2003

10628 - Exchange Server 2007