The Exchange Central category delivers information, tips and tweaks for Microsoft Exchange Server on topics such as mobile messaging, MONAD, and Active Directory integration.

There is also a discussion on various aspects of Exchange administration and management with a very special focus on the upcoming version of the product, Exchange Server 2007 (aka E12).

It’s no longer a secret I’m writing a book on Exchange Server 2007, you can even find information about this upcoming book on Amazon.com. Just like my previous book this one too will be published by Syngress Publishing, and will be part of the successfull “How To Cheat at” series.

The book will be published shortly after Exchange Server 2007 RTMs, more specifically in the beginning of February 2007.

Exchange 2007 introduces a completely updated GUI management console to replace the Exchange System Manager of previous versions. This new Exchange Management Console is still a Microsoft Management Console (MMC) snap-in, just like the old version, and still uses standard GUI elements like a navigation tree, result pane, wizards, property pages, and dialogs. However significant improvements have been made to greatly simplify the console experience without a complete paradigm shift - in short the console will provide a simplified, intuitive, and an organized management experience, but not a steep learning curve.

Continue here.

Sami Khoury posted below tidbit on the MSExchangeTeam blog.

Web servers, network security appliances, and system network stacks have a number of time-based thresholds that are intended to insulate these systems from buggy or malicious clients.  For example, a denial-of-service (DoS) attack could be mounted by failing to complete the handshake that is implicit in the creation of a TCP connection, but the TCP stack in Windows mitigates this threat by requiring that the handshake complete within a finite time.  Similarly, a DoS attack could be mounted against IIS by opening a larger number of TCP connections but never actually issuing an HTTP request.  IIS mitigates this threat by requiring that a client submit a fully-formed HTTP request within a certain time before dropping the connection.

Note, however, that there are timeout settings that can be safely increased without compromising the security of the network.  For Direct Push, the timeout of concern is the idle connection timeout; that is, given a fully established TCP connection, for how long should that connection be permitted to live in the absence of traffic?  Recall that the essence of Direct Push is a long-lived HTTP request: the device issues a request, and the server holds that request without responding until either a device-specified timeout (the “heartbeat interval”) expires or new email arrives.  When either of those events occurs, the HTTP request is completed, but the connection is idle in the time between the request and response.

Now, the design of Direct Push makes no assumption as to the length of its sessions - email is delivered rapidly whether the heartbeat interval is one minute or thirty minutes.  However, using a heartbeat interval of 15-30 minutes has positive implications for battery life and bandwidth consumption: if the Direct Push sessions are permitted to live longer, there will be fewer HTTP roundtrips, less data sent and received, and less power consumed by the device.

We will characterize the different types of DoS threats regarding incoming connections and show that increasing the idle connection timeout neither increases nor decreases the exposure to attack:

   - An attacker attempts to create a large number of “half open” TCP connections by only partially completing the TCP handshake process.  Increasing idle connection timeouts is unrelated to this type of attack - the time within which a TCP handshake must complete is a separate threshold governed by the Windows TCP/IP stack.

   - An attacker establishes a large number of TCP connections but never issues an HTTP request over any of them.  These connections will be closed as soon as the “Connection Timeout” value in the IIS management console is exceeded (this defaults to 120 seconds).  We realize that this setting is misleadingly named, but here again, increasing the idle connection timeout of the firewall appliance does not further expose an enterprise because the attack is mitigated by a separate threshold that is reached before the firewall’s idle connection timeout comes into play.

   - An attacker establishes a larger number of TCP connections, issues HTTP requests over all of them, but never consumes the responses.  This threat is mitigated by the same timeout as the previous scenario.  That is, the “Connection Timeout” setting in IIS defines the time within which a client must issue its first request after a TCP connection is established and any subsequent requests in an HTTP keep-alive scenario.

Microsoft has worked with mobile operators to increase the idle connection timeouts on their outgoing firewalls, but the enterprises that are deploying Direct Push will also need to increase those timeouts on their incoming firewalls.  In Microsoft’s own deployment, the timeouts on ISA are set to thirty minutes.

I was lucky enough to get an invitation to the E12 Ignite Tour back in February, now it’s time for the MCT’s to get some E2K7 knowledge

“I’ve just finished delivering 2 days of Exchange 2007 training to a group of Microsoft Certified Trainers from across Europe. It’s called Exchange Ignite training (Ignite the interest / ignite the spark / ignition). There were 18 MCT’s in the room (2 women thanks to Anne and Ilse), with 2 Microsoftee’s (Jane and me). You know Jane, you need to get a blog, share that massive amount of deep technical knowledge you have with the rest of the world, and increase the number of Technical women blogging on Exchange beyond KCand myself Mind you 20% female techies in a room was impressive (and certainly unusual!)”

Read on over at Eileen’s blog.

Technorati : Exchange Server 2007, Ignite Training

Along with the public release of Exchange 2007 Beta 2, we are today releasing an update to ExBPA v2.7 called the “Exchange 2007 Readiness Check”. This is a new type of scan that you can run against your existing Exchange deployment. Its purpose is to provide a ‘to do’ list of changes and decisions that need to be made before Exchange 2007 can be deployed. Armed with this analysis, you can spend the next six months getting ready, so that when you crack open the Exchange 2007 DVD, you can get up and running as quickly as possible.

Continue at source: http://msexchangeteam.com/archive/2006/07/28/428506.aspx

Should you not have received the MSExchange.org newsletter by email, you can find it online here in the newsletter archive. This time I talk about the new method used to route messages in Exchange Server 2007.

Technorati : MSExchange.org, newsletter
Del.icio.us : MSExchange.org, newsletter

Below question was posted on the OWA 2003 board today, and quite frankly I wasn’t sure whether this issue could be fix with some kind of workaround or not. But I’ve just confirmed with an Exchange Program Manager, who says there’s currently nothing to do about. He forwarded the issue to the respective people on the Exchange team though.

Dear All,
I have fron-end and back-end server in my company. I want to block access attachment from OWA for out side user. I already change in registry of Exchange Server for that, you can review how to do that via: http://www.microsoft.com/technet/prodtechnol/exchange/guides/E2k3ClientAccGuide/c0554fb9-f636-4c56-9cd5-ecb9bf5ae08a.mspx?mfr=true, user can not access attachment from outside via OWA. But there is still a bug in Exchange, if User copompose a new mail and attach an attachment file and then not send, they just save it in Draft folder, and then go outside, access Mail box via OWA, open Draft folder, they still can download the attachment file. So I want to ask if is there any solution to prevent that situation. Please help !!!

Thanks in advance.

One would think the new DirectPush technology (aka AUTD v2) were supported over a WIFI connection right? But unfortunately it isn’t so, it requires a cellular data connection such as GPRS, EDGE 3G etc. The reason behind this rather serious limitation is to be found at the device end. You see mobile devices with WIFI enabled cannot enter standby mode and receive notifications at the same time. So because DirectPush works by keeping an HTTP(S) connection alive to the Exchange Server 2003 using heartbeat intervals, the WIFI connection would have to be kept alive all the time. As some of you might know WIFI connection are quite battery hungry, so the battery would be drained in no time.

Hopefully this issue will be fixed with later models, as this reduces the usefulness of DirectPush rather drastically.

Did you know Mailbox quotas could affect server performance? To see why read Dave Goldman’s last post on his blog.