How Outlook rules work

Posted on By Mark Wilson
This content is 20 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

This morning, as part of an e-mail migration, I was looking at a scenario where I needed to divert all inbound e-mail messages from one (Exchange Server) mailbox to another (Microsoft Mail) mailbox, unless the message originated from the target mailbox. I couldn’t implement this in Active Directory as it only supports a simple divert of all incoming messages to another recipient (and so couldn’t handle the additional complexity of excluding certain messages), but the rules and alerts functionality within Microsoft Outlook is more flexible.

One potential issue was around where Outlook stores information relating to its rules – because I need to create the rule using Outlook on one PC and remove it from another.

In this case, everything was fine, because this particular rule ran server-side (and hence didn’t rely on Outlook being active in order to execute); but it’s not always that simple – some rules rely on Outlook client functionality.

The Slipstick website includes comprehensive information on how the rules functionality is implemented, both for standalone Outlook clients and for Outlook clients connected to Exchange Server computers.

OWA and Windows XP SP2

Posted on By Mark Wilson
This content is 20 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

If, like me, you use Outlook Web Access (OWA) to access e-mail from a client site, you may experience some issues with the Internet Explorer popup blocker in Windows XP SP2. To be honest, I’ve not found it a major concern as I added all the key servers at my company’s domain name to the trusted sites zone, but if that is not an option (e.g. due to policy restrictions in place), you may have to find a workaround. A few weeks back, the Windows IT Pro magazine network Exchange and Outlook Update ran an article on OWA and XP SP2 and Microsoft knowledge base article 883575 gives further information.

The Exchange Server Best Practices Analyzer (ExBPA)

Posted on By Mark Wilson
This content is 20 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

The Microsoft Exchange Server Best Practices Analyzer tool (ExBPA) is designed for administrators who want to determine the overall health of their Exchange servers and topology.

The tool scans Exchange servers, identifying items that do not conform to Microsoft best practices, programmatically collecting settings and values from data repositories such as Active Directory, the registry, metabase and performance monitor. Once collected, a set of comprehensive best practice rules are applied to the topology using an XML schema and a detailed report produced listing the recommendations that can be made to the environment to achieve greater performance, scalability and uptime.

According to the Exchange Security website:

“ExBPA’s purpose is to automate some of the basic health-and-sanity checks that an experienced Exchange administrator, consultant, or PSS engineer might do when evaluating an unfamiliar environment. It’s not designed to find every possible mistake you can make (heaven knows there are plenty); instead, it’s intended to help you quickly find well-known misconfigurations and administrator errors. It checks the protocol configurations for SMTP, POP, IMAP, LDAP, and HTTP; GC/DC accessibility; hop counts and routing latency for message routing; the packet size and contents of the link state table; and basic DNS configuration stuff.

You can tweak the rules to control which specific areas ExBPA checks for, which is handy. ExBPA generates XML report files that you can parse yourself, or import into another instance of ExBPA on another machine. One output is a list of issues that the tool found – this is similar in concept to the problem report you get from MBSA, and it serves the same purpose of allowing you to quickly pinpoint and fix whatever needs fixing.”

Further details are available at the Microsoft Exchange team blog (you had me at EHLO…) and known issues are discussed on the Microsoft website.

Tackling spam in Exchange with the RegEx SURBL

Posted on By Mark Wilson
This content is 20 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

Last week, I read an interesting e-mail from the Windows and .NET magazine network Exchange and Outlook update, discussing Spam URL Realtime Block Lists (SURBLs), which examine message contents to block spam. This week’s e-mail highlights a free Exchange Server SURBL – the RegEx filter.

The basic idea behind the RegEx Filter, is the ability to filter email based on any arbitrary text pattern. It is implemented as an event sink that hooks into the Exchange SMTP engine (by default, the filter works only with the first virtual server instance, but this can easily be changed) and applies regular expression tests against the message sender, recipient, or contents.

It is possible to specify any number of individual filters to run against incoming messages and the filter also includes:

  • A large filter file that tests for common patterns found in adult-oriented spam.
  • A whitelist of expressions to be allowed; by customizing this list, it is possible to easily whitelist addresses or senders.
  • A list of blocked recipients; the filter drops blocked recipients as soon as it sees the SMTP rcpt to verb, instead of waiting until the mail has been accepted for delivery.
  • A list with expressions commonly found in “Nigerian scam” messages.

Any or all of these capabilities can be used to roll in additional filtered expressions (by editing XML files, as long as there is a regular expression that will match the messages to be accepted or dropped). The XML schema for the filtering language includes the ability to specify IP address ranges, perform DNS lookups and filter according to the results, slow down the sending mail server by imposing a timeout (for punishing repetitive spammers), and a host of other features.

I haven’t tested the filter yet (I need to move my e-mail service over to Exchange first), but in Paul Robichaux’s original article (from which the information in this post is taken) he suggested that the filter didn’t add any significant performance overhead and that it also includes a set of Performance Monitor counters that can be registered to assist in assessing any performance issues as a result of filtering.

Robichaux also highlighted that RegEx isn’t perfect: its documentation is pretty opaque, and there’s no real step-by-step guide to installing the filter on an Exchange server. Also (and potentially worrying) the default filter configuration logs all accepted messages to disk, exposing all valid, accepted mail in plain text form. Apart from the obvious security implications, these logs also consume a large amount of disk space. Fortunately, the logging can be turned off.

This looks to me, to be a useful (free) tool in the battle to prevent spam.

Migrating from Exchange Server 5.5 to Exchange Server 2003

