I often find myself reiterating the fact that IMF is not a full-featured anti-spam product. We can't really expect the same level of functionality and reporting from IMF that you would accept from these third party products that you pay for.

One very frequently requested feature is the ability to create "white lists" -- lists of senders or domains from which messages should not be filtered at all. Exchange has a "black list" of senders who should be blocked, why not a white list of the good guys, the important customers or contacts that my users don't ever want filtered? To a certain extent, the absence of this white listing feature is understandable and even logical. Just like blacklists, maintaining whitelists is a hassle. Also, consider the fact that the SMTP protocol provides the ability to spoof any sender. If I were a spammer, I would really love to get a list of addresses people have whitelisted, and even if I didn't, you could get spam from addresses on your whitelist simply because many email addresses invariably, and inadvertently, end up in spammers' databases using the methods they do.

One alternative to this whitelist of senders or sending domains -- that can be easily spoofed -- is to build a whitelist of IP addresses of SMTP hosts I trust. These are easy to discover, typically are the same hosts that the sender's MX records point to, and by adding them to a trusted list, we allow all senders from that organization to send us mail. This is the Global Accept list in the Connection Filtering tab.

Another important issue is the ability to selectively apply IMF filtering and either, exempt certain recipients from it, or only apply it to certain recipients. This functionality did not ship with IMF v1, nor with IMF v2 that was included in SP2. However, based on strong user demand I suspect, Microsoft did add this functionality. You can now create registry entries to control this -- called RecipList -- a list of Recipients you want to have IMF applied to or exempted from, and CheckRecipients -- which controls the behavior for those recipients. This is documented in KBA 912587.

Most third-party vendors allow you to block or allow messages that have certain keywords in the subject or body. IMF v1 did not ship with such functionality. IMF v2 implements this. Unfortunately, there's not GUI tool to manage this keyword functionality. The feature is implemented through an XML file. This syntax, and usage of this file, is documented in the SP2 Release Notes. It lets you change the SCL value that is otherwise assigned to that message by the value your specification.

Finally, the other aspect of about this blackbox called IMF -- how do I know if this is even working? There are no specific IMF logs that record action taken on each message, nor does the SMTP log have anything about what IMF does (since IMF really comes into picture after SMTP has received the message).

Luckily, IMF does have perfmon counters that can be monitored. These tell you messages scanned for UCE per second, total messages scanned, % of total messages that turned out to be UCE, and %UCE in last 30 minutes, as well as number of messages tagged at each SCL value (numbered 0-9).

Additionally, you can have Outlook display the SCL assigned to each message.
Posted by Bharat Suneja IMF and other messaging hygiene components
24 JUL 2006 11:06 EDT (15:06, GMT)
When talking about Exchange Server 2003's anti-spam features, most folks think about Intelligent Message Filter, or IMF. This is the content filter that scans inbound messages and rates messages for the probability of being spam. This rating is called "Spam Confidence Level" (SCL). IMF can be configured to take actions at the gateway -- this would be the first Exchange server that handles inbound Internet mail and has IMF enabled -- or at the Exchange mailbox store where the message is being delivered. The actions are taken based on these SCL ratings -- you can configure IMF to drop, reject or accept the messages at the gateway if it meets or exceeds a certain threshold, and at the Store you can configure it to move messages to the user's "Junk Mail" folder.

IMF shipped as a separate download after Exchange Server 2003 was released, and a newer version -- IMF v2 -- became part of Service Pack 2. I am often asked how good it is at fighting spam -- my experience with it has been great. I think it works very well, and stops most spam with very few false positives. By itself, it doesn't have all the bells and whistles you'll find in a commercial (and therefore costly) anti-spam software. However, for many smaller organizations that do not have such requirements and, are often on a budget, it gets the job done along with some other pieces.

It's important to understand these other pieces of what Microsoft calls "Messaging Hygiene" -- together they form a more complete anti-spam solution.

A message comes in to your Exchange Organization over an SMTP connection from a sending server. Connection Filtering is the component that drops connections based on Real-Time Block List (RBL) look-ups. Additionally, if you frequently receive spam from certain IP addresses, you can insert them into the Global Deny list. This provides a great opportunity to drop a large number of messages at the gateway -- if you can imagine the resources it saves by dropping a suspect connection -- which could potentially have delivered tens or hundreds of messages over that single connection that other filtering mechanisms would then have to process, and possibly forward to the user whether tagged as spam or not!

