Today we continue down our journey in setting up our SharePoint 2010 farm, with the focus on configuring incoming email for SharePoint 2010.  When SharePoint 2007 was released, there was a lot of discussion and rumors around Exchange 2007 being the last version of Exchange to provide Public Folder support, and that SharePoint 2007 was going to be it’s alternative. Microsoft quickly changed its stance and continues to support Public folders in Exchange 2010.  However, there still might be a number of compelling reasons why you would want to consider storing incoming email messages in SharePoint 2010 document libraries, instead of public folders. 

In today’s post, I will provide you with a comprehensive step by step guide in configuring your SharePoint 2010 server in conjunction with Exchange 2010, to provide successful delivery of incoming email directly to your SharePoint Web Applications.

The SMTP service

SharePoint 2010 is reliant on the SMTP service which is a Windows 2008 feature and we must install this on our SharePoint 2010 front-end web server.

Navigate to your Start Menu / Administrative Tools / Server Manager.  Click on the Features node and select Add Feature.  Scroll down and select SMTP Server and click on Add Required Role Services.

Click Next, Next and Install.

Click Close

We now need to install the II 6.0 Management Tools on our Windows 2008 R2 server in order to configure our SMTP service.  If IIS 6.0 Manager is not already installed you must do so via, Start / Administrative Tools / Server Manager.  Click on the Roles node and select Role / Add Role Services.  Then select Management Tools and IIS 6 Management compatibility.  Click Install.

We can now launch the IIS 6 Manager via Start / Administrative Tools.

Right click on SMTP Virtual Server #1 and select properties.

Under the General tab, I have enabled logging and encourage doing so at the start in the event we need to do some troubleshooting.  You can turn logging off after successful testing.

Click on the next tab, “Access”.

Click on “Authentication” and ensure that Anonymous access is selected.

Next, click on “Connection” and ensure “All except the list below” is selected.

Finally, click on “Relay”, and ensure that “Only the list below” is selected and that “Allow all computers which successfully authenticate to relay, regardless of the list above” is also checked.

Now click on the Messages Tab and make any necessary adjustments that you see fit, such as potentially increasing the message size to allow for the delivery of larger emails with attachments into your SharePoint Libraries and Lists.

Next click on the Delivery Tab in which I normally leave all the defaults in place.

We can skip the LDAP routing tab as there are no settings required to be configured in this area.

Lastly, the Security tab should list the default permissions as per the below.  No changes are necessary in this area.

We next journey into the “Domains” are within IIS 6 Manager and a domain name should be listed, which by default is the fully qualified domain name of the machine.

Right click on the Domain Name and select properties and take note of the Drop directory.

Finally, we now just need to confirm that our SMTP service is set to start automatically in the event the server is restarted.  I can tell you now that the service is by default set to Manual.

Venture into Start / Administrative Tools / Services.

Scroll down your list of services and ensure that the Simple Mail Transfer Protocol (SMTP) is set to Start-up type, Automatic.

We have now completed the configuration of our SMTP service on our SharePoint Server.

Exchange 2007/2010 Connectors

Part two of the implementation of configuring incoming email in SharePoint is to configure our connectors in Microsoft Exchange.  Now even though this is not a requirement, most organisations running SharePoint 2010 or 2007 will also be running a recent version of Microsoft Exchange, hopefully either 2007 or 2010.  Exchange 2010 or 2007 will provide you with that extra layer of protection ensuring that all the necessary message hygiene has been performed via its inbuilt Anti Spam Agents on the Edge or Hub Transport Server in conjunction with some form of email antivirus such as Microsoft’s Forefront for Exchange, before the message is delivered to the SharePoint 2010 List or Library.

My instructions and screen captures below are from an Exchange 2010 server which are pretty much identical and applicable to Exchange 2007.

Let’s begin by launching the Exchange Management Console / Organization Configuration / Hub Transport.

Click on Send Connectors / Actions / New Send Connector.

Type in a descriptive name for your Send Connector and then select Internal as the type.

Click Add and enter the Address space as the fully qualified domain name of the server where the SMTP service is installed (i.e. your SharePoint Server)

Click Next

Enter the IP address of the server which also hosts the SMTP service.

Click Next

Select “None” as your smart host authentication settings

Click Next

Ensure your Hub Transport Server has been added.

Click Next

Click New and then click Finish

The end result will be that the Send connector will route email to the SMTP service sitting on our SharePoint Server.

The Directory Management Service

SharePoint 2010 allows you to leverage Active Directory Domain Services (AD DS) so that contacts that are created when you email enable document libraries or lists are stored in a designated Organizational Unit within your AD DS infrastructure.  So why would you want to enable Directory Management Service?  Purely for the fact that by storing these contacts in AD, you are allowing your users to locate email enabled libraries and lists easily from within their Outlook Address book.

Let’s begin by creating an Organizational Unit in Active Directory.

From your Active Directory server, click Start / Administrative Tools / Active Directory Users and Computers.

Right click on your domain object and select New / Organizational Unit

Type in a descriptive name

Click Ok.

The next step is imperative and very important that we get this right.  I have seen on many occasions where incorrect permissions were applied and all sorts of problems were encountered when libraries or list were email enabled.

In summary, we need to provide our Central Administration Application pool identity account specific permissions to our recently created Organizational Unit to be used for creating and deleting contacts for our SharePoint 2010 libraries and lists when they are either email enabled or email disabled.

Right click on the recently created Organizational Unit and click on Delegate Control.  This will invoke the Delegation of Control Wizard.

Click Next.

We will now add the Central Administration application pool account which you can confirm from IIS Manager as per the below screen capture.

Add the necessary Account.

Click Next.

Click Create a custom task to delegate.

Click Next

Click “This folder, existing objects in this folder, and creation of new objects in this folder’.

Click Next

Click on Create All Child Objects and Delete All Child Objects.

Click Finish.

Before we finish off our configuration of AD DS and the Directory Management Service we need to provide our Central Administration application pool account with Delete Subtree permissions.

We need to ensure that “Advanced Features” from within Active Directory Users and Computers (ADUC) is active before we venture into the security tab of our SharePoint organizational unit.  If you do not enable Advanced Features, the security tab will not be visible.

From within ADUC, click on View and select Advanced Features.

Right click on our SharePoint 2010 Organizational Unit and select Properties.

Click on the Security Tab / Advanced /and Edit the CA Application Pool Identity Account.

Select Allow for “Delete Subtree”

Click on OK and Apply.

After assigning these permissions, you must run IISRESET on your SharePoint server.

Configuring Incoming e-mail settings in Central Administration

Navigate to Central Administration / System Settings / Configure incoming e-mail settings.

Select Yes to “Enable site on this server to receive e-mail”

Select “Automatic” for Setting mode.

Select “Yes” to use the SharePoint Directory Management Service to create distributions groups and contacts.

Enter your Active Directory container details, i.e. the Organizational Unit container that we created specifically for our SharePoint 2010 contacts.

