At the beginning of a project, we typically ask
for a list of client types that must be supported by the end solution.
There are generally two responses to this question: Either the customer
responds quickly and confidently with such a list (accurate or not) or
we get a look that tells us no one has considered this question
previously.
Since we now recognize the importance of
client choice, it should come as no surprise that we strongly recommend
that you try to determine which client types are used on the existing
service before you attempt to design a new one. This recommendation is
equally applicable if you are moving to Exchange Online, which is part
of Office 365. Client type has a dramatic impact on network and other
system resources. If you cannot reasonably assess the client
types/versions that will use the service, it could prove to be very
difficult to ensure that the service meets all of its requirements.
Messaging API (MAPI/RPC)
By far the easiest way to determine the types of
MAPI clients that are connected to a system is via the Exchange Client
Monitor (ExMon). While this tool has not yet been released for Exchange
Server 2013, at the present time the most important use for it is on an
existing Exchange service to get a better understanding of client types
within the environment to help with the Exchange 2013 design.
ExMon is a great
tool, but it is known to crash frequently. If it does indeed crash, the
background ETL trace should continue to run. You can see this by
looking for the state of the Exchange Event Trace via logman, an
example of which is shown in Figure 1. Logman is a command-line tool that manages performance counter and event trace log collections on both remote and local systems.
FIGURE 1 Logman query results for ExMon trace
If the Exchange Event Trace shows a status
of Running, the trace file is still being created and will stop logging
when it reaches 512 MB. If you want to stop the trace before then, you
can do so via the following command:
logman stop “Exchange Event Trace” -ets command
By default, the ETL trace file will be stored in the default directory C:\Program Files (x86)\Exchange User Monitor. To open the ETL file, simply drag it over the ExMon.exe
file in File Explorer. It is beyond the scope of this section to walk
through the ExMon output in detail, but it is explained quite well in
the following TechNet article:
For the purposes of client inventory, it
is recommended that you run a few traces during a workday and then
export that data to a .csv file
for analysis within Excel. The aim of this process is to determine
which Outlook client versions are currently in use so that you can
ensure that your new Exchange 2013 solution will work with them or that
they can be identified and upgraded.
LINUX MAPI CLIENTS
A word of warning here about Linux MAPI
implementations: The Linux MAPI library allows Linux mail clients, such
as Evolution, to connect to Exchange 2007 and Exchange 2010 via MAPI.
These clients usually report in ExMon as version 12.0.6206.1000, which
is the same as Outlook 2007. The problem with this procedure is that
Exchange 2013 does not work with any current Linux MAPI implementation,
and so all of these Linux MAPI clients will fail to connect if you
migrate them over to Exchange Server 2013 without first reconfiguring
them back to IMAP4 or POP3. You first must identity them, however,
which is tricky since you can't tell them apart from Outlook 2007. If
you have a significant population of Linux users, it's probably a good
idea to notify them of this issue prior to migration.
Web Clients (EWS, EAS, and OWA)
Exchange Server uses the standard-issue Internet
Information Server (IIS) to serve web requests, both HTTP and secure
HTTPS. There is no easy way to see how many of each version of the web client requests are being made to Exchange Server. This information, however, is tucked away in the IIS logs.
Log Parser is by far the best tool for
analyzing text logs generated via IIS. There is a great write-up of
this tool specifically for Exchange on the Exchange Team Blog:
We recommend spending some time analyzing
the data from your Exchange Server IIS logs and grouping the results
into device categories. This will help you to quantify the relative
size of each device group and allow you to understand the importance of
each device type and version. See the end of this section for a link to
some scripts to help with this.
POP3 and IMAP4
Since neither POP3 nor IMAP4 has changed
recently, it is unlikely that you will need to know the precise client
versions deployed for your design. One thing you do need to know is how
many POP3 and IMAP4 clients there are in the organization, because
potentially you may not need to support POP3 or IMAP4 clients at all.
The easiest way to understand POP3 and
IMAP4 usage within an existing Exchange environment is to log some
Exchange performance counters over a period of time. We recommend
logging the following performance counters every 15 minutes for a
couple of weeks:
- \MSExchangeIMap4\Active SSL Connections
- \MSExchangeImap4\Current Connections
- \MSExchangePop3\Active SSL Connections
- \MSExchangePop3\Connections Current
Once you have a better understanding of
the scale of POP3 and IMAP4 usage, you can then decide if you need to
take things further. If there is significant usage in the user
population, then you should include POP3 and IMAP4 appropriately in
your design. If you are dealing with a very small community of users
who rely on these protocols, this may be a good time to move them over
to an alternative protocol, such as OWA or EWS.
To enable protocol logging, use the following commands:
Set-PopSettings -Server “CAS1” -ProtocolLogEnabled $true -LogFileLocation “E:\POP3Logs”
Set-ImapSettings -Server “CAS1” -ProtocolLogEnabled $true -LogFileLocation “E:\IMAPLogs”
WARNING IMAP4 and POP3 protocol logging
can consume considerable disk space on heavily used servers. Make sure
that you specify a log file location with plenty of space, and remember
to disable protocol logging when you have finished.
Analyzing these logs should provide
sufficient information about the users who are authenticating to the
mailboxes and also the client device IP addresses. Such information
should be sufficient to locate the individual users and have a
conversation with them about their client usage.
Here is a short example from a POP3
protocol log. This log shows both the client IP address and username
that was used for authentication.
When performing this
process, it is important to remember that the fewer client types and
protocol mechanisms that your Exchange design needs to support, the
simpler it will be. Additionally, it reduces the attack surface of the
solution, which is always a good thing.
Scripting
All of this log file analysis is great. But if you have lots of Exchange Servers, or you are just not comfortable with LogParser,
then there is still some hope. Our friend Steve Goodman has created a
couple of scripts that will analyze your IIS logs and generate a nice
report.
The scripts can be found here:
