Exchange Message Archive Management

You remember Steve, right? That’s Steve from Sales, the guy who absolutely needed access to an email that he deleted over a year ago. You probably clearly remember the hassles of having to first find and then restore his mailbox. Perhaps you even recall sifting through his messages, trying to find that single, solitary email, and dedicating a whole afternoon to the process. Not exactly a fun experience, regardless of which way you cut it.

Thankfully, things don’t have to be this way. While there’s no question that the need to store and retrieve old email messages is necessary, there are much simpler ways to go about the process if your organization is running Exchange Server 2000 or 2003. I’m talking about a product called GFI MailArchiver, an message archiving solution that makes searching through internal and external email as simple as firing up your web browser and searching for the message in question.

How it works

Without a solution like GFI MailArchiver, digging up old email messages is usually a long and arduous process that involves restoring old mailboxes and searching through messages manually. While there’s no question that different techniques exist to speed up the process, most are involved and cumbersome to say the least.

Anti-Spam and Mail Monitoring with GFI MailEssentials 8

Striking a balance between securing network resources and ensuring that users have the tools they need to do their job presents a difficult quandary for IT managers and network administrators alike. If your network is like most, your users are likely inundated with almost unmanageable levels of junk email. Spam is not only intrusive and annoying, but also costly in terms of server storage space and user time. On the flipside, providing users with access to email also comes with a security risk in that it provides a facility by which users can easily forward data to other users or even customers, be it sensitive corporate information or simply inappropriate content. Quite simply, companies need the ability to both monitor and manage email resources as necessary for both legal and/or security reasons more than ever before.

Out of the box, most email server products provide limited monitoring, security, and anti-spam functions. In those that do, the feature set tends to be weak and seemingly implemented as an afterthought. However, the new GFI MailEssentials 8 product from GFI Software not only provides the most comprehensive anti-spam capabilities currently available, but also industrial-strength mail monitoring, the ability to add disclaimers to all outgoing messages, and more. Impressively, GFI provides many of the products best features as freeware, making GFI MailEssentials 8 a must-evaluate product for administrators of both large and small networks alike.

Using SSL with Outlook Web Access

One of the most frequent questions I see posted to both the 2000trainers.com newsgroup and the Microsoft public newsgroups is about setting up OWA (Outlook Web Access) to use SSL for security. This is especially important in a scenario where you are using a Front-end/Back-end configuration as Front-end servers only support basic authentication. This might not seem like a big deal at first, but when you realize that this means that information is being sent across the wire in an unencrypted format, you can see how important this becomes. Some administrators also want to be able to *force* users to a secure connection, rather than manually requiring them to type it in. Finally, a lot of folks want to use the functionality included with OWA that allows you to change a users domain password. We are also going to cover all of this, but be aware that this last step does require you to use SSL on your OWA server. Having said all that we will begin by actually enabling SSL on the Exchange Virtual Server. In order to do this, I used a digital certificate from my own CA that I installed into my network. You can get your certificate from a local CA or from any of the CA’s that exist out on the internet. Where the digital certificate comes from isn’t important. Installing it into the Exchange Virtual Server to enable SSL for OWA is what is important to us. We start by going into the Default Virtual Web Server through Internet Services Manager, as you can see in Figure 1.

Next up we go into the properties of the Default Web Server, as you can see in Figure 2.

From there, we go to the Directory Security Tab and select to install a new digital certificate. This launches the certificate wizard as you can see in Figure 3.Once you have stepped through the wizard you should be able to go in and view the properties of the new digital certificate that you have installed as you can see from Figure 4. If you would like an actual walk through of the Certificate Wizard you can find it here.

GFI FAXmaker for Exchange

In a world where email has changed the way both individuals and companies communicate with one another, it’s easy to forget that only a few years ago, faxing was the accepted worldwide standard for the timely transmission and reception of just about any document. While the use of email to transfer documents continues to grow in popularity, the use of faxing isn’t going to end any time soon, since much of the world still relies upon faxes for the transfer of critical information. Although the Internet is changing the ways that companies look at communicating with both their customers and suppliers, faxing still represents a secure, convenient, and ubiquitous technology that almost all companies worldwide accept and make use of.

