Sembee

Exchange 2010 Database Sizes

Sembee — Thu, 29 Jul 2010 18:10:00 +0100

The blog is getting lots of search engine hits for Exchange 2010 databases, probably because I wrote about the database size on the older versions in the past.

For older versions of Exchange see the posting here: http://blog.sembee.co.uk/post/Exchange-Database-Limits.aspx

For Exchange 2010, things are much the same.
On standard edition, the initial soft limit is 50gb, which can be increased as required. Enterprise edition has no limit configured.

To change the soft limit, you need to make a registry change and then restart the information store. The registry change is outlined in this article:
http://technet.microsoft.com/en-us/library/bb232092.aspx

Note that the change is case sensitive.
If copying from the article, watch that it doesn't include an extra space at the end.

If you have the registry key set correctly, after restarting the information store, the following entry will be logged:

Log Name:      Application
Source:        MSExchangeIS Mailbox Store
Date:          29/07/2010 22:07:52
Event ID:      1216
Task Category: Storage Limits
Level:         Information
Keywords:      Classic
User:          N/A
Computer:      exch.domain.local
Description:
The Exchange store Mailbox Database 1 is limited to 75 GB. The current physical size of this database (the .edb file) is <1 GB. If the physical size of this database minus its logical free space exceeds the limit of 75 GB, the database will be dismounted on a regular basis.

As with Exchange database since 2003 SP2, when the limit is reached, the database is dismounted. It can be remounted again immediately. However it will be dismounted at the next time the limit is checked, unless the registry has been changed and the information store service restarted.
The white space in the database continues to be taken in to account when the size is calculated - referred to as logical free space in this event log entry.

Outlook 2007 Certificate Prompts with Exchange 2003

Sembee — Mon, 14 Jun 2010 09:05:00 +0100

A common complaint in forums for some time has been SSL certificate prompts from Outlook 2007, when running Exchange 2003.
The error is usually along the lines of

"The name on the security certificate is invalid or doesn't match the name of the site."

Often the first response will be connected to RPC over HTTPS, as this is the only part of Exchange 2003 that can use SSL certificates for Outlook connectivity.

However the real cause of this is because of the changes made to Outlook 2007 to accommodate the changes to Exchange 2007 and its move to web services. Web services are used to reduce the dependency on Public Folders.

The specific cause of this is a process known as autodiscover. Anyone who has managed Exchange 2007 will be very familiar with Autodiscover, as it can be a key pain point.

Outlook 2007 will attempt to connect to autodiscover.example.com - where example.com is the part of your email address after the @ sign. It will also attempt to connect to a number of other URLs if that one fails.

If your domain does not have an entry for autodiscover, but does have a wildcard entry in its DNS (which is common) then you may get this issue.

Therefore from a client where you have the problem, attempt to ping

autodiscover.example.com

Where example.com is your email domain, then repeat with your internal Windows domain.

If it resolves, pinging either autodiscover.example.com, example.com or similar, even if it fails, then you may well be on to the cause. The final test is to bring up a web browser and type in autodiscover.example.com and see what happens.
It is likely that you will get the same SSL certificate prompt that Outlook receives and then it will load another web site completely.

The reason for this is quite simple.
Web hosts will often share the IP address of their server with a number of web sites, could be 100s. However to use SSL, a web site must have a dedicated IP address. Therefore a single web site with that IP address will have SSL support.
By using a wildcard in your DNS (so anythingyoulike.example.com resolves) means that all hosts will resolve to the same IP address.
As SSL cannot share an IP address, and does not see the host name being used, it will connect, and generate the SSL certificate mismatch.

How to resolve? Either remove the wildcard entry on the external DNS or have an entry for autodiscover.example.com put in to your domain with a dummy IP address - 127.0.0.2 for example. This will cause the host name to resolve, but fail to connect. See the single host replacement method on this page for instructions on how to do it: http://www.amset.info/netadmin/split-dns.asp

However if you ever deploy Exchange 2007 or higher then remember to remove it!

Short URL for TestExchangeConnectivity.com

Sembee — Sat, 08 May 2010 17:50:00 +0100

