First of all, let me give you a bit of background. Between 2004 and 2010 I spent a lot of time working with on-premise solutions which processed hundreds of thousands of clean mail each day and deflected many orders more spam. During that time I had to understand a lot about where spam and associated malware comes from and what techniques work well against it. By 2010 the kind of effort required to keep up with the above was something I particularly found resource intensive, even though much of it I was delegating to my team. So around that time, I decided it just wasn’t worth it and outsourced mail scanning to the cloud – and never looked back.

Working as a TA these days I see the same decisions made elsewhere and these days it really is the exception rather than the rule when I see a customer who is running on-premises mail scanning software at the edge.

With that in mind, it’s interesting to see that GFI, who have long been a leader in the market for on-premises spam and malware scanning software with GFI MailEssentials, move to offer a cloud-based solution to compete, primarily in the SMB market. GFI got in touch with me about a month ago and asked me to give their new product, GFI MailEssentials Online a spin and share my thoughts…

First Impressions

I’ve worked with a number of cloud-based mail scanning solutions in the past – working on projects to migrate to them from on-premises systems, moving between different solutions and during Exchange Server migrations had experience when cutting mail over between the old and new systems.

A common theme with some of these solutions is that the user interface isn’t very intuitive and all of these products (e.g. Websense/Black Spider, Postini and FOPE) are very capable in terms of what they can do, but for your average IT administrator settings are found all over the place. If you’re not logging into the interface very often, it’s almost as if you’ve got to learn the interface from scratch. I’ve witnessed customers who have used their provider for years struggle to find basic settings through no fault of their own – the systems can be a right mess.

That’s where GFI seem to have got things right from the outset – the interface reflects that it’s not a dated offering where new features have been thrown in as time has went on; it’s fresh, clear and concise and not once did I need to refer to the actual documentation to accomplish anything. If you’ve ever had to work with policy rules or setup directory synchronization in FOPE, for example, you’ll see that this is a breath of fresh air.

In terms of features – again I am impressed. We know that for the SMB market, GFI have over a decade of experience with the on-premise MailEssentials product so we know it’s going to be capable, but I wasn’t expecting to see the option to use features like greylisting, which I think is particulary effective in the fight against spam.

Getting Started and Setup

I signed up for a trial via the GFI website, and with a few minutes was granted access to the Administrator portal. Like most other solutions, a dashboard greets the admin with statistics shown for areas such as spam volume:

The first thing you need to do is add a new domain, and configure it’s services. As I mentioned above – it’s actually very intuitive. I was asked for the domain name, and the primary mail server to list – perfect for the SMB market:

After adding the domain, we’re then led to the domain management section of the Administrative portal, which allows us to configure spam filtering service for the domain itself. First of all, we’ve got an “aggressiveness level”. This can at a high-level be compared to the built-in anti-spam features within Exchange, where blocking, quarantine levels can be specified based on score. You’ll also see configuration options for dealing with unknown users, and the ability to switch on or off the greylisting features.

One area most administrators are familiar with is making sure certain senders – such as partner companies – can send mail without being scanned both inbound and outbound. GFI call this “Whitelisting”, though personally I prefer the term “Safe Senders” as used within the Outlook client. From, To, Subject and mail server IP addresses can be specified here:

Another common area that control over blocking is required is based on the attachment type. Many forms of attachment are blocked, some to ensure that end-users cannot bypass web filtering to get access to executable files, and more commonly to ensure that malware is very unlikely to reach internal recipients. Yep, you can scan messages for known viruses, but there is a pretty big gap between a new form of malware appearing and definition updates being produced by most anti-virus companies. Therefore blocking executables (or exes renamed to a different file extension) from being received in the first place is extremely helpful.

Finally, in the basic setup we can add additional inbound mail servers, and of course make a note of the records we’ll need to change later on to switch MX records over from our on-premises mail server to the GFI service:

Directory Synchronization