Although a popular communication mechanism, most companies still rely on traditional manual faxing using a dedicated fax machine. While still acceptable in cases where a company rarely or very sporadically requires the ability to send or receive faxes, the manual fax machine is clearly out of date in any environment that regularly relies on fax communication. The main issue with manual faxing is the need for individuals to literally get up, walk to the fax machine, wait for their fax to send, and then return to what they were doing – just to send a single document. Furthermore, the user sending the fax needs to look up the recipient’s fax number, possibly create cover pages, and more. On the receiving end, time is wasted with the sorting and manual routing of faxes, which can easily be lost, forgotten, or otherwise not received in a timely manner. At the end of the day, manual faxing leads to only two sure things – lost productivity, and by extension, wasted money.

Exchange 2000 Address Lists and Views

Aright, now that the summer is over, I guess that it is time to get back to work and start writing articles again on a somewhat regular basis. The topic for this particular article is going to be address list views and is in part inspired by a question posted by one of our newsgroup readers. The reader was looking for a way to create a new address list, but set it up so that only specific users would be able to access it. Well, that is exactly what we are going to do here today, so lets go ahead and jump right into it! Our first screen shot is taken from within Outlook, showing the different address lists that are configured and accessible by our clients. What I am going to do is a two step process. First, I will go ahead and create a new address list and show how that is done. We will then verify that the address list is visible and accessible to the Outlook users by logging in and trying to access some information from within the address list. Then, I will go ahead and hide that address list from view so that only specific users with the appropriate permissions will have the ability to connect to or even see the particular address list in question. Sound fun? Well let’s give it a whirl then! The first thing I want to point out is the default address lists that are visible from within Outlook 2000. As you can see from the figure below, there is nothing out of the ordinary here, although I do already have one custom address list that I created called Demo. (ok, so there is something out of the ordinary!)

Figure

Now the first thing that I do is go to the machine that is running the ESM, and I open up Recipients, and then All Address Lists. This should display the different address lists that have been created or are created by default upon installation of Exchange 2000. You can see the list in Figure 2.

Figure

Exchange, DNS, and Internet Email

As most of you know, I haven’t been churning out the articles lately. I am in a little bit of a slump, and decided to do a light article this week to help me get back into the swing of things. I decided that one of the best places to start would be with one of the most frequent problems I see people having with Exchange 2000. The question that I probably see the most relates to setting up Exchange 2000 to access the internet. What I am going to talk about in this article is how to setup DNS to allow your Exchange 2000 server to access the internet, as well as how to use Nslookup to troubleshoot DNS settings. Obviously, I can’t cover all possible configurations, but I am going to try and cover the most basic configuration.

I am going to go with the understanding that most of you already have your Exchange Server installations completed. If not, then this isn’t the article that will cover that. For installing Exchange, take a look at one of my earlier articles. Now once you have Exchange 2000 installed, there isn’t much else you need to do on the Exchange side. Exchange is tightly integrated with Active Directory, but more importantly, it is very tightly integrated with IIS as well. This integration allows Exchange 2000 to connect to the internet without requiring any connectors to be installed or configured. This one is a little different, because previous versions of Exchange required a connector of some type to be configured. For example, Exchange 5.5 required an Internet Mail Service Connector (IMS) in order to access the internet.

Now there are a couple of different ways that we could configure DNS for our Exchange 2000 server. For example, I might be running DSL, with a firewall like Proxy 2.0 or ISA Server in place. This would mean that we would have a public IP on the external network card of the firewall. Now, if we were running our own DNS server, we could simply put the appropriate Host (A) and Mail Exchanger (MX) records into our DNS database. Now, when a client queried our DNS server, the record for our Exchange 2000 server would be returned, and the client would be able to communicate with our server. This is a simple configuration from the standpoint of DNS, although it would require additional work in order to get the Exchange Server communicating from behind the firewall. For additional information on how to configure this, see Q276388 and Q308599.

However, judging from the questions that I am getting, the majority of you aren’t setting up your servers in this type of environment. The majority of the questions that I am seeing are centered around small companies that are running a single Exchange 2000 server, and running their own DNS servers for internal purposes, but using an ISP for external name resolution. Although this situation is a little more complicated than our previous example, it is by no means impossible. Probably the biggest problem facing most people is a lack of understanding on how DNS works. For this, I recommend reading DNS and BIND, by Paul Albitz and Cricket Liu. You can find this book just about any place that sells books on technology. Another good resource would be the Windows 2000 help files, as well as the Windows 2000 Resource Kit.

Now lets get back to our problem. We have our Exchange 2000 Server installed, we have our internal DNS working, taking care of Active Directory and all its needs. So how do we configure it to allow our internal clients to be able to send email out to the internet, and also to allow internet users to send email to our internal users?