Posted on By Mark Wilson
This content is 21 years old. I don't routinely update old blog posts as they are only intended to represent a view at a particular point in time. Please be warned that the information here may be out of date.

With Microsoft Exchange Server 2003, Microsoft have made Exchange installation simpler – the Exchange Server deployment tools and documentation (ExDeploy) lead an administrator through the entire Exchange Server installation or upgrade process and it is recommended that Exchange Server 2003 Setup is run using ExDeploy. Specific tools and utilities can be used to verify that the organization is ready for the Exchange Server 2003 installation.

For a variety of reasons, the majority of organisations moving to Active Directory perform a migration rather than an upgrade. The main reason for this is that the legacy Windows NT domain structure is generally over-complicated, often having grown organically with various resource domains created to support applications, and so may be poorly matched to the current organisational structure. Implementing a totally new directory is often the simplest method of re-engineering this, allowing for domain consolidation and improved flexibility post-migration.

Messaging connectivity is fairly straightforward to provide – that is at the core of the Exchange Server product – the main issues for Exchange Server are around directory management.

Because Exchange Server 4.0-5.5 use their own directory service and Exchange Server 2000 and 2003 use Active Directory, in a mixed environment it is necessary to synchronise directories using the Active Directory Connector (ADC). Note that there are two commonly available versions of this tool – the Windows 2000 version is not suitable for Exchange and the Exchange version should always be used.

The Exchange Server directory allows one user to be linked with several mailboxes (e.g. a primary mailbox and a resource mailbox) but Active Directory has a 1:1 relationship between a user account and a mailbox; however, ADC can create a disabled user account with an associated mailbox for resource accounts (permissions on the mailbox can then be delegated to one or more users).

The NTDSNoMatch utility can assist administrators by checking for mailboxes with a duplicate primary Windows NT account and determining if the mailbox is the primary mailbox or a resource mailbox. Following this, it creates a comma-separated value (.CSV) file that can be imported into the Exchange 5.5 directory to automatically set Custom Attribute 10 to NTDSNoMatch for the resource mailboxes. The ADC uses this attribute to match a mailbox that does not have NTDSNoMatch set to the correct user account.

The ADC uses a series of connection agreements (CAs), which are set as primary (i.e. synchronise and create objects as necessary) or non-primary (synchronise only). One- or two-way CAs can be configured and if required, a CA could be primary in one direction, and non-primary in the other. This primary and non-primary arrangement prevents duplicate entries in the global address list (GAL) from being created as a result of various CAs synchronising with multiple sites.

In mixed mode, recent versions of Exchange Server provide a service called the site replication service (SRS), which makes an Exchange 2000/2003 routing group appear as a site to the Exchange 5.5 infrastructure (cf. native mode, where Exchange Server 5.5 interoperability is not supported).

The SRS acts as an endpoint for a configuration CA, created in the ADC by Exchange Setup. This allows SRS to funnel organisational changes made in Active Directory into the legacy Exchange directory service, where they propagate to the legacy servers via standard directory service replication.

Recipient and public folder CAs are created by an administrator. These should be configured to point at the SRS rather than a legacy Exchange server so that legacy servers can be decommissioned without losing synchronisation with Active Directory. When all legacy servers have been decommissioned, the SRS is no longer required. Note that even when hosting the SRS, an Exchange Server 2003 server still read directly from Active Directory (using DSAccess) and the SRS is only for the benefit of Exchange Server 4.0-5.5 servers.

If an organisation creates an Active Directory to support Exchange Server 2003, and completes the Exchange migration before all the NT domains have been migrated to Active Directory, duplicate accounts will be created. The ADClean tool can be used to merge duplicate accounts and is installed with Exchange Server 2000 and 2003.

The whole migration process from Exchange Server 5.5 to 2003 is summarised as follows:

Exchange 5.5 to 2003 migration

  1. Install Active Directory on a new Windows 2000 or Windows Server 2003 server
  2. Migrate NT objects to Active Directory using the Active Directory Migration Tool (ADMT) – this will require a trust to be in place between the legacy and new domains.
  3. ADMT manages SID history to ensure that new accounts in Active Directory still have access to resources in the NT domain (including permissions over their Exchange Server 5.5 mailboxes.
  4. Run Exchange Server setup once with the /forestprep switch to prepare the Active Directory Schema for Exchange and again with the /domainprep switch for each domain in the forest which will host Exchange Servers (ADC installation in 5 would make some changes, but not all).
  5. Install the ADC on a member server within the Active Directory forest. Create recipient CAs and use the NTDSNoMatch utility to check for mailboxes with a duplicate primary Windows NT account.
  6. Install a new Exchange Server 2003 server, ideally into the Exchange Server 2003 administrative group which corresponds to the existing Exchange server 5.5 site (i.e. same organisation). Alternatively, a new organization can be created.
  7. Use the Move Mailbox Wizard to move mailboxes from legacy Exchange servers to the new server. This is multi-threaded in Exchange Server 2003 and so much faster than in Exchange Server 2000. Outlook clients will automatically be updated via the directory referral method and so a client visit is not required. If a new Exchange organization was created in 6, it will be necessary to use the ExMerge tool to migrate data and to reconfigure each Outlook client with a new profile. The public folder migration tool can be used to migrate system and public folders.
  8. Once all of the data is migrated, the legacy Exchange Server 5.5 servers may be decommissioned and Exchange Server 2003 switched from mixed to native mode (note that this is entirely separate from the mixed and native modes for Active Directory).
  9. Optionally, ADSI Edit can be used to restructure administrative groups (unsupported by Microsoft).
  10. Finally, the ADC may be decommissioned and the SRS disabled.