There’s a couple of reasons why you’d wish to synchronize your local directory with your online service. First of all, there’s the ability to block unknown email addresses at the “edge” and prevent any attempt to deliver them to your local Exchange server. Secondly is if you wish to be able to give end-user access to the spam quarantine and release messages themselves.

Typically, there are two ways to accomplish this – first is via a dedicated on-premise piece of software that sits behind the perimeter network and reads the local Active Directory or Exchange organization information and synchronizes that data to the mail scanning solution, and the second is by the mail scanning solution initiating a connection to the on-premises Active Directory or other LDAP directory.

Personally, my preferred approach is the former, as larger enterprises especially tend to deploy dedicated DMZ networks and are not able or willing to allow an external internet-based source to connect to their on-premises directory. However the downside is that the on-premises sync tool often requires some maintenance and occasional troubleshooting.

GFI’s approach is to use the LDAP-based approach, which for the target market – small and medium enterprises – seems most appropriate as it’s low maintenance and requires minimal time and effort to keep running.

The configuration is fairly straightforward; once you have allowed GFI’s IP address ranges to contact an Active Directory domain controller (via port 636, if you want to ensure traffic is encrypted), GFI provide a wizard-driven interface to enter your server details:

After entering server details, you are able to test the configuration to ensure that it is indeed valid.

And finally, it gives an overview of the users it plans to create accounts for within the GFI service:

To be honest, it couldn’t get more straightforward. Another thing I did check was that it could handle more than just mailboxes – for example in my example organization, I’ve got mailboxes hosted on Office 365 and it imported these also without any issue.

Reporting

A key area most administrators in companies large and small are interested in, is the reporting facilities that a product offers. Being able to demonstrate that a product is working is very important when the time comes to prove that it’s been a valuable investment.

So GFI’s product certainly delivers in this area. I’m not a big fan of reports myself so I don’t get all that excited about them – and based on my demo experience, I haven’t been able to generate enough traffic to generate something worth showing, but suffice to say the facility is there and on a par with competitors:

The second type of reporting is message tracking reports – essential for troubleshooting delivery issues and verying that a message was or wasn’t delivered. I can definitely say that the product delivers in this area – and is equal or better to most other competitors – for example compared to FOPE it’s a lot easier to use, a bit more flexible and shows an equal amount of information:

Custom Policies

Policy rules are an area that bigger customers I deal with do use and some find essential. The kind of things policies can do include:

• Profanity rules and exceptions; for example engineering terms that double as mild swearwords, or a pharmaceutical company wanting to ensure that messages containing references to certain prescription medicine aren’t blocked.
• Confidentiality rules; for example to ensure that key terms or patterns are not sent outside the organization – such as credit card numbers.
• Encryption rules; for example to ensure that TLS is enforced between particular domains.

This is one area that just yet, GFI aren’t offering extensive functionality. However I don’t see these kind of features being used extensively in the small and medium business sectors, so it’s not in my opinion a big issue. For the most part this functionality can be used in Exchange itself using Transport rules or whitelisting domains or senders within the GFI service. In regards to TLS, GFI have confirmed opportunistic TLS (i.e. if the recipient domain supports it, TLS will be used) can be switched on if a customer requires it.

Summary

Overall, I’m pretty impressed with the GFI MailEssentials Online service. It doesn’t feel like a “new” offering and it’s clear that the service is based upon experience elsewhere, possibly the many years offering similar products like the on-premises product.

I also think there is a great opening for MailEssentials for the SMB market looking to move/migrate from services with an uncertain future – like Webroot, who are closing their email protection service. It will be interesting to see if this good timing pays off, and to be honest I hope it does.

Read more about GFI MailEssentials Online over at the GFI site

Related posts:

1. Testing edge blocking in Forefront Online Protection for Exchange using Powershell
2. Great joint post about Zimbra verses Exchange
3. Missed Tech Ed Europe 2010? Watch the Exchange Sessions Online Now