One of the most useful online tools to come out of Microsoft for the Exchange product is their testexchangeconnectivity site - or to give it's correct name - the Microsoft Exchange Remote Connectivity Analyzer (ExRCA). However the URL is a mouthful, and if you are typing it as often as I do, it is easy to make mistakes.

Therefore I have setup a short URL for it using our Exchange community site exbpa.com - you can get to it via http://et.exbpa.com/

I was going to use te.exbpa.com (which also works) but I thought et would be easier to remember.

New Site Launch - statuspages.co.uk

Sembee — Tue, 04 May 2010 16:00:00 +0100

Today we have launched a new web site - statuspages.co.uk. This is a development of an internal site that was built in a hurry after the Paddington exchange flood in March 2010 and is our first all new site launch since exbpa.com was created in December 2009 - all others have been existing content spun out to their own sites.

At the moment it is simply a list of links to the status pages for most of the biggest ISPs in the UK, along with BT, and some other internet based services. Not all ISPs have status pages, so where they cannot be found they are not included.

If you are supporting clients on multiple ISPs then this page could be useful, as it is a single location for the list, which we intend to keep up to date.

The site may be developed over time, but we believe it will be a useful resource in its current format.

Related Links

Statuspages.co.uk home page: http://statuspages.co.uk
ISP Status Pages: http://statuspages.co.uk/isp.asp
Phone Services Status pages: http://statuspages.co.uk/phone.asp
Other Internet Services Status pages: http://statuspages.co.uk/others.asp

Blog - All Change

Sembee — Mon, 03 May 2010 23:35:00 +0100

Its all change here on blog.sembee.co.uk and I have an apology to make to visitors.

First the change. If you aren't reading this on the RSS feed, then you will have noticed things look a little bit different. This is because I have changed the blog engine that I am using.

Since I started blogging in 2007 I have used Community Server, nursed back to life after two server failures, plus version upgrades. However with the change of my underlying OS to Windows 2008 R2, I decided it was time to switch to something a little more basic. I only used the blogging functionality of Community Server, nothing else. Plus I wanted to drop the SQL database dependency.

Therefore I have switched to BlogEngine.net. The change was relatively painless, I was running with it on a private URL in less than 30 minutes. What took the time was putting redirect files in to place so that URLs were redirected to the new format. That is now complete (I hope).

You might find that the theme changes, I am still looking for one that I am 100% happy with, and may end up creating my own, or getting one created for me to match the other sites that I have through Sembee Ltd. I haven't quite decided. The content will stay the same.
The HTML code is a bit odd in places, which I will correct as I find the postings, but that is a display issue, nothing more.

Comments are still turned off, because I have seen then turn in to support forums before, and blogs are a really bad way for that kind of thing - use a forum instead.

Now for the apology.

If you sent a message through the Contact option in the previous Community Server based blog format, then I didn't receive it. I had thought I had disabled all of the options for contact via the blog itself, preferring to receive direct email messages. However when I started to pull the original installation of Community Server apart, I found 70 pages of contact attempts in a location I had never looked at before - called "Feedback". Most of it was spam, and was deleted, but there were still seven pages of legitimate messages, dating back to 2008. I hadn't seen of them.

Big oops.

I am not going to reply to the lost messages now, as they will be very old and no longer relevant. However if you sent me a message via the blog and did not get a reply, it wasn't intentional. They simply went in to a location I didn't know was there.

Google Custom Search and IE Accelerators

Sembee — Sun, 25 Apr 2010 12:25:00 +0100

For some time, I have had a web site called kbsearch.info, which was created a few years ago when I first discovered Google Custom Search. It was a result of playing with this new (at the time) service from Google and creating search engines for some IT vendor knowledgebase.
The site was rather basic and I didn't do anything with it.
The site wasn't published, but Google found it, and it has had a trickle of traffic ever since - usually much less than 100 visitors a day.

However at the end of last year I started to split off some of the content from amset.info out to their own sites. This was content that wasn't core Exchange or Outlook related, but was responsible for a significant proportion of the traffic. A page I wrote six years ago as a getting started guide to the Command Prompt received more visits a day than the next five pages put together. It now has its own site at http://dosprompt.info/
With these additional sites, I implemented a common core design across them all. This design needed to be applied to kbsearch.info, and it was then I realised how poor it was and that the site needed some attention.

