With the release of official support for Exchange 2010 and BES 5.0, I thought I would have another crack at getting Exchange 2010 to work directly with BES 4.1. This is instead of using an Exchange 2007 server somewhere in the mix.
I used Blackberry Professional Server in my testing, installed on Windows 2003 separate to Exchange 2010.
To my surprise, I have managed to get it working - with no interim servers used. A clean Exchange 2010 installation was used, along with BPS 4.1.3A (so not even the latest version).
In addition to the regular installation of the Blackberry Server software (so logged in to the machine as besadmin etc), to get things to work I had to do the following.
- Install Exchange 2010 rollup 1 on the Exchange server.
- Install the latest version of the CDO on the Blackberry server.
- Set more permissions than normal (see below)
The server I was using also had a public folder store created and mounted. I have not tested it with Exchange 2010 without Public Folders.
During the installation there was an error about being unable to verify the permissions, which I ignored.
Tested Functionality
I have tested the following:
- Full over the air Enterprise activation.
- Sending and receiving email from the device.
- Lookup against the GAL and the personal address book
- Adding a task from the Blackberry and seeing sync to the account.
- Adding a task from OWA and seeing it sync to the Blackberry
- Adding a calendar entry from the Blackberry and seeing sync to account.
- Adding a calendar entry from OWA seeing it sync to the Blackberry
Of course functionality that doesn't require Exchange - such as Blackberry Browser access to the intranet continues to work correctly.
Permissions
To get things to work, I had to set additional permissions. This may well be related to the change in the database model, which is now at the Org level rather than the server level.
Exchange 2010 View Only Exchange Admin.
This permission is no more, so the equivalent has to be set:
Add-RoleGroupMember "View-Only Organization Management" -member besadmin
Store / Server level permissions
The usual permissions used with Exchange 2007 set via the following command didn't appear to work:
get-mailboxserver | add-adpermission –user BESAdmin –accessrights ExtendedRight –extendedrights Send-As, Receive-As, ms-Exch-Store-Admin
I had to grant the permissions at the database level:
Get-MailboxDatabase |add-adpermission -user besadmin -accessrights ExtendedRight -extendedrights Receive-As, Send-As, ms-exch-store-admin
Get-PublicFolderDatabase |add-adpermission -user besadmin -accessrights ExtendedRight -extendedrights Receive-As, Send-As, ms-exch-store-admin
As the permission is being granted at the mailbox database level, if databases are changed/added/removed then the permission will need to be run again.
As always, the permission didn't take effect immediately, therefore I restarted the information store and the Blackberry services to get things to take effect.
CDO Installation
The latest version of CDO was used, which can be downloaded (At the time of writing) from this location:
http://www.microsoft.com/downloads/details.aspx?FamilyID=e17e7f31-079a-43a9-bff2-0a110307611e&DisplayLang=en
At last Microsoft have released the installation tool for Exchange 2007 SP2 on SBS 2008.
Looks fairly straight forward to use, download the service pack as normal, download the tool and then run the tool.
You can get more information about the tool and download it from this KB article: http://support.microsoft.com/?kbid=974271
Exchange 2007 has been rock solid in my experience and if you were put off installing it on your SBS 2008 machine because this tool wasn't released, now is your chance.
I am pleased to announce that the domain exbpa.com has been saved for the Exchange community.
This was a domain that Microsoft first used a few years ago to point to their (at the time) recently released Exchange Best Practises Analyser. There are thousands of links to this domain across the internet as well as in books and magazines.
However Microsoft recently decided to allow the domain to lapse and early this morning it was finally deleted.
Fortunately I was able to register it myself through my consultancy company Sembee Ltd and therefore kept it out of the hands of a domain squatter.
I have uploaded a slightly modified version of the list of Exchange resources that I maintain at Daniel Petri's forum, which as well as the links to the Exchange Best Practises Analyzer, also contains links to other Microsoft tools, blogs etc.
http://exbpa.com/
While it is not the best designed web site in the world, it does the job. Hopefully the Exchange community will find it of some use.
When I am working with clients and their Blackberry devices, particularly on new deployments, one of the issues I frequently have is discovering whether the device is enabled for the BES use. It is very common for the service providers to NOT enable the Blackberry device for BES correctly. As anyone who has dealt with mobile phone provider support, when it comes to Blackberry, most of them haven't got a clue.
For some time I have been aware that RIM have a tool available to people with a support contract which allows you to query their database, but none of my clients have a support contract. I actually considered getting a contract just to get access to that database!
However I discovered that recently RIM have released a new web tool, which is free to register and use, which allows you to check the status of the device. In RIM speak "Enterprise Activation Readiness".
It is free for all users of Blackberry Professional Server, Enterprise Server, Server Express and all the other names they have used for their software in the past. All you need is your identifier and CAL key for the server.
You also get a complimentary support incident which is also another good reason for signing up.
From the site itself:
"The BlackBerry Expert Support Center is a Web 2.0 application, which is designed to allow direct access to Enterprise grade tools and resources, and to give you the ability to manage your Technical support agreement and support related inquiries easily and independently.
- One Complimentary Support Incident to receive expert advice from a member of the BlackBerry Technical Support team at any time
- Online self service tools and resources designed to help with installation and ongoing management of your BlackBerry solution including step-by-step demonstrations
- All the relevant guides, articles and other resources to increase your BlackBerry solution know-how "
https://www.blackberry.com/besc/dashboard/
I have mentioned before the results I have received from Vamsoft ORF in the past, most recently using they honey pot feature http://blog.sembee.co.uk/archive/2009/09/26/108.aspx.
However recently I deployed the product with another client and the results are truly spectacular.
The client has approximately 300 users, and they noticed the results almost immediately.
It was deployed as I have written in the above blog posting, so running in test only for a day or two to build up a white list to begin with then it went live.
The proof is in the numbers, so here is a screenshot of the statistics. At the time this was taken, the system had been running for almost 12 days.
For those of you not believing their eyes, that is 8.8 million messages were attempted to be delivered.
Roughly 700,000 messages a day.
Of which 60,000 were not spam, so around 5,000 a day or 16 per user on average.
The spam ratio hovers at between 99% and 100% (there is some rounding going on there as it is to the nearest full percentage point).
The logs have been watched very carefully for false positives. There have been none.
So lets just go through what is working with that client.
First is DHA protection. Direct Harvest Attack. This is simply a large number of email messages coming from the same IP address to multiple email addresses in a short space of time. For some reason this client receives a lot of messages to invalid recipients. The software blocks the host from sending more messages. It works hand in hand with the honey pot test and recipient validation.
Next is the Honey pot test. I have talked about that before (link above), but in brief it is blocking hosts sending to known non-valid recipients. This feature is simply the most effective thing I have seen against spam for a long time.
Third is recipient validation. Dropping email that is simply sent to users who do not exist. This is a straight query against the AD.
A DNS blacklist is being used - Spamhaus ZEN, but it is only blocking a small percentage of email.
What the screenshot doesn't show is that the built in Exchange 2007 Content Filtering is also enabled, but the number of messages being received in to the quarantine mailbox is a handful a day.
We are not using Greylisting, reverse DNS or the SPF tests.
In short - the three tests that are getting the most results are based on two factors - non-valid recipients and blocking hosts that are sending to them.
The messages are blocked at the point of delivery, therefore the amount of bandwidth used is negligible. The messages do not come in and have to be processed by Exchange, scanned by AV and anti spam software
Due to the volume of email and the number of queries, this system will most likely be moved to an SQL backed database and the load on the domain controller that is used is being watched carefully and the hardware of the DC increased if required.
If you haven't had a chance to try Vamsoft ORF, then I suggest that you do. The impact can be almost immediate. It is priced per server and because it is based on host and recipients, no definition files to be updated.
Works with all versions of Exchange, including Exchange 2010.
Vamsoft ORF: http://www.shareit.com/product.html?productid=169362&affiliateid=200023740
Starting to see lots of questions on forums about setting up a hosted Exchange 2010 system.
Well to be supported, you are going to have to wait 12 months.
"Hosting in Exchange 2010 will be supported approximately twelve months after the release of Exchange 2010."
http://www.microsoft.com/hosting/solutions/hostedmessaging.mspx
Interesting little snippet posted on the RIM web site today.
"October 20, 2009 - Research In Motion (RIM) is pleased to notify you that we are working in close collaboration with Microsoft on compatibility and support for BlackBerry® Enterprise Server for Microsoft® Exchange Server 2010. Compatibility is expected later this year. BlackBerry® Technical Support Services for BlackBerry Enterprise Server for Microsoft Exchange Server 2010 is expected within 30 days following the global availability of Microsoft Exchange Server 2010."
http://na.blackberry.com/eng/support/software/server_compatibility.jsp#tab_tab_news
No doubt that will mean BES only, as the Blackberry Professional version seems to be ignored. Looks like I will be giving up my Blackberry when I move across to Exchange 2010 shortly.
A common question that keeps coming up on forums and similar sites is "What is the best anti spam solution?"
Unfortunately there is no single answer to this question.
I usually respond with something like "What is the best car, best house, best wife?"
The only answer is that the best product is the one that works for you.
On most forums, most of the posters will have experience with one or two products, so will post that product X has worked well for them.
Someone else may well post and say that product X sucked and product Y was the best solution. Then another person will say, don't bother with a product, outsource it to service Z.
On my home network I have had good experience with Vamsoft ORF, but when I tried it on another site it was unsuccessful. I also tried GFI Mail Essentials at home, found it's performance wasn't great for me. However at another client it has been very successful.
When it comes to looking at antispam solutions, the key metric should not be how much spam does it remove, but how much legitimate email it blocks. If the product is stopping email you want from being delivered, then you need to look at a different product.
I have personal experience with this with a client a few years ago.
The client was a large finance company. They did loans and mortgages through brokers, many of whom used AOL and similar accounts. (It will surprise you how many of the very small businesses like one man band brokers still do).
They have a requirement for zero false positives - because a single false positive could mean the loss of many thousands of pounds of business.
We evaluated every product on the market, from open source to high end commercial and out sourced solutions. The requirement was very strict - and every product failed because they were all blocking one or two messages a week that were legitimate.
It actually reached the point where we started to put a plan together to hire IT contractors whose sole responsibility was to go through the quarantine email manually, as it was worked out that they would only have to save one email every six months to make it worth while to the company. However in the end, one of the out sourced providers built a custom solution for them so that the management could be handed off.
The point I am trying to get across is that asking people what works for them and then using that for a buying decision isn't really a good idea. It does not allow you to bypass the evaluation period. Everyone knows that users don't like spam and no doubt as the administrator of the server you will be under pressure to find a solution that works. However purchasing in haste may actually end up costing your company money.
Most of the major products have evaluation versions you can download. Install them and run them in report only mode. See what it would catch. If you decide to start block messages, then quarantine them first so you can check for false positives.
You could find that the product that someone posts saying "We tried product X and it didn't catch a thing" actually works very well for you.
Blacklisting.
For some email administrators Blacklists are the greatest weapon against spam. It cannot be denied that they can have a significant effect on the amount of email that your server has to process, and they do meet the primary objective of spam detection - dealing with the email at the point of delivery, therefore reducing back scatter. They are also free, and once setup require little to no maintenance by the administrator.
However personally I dislike blacklists. I don't like the idea of someone else (either human or computer) deciding on what email I should receive, based on lists and reports that I have no control over.
Furthermore, from a business perspective, using a blacklist may cause potential clients to be rejected, as one of my specialism's is the cleanup of servers that have been abused and are likely to be blacklisted.
However, if I could blacklist IP addresses that I know are trying to send spam to me, in real time, where I have complete control over all aspects of the filter, then that could be something of use. A new feature in Vamsoft ORF has introduced exactly that, and has actually got to the point where I have turned off the antispam features in Exchange.
I have written about Vamsoft ORF before, using it for Greylisting (http://blog.sembee.co.uk/archive/2006/09/18/24.aspx) and as part of an SMTP gateway configuration (http://www.amset.info/exchange/gateway.asp).
With the latest version at the time of writing, 4.3, they have introduced a feature called Honey Pot. The simple way that this works is to block IP addresses that attempt to send email to addresses in the Honey Pot list.
In the Vamsoft setup guide it gives you some ideas on how to publish the honey pot addresses, however I found that I didn't need to publish anything.
Going through logs on my backup SMTP gateway, which does recipient validation through Vamsoft rather than Exchange, I noticed that the same non-valid addresses were being used time and time again. These were addresses that I had NEVER used, would never be likely to.
IMPORTANT: The use of addresses that have never been used is the key here. Adding addresses that were in use will provide you with false positives, because that could be legitimate email. If you decide to follow this practise then ensure that you only use addresses that have NEVER been used.
Therefore what I did was turn off recipient validation on my primary SMTP point of entry and configured that function to be done by Vamsoft ORF. This allowed me to see the addresses that were being sent to on that server as well. I was then able to compile a list to use as my honey pot.
I review the logs frequently to see if new email addresses are being tried, which can be added to the list of honey pot addresses.
This means I am using three tests for spam - recipient validation (which should be something that every site does) greylisting, and honey pot.
The effect was significant. I have been using this setup for a number of weeks and the amount of spam I am seeing in my mailbox or caught by IMF (so got through the initial greylisting and honey pot) is almost zero. One or two messages a week. I have actually now turned off IMF on my Exchange servers.
Why is this being so effective?
The simple reason this is being so effective is that the spammer's list of email addresses will contain a mixture of valid and invalid addresses. As soon as the spammer's server attempts to send an email to a non-valid address that is on my honey pot list, it is blacklisted. Even if that IP address subsequently tries to send to a valid address it will be blocked.
Combined with greylisting, which sends away the initial connection, the even if a legitimate address is used first, the spam doesn't get though. The first attempt is greylisted, then if the list of email addresses contains one of the bogus ones, then it gets blocked. The server attempts to deliver again after greylisting and its connection is blocked.
I also think this is more effective than regular blacklisting because it is in real time and is based on email received by my servers.
I have combined this with an SQL backed database for Vamsoft ORF so that both of my SMTP gateways share the same information, meaning that a blacklisting that is set by one server, is also used by the other.
Finally, I have also combined this with custom NDR text, that points people to a special page on my web site. This page explains what is happening, and other ways to contact me. If required, I can then white list to allow the legitimate messages through and take the spam hit for a short time.
Vamsoft ORF: http://www.shareit.com/product.html?productid=169362&affiliateid=200023740
Exchange 2007 SP2 has been released at last.
You can download it from here: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=4c4bd2a3-5e50-42b0-8bbb-2cc9afe3216a
The service pack is so large because it is the complete installation files. You can install a new server using this download only.
Release Notes are : http://download.microsoft.com/download/8/3/E/83E9DB24-0041-4F7E-A0DD-26043BBF7CAA/RelNotes.htm
The what is new document is here: http://technet.microsoft.com/en-us/library/ee221150.aspx
This update required Windows Installer 4.5 which you can download from here: http://www.microsoft.com/downloads/details.aspx?FamilyId=5A58B56F-60B6-4412-95B9-54D056D6F9F4&displaylang=en
If you using Exchange 2007 as part of SBS 2008, then you should take note of this blog posting from the SBS Team: http://blogs.technet.com/sbs/archive/2009/07/30/microsoft-exchange-2007-sp2-installation-is-blocked-on-windows-sbs-2008.aspx
(Blog post updated to include links to release notes and what is new)
The database of an Exchange server is something that seems to raise a lot of questions with Exchange administrators. Many of the questions appear to be around the size of the database and its limits.
This article should help to increase the understanding of the database size and limits. I have also touched on the thorny topic of offline defrags.
First some terminology.
Where I mention VERSION, this is Exchange 2000, 2003, and 2007.
Where I mention EDITION, this is Standard or Enterprise. Where I mention Standard edition that also applies to the SBS variant.
Unless stated otherwise, references to Exchange 2003 also apply to Exchange 2000.
To the best of my knowledge at the time of writing, Exchange 2007 references also apply to Exchange 2010. However if I find that is not the case, I will update this article.
This is a background article, it does not tell you how to do anything (just in case you came here via Google expecting to be told how to do X with your database).
Myths of the Exchange Database
There are a lot of myths around the Exchange database size and limits which I hope this article will help to dispel
- The store will dismount when you hit a physical size of 75gb
- Adding up the mailboxes listed in ESM should equal the size of the database
- Regular offline defrags are required.
Then there is the confusion with many administrators that the database doesn't shrink in size, even after the users have deleted lots of data. I will cover that as well.
Exchange Database Basics
Lets start with some basics of the database.
With Exchange 2003, the database is made up of two separate files. An EDB and an STM file. These combined are referred to as a store and come in two flavours - Mailbox and Public Folder.
Mailbox and Public Folder stores can be grouped together in to Storage Groups.
The EDB file should be thought of as the MAPI database and will consist mainly of internal email.
The STM file should be thought of as the SMTP database and will consist mainly of external email.
Email sent by Outlook Express users or other internal non Exchange servers would be considered external email.
However some information from the mail in the STM file is held in the EDB file.
The two files should be treated as one.
Mailbox Store and Storage Group Capacities
With Exchange 2000 and 2003 Standard edition you can have one storage group consisting of one database of each type.
With Exchange 2000 and 2003 Enterprise edition, you can have four storage groups consisting of a maximum of four mailbox stores in each group.
With Exchange 2007 Standard edition you can have up to four storage groups with a single mailbox store or public folder store in each, or a single Storage Group with four mailbox stores.
With Exchange 2007 Enterprise the number of Storage Groups goes up to 50.
Database Size
The size of the database is a source of much confusion with newcomers to Exchange.
The simple fact with the PHYSICAL size of the database is that it will never shrink without intervention from the administrator. When content is removed from the database then the Exchange server marks that space as white space, and should use that space first for new content before increasing the physical size of the database.
However in practise, that often does not happen. What you will usually find is that if users are asked to clean out their email, more external email will be removed (spam etc) but more internal email is generated.
Database Limits
The database limits are probably the are that causes the most concern for the Exchange administrators, so lets clear that up to begin with.
Exchange 2000 Standard has a database limit if 16gb, which can be increased to 17gb via a registry hack.
Exchange 2003 Standard RTM and Service Pack 1 is also subject to the same limit.
Exchange 2003 Standard with Service Pack 2 has a soft limit of 18gb, which can be increased to 75gb via a registry change.
Exchange 2007 Standard has a soft limit of 50gb in RTM and 250gb in Service Pack 1 which can be removed/changed with a registry change.
Enterprise edition of all versions have a technically unlimited database size, although if you are picky it is 8TB with Exchange 2000/2003.
If you update Exchange 2003 from Standard edition to Enterprise edition, then the registry setting for the soft limit is not removed, so the database may still dismount when it hit the size stated. You need to remove the key completely for that to stop happening
Soft Limit
Soft limits are basically a way for an administrator to ensure that the database doesn’t get out of control. The Exchange server will react when a soft limit is reached by dismounting the store.
Database Limit Enforcement
The way that the database limit is enforced changed with Exchange 2003 Service Pack 2 and subsequent versions.
With Exchange 2000 and Exchange 2003 RTM and Service Pack 1, the limit was simply the physical size of the two database files combined.
With Exchange 2003 Service Pack 2 and later, the limit is now a logical limit. The limit is the physical size of the two files, minus the white space.
The white space is reported by event ID 1221 during the night.
The logical limit of the database is not reported by Exchange until you change the default limit of 18gb.
The registry keys for increasing the 18gb limit in Exchange 2003 are in Microsoft KB article 912375 (link at the end) however I suggest that you read the Technet Article on how to work with the limit and setting the registry key for the warnings.
When setting the check time, ensure that it is AFTER the maintenance window configured on your Exchange server (ie after event ID 1221 has reported) so that content removed that night is taken in to account.
If you hit the limit -whether it is a limit below 75gb or the maximum 75gb limit and the database dismounts, you can mount it again. However it will dismount again the next day.
Offline and Online Defragmentation of the Database
When it comes to the database size and reducing it, most Exchange administrators will be referred to an offline defrag. However Exchange also does an online defrag. While they are related there are some key differences to what they do.
The online defrag is part of the nightly maintenance that Exchange does on its databases and is what finds and marks the white space for use. Its results are reported by event ID 1221. If that process does not run, the space gained by deleting content will not be used.
Am offline defrag will take the database and create a new one, consisting of the same data, minus the white space. Therefore the physical size of the database will be reduced. An offline defrag is the only way to reduce the physical size of the database.
The offline defrag is not risk free, and can take a considerable amount of time. The process speed is hardware dependant and can vary between 1 and 4gb per hour. Therefore if you have a 50gb store you could be looking at anything between 12 and 50 hours for the process to complete. Once started, it cannot be stopped. If it is, then both the source and the destination files are useless and a copy will need to be put in place.
The Exchange services have to be stopped while the process runs - so requires total downtime of the server. If you have multiple databases on the server then you can dismount the store you are working on and allow the others to run, however if you are in a position to run multiple databases, then you do not need to do an offline defrag, as I will explain below.
Some Exchange administrators claim that a regular offline defrag is required to keep the server running at the peak of performance. This is not the case and Microsoft specifically state that an offline defrag should not be considered something that needs to be done regularly.
The reason why there can appear to be a performance gain is because an offline defrag creates a new database. As with many things, if you replace with new then you will see some performance gains. Minor imperfections in the database structure can be removed and things generally cleaned up. However because it will skip data that it cannot read, that can mean there will be data loss.
With Exchange 2007, and Exchange 2003 Service Pack 2, or Exchange Enterprise edition (any version) an offline defrag is not necessary and is a waste of time.
Why?
With Exchange 2003 SP2 standard, due to the way that the database is reported, you gain nothing by doing an offline defrag. All you could do is lose data during the process. If you hit the limit, you can remount the database and then remove content.
With Exchange 2007 (all editions) And Exchange Enterprise Edition (all versions) the process is unnecessary. Simply create another mailbox store, move all of the mailboxes to that store and then drop the original one and delete the database file. You can then create a replacement and move the content back. Zero risk, zero downtime.
If the store you are replacing is the original first store, then it will also hold some system mailboxes. Those will be recreated in another database when the system attendant service is recreated, so you should do that as soon as possible after dropping the original store.
The only reason why you want to do an offline defrag is because you are tight on physical storage, however you will need considerable space to do the offline defrag (At least 110% the size of the store) which will mean additional storage somewhere, so you may as well add it to the original server.
Mailbox Size - Exchange 2000/2003 only.
Many Exchange administrators will be unaware that the list of mailboxes in ESM is not showing the true size of the mailbox. This is clearly shown by the number of questions on forums from administrators who add up the size of their mailboxes and then ask why there is a X gb difference between that total and the sum of their physical database sizes.
In Microsoft KB article number 828070 (link at the end), Microsoft state:
"When you view the space that a mailbox uses in Exchange System Manager, the amount only includes the space that is used by the Priv.edb file. The amount does not include the space that the Priv.stm file uses."
Therefore a significant difference between the size of the mailboxes and the total of the physical database size should be expected.
This difference is further increased when you take in to account single instance storage and deleted item retention.
Single Instance Storage is a mechanism used within the Exchange database to keep the size of the database down. If you send an email with a 5mb attachment to 10 users, rather than using 50mb of space, it only uses 5mb. The attachment is only removed from the store when the last of those ten recipients removes it from their mailbox.
Deleted Item Retention (aka dumpster) is a feature of the Exchange database, where an item that is deleted from the mailbox or public folder (including removal from the Deleted Items folder) is stored in the database where it can be recovered.
Conclusion
Day to day administration of the Exchange database is not something that most administrators should fear or have any concerns about. As long as you monitor the size of the database regularly, then issues around the size should not come as a surprise.
References
Exchange Server 2003 mailbox store does not mount when the mailbox store database reaches the 16-GB limit
http://support.microsoft.com/kb/828070/
Database Size Limit Configuration and Management (Exchange 2003 SP2)
http://technet.microsoft.com/en-us/library/aa998066.aspx
How to increase the Exchange Server 2003 Service Pack 2 18-gigabyte database size limit
http://support.microsoft.com/kb/912375
How to Modify a Database Size Limit (Exchange 2007)
http://technet.microsoft.com/en-gb/library/bb232092.aspx
Related Articles
Recover Deleted Items: http://www.amset.info/outlook/recoverdeleteditems.asp
Over the weekend one of my clients suffered an authenticated user attack on the SMTP interface of the Exchange 2003 server. This was detected by the monitoring tool I use, HoundDog (http://www.hounddogiseasy.com/referrer.html?code=YNPX) .
The attack was unsuccessful, as I have all of the authentication options disabled.
However what was interesting was the list of usernames that were tried. Some of them are to be expected, but others maybe not so. I have included the list at the end of this posting.
What this list tells you is the usernames that should be avoided, as some of them may well be used as test accounts, with basic or no passwords and therefore may well be easily compromised.
As authenticated user relaying is enabled by default on Exchange 2000 and 2003, if an account can be compromised, even with limited privileges, it can be used to relay spam through your server.
If you do not have anyone using POP3/IMAP accounts on your Exchange server, then authenticated relaying should be disabled completely. It is not required for the correct operation of Exchange with MAPI, Outlook RPC over HTTPS, Outlook Web Access and Windows Mobile or Blackberry use.
If you do have POP3/IMAP users then lock down the authenticated relay to those specific users only. I have added a link to my article on amset.info with instructions on how to do that below.
If you are a victim of an authenticated user attack then remember that most of them are not against you or your company directly, but a spammer wanting to use your bandwidth to send their messages, whether this is to sell something or a phishing attack.
Related Articles
Securing the authenticated relaying: http://www.amset.info/exchange/smtp-relaysecure.asp
Spam Cleanup: http://www.amset.info/exchange/spam-cleanup.asp
List of Usernames Targeted During Authenticated User Attack
webmaster
service
web
info
root
backup
tech
test
Administrateur
administrator
admin
tunnel
nagios
visitor
access
account
data
server
user
This is for reference really.
The events below are the sequence for a successful Backup of an Exchange database on Exchange 2007. It should apply no matter what backup application you are using, as long as it is Exchange aware.
When the jobs starts, this is logged:
Event Type: Information
Event Source: ESE
Event Category: Logging/Recovery
Event ID: 210
Date: 17/04/2009
Time: 05:13:25
User: N/A
Computer: SERVER3
Description:
MSExchangeIS (3680) First Storage Group: A full backup is starting.
Immediately telling you which database is going to be backed up (you would see one for each database).
Event Type: Information
Event Source: ESE
Event Category: Logging/Recovery
Event ID: 220
Date: 17/04/2009
Time: 05:13:25
User: N/A
Computer: SERVER3
Description:
MSExchangeIS (3680) First Storage Group: Beginning the backup of the file E:\Exchange Databases\First Storage Group\Mailbox Database.edb (size 3206 Mb).
When the backup is complete you get this reference:
Event Type: Information
Event Source: ESE
Event Category: Logging/Recovery
Event ID: 221
Date: 17/04/2009
Time: 05:15:18
User: N/A
Computer: SERVER3
Description:
MSExchangeIS (3680) First Storage Group: Ending the backup of the file E:\Exchange Databases\First Storage Group\Mailbox Database.edb.
With the database backed up, the logs begin. The Exchange backup will include the logs that were generated while the backup was running. This store is quite small, so only a few log files are required:
Event Type: Information
Event Source: ESE
Event Category: Logging/Recovery
Event ID: 223
Date: 17/04/2009
Time: 05:15:18
User: N/A
Computer: SERVER3
Description:
MSExchangeIS (3680) First Storage Group: Starting the backup of log files (range D:\Exchange Transaction Logs\First Storage Group\E0000005127.log - D:\Exchange Transaction Logs\First Storage Group\E0000005136.log).
If the Backup was successful, then the complete message is logged:
Event Type: Information
Event Source: ESE
Event Category: Logging/Recovery
Event ID: 213
Date: 17/04/2009
Time: 05:15:56
User: N/A
Computer: SERVER3
Description:
MSExchangeIS (3680) First Storage Group: The backup procedure has been successfully completed.
Finally, the committed transaction logs are flushed. You will notice that the last log being flushed is the one immediately before the log backed up earlier in the sequence.
Event Type: Information
Event Source: ESE BACKUP
Event Category: General
Event ID: 916
Date: 17/04/2009
Time: 05:18:16
User: N/A
Computer: SERVER3
Description:
Information Store (3680) Deleting log files D:\Exchange Transaction Logs\First Storage Group\E00000050E1.log to D:\Exchange Transaction Logs\First Storage Group\E0000005126.log.
The backup is successfully completed.
As you may be aware, my consultancy company is Amset IT Solutions Ltd. If you hire me, then this who you pay your bills to. As from 1st April 2009, that company name is no more. I changed it to Sembee Ltd.
There are a number of reasons why I changed it, the main one being to more closely link the company to me in an attempt to increase business. I also wanted a shorter more general name for business purposes.
It will take some time for the change to be reflected in everything I do, for example the branding on amset.info is still amset, but sembee.info points to the same place.
That was also the reason why the blog URL changed to blog.sembee.co.uk, as I wanted to use www.sembee.co.uk for the company address.
Otherwise everything else remains the same.
Blackberry - not a subject I usually touch on, but as I am using a BES variant with my Exchange system I thought I would post this little snippet.
Recently exchanged by very old 7230 Blackberry for a new Curve 8310. I found that my previously published applications of Google Maps and Google search were not appearing on the device.
A look through the event long on the server gave me this error:
Event Type: Warning
Event Source: BlackBerry Policy Service
Event Category: None
Event ID: 20000
Date: 29/03/2009
Time: 21:15:32
User: N/A
Computer: BES-SERVER
Description:
Device info for hardwareID 0x8d000f03 could not be found.
No idea what that meant, and I couldn't find anything clear on Google either.
However looking through older posts on some forums from when the 8700 series was released, I was pointed to a file called device.xml, which can be found in this location: "C:\Program Files\Common Files\Research In Motion\AppLoader"
Apparently if your device doesn't appear in the list, then you will get the above error.
I am using Blackberry Professional Edition, which is currently on 4.1.4, whereas the current version of Blackberry Enterprise Server is 4.1.6 (or very close, at the time of writing). The device.xml file was quite out of date and the ID number in the error message did not appear in the file. I needed to update the file!
You can get an updated device.xml by installing the latest Desktop Software from Blackberry somewhere. (4.7 at the time of writing) I have seen references to the desktop software being installed on the server, but I already had it on my laptop for playing around with the device. It will be found in the same location on both the server and the workstation. I went from a file that was only 8kb in size to a 16kb file.
I simply copied the file from my laptop in to the same location on my Blackberry server re-ran the "loader /index" command and then restarted the Blackberry Policy service. The application pushed out to the device shortly afterwards.
More Posts
Next page »