Let’s say you’ve built a Hybrid Exchange 2010 SP2 / Office 365 environment. You create a user, using your provisioning tool of choice – for this example we’ll say Active Directory Users and Computers:

So generally, running Enable-RemoteMailbox should work, in the same way running Enable-Mailbox should work too – all the components in Exchange are configured correctly, and if you create a mailbox using New-RemoteMailbox or the Exchange Management Console everything works.

However, the following happens:

The error – for the purposes of people searching for it is The Address @tenant.mail.onmicrosoft.com is invalid: “@tenant.mail.onmicrosoft.com” isn’t a valid SMTP address. The domain name can’t contain spaces and it has to have a prefix and a suffix, such as example.com. FullyQualifiedErrorID : F0109C5E,Microsoft.Exchange.Management.Recipient.Tasks.EnableRemoteMailbox.

I did a quick search on the net, and didn’t find any answers however I did find someone having the same problem. Sadly they hadn’t had much luck with forum support or Office 365 support.. So I had a little bit more of a look into the issue and found that the solution in most cases should be fairly simple.

When enabling the remote mailbox, use the –RemoteRoutingAddress parameter, specifying your alias and service domain/Office 365 tenant, for example:

Enable-RemoteMailbox <username> -RemoteRoutingAddress <alias>@<tenantName>.mail.onmicrosoft.com

After using the command as shown above, the remote mailbox should be created and thus provisioned correctly by DirSync:

A few points of note in addition – if you’ve configured your Hybrid organization the “old” way – i.e. you’ve got a service domain, replace the above <tenantName>.mail.onmicrosoft.com with your chosen Service Domain (i.e. service.contoso.com). And the original poster to the question I answered on TechNet found in his environment, he needed to use the –Alias parameter also to get things moving.

Hope this helps

Steve

Related posts:

1. Managing Office 365 and On-Premises Exchange 2010 from the same Powershell Session
2. Enabling Silent OWA Redirection for Office 365 Hybrid
3. Disable Exchange 2010′s Auto Shared Mailbox Mapping Feature

So, it’s about time I wrote about the KEMP LoadMaster, ran through a quick overview of how it works and re-iterate why you really should consider load balancing Exchange Server 2010 with a load balancer rather than Windows Network Load Balancing.

Why use a load balancer?

With Exchange Server 2010 clients in a highly-available environment need a resilient point to communicate with Exchange client access servers. In Exchange 2010, not only do clients like web browsers, mobile devices and Outlook Anywhere clients (e.g. Outlook!) connect to the Client Access servers, but also traditional MAPI clients too. The “Client Access Array” within Exchange Server provides a single name that is used by MAPI clients as the Exchange Server name, and because of this it is very important that this is highly available and in the event of failover or switchover clients are not disconnected.

When you listen to the advantages of Exchange Server, one of the areas where benefits are apparent over previous versions is in this area – the ability to perform maintenance on servers without affecting end-users. The real benefit to you as an IT admin is that you can patch Exchange during the working day instead of waiting until a scheduled out-of-hours maintenance period in the evening. It’s kind of like the vMotion of Exchange.

However if you’re just relying on Windows Network Load Balancing, you kind of only get half of that advantage. Common problems using Windows Network Load balancing are issues like some Outlook clients not automatically reconnecting to the NLB after one node is removed and this often means you are back at square one when it comes to performing maintenance.

The second more fundamental set of reasons lie in scalability, service awareness and session affinity. Rather than re-iterate what I’ve written about in the past, check out my article Exchange Team no longer recommend Windows NLB for CAS load balancing.

Finally if you’re building out a new Exchange 2010 environment, hardware costs and licensing are real considerations. As an example, let’s look at two options for building out a small but resilient Exchange infrastructure:

Option 1, using NLB:

• 2 x Client Access / Hub Transport Servers
• 2 x Mailbox Servers forming a Database Availability Group