Ensure that your SMTP server details are correct, this should be the fully qualified domain name of your SMTP service that was installed on your SharePoint Server.

Finally, ensure “Accept mail from all e-mail servers” is selected.

Click OK.

Please note that this process will configure the necessary permissions on the email drop folder listed in IIS 6 Manager.  In summary, the following permissions are added;

WSS_Admin_WPG – Full Control and

WSS_WPG – Read & Execute / List folder Contents / Read

Ensure that these accounts are added successfully and on the rare occasion in which it isn’t, you will need to add them manually.

Testing the configuration

From within any document library or list, click on Library / Library Settings.

Click on Incoming e-mail settings.

Select “Yes” to allow this document library to receive e-mail.

Select your email attachment options and ensure that Save original e-mail is set to Yes.

Lastly, ensure that you Accept e-mail messages from any sender is selected.

Click OK.

This is your first step to ensure that all of the above configuration is in place.  If you do receive an error, it’s most likely going to be permissions related against your Organizational Unit, i.e. SharePoint may not have the privilege to add the contact in Active Directory.

Let’s navigate back to ADUC and confirm that our “testing” contact is created under the SharePoint 2010 Contacts Organizational Unit.

Let’s next navigate to our Exchange 2010 server and ensure it is also listed there with an SMTP address against it.

Launch your Microsoft Exchange Management console and navigate to Recipient Configuration / Mail contact.

Right click on the Contact and select Properties / E-Mail Addresses.

Ensure that both an internal and external routable email address is listed.

From your favorite email client, send a test email to the document libraries’ external SMTP address.

Navigate to your recently email enabled document library and hopefully after a couple of minutes (SharePoint Job timer service delay) you should have received your test email.

Well! That’s all that is to it, from start to finish.  Apart from sending a test email, there are a couple of other scenarios that you should test to ensure complete seamless integration with the SharePoint 2010 Directory Management Service.  Within the same document library, modify the email address to something different and ensure that this change also flows through to Active Directory. You should also try disabling incoming email from that same library and ensure that the contact is completely removed from Active Directory.  If you pass all of these tests scenarios, then we are comfortable in knowing that the correct delegation was provided to our Central Administration Pool Account against our SharePoint Contacts Organizational Unit.

Since damage modeling was announced by Polyphony Digital earlier in the year, it has been under close examination. Gran Turismo 5 is the first in the series to incorporate damage on its precious cars, and its absence has been one of the only major weaknesses noticed by many fans. Now that the game is finally out, online forums and websites have been flooded with players wondering why the damage effects in the game are so underwhelming, and the answer to those concerns is fortunately simple.

In Gran Turismo 5‘s GT Mode, damage isn’t unlocked until the racer reaches level 20. Better yet, several hours later at level 40, the full-feature damage, including mechanical as well as major structural damage, is unlocked. My experience with both so far has been nothing short of impressive. Unlike a few racing games I have played in the last few years, the cars don’t just crumple like paper. Instead, each portion of the car reacts differently, and the violent effects of impact are felt and seen therein.

Below I submit to you Exhibit A. Notice the realistic physics on impact in conjunction with significant physical damage.

When you reboot an SBS 2008 server, you may experience some of the following symptoms:

• The SBS server will be unable to browse to the Internet.
• Users will not be able to connect remotely to the SBS server using utilities such as remote web workplace or Outlook web access.
• Client PCs that rely solely on the SBS server for DNS may not be able to browse the Internet.

If you run ipconfig on the SBS 2008 server you will notice that the default gateway is blank.

If you manually assign the default gateway the connectivity will be restored until you reboot the server. After you reboot the server, the default gateway may again be lost.

This issue occurs because of a problem with the netsh utility in Windows Server 2008. The issue is documented in knowledge base article 973243: The default gateway is missing on a computer that is running Windows Server 2008 or Windows Vista after the computer restarts if the default gateway is set by using the Netsh command

In certain conditions, the netsh command improperly adds a Unicode Null character before the real value for the default gateway in the registry. Note: The Small Business Server Connect to the Internet Wizard uses the netsh command to set the default gateway on the server.

Use the following steps to resolve this problem.

1. Go into the TCP/IP properties of the network card and enter in the proper default gateway.
   
2. Download and install the hotfix associated with article 973243. This fix will prevent the netsh command from adding the Null value in the future.
3. Manually edit the affected registry key to remove the improper value set by the netsh command.
   1. Run regedit.exe
   2. Navigate to
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Para
      meters\Interfaces\\DefaultGateway
      Where is the interface value for the network card.
   3. Double click the value for DefaultGateway
   4. Remove any blank lines in the value.

   Here is an example of an incorrect registry value:

   

   After you remove the blank line, the registry value should look like:

   

   If you receive the following warning while saving the registry value, simply click OK

   

4. Once the update is installed and the registry change has been made, you must reboot the server.

Part I of this article series explained how email coexistence with BPOS and your local on-premise exchange system works. We also walked through the first steps to configure this.

Moving Microsoft to the Cloud with BPOS

To recap, configuring email coexistence with BPOS requires the following steps:

1. Add your own domain to BPOS and enable external relay (Covered in Part I)
2. Verify the domain (Covered in Part I)
3. Verify email traffic flow
4. Enable Active Directory Synchronization
5. Activate migrated users
6. Migrate mailboxes to BPOS
7. Optional steps: Configure SPF and secure the mail flow

This 2nd instalment covers steps 3 and 4:

• Verify email traffic flow
• Enable Active-Directory Synchronization

Step 3: Verify Email Traffic Flow

This step may seem out of order, but it’s actually very important. Before configuring Active-Directory sync, it’s crucial to verify that the two SMTP domains used for coexistence can successfully communicate.

As explained in part I of this article series, BPOS makes it look as if all users are using the same SMTP domain, whether using BPOS or your on-premise Exchange. However, behind the scenes it uses two different domains, and some tricky forwarding techniques. So, it’s important to verify that the two domains can talk to each other.

For this example we’ll continue to use the sample domain bpostutorials.com, and the BPOS domain bpostutorial.microsoftonline.com.

To verify email flow:

1. In your BPOS environment, create a test user with a mailbox in the microsoftonline.com domain. For example, UserOne@bpostutorial.microsoftonline.com
2. Create a test user in your on-premise Exchange environment. For example, UserTwo@bpostutorials.com
3. Log on to the BPOS Outlook Web Access as UserOne@bpostutorial.microsoftonline.com
4. Send an email message to UserTwo@bpostutorials.com
5. Verify that UserTwo received the message, and reply back to the email.
6. From OWA, confirm that UserOne received the reply.

Troubleshooting:

If messaging doesn’t work, check to confirm that the microsoftonline.com domain has been added to your safe-senders list in Exchange. It may also be worth confirming that any 3^rd party Spam filters aren’t rejecting the messages, and that your MX records are configured correctly to point at your on-premise Exchange.

