In my last article I provided you with a guide in setting up your SharePoint 2010 farm providing it with the capabilities in receiving incoming email which can then be delivered directly to your SharePoint libraries and or lists.  Today we wrap up our 2 part series on email flow in SharePoint 2010 in which I will provide you with another step by step guide in configuring your SharePoint Farm in order for it to send outgoing emails through your Microsoft Exchange server.

The environment

This article builds on the SharePoint Farm setup that I have documented here. It consists of the following servers which would form a common basis in most large organizations.

• Windows 2008 R2 server running Active Directory Domain Services
• Windows 2008 R2 server running SQL 2008 R2
• Windows 2008 R2 server running SharePoint 2010 RTM
• Windows 2008 R2 server running Exchange 2010 RTM
• Windows 7 client running Office 2010 RTM

SharePoint 2010 allows you to configure any SMTP service including the one which I had setup in my previous article to send outgoing email, however we will utilise Exchange 2010 (same instructions apply for Exchange 2007) to provide email delivery to our end users.  Instructions on configuring the SMTP service (i.e. you are not using Microsoft Exchange in your environment) can be found on TechNet.

Creating a Receive Connector in Exchange 2010

If you recall from my previous article when we were configuring incoming email, we created a “Send Connector” in Exchange to forward the messages to the SMTP service that we had configured and installed.  This time round we will create a “Receive Connector” in Exchange 2010.

Launch the Exchange Management Console and navigate to Server Configuration / Hub Transport / New Receive Connector.  The New Receive Connector wizard is invoked.

Enter a descriptive name and ensure “Custom” is selected as the intended use.

Click Next

Leave “All Available IPv4” in your Local Network settings unless you have specific Exchange IP requirements.

Click Next

Edit the IP address of your SharePoint 2010 server.

Click Next

Click New

You will now notice that our SharePoint 2010 Outgoing mail connector is listed with our default Exchange 2010 Receive Connectors.. 

We will now venture into its properties and make a minor permission change.  Click on the “Permission Groups” tab and select Anonymous users.

Click Apply.

Configuring outgoing email in SharePoint 2010 Central Administration

Launch Central Administration and navigate to System Settings / E-Mail and Test Messages / Configure outgoing e-mail settings.

Enter your Outbound SMTP server, i.e. your Exchange server where we created our receive connector and specify a From and Reply-to address.

Click OK

Testing our configuration

Lets navigate to our SharePoint 2010 web application and create an Alert .  In my example I will create an immediate alert for Announcements.

Navigate to your Announcement List and click on List Tools/List and then click on “Alert Me” located in the ribbon interface.

Select “Set alert on this list” and select your Alert options.  Ensure that you have “send notifications immediately” selected for testing purposes.

Click OK

You should receive your notification email that you have successfully subscribed soon after creating your alert.

I will now create a Test Announcement to ensure that the actual alert is delivered.

Alas! 5 minutes later (based on the immediate timer job definition schedule) we have received our email alert confirming that our SharePoint configuration with Exchange was successful.

Did you know that you can also configure outgoing email for a specific Web application?  You might want to do this if you have multiple SharePoint Web Applications hosting specific site collections and would want a different From and or Reply Address setup.

Even though we are now going to configure outgoing email for a specific Web application, you are still required to setup the default farm outgoing email settings as per the above.

Configuring outgoing email for a specific Web application in SharePoint 2010 Central Administration

Launch Central Administration / Application Management / Manage Web Applications.

Select one of your Web Applications and then select “General Settings” from the Ribbon.

Select “Outgoing E-Mail” from the drop down.

It will pick up your default farm settings that we entered in earlier in which you can now change the From and Reply-to address to something more specific for the selected Web application.

Click OK

We are done!  I hope you have found this step by step guide in configuring outgoing email in SharePoint 2010 with Exchange useful, and stay tuned as we continue our journey in configuring our SharePoint 2010 Farm.

Articles in this series

Installing SharePoint 2010 using Least Privilege Service Accounts – Step by Step Guide

Configuring incoming email in SharePoint 2010 with Exchange – Step by Step Guide

Configuring outgoing email in SharePoint 2010 with Exchange – Step by Step Guide

After yesterday’s announcement made by Apple with regards to the latest iTunes version 9 and iPhone OS 3.1, I decided to update both and take advantage of the new features. After updating iTunes to version 9, I docked my iPhone which then detected that an update was available in which it then proceeded and installed successfully. However! When I decided to look at my work Exchange ActiveSync Account I received the following popup as per the below screen shot.

“The account “” requires encryption which is not supported on this iPhone”