Option 2, using a Load Balancer:

• 1 or 2 Load Balancers, depending on requirements
• 2 x Combined Client Access, Hub Transport and Mailbox Servers forming a Database Availability Group

So, with Option 1 we’re possibly looking at the following additional servers just to support Windows NLB on the Client Access/Hub Transport roles:

• 2 x Exchange Server Standard Edition Licences
• 2 x Windows Server Standard Edition Licences
• 2 x Servers with probably 8GB RAM each, RAID 1 storage and Xeon CPUs with multiple NICs, redundant PSUs.

But with option 2, we’re replacing all that with a load balancer (bear in mind that in a typical environment the combined role Exchange servers will have a lot of spare CPU cycles available and not need as much additional memory as standalone CAS/HT servers).

Now, traditionally with load balancers like the F5 and the Cisco ACE I’ve found that it’s not easy to justify the benefits when the primary application may just be Exchange, and possibly Lync – they are just too expensive and completely overshadow the hardware and licensing costs of CAS/HT servers.

However I think this is where KEMP have found a good niche in the market – not only are they now an established player with a lot of people in the Exchange community using them, the price point fits the bill perfectly. Even in a virtual environment where there’s no additional hardware and Windows licences to purchase, the KEMP is still competitive against Exchange Server Standard edition licences.

So for the same ballpark price, it’s an easier implementation, easier to manage and it’s a nice compact straightforward design. For example, using a load balancer fits in quite well with the idea of using combined role servers as “building blocks” to scale Exchange simply as your requirements grow.

Overview of the KEMP Virtual LoadMaster

A good start when you’re looking at the KEMP LoadMaster is the Virtual LoadMaster, or VLM for short. There’s a few different models in the KEMP range – and the VLM is a good one to get a demo of to see what it’s actually like in practice. You’ve got the Exchange specific ones and generic ones which can balance pretty much anything.

For this example, I’ve drawn a quick diagram to illustrate what we’ll be attempting to do. You’ll see the HTTP/S namespace for exchange (mail.exchangelabs.co.uk) and the CAS Array name (outlook.exchangelabs.co.uk) both pointing internally at the KEMP VLM. Behind it is three Exchange Servers, all hosting the Client Access, Hub Transport and Mailbox roles as part of a Database Availability Group:

Initial setup of the KEMP LoadMaster is straightforward – but in overview you need to perform the following steps:

• Installation of the VHD of VMDK into your Virtual environment.
• First boot and access of the VLM via HTTP
• Licensing
• Configuration of network interfaces.
• Installation of my Wildcard SSL certificate onto the LoadMaster.

Next it’s onto the configuration of the environment to match the diagram above. I’ve configured two network interfaces, bridging the above two VLANs/LAN segments shown. This allows the LoadMaster to act in a transparent fashion and report the original client IP addresses to the Exchange Servers themselves. I’ve then configured the Exchange Servers, covered in detail within the KEMP Exchange 2010 deployment guide:

• Using the LoadMaster as the default gateway on each Exchange server hosting the CAS role (all of them, in our scenario).
• Configured SSL Offloading on each Exchange server hosting CAS.
• Configured Static RPC ports for MAPI and the Address Book Service on each Exchange server hosting CAS.

I’ve then added services for HTTPS, and the two RPC services, as shown below:

As you can see, it’s a fairly straightforward configuration, and we can add more services under different ports, or different IP addresses as required; for example to publish SMTP services, or indeed other servers such as Lync.

Similarly, when it comes to management of the devices and services, we’ve got an easy to use interface to disable the real Client Access Servers from receiving traffic:

Finally, we can examine statistics about the Loadmaster itself, client connections and the traffic sent to each Exchange Server:

Conclusions