Connection Filtering also has a Global Accept list, which not only accepts messages from the specified IP addresses, but also gives those messages an express lane to pass through with none of the other filters applied.

Next in line is Sender ID filtering. Here, we're looking at the sending host's IP address and the sender's domain, and verifying whether it is being delivered by the IP addresses that are authorized to deliver messages for that domain. This authorization comes from a new type of text record in the sending domain's DNS -- called an SPF record. It's a simple concept. If I can insert a list of IP addresses that send outbound mail for my domain in my (external) DNS, when you receive any messages that claim to be from my domain, you can quickly check with my DNS servers whether it shows up in that list. As more folks start to use this -- many already do -- this can become a great tool against the spoofing of SMTP headers, which is very easily done. Until that happens, for messages that fail the SenderID test, you can simply have Exchange scrutinize it further.

Next stop is Sender Filtering -- a list of email addresses or domains that you don't want to receive email from that are explicitly specified -- the typical black-list feature that most anti-spam tools have. Possibly another few messages dropped. I think maintaining such blacklists is always a hassle, but if you find the same sender or domain spamming you frequently, and isn't caught by Connection Filtering (or Sender ID), this comes in handy.

Next, the message has to deal with Recipient Filtering. Here you can choose to have Exchange drop all messages for Recipients that do not exist in your directory (AD). It makes sense to do so -- why accept messages for email addresses that do not exist in your system and subject them to additional processing, and also generate NDRs? Additionally, you can also specify Recipients that do exist in your system to be filtered -- for instance, recipients like internal distribution lists, public folders, or certain mailboxes that you may not want to receive Internet mail for. Imagine another chunk of spam being dropped at this layer as well, and all this before we even receive the complete message.

After passing all these checks, messages finally get to deal with IMF, also referred to as Content Filter. It scans the message content and assigns the messages an SCL, and drops or delivers it as noted earlier.

If you can visualize an SMTP session, which starts with an SMTP connection, the MAIL FROM command (after HELO/EHLO), the RCPT TO, and finally, the DATA -- you can understand at which different points during that session these different filters are applied, and how effective such an approach can be.
Posted by Bharat Suneja Users with multiple email addresses
21 JUL 2006 20:13 EDT (00:13, GMT)
Quite often you will come across users that need multiple email addresses, at times from the same SMTP domain as their "primary" address, or at times from a different SMTP domain altogether.

Exchange allows you to do this either by creating a Recipient Policy to generate such addresses for the all or a subset of recipients in the Organization, or by manually entering the address in the Email Addresses tab in a user account's properties. If the address is from a different SMTP domain, you would need at least one Recipient Policy for that domain.

Once you do either of the above, users can receive email for any addresses seen on his/her account's Email Addresses tab. These are known as proxy addresses, and some folks also refer to them as "aliases." However, here's where the convenience of being able to have multiple email addresses ends.

When a user with multiple email addresses sends an outgoing message to Internet recipients, it always goes out from the user's default or primary email address. This is the email address that the Email Addresses tab displays with an uppercase SMTP.

When you try to insert the user's alternate address in the "From" field when sending a message, it automatically resolves to the user's display name, and gets sent out using the user's primary email address.

Annoying as it is, I've always been surprised by the fact that many other mail clients can accomplish this fairly easily, even when working with Exchange, as long as they use SMTP to submit messages. This means you can get this functionality by using Outlook Express and configuring your alternate email address(es) in it.

There are a couple of other alternatives to do this. One alternative is to create a separate mailbox and assign the user Send As permission to that mailbox. Assign the alternate email address as the primary SMTP address for that mailbox. Now the user can insert the other email address or username in the "From" field when composing a message, and it will go out using that account's primary email address. Inbound email for that account can be redirected to your user's mailbox using Delivery Options from the other account's properties.

Alternatively, the user can also open the other account as an additional account in Outlook.

