January 2010
Travel Add-in for Outlook
written by admin on Jan 30, 2010
Released: Update Rollup 2 for Exchange Server 2007 Service Pack 2
written by admin on Jan 29, 2010
In addition to bug fixes reported by customers we have added new rules to the Exchange Best Practices Analyzer to check the health of your system. Starting this rollup, customers who wish to deploy the new BPA health rules to a server with no internet connection can do so by downloading the installing the update rollup on the server. Until Exchange Server 2007 Service Pack 2, updates to the BPA rules were available only via the web which meant customers wanting to deploy the new health check rules to servers not connected to the internet would have had to copy over the XML files manually. In Exchange 2007 SP2, we implemented a work item which allows us to ship updates to the BPA health check rules via the rollup and as well as via the traditional web based channel. More on this via a blog post in the near future.
KBA 972076 lists all the fixes included in this rollup. Here are some of the product improvements and critical bug fixes we'd like to call out:
- KB 972705: This one is for all the IT pros and anyone who has ever had to explain abnormal database size/log file growth in a short period of time. We have added three new registry entries to help speed up troubleshooting the issue:
- BytesLogWarningThreshold
- BytesLogErrorThreshold
- BytesLogCheckPeriodInMinutes
- KB 975404: Accepting meeting requests sent via an application using CDO like Blackberry devices sometimes results in rendering an embedded message attached to the meeting request inaccessible.
- KB 976137: We have made a change to the behavior of the Unified Messaging Auto attendant when it plays the greeting for callers on a holiday. Currently when callers call on a holiday, they hear the non-business hours greeting followed by the holiday greeting. In this rollup we have made a change so that the callers calling on a holiday will only hear the holiday greeting. If your greetings are configured such that they would make sense to callers calling on a holiday only if they hear both the non-business hours greeting and the holiday greeting, then you need to re-configure them when you install this update rollup.
- KB 971177: Another change in the UM Auto Attendants configuration in the Exchange Management Console. It is now aware if your time zone follows Daylight Saving Time.
- KB 975165: In an environment using self-signed certificates and CAS-CAS proxying, Exchange Web Services requests proxied may start failing after the Availability Service has made a proxy request.
- A bug where the OWA Virtual Directory cannot be accessed via the Exchange Management Console in an environment coexisting with Exchange 2010 if the Exchange 2007 server was upgraded from Exchange 2007 SP1 to SP2.
Interception and Redirection of Messages Using Transport Rules or Journaling
written by admin on Jan 28, 2010
When looking for Exchange controls to copy messages for regulatory compliance needs, you may have come across both Transport Rules and Journaling and wondered, "Which one best serves the needs of my organization?"
Both features have the capability to intercept and copy messages to another mailbox, but they differ in how they intercept messages and in what details are included in the copied message. Transport Rules can be employed to satisfy needs for message review and monitoring, while Journaling can be employed to meet the regulatory compliance needs for message archiving. The purpose of this article is to contrast these features' capabilities of message interception, and to help you identify which will best meet your particular compliance and control requirements. For a broader understanding of these two Exchange features, please reference the links provided below.
Transport Rules-based message interception
Transport rules are applied when messages are sent or received in your organization.
Transport Rule = Condition + Action + Exception
First, a criteria is evaluated such as who the sender or receiver of the message is, or the keywords in a message. If messages meet particular criteria (conditions and exceptions), then an action can be applied like 'block,' 'copy,' 'moderate,' or 'append a disclaimer to the message'. Transport Rules are used to enforce message control and protection policies.
The Transport Rules agent runs on the Exchange Hub Transport server, evaluating every message against the set of Transport Rules.
If your goal is to clandestinely copy certain messages to a supervisory mailbox for post-send review, one could use the "Blind carbon copy (Bcc)" action. For example:
| Conditions | Apply rule to messages sent to users that are 'Outside the organization' and when the Subject field or message body contains 'Secret project code words' |
| Actions | Blind carbon copy(Bcc) the message to 'contentreview@contoso.com' |
| Exceptions | Except when the message is sent to a member of 'trustedpartner@contoso.com' |
In this rule, external bound messages containing sensitive project key words are copied to a mailbox, where they will be reviewed periodically for policy violations, except for messages which are addressed to members of the trusted partner group.
If your goal in message interception is to have a supervisor review and approve the message before delivery, then you may want to use the moderation action (new in Exchange 2010). An example of how to configure a Transport Rule for moderation, using the Exchange Management Console (EMC):
Figure 1: Transport rule conditions
Figure 2: Transport rule actions
In the example rule above, members of the "Contractors" group are working on a sensitive project and corporate policy dictates that messages sent outside of the organization must be first approved by the user's manager before being delivered. The manager gets an approval request message for the intercepted message, and has the ability to approve or reject the message (via Outlook or OWA).
The advantage that Transport Rules presents is the rich set of conditions & exceptions to which one can scope the rule. One can create very specific rules to intercept messages based on recipients, senders, message content, and/or message properties. For additional details on Transport Rules see:
- Transport Rules documentaton on TechNet
- Exchange Server 2007 Transport Rules Editor GUI
- Moderation with transport rules
- Spotlight on Exchange 2010: E-mail Moderation
Journaling for compliance
The journaling feature was developed to meet the needs of enterprise class message archiving, often driven by legal and regulatory requirements, such as the Sarbanes Oxley Act, SEC Rule 17A-4, and other similar regulations. If an archive is required, then Exchange journaling can be used to create records of email communications, including BCC data, DL membership at the time of delivery, etc.. These records are then delivered via SMTP to the archive for de-duplication / discovery and production.
Similar to the Transport Rules agent, the Journaling agent also runs on Hub Transport servers (the Journaling agent runs after the Transport Rules agent), evaluating every message against the set of journal rules.
Journal rules are policies for intercepting and archiving messages to and from regulated users (or sets of users); the journal rule configuration allows one define the target user(s) and scope to global, internal, or external messages. For example:
Figure 3: Journal rule properties
In the example journal rule above, all messages sent to or from User01 will be journaled. The journal reports are sent to the Journal mailbox for archiving.
In the example journal report below, the message, "Sales Forecast," from Test User01 was intercepted by the journal rule. A copy of the original message is attached to the journal report, and message metadata (e.g. recipient details) is included in the journal report body:
Figure 4: A journal report includes message metadata and the original message as an attachment
Attaching a copy of the original message to the journal report ensures that the original headers and properties of the message are maintained, as opposed to a message copied by transport rules where some headers will be stripped and properties transformed on delivery. This is one significant difference between a message intercepted by Journaling and a message intercepted by Transport Rules. Other differences are provided in the next section below.
The other advantage that Journaling has over Transport Rules is in the message recipient meta-data provided in the journal report envelope. This lists all of the recipients in the SMTP envelope (P1 recipient list, RFC821), and how each recipient got on the message, including:
- Distribution group expansion ("To: user01@contoso.com, Expanded: salesteam@contoso.com")
- Forwarded recipients ("To: user03@contoso.com, Forwarded: user02@contoso.com")
- BCC'd recipients ("Bcc: reporterdude@treyresearch.net")
- Recipients added by Transport Rules or any other transport agent (not in the example above, but would be listed as "Recipient: someone@example.com"
Lastly, the journal report messages themselves are privileged messages, which will not be intercepted by transport rules, and can be configured such that they will never expire in a transport queue (e.g., will not NDR). Messages redirected or bcc'd by a Transport rule, on the other hand, are treated just like any other standard message in the system (e.g., can NDR if the target mailbox is unreachable).
For additional details on Journaling see:
- Technet documentation on Exchange Journaling
- Technet article on Exchange Journaling
- Whitepaper on Exchange 2007 Journaling
Which feature should I use?
In most cases, this decision will probably pivot around how important it is for you to capture the meta-data around intercepted messages. In summary:
- Transport Rules support redirecting or BCC'ing messages to another user or mailbox for moderation or review. This is not suitable for legal e-discovery due to missing metadata and the modified message contents (headers, etc). This best suited for internal surveillance or corporate policy enforcement, where reviewing the message body content is the primary need.
- Journaling supports e-discovery archives and enables copying a full fidelity version of the message. The journal reports contain BCC, DL membership, etc. This is best suited for enterprise class archiving and regulatory compliance. If your organization wants to support e-discovery via a third party archive, you need to use Journaling.
Below is a chart of some typical requirements organizations have for message interception (be it for review or archiving), and how each feature meets those needs:
| Requirement | Transport Rule (Blind carbon copy) | Journaling (Journal report) |
| Message ID: Is the original submitted message ID preserved? | Yes, the bcc'd message has the same message ID as the original. | Yes, in the journal report body and in the attached message. |
| Message Body: Is the message body preserved? | Yes, the message body is untouched by the bcc action. | Yes, in the attached message to the journal report. |
| Recipients in the SMTP Envelope: Is all of the recipient data in the SMTP envelope (aka, P1 recipient list, RFC 821) preserved? | No, the delivered message only has the recipients in the message body (aka., P2 recipient list, RFC 822). | Yes, in report body and in the attached message. |
| Recipients in the Message Body: Are the recipients in the message body (aka., P2 recipient list, RFC 822) preserved? | Yes, in the bcc'd message headers. | Yes, in the report headers and in the attached message. |
| DL Members: Is group expansion information included? | No. | Yes, in the report body. |
| BCC: If the sender addressed BCC recipients, is information about those BCC recipients captured? | No, all bcc recipient (P1 recipient list) information is stripped when delivered. | Yes, in the journal report body and in the attached message. |
| Transport Rule Recipient Changes: Are added recipients accounted for? | No, recipients added by transport rules after the bcc rule will not be accounted for in the bcc rule. | Yes, the Journaling agent will detect any change in recipients made by Transport Rules or other agent, and will re-evaluate the journal rules against these new recipients. |
| Moderation: Are moderation messages and events captured? | No, if the recipients on the message (e.g. moderated distribution groups) were first moderated, the transport rule for bcc would not capture the moderation activity. | Yes, the journaling rule would capture approved and rejected messages. |
| De-duplication: Are unnecessary duplicate messages prevented? | No, all duplicates will trigger the rule, potentially resulting multiple copies. | Yes, duplicate reports to the same journal target address are minimized. |
| IRM Decryption: Are IRM-protected messages decrypted in the delivered copy? | No, the bcc recipient will receive an encrypted message (and may not be able to read it). | Yes, the Journaling agent can provide both a decrypted copy and an encrypted copy of the message, attached to the journal report. *Requires configuring Journal Report Decryption |
| Loss prevention: Is there a way to ensure delivery of the copied message? | No, if the Bcc target mailbox is unreachable, the Bcc'd message will eventually time out in the queue and fail delivery. | Yes, on-premise deployments of Exchange, by default, will hold journal reports indefinitely in the queue until the journal mailbox is available again. Alternatively, a journaling NDR address can be configured (required for datacenter tenants), to which undeliverable journal reports will be sent. |
| Comprehensive: Are all message types evaluated? | No, the Transport Rules agent will not evaluate rules against system messages. | Yes, the Journaling agent will evaluate all messages, including system messages. |
Both Transport Rules and Journaling are powerful tools for the Exchange admin to meet message policy enforcement needs and regulatory compliance needs of your organization - understanding your organization's real archiving and control needs is key to picking the right technology.
Add an Image to your Signature in OWA
written by admin on Jan 28, 2010
Protecting Exchange 2010 DAG (Single Site) Using Data Protection Manager 2010
written by admin on Jan 26, 2010
Our friends over in the Data Protection Manager product group recently posted this article on how you can protect your Exchange 2010 high availability architecture using the next version of Data Protection Manager. To find out more about DPM 2010, head over to the DPM blog.
Exchange 2010 Mailbox Server Role Requirements Calculator Updated to Version 3.2
written by admin on Jan 22, 2010
It's been a while since we discussed the Exchange 2010 Mailbox Server Role Requirements Calculator. Well I am pleased to say that today we are launching version 3.2 of the calculator.
This version includes the following improvements and new features:
- Added processor core guidance for Hub Transport and Client Access server roles.
- Added the ability to define a custom number of databases that you would like to implement in the solution.
- Added support for 2-node site resilient Database Availability Groups.
- Added 1 and 6 processor cores as selectable options.
- Improved breakdown of the activation scenarios in a site resilient solution.
- Improved breakout of the role requirements section.
- The Storage Design tab now indicates that when you select a custom RAID configuration that the calculator ignores RAID-5 and RAID-6 for 5.xK and 7.2K spindles due to performance concerns.
- Updated processor utilization results to show the processor utilization even if it is above the recommended threshold.
- Made conditional formatting improvements throughout the calculator to warn you when you have a configuration that will not work.
- Improved various cell comments.
This version also corrects the following bugs:
- Fixed LUN Requirements tables to accurately reflect space requirements when database copies are deployed as each server may not host all database copies.
- Fixed conditions that resulted in -1 lagged copies.
- Improved the active database copies after first/second server failure calculations:
- We now calculate and expose the worst case scenario (the server that has to host the most active databases) is used in sizing memory and CPU.
- We now ensure that the secondary datacenter calculations only consider double server failures when there are 3+ HA copies located in the secondary datacenter.
Hey where is Active/Active?
And for those that I know will ask, this version of the calculator does not include the Active/Active user distribution site resiliency scenario. For those that need that scenario, what I recommend is the following:
- Launch two versions of the calculator.
- Populate the first version for the first DAG in your design. This DAG (DAG1) will utilize Datacenter 1 as its primary location (and thus its user population is based out of Datacenter 1). It has site resiliency by having servers and database copies located in Datacenter 2 that can be activated in the event Datacenter 2 is lost.
- Populate the second version for the second DAG in your design. This DAG (DAG2) will utilize Datacenter 2 as its primary location (and thus its user population is based out of Datacenter 2). It has site resiliency by having servers and database copies located in Datacenter 1 that can be activated in the event Datacenter 2 is lost.
| Datacenter 1 | Datacenter 2 | |
| DAG1 | Active | Passive |
| DAG2 | Passive | Active |
By implementing the architecture in this way, you can ensure that for the majority of scenarios except loss of datacenter, the users remain operational in their primary datacenter location.
Conclusion
Hopefully you will find this calculator invaluable in helping to determine your mailbox server role requirements for Exchange 2010 mailbox servers. If you have any questions or suggestions, please email strgcalc AT microsoft DOT com.
For the explanation of different tabs and how the calculator works, go here. Yup, we updated that too!
Finally, to get the new calculator - go here.
Issue with message sizes in Outlook 2010 Beta
written by :: Microsoft Outlook Forum :: on Jan 22, 2010
Hello Outlook 2010 Beta users!
We have heard from some of you that you are running into an issue with large e-mail message sizes in the Outlook 2010 Beta. We want to update you on the status of this issue. There is a known bug in the Outlook 2010 Beta where the usage of number and bullet lists causes redundant CSS definitions to be included in each outgoing message. The outgoing message might not display correctly in a mail service where there is a limit to message size, such as Gmail, BlackBerry e-mail, or Craigslist.
Restarting Outlook removes all the extra CSS for new outgoing messages, although you might see remnants of this bug when responding to a message that was already inflated.
If you use number and bullet lists, close Outlook at the end of each day, and your new outgoing messages will return to their normal size. This bug has been fixed in later Outlook 2010 builds.
We hope you are enjoying the Beta!
Jenny Liu
Outlook Program Manager
Making sense of Exchange Logs using ExLogAnalyzer
written by admin on Jan 20, 2010
Early 2008 we have posted a blog entry with a VB script that generates some pre-canned reports that are based on message tracking logs. The script has proven to be useful in understanding Microsoft's Exchange work load and guide some design decision for Exchange 2010. This script was developed by Todd Luttinen, Principal Program Manager at Microsoft.
During the development of Exchange 2010, we needed to extended our log analysis beyond just message tracking and to answer a variety of questions that assist with design decisions. This exposed a bottle neck with having a single script that has all the parsing and analyzers bundled together.
This resulted in the creation of ExLogAnalyzer by Victor Boctor, Principal Architect at Microsoft. ExLogAnalyzer was developed in C# with the following goals:
- Separation of syntax and semantics.
- Multi-Server support (process log files that span multiple servers). Log events across servers are processed in chronological order.
- Multi-Log Type support (process / cross reference logs of different log types to produce a single report). Log events across log types are processed in chronological order.
- Provide an extensibility model to support rapid development and distribution of extensions (to support new log types) and analyzers (to encapsulate reporting logic).
- Ability for the community to develop their own analyzers or even extensions.
- Support for Exchange 2007 / 2010 log types.
The main shift in this model, compared to the previous script, is that ExLogAnalyzer is built as a framework that can be used to analyze Exchange as well as possibly any other log format. New log types are supported via plugins called "extensions". Extensions are responsible for doing all the parsing and converting of log lines into events, where each event triggers a method and passes all the pre-parsed information as the event arguments. The specific reports are also implemented as plugins known as "analyzers", where each analyzer handles the events it is interested in and does the appropriate accounting and report generation (typically in CSV format). Implementing each analyzer in isolation (rather than one script that answers multiple questions) makes it much simpler to develop, understand and distribute such analyzers. Such extensions and analyzers can also be easily shared given the plugin model. The following simple diagram summarizes the architecture of this tool:
The ExLogAnalyzer is now released to the community with the following extensions / analyzers available out of the box:
- Message Tracking Log
- MsgTrkTopSendersByDeliverLogAnalyzer - Generates the top 1000 senders based on mailbox deliveries. Messages to the internet are not counted.
- MsgTrkTopSendersBySubmitLogAnalyzer - Provides an analysis of the sender load distribution based on number of messages sent from their mailboxes.
- MsgTrkTopRecipientLogAnalyzer - Generates the top 1000 recipients based on mailbox deliveries. Messages to the internet are not counted.
- MsgTrkMessageSizeDistributionLogAnalyzer - Provides an understanding of the message size distribution.
- MsgTrkRecipientNotFoundLogAnalyzer - Discover and summarize recipients for which "Recipient Not Found" error was generated.
- MsgTrkMailflowVisualizerLogAnalyzer - Generates a directed graph showing the server being analyzed and all the inbound / outbound mail flow paths.
- MsgTrkComponentLatencyPercentileLogAnalyzer (E14) - Analyzes the latencies of the different components and determines the latencies experienced by the specified percentiles of messages.
- MsgTrkDuplicateDeliveryLogAnalyzer - Analyzes the sources for duplicate deliveries to Store. Note that end users don't see such duplicates.
- MsgTrkEventFrequencyLogAnalyzer - Provides an understanding of the distribution of the event + source combinations.
- MsgTrkEventTimeDistributionLogAnalyzer - Provides an understanding of the event distribution over time with a per hour resolution.
- MsgTrkExpandLogAnalyzer - Analyzes the distribution list expansion load on the system.
- MsgTrkReceiveLogAnalyzer - Analyzes the distribution of the sources for the messages received by a server or a set of servers.
- SmtpReceiveWorkLoadLogAnalyzer - Analyzes the SMTP receive work load over time while tracking tarpitting, client time outs, etc.
- SmtpReceiveDelayedAckLogAnalyzer (E14) - Analysis of delayed ack performance over time. This report provides an overview of the redundancy that is achieved for legacy systems via delayed ack.
- SmtpReceiveFormatterLogAnalyzer - Re-writes the logs with each session in a separate file, it also reformats the log so that the common session information is included in the header, hence, making the session details more readable.
- SmtpReceiveSeparatorLogAnalyzer - Re-writes the logs with each session in a separate file while maintaining the exact log format.
- SmtpReceiveSessionIndexLogAnalyzer - Provides a summary of all sessions processed within the provided logs.
- ConnectivityWorkLoadLogAnalyzer - An analyzer that samples the connections over time. This analyzer generates a CSV file per source (e.g. SMTP or MAPI).
- ConnectivityStatsLogAnalyzer - An analyzer that provides the frequency of sessions, failed and DNS failures per source + destination combination.
- ConnectivityFormatterLogAnalyzer - Re-writes the sessions as a file per session, moved all the common session information to the header to make the sessions more readable.
Sample Reports
Following are some samples to provide a feel of the outputs of some of these analyzers.
Mail Flow Visualizer (demonstrated possible visualization using directed graphs):
Message Size Distribution:
SmtpReceiveFormatterLog (log re-writing for splitting sessions and making them more readable):
# Session Id: 08CBDCECE3DDF231
# Start Time (local): 2009-07-28T11:07:46.922
# End Time (local): 2009-07-28T11:07:46.953
# Start Time (UTC): 2009-07-28T18:07:46.922Z
# End Time (UTC): 2009-07-28T18:07:46.953Z
# Disconnect Type: Local
# Connector Id: MyServer\MyServer_CrossForest
# Local End Point: 157.54.7.153:25
# Remote End Point: 157.54.71.39:41830000000,+,,
0000000,*,None,Set Session Permissions
0000000,*,SMTPSubmit SMTPAcceptAnyRecipient SMTPAcceptAuthenticationFlag SMTPAcceptAnySender SMTPAcceptAuthoritativeDomainSender BypassAntiSpam BypassMessageSizeLimit SMTPAcceptEXCH50 AcceptRoutingHeaders AcceptForestHeaders AcceptOrganizationHeaders SMTPAcceptXShadow,Set Session Permissions
0000000,>,220 MyServer E14 Cross Forest,
0000000,<,EHLO otherhost.otherforest.microsoft.com,
0000000,>,250-MyServer.redmond.corp.contoso.com Hello [157.54.71.39],
0000000,>,250-SIZE 10485760,
0000000,>,250-PIPELINING,
0000000,>,250-DSN,
0000000,>,250-ENHANCEDSTATUSCODES,
0000000,>,250-AUTH,
0000000,>,250-8BITMIME,
0000000,>,250-BINARYMIME,
0000000,>,250-CHUNKING,
0000000,>,250-XEXCH50,
0000000,>,250 XSHADOW,
0000000,<,XSHADOW 3333YTkxYjEtYzE1OC00NDcxLWI4OTktMDA2NDI5YmVmZWRlQFRLNUVYMTRNTFRXNjUxLndpbmdyb3VwLndpbmRlcGxveS5udGRldi5taWNyb3NvZnQuY39t,
0000000,>,250 q7rdaFIdKk3NNRTbjRsjrQ==,
0000000,<,MAIL FROM:<sender@contoso.com> SIZE=25477 XSHADOW=70136df4-c89b-4700-9654-b642c4eb78bb,
0000000,*,08CBDCECE3DDF231;2009-07-28T18:07:46.922Z;1,receiving message
0000000,<,RCPT TO:<receiver@contoso.com> ORCPT=rfc822;receiver2@contoso.com,
0000000,>,250 2.1.0 Sender OK,
0000000,>,250 2.1.5 Recipient OK,
0000000,<,XEXCH50 1136 2,
0000000,>,354 Send binary data,
0000015,>,250 2.0.0 XEXCH50 OK,
0000015,<,BDAT 25477 LAST,
0000031,>,250 2.6.0 <DB82FD8C490D4F43ACE766C04B23A7050F0F12@someserver.otherforest.contoso.com> [InternalId=16796908] Queued mail for delivery,
0000031,<,XQDISCARD 50,
0000031,>,251 OK, no discard events,
0000031,<,QUIT,
0000031,>,221 2.0.0 Service closing transmission channel,
0000031,-,,Local
Top Senders by Submit (analysis yielding CSV - full report has top 1000):
| MailboxServer | Sender | Count |
| mbx01.contoso.com | support_person@contoso.com | 162 |
| mbx01.contoso.com | sales_person@contoso.com | 124 |
| mbx02.contoso.com | ceo@contoso.com | 61 |
Sender Distribution by Submit (analysis yielding CSV):
| SentMsgRange | Count | Percent | Percentile |
| 1-5 msgs | 23310 | 86.59% | 86.59% |
| 6-10 msgs | 3078 | 11.43% | 98.02% |
| 11-20 msgs | 497 | 1.85% | 99.87% |
| 21-30 msgs | 28 | 0.10% | 99.97% |
| 31+ msgs | 7 | 0.03% | 100.00% |
Distribution Group Expansion Analyzer (analysis yielding CSV):
| Recipient | RecipCount | ExpandCount |
| info@contoso.com | 1 | 2242 |
| skiing@contoso.com | 43 | 848 |
| parents@contoso.com | 223 | 203 |
| all@contoso.com | 2325 | 17 |
Getting started
- Download ExLogAnalyzer from here.
- Checkout the Power Point slide deck included in the download for more details about ExLogAnalyzer.
- Use ExLogAnalyzer and its distributed sample analyzers to analyze your logs.
- Develop your own analyzers. Visual Studio and Visual C# Express Edition are the recommended tools. However, you can use Notepad or your favorite editor, given that ExLogAnalyzer detects and compiles the analyzer CSharp files at runtime.
- Provide us with feedback about ExLogAnalyzer, sample analyzers or the development process.
- Share your analyzers or ideas for useful new analyzers with the Exchange community.
Restricting email to the Internet on a per user AND per domain basis
written by admin on Jan 18, 2010
You requested it... and we delivered it in Exchange 2010!
One of the most requested items in exchange 2007 was something like this...
...we have 5-12 external domains that we need to allow some users to send to, but prevent sending to all other domains...
Or like this...
...we need a way to allow everyone to send to the internet but restrict members of 'contract workers group' to just certain domains.
This blog post is meant to show how easy it now is to accomplish this oft heard request in Exchange 2010. Transport rules, introduced with Exchange 2007, provided a lot of new options for administration of mail resulting in even more requests for additional functionality. The rules now have new predicates and actions extending the possibilities of what can be done.
In particular, the predicates for address matching that were previously only available on the Edge role are now available for Hub role as well!
For more information about the new predicate and actions see the following links below:
Exchange 2010 Transport Rule Predicates:
http://technet.microsoft.com/en-us/library/dd638183.aspxExchange 2010 Transport Rule Actions:
http://technet.microsoft.com/en-us/library/aa998315.aspx
So I will use the 2nd "request" above to demonstrate how to create a rule in 2010 to accomplish it.
For our example, the rule will restrict "Active Directory Mail enabled users" who have their 'Department' defined as 'Temp Employees' from sending mail to the internet, except they must be allowed to send to 2 external domains called: 'partnerdomain.com' and 'fourthcoffee.com'. Additionally, to reduce Helpdesk calls, you want to send an NDR when they violate the rule. For demonstration purposes I will use 2 Conditions, one Action and one Exception.
Creating a new rule
1. Conditions
a. First condition:
"Sent to users that are inside or outside the Organization, or partners"
Screenshot #1 above, set the dropdown to Outside the Organization option
b. Second condition:
"When the sender's properties match text patterns".
Now note the new options with this in the 3rd screenshot below allowing selection of Active Directory properties on the user object!
Here we will be using the 'Title' property to match the rule to a sender.
2. Actions
"Send rejection message to sender with enhanced status code". The text you add here is displayed in the "Diagnostic information for administrators:" section of the NDR and can say whatever you wish. Originally I started out with "You may only send internet mail to @fourthcoffee.com and partnerdomain.com".
While the NDR provides the information, it is somewhat 'hidden' to be practical for your typical user, so I will create a customized DSN. At this point, all we need to do is specify the text and enhanced status code for our administrators. The new text will be "Diagnostic information for System Administrators" and we specified a specific and unique error code 5.7.122 that is easy for administrators to associate with this rule, should troubleshooting be necessary.
3. Exceptions
"Except when a recipient's address matches text patterns". This is where we add domains that these senders are allowed to send mail to on the "Specify text patterns" dialog box.
And finally, this is the customized NDR that senders receive when violating the rule we created. This test was to two recipients where one is an allowed domain, Janer@fourthcoffee.com, and another is not an allowed domain: mthomas@e2k3.dom.
Notice how the NDR was only generated for the rejected recipient. All other recipients were allowed through.
For more information:
- Understanding Transport Rules
http://technet.microsoft.com/en-us/library/dd351127.aspx- Understanding How Transport Rules Are Applied
http://technet.microsoft.com/en-us/library/bb124703(EXCHG.140).aspx- Create a Custom DSN
http://technet.microsoft.com/en-us/library/aa996803.aspx- Associating a DSN Message with a Transport Rule
http://technet.microsoft.com/en-us/library/bb123506(EXCHG.80).aspx
- Dave Forrest
(Contributions by Scott Landry, Stephen Gilbert and Steve Clagg)
PSTStation
written by admin on Jan 18, 2010