My iPhone is the 3G model which apparently does not support encryption, however the new 3GS does. So why did my original ActiveSync Policy (which is set to “Require encryption on the device”) always worked with my 3G iPhone prior to the 3.1 update. As per the following post by Daniel at ExchangeGeek , the iPhone 2/3G was set to bypass this setting and still sync with the iPhone. Okay, so 3.1 has now resolved this “bypass” issue, but where was the notice from Apple warning users and Exchange Administrators that this will be the case.

So here is the deal, if you want your non 3GS iPhone devices to continue to sync with your Exchange Server, your Exchange Administrators will need to create a separate Exchange ActiveSync Mailbox Policy and assign it to non 3GS mailboxes. So let’s begin the process.

Launch Exchange Management Console in 2007 and navigate to Organization Configuration / Client Access Node. Your ActiveSync Policies will be listed as follows.

I have 2 policies setup one being the Default and the other a custom policy that I have created specifically for Windows Mobile 6 devices which I have set as the default policy. This policy enforces device encryption so I will now proceed and create a new policy for my non 3GS iPhone users. On the right navigation pane under Actions, Client Access click on “New Exchange ActiveSync Mailbox Policy..” to invoke the wizard. Fill out the details and ensure you do not select “Require encryption on the device”.

Click New. You will receive the below confirmation message upon completion.

You will now need to navigate to your user’s mailboxes whom own a non 3GS device and assign the new policy that you have just created. To do so, navigate to Recipient Configuration / Mailbox and right click on the respective mailbox user and select properties.

Click on the Mailbox Features Tab, click on “Exchange ActiveSync” and then click on “Properties”

Browse for the new policy that we have just created and then click on OK.

Then click Apply and OK to close the properties of the mailbox.

On the iPhone itself, you should now be able to navigate to Settings / Mail, Contacts, Calendars in which you will notice that your Exchange ActiveSync Account is set to Inactive.

Click on the account and then turn on your sync items.

That’s it. Your non 3GS iPhone users are back in business and are able to sync just as they were prior to the 3.1 update.

Were you caught off guard with this update and do you have many users running non 3GS devices against your Exchange Server? Let me know if you were just as surprised as I was after the 3.1 update.

Welcome back to the final post in this 2 part series, Integrating Exchange 2007 MRM with SharePoint Document Libraries.  Today’s post will wrap things up by going through the process of mail enabling an existing SharePoint document library and creating a new managed content setting in Exchange 2007 providing us with the ability to journal a copy of all messages moved into our “Project XYZ” managed folder located in Outlook, into our Shared collaborative Document Library under our Project Team Site.

Recall from part 1, that the objective of integrating Exchange MRM with SharePoint is to provide us with the ability to store and centralise all emails pertaining to a specific project from multiple users into a single SharePoint document library, that can be easily accessed by the Project Team.  If you missed the initial setup of Exchange MRM, you can access part 1 of this series here.

We finished off our last post by having our Project XYZ Managed Folder automatically pre-created for our specified Exchange users as per the below screen shot.

This has provided all users from the Project XYZ Team site the capability of moving all email records in relation to Project XYZ into this so called “dumping ground”.  At the moment, it’s fairly static and the information “dumped” into this folder isn’t going anywhere any time soon.  But this will now change by creating a new “Managed Content Settings” policy in Exchange 2007.  But just before we go ahead, we need to ensure we have our SharePoint Document Library ready to receive incoming emails.

To mail enable a SharePoint Document Library, navigate to the Project XYZ Document Library in question and click Settings / Document Library Settings / and click on Incoming e-mail settings under Communications.

We will then fill out the details as per the below screen shot.

This will go ahead and create the corresponding Contact address in Exchange 2007.  Please note this article is assuming that your SharePoint farm has been correctly setup to receive Incoming mail.  Click on the following TechNet article for further instructions on how this can be achieved; http://technet.microsoft.com/en-us/library/cc262947.aspx

We can now proceed with the creation of the Exchange Managed Content Setting for our Managed Folder.

To so, navigate to Mailbox / Managed Custom Folders / click on the newly created custom folder, in our case Project XYZ and then click on New Managed Content Settings.

The below wizard is invoked and we will specify the following details as per the below screen shot.

Your goal here should be defined to meet the business requirements and in this example we will want to keep items that are moved into the Project XYZ managed folder for 30 days. After the 30 day period ,the items are permanently deleted to empty the user’s Project XYZ custom folder.

Do not fear however!!  In the next screen we will specify our Journaling options providing us with the capability to auto forward a copy to our SharePoint Email Enabled Document Library that we had created earlier. One of the advantages of using Managed Content Settings and Journaling with SharePoint enabled Libraries, is that you can specify the format of the email message and hence I have selected Outlook Message Format to ensure greatest compatibility.