Don’t move on until you’ve confirmed that basic mail-flow works as expected. Email coexistence won’t work if you can’t email between the two domains.

Step 4: Enable Active-Directory Synchronization

Active-Directory synchronization does exactly what you might expect. It copies your local active-directory user information over to BPOS.  This simplifies user administration, since BPOS automatically has a list of all users.  It also makes your full Global Address List available to all users, whether they are on BPOS or on-premise Exchange. Synchronization is performed using a tool called the “Active-Directory Synchronization Tool”, or Dirsync for short.

Dirsync will copy AD user information over to BPOS, with the exception of passwords. It will perform an initial sync, then re-sync every 3 hours. After running Dirsync, it’s important to make all user changes in your local AD, not on the Microsoft Online environment.

Before beginning, there are a few prerequisites.

• Dirsync cannot be installed on a domain controller. It must be installed on a member-server joined to the same AD forest that you plan to sync with BPOS.
• It cannot run on a 64-bit system, it must be installed on a 32-bit, Microsoft Windows Server 2003 SP2 or newer OS.
• The .NET framework 2.0 or greater must be installed on the computer that will run Dirsync
• Powershell must be installed
• Enterprise Administrator credentials for your AD will be required
• BPOS Administrator credentials will be required

To install Dirsync:

From the machine that you plan to install Dirsync on, open up the BPOS admin console, and go to the Migration tab.

In the “Directory Synchronization” section click on Configure.

The window that opens provides a series of steps.

Read the planning document under Step 1 and check the box.

Next, under Step 2, click the button to Enable Directory Synchronization.

Now, under Step 3, click the download button which will take you to the download page for Dirsync.

Download and run the Dirsync setup file. Go ahead and install it using all default options.

Ensure that the option to “Start Configuration Wizard now” is selected, then click Finish.

Enter your BPOS administrator’s credentials when prompted:

And next enter your Active-Directory Enterprise administrator credentials:

We want synchronization to start immediately, so leave the checkbox labelled “Synchronize directories now” selected, and click Finish

Verify Synchronization

There are a couple of ways to verify that synchronization is working correctly.

First, open up the Event Log on the server running Dirsync.  Check the Application Log for events with a source of “Directory Synchronization” and Event ID 4. Events logged with ID 4 indicate that synchronization completed successfully.

Next, we can verify that users and groups were copied to BPOS. Dirsync copies all accounts over and automatically disables them in BPOS by default, so you’ll need to view “Disabled User Accounts” in BPOS to find the synchronized accounts.

To do this, log in to the BPOS admin center. Go to the Users tab, and click on the User List sub-tab.  Select “Disabled User Accounts” from the right-hand navigation pane. You should see a list of user accounts that were synchronized from your own Active-Directory.

If you can see user accounts from your domain, then congratulations! Directory synchronization is working correctly. For now, leave the accounts disabled. You should only activate accounts when you’re ready to complete the user migration process.

We’ll cover the final steps required to configure email coexistence in Part 3 of this series.  In Part 3 we’ll use the BPOS migration tool to copy mailbox data to BPOS, and configure the forwarding information that makes co-existence possible.

Microsoft’s cloud service, the Business Productivity Online Standard (BPOS) Suite is designed to integrate with your existing on-premise Exchange system. BPOS can host your mail domains in parallel with your own servers.  It also can sync with your own Active-Directory, making it simple to migrate users to BPOS.

This is the first article of a three-part series. In this article, we’ll look at how Exchange coexistence with the cloud works, and start working through the technical steps to make this happen.

Moving Microsoft to the Cloud with BPOS

What is Email Coexistence?

First a definition: email coexistence refers to keeping some of your users on your own on-premise Exchange servers, and migrating other users over to BPOS – but you want all users to have the same SMTP domain. So in the example scenario in this article, all users keep the same user@bpostutorials.com addresses.

In our example, some users would use Exchange the traditional way – with a mail client like Outlook pointed at in-house mail servers.  However, some users have been migrated over to BPOS, and their mail client is pointed to cloud servers.  But all users have email addresses in the same domain, and all of them show up in the same Global Address List (GAL), making corporate-wide communication easy.

Email coexistence is a great solution, but it is not perfect. There are a few things you should be aware of:

• This is an either/or scenario – users can’t maintain a mailbox on both systems. Old mailboxes on the on-premise Exchange should be removed as quickly as possible.
• Free/busy data does not get exchanged between the two systems, so on-premise users can’t see free/busy data for BPOS users. For this reason, it may make the most sense to migrate entire workgroups to BPOS rather than just a few users.
• One other feature that doesn’t work between the two environments is mailbox delegation – another reason to migrate entire workgroups at once.

How Email Coexistence Works

Before we start configuring email coexistence, a high-level overview of mail traffic flow is important. With coexistence, mail is routed as follows:

• First, all incoming mail for our example domain, bpostutorials.com, continues to go to an on-premise Exchange system.
• Second, the on-premise Exchange server receives the mail. The local Active-Directory syncs with BPOS, and a migration tool tells Exchange if the mail recipient is local, or has been activated in BPOS. Then, depending on the setting for each user, the Exchange server either delivers mail locally or forwards it over to BPOS.
• Finally, BPOS receives the forwarded mail, and delivers it to users’ mailboxes.

The Trickery

Behind the scenes, this all works via some clever user trickery. The secret? The BPOS mailboxes don’t actually use your domain as its SMTP domain. BPOS actually uses a microsoftonline.com domain – such as bpostutorials.microsoftonline.com.

So, mail is simply being forwarded back and forth between two domains: bpostutorials.com, and bpostutorial.microsoftonline.com.

However, the system tricks users by displaying their login, mailbox, and sent mail as being part of the bpostutorials domain – hiding the long microsoftonline.com domain and saving users the agony of changing email addresses.

Step-by-Step: How to Configure Email Coexistence

Now that you understand the basic mail traffic flow, configuring mail coexistence takes a few simple steps.

1.       Add your own domain to BPOS and enable external relay

2.       Verify the domain

3.       Verify email traffic flow

4.       Enable Active Directory synchronization

5.       Activate migrated users

6.       Migrate mailboxes to BPOS

7.       Optional steps: Configure SPF and secure the mail flow

Let’s go through each of these steps in detail. We’ll cover steps one and two in this article, and finish off the process in our next articles in the series.

Step 1: Add Your Own Domain to BPOS and Enable External Relay

Open up the BPOS Admin site.  Click on the Users tab, then the Domain menu item. Then, click the “New” link in the upper-right corner.

Enter your Domain name in the new window that opens up – in my example I’ve used bpostutorials.com. And, since we’re setting up email coexistence in this article, click the option for “External Relay.”

(For a step-by-step guide to use BPOS as your primary mail system instead of email coexistence mode, check out our article on using your own custom domains with BPOS.)

Click “Create” and a window like the one below will be displayed. Select the box to “Start the Verification Wizard” if you’re ready to go to the next step, and verify the domain now.

Step 2: Verify Your Domain