I frequently recommend IvaSoft's ChooseFrom utility to accomplish this without going through the complicated set-up above, and it seems to work better for most users. I am hoping sooner rather than later the Exchange and Outlook product groups at Microsoft will figure this out and include this feature out of the box.
Posted by Bharat Suneja When disaster strikes: the new disaster recovery options in Exchange Server 2007
20 JUL 2006 23:15 EDT (03:15, GMT)
If you've been using Exchange for a while, at some point the thought of being able to replicate Exchange server data has probably crossed your mind. What if an Exchange server could be replicated to another server, and have the replica simply wake up and take over the job in case the original, or primary server, should face an outage? Such a scenario would be ideal for disaster recovery, and do wonders for your SLAs and uptime statistics. Some applications do this, including Microsoft's own SQL Server.

However, this option hasn't been available for Exchange servers so far. Not without some fairly expensive third party solutions and some fairly complicated setups at times. No native, built-in solution in Exchange -- nothing out of the box.

In absence of the above, many Exchange folks have looked at, and implemented, clustering -- in particular Microsoft Clustering Services (aka "MSCS"), also referred to as High Availability Clustering. Exchange Server 2003 provides a robust clustering solution. The concept is to host Exchange "virtual servers" (EVS) that reside on a cluster node, referred to as an "active node", which fails over to a standby node referred to as a "passive node." Microsoft has supported Active/Active clustering as well, where two nodes host two different instances of Exchange virtual servers, and one EVS can fail over to another "active" node. However, this model has severe limitations, including scalability limitations, and Microsoft has actively discouraged deployments of active/active clusters.

Regardless, clustering only provides part of the solution, and it raises other issues that need to be addressed. For instance, clusters only provide hardware redundancy -- when one cluster node goes down, another node takes on the responsibility of hosting an EVS. If you are not using active/active topology, you will have one or more passive nodes sitting in the cluster doing nothing more than simply awaiting the signals (or the lack thereof) from an active node to hand over the responsibility of hosting an EVS. Many folks consider this to be a waste of hardware.

Further, clusters need shared storage to locate Exchange databases, log files, SMTP queues, and such. The shared storage becomes a single point of failure -- if it fails, no number of standby or passive nodes can save you from an outage. Clustering also comes with a higher price tag -- the initial cost of implementing shared storage, and carefully selecting clustering components from a list of clustering-approved hardware, as well as ongoing operational costs that clustering solutions impose on an organization. Nevertheless, if high uptime is a priority, clustered deployments have so far been a reasonable solution.

Exchange Server 2007 brings some relief for folks looking for higher availability and less downtime. The good news is that both these solutions -- 1) Local Continuous Replication (LCR) and 2) Cluster Continuous Replication (CCR) -- can be implemented without the comparatively complicated and costly solution provided by previous iterations of clustering.

The concept behind Local Continuous Replication (LCR) is quite simple -- have Exchange copy the transaction logs from a production store to another volume on the same server. If the production store faces an outage of some kind, the second copy can be mounted within a matter of minutes. A good scenario to compare downtime in such cases -- in the time it would take to simply locate a backup tape, let alone begin recovering it, your users would be up and running on a second copy of the database. Yes, it's really that simple! And the implementation -- whether from the GUI or the command-line -- keeps that simplicity theme alive.

Using LCR has some requirements. You can only setup a single store in a Storage Group. It cannot be used for Public Folder Stores if you have more than one PF Stores in your Org. (Public Folders do have a built-in replication mechanism that provides similar functionality for PF Stores, making PF Stores somewhat unsuitable candidates for LCR, in my opinion). You need to use volume mount points -- a feature of the operating system that allows you to map a disk volume as a folder on an existing volume, bypassing the alphabetical limit of 26 "drive-letter mapped" volumes on a server. Of course, you will need to plan for adequate storage to be able to maintain the LCR copy and to use it in production in case of failure -- you do not want to be using cheaper disks or storage that doesn't provide similar I/O performance as the primary storage does.

Great as this solution sounds, it does not protect you from an actual server outage like clusters do. If you want protection from such outages as well, you will need to look at clustering.

Exchange Server 2007 has a new clustering model that enables you to deploy Exchange clusters without using any shared storage. This is facilitated by Windows Server 2003's Majority Node Set clusters. MNS lets all cluster nodes maintain a local copy of the quorum, instead of locating the quorum on a shared disk. If you are interested in knowing more about MNS, here's the FAQ that talks about it.

