You can protect Exchange on seven layers: cloud, perimeter, Edge Transport Server, inner firewall, Hub Transport Server, Mailbox Server, and clients.

The best security solutions are layered ones, taking a defense in depth approach so that there is no single layer between vital information resources and disaster. Nowhere can this be more critical than in protecting your Exchange infrastructure from malware attacks. In this post we will go over the seven key layers you should have in your game plan.

1. Consider a cloud solution as the first line of defense

The right place to stop malware (and spam) is as far away from your systems as possible. Using a solid SaaS solution is a great way to filter out malware and spam before it ever gets to your perimeter. This saves you on bandwidth, CPU cycles, and storage space and can reduce the number of threats crossing your border by an order of magnitude.

(more…)

Whenever you get the message "The connection to Microsoft Exchange is unavailable" you can use the Exchange Remote Connectivity Analyzer to analyse and test Exchange connectivity.

Email is the lifeblood of businesses today. Everyone needs email access and they need it everywhere, in the office, at home, at the airport and in the motel room where they’re meeting their lover. Maybe that last one is stretching it a bit but email connectivity from everywhere and on every device is certainly a top priority for many Exchange administrators.

Fortunately Microsoft provides an online tool to help troubleshoot remote connectivity that has steadily improved over the years; the Exchange Remote Connectivity Analyzer

(more…)

Rate this tool: (2 votes, average: 4.50 out of 5)

 Loading ...

Submit a free admin tool | Free admin tools index | Browse free admin tools

The Exchange Deployment Assistant helps you to migrate Exchange 2003 and Exchange 2007 to Exchange 2010 or Exchange cloud.

In September and October Alexander Weiss wrote a series of articles here on 4sysops around the technical aspects of deploying Exchange 2010 roles and migrating from Exchange 2003. This time around I thought we’d focus on the planning phase of a medium to large sized migration from earlier versions of Exchange to Exchange 2010.

Microsoft has offered for some time, and recently updated, the Exchange Server Deployment Assistant. It’s an online wizard that asks a series of questions about your current environment and in the end produces a customized check list with instructions for each step you need to take in your migration. These types of “design” questions are crucial in controlling how your environment will look and are similar to the concepts behind questions you’d encounter on an Exchange MCITP certification exam.

Planning is vital as email is “mission critical”; thus a large and possibly complex setup that’s going to be migrated needs precise planning. Whilst this tool doesn’t give you everything (it doesn’t cover all different combinations – yet) it’s a good starting point.

(more…)

This article explains how to automatically add email signatures/disclaimers in Exchange 2010 using Transport Rules.

For many organizations, it’s a good idea to centrally manage email signatures and email disclaimers – it gives a consistent branding on your email communications, and you’re not relying on end users to set them up correctly and keep them consistent. If you’re running Microsoft Exchange 2010, you have the ability to do this out of the box, using ‘Transport Rules’. Applying signatures this way should also save you space in your mailbox databases, due to the fact that signatures won’t be added on to each message in every users “Sent Items” folder.

To get started with a basic signature, open the Exchange Management Console, and navigate to: ‘Organization Configuration’ >> ‘Hub Transport’, then select the ‘Transport Rules’ tab, finally click the ‘New Transport Rule’ link in the actions pane on the right. The Transport Rule wizard should then start, you’ll need to provide a name for your rule, and then select which user or group of users this rule should apply to. In your first instance, it’s probably a good idea just to apply it to yourself to test with, later you can apply the rule to other individuals, distribution groups  etc. Have a look through the options available to you in step 1, they are quite flexible with who the rules can be applied to. In step two of the transport rule wizard, you will need to chose the ‘append disclaimer text’ action, and then enter your text by clicking the appropriate hyperlink in the bottom pane of the wizard.

(more…)

This article explains how to deploy the Exchange 2010 Mailbox Server Role

The Mailbox Server Role is the last role you need to install to have a working Exchange 2010 environment. The two Server Roles that I haven’t talked about yet—namely, the Edge Server Role and the Unified Messaging Server Role—are specialized roles that either improve security or centralize communication in one inbox. Exchange 2010 will run well without them, so I won’t cover these topics in my Exchange 2010 deployment series.

The deployment of the Mailbox Server Role is straightforward. The Mailbox Server Role is quite resource intensive, so unless you have a very small amount of users and data you should deploy it on its own server. The mailbox server is also the place where all your data resides, so it needs plenty of hard disk space. A video is available at TechNet that supports you in deciding how to size the mailbox server. There is also a tool to calculate Exchange 2010 Mailbox Server Role Requirements.