Verifying a domain is accomplished by creating a DNS entry called a CNAME, or Alias. Your DNS records are generally hosted by your domain registrar, though in some cases your DNS may be hosted elsewhere.

First we need Microsoft to tell us how to configure the CNAME. If you didn’t select the option to start the Verification wizard in the previous step, then go back to the Users tab, and click on the Domains menu item.  The newly added domain will now appear in the domains list. Click the “Verify Now” link.

Select your registrar from the drop-down if available, otherwise select “Other” and click “Next“.

On the next screen you’ll be provided with DNS settings that you’ll need to configure with your domain registrar. Don’t use the ones in the screenshot here, they will all be unique. Make a note of the Host name, and “Points To” information.

Keep this window open. Now, fire up a new browser window and log in to your domain registrar’s admin site.  The example below was created using Go Daddy, but most registrars will have a similar tool. Microsoft has also compiled a detailed list of instructions for popular registrars.

Open up your registrar’s DNS tool and add a CNAME record. For example, with Go Daddy I would click the “Add New CNAME Record” button on the right-hand side of the screen.

Enter the Alias information that BPOS gave you. Note that you usually don’t have to fully qualify an Alias (i.e. the full domain name isn’t required, just the host name).

Success! Keep your registrar’s admin site open, because you’ll need it again in a minute.

Flip back to your BPOS window (you left that open right?) and click the “Verify” button. If you did it right, then you should see a message like the one below. If it was unsuccessful then go back and confirm that you typed in the alias properly. Some registrars could take anywhere from 15 minutes to a 72 hours to activate the new records.

If it’s not working, try doing a DNS lookup from another system to confirm that the alias is configured properly. BPOS won’t verify the domain until it can resolve the new alias you created to the server name it provided you in the previous steps.

Verify that you’ve configured everything correctly so far by going back to the Domains window. You should see your domain listed with a Status of “Verified”, Inbound messaging “Disabled”, and a Type that shows “External Relay”.

Once you’ve added and verified your domain, you’ll be ready for part II of this series. In part II we’ll synchronize Active-Directory with BPOS. In part III, we’ll cover the final pieces of the puzzle: activating and migrating users.

HP has developed the HP Sizer for Microsoft Exchange Server 2010 to assist you with proper server and storage sizing for Exchange Server 2010 deployments. It follows the success of the “HP Sizer for Exchange Server 2007”.

The algorithms developed and implemented in this tool showcase HP’s deep expertise with Exchange across the infrastructure; and are based upon extensive lab testing.

Based on your input, the tool provides a comprehensive bill of materials along with a deployment overview of the Exchange Server 2010 server roles and storage configurations. Once this Sizer is installed, updates can be downloaded automatically to the underlying software engines that are necessary to provide support for HP server and storage product information details.

You’ll find support for HP tower, rack mounted, or HP BladeSystem server platforms, as well as direct attached or SAN-based storage solutions. Additionally there are options for showing multiple site deployments, varied client types and access methods, all Exchange Server 2010 server roles, and Database Availability Group (DAG) high availability options.

Download this free tool now!

Active Directory elements

When designing an Active Directory, you need to be completely clear of what each element or part actually means and how it fits into the overall design. The old saying goes: You can’t see the forest because of the trees, and you can apply this to Active Directory as well. It is all about trees and forests and leaves and branches.

The Active Directory forest

The forest, in terms of Active Directory, basically means every domain, organizational unit, and any other object stored within its database. The forest is the absolute top level of your Active Directory infrastructure. Of course, you can have more than one forest in a company, which actually represent security boundaries, and can therefore improve security between different business units or companies belonging to a single organization. The point behind the forest is that you have all your domains and domain tree within your organization contained within it. It is designed so that you can have transitive trust-links between all of the trees within one forest.

To read more about the technical layout of AD, please read Domains and Forests Technical Reference at: http://technet2.microsoft.com/windowsserver/en/library/16a2bdb3-d0a3-4435-95fd-50116e300c571033.mspx.

To visualize a forest with its parts, please see the following image.

The Active Directory tree

A tree in Active Directory refers to a domain and all of its objects that adhere to a single DNS name. For example, a tree of nailcorp.com would contain all other domains that end with “nailcorp.com”. So, americas.nailcorp.com, europe.nailcorp.com, and asia.nailcorp.com all belong to the Active Directory tree of nailcorp.com. You cannot separate these unless you create a whole new forest for a sub-domain.

Organisational Units and Leaf Objects

In Active Directory, Organizational Units (OU), which are also called Containers, and Leaf Objects, which are non-containing objects such as computer accounts and user accounts, are directly related and even though you could have objects that do not belong to an OU, it isn’t recommended and isn’t really feasible.

Organizational Units are comparable to folders in a filing cabinet, and objects are the files. You can move files between different folders, and classifications or properties are applied to the files within a folder. For example, if you move a file into a folder classified “Top Secret”, the file will automatically fall under that classification. The same applies to objects within an OU, all properties or rules that apply to the OU apply to the objects within it. OUs, however, are mostly useful from an administrative point of view, not from an user’s point of view. If you think of how your files are organized, for example, on your computer, they are most likely to be organized into different folders. You can go ahead and set different folder settings, such as permissions, and it will affect all of the files within that folder, but anything outside that folder won’t have its permission affected. It is exactly the same principle with OUs. Any OU that will be created within an OU will contain all of the policy settings of the parent unless you change them. An object can also only belong to a single OU, just as a single file can only be contained within a single folder.

Leaf objects in Active Directory can be users, contacts, and computers. Or in short, any object that cannot contain other objects. They are called leaf objects because they are like leaves on a tree. And, as you can guess, they are the “lowest” class of objects within Active Directory. But if you now look at the forest-tree-branch-leaf concept, it is starting to make sense.

You can access the OUs and other objects through the Microsoft Management Console (MMC) or through the Users and Computers tool in the Administrative Tools. This second option actually just invokes the MMC with the correct view and is a lot quicker, as seen in the following screenshot:

Active Directory Sites

The Sites and Services MMC snap-in is a utility that a lot of Windows administrators, particularly in smaller organizations, completely overlook. This part of Active Directory, however, is one of the most crucial parts to understand and implement correctly.

If you have several locations in your organisation, you need to know about Active Directory Sites. Sites give you a very unique and well-designed approach to separate specific locations within your Active Directory. As the principle of an Active Directory domain is global-meaning that it is meant to be the same anywhere-it could present a problem for users who move from office to office, or for offices with network connections that are slow. Active Directory sites allow you to specify the IP address spaces or subnets used within your organisation and, therefore, bring the structure of your network into Active Directory. The usefulness of having properly organised and maintained Sites becomes more evident when you consider that any machine within an address space will use that Sites’ DC to authenticate. This is a great feature of AD and reduces unnecessary traffic. However, it requires having Sites and subnets properly updated and maintained. This is also particularly useful for defining different replication schedules for different locations within the same domain, and also to support users who travel. Once they log on through the other location, they are assigned an IP address from that network. The Windows locator service will then look up which DC is the nearest one, and the user won’t log on all the way to their usual DC (to read more about how the locator service works please refer to http://support.microsoft.com/kb/314861). This saves bandwidth and speeds up the authentication process.

Bandwidth nowadays is cheap, especially in developed countries such as the USA or most parts of Western Europe. But just because it is cheap in some parts, does not mean it is cheap in other parts of your organization. If you are primarily located within developed countries, but your then company decides to open 10 or 20 small sales offices within not-so-developed countries, where bandwidth is expensive, then you really need to start using AD sites. Of course, the problem then is that because you haven’t used AD sites before, you need to make the appropriate changes to your infrastructure to accommodate them, and train staff appropriately in order to be able to implement, support, and manage them.

In this example, the argument might be brought up that each of these small branch offices has a local DC that also functions as a File and Print server where the local employees collaborate. This is great, but what about replication to and from your Hub site? Which is the data centre that hosts a critical part of your Active Directory backend? If changes to your AD are fairly frequent, for example, adding and removing users on a regular basis, then the Active Directory will replicate—if the Site links are properly configured—without compression every 15 minutes. Of course, depending on the size of your organization, this can be quite a strain on the link you have from that office. If the people at that office receive email and browse the Web over the same link, network performance will degrade significantly for users and cause unnecessary inconvenience.

To see what Sites look like in the Active Directory Sites and Services console, see the following screenshot:

Group Policy Objects

Group Policy Objects in Active Directory are a set of defined rules for settings about the user environment or the operating environment for a particular PC. They are treated as standalone objects because they can be linked to different OUs. This gives you the flexibility of creating one set of rules and applying it to different OUs in different OU structures, making settings deployment much easier and administratively quick.

The policy settings are quite extensive and if you want to get your hands dirty, you can create your own policy templates, giving you even more control over the machines and application settings located in your domain.

There are templates available for many settings, ready to use. The templates for these settings are called ADM templates and there are quite a few already included in the Windows 2003 installation. Some applications, such as Microsoft Office 2007, also provide ADM templates that can be loaded and modified (see http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=92d8519a-e143-4aee-8f7a-e4bbaeba13e7 for Office 2007 ADM templates). Using ADM templates, you do not need to write anything by yourself, and so it is a quicker way apply to GPO settings. The following screenshot shows Office 2007 ADM templates loaded in the Group Policy Editor.

Domain Design: Single Forest, Single Domain, and Star Shaped

A domain is not a security boundary within a forest. By default, all domains have transitive trust relationships within a forest and are therefore visible to each other. On top of that, all Global Catalogs contain the Security database and a rogue administrator can potentially gain access to different domains or even the entire forest. Please see http://www.microsoft.com/technet/security/bulletin/MS02-001.mspx for more details on such vulnerability. Even though this particular vulnerability no longer exists within Windows 2003, something causing similar effects can be a possibility.

This is the most common design version for small-and medium-size businesses, that have offices within one country or that are geographically close. It involves a single hub site and several small sites. A hub site is defined as a big data center where the majority of your infrastructure is housed. So if you have the headquarters and development for nailcorp.com taking place in Los Angeles where 40 servers are housed in a datacenter and 900 people work, then that would be a hub site. In short, a hub site is a location where a large part of your crucial infrastructure operates.

From the hub site, all changes are replicated out to smaller sites, which can be small branch offices, small development locations, or pretty much any office that warrants its own domain controller. This puts control firmly into the one major hub site and all the branch sites just replicate with that. The advantage of this set-up is that you can push out a forced replication to all branch sites at once (provided your bandwidth supports this) and do not have to wait for any delayed replication schedules due to time zones and so on. The drawback is that if you do have a problem, due to human error, for example, and this gets replicated, everyone gets it at once. If, for example, an administrator at NailCorp deletes or renames by accident a service account that is used by a certain service throughout the organization, and he does not notice it, then after the next replication the service stops working. If the replication was star shaped and went to everywhere at the same time, the service stops everywhere at the same time. If the service is something that does not get recognized immediately, such as an antivirus policy update or some automatic update service from a third-party application, this failure will not get noticed immediately and the service will stop and won’t restart because it will be a logon failure. In this scenario, NailCorp could go on for days without anyone noticing.

As you can see in the following figure, in this design NailCorp would have a single hub site and three branch sites. Each site would have its own IP address range and would have, within Active Directory, its own site with DCs located inside it.

In this case, we only have a single forest and a single domain with different sites, but even in these sites all objects belong to the same forest and hence the same domain.

Domain Design: Single Forest, Single Domain, Empty Root, Star Shaped

Even though this architecture is no longer recommended, there are still quite a lot of companies that either use it or implement it. This is almost the same design as the previous one, except that it includes an empty root domain. Basically, it implies that the root of your forest is empty, meaning that there will be no computer accounts and no user accounts other than the Enterprise Administrators located in this domain. Within AD, a domain is not a security boundary. A forest, however is, so a multi-forest architecture would provide more security. An empty root domain has good and not-so-good points. The point is that this is a fairly safe design, which still adds layers of security. The other domain under the root domain – the child domain-will contain all of the user and computer accounts. This setup is beneficial from a security perspective in that the Enterprise and Schema Administrators groups are isolated from the other users and administrators. With this design, a few administrators can be selected to control the Enterprise and Schema Administrator groups, and all the other administrators reside in the child domains, configured to be Domain Administrators.

This will add a proper layer of security to the whole structure and will allow an easier structural change, should:

• New companies be acquired and need transitional access, or
• A separate AD be required for special access etc.

There has been some controversy about the necessity of an empty root domain. When Windows 2000 came out, the empty root was all the rage and everyone was doing it.

Domain Design: Multi-Domain Forest

This design is used a lot in larger corporations and companies that do a lot of Quality Assurance testing for software, or software development. It has a forest and multiple trees under this. This is also very good if your company has expanded a lot through acquisitions and you need to ensure that the acquired companies can access cross-domain files.

This design approach needs to be designed from the beginning because you cannot create a new forest on top of an existing one. Windows 2003, however, makes moving domain information and migrating between two Active Directories easier, with the tools that it provides.

Domain Design: Multi-Forest

This design, while administratively more complex, provides the best security. It also raises support costs and makes collaboration a little more difficult, but it definitely has its benefits. This design will have standalone forests for all of the business units or departments. This also means that by default they cannot see or access each other. Administrators then create trust relationships between the different domains that are within the forests. This will give the granularity needed. To visually understand this, please see the following image:

LRS—Lag Replication Site

These sites are also often called RLS (Replication Lag Site), DRS (Delayed Replication Site), and just plain lag site. Officially, there really isn’t a “correct” name as Microsoft and AD experts have referred to this concept in all four ways.

A lag site is a site in your AD that will contain at least one DC. This site is configured so that the replication only happens at a delayed schedule compared to all the other sites. This can be anything from one day to one week.

The purpose of lag sites is primarily to restore deleted objects quickly without having to go through the process of authoritative restores or even start working with tapes. If something gets inadvertently deleted, all that is needed is a replication in the opposite direction, from the lag site to the production DCs, and the deleted data is recovered. It is a clean, fast, and efficient way to recovery.

The other feature that is a natural by-product of a lag site, and used by quite a few organizations, is that in case of a disaster, it becomes easier, cleaner, and faster to recover a part of or your complete infrastructure. As lag sites are not used for authentication by users and DNS registration is disabled, they are considered stealth sites because they are not usable by any service or user.

Active Directory, as we have established, is a very complex infrastructure. There are a multitude of things that can go wrong at any given time, and human error, while the most common cause, is also the worst of the things that can happen if the changes are replicated out. Best practices generally include separating one or even two domain controllers per domain in your datacenter or somewhere else. (Create it in a new site in your Active Directory and make the link cost the highest possible. That means that it will only replicate the data with the main Active Directory once a week and the rest of the time just sit there. You can even design it so that there is no active replication going on by putting a firewall in front of the site and denying the traffic.)

Of course, you will get replication errors, but at least you have a working Active Directory in any event. If your infrastructure fails, all you need to do is complete an authoritative restore from the lag site, and activate the network link, meaning dropping the firewall if you have one, and promote or seize the roles of the domain controllers in the lag site. You will generally have a working infrastructure and since the lag site has an authoritative restore, all other DCs will replicate from it.

There are different approaches to lag sites. If you want to keep your Active Directory even more redundant and safer, you should definitely consider establishing a lag site.

The Microsoft Online Services Directory Synchronisation tool provides one-way synchronisation from your local Active Directory directory service to Microsoft Online Services. Directory synchronization can also provide global address list synchronization between your local Microsoft Exchange Server environment and Microsoft Exchange Online.

Using Directory Synchronisation

If you plan to establish e-mail coexistence between your local Exchange Server environment and Exchange Online, you must establish e-mail coexistence before installing and configuring directory synchronisation.

When you first run the Directory Synchronisation tool, it will write a copy of each user account and mail-enabled contact and group to your organisation’s Microsoft Online Services directory.

When user accounts are first synchronised with your Microsoft Online Services company, they are marked as disabled. They cannot send or receive e-mail, and they do not consume licenses. When you are ready to assign Exchange Online mailboxes to specific users, you must select and activate these users.

While in e-mail coexistence, all edits of user accounts and mail-enabled contacts and groups must be performed in your local Active Directory. Directory synchronisation will update Microsoft Online Services with those changes every three hours, or you can manually force synchronisation at any time. For example, deleting a user account in your local Active Directory will delete that account in Microsoft Online Services.

Important 

Directory synchronisation is one way, from your local Active Directory environment to Microsoft Online Services. When synchronising Active Directory with Microsoft Online Services, it is important that you continue to create and edit all user accounts and e-mail enabled contacts and groups in your local Active Directory. Objects edited in the Microsoft Online Services Administration Center will be overwritten when the next synchronisation takes place.

Note 

Synchronised objects may take up to 24 hours to appear in the Offline Address Book (OAB) and Communicator.Objects that have been synchronized from your on-premises Active Directory directory service will appear immediately in your global address list (GAL), but it may take up to 24 hours before they appear in the OAB and in Microsoft Office Communicator.

Note 

When an account is migrated from your on-premises Active Directory, the account password is not migrated with the account. When the administrator activates the migrated account, a new password is assigned to that account.If the password associated with an on-premises Active Directory account is changed, that new password is not migrated. Users must change their Microsoft Online Services passwords manually.

Active Directory accounts are identified by a globally unique identifier (GUID) that is assigned to each account when it is created. If you delete an account and then create a new account with the same name, the new account will have a different GUID. Because the Directory Synchronization tool identifies the user accounts by their GUID, the Microsoft Online Services account associated with the deleted user account will be deleted during the next synchronization, and a new account will be created. The mailbox or other services associated with the deleted user account will also be deleted.If you accidentally delete a user in your local Active Directory, you should use the Active Directory tools to recover that user account. To prevent replication of the accidental deletion, disable directory synchronization in the Administration Center until you have recovered the deleted user account.

Install the Directory Synchronisation Tool

Before you install the Microsoft Online Services Directory Synchronisation tool, you’ll need:

• Enterprise administrator credentials: With the Directory Synchronization tool, you will need to use enterprise administrator credentials on the computer on which it will be installed in order to create a local account with synchronization permissions. For more information, see Directory Synchronization Tool Prerequisites.
• Windows Server 2003 SP2: The Directory Synchronization tool must be installed on a domain-joined computer that is running Windows Server 2003 with Service Pack 2 installed.

After you install the Directory Synchronization tool, you can upgrade the Directory Synchronization tool on the same computer or use a different computer. Using a different computer is recommended for customers who have an on-premise Active Directory with more than 50,000 objects to avoid missing deletions that occur on-premise while the upgrade is taking place.

There can be only one instance of the Directory Synchronization tool installed on your network. If you install the tool on a second computer that is networked with your first computer, synchronization will stop working on the first computer.

To install the Directory Synchronisation tool

1. Log on to the Microsoft Online Services Administration Center, click Migration, and then click Directory Synchronisation.

2. On the Directory Synchronisation page, complete steps 1 and 2.

3. Under step 3, click Download and follow the instructions to save the installation file on your computer. If necessary, copy the installation file to the computer on which it will be installed.

4. Run the installation file.

5. On the last page of the installation program, select Run Configuration Wizard now, and then complete the configuration process.

   Important 

   You must successfully complete the Directory Synchronization tool Configuration Wizard before synchronization will begin.

To upgrade the Directory Synchronisation tool

1. In the Microsoft Online Services Administration Center, on the Migration tab, click the Directory Synchronisation page. Click Download, and then follow the instructions to save the latest version of the Directory Synchronization tool installation file to the directory synchronization computer.

2. On the computer on which the Directory Synchronisation tool is installed, open the Control Panel, select Add and Remove Programs, and then uninstall the Directory Synchronisation tool.

   Note 

   If a synchronisation session is in progress, you will receive a warning when you try to remove the Directory Synchronisation tool. If you receive this warning, wait until synchronisation is complete and then repeat this step.

3. Run the latest version of the Directory Synchronisation tool installation file.

4. On the last page of the installation program, select Run Configuration Wizard now, and then complete the configuration process.

   Important 

   You must successfully complete the Directory Synchronisation tool Configuration Wizard before synchronisation will begin.

To update the Directory Synchronisation tool using a different computer

1. Log on to the current directory synchronisation computer, click Start, click Control Panel, open Administrative Tools, and then, in Services, stop the MSOL_AD_Sync service.

2. On a different computer, download and run the Directory Synchronisation tool installation file as usual, and then run the Configuration Wizard.

3. On the last page of the Configuration Wizard, select Start directory synchronisation now, and then click Finish.

   This will reset the synchronisation service password, break the synchronization relationship with the old computer, and establish a synchronisation relationship with the new computer.

4. When the Event Viewer on the new directory synchronisation computer shows that synchronisation is complete, log on to the old directory synchronisation computer, run the Configuration Wizard, and force a synchronisation.

   This will identify and synchronise any objects that were deleted while directory synchronisation was stopped.

5. On the new directory synchronisation computer, run the Configuration Wizard again, and force another synchronisation.

   This will reset the synchronisation service password and reestablish the synchronization relationship.

6. Uninstall the Directory Synchronisation tool from the old directory synchronisation computer.

Additional Information

Important 

Installing the Directory Synchronisation tool creates the MSOL_AD_SYNC account in the standard Users organizational unit (OU) of the local Active Directory. This account is used by Directory Synchronisation tool to read the local Active Directory information. Do not move or remove this account. Moving or removing this account will cause synchronisation failures.

Issue: Items deleted on local computer while tool is uninstalled aren’t deleted from Microsoft Online Services

If you uninstall and then reinstall the Directory Synchronisation tool on your local computer (or move the tool from one computer to another), items deleted on your computer during the time that the Directory Synchronisation tool is uninstalled will not be deleted from Microsoft Online Services. This issue occurs when you are using the Directory Synchronisation tool to provide one-way synchronization from your local Active Directory directory service to Microsoft Online Services.

Issue: Can’t uninstall Directory Synchronisation tool

When the Directory Synchronisation tool installation fails before the MIISAdmins group is created, the account that would be used to uninstall the Directory Synchronisation tool does not exist; hence, the Directory Synchronisation tool is not uninstalled.

To work around this, you need do the following:

1. Create a Local Machine Group called MIISAdmins.
2. Add yourself to the group.
3. Attempt to uninstall the Directory Synchronisation tool.

Enable Directory Synchronisation

Enabling directory synchronisation is one simple step in the process of implementing e-mail coexistence and directory synchronisation. It must be done before installing the Microsoft Online Services Directory Synchronisation tool.

Directory synchronisation is one way, from your local Active Directory environment to Microsoft Online Services. When synchronizing Active Directory with Microsoft Online Services, it is important that you continue to create and edit all user accounts and e-mail enabled contacts and groups in your local Active Directory. Objects edited in the Microsoft Online Services Administration Center will be overwritten when the next synchronization takes place. For more information about directory synchronization, see About Directory Synchronisation.

Note 

If you plan to establish e-mail coexistence, you must enable directory synchronization.

To enable directory synchronisation

1. Log on to the Administration Center, click Migration, and then click Directory Synchronisation.

2. In the Enable one-way synchronisation from your local Active Directory to Microsoft Online Services step, click Enable.

One of the first tasks for many admins switching to the Microsoft Business Productivity Online Services (BPOS) is to configure email messaging.  This can be accomplished a few different ways, depending on your migration strategy.

Grow Your Business with Microsoft Cloud Services

In this article we’ll walk through the simplest way of getting BPOS up-and-running: configuring BPOS as primary mail server for a domain without any data migration; and no Exchange co-existence.

When would this scenario be used? Most likely for one of these reasons:

• You are setting up a brand new domain with BPOS.
• You are running a trial evaluation of BPOS with a test domain before committing and migrating users.
• You’re switching to BPOS from another hosting provider, and have no (or little) mailbox data to migrate.
• You want to switch to BPOS, but only have a small number of mailboxes, so creating new mailboxes is low-effort.

High-Level Summary of the Steps

Setting up BPOS as your primary mail server is very easy.  There are only a few tasks involved, and we’ll walk through them step by step.

First, a couple of prerequisites.

If you haven’t already, sign up for a BPOS trial or pay account. I’m going to assume you can handle this one on your own.

Second, log in to the BPOS Admin site with the Administrator ID you just created. The link will be in the welcome email from Microsoft.

Third, you’ll need account login information for your domain registrar.  Setting up email involves creating a DNS record with your domain registrar or DNS hosting service.  So, get their login information handy and find their DNS management tool.  Some registrars require that you contact their support staff to make DNS changes, the good ones let you do it yourself. (Tip: Unsure who your registrar is? Here are some ways to find out.)

We’ll go into great detail below, but here’s a high-level summary of what you’re about to do, and why the steps are required. There are really only five main steps:

1. Add your custom domain(s) to BPOS. Microsoft creates a generic domain that you could use for messaging, but it’s pretty ugly. Something like “user@bpostutorial.microsoftonline.com”. In this example we’ll add a new domain called bpostutorials.com.
2. Verify your domain – a procedure to confirm that you own the domain you’re attempting to add to BPOS. This step involves creating a DNS record with your DNS host or domain registrar.
3. Create user accounts and mailboxes in BPOS.
4. Enable inbound messaging so that internet hosts send mail to BPOS instead of your old servers. This involves changing your DNS MX (Mail-Exchanger record) to point to Microsoft.
5. Test it out!

In Detail: How to set up Messaging and DNS

Step 1: Add Custom Domains to BPOS

Open up the BPOS Admin site.  You may have a helpful “Tasks I Need to Do” shortcut in the middle of your screen. If so, click “Add your domain to Microsoft Online Services”. If not, click on the Users tab, then the Domain menu item.

If you’re using the Users/Domains tab, click the “New” link in the upper-right corner.

A screen will pop-up, like the one below. Enter your Domain name in the box provided – in my example I’ve used bpostutorials.com.

The two options in the lower-half of the screen determine if BPOS will be the primary mail server, or if it will co-exist with an external Exchange system.  Since we want BPOS to be your primary mail server, choose the “Authoritative” option.

Click “Create” and a window like the one below will be displayed. Select the box to “Start the Verification Wizard” if you’re ready to go to the next step and Verify the domain now.

Step 2: Verify Your Domain

Verifying a domain is accomplished by creating a DNS entry called a CNAME, or Alias into your DNS records.  Your DNS records are generally hosted by your domain registrar, though in some cases your DNS may be hosted elsewhere.

First we need Microsoft to tell us how to configure the CNAME. If you didn’t select the option to start the Verification wizard in the previous step, then go back to the Users tab, and click on the Domains menu item.  The newly added domain will now appear in the domains list. Click the “Verify Now” link.

Select your registrar from the drop-down if available, otherwise select “Other” and click “Next“.

On the next screen you’ll be provided with DNS settings that you’ll need to configure with your domain registrar. Don’t use the ones in the screenshot here, they will all be unique. Make a note of the Host name, and “Points To” information.

Keep this window open. Now, fire up a new browser window and log in to your domain registrar’s admin site.  The example below was created using Go Daddy, but most registrars will have a similar tool. Microsoft has also compiled a detailed list of instructions for popular registrars.

Open up your registrar’s DNS tool and add a CNAME record. For example, with Go Daddy I would click the “Add New CNAME Record” button on the right-hand side of the screen.

Enter the Alias information that BPOS gave you. Note that you usually don’t have to fully qualify an Alias (i.e. the full domain name isn’t required, just the host name).

Success! Keep your registrar’s admin site open, because you’ll need it again in a minute.

Flip back to your BPOS window (you left that open right?) and click the “Verify” button. If you did it right, then you should see a message like the one below. If it was unsuccessful then go back and confirm that you typed in the alias properly. Some registrars may take a few moments to process the change, so you could also try doing a DNS lookup from another system to confirm that the alias is working. BPOS won’t verify the domain until it can resolve the new alias you created to the server name it provided you in the previous steps.

Step 3: Create Users

Without going into detail, this would be a good time to create some user mailboxes. In a moment you’ll tell the world to start sending mail to the new BPOS server for your domain. If you haven’t configured accounts before making the next changes, then mail delivery could be refused.

Make sure to select the correct domain from the domain drop-down box when creating users!

Tip – make the domain you just created your “Default user account domain” on the domain properties screen. This will add new users to this domain by default.

Step 4: Enable Inbound Messaging

This is it, the big moment when you enable messaging with BPOS. Before you proceed, make sure that you’re ready to make this change. This will make BPOS the primary, and only, mail server for your domain. Make sure you’ve created mailboxes, notified your users how to access the new system, and that you’re sure you want to direct all incoming mail to BPOS.

By now your domain should show as Verified on the Users/Domains menu:

Click on the name of the domain to access the domain properties box, then go to the “Inbound Messaging” tab. Click “Enable”.

Click “Enable” again on the next screen:

And you’ll see a Success window like this one. But you’re not done yet! The dialogue box will provide a new MX record that needs to be set-up with your domain registrar. Make a note of the new MX information (e.g. in “Step 2” in the window below).

Now go back to your domain registrar’s Domain management tool. Create a new MX record using the information provided in that last window. Set the Priority to 0 so that this record takes priority over other ones that might exist. Once again, for Go Daddy it would look like something like this:

Check to make sure that no other MX records have a higher priority. If they do, change them to a lower priority (e.g. 10 or 20. Larger numbers = lower priority), or delete them if appropriate. The new record needs to be the highest priority or mail delivery will not work.

Done? Great! Switch back to your BPOS admin window, and click Finish on the Enable Inbound Messaging box. That’s it! You’ve just configured BPOS for email.

Step 5: Test

Use a different mail system to send an email to one of the newly created mailboxes. Then, log in to OWA and you should see something like this:

From time to time, you need to allow an application server to relay off of your Exchange server. You might need to do this if you have a SharePoint, a CRM application like Dynamics, or a web site that sends emails to your employees or customers.

You might need to do this if you are getting the SMTP error message “550 5.7.1 Unable to relay”

The top rule is that you want to keep relay restricted as tightly as possible, even on servers that are not connected to the Internet. Usually this is done with authentication and/or restricting by IP address. Exchange 2003 provides the following relay restrictions on the SMTP VS:

Here are the equivalent options for how to configure this in Exchange 2007.

Allow all computers which successfully authenticate to relay, regardless of the list above

Like its predecessor, Exchange 2007 is configured to accept and relay email from hosts that authenticate by default. Both the “Default” and “Client” receive connectors are configured this way out of the box. Authenticating is the simplest method to submit messages, and preferred in many cases.

The Permissions Group that allows authenticated users to submit and relay is the “ExchangeUsers” group. The permissions that are granted with this permissions group are:

NT AUTHORITY\Authenticated Users {ms-Exch-SMTP-Submit}
NT AUTHORITY\Authenticated Users {ms-Exch-Accept-Headers-Routing}
NT AUTHORITY\Authenticated Users {ms-Exch-Bypass-Anti-Spam}
NT AUTHORITY\Authenticated Users {ms-Exch-SMTP-Accept-Any-Recipient}

The specific ACL that controls relay is the ms-Exch-SMTP-Accept-Any-Recipient.

Only the list below (specify IP address)

This option is for those who cannot authenticate with Exchange. The most common example of this is an application server that needs to be able to relay messages through Exchange.

First, start with a new custom receive connector. You can think of receive connectors as protocol listeners. The closest equivalent to Exchange 2003 is an SMTP Virtual Server. You must create a new one because you will want to scope the remote IP Address(es) that you will allow.

The next screen you must pay particular attention to is the “Remote Network settings”. This is where you will specify the IP ranges of servers that will be allowed to submit mail. You definitely want to restrict this range down as much as you can. In this case, I want my two web servers, 192.168.2.55 & 192.168.2.56 to be allowed to relay.

The next step is to create the connector, and open the properties. Now you have two options, which I will present. The first option will probably be the most common.

Option 1: Make your new scoped connector an Externally Secured connector

This option is the most common option, and preferred in most situations where the application that is submitting will be submitting email to your internal users as well as relaying to the outside world.

Before you can perform this step, it is required that you enable the Exchange Servers permission group. Once in the properties, go to the Permissions Groups tab and select Exchange servers.

Next, continue to the authentication mechanisms page and add the “Externally secured” mechanism. What this means is that you have complete trust that the previously designated IP addresses will be trusted by your organization.

Caveat: If you do not perform these two steps in order, the GUI blocks you from continuing.

Do not use this setting lightly. You will be granting several rights including the ability to send on behalf of users in your organization, the ability to ResolveP2 (that is, make it so that the messages appear to be sent from within the organization rather than anonymously), bypass anti-spam, and bypass size limits. The default “Externally Secured” permissions are as follows:

MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Accept-Authoritative-Domain}
MS Exchange\Externally Secured Servers {ms-Exch-Bypass-Anti-Spam}
MS Exchange\Externally Secured Servers {ms-Exch-Bypass-Message-Size-Limit}
MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Accept-Exch50}
MS Exchange\Externally Secured Servers {ms-Exch-Accept-Headers-Routing}
MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Submit}
MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Accept-Any-Recipient}
MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Accept-Authentication-Flag}
MS Exchange\Externally Secured Servers {ms-Exch-SMTP-Accept-Any-Sender}

Basically you are telling Exchange to ignore internal security checks because you trust these servers. The nice thing about this option is that it is simple and grants the common rights that most people probably want.

Option 2: Grant the relay permission to Anonymous on your new scoped connector

This option grants the minimum amount of required privileges to the submitting application.

Taking the new scoped connector that you created, you have another option. You can simply grant the ms-Exch-SMTP-Accept-Any-Recipient permission to the anonymous account. Do this by first adding the Anonymous Permissions Group to the connector.

This grants the most common permissions to the anonymous account, but it does not grant the relay permission. This step must be done through the Exchange shell:

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

In addition to being more difficult to complete, this step does not allow the anonymous account to bypass anti-spam, or ResolveP2.

Although it is completely different from the Exchange 2003 way of doing things, hopefully you find the new SMTP permissions model to be sensible.