At around the same time, I was starting to play around with Windows 7 in some more depth, including the accelerators that are built in to Internet Explorer 8. The Google search tool was very useful, but there wasn't one for the UK version of Google. I found one for Canada, so I pulled it apart and modified it for the UK.

I therefore wondered if I could combine this newfound knowledge of IE search Accelerators with my kbsearch site. The reason for this was that I had created a custom search that was simply a web search engine, so that I could search Google without getting results that were mangled with their tracking information when you copied the result. An example of the URL that is returned is this:

http://www.google.co.uk/url?sa=t&source=web&ct=res&cd=2&ved=0CAsQFjAB&url=http%3A%2F%2Fkbsearch.info%2F&rct=j&q=kbsearch&ei=IW2lS5Voi7LSBP-KpPoJ&usg=AFQjCNFqOtghxR4pAS8Cum8pSB6xyKpRBQ

The custom search is here: http://kbsearch.info/google/default.asp

I found that you could indeed create an IE search accelerator for a Google custom search engine. What this means is that I can take a term and search for it through my own version of Google.

I have written exactly how here:
http://www.amset.info/ie/custom-search-accelerator.asp
And the resulting accelerators are to be found here:
http://kbsearch.info/a/

BES 5.0 Cannot Delete or Select User: The Request Could Not be Completed

Sembee — Sat, 24 Apr 2010 13:45:00 +0100

Currently migrating a client from BES 4.1 to BES 5.

All going well, except a few users didn't migrate correctly using the transporter suite. When selecting the user, it returned an error "The Request Could not be Completed". This stopped me from doing anything with the user account, including deleting them so I could reactivate them.

However a clever trick was shared with me, which I hadn't seen anywhere else, which allowed me to delete the troublesome user.

Select Manage Users, then Search. At the bottom of the page, choose manage multiple users. Select the user with the problem and then choose Delete User at the bottom of the list. You will get asked if you are sure. After selecting yes the user is then deleted and can be added back in again and go through the regular activation process.

A simple fix for an annoying problem.

SBS 2008 Certificate Installation

Sembee — Sat, 27 Mar 2010 16:45:00 +0100

In recent months I seem to have spent longer with SBS deployments, rather than Exchange 2007 or 2010. Therefore I have had lots of time to get annoyed with how SBS 2008 works with SSL certificates.

Exchange 2007 is very dependant on SSL certificates, which is something I have posted about in the past. However throw in the customisations to IIS that SBS 2008 makes and it gets much harder.
The SBS team have attempted to simplify the process, but for most people they have actually made it worse.

The major problem with SBS 2008 and SSL certificates is twofold.
1. SBS 2008 presumes that your external DNS provider supports SRV records. Their DNS partners that are pushed in the wizard do of course, but most do not.
SRV records are one of the methods that Outlook 2007 can use for autodiscover. Autodiscover is connected to the availability service. Therefore that means if you are using Outlook Anywhere, without autodiscover working correctly, the client doesn't work.
It can also cause problems internally, but the wizard does actually make the required changes for that.

I can see why the SBS team used the SRV record method, as it allows a standard single name SSL certificate to be used - usually remote.example.com . The wizard then makes the requires changes to Exchange and the domain to allow this method to work correctly. Using a single name SSL certificate keeps the costs down, as anyone who has worked with SBS user will know - getting the typical customer to pay for a certificate can be difficult, particularly when there is a "free" certificate in the product.

The comments in this article from Sean Daniel clearly show the presumption of SRV records use. In my opinion this is a very poor decision from Microsoft, when the wizard could easily automatically enter the additional names that are required and generate the relevant request.
http://sbs.seandaniel.com/2009/02/installing-godaddy-standard-ssl.html

2. The second issue is that SBS 2008 sets up additional web sites and uses them for external traffic. If you install and enable the certificate in the usual way for Exchange 2007, then you break those sites. That causes a mess, which can be resolved, does make extra work.

However, it is possible to get the certificate in place, in a way that is acceptable to both Exchange 2007 and SBS 2008. Whatever you do, DO NOT use IIS to generate and manipulate the certificate.