(more…)

By now you should have a working Exchange 2010 Client Access server. However, an Exchange 2010 environment needs at least two more server roles installed: the Hub Transport Server Role and the Mailbox Server Role. It doesn’t matter if you are going to deploy these roles on the same server as the Client Access Server Role or if you choose a different server; the procedure is nearly the same. Because installing the three roles on the same server might lead to performance issues, however, Microsoft recommends to not combine the Mailbox Server Role with any other role on the same server. In small environments, performance shouldn’t drop when you run all of them on the same server, even if the server is virtualized.

Let’s start with the Hub Transport Server Role. The installation process will differ slightly if you install this role together with the Client Access Server Role or on a standalone system. If you do the latter, you should install the prerequisites before you launch the setup wizard. The fastest way to achieve this is by typing these PowerShell commands:

(more…)

In my yesterday’s post in the migration to Exchange 2010 series, I wrote about deploying a Client Access server. By following my guide, you set the external namespace for the Exchange 2010 environment. For your users’ convenience, you might have chosen the same namespace you used for your legacy server. But assigning the same namespace for two different services usually causes a lot of trouble, so you might ask yourself how both Exchange versions can coexist under the same namespace.

Coexistence under the same namespace is not possible. When you provided the same namespace during the Client Access Server Role installation that you are using for your legacy Exchange installation, the setup routine automatically changes the namespace for the legacy server. If your users try to access Exchange using the URL they are used to, they connect to Exchange 2010. But that is what you want your users to do because Exchange 2010 Client Access can interoperate with legacy Client Access servers. If the Exchange 2010 Client Access server gets an access request it can’t handle, it simply redirects the query to the legacy server.

(more…)

After you prepare the active directory and determine the hardware resources, you can start deploying Exchange 2010. The first role you have to deploy is the Client Access role. Before you can run the Exchange server’s setup routine, you must install the following software: .NET Framework 3.5 SP1, PowerShell 2.0, WinRM 2.0, and IIS 7.0.

You also have to install a few server roles and features. You can do this via the Server Manager interface, or you can use this PowerShell command:

Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic-Auth,
        Web-Windows-Auth,Web-Metabase,Web-Net-Ext,
        Web-Lgcy-Mgmt-Console,WAS-Process-Model,RSAT-Web-Server,
        Web-ISAPI-Ext,Web-Digest-Auth,Web-Dyn-Compression,
        NET-HTTP-Activation,RPC-Over-HTTP-Proxy -Restart

(more…)

In my last post about Exchange migration, I wrote about the preparation of the Active Directory. Before I give a rough guide through the migration process I want to talk about the possibilities of virtualizing Exchange Server 2010. There are two reasons why I think it is necessary to bring this point up: First, there are still quite a few administrators that have a deep aversion to virtualization. Second, although virtualization is widely used today, there are a few things you have to consider before you should deploy Exchange 2010 on a virtualized machine. Exchange 2010 is ready for virtualization, so you can install every role on virtualized guests. Only the Unified Messaging Server Role needs to be installed directly on the hardware.

For those who are still skeptical about running a business-critical application like Exchange in a virtualized environment, I just have to say that it works; indeed, it works very well. Besides that, there is no difference between running Exchange Server 2010 on a hardware machine or a virtualized machine, as long as you follow some guidelines. It even has some advantages: If you want use the DAG feature of Exchange 2010 you need two Server and two Windows Server 2008 R2 Enterprise licenses. If you only have a midsized company, the chances are big that the resources of the two Servers are not close to being utilized properly. The Windows Enterprise license allows you to run up to four software instances at a time in a virtualized environment under one license. So you could have up to eight virtualized machines running Windows Server 2008 R2 Enterprise with the two licenses you need for a DAG. Isn’t that alone reason enough to virtualize Exchange 2010?

(more…)

Some companies still run Exchange 2003 and are content with its performance. However, Exchange 2003 is slowly getting close to the end of its lifecycle. Besides the end of mainstream support, there are other good reasons to switch to a newer Exchange version. In particular, Exchange 2010 offers many features that are just too good to be ignored. In addition to high scalability, the most welcome feature is the Database Availability Groups (DAG). It has never been easier to offer High Availability services for your users. But what about the migration to Exchange 2010; is it as simple as building a DAG?

