When you are transitioning from a legacy Exchange version to either Exchange 2007 or Exchange 2010 you will come to a stage in the project at which you need to plan for the migration of mailboxes to the new servers.

In small to medium size businesses the considerations are fewer than for larger enterprises, but they do share several in common.  Generally speaking you should plan for the following items.

End user interruption – when a mailbox is moved the end user will be disconnected from it.  Older versions of Outlook do not handle this very well, but even newer versions will need the end user to restart the application to connect to their new mailbox.

This means that it is often best to schedule migrations to occur outside of normal business hours.  Evenings and weekends are very common for this.  If a business operates 24 hours a day using rotating shifts then you can schedule migrations to occur so that a given user is moved when they are not rostered on duty.

Transaction Logging – a mailbox migration means that on the target server (the new server) a whole bunch of new data is being written into the databases.  This creates a very large amount of transaction logging, often much larger than what a normal day’s email traffic would generate.

There are a few ways to manage this.  Moving mailboxes in smaller batches keeps logging to a minimum but means migrations will take longer.  Provisioning large amounts of disk space on the logging volume means bigger batches can be migrated, but after the migration is finished it can mean wasted disk space that is not needed for day to day logging levels. Continue reading Planning Considerations for Exchange Mailbox Migrations

In most businesses the topic of shared email and other mailbox features will come up at some stage.  A business will have certain requirements that the Exchange administrator needs to configure the system to meet.  Depending on what those requirements are the actual configuration used will vary.

One of the most common situations is the sharing of email addresses.  A group of uses need to receive email sent to a certain email address other than their own personal email address.

Sometimes it is appropriate for this to be achieved simply by using a secondary email address on the user’s mailbox.  John Smith can have john.smith@company.com as his primary email address, but also receive email sent to his predecessor’s email address of greg.jones@company.com.

In other cases this does not work so well.  A reception desk staffed by more than one person throughout the week makes it impossible to assign reception@company.com as a secondary email address to each individual person’s mailbox, because an email address can only exist on one mail-enabled object in the organization at any one time.

The solution here could be to use a distribution group, or to use a shared mailbox.  Each has its pros and cons.  A distribution group delivers each mail item sent to the address to each member of the group.  This works fine for newsletters, memos, and other broadcast type information, but not so well for items where only one person needs to take action.

In those cases a shared mailbox is better suited, because it means a single instance of each actionable item and everyone who shares the mailbox can tell when something has already been actioned.  Shared mailboxes are commonly used for Help Desks and sales teams so that a single email address can be publicized and a team of people can access the mailbox to action new items. Continue reading Shared Email Address Scenarios

There have been many times in the past when I have started a project for a new customer and discovered that they are not using SSL for their email servers.  Usually after a brief discussion they agree to implement SSL in the new system we are installing for them.

Occasionally they agree but insist on doing it in a less than ideal manner.  And sometimes, although rarely, they decline our advice and continue without SSL.

What is SSL?

SSL stands for Secure Socket Layer and is an encryption protocol that secures communications between two parties over insecure networks such as the internet.  Although still commonly referred to as SSL its new name is actually TLS (Transport Layer Security) which more accurately describes its role of securing communications at the Transport layer of the OSI model (eg, the TCP protocol).

In an SSL/TLS secured communication the two parties (e.g. a web server and a web browser) agree on how to secure the connection they are establishing. Continue reading The Importance of SSL for Exchange Servers

Some Exchange Server 2007 and Exchange Server 2010 roles require Internet Information Services (IIS) to function.   On these servers Exchange will install a series of IIS virtual directories.  In this post I will describe the Exchange Server virtual directories and their purpose.

/owa – This is the directory for OWA (Outlook Web Access on Exchange 2007, and now called Outlook Web App on Exchange 2010), which is the web browser version of Outlook that is usually accessed by remote workers.  The /owa directory is for access to Exchange 2007 or 2010 mailboxes.

/Public – This is the directory used by OWA users when accessing any Public Folders in the organization.

/Exchweb – This directory is used for OWA access for Exchange 2003 or 2000 users but is not usually accessed directly by the end user.  The OWA session will automatically refer the connect to this virtual directory when necessary.

/Exchange – This directory is again used for OWA access.  When an Exchange 2003 or 2000 mailbox user access the /Exchange virtual directory they are proxied to their mailbox.  For Exchange 2007 or 2010 mailbox users they are redirected to the /owa directory for their mailbox access.