With the cluster's need for a shared quorum disk removed, the application is now free to offer functionality that can bypass shared storage and locate data on each cluster node -- which is what Exchange Server 2007 does. Just as LCR ships data to another disk on the same server, Cluster Continuous Replication (CCR) ships data to another node in the cluster. In case of an outage, the second node can pick up the responsibility of hosting an EVS with its own local copy of the data. You also need a third computer that hosts a simple shared folder to host an additional copy of the quorum -- for situations where the two nodes cannot communicate with each other but are still up, this comes in handy to provide the required majority in the Majority Node Set cluster. Microsoft recommends creating this fileshare on a Hub Transport server -- and it can be used by multiple MNS clusters in your Org.

To facilitate this process in both of the above cases -- LCR, and more so for CCR -- certain changes have been made in Exchange. The size of transaction log files that Exchange generates has been reduced from 5 MB -- the size we've been used to for as long as I can remember -- to 1 MB. This facilitates the copying of transaction logs to another cluster node. Smaller files can be copied faster and more frequently, and the current transaction log, that remains locked by the EVS, holds less data in case of a failover.

A frequently asked question at this point is: Is there any data that has not been copied over to a CCR copy, or an LCR copy in case of local replication? Yes, there invariably will be some data at any given point that hasn't been copied to the alternate location, including the current transaction log that remains locked because Exchange is using it. So yes, when the failover occurs, some data will not be moved over. To circumvent this, a new feature called the Transport Dumpster has been implemented. Remember the Hub Transport server role in Exchange Server 2007? This is the role that's responsible for routing mail to and from Mailbox servers, including all local mail originating from the same server and destined for a mailbox on the same server. It caches some of the most recent messages in the Transport Dumpster.

When a failover occurs, Exchange can detect the recent messages cached in the Transport Dumpster that have not been copied over to an LCR or a CCR copy and backfills the data. In a very short time after the failover occurs, the missing messages make their way back to users' mailboxes from the Transport Dumpster.

Together, LCR and CCR provide the kind of disaster recovery solutions Exchange folks have asked for over the years. The ability to provide storage redundancy, as well as server redundancy -- you can pick which one you want to implement depending on your requirements. Conceptually, these are brilliant. The simplicity with which these can be implemented is no less impressive -- both from the command-line, and from the Exchange Management Console GUI.

With every new version, there is some learning to do. However, for features like these, I am willing to learn and relearn Exchange a few times. Anything that can provide higher uptime and decrease the amount of downtime in case of outages is very welcome.

If you haven't already downloaded Beta 2, now's a good time to do so and play with LCR and CCR.
Posted by Bharat Suneja Understanding exchange server 2007 server roles
19 JUL 2006 14:13 EDT (18:13, GMT)
One of the first things that most Exchange folks get intrigued about when the subject of Exchange Server 2007 comes up is the fact that it has pre-defined server roles.

In Exchange Server 2000/2003, we have been used to these concepts in a limited way. For instance, front end servers are Exchange servers that do not host mailboxes, but take on the burden of providing access to users using the different protocols supported by IIS:

1. HTTP/HTTPS for Outlook Web Access, Outlook Mobile Access (OMA), Exchange Active Sync (EAC), and RPC over HTTP(S)
2. IMAP4 and
3. POP3.

The other server role we're used to is the bridgehead server. These are Exchange servers running SMTP that deliver mail from one Routing Group to another over Routing Group Connectors, or to SMTP domains (aka "namespace" or "address-space") over SMTP Connectors.

Though there is no explicitly defined or configurable role of a back-end server, it is generally an Exchange server that hosts mailboxes.

In most medium-sized to large deployments there are SMTP hosts that do not typically run Exchange server, and are generally located in Perimeter networks (aka "Demilitarized Zones" or DMZs). These could be servers running Windows SMTP service -- a component of Internet Information Services (IIS), or some other MTA like Postfix, Sendmail, et al. These act as "gateways," or more appropriately, "SMTP Gateways," and are responsible for delivering mail to destination SMTP hosts on the Internet.