The first thing that we need to take a look at is how do we get our email out to the internet? In this case, setting up our internal DNS server to forward requests that it can’t handle to our ISP’s DNS server should do the trick. So what I would need to do would be to go into the DNS MMC, right click on the DNS server object, and go to properties, and then select the Forwarders tab. I would type in the address or addresses of my ISP’s DNS server(s), clicking add after each one. Now my DNS server will simply send requests that it can’t resolve out to my ISP’s DNS Server. This will allow my clients to get their email out to the internet, but at this point, I am only halfway done. I still need some way to give users access to my Exchange server. The trick here is that my Exchange server is running on my internal network, probably running on a Private IP address. So let’s take a look at how we can accomplish this task.

As a first step, we have to add the appropriate MX and A records to our ISP’s DNS Server. In this case, the records would point to the public IP for our company, typically the external interface of our firewall. Now, we would need to use something like Network Address Translation (NAT) in order to convert the incoming request and redirect it to our Exchange server. In my earlier example using ISA server, publishing Exchange from behind the ISA server allows you to accomplish this task with a minimal of effort, because ISA will forward the requests for Exchange to the appropriate address, allowing external clients access to our internal Exchange server.

Given that we have configured everything correctly, our internal clients should be capable if sending and receiving both internal and internet email. But how do we know that we setup DNS correctly? Enter Nslookup. Nslookup is a troubleshooting utility that allows us to query a DNS database for the presence of appropriate records, amongst other things. Now, for internal DNS, we can simply open up the DNS MMC console and verify that we have correctly configured the Forward and Reverse Lookup Zones. This is easy enough, because we are in charge of these zones, we manage, create and delete them. But what about our ISP’s DNS database? How do you know that they have correctly configured your A and MX records. The answer would be to do a simple query of their DNS database using Nslookup. From Windows NT 4.0, 2000, and XP, simply drop to a command prompt and type in Nslookup

Once you hit enter, you can now query the DNS database. In my case, I have typed in that I am looking for an MX record. The second option tells the Nslookup utility what domain name I am looking for. In this case, it is my business domain, Bellcs.com. The screen would look like this;

Figure

You can also see from looking at the second screen shot that I am querying my ISP’s DNS server, which is 4.2.2.2. However, this ISP isn’t authoritative for this particular domain name, as you can see from the reply that has been returned. It does show that I do have a configured Mail Server, as well as the Name Servers for my domain.

So this is how I can see what is in my ISP’s DNS database, without having access to the physical DNS server. Obviously, there is a lot more to Nslookup than what I have shown here. For more information about this utility, simply type Nslookup and press Enter. Then type help and press Enter. You can also lookup Nslookup in Windows 2000 Help, or online at Technet.

That should just about do it for now. Hopefully this helps to shed some light on configuring your Exchange 2000 servers to access the internet, as well as the DNS settings necessary to make it work. Next week we will get back to our regular series, starting with a new Exchange 2000 article. Until next time, cya!

Creating Address Lists in Exchange 2000

In my last article, I had mentioned that we would be talking about Address lists the next time that we talked. Lets go ahead and take a look at the default address lists created in Exchange 2000, and how to create new address lists as well. The first thing that I want to cover is the default address lists that exist in Exchange 2000.

Figure

What I have done is opened the Exchange System Manager (ESM). I opened up Recipients, and then All Address Lists. The first thing that I would note, and one of the things that most people immediately question, is why you can’t see the actual addresses when you highlight one of the default address lists, like so;

Figure

This is by design. In Exchange 2000, unlike previous versions of Exchange, we are using LDAP (Lightweight Directory Access Protocol) filters to create the address list. In order to see what addresses fall under a particular address list, you must right-click on the address list in question, and select properties. From the General tab, select the Preview button, and the addresses that display will be the appropriate addresses for the particular address list in question.

Figure

Figure

As you can see, the first screen shot is the actual LDAP filter that is used to define the recipients in question. In this case, I have selected the All Users address list. The point of my showing the LDAP filter is not to get into an in-depth discussion on LDAP, but rather to illustrate what an LDAP filter looks like. For more information on LDAP, you can look here. Also, RFCs #1777 and #1960 can give you a good jump on what LDAP is and how to use it in your network. Having said that, we have uncovered one of the mysteries of address lists in Exchange 2000!! If you have been working with Microsoft Windows 2000 for a while now, one of the things that you have probably realized is that there have been many changes to the interface. The same thing holds true for Exchange 2000, and address lists are a great example of how things have changed from previous versions of Exchange. What I am going to do is create a sample address list to give you some ideas on how to create one. Keep in mind that there are many different options for creating address lists, and this article simply means to serve as a starter, so to speak, for some of the different things that we can do. In order to create an address list, we right-click on All Address lists, and select New, and then Address list, like so;