The migration certainly is easier than what most administrators will expect. Microsoft also offers some nice guides, such as the Exchange Server Deployment Assistant. Though I strictly followed the guide, I encountered more than one problem. As problem solving can take quite some time, I decided to share my experience. This is by no means a complete migration guide or an alternative to the documentation available on TechNet or elsewhere. It is merely a supplement to the Exchange Server Deployment Assistant.

(more…)

For the time being, this article may be the last one in my series about email archiving. Perhaps I will add a few notes about GFI MailArchiver at a later date, because I will review this product for a German magazine. Even though I didn’t review an email archiving tool in this series, I think that the benefits of email archiving were clear.

Since I probably influenced many with this series, I don’t expect this poll to be representative. However, I think that the results could still be interesting. I already was planning to introduce an email archiving solution in my organization, mostly because I didn’t like the fact that our email backups only lasted for a relatively short time period. For most organizations compliance is probably the most important reason for introducing an email archiving software. But since, I have looked at the features of email archiving tools, and it has become clear that the technical benefits are most interesting from an administrator’s point of view.

(more…)

This is the last article in my series about email archiving features; however, I will probably conduct a new survey concerning email archiving. Today, I will discuss some technical considerations that must be taken into account when introducing an email archiving solution. In particular, I will consider email archiving services, appliances, email systems, and enterprise features.

The first issue to consider before you begin evaluating email archiving solutions is whether you want to buy and install the software yourself, or employ an email archiving service. Since the cloud computing hype will probably reach its peak in 2009, I believe many will take the latter way. It is an attractive solution due to the time and effort that is saved.

Email archiving services

In the course of my career, I have outsourced many IT solutions to larger computer centers. What seems simple initially can cause many technical problems. In this case, you not only have to ensure that all emails are routed to the service provider, but you also have to synchronize the user databases. This is necessary to enable end-users to restore emails by themselves. Most time consuming are those cases where an end-user cannot access the service and you don’t see any technical problem on your side, but the service provider purports that everything works just fine. We have to deal with such incidences every day, and I can tell you, it is not fun.

(more…)

This article in my series about email archiving is about how to access the archive. Perhaps these are most important features of an email archiving solution. After all, the main reason for archiving emails is to search for and retrieve them.

Indexing

In my last post in this series, I mentioned that email archiving tools store emails in different ways. This may also influence their search capabilities. Every email consists of different parts: sender, recipient, subject, date, categories, etc. I think it is important for the tool to allow you to limit the search to any of these fields. Of course, it should also be possible to perform a full text search in the email’s body.

The most difficult part to index is definitely the attachment. Most attachments are sent as MS Office or PDF files. But there are many other important formats such as the OASIS Open Document Format, Open Office formats, HTML, XML, etc. The more formats the email archiving product supports, the better. Another problem is that the attachments are often compressed. The email archiving tool must be able to understand the different compression formats to be able to index all attachments. Furthermore, it is important that new formats can be added and that the email archiving vendor updates its software regularly.

(more…)

This is my second post about the features of email archiving software. Yesterday, I discussed the features that are related to the archiving process. Today I will focus on the different ways emails are stored by archiving tools.

As files or in a database

There are email archiving solutions that only store the metadata in a database. The email bodies and the attachments are saved as files. It is also possible for only the attachments to be stored separately. Perhaps this method is safer when it comes to long-term archiving because one is not dependent on the database software. Who knows if its vendor will still exist in 20 years? However, search performance might be better if everything is stored in a database.

Whole object or individual parts

This topic is related to the one above. Emails can be archived in one piece or each part of an email (header/body/attachment) can be stored separately. Obviously, you have more search options if the email archiving solution is able to distinguish between the different parts of an email.

(more…)

In my upcoming posts I will cover all the important features that an email archiving software can possibly have. As noted before, you can use this feature list to decide what kind of email archiving solutions fit best with your environment and your needs. As things stand now, there will be three posts about these possible features. Today I will discuss the features that are relevant to the archiving process. In the next posts I will cover storage-related, access-related, and technical features.

Server-based archiving

Server-based archiving means that an email is archived immediately after it is received by the SMTP server. Large organizations with many email servers can especially benefit from this feature because the email archiving software can intercept emails before they are delivered to the server where the user’s mailbox is stored. This can improve performance because the email archiving software doesn’t have to scan all of the email servers for new emails. Another important advantage of server-based archiving is that end users can’t delete emails before the email archiving software gets a chance to store them away.

(more…)