Most small organizations do not deploy Exchange in such a topology -- they neither need to scale out in such a manner, nor do their cost structures allow for it. Such organizations are usually seen deploying a single or a few Exchange servers that take on all the roles -- mailbox & public folder server, bridgehead, OWA, and have the same server(s) also act as SMTP gateway to deliver mail to Internet recipients.

Nevertheless, as far as the larger deployments go, and from a management point of view, I've always questioned some of these aspects -- the availability and accessibility of Outlook Web Access on a mailbox server when front end servers are deployed, for instance. Exchange Server 2000 and 2003 do not allow you to select the components you want to install -- for the most part, it's an all-or-nothing deal.

Exchange Server 2007 addresses this concern by defining server roles, and installing only the components required for each server role being installed on a server.

Servers with the Mailbox server role, as the name suggests, host mailboxes.

Client Access Server (CAS) is the equivalent of a front end server -- clients connect to the CAS to access their mailboxes using Outlook Web Access, POP3, IMAP4, Exchange ActiveSync, and RPC over HTTP -- renamed "Outlook Anywhere." One important exception is Outlook clients accessing Exchange using MAPI, which will still talk to the Mailbox server role directly.

The Hub Transport server role is the equivalent of a bridgehead server -- it routes mail based on information found in the Active Directory, and applies policies to inbound and outbound mail. The hub transport server receives mail from mailbox servers in an AD site and transports internal mail for other AD sites to the hub transport servers in those sites (which in turn deliver it to destination mailbox server(s) in their site), or delivers Internet mail to edge transport servers, or non-Exchange MTAs, generally called mail relays or smarthosts.

The Edge Transport role is a new server role that is intended to act as a smarthost. Edge transport servers typically reside in perimeter networks, and send and receive Internet mail. In other words, it is intended to replace the non-Microsoft smarthosts in your perimeter networks. This is where you will also apply antvirus and anti-spam filters to inbound Internet mail, and drop a good amount of suspicious messages before the remaining ones are delivered to hub transport servers on your internal network. As such, edge transport servers are not members of your AD Domain, and cannot exist with any other Exchange Server 2007 server role on the same server.

Another new server role, the equivalent of which does not exist in your current Exchange topology, is the Unified Messaging role. This is by far one of the more interesting and exciting pieces of new functionality in Exchange. The UM server is intended to talk to your telephony infrastructure and allows access to your voicemail, email and fax messages over the phone or by email. It also includes functionality that allows you to access your calendar, and adds conveniences like moving or rescheduling your appointments based on your calendar info residing in your mailbox -- over the phone!

It doesn't really end here. The UM server also provides an "Auto-Attendant" feature that lets you call your company's (toll-free?) number and directs the call to whoever you want to talk to, without having to remember their office, mobile, or home phone numbers. Having worked with and becoming completely dependent on a different implementation of the Auto-Attendant -- the one created by my former employer Nuance, the leading speech technology company -- I can't wait to see unified messaging get deployed and what the experience is like for most users.

As you can probably tell, I am particularly excited about unified messaging. More so because, not very long ago, I had envisioned such functionality being provided by Nuance -- the ability to have a speech interface to Exchange, for the number of occasions I've been faced with where I had no access or urge to fire up a laptop to check email or meeting schedules, when a Blackberry or Windows Mobile handheld was having issues connecting or doing what I commanded it to do for any number of reasons. Folks frequently on the road will love this functionality if it lives up to its promise!

Given the number of times I've been asked this question, it makes sense to mention it here. Most of these roles can happily co-exist on a single server, with one exception as noted above. The Edge Transport server role cannot exist on the same server as any of the other server roles, primarily because it needs to be installed on a server that's not a member of your AD Domain(s), and sits in your perimeter network. Also worth nothing -- if you are implementing clusters, these can only have the mailbox server role.

The new roles-based deployment of Exchange servers promises to make server installations simpler, allowing you to only install the components that will be used on a particular server. It will also help in making such deployments more secure -- imagine more compact installs of Exchange based on the roles, and much less code sitting on your servers that could potentially be exploited, or needs to be managed and patched. It also translates into more stable servers with decreased potentials of version mismatches or interoperability issues between different versions of the code.
Posted by Bharat Suneja Installing your first Exchange Server 2007 Beta 2 in a lab
18 JUL 2006 18:37 EDT (22:37, GMT)
Those interested in Exchange Server 2007 can download Beta 2 -- the first publicly available beta -- from Microsoft's web site today.

