Logparser to monitor suspicious mailbox access

A good indicator for hacking activies or other attacks is the number of errors per hour. The following script returns the dates and hours that had more than 25 error codes returned. Adjust the value depending on the amount of traffic on the site (and the quality of your web application ;-) ).

SELECT date as Date, QUANTIZE(time, 3600) AS Hour, 
       sc-status as Status, count(*) AS ErrorCount
FROM   {filename} 
WHERE  sc-status >= 400 
GROUP BY date, hour, sc-status 
HAVING ErrorCount > 25
ORDER BY ErrorCount DESC

The result could something like this:

Date       Hour     Status ErrorCount
---------- -------- ------ ------
2009-07-24 18:00:00 404    187
2009-07-17 13:00:00 500    99
2009-07-21 21:00:00 404    80
2009-07-03 04:00:00 404    45
...

The next query detects an unusually high number of hits on a single URL from one IP address. In this example I chose 500, but you may have to change the query for edge cases (excluding the IP address of Google London for example ;-) .)

SELECT DISTINCT date AS Date, cs-uri-stem AS URL,
      c-ip AS IPAddress, Count(*) AS Hits
FROM  {filename}
GROUP BY date, c-ip, cs-uri-stem
HAVING Hits > 500
ORDER BY Hits Desc

Date       URL                                 IPAddress       Hits
---------- ----------------------------------- --------------- ----
2009-07-24 /Login.aspx                         111.222.111.222 1889
2009-07-12 /AccountUpdate.aspx                 11.22.33.44     973
2009-07-19 /Login.aspx                         123.231.132.123 821
2009-07-21 /Admin.aspx                         44.55.66.77     571
...

It sounds like a piece of cake, to be honest. A single server, single physical location scenario like you're describing is the easiest migration to perform. Follow the guidelines from Microsoft and you'll be well on the way to success. You're basically talking about a "Move Mailbox" migration, with zero visibility to the users.

Your Exchange 2003 install should already be at Service Pack 2. That's all that's really necessary there.

Exchange 2010 has the feel of a minor version upgrade from Exchange 2007 (what w/ a lack of major architectural changes like there were between 2003 and 2007), and the migrations I've done from 2003 to 2007 have been very smooth anyway. I expect that 2003 to 2010 migrations will be equally smooth (though I haven't had occasion to do any yet... anybody game?).

You're saying the right things re: getting a new server computer to host Exchange 2010. Be sure you provision your storage per Microsoft best practices (separate spindles for ESE transaction logs and databases, tuned for sequential access for the former, and random access for the latter).

I have seen some hiccups in Exchange 2003 to 2007 migrations when users have their mailboxes open, while in Cached Exchange Mode, during the migration. It's supposed to be possible to move a user's mailbox while they're using Outlook, but I wouldn't chance it-- I'd be sure that they aren't using Outlook while moving the mailboxes.

If you're going to cut everyone over at once, changing your firewall rules that forward OWA access from the Internet to the new Exchange Server computer isn't a big deal. If you plan to coexist mailboxes on both servers for a time, then you're going to need to worry about users accessing the right instance of OWA to get to their mail, depending on whether their mailbox has moved or not. (That's a good argument for cutting over all the users at once during a scheduled downtime interval.)

I don't know that virtualization will "help" in the sense that the migration is going to be the same whether you're migrating onto bare metal or a virtualized machine. Exchange 2010 is more friendly than prior Exchange versions with respect to IO needs, so running in a virtualized environment (where you incur some amount of IO overhead due to being virtualized) is going to less of an impact as compared to prior Exchange versions.

If you're hosting any Exchange-integrated antivirus are you ready to go with a license for an Exchange 2010-capable version?

Is your backup management software ready to support Exchange 2010?

You may want to read up on Exchange Autodiscovery. It can have ramifications for your SSL certificate and DNS infrastructure, assuming you don't want to get little annoying warnings from Outlook. Have a look at these for some good background (the second refers to Exchange 2007, but it hasn't change dramatically in Exchange 2010).

• Understanding the Autodiscover Service

• White Paper: Exchange 2007 Autodiscover Service