Figure

Next, we provide a name for our address list, and then we have to define the filter that we will be using for this particular address list. In my case, I have named my new Address list Demo, and the filter that I have defined filters my users based on their Department, specifically the Marketing Department. The next graphic shows the default Filter that appears when you click on the filter button;

Figure

What I am going to do is modify the default filter to only apply to Exchange Users and Contacts, and the only field that I am interested in is the Department field. Again, the only users that I want to have appear are those in the Marketing Department. The filter will look something like this;

Figure

On the advanced tab, I select Users, and then select Department as my field of interest. I select “Is Exactly” and then Marketing. I click on Add, and then Ok. I have now defined my new LDAP filter that will list only users in the Marketing Department. Now, let’s make certain that we understand the practical application of this. If I had a very large company with users all over the world, my company address list (aka, the All Users List) could grow quite large. Instead of requiring my users to go through thousands of users names and address lists, I could create an address list similar to the one that I have just defined, and it would only show users from the Marketing Department. This would make it easier for users in the Marketing Department to locate users anywhere in the world, because the Marketing users are a small subset of all the users in the organization. This could be repeated numerous times, until we had defined all the appropriate address lists we needed for our organization. Having said that, if we go into the properties of our new address list, and click on the Preview button (on the General Tab), we should see something like this;

Figure

Not quite the scenario that I described a moment ago, but it definitely helps to illustrate the concept involved! One thing that I should point out is that once you actually create your new Address list, there could be a delay between the time you create the list, and the time that it takes for your recipients to show up in the list. The Recipient Update Service (RUS) is responsible for updating this information, so that would be the point to start troubleshooting from should you have problems getting the list to update. For some additional information on working with Address lists in Exchange 2000, take a look at Q319213. Also, take a look at Q253828 for information on how the RUS works to update address lists in Exchange 2000. Anyway, that about wraps it up for today. Normally, I give you a hint about what my next article will be on, but that will not be the case this time around. All I can tell you is that I will be back next time with another article discussing working with Exchange 2000. Until then, cya!!

Securing Mail Servers with GFI Mail Security for Exchange/SMTP

Implementing network security is like trying to chase a moving target at the best of times. Some companies spend tens of thousands of dollars per year reactively trying to solve problems as they occur. If you had the unfortunate experience of having to react to the Klez worm or the Love Bug virus, you certainly understand what I’m talking about. The days where you could rely on updated desktop virus definitions alone are unfortunately long gone. Securing a network is a constantly evolving challenge. Where most companies today would consider it incomprehensible to not have a properly configured firewall, many of these same companies still overlook the single biggest source of their problems – their email systems.

As the Love Bug virus showed, companies also still rely on their users to exercise good judgment when it comes to dealing with things like potentially malicious attachments. Disabling VBScript on their systems may be a great first step, but what’s your plan for dealing with HTML emails that include embedded ActiveX controls? With 25 critical security updates already released by Microsoft this year, the need for centralized email security has never been clearer. Instead of spending your precious hours trying to fix the security leaks that have already entered your network, secure the source – the free-for-all known as your mail server.

If your company is running Exchange 2000, one product definitely worth a look is GFI Software’s GFI MailSecurity for Exchange/SMTP. Not only does this application provide you with complete control of incoming, outgoing, and internal mail, but it also does so in a manner completely transparent to users. MailSecurity is much more than just virus-checking software. The list below outlines some of the capabilities that we’ll explore further in this article.

  • Content and Attachment Checking. MailSecurity provides the ability to scan email messages that include specific words or attachments. Whether you’re looking to ensure that messages containing VBScript attachments are blocked, trying to filter spam, or want to stop certain users from sending or receiving attachments at all, this feature is a must-have.
  • Quarantining. Emails that include checked content, attachments, or viruses can be quarantined. Quarantined messages can then be sent to an administrator, a user’s manager, or even a mail-enabled Exchange public folder, prior to being manually approved or rejected. You also have the option of automatically deleting emails that meet the conditions of the rules you’ve specified.
  • Virus Scanning. MailSecurity can also scan all incoming, outgoing, and even internal attachments for viruses. Not to be outdone, the program uses two virus-checking engines by default – Norman Virus Control and BitDefender. If two virus engines are still not enough, you have the option of adding the McAfee engine as well.
  • Email Exploit Engine. If you think that it’s only email attachments that you need to worry about, think again. Over the course of the last few months, some of the most serious problems to work their way into the enterprise are those associated with active content or scripting, via HTML emails. MailSecurity protects against these types of exploits as well, using their industry-first email exploit engine.

