In Exchange Server 2016, Mailbox servers handle data storage, mail transport, client connectivity, and Unified Messaging. The most common troubleshooting topics for Mailbox servers are database replication health, server performance, and email delivery.
Here are some standard troubleshooting techniques for Mailbox servers:
- Check the event logs.
- Use the Exchange Management Shell.
- Collect performance data.
- Use the Exchange Troubleshooting Assistant.
General Mailbox Server Health
When dealing with Mailbox server issues, you’ll want to perform these basic checks:
- Exchange Server services started?
- Any errors in the event log relating to MSExchangeDatabase,
MSExchangeDatabase ⇨ Instances, or MSExchangeSubmission Mailbox? - Any Active Directory issues that might have a negative impact on
Exchange Server?
To troubleshoot Exchange Server, you should check if all required services are able to start as necessary. You should also check the event logs for errors relating to MSExchangeDatabase, MSExchangeDatabase Instances, or MSExchangeSubmission Mailbox. Finally, you should check Active Directory for any issues that might have a negative impact on Exchange Server.
Here are some specific things to look for:
- In the event logs, look for errors with the following Event IDs:
- 4098: This error indicates that a mailbox database could not be started.
- 4519: This error indicates that a mailbox database could not be mounted.
- 4520: This error indicates that a mailbox database could not be dismounted.
- In Active Directory, look for the following errors:
- “Object not found” errors: These errors indicate that a mailbox database or mailbox does not exist in Active Directory.
- “Access denied” errors: These errors indicate that a user does not have permission to access a mailbox database or mailbox.
If you find any errors, you can use the Exchange Management Shell to troubleshoot them. You can also use the Exchange Troubleshooting Assistant to help you diagnose the problem.
Obviously, the Test-ServiceHealth cmdlet would be useful in detecting basic problems, such as a dismounted database or a stopped service. The Get-ServerHealth cmdlet is also useful in detecting health issues. You can run the following command to list the current health status of the Exchange components on a server named PRD-EX1:
PS C:\>Get-ServerHealth –Identity PRD-EX1 | FT Name, AlertValue
Test-ServiceHealth and Get-ServerHealth should always be the first two cmdlets you execute when troubleshooting a Mailbox server, simply because they check many areas of the environment at once.
Using Test-MapiConnectivity
Like its close cousin, Test-OutlookConnectivity, Test-MapiConnectivity will help you determine problems accessing a specific mailbox. It logs into a target mailbox (which you can specify with the –Identity parameter), the system mailbox in a specific database (which you can specify with –Database), or the system mailbox in every active database on a server (through –Server). The output for all three variants looks like the following:
PS C:\>Test-MAPIConnectivity -Server Server1 MailboxServer Database Result Error ------------- -------- ------ ----- Server1 MailboxDatabase… Success Server1 MailBoxDatabase… Success PS C:\>Test-MAPIConnectivity GTaylor MailboxServer Database Result Error ------------- -------- ------ ----- Server1 MailBoxDatabase… Success PS C:\>Test-MAPIConnectivity -Database MailboxDatabase-001 MailboxServer Database Result Error ------------- -------- ------ ----- Server1 MailBoxDatabase… Success
For end-to-end connectivity checks, use the Test-OutlookConnectivity cmdlet. This cmdlet tests both RPC over HTTP and MAPI over HTTP connection types. For example, to test the RPC connectivity, run the following command:
PS C:\>Test-OutlookConnectivity -ProbeIdentity "OutlookRpcSelfTestProbe"
Samdani Pasha
Author works as an IT Engineer in a MNC based in India. He holds 7+ years of experience in IT Cloud & Operations and would love to share his experiences. Basically, transforms his daily experience to blogs.