I just wanted to make a note of this because it is easy to do via the Exchange Management Shell but can become problematic through the EMC, especially with a large number of mailbox databases. Essentially what we are looking to do here is change the default warning and prohibit limits that Exchange uses for user mailboxes.
The following command will change the warning size to 7GB and prohibit users the ability to send messages at 8GB.
And we can double check our handy work through the EMC to make sure that we have these properties adjusted properly.
Everything looks good. I should note that there are a number of other really handy things that can be changed via the set-mailboxdatabse cmdlet and the ability to pipe it through get-mailboxdatabase is fairly straight forward, making global changes to your Exchange environment such as this one much quicker and easier to do. There is some good reading here:
I ran into a few minor glitches that weren’t mentioned in other posts when using this method in my own environment. So first I will mention what was different for me, then I will be going over the full set of instructions to use this method. My goal for this post is to be as thorough and unambiguous as possible so there are no questions after reading these instructions.
First, it wasn’t readily apparent what specifically needed to be backed up in the pieces I read. Though, it is quite possible I managed to misread the sections that described them. After some experimentation in our test network I learned that all volumes containing databases and log files need to be backed up. This means that if you have separate drives for logs and databases, both of them need to get backed up, I would have saved a lot of time had I known this beforehand. And, as far as I can tell, both the mailbxes and logs have to be backed up for this method to work, not just one or the other. So just to reiterate this with an example, you have to back both the (L:) and (M:) volumes up.
The other thing that was mentioned in other posts but wasn’t clear cut was the need to change the registry key to disable VSS trasnport replication. It is necessary for Exchange environments using a DAG configuration with both active and passive databases, if this change isn’t the case the backup may work but your logs won’t get truncated. Finally, ensure that you have the Microsof Exchange Server Extension for Windows Backup service started.
Log on to the server by using an account that has local administrator access, and open regedit
Navigate to HKEY_LOCAL_MACHINE\Software\Microsoft\ExchangeServer\v14\Replay\Parameters.
Add a new DWORD value named EnableVSSWriter, and set its value to 0.
Exit Registry Editor and then restart the Microsoft Exchange Replication service.
Okay, now we need to enable the Windows Backup feature (I will leave that to the reader), just make sure not to enable the backup command line tools (they are outdated).
So now you just create your backup job and after everything is all said and done your logs should get truncated, it seems like a lot more work than should be necessary but if your logs don’t get truncated then really bad things happen, so it is a small price to pay I guess to make sure things are working the right way.
That’s pretty much it. Once the backup has completed your log volume should have more room. There are other ways to clear the transaction logs, maybe I will go over them in another post but this method is (for the most part once you figure out what you’re doing) easy and built into Windows. Just make sure you have enough free space somewhere on your network to house the backups, especially if there there is a lot to move.
Sorry for the long boring title, I wasn’t sure what to call this. There are a variety of components to this filtering system so it is hard to classify. It has a MTA built into it, is a spam filter, a mail anti-virus solution, a graphing tool and has a log analysis component.
Alright, so let’s get going. This has been an ongoing project for me at work as I had no prior experience in setting something like this up. The first step for me was determining what sorts of tools were going to work the best for me. We are on a strict budget where I work at so any paid, third party solutions were out of the picture (Postini, GFI Mail Essentials were two that actually showed some promise). Instead I had to take the Open Source route, which it turns out has a multitude of different options, whew!
Enter Spamassassin. This is the main service that I decided to build this system around. It is easy to set up and get running and provides a robust spam filtering system, easy enough. Here is the list of tools that I have put together for this system, based on Ubuntu Server 10.04 LTS with everything but SSH disabled initially:
postfix – mail transfer agent
spamassasin – spam filter
clamAV – anti-virus
amavis-new – interface for postfix -> SA/clamAV
mailgraph – tool to visualize mail statistics
rrdtool – graphing tool for mailgraph to functions
Configuring Postfix:
This piece was confusing to me initially so I hope that this guide will make things a little easier to understand. If there are questions I will do my best to answer them through my own experience with this project.
Ok, the first step is to grab and install Postfix on the new server.
sudo aptitude install postfix
Next, we need to edit the Postfix configuration file /etc/postfix/main.cf to act as the gateway for our Exchange server, these are the settings that I have currently configured for my gateway so you will need to alter yours accordingly.
smtpd_banner = $myhostname ESMTP $mail_name (Ubuntu)
biff = no
# appending .domain is the MUA's job.
append_dot_mydomain = no
# Uncomment the next line to generate "delayed mail" warnings
#delay_warning_time = 4h
readme_directory = no
# TLS parameters
smtpd_tls_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
smtpd_tls_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
smtpd_use_tls=yes
smtpd_tls_session_cache_database = btree:${data_directory}/smtpd_scache
smtp_tls_session_cache_database = btree:${data_directory}/smtp_scache
# See /usr/share/doc/postfix/TLS_README.gz in the postfix-doc package for
# information on enabling SSL in the smtp client.
myhostname = computer.local.domain
mydomain = local.domain
myorigin = $mydomain
inet_interfaces = all
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
#mydestination = localhost, localhost.local.domain
mydestination = mail.site.com, site.com, localhost
relay_domains = site.com
relayhost =
mynetworks = 192.168.1.0/24 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128
mailbox_size_limit = 0
recipient_delimiter = +
transport_maps = hash:/etc/postfix/transport
append_at_myorigin = no
local_recipient_maps =
smtpd_helo_required = yes
smtpd_recipient_restrictions =
permit_mynetworks reject_unauth_destination
# Content filtering
content_filter = smtp-amavis:[127.0.0.1]:10024
Now we need to configure Postfix to relay mail through our filter to our Exchange server. To do this we need to make sure our domain is the only place email gets forwarded to. Add this line to the file /etc/postfix/transport
site.com smtp:[192.168.1.69]
This maps our external site “site.com” to our Exchange server living comfortably inside the network. Finally, build the hash table for Postfix to use to forward mail
postmap /etc/postfix/transport
and then restart Postfix to update all of the new settings
sudo /etc/init.d/postfix restart
Configuring the Spam Filter:
Ok, so once everything is updated and you have configured postfix the way you want it, you should be able to start the installation/configuration process.
To get these new settings to work (figured this out the hard way) we need to restart the amavis and clamAV services.
sudo /etc/init.d/clamav-daemon restart
Next, we need to enable virus scanning in amavis by editing /etc/amavis/conf.d/15-content_filter_mode and uncommenting the following lines in the configuration:
Finally, we need to restart the postfix service to update the changes.
sudo /etc/init.d/postfix restart
Everything should be ready to go. If you have a port forward pointing to your Exchange server on your firewall, now is the time to point the port forward to the new address. Now we are ready to go!
Graphing Statistics
Now that everything is set up we will want a way to see what kind of work our new system is doing. For a graphical representation we will use a tool called mailgraph to give us results in a nice pretty format. To get started we will need to grab it and put it on our server.
sudo aptitude install rrdtool mailgraph
This should take care of most everything, but we want to be able to take a look at the results locally on our network in a browser