This is useful during the transition from legacy Exchange versions to 2007 or 2010, because users can continue to connect to the /Exchange directory and the result will always be that they connect to their mailbox, as long as the server does not run the Mailbox Server role.  In other words, the /Exchange directory only works for legacy mailbox users if the server is a dedicated Client Access Server (though it can also contain the Hub Transport Server role without a problem). Continue reading Overview of Exchange Server Virtual Directories

As often happens with electronics trends, the proliferation of a consumer device soon results in that gadget knocking on the door to the enterprise.  That’s the case with smartphones. The trend started with the Blackberry, was supercharged by the iPhone and will continue to grow with phones running Google’s Android operating system.

What’s worrisome about these devices is that they run applications… far too many applications that any IT department could vet for security purposes. Jupiter Research, purchased by Forrester research in 2008, estimates that by 2014, 20 billion apps will be downloaded annually to smartphones.

That is a nightmare in the making for network administrators, who see legions of unknown programs touching their enterprises. Such apps already exist for the iPhone to directly access enterprise programs like SAP and Oracle. And with more apps on the way, the potential for them to spread malware or facilitate unauthorized access to precious data is a sobering thought for gatekeepers.

One way to get a handle on mobile devices invading an enterprise is to impose tough policies on employee use of their mobiles when performing office tasks. Monitoring policy compliance manually, though, can be an overwelming task for overtaxed IT departments. There are automated systems for ensuring compliance, but they can be expensive to implement.

There are also some drawbacks to keeping a tight rein on smartphone use. By limiting an employee’s choices on how he or she must work, a policy could adversely impact the worker’s productivity. Then there’s the problem with exceptions to the rule. If someone higher up on the corporate food chain than an IT gatekeeper wants to use a particular application, whether it’s risky or not, an exception to its use will likely be made.

Continue reading Protecting the enterprise from mobile devices

Microsoft Exchange Server has used Connectors in various ways for many different product versions to date.  Exchange Server 2007 and Exchange Server 2010 both use the same types of Connectors in their organizations.

Even in simple organizations some people become confused by the variety of Connectors and their purposes.  Here is an explanation of each type of Connector for Exchange Server 2007 and 2010.

Send Connectors

Send Connectors are responsible for sending email to servers outside of the organization.  This might also include Edge Transport Servers, which are non-domain member servers usually located in a secure DMZ for sending and receiving internet email.

Send Connectors can be configured in a number of different ways.  The typical Send Connector for an organization sends all outbound email to a smart host or uses DNS to route the mail directly to the receiving party.

More specific Send Connectors can be used to send email destined for particular domains to different servers.  One example would be a Send Connector that routes email across a secure VPN to a partner domain rather than go via the internet.  Another example would be a Send Connector that has a larger message size limit than the default one, permitting very large files to be sent to partners or customers.

Send Connectors can be configured with authentication requirements when sending to a smart host, but when sending via DNS lookup have no authentication options to configure.  However, Exchange Server will honour the receiving server’s security or authentication requirements (such as TLS encryption) where possible.

Continue reading Understanding Exchange Server Connectors

Having multiple mailboxes can be a benefit for users who want to direct email to specific mailboxes based on subject material, audiences or other personal reasons. But it can also increase the workload of not only the corporate servers but of the administrators as well.

Exchange server allows users to access those multiple accounts while using only one profile and not having to re-log in under a different username. To support this functionality it is necessary for an administrator to configure Outlook such that it will enable a user to access those multiple email boxes from one profile.

