Hello again! In our last article, we discussed recommendations for deployment of public folders and public folder mailboxes. In this post, we will be discussing methods and tips for monitoring connections being made to the Public Folder mailboxes with the help of different log types available in Exchange Server 2013 and Exchange Server 2016. This article mainly focuses on logging related to public folder mailbox activity and provides information on how to analyze these logs to get the information on the usage of public folders. Let’s get to it!
As we discussed in previous post, the ability to estimate the number of connections being made to public folder mailboxes is very helpful as deployment guidance for public folders partially revolves around connection counts. As of today, currently available logging methods will not reveal individual names of public folders clients are connecting to but will contain information about public folder mailboxes being accessed by clients. Depending on what information you are looking to gather there are several flavors of logging you can consider.
Let’s get started! In the upcoming section, we are going to make extensive use of Log Parser Studio (LPS) tool which will be used to parse the logs to help get the required data. It is a great tool and if you are not aware of it, I would recommend you to first visit the following links and get yourself familiarized with it first:
The Autodiscover service is responsible for informing Outlook clients where and how to connect to a public folder mailbox. This may be so Outlook can display the public folder hierarchy tree, or to make a public logon connection to access content within a public folder mailbox. Thus, the Autodiscover logs can be useful to administrators in determining which public folder mailboxes are being returned by the Autodiscover service. This information can be very helpful in large multi-site environments when trying to identify possible improvements in public folder mailbox or public folder locations. To understand this better let’s consider a common scenario that an administrator might face in the environment. An administrator may need to determine which public folder mailboxes are being returned to the end users when they connect from different sites using Outlook. This can be a challenging task if there are many sites and users resulting in a huge data set. Rather than try to analyze the data manually there needs to be an automated way which can get the desired outcome. This is where the Log Parser Studio (LPS) queries can be used to parse the Autodiscover logs on mailbox servers to get us the required data for further investigation and actions.
Autodiscover logs should be investigated on Mailbox servers and can be found in the following default path for Microsoft Exchange 2013/2016:
(The location may change if the installation path is different from the default.)
At this point it is assumed Log Parser Studio has been installed. 1. Open the Log Parser Studio by double clicking the LPS.exe application file as shown in the below image which will launch the LPS. 2. Once the LPS launches, at the top of the left corner, select File and then click on New Query which will open new tab for query 3. Copy the sample query mentioned in the example below to the query section and set the Log Type to EELXLOG
/* New Query */
SELECT Count(*) As Hits,
EXTRACT_PREFIX(EXTRACT_SUFFIX(GenericInfo, 0, 'Caller='), 0, ';') as User-Name,
EXTRACT_PREFIX(EXTRACT_SUFFIX(GenericInfo, 0, 'ResolveMethod='), 0, ';') as Method,
EXTRACT_PREFIX(EXTRACT_SUFFIX(GenericInfo, 0, 'ExchangePrincipal='), 0, ';') as PF-MBX,
EXTRACT_PREFIX(EXTRACT_SUFFIX(GenericInfo, 0, 'epSite='), 0, ';') as Site-Name
WHERE Method LIKE '%FoundBySMTP%'
GROUP BY User-name, Method, PF-MBX, Site-Name
/* End Query */
4. Lock the query to avoid any modifications by clicking on the Lock icon once as shown below 5. Click on the Log file manager button available at the top panel window of LPS to add required logs as shown in the below image. 6. Specify the log location of the required log files and select one file in the folder where the logs reside and click Open and hit OK 7. In this example, I have accessed and selected logs from a specific mailbox server by specifying the UNC path of the server and log location. It is possible to add multiple folders of same log type from different servers and parse all of them at same time. 8. The only thing left is to execute the query and to do so just click the execute query button. in the LPS panel. The output will be similar format to the one shown Note: This LPS query will provide a report that includes information on what users are connecting to what public folder mailboxes along with the Active Directory site the mailbox resides in:
The output of this data may help an administrator determine if a significant number of users in a geographic location would benefit from a public folder mailbox to be located closer to them. Depending on the results administrator can make decision to deploy additional Hierarchy Only Secondary Public Folder Mailbox (HOSPFM) in those geographic sites and then set the DefaultPublicFolderMailbox property on the mailboxes so that they contact the PF Mailbox (HOSPFM) in their own site for fetching the public folder hierarchy information and in turn the user experience while accessing public folders will be better! One more point to be noted is that only Microsoft Exchange 2016 Autodiscover logs will show the Site Name. This logging feature functionality is not present in Microsoft Exchange 2013 and will require additional manual work to figure out the site location of the mailbox. Note: The example query will return additional Autodiscover log entries for non-public folder mailbox queries. If you have standardized naming convention for your public folder mailboxes you could enhance the query to only return results where the ExchangePrincipal value contains a portion of your naming convention.
You can also use the Test E-mail AutoConfiguration tool from within the Outlook client to perform a single user test. This will provide you with which public folder mailbox is being returned to a single end user by Autodiscover service for hierarchy connections. To start the Test E-mail AutoConfiguration tool, follow these steps:
Below is the excerpt from the XML File gathered from Test E-mail AutoConfiguration: As you can see above the user firstname.lastname@example.org will be using the public folder mailbox HOSPFMemail@example.com to make a hierarchy connection. Please note this is only an example; if you follow our guidance you will not have any users making connections to your primary public folder mailbox for hierarchy or content.
When users log into Outlook on the Web (OWA) in an environment with public folders, the public folder mailbox used for hierarchy information could be a static default public folder mailbox (if one has been set manually on the mailbox), or a random public folder mailbox. It should be noted Autodiscover is not utilized when accessing public folders using OWA. Instead, OWA uses its own function to return a default public folder mailbox to the requesting user. As such, you will not find OWA users in the previously mentioned Autodiscover logs.
All logging data for Outlook on the Web (OWA) including public folder access will be in the following folder on Exchange 203 Client Access Servers or Exchange 2016 Mailbox Server:
Here is an example of a Log Parser Studio query to fetch data from OWA logs:
/* New Query */
SELECT COUNT(*) as hits,
AnchorMailbox AS PF-MBX,AuthenticatedUser,ProtocolAction,TargetServer,HttpStatus,BackEndStatus,Method,ProxyAction
WHERE PF-MBX LIKE '%smtp%'
GROUP BY PF-MBX,AuthenticatedUser,ProtocolAction,TargetServer,HttpStatus,BackEndStatus,Method,ProxyAction
ORDER BY hits ASC
Log type is set to EELXLOG
|AnchorMailbox||The default public folder mailbox being returned to the user|
|AuthenticatedUser||Users accessing the PF mailbox|
|ProtocolAction||Action being taken by the user while accessing public folder such as GetFolder, Getitem, Createitem, Finditem|
|TargetServer||Provides information on which Exchange Server the query is being redirected to fetch the public folder mailbox|
|HttpStatus & BackEndStatus||Provides information on connection status for the public folder mailbox connection|
Output is as follows: In the output below the AnchorMailbox value is the public folder mailbox the end user is accessing for their hierarchy connection. In the above sample result, the user “Administrator” is logged into OWA and is accessing public folder mailbox HOSPFM-001 which is returned as default public folder mailbox. We know Administrator is using this public folder mailbox for a hierarchy connection as OWA logging currently does not capture information for public folder content access. In Log Parser Studio, you can save this query and execute it in batches to get concurrent logging. You can also add entire folder instead of individual logs which will make it easier to parse existing and newly written logs. The number of hits returned and being logged against specific public folder mailbox by the user will reveal the public folder mailboxes which are most often being used for fetching hierarchy information.
Since OWA does not use Autodiscover to fetch a default public folder mailbox, it may make sense to identify the public folder mailboxes being returned to users when they use OWA. Like our earlier example for Outlook, it may identify cases were OWA is using public folder mailboxes that are a less optimal performance choice. Keep in mind that for OWA a better performing hierarchy mailbox is one closer to the Exchange mailbox server where OWA is being rendered rather than one closer to where the user’s Outlook client sits. Depending on your Exchange deployment and where OWA is served this may mean making choices about your public folder mailbox deployment based on what client is more often used in your environment to provide that client more optimal experience. As mentioned in my earlier post the recommendation for users in geographically disperse sites is to deploy additional Hierarchy Only Secondary Public Folder Mailbox (HOSPFM) and set the DefaultPublicFolderMailbox property on the user mailboxes in those sites to ensure a public folder mailbox within the Site is being used by the respective users for hierarchy.
While AutoDiscover logs can provide information about public folder mailboxes Outlook is learning about and may potentially connect to, the RPC Client Access (RPC/HTTP) & MAPI Client Access (MAPI/HTTP) logs will provide information about actual public folder mailbox connections established by users. Both log types in this case can be combined in LPS in single query and parsed to get some useful information on Public folder mailboxes being accessed. Default location of logs:
Consider the scenario consisting of a multi-site environment where the administrator is given a task to determine which users are connecting to public folder mailboxes on a specific server. Let’s say E15-CLASS-MB1 is the Mailbox server hosting the public folder mailboxes and the administrator needs to find who is making connections to them. Depending on the results decisions can be made whether or not it makes sense to move certain public folder mailboxes closer to a certain user location based on who actually uses that public folder mailbox. Below are the steps to be followed: 1. Open the LPS on the machine. Copy and paste the query below in the New Query Window in LPS as per the instructions mentioned earlier in the post.
/* Public Folder Mailboxes Hits */
SELECT Count(*) as Hits,
operation as Operation,
user-email as [SMTP Address],
EXTRACT_PREFIX(EXTRACT_SUFFIX(operation-specific, 0, 'Logon:'), 0, ';') as MailBox-LegacyExchangeDN,
EXTRACT_PREFIX(EXTRACT_SUFFIX(operation-specific, 0, 'on '), 0, ';') as Server
WHERE operation-specific LIKE '%Logon: Public%' AND Server LIKE '%E15-CLASS-MB1%'
GROUP BY Operation, Mailbox-LegacyExchangeDN, Server, [SMTP Address]
ORDER BY hits DESC
Fields used in query:
|Operation||Used to extract the logons for public folder mailboxes|
|SMTP Address||Email address of the users accessing the public folder mailbox|
|Mailbox LegacyExchangeDN||Public folder mailboxes in form of LegacyExchangeDN|
|Server||Connection requests coming to the server|
2. Set the Log File type to EELLOG. Add the required folders to parse from respective mailbox servers and start the query by clicking Query button in LPS Panel. 3. The above sample query exports the results in CSV format. If there is no specific location specified in the query to export the report the default export directory will be used. 4. Once the query has finished executing, it will export the output to a CSV file, which can be further formatted as table. 5. To do so Open the CSV file. By default, the CSV file will not have any formatting and will show the output in similar format. 6. Select all the cells which contains the data and then select Insert tab and click on Table which will open a new pop-up window to Create Table. Click on OK button 7. A new table will be created in structured format to help sort the data and filter it. 8. The filtering can be used to sort the data by available fields such as SMTP Address, Mailbox-LegacyExchangeDN If the LegacyExchangeDN output is trimmed and you cannot figure out the full public folder mailbox name, then you can copy the LegacyExchangeDN value of the public folder mailbox in Exchange PowerShell and use it to find the name of relevant mailbox as shown below: You now have information regarding public folder mailboxes being actively used by users on the server. Not only which ones, but also the frequency. This can be utilized by the administrator to make public folder deployment decisions.
In Microsoft Exchange 2016 there is one additional folder created specially to log MAPI/HTTP protocol traffic. Recent updates to Exchange 2016 have removed MAPI/HTTP traffic from the MAPI Client Access log. If not all of your Outlook for Windows clients are connecting to Exchange 2016 via MAPI/HTTP you may need to analyze both logs to get a full picture of your public folder mailbox connections until such time that all Outlook for Windows clients are using MAPI/HTTP. All MAPI/HTTP logging is now logged in to the MapiHttp folder. The logs reside in the following default path:
Exchange Server 2016 uses slightly different field names for MAPI/HTTP logging, and a query used previously with Exchange Server 2013 for parsing the MAPI/HTTP traffic in the older MAPI Client access logs will no longer work with Exchange Server 2016.
MAPI/HTTP logs can be investigated for connections established to public folder mailboxes over the MAPI/HTTP protocol in Exchange Server 2016 using the below query in Log Parser. Ensure the Log Type is set to EELXLOG
/* New Query */
SELECT Count(*) as Hits,MailboxId AS PF-Mailbox, MDBGuid AS Database, ActAsUserEmail AS SMTP-Address, SourceCafeServer FROM '[LOGFILEPATH]'
WHERE OperationSpecific LIKE '%PublicLogon%'
GROUP BY PF-Mailbox,Database,SMTP-Address, SourceCafeServer
ORDER BY Hits DESC
|Operation-Specific||Used to extract the logons for public folder mailboxes|
|SMTP Address||Email address of the users accessing the public folder mailbox|
|PF-mailbox||Mailbox Guid of PF mailbox|
|SourceCafeServer||Connection request coming to the server|
|Database||Shows which specific mailbox database which host public folder mailboxes is being connected to|
Once the query is executed it will gather the information and will populate the results in the below format which can be exported to CSV and output can be gathered in batches by running the query in batches to fetch more data. Sample output: In Exchange 2016 MAPI/HTTP logs, the name of the public folder mailbox is not revealed but, the log does capture the mailbox GUID of the public folder mailbox which can be used in PowerShell command to fetch the actual public folder mailbox name. Note: If there are any users hosted in Exchange 2016 who still use the RPC/HTTP protocol, the RPC/HTTPS query previously shown can be used to fetch the data for these specific users.
The administrators can run this report repeatedly in batches and gather the data in CSV file. The data can be collated for the results from different batches and investigated for public folder mailboxes being accessed frequently by the users. From there administrators should be able to find if there are any public folder mailboxes being used heavily by the users and then make decision to move any specific public folder mailboxes or maybe even specific public folders closer to users in specific location.
It is true there are many different logs in Exchange Sever showing similar information. Depending on what protocol your users use you may make decisions on the log type to parse. Autodiscover logs will give a combined view of what public folder mailboxes users are at least trying to access once. If you have content-only public folder mailboxes in your environment that are excluded from serving hierarchy and not directly assigned to users as their default, you may be able to determine if some are never accessed and may contain content worthy of purging. If you need a more granular view of the world, and the ability to generate some sort of heat map you may choose to go with more protocol specific logs. These logs will provide data on each time the client creates a new connection to a public folder mailbox and allow you to determine more than just if the client learned about it through Autodiscover but if it is being used far more heavily by many users over time. The options are varied and up to you to choose based on your need.
In this post, I have discussed and provided information on different types of public folder logging and how this logging can be useful to administrators to identity heavily used public folder mailboxes, which in turn can be used to do planning and deployment of public folders in the environment. In upcoming posts, we will discuss topics related to public folder management and quota related information I would like to thank Brian Day, Ross Smith IV & Nasir Ali for their inputs while reviewing this content and validating the guidance mentioned in the blog post, Special thanks to Kary Wall for providing inputs with Log parser studio queries and Nino Bilic for helping to get this blog post ready! Siddhesh Dalvi Support Escalation Engineer
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.