Whether you’re looking to secure your mail server or a way to control what your users can do with their email, MailSecurity has something to offer. You hopefully already have a firewall. It’s time to consider something similar for your mail server.

The installation of MailSecurity requires Windows 2000 Service Pack 1. It also requires Exchange 2000 Service Pack 1 to take advantages of Microsoft’s new Virus Scanning API (VS API). VS API allows messages to be scanned within the Exchange message store, ensuring that scanning occurs before a user’s mail client accesses a potentially malicious attachment. The VS API is also much more efficient in how it deals with attachments – if sent to multiple users, it will only be scanned once prior to delivery, rather than multiple times according to the number of recipients.

The installation of MailSecurity is exceptionally straightforward and not worth exploring in detail. Once installed, MailSecurity is managed using the MailSecurity Configuration tool, which is implemented as an MMC snap-in. The interface of the console is shown below.

Figure

Content and Attachment Checking

GFI MailSecurity provides you with the ability to “police” your mail server by controlling both the content of email messages and the associated attachments that are allowed to pass through. For example, it’s generally a good idea to block potentially malicious attachments like .exe, .vbs, and .js files. MailSecurity takes care of all three (and more) in the default attachment-checking rule that we’ll look at shortly.

Content checking rules allow you to control the types of messages that can be sent or received on your mail server according to the words they contain. For example, you might choose to create rules that search messages for profanity, or common spam keywords. Not only is MailSecurity capable of searching for these words in the body of a message and subject line, but also in attachments if so configured. Consider the options shown on the screen below.

Figure

Once a rule has been specified, you need to associate it with an action, and optionally a group of users. Consider the screen shot below, which shows the Action tab for my new rule that checks all messages for the words “racist” or “university diploma”. The top of the page allows me to block the message and perform an action. Possible actions include quarantining the message, deleting the message, or moving it to a folder. Another course of action would be to specify multiple rules, which could then have different actions associated with them, or apply to different users. For example, you might delete messages considered spam immediately.

Figure

Notice the option to inform a manager. If you’ve ever looked at the properties of a user account in Active Directory, your may have noticed that you have the ability to configure the manager of a user within the properties of an account. In cases where this option is selected and the rule is matched, MailSecurity will query Active Directory, find the manager associated with a user, and forward the message to the manager, allowing them to approve or reject the message. If approved, the message will be sent. If rejected, the message is deleted. In cases where the Manager attribute is not set in a user’s account, the message will be sent to the configured administrator.

After specifying an action, you can use the Users/Folders tab to control to whom this rule will apply. By default, a rule will apply to all users. For a more granular level of control, you can select the individual users to whom the rule should apply.

Figure

Attachment checking rules are something that every company will want to implement. The default attachment checking rule is set to deny commonly malicious attachments, such as those shown in the list below.

Notice that inbound, outbound, and internal emails can be selected as checking options. Select inbound to check attachments that originate from outside of your organization. Outbound attachments are those sent from users found in Active Directory to outside persons. Internal checking is used to check attachments sent to and from users within your organization. Remember that not all malicious code originates from the outside world. Ensuring that your users are not purposely or inadvertently sending potentially harmful attachments to others should also be a primary consideration. The actions associated with attachment rules are similar to those seen earlier with content checking. Users who are to be impacted by the rule can similarly be specified.

MailSecurity is also a great tool for retaking control of your Exchange server. Every company has users who waste significant server resources in sending and receiving personal attachments like jokes, MP3 files, or similar. You can use MailSecurity to block these attachments, for all users or a subset thereof. Trying to circumvent the rule by renaming the extensions of files won’t work either – MailSecurity is capable of detecting files with renamed extensions.

Quarantining

After first installing MailSecurity, consider quarantining messages that have been filtered by the content and attachment checking rules, rather than deleting them outright. Quarantining gives you the opportunity to manually approve or reject messages that have been filtered.