Click New to Finish.

You will now notice that our Managed Content Settings has been applied against our Managed Custom Folder as per the below screen shot.

That’s it!  Based on your Managed Folder Assistant Schedule that we configured in part 1, all email records that are moved into the Project XYZ Managed Folder in Outlook will be copied to the Project XYZ Document Library as well.  In order to expedite the process and to ensure that it is all working, you can run the following Exchange Management Shell command;

Start-ManagedFolderAssistant

Once the Managed Folder Assistant has been initiated, it should only be a matter of a couple of minutes until you see your SharePoint Document Library populated as follows.

The Folder Assistant is intelligent enough to only copy the emails that are stored under the Managed Folder in Outlook once, avoiding any duplication.  It there are emails with the exact same subject line, SharePoint is also intelligent enough to follow our settings that we configured earlier for our email enabled SharePoint Library. In my setup we set it to not overwrite and hence will append the subject with a unique number as per the below screen shot.

In summary, Exchange 2007 MRM and SharePoint Document Libraries has enabled us to control the lifespan of items that are moved into our Project XYZ Managed Folder that we have created in Exchange and the capability to journal a copy of all records that are moved into this folder to our SharePoint document library for collaborative and archival reasons.

Hope you enjoyed this two part series and am sure you will find use with integrating these two technologies together to meet your business requirements.

There are two technologies in my IT Pro life that I am very passionate about, SharePoint and Exchange, so why not incorporate both passions in a single blog post. In this two part series I will be discussing how we can manage email records from our Exchange mailboxes and archive them in SharePoint Document Libraries for compliance or collaboration reasons.  Exchange 2007 introduced a great new feature set in the name of “Messaging Records Management” or commonly referred to as MRM.  Managed Default Folders is a key component of MRM which will assist us in achieving our archiving strategy.  Exchange 2007’s MRM functionality provides organisations with the ability to set email-retention policies, the ability to manage content residing in mailboxes and to establish an archiving strategy to SharePoint Document Libraries.

This is a great feature when you want to combine email records from various users working on a particular project and have them reside under the Team SharePoint Site Document Library. In this 2 part post I will provide step by step instructions on how this can be achieved with today’s post focusing on Exchange and the creation of our managed “project” folder .

So let’s begin by firing up the Exchange Management Console and navigating to Organization Configuration / Mailbox and then click on the Managed Default Folders Tab. You will notice the system default folders listed as per the below screen shot.

In our case we will create a new Managed Custom Folder for a specific project that we will later integrate with a specific document library located under our project team site.

In order to create our Managed Custom Folder, navigate to Actions and select New Managed Custom Folder..to invoke the wizard.

Enter the Name, Display Name and Description similar to the below screen shot.

Please take note of the Exchange Enterprise CAL requirement.

After filling the details click New. Your managed folder has now been created and listed under the Managed Custom Folders Tab per the below screenshot.

If you are an Exchange Management Shell person and would like to create a managed custom folder that way, all you need to do is simply type in the below command.

New-ManagedFolder -Name Project XYZ -FolderName “Project XYZ”

Now that our Managed Custom Folder has been created, we need to create a Managed Folder Mailbox policy.   Also located under Actions, Select New Managed Folder Mailbox Policy …

Creating a managed folder mailbox policy setting is great when grouping together a set of managed folders that you can then assign to a user mailbox in the one step.

Type in your managed folder mailbox policy name and then select Add to select the Managed Custom folder that we had just created earlier.

Your newly created policy will now be listed under the Managed Folder Mailbox Policies Tab as per the below screen shot.

We now have the capability to assign this policy to our users. So let’s now do so by navigating to Recipient Configuration / Mailbox. Right click on your user and select Properties / Mailbox Settings.

Select Messaging Records Management and then click on properties. From here, click on browse and select the Policy that we have just created.

When applying the settings you will receive a warning regarding compatibility with different Outlook versions, but we can ignore this warning as we are all running Outlook 2007/10 right?

Now that we have created our custom managed folder and policy we need to ensure that our Managed Folder Assistant Schedule has been setup. To so, navigate to Server Configuration / Mailbox and right click on the top pane on your server name and select properties. Then click on the Messaging Records Management tab.

By default it will be set to “Never Run”. We will click on Customize and set a schedule for it to run during non business office hours.

Now rather than waiting for the next scheduled time we can force the process via the Exchange Management Shell by running the following command.

Start-ManagedFolderAssistant

The below entry should appear in your Windows Application Event Log when the Managed Folder Assistant routine is run.

