This video demonstrates troubleshooting using protocol logs and message tracking logs in the Exchange management shell as well as delivery reports in ECP.
- [Narrator] Exchange Server 2016 has a lot of logging capability, which can be nice when you're trying to track down what it is that you need to fix. Not all of the logs are enabled by default and some of them can be tricky to read but they can all be helpful in their own respect. The first one that I want to show here is a protocol log used for specific client access protocols. If I need to troubleshoot a problem with a user sending a message, I usually start by talking to the user but if their only responses are things like, I didn't do anything or I saw a message but it didn't seem important so I closed it, there are some log files that can help us track down what might be going on.
POP and IMAP logs, for example are not enabled by default but they are easy to turn on and they can give you some information about client access to the Exchange Server. These protocol logs can be turned on from the Exchange Management Shell. The commandlet that we're going to use is Set-ImapSettings, which could just as easily be set POP settings, if that's the protocol that you want to log. And the first parameter that we need to specify is which server we want to monitor.
If we want to monitor Exchange zero one, we would just add that and then we would specify protocol log enabled, and set that to True. Now there is one risk in turning on these logs. IMAP and POP especially, create a lot of log detail very quickly. And since the default location of these logs is on your system volume, you might want to specify a different log file location and designate a location on a different volume or a different physical disc so that you don't end up creating a space problem on your system volume.
In this demo, I'm going to be running these logs for a very short amount of time, so I'm not going to move them at this point. And you'll notice, when I run this commandlet, I receive a warning that these changes will only take effect after the IMAP services have been restarted on this server. So the next thing I'm going to do is open the Services tool. I'm looking for Microsoft Exchange, IMAP4 and you'll see that there are two services, one that's just labeled IMAP4 and one that is the back end.
I'm going to restart each of these in turn. Now, to generate some traffic that can be tracked in this log, I'm going to switch over to Janice's laptop. This is an email application, configured to use the Exchange Server as an IMAP server and the account for Janice Jansdotter. If I attempt to send an email to let's say the administrator, subject Test and a very short message body, and send this message, it's not going to get through.
And while the user gets this very convenient pop up message, giving them a pretty good idea of what's gone wrong, if they don't report this to you, you can still use the log files to find out. Back on our Exchange Server, let's go ahead and browse to where these log files are located. The default location is inside the Exchange Server Install Directory, in a folder called Logging, where there is now a folder named IMAP4. And here we have a text document that is the most recent log file.
So as I open this file, I'm reminded that log files are not the easiest thing in the world to read. One trick that helps me, is scanning for words like fail, bad, unknown or denied. But as I look through these log entries, I see attempts to open a session and start TLS, which is the security for an email server. And I see the session closed without any messages being sent. One thing that I can deduce from that series of events is that there was no successful logon, which would lead me to question whether or not the password is correct in Ms. Jansdotter's laptop configuration.
As it turns out, the password was updated in Active Directory but not in the email client application, which stopped it from being able to create and maintain a session to send a message. Now this has been a very brief example of one way to diagnose a user connectivity issue using a specific protocol log. If you want to track message flow regardless of protocol, there's another log that you'll find helpful.
- Planning and configuring transport and routing
- Understanding Safety Net
- Sending and receiving connectors
- Creating partner connectors
- High availability and site resilience
- Troubleshooting transport services
- Message security
- Filtering connections and recipients
- Spam confidence level thresholds
- Antivirus solutions