Do you use the categories feature in Outlook to identify your mail?  If so, you might want that category information to be passed to others in your organization.  Starting with Exchange 2007, all categories get stripped from sent messages. Below is the PowerShell you can run to ensure that the category information stays put.

set-transportconfig -clearcategories $false

To turn it off again, change the flag to $true.

One of my most popular blog posts is “Control Outlook 2007 Junk Mail Settings via GPO“. I’ve used this policy and corresponding text file for nearly two years now, without any issues.

And then I upgraded the mail server to Exchange 2010 SP1.

It was reported to me (and the “interwebs” confirm) that the import and processing of the text file for the “safe senders” has a bit of a special “feature”.  If you have any addresses on the list that match your internal domain, they are removed a few minutes after the import happens.  And if you manually add any internal domain addresses to the safe senders list, they disappear too.  This happens with the Outlook 2007 and Outlook 2010 client. 

There is quite an extensive forum posting about the issue from early 2011 that you can check out. It includes some PowerShell to adjust transport rules so that domain mail has a reduced spam level. I haven’t tried that though, as this issue isn’t mission critical for our office.

But if you or your end users have noticed this behavior, it isn’t insanity. It’s just not working the way it did with Exchange 2003.

With Exchange 2010 SP1, I have a lot more options for helping users manage their emails and help our company meet requirements regarding email retention policies, compared to past versions of Exchange. While the original Exchange 2010 RTM “Managed Folders” features are still available via PowerShell, the most current iteration of MRM involves Retention Tags and Retention Policies.

While our lawyers hammer out the details regarding how long we should be holding onto mail, I’ve been playing around with the tags and working out the most suitable way to implement the technology for our office. Part of this involves the use of the “Online Archive” feature as a way to eliminate the difficult to manage PST files and to ensure that the primary mailbox database remains small enough to restore quickly in the event of a system failure.

Online Archives act as an extension of the primary mailbox and the folders and mail within it are still subject to the retention tags that were applied to mail messages and folders. So for my needs, the “archive” is simply a place to automatically move the mail that is subject to our longer retention needs.

By default the label of the archive in OWA and Outlook is “Online Archive – User Name”, however for my office I’d like to change the name from “Online Archive” to something more appropriate for our use of the feature, like “Retained Mail – User Name”. 

The word “archive” seems to imply that any message put in that area will be saved indefinitely and I want to make sure it’s clear that those messages are still subject to the retention rules. It’s a cosmetic change and mostly semantics, I know, but I think it’s important for the scope of our project.

Within EMC there is a spot on each users mailbox settings where you can customize the display name of the title. I changed my test account and was happy to see it reflected in OWA and Outlook 2007.  We’ll be upgrading our users to Outlook 2010 in order to fully support the retention tag features, so I updated my lab workstation to Outlook 2010 as well.

Much to my dismay, I noticed the online archive title was not customized in Outlook 2010. It now read, “Archive – email address”.  Curious.  I did a little search on the Internet and found a detailed posted describing the problem from fellow MVP, Tim Harrington.  The post dates back to December 2010, so I’m disappointed that the bug still exists after a year’s worth of Office 2010 patches and updates.  But there you have it.

Another quick note on Office 2010… If you launch Outlook during your Windows session, then close it and launch it again, it may hang on the “Loading Profile” step.  Switch over to Task Manager and you’ll likely find several “agent” processes.  Kill them and Outlook will load properly when launched.

One of the things I allowed certain end-users to do via Outlook was manage some of their own distribution lists. With a small office and a small IT staff, constantly changing distribution list membership was an easy thing to just delegate back to the people who really “owned” those lists. In Exchange 2003, it was an easy process to delegate that ability to end-users by making them the “manager” of the list.

Shortly after the migration to Exchange 2010, I started getting reports that the distribution lists could no longer be changed by the designated list managers. Exchange 2010 RBAC roles include a role called “MyDistributionGroups” that grants the ability for end-users to view and modify distribution groups. However, it also grants the right to create new distribution lists, which was not something I wanted for non-IT staffers.

I found this great blog post, Allowing End-Users to Manage Distribution Group Membership, in Exchange 2010 by Mike Pfeiffer on how to create a custom locked-down role for distribution group management using PowerShell. Written in early 2010, it’s still get lots of great comments and usage – it certainly made my day easier!

Once I had my Exchange 2010 server up and running, I had a need to create a new store. Unfortunately, things didn’t look so great when the store wouldn’t mount after I created the store in the GUI console.  There were even some fine error messages in the logs letting me know that Exchange was unable to mount the store. If you search the Web for answers to this problem, you’ll find all sorts of potential solutions and ideas.

Turns out the thing that worked best for me was some patience. Exchange 2010 is deeply ingrained in Active Directory and Active Directory does things at it’s own pace.  Sometimes immediately, sometimes in 5 minutes and sometimes in fifteen.

So go ahead and read all those links you found in the great WWW and then after about 5 minutes, go back and try to mount that database again.  Chances are, it’ll work just fine.

The “Receive” Connector is a funny thing in Exchange 2010. The receive connectors on my system seem to double as “Send” connectors depending on who’s doing the sending. Once my new server was up and running, it was a no brainer to make a proper “Send” connector so the server could access the Internet to deliver mail to external parties.  I was also able to quickly bring up “Receive” connector to collect mail from our Barracuda appliance.

Then I started tackling the servers within our organization that send alerts and reports via email.  I added their network addresses to the same connector I used for the Barracuda device, since they are all on the same network.

All the devices seemed happy until I ran across one that needed to send messages to external recipients. Turns out that on Exchange 2003, I was using the same connector for both internal and external relaying without issue, but Exchange 2010 is a little pickier from a security standpoint (a good thing) and I had to create a special receive connector to handle external relaying.

So why are we using “receive” connectors to relay external mail?  The receive connectors collect mail coming to the Exchange 2010 server which are then sent out using the Internet send connector.  So while all your devices are sending mail, the Exchange server is both receiving it and sending it.
Of course, I wouldn’t be writing a post about External Relays if there wasn’t something special about them. 

When creating an external relay you want to be sure to un-check all the security mechanisms from the Authentication tab, since it’s likely you are relaying mail for things like your UPS which might be “phoning home” with updates to a support provider or copier/scanners that might need to send a scanned items to an outside party – all types of devices that likely won’t have a mechanism to authenticate to your mail server.

You also need to set your “Permission Groups” to Anonymous, but the configuration doesn’t end there.  Be sure to kick off this little extra PowerShell as well.

Get-ReceiveConnector “External Relay” | Add-ADPermission -User “NT AUTHORITY\ANONYMOUS LOGON” -ExtendedRights “ms-Exch-SMTP-Accept-Any-Recipient”

Now that this relay is pretty wide open, so lock down which IP addresses from your network are allowed to use it so that its well controlled.  If you need some screenshots for the configuration, check out this post from the Lazy Network Admin.
http://www.lazynetworkadmin.com/knowledgebase-mainmenu-6/2-windows/149-exchange-2010-configure-anonymous-relay-to-external-domains