Here are some system requirements, pre-reqs, and some things you will need to consider when installing the first server.

System Requirements:
CPU: For 32 bit systems, you need a minimum of Pentium 800 Mhz. 64-bit systems need either support for Intel's EM64T (most Xeons and Pentium D) or AMD64 -- commonly referred to as x64 systems. Exchange Server 2007 will not run on Intel's Itanium processors.
Memory: 1 Gb + 7 Mb per user minimum, 2 GB + 10 Mb per user recommended.
Storage: At least 1.2 Gb free space on volume where you'll install Exchange, at least 200 Mb on system drive.

Pre-Requisites:
You will need the following installed on your server before you start installing Exchange Server 2007 Beta 2:

1. Windows Server 2003 Service Pack 1
2. Windows PowerShell (aka "Monad")
3. Microsoft Management Console (MMC) 3.0
4. Dot Net Framework 2.0
5. AD Domain mode/functional level at least Windows 2000 native mode

As noted earlier, Exchange Server 2007 has different pre-defined server roles. To have a functional installation of Exchange, you will need at least 2 server roles -- Mailbox server and Hub Transport roles. These two roles provide the functionality of a "normal" Exchange server -- it will allow you to host mailboxes, public folders (should you need to), mail transport, and mailbox access/connectivity using Outlook/MAPI. To get OWA, RPC over HTTP(S), ActiveSync, et al, you will need to add the Client Access Server (CAS) role.

The good news is all three roles can be installed on the same server. Also note, you do not need an Edge Transport server role to make Exchange Server 2007 work.

It will take some time to get used to the new Exchange Management Console (EMC) -- you will see a completely different look-and-feel. The Actions pane on the far right of the console has plenty of context-sensitive short-cuts that make it unnecessary to get into multiple levels of dialog-boxes, and reduce the mouse-clicks it takes to accomplish many common tasks. The console will also force you into the mode of managing servers by server roles. As a side note, Recipients (users, groups, contacts, et al) are now managed from the EMC, not from Active Directory Users & Computers console as in previous versions.

It will also take time to get used to and become productive with the command-line interface -- Exchange Management Shell -- which is built on top of Windows PowerShell. To minimize the learning curve, I would strongly recommend reading the Getting Started Guide included in the PowerShell documentation, and playing with the shell even for performing non-Exchange-related tasks such as registry lookups/modifications.

You will find parts of the Help file that ships with this beta -- ExchHelp.chm -- are incomplete because the product is still in beta, and the documentation is a work in progress. Nevertheless, at first looks it seems this is perhaps one of the better-documented betas out there.

Some quick notes as you navigate through your first Beta 2 install:

• You can setup Exchange Server 2007 Beta 2 using the GUI setup, or from the command-line
• Exchange Server 2003 Recipient Policy instructs Exchange that it should receive email for a SMTP domain, and also generates email addresses. The Exchange Server 2007 equivalents are Allowed Domains, configured with a simple command:
  new-alloweddomain "foo.com"
  or from Organization Configuration | Hub Transport | Actions | New Accepted Domain.
  Email addresses are generated by Email Address Policy, also managed similarly from the command-line (new-EmailAddressPolicy) or from the Actions panel in the GUI.
• If you are testing mail flow without an Edge Transport server, you will need to modify the default Receive Connector to receive inbound internet mail. This Connector requires authentication by default.
  To list the Receive Connectors configured:
  get-ReceiveConnector
  Use the following command to modify the default Receive Connector to accept anonymous connections:
  set-ReceiveConnector --identity "Default Receive Connector name here" --permissiongroup anonymous