So, we’ve had a quick look at the KEMP and as you can see, it’s fairly straightforward to administer and look after. It’s certainly a lot easier to get to grips with than, say a Cisco ACE (something I’ve had some experience with) and that means it’s likely to be more than just some “black box” that you don’t ever log into, or are worried about breaking something if you use. And if you’re implementing it for someone else, you’ll be able to hand over the unit confident in the knowledge that you won’t get a phone call next time someone needs to disable one of the servers for patching.

But the one thing that makes KEMP especially attractive is the combination that it’s a well known product, with decent support and a decent price. There are free solutions out there (like my own!) but I wouldn’t use them in a production environment simply because you need quality support available if there is an issue.

A final note – KEMP did ask me to write about their Load Balancer but I’d like to make it clear that I didn’t receive any compensation for it, apart from a Not For Resale (NFR) demo copy of the VLM to use for the review. What their marketing people didn’t know when they asked me to write about their Load Balancer is that I already recommend KEMP to my customers – in fact I’m implementing another for a new deployment in a couple of weeks time, so I figured.. why not

You can download the demo version of the KEMP LoadMaster here, for the standard version and here for the pre-configured Exchange version.

Steve

Related posts:

1. Exchange Team no longer recommend Windows NLB for Client Access Server Load Balancing
2. New Release – Exchange 2010 Virtual Load Balancer
3. Unified Messaging now supported in a virtual machine with Exchange Server 2010 SP1

Confirmation came from Microsoft PSS that this was an issue, however it’s not something that had been publically documented. After talking to Henrik Walther I was glad to find that I wasn’t the only person out there to have seen this, though, however it’s fair to say it’s unusual that this would be a major issue. Here’s a little more on the problem:

When reviewing or modifying delegate information via Tools>Options and choosing the Delegates tab, Outlook 2003 may exhibit some or all of the following symptoms:

• Choosing the Delegates tab causes Outlook 2003 to stop responding for upwards of 30 seconds to 2 minutes before displaying information.
• When saving delegate information, Outlook 2003 stops responding for upwards of 30 seconds to 2 minutes before closing the Options window.
• The message "Outlook is trying to retrieve data from the Microsoft Exchange Server" pop-up notification is displayed to the user.

You’ll see this in action in the video below:

In previous versions of Exchange Server, the Outlook Client talked directly to a Global Catalog server after a DSProxy referral. In Exchange Server 2010, the Client Access Service runs the Address Book Service which provides the NSPI endpoint that Outlook clients connect to for accessing directory information.

This issue is caused by the method Outlook 2003 requests data from the Address Book Service on the Client Access Server. The issue is corrected in current versions of Outlook 2007 and 2010, but will not be corrected in Outlook 2003.

The workaround to this issue is to limit which users should be delegates on mailboxes, and grant general calender sharing permissions via the following method, which is also applicable to other Outlook folders.

1. Right-click the Calendar folder, and then click Properties.
2. Click the Permissions tab.
3. Click Add.
4. Click the name of the user who you want to grant permissions to, click Add, and then click OK.
5. In the Name box, click the user name, and then choose the permission level, for example Editor in the Permission Level box.
6. Click Apply, and then click OK.

There is a way to force Outlook 2003 to contact a Global Catalog server directly – this was published in the KB article KB319206, How to configure Outlook to a specific global catalog server or to the closest global catalog server. In our customer’s environment, MS suggested it’s use, and theoretically it should be similar to an Exchange client access server running on a AD DC/GC (which is supported). However, given the article says it should never be used in an Exchange 2010 environment I would stay away from it unless specifically advised otherwise by Microsoft.

I’ve updated the TechNet Wiki article Concern: Is Having Outlook 2003 Clients Going to Prevent Me from Deploying Exchange 2010? with this information.

Steve

Related posts:

1. Enabling Outlook 2003 and 2007 to display Exchange GAL photos
2. Managing iCal Calendar Sharing with Exchange 2010 SP1 [Updated]
3. Auto-mapping shared mailboxes in Exchange 2010 SP1 with Outlook 2010 and Outlook 2007