Event Type: Information

Event Source: MSExchange Assistants

Event Category: Assistants

Event ID: 9022

Date: 16/07/2009

Time: 11:01:18 AM

User: N/A

Computer: EXCHANGESERVER

Description:

Service MSExchangeMailboxAssistants. Managed Folder Mailbox Assistant for database Users Mailbox Database/Users Mailbox Database (ed6raqeq29db3-7301-4443-8917-a3b6e7857dd1) has finished an on-demand request. 1002 out of 1002 mailboxes were successfully processed. 0 mailboxes were skipped due to errors.

I can now open up Outlook for the user we applied the policy to and see that the Project XYZ managed folder has been created and listed under Managed Folders.  Remember, this is the folder that our user can now drag emails into for compliance or archive reasons.

Now that we have successfully created and deployed our Managed Folder Project XYZ we will continue our journey in Part 2 where we will mail enable a SharePoint Document Library providing it with an SMTP address and creating a Managed Content Setting that will be applied to our manage custom folder “Project XYZ”.  This will enable us to control the lifespan of items that are moved into our Project  XYZ Managed Folder that we have created and to also enable journaling on that folder to forward a copy to an alternative address, in our case the SharePoint Document Library SMTP address for archive.

If you would like to notified of future articles via email click here or subscribe via RSS.

We all know from experience that advising end users to browse  to https://mail.yourdomain.com/OWA if you are running Exchange 2007 or /exchange if you are running Exchange 2003 is usually problematic .  Oh! and did I forget to mention that it’s HTTPS and not http!  We must admit that not all end users are likely going to remember this URL and at times even struggle to distinguish the difference between secure and non secure sites.  Well if you are running ISA 2006 as an edge or secondary application layer firewall then we can easily simplify the URL that we will publish to our end users by creating a deny rule which will then automatically redirect them to the correct address.  By the end of this post,  your end users will only need to remember a simple URL in the form of  mail.yourdomain.com (notice that http or https is not required). This post is assuming that you already have an existing Exchange Publishing Rule in ISA 2006.  Note, that this technique can also be used for other websites that ISA may already be protecting such as SharePoint and Terminal Server Web Access.

Let’s begin by launching the ISA Management Console, and navigate to create a new web site publishing rule.  The New Access Rule Wizard will launch in which you will begin by specifying a name for your rule.

Select Deny as your Rule Action

Select Publish a single web site or load balancer.

Select Use SSL to connect to the published Web server or server farm.

Enter your Internal Publishing Details which should be identical to the original Exchange Publishing rule.

Click Next and then Next again skipping the Path details.

Enter the Public Name details as per your original Exchange Publishing rule.

Select the existing Exchange Web listener that you already have created for your Exchange Publishing Rule.

Select, No delegation, and client cannot authenticate directly.

Remove Authenticated Users if present and select All Users instead.

You will then receive the below warning as we have selected All Users.  Ignore this warning and click on OK to continue.

Now that the rule has been created, we need to specify the redirect page.  Right Click on the newly created rule and select properties.  Navigate to the Action tab and click on the check box beside “Redirect HTTP requests to this Web page:” and enter the full Outlook Web Access URL.

We are now complete.  You will need to ensure that the deny rule is place immediately below the original Exchange Publishing Rule as per the below screen shot.  When a user now enters the url mail.yourdomain.com it will hit the redirection rule that we have just created which will then redirect to https://mail.yourdomain.com/owa and authenticate against your original Exchange OWA rule.

In summary we have removed the all so common confusion that end users may encounter when browsing to the Outlook Web Access site.  This methodology provided above with the deny rule can also be used against any other web site publishing rule including SharePoint Sites and Terminal Server Web Access.

I came across a minor situation today when setting up a forwarding rule against an Exchange Public folder.  Having done this many times in the past, I knew I would get this accomplished in a matter of minutes.  So I began by creating the Public Folder, mail enabling it and then when into the properties of the public folder itself to create a rule which would forward the items as they arrive to multiple recipients both internal and external to the organisation.

The forwarding was behaving as expected for internal recipients but none of the external recipients were receiving the emails that were being auto forwarded.  Scratching my head, I delved straight into the Exchange Management Console, and launched the Exchange Message Tracking toolbox which showed zero results for emails sent to those external recipients.  Scratching my head again, this time for a briefer moment, it clicked to me that this is the first time I had setup auto forwarding for external recipients and was aware of some settings under the Hub Transport Server (Organisation Configuration) that may prevent this.  Alas, by default Exchange 2007 prevents “Automatic Forward”, so I checked the box to allow, and the auto forward rule behaved expectedly for external recipients as well!