• One of the first tasks many folks perform after an Exchange server installation is to move Exchange databases to alternate location, usually to a different volume. Exchange needs to take the Stores offline to perform these operations -- it changes the Storage Group/Store configuration in AD and moves the files to the alternate path.
  Here's how you get this task done using EMS:
  move-StorageGroupPath -- identity "Name of Storage Group" -- logfolderpath "D:ExchangeLogs"
  move-StorageGroupPath -- identity "Name of Storage Group" -- systemfolderpath "D:ExchangeLogs"
  move-databasepath -- identity "Name of Mailbox Store" -- edbfilepath "D:ExchangeEdb"
  (To get a list of Storage Groups and Databases, you use the Get commands... e.g.: Get-StorageGroup and Get-MailboxDatabase/Get-PublicFolderDatabase
• To enable Recipient Filtering to drop messages for non-existent recipients:
  Set-RecipientFilterConfig --RecipientValidationEnabled:$true
• By default the Content Filter Agent (we know this guy as IMF or Intelligent Message Filter from Exchange Server 2003) is enabled on Edge Transport servers for inbound internet messages/messages sent by unauthenticated hosts. To enable Content Filtering:
  Set-ContentFilterConfig -- Enabled:$true -- SCLRejectEnabled:$true -- SCLRejectThreshold:8
  The other actions for Content Filter are SCLQuarantineEnabled (where -- SCLQuarantineThreshold specifies the SCL threshold for quarantining) and SCLDeleteEnabled (where -- SCLDeleteThreshold specifies the SCL threshold for deletion).
• To exempt specific domains from Content Filtering:
  Set-ContentFilterConfig
  BypassedSenderDomains:domain1.com,domain2.net,domain3.edu
  This is the much-demanded white-list feature that was missing from IMF in Exchange Server 2003. It takes list of domains as an argument, the maximum value being 100.

These, and many other commandlets are documented in the ExchHelp.chm file. The key is to get used to the command shell interface. The reason you need to learn the shell -- the GUI console can only perform a subset of tasks that the shell can. Most advanced tasks can only be performed by using the shell. Besides, mastering the shell will certainly make life easier by being able to automate routine administration tasks.

I've seen, and at different times been able to relate to, the reaction I get from many folks who are quite vocal about their dislike for command-line interfaces. One of the more common reactions I get is: "That's the reason for using Windows and not some open-source OS". I am sure we'll continue to see this debate carried on in different forums as we move along from Beta 2 to RTM.
Posted by Bharat Suneja Buckle up for Beta 2
17 JUL 2006 23:17 EDT (03:17, GMT)
Exchange Server 2007 Beta 2 is just around the corner. Soon, those who pre-registered to get the beta will be able to install the first "feature-complete" build of the next major release of Microsoft's messaging and collaboration server. Attendees at Microsoft Tech Ed 2006 in Boston got a generous preview of most new features of this release. Having been closely associated with this release since its pre-beta 2 days, I've seen it evolve into what now seems like production-ready code (albeit only for the select participants in Microsoft's TAP and similar programs for now).

If you've been living and working with the previous two major versions of Exchange, there's a good chance that you're used to thinking of and managing Exchange in a particular way, mostly using the GUI tools like Exchange System Manager console, Active Directory Users & Computers, IIS, et al, and perhaps some scripts. Exchange Server 2003 did not have major architectural changes in the product from Exchange 2000 (compared to the ones seen when we moved from Exchange Server 5.x to 2000).

Most Exchange architects and administrators (I will refer to this bunch of people as "Exchange folks"/we/us) are used to the big architectural changes Exchange 200x brought us, as compared to the earlier Exchange 5.0/5.5 architecture. We are now used to the separation of Exchange 5.x's administrative and message routing units called "Sites", into Exchange 200x's Administrative Groups as administration and security unit, and Routing Groups as the message routing unit. Part of Exchange 5.x's concept of "Sites" became a part of Active Directory -- which lets you define areas of high bandwidth connectivity and associate a bunch of IP subnets -- typically maps to a physical site or geographical location.

We are now used to the logical move to SMTP -- the Internet's standard protocol for transporting email messages -- as the protocol used by Exchange servers to exchange messages within an Exchange Organization (a group of Exchange servers in an Active Directory Forest), and outside. We are also quite used to using AD tools like Active Directory Users & Computers (ADUC) to manage Exchange recipients -- users, mail-enabled groups, and contacts.

As many of you may know by now, all of that changes with Exchange Server 2007. However, at first looks, it is easy to conclude that we're back a full circle to Exchange 5.x days in many ways. For starters, the next version moves away from using Administrative Groups as administrative boundary, which seemed like a wonderful idea to some in the "Platinum" (codename for Exchange 2000) timeframe. Experience has shown us in the past few years that we manage Exchange security on a more granular basis, proving that, for most part, the Administrative Groups are far less useful, and even counter-productive at times.

Message Routing undergoes numerous changes, the major ones being a move away from Routing Groups to manage message routing topology. When Exchange 5.x's directory service was moved to the Windows OS with Windows 2000 and christened "Active Directory", for many of us it was a logical conclusion that Exchange 2000 would use the Site topology defined in AD. Finally, we're there with Exchange Server 2007! I, for one, quite welcome the change, but it will require Exchange folks to work ever more closely with the usually separate AD groups within enterprises.

The other major transport change is that we're partially moving away from using SMTP as the message transport in part of the topology. The transport between an Exchange 2007 mailbox server and Exchange 2007 hub transport server (more about Exchange Server 2007's server roles in a follow-up post) is RPC/MAPI, the same protocol used by Outlook to talk to Exchange servers. At first looks, it is easy to be critical of this move; from a standard protocol to Microsoft's proprietary ones, even though it is restricted to only certain parts of the message routing topology. Nevertheless, if you look at the benefits these changes provide, it may be one of the reasons you will move to 2007.

There are two other major changes that get most of the attention from folks curious about, or evaluating, Exchange 2007. The first one is the support for only 64-bit processors for production use (albeit a 32-bit version is, and will be made, available for testing and learning purposes. Don't let the x86 version into your production environment -- it is not supported as such).

Enough has been written about this already, but what really needs to be understood at this point is the fact that most servers shipping today with Intel or AMD processors are already 64-bit. There are no cost concerns with going for 64-bit CPUs, and the 64-bit Windows Server OS's are also priced the same as their 32-bit siblings. For enterprise and service provider (ISP/ASP) customers that do want to scale up to bigger servers that can host more mailboxes, the 64-bit platform proves to be a huge advantage. Until you reach a certain threshold, adding more memory allows Exchange to use a bigger database cache, dramatically reducing disk I/O requirements. 32-bit CPUs, such as the x86 family, are restricted to 4GB of virtual address space, which is seen as a major scalability limitation by many customers.

The move to 64-bit processor (and therefore, the 64-bit version of Windows server OS) also means there won't be any in-place upgrades of Exchange 200x servers -- which can only run on 32-bit Windows servers. Nevertheless, as our experiences have shown in the past, in-place upgrade doesn't exactly have a lot of fans -- in fact, it is by far the least-used method. Most folks "swing" it -- by installing another Exchange server and moving users to it -- to reduce downtime and the risk of failed upgrades.

Last, but not the least, is the extensive use of "Monad" -- Microsoft's new command line management interface -- now known as Windows PowerShell (thankfully so -- my worst fears were names like Microsoft Active Command-line Management Interface or ACMI… ). Exchange Server 2007 has an extensive, and by most counts quite impressive, layer of command-line management built on top of Monad. It's known as Exchange Management Shell. Experienced admins always envied their Unix/Linux counterparts who can do everything possible on those platforms from the command-line, rather than the half-a-dozen mouse-clicks for almost every task that many of us are used to. A good number of us grew fond of, and proficient, at scripting; wrote or found and modified a whole library of scripts to perform many of those tasks from the command-line.

Monad and the Exchange Management Shell turns that around. For a change, the Exchange Management Console GUI is now built on top of the command-line shell, and under the hood it executes EMS cmdlets to accomplish everything. In other words, every single thing that the GUI does and more can now be done from the command-line because everything that is done inside the GUI is actually executing behind the scenes in the command line interface! All tasks can be accomplished from the command-line, but only a subset of tasks can be accomplished using the GUI. It's the perfect world for many of us!

Nevertheless, if you are command-line challenged or simply prefer the GUI, the new management console will take some getting used to. Most folks I know who've come across the new console seem to love it, and think it's much more intuitive and simplified now.

In the coming weeks, you will be able to download Beta 2 and see and experience these changes first hand. Many of us love it, and I am sure many others may not share the same enthusiasm for the wholesale changes in what has become a critical piece of enterprise infrastructure -- our favorite messaging server, the lifeblood of most enterprises, and a communication medium that's clearly more important for many even compared to the phone.
Posted by Bharat Suneja