Preparation Work

To ensure that you work with the common configuration for SBS 2008, some DNS entries need to be made on the internet facing DNS services (usually your DNS provider).
Specifically these are
remote.example.com and autodiscover.example.com

(where example.com is your domain after the @).

These should point to your public static external IP address. If you cannot use a static IP address, then use a dynamic DNS provider to setup a host. Then create a CNAME for each of the above hosts and point them to then dynamic DNS host name.

While you can use another host name instead of remote.example.com, but everything in SBS seems to be orientated towards that name. Therefore I usually also use that host name for the MX records for the server as well, and get the ISP to setup the reverse DNS (aka PTR) record.

Certificate Request Generation and Response Installation

To generate the request, follow my guide elsewhere on this blog: http://blog.sembee.co.uk/archive/2008/05/30/78.aspx
However, add the name "Sites" to the list of domains that you include. That makes the full list:

remote.example.com
autodiscover.example.com
server.domain.local (the server's internal FQDN)
server (the server's NETBIOS name)
sites

When you get the response back from your provider, continue to follow my blog article up to the point about installing the response. DO NOT use the enable-exchangecertificate command.

By using the Exchange Management Shell to do the request you do not put the current self generated certificate at risk, because the request and response doesn't touch it. The certificate is only changed later on in the process.

Activating the Certificate

Now this is where things get different to Exchange 2007 full product installation.
In the SBS Management Console, start the SSL certificate. Select the option to use an existing certificate. Your new UCC certificate with the additional names should be listed. Select it and then complete the wizard. SBS will install the certificate in to the web sites correctly for you.
You should then be able to browse to https ://remote.example.com/remote and use the full feature set.

You can verify the certificate is installed correctly by using the Fix my Network wizard, which shouldn't touch the certificate installation - or by running the SBS Best Practises tool. The link to that is on my list of Exchange resources at http://exbpa.com/

Conclusion

With care, you can deploy a commercial certificate on to SBS server, without breaking any of the functionality of the server. This provides a more professional looking deployment for everyone involved, and no need to tell users to ignore certificate prompts.

Vamsoft ORF Update Available - Exchange 2010 Support

Sembee — Mon, 15 Feb 2010 17:15:00 +0100

My favourite antispam tool Vamsoft ORF has had an update and now supports Exchange 2010, as well as Windows 2008 and Windows 2008 R2 IIS based SMTP.

While support was available for Exchange 2010 in the previous version, a patch was required, this has now been integrated.

The support for Windows 2008 and 2008 R2 is important because of the changes in IIS.
With Exchange 2003, Exchange used the SMTP engine from IIS. This meant that the product worked with and without Exchange.
With Exchange 2007 and 2010, Exchange has its own SMTP engine and you do not install the IIS SMTP engine on to the server at all. Vamsoft ORF worked with the Exchange SMTP engine, but not the IIS engine that was part of Windows 2008/2008 R2. This update corrects it.

What that means is that you can now use Windows 2008/2008 R2 as an SMTP gateway, as I have outlined in this article on amset.info: http://www.amset.info/exchange/gateway.asp

More information on this update is here: http://www.vamsoft.com/orfee_changelog.asp

For the price of $239 per server, this product is very cost effective.

Some of the background to my liking for Vamsoft ORF, particularly with the latest version can be found elsewhere on my blog here:

Truly Spectacular Results from Vamsoft ORF
http://blog.sembee.co.uk/archive/2009/11/16/112.aspx
Real Time Blacklisting
http://blog.sembee.co.uk/archive/2009/09/26/108.aspx

Catch All Mailboxes and the POP3 Connector

Sembee — Mon, 15 Feb 2010 16:55:00 +0100

I have recently seen an issue with the POP3 connector which I haven't seen before, but will be very widespread. In this particular circumstance it caused the client's server to get blacklisted and have a server processing many thousands of messages which it shouldn't need to.

It is yet another reason why using the POP3 Connector is a bad idea. I have blogged on the POP3 connector being a bad option in the past: http://blog.sembee.co.uk/archive/2006/09/25/25.aspx .

This client was not only using a POP3 connector, but they were also using a catch all mailbox at the ISP - I have posted today why using a catch all is a bad idea here: http://blog.sembee.co.uk/archive/2010/02/15/117.aspx (posting that item was inspired by this one).

The Problem

The actual problem was quite simple, and something that Exchange could have dealt with on its own if the server was setup for SMTP delivery. However it became a noticeable issue because of the way this particular server was configured.

The domain was subject to an NDR or directory harvest attack (I cannot tell which due to the nature of the SBS Connector) and ended up with large numbers of email messages in their queues.

What puzzled the client was that port 25 wasn't open to the internet, and they had followed my guides on recipient filtering and authenticated user relay so that the server was secure ( http://www.amset.info/exchange/spam-cleanup.asp ).
As I wrote in that article, messages can continue to appear in the queues for some hours after the initial clean-up due to the way Exchange displays the queues when there are a very large number of messages in the queues. However for this client, the messages continued to appear for weeks. Eventually, fed up with cleaning the queues daily, I was asked to look at the server.

What I found was that the messages in the queues were all from postmaster@ so had the classic hallmarks of an NDR or direct harvest attack, but the client was using the POP3 Connector.

Due to the way the POP3 connector works, messages that come in to the server through it are not subject to the recipient filter. The recipient filter works at the connection point, but the POP3 connector simply drops the in to the queue for delivery. This is the key point and the result was the same as a standard NDR attack through SMTP without recipient validation - the messages that could be delivered were, and the messages with invalid external recipients, or where there was a delivery problem, hung around in the queues. As time went on, the server became blacklisted by most major ISPs for being a source of spam and back scatter.

Furthermore, the client also had the POP3 connector setup to send a copy of messages that could not be delivered to a valid user in to a mailbox, so not only were the messages being delivered there (and the client had what they considered to be a major spam problem) but the NDRs were going out as well. The user concerned thought they were receiving large amounts of spam - when in actual fact they were receiving email that wasn't even addressed to them.

In short, it was a complete mess.

This will be a widespread problem

In many respects, the client was not to blame for this problem. This configuration is quite common, and would therefore affect everyone using the POP3 connector with a catch all mailbox. However you may not see the messages in the queues and therefore be unaware that your server is a source of spam or backscatter.

The most common configuration when SBS is used with a POP3 connector is to route email OUT through a smart host - usually the ISPs SMTP Server. If you are doing that in combination with a catch all mailbox then you wouldn't see the symptoms of this problem. When a smart host is used, Exchange is sending the email straight back out again and the smart host is responsible for the delivery of the email.

It was only because this client was using direct delivery rather than a smart host that the email messages were shown in the queue causing further investigation. The client had accepted large amounts of spam in the mailbox as something that happens - and asked me to look at that as another issue - not realising that it was all caused by the same thing.

If the server had been configured in the usual way for POP3 use, that is to use a smart host, then the first the client would have known there is a problem is when their ISP called to tell them - although many do not.

Furthermore the email messages also do not appear in message tracking logs as they do not pass through Exchange, but simply bounce off SMTP. The only messages that do appear in message tracking are those delivered to the user set to receive the messages that could not be delivered.
Therefore a server could be the source of back scatter and the administrators (whether in house or an external support company) would be completely oblivious to the issue.

I haven't been able to verify if the email messages showed in the volume reported by the SBS Reporting tool, because as with most SBS Servers I see, it wasn't turned on.

The Solution

Changing the client to SMTP delivery of email resulted in the spam level dropping immediately. In the 24 hours after the change, the number of messages the server dropped for non-valid recipients was measured in 1000s. The account which received a copy of the unmatched addresses from the POP3 connector saw the level of spam almost completely drop away - as most of the spam wasn't addressed to the user.

Conclusion

There is a very simple conclusion to this blog posting.
Don't use a catch all mailbox with the POP3 Connector. Ideally you shouldn't use the POP3 connector at all.

If you are using the POP3 connector and do not wish to move to SMTP delivery, then you should look at switching to user specific POP3 mailboxes instead of a catch all. While that is more tedious to setup, it does mean you are only downloading email that you may want, rather than lots of spam that you almost certainly do not, only for it to be rejected.