An administrator should start Outlook using the profile that is configured for the Exchange server mailbox of the account (#1) that is going to be used to add a “delegate” account. Validation may be required. If so then log in to the network as the user of the account (#1). Then, follow the steps outlined below for Outlook 2002 and 2003:

1. From the Tools menu, click Options to add a delegate.
2. Select the Delegates tab and click Add.
3. Type or select a username for the delegate account (#2).
4. Click Add, and then click OK or hit enter
5. Locate the Delegate Permissions dialog boxes. Then select Editor (read, create, and modify items) in each of them.
6. Click OK or hit enter two times.
7. Click on Folder List on the View menu to make it visible.
8. Right-click the Mailbox – user name (to begin adding a new user).
9. Then click Properties for Mailbox – user name on the shortcut menu.
10. On the Permissions tab, click Add.
11. Type or select the username of account (#2) you wish to add and then click Add.
12. Click OK or hit enter.
13. From the Name box, click the newly added user for the account (#2).
14. From the Roles box, click Owner, and then click OK or hit enter.
15. Repeat steps 8 through 14 for the rest of the other folders in the mailbox.
16. On the File menu, click Exit and Log Off.

You are now ready to restart Windows and log in as the newly created username for account (#2). Once Windows has restarted you should then start Outlook with the corresponding profile for the newly created username.

Continue reading Working With Multiple Mailboxes

One of the features of Outlook and Exchange Server Information Services is the ability for end users to work in an offline mode. This can be beneficial when connections cannot be made to the server for various reasons.  Working in an offline mode allows workers to continue to be able to create emails and schedule other email functions that can be completed at the next connection with the email server.

End users are able to work with folders in an offline mode. Sometimes this is required when the network connection is not available. After the network connection is made available then the end users can synchronize their changes and updates with the email server.

Offline folder files (OST) are stored locally on disk in the end user’s Windows folder and are always available. Like other folder files, the offline folder file can be compacted to save space. The offline folder file is created as a mirror image of the end user’s files on the Exchange server. The files are coordinated with each other during synchronization with the server. When creating an offline folder file for the first time it is required that the client is connected to the Exchange Server for the successful creation and synchronization of the Offline Folder file.

An offline folder file can be created as outlined below:

1. From the Tools menu, select Services. (A Services dialog box will be displayed.)
2. Select Microsoft Exchange Server and then click the Properties button.
3. Next click on the Advanced tab and then select the Offline Folder File Settings button. (An Offline Folder File Settings dialog box will be displayed.)
4. In the File box, type the path of the file you want to use as the offline folder file.
5. If the message stating that the “<path><filename>.ost could not be found. Would you like to create it?” appears, click OK or hit enter.
6. Click OK or hit enter twice.

As previously mentioned, end users can add, remove and make changes to their offline folder content as if they were connected to their server even without a connection. Users will have the ability to create replies and read messages in the offline Inbox. They’ll also be able to “send” messages. But these actions will not be applied until the next time the user connects to the email server and performs synchronization.

Continue reading Working With Offline Folders

Exchange Server 2010 has similar capabilities to Exchange Server 2007 when it comes to adding disclaimers to emails sent by end users.

However two improvements have been made in Exchange Server 2010 – the ability to use HTML to format the text, and the ability to insert Active Directory attributes into the text.

These new capabilities make it very easy to add a standardised email signature and disclaimer to all emails sent in the organization.

For this to work the desired Active Directory attributes need to be populated on the user account objects.  Attributes that would commonly be used in email signatures include the person’s name, job title, phone number, and street address.

You can view and edit these attributes in the properties of the mailbox or user account.

When the user accounts are populated with the necessary attributes you can proceed with the creation of the Transport Rule that will add the signature and disclaimer. Continue reading How to Add Automatic Email Signatures and Disclaimers with Exchange 2010

A fix for a flaw in an important Internet security protocol is ready for prime time but it will be many months before the patch is fully implemented, according to technical experts.

The authentication vulnerability in TSL/SSL, which is the most common security code on the Net, could be exploited by hackers for all kinds of mischief. Built into browsers and Web servers to protect high-value information, the flaw impacts a wide scope of technologies including online banking, back-office systems using Web-based protocols, non-HTTP applications such as mail and database servers, mobile phones, wireless access points, DECT phones and home security systems.

The vulnerability was discovered last September by researchers at PhoneFactor, a security service provider in Overland Park, Kansas, but was kept under wraps until November when another security expert, working independently, made the flaw public on a mailing list sponsored by the Internet Engineering Task Force (IETF).

With the cat out of the bag, PhoneFactor decided to push out a press release on the subject. In it CTO Steve Dispensa, who, along with Marsh Ray, initially unearthed the flaw, stated,

“Because this is a protocol vulnerability, and not merely an implementation flaw, the impacts are far-reaching. All SSL libraries will need to be patched, and most client and server applications will, at a minimum, need to include new copies of SSL libraries in their products. Most users will eventually need to update any software that uses SSL.”

“The discovery of this vulnerability speaks to a larger issue with single channel authentication protocols,” he added. “While this vulnerability is larger in scope than many, man-in-the-middle attacks have been a known threat for some time. Out-of-band protocols should be considered when possible to help mitigate the risk of these attacks.””

Continue reading Net security hole could take year to fix