I’ve been reading through several forums on the web to looking for resolutions to the blank email problem. Unfortunately there is no all-encompassing, single silver bullet out there that will satisfy everyone.
What originally got me started down this path is that I was reading through a blog forum – “Office for MacHelp.com” – and I came across a blog entitled, “Exchange Mail sent as HTML in Outlook 2011 is received as plain text”, written by Diane Ross. Continue reading Blank Email Messages
There are multiple management roles that are included with Microsoft Exchange Server 2010. Many of the roles get assigned to management role groups or management role assignment policies. Together, these management role groups and management role policies control who is permitted to manage and use the various capabilities of Exchange Server. Continue reading List of Built-In Management Roles
When end users type in email addresses they sometimes make use of an Outlook auto-complete feature which fills in the extra characters of the email address for them. But where does this information come from? The answer is that the email address data is stored in a file that has “.nk2” as its filename extension. This file is also known as the nickname cache file. Continue reading Troubleshooting the Nickname Cache File
When working with Outlook folders administrators will often run into the question of how to manage the Outlook Secure Temp Folder. Sometimes users are not able to open the attachments that come with their emails specifically addressed to them. This problem can be very irritating especially to an end user who has been waiting for a very important email message. Continue reading Troubleshooting Outlook Secure Temp Folder
In his article, “Cross Org Availability using Federation Trust and Organization Relationship”, Ben Winzenz discusses some of the issues that can occur when organizations need to share Exchange server availability status with other Exchange organizations. Continue reading Free/Busy Outlook Feature
As more and more organizations move to Outlook 2010 they will have many discussions surrounding how to secure their email. They are probably already using certificates to secure their email communications with digital signatures. Setting up secure email can be a complex task and involve multiple decisions. Sometimes, it is almost better to remind users to simply put only content into their emails that would not cause them to lose any sleep at night should those contents be posted on the internet somewhere. Continue reading List of Cryptography Policies for Outlook
In Nino Bilic’s article, “help-us-understand-how-you-manage-your-discovery-mailboxes”, he asks for feedback from system administrators regarding how they manage their Exchange discovery mailboxes. Continue reading Discovery Mailboxes
Installing software is always an activity that administrators must allocate extra time to in order to prepare for the unexpected problems that can occur. And of course there is the time that must be allocated to handle the prerequisites.
Many times users will report that they are unable to access their email mailboxes. This can cause a lot of problems not only for the end users but to the organization in general. At a minimum, not being able to access email can results in frustrations and loss of productivity but from a wider viewpoint this can lead to loss of revenue to the organization and especially to one focused on sales.
There are many reasons for email to become inaccessible. The usual suspects are either the network connections or the email server. If, after troubleshooting the network and the server hardware, an administrator finds that neither are the source of the problem then it is time to drill down into the soft internals of the Exchange server.
In the case where mailboxes are inaccessible after a migration, an administrator should review the configurations of the mailboxes. If an Exchange mailbox has been migrated to a managed environment then an administrator can review the configurations of the mailboxes by using the following steps:
- Confirm that the source primary Simple Mail Transport Protocol (SMTP) address is the same as the managed primary SMTP address.
- Confirm that the source primary SMTP address is the same as the managed primary SMTP address.
- Confirm that the source target address has been specified as a proxy address on the destination object. Additionally the source target address should refer to the correct managed domain name.
- Confirm that the managed mailbox does not have a target address that is listed. An administrator can use the ADSI Edit or LDP to search for the managed mailbox and check the targetAddress attribute.
- Confirm that the source object is not specified as a mailbox. Also check that it does not have a HomeMDB or HomeMTA attribute.
If all of the above steps are completed successfully and the problem was with a user mailbox, then an administrator should confirm that the managed mailbox is specified as a linkedmailbox. They should also confirm that the linkedmasteraccount field lists the correct domain.
If all of the above steps are completed successfully but the problem was with a shared mailbox then an administrator should confirm that the user is listed explicitly and has full mailbox access.
An administrator can also test MAPI connectivity access by running the following command using Exchange Management Shell (EMS): test-mapiconnectivity <alias>.
As part of the troubleshooting process it always best to grant “Full Access” permission for a mailbox or “Receive As” permission for a mailbox database. “Full Access” permission is given to the user on a specific mailbox. Once they have “Full Access” permission then a user can open and read the contents of only that particular mailbox.
When using Exchange 2010 Service Pack 1 (SP1), Outlook 2007 and Outlook 2010 clients are automatically mapped to any mailbox that a user has been granted Full Access permission to use. There is an autodiscover feature that loads all mailboxes for a user that has been granted full access to, including shared mailboxes. This is one area that administrators need to watch as a potential cause of overloading the server. If overloading of the server occurs then performance will suffer. Most often, administrators are granted full access to all the mailboxes in the system. This can lead to overloading of the server when Outlook attempts to open all the mailboxes at startup time.
Another possible reason for inaccessible mailboxes is when some users have multiple mailboxes on the same system where Exchange server is running. In this case, users do not have to log on to each separate account to gain access to all of their Outlook accounts.
They may find that they can read their mail but are unable to send mail from their account. In this case it is most likely that the user permission to access the mailbox has been set to “Receive As” permission. “Read As” permission will allow a user to still log on to their mailbox and review their email messages but they won’t be able to send email. If this is the situation then an administrator will have to set their permission on the mailbox to “Full Access” for the end user to be able to send email. Remember to stop and then restart the Exchange Information Store service to allow immediate access.
Exchange Server uses several components and processes to route email messages from outside the organization through the internals of an Exchange Server transport pipeline. Many of the components and processes include: SMTP Receive, Submission, Categorizer, Local Delivery and SMTP Send.
A couple of ways that email messages can enter the transport pipeline include through a receive connector or via the pickup directory. Messages may also be placed in the submission queue by the store driver. One action that is always performed is the categorizing of the received email message. After categorizing the message, the message is placed in a delivery queue to await delivery to a mailbox or for routing to a recipient on another server maybe within a different company.
Queues are used to hold messages or data that needs further processing before reaching their final destination. Each queue of messages is processed based on its location in the transport pipeline. The transport system holds messages inside memory queues for processing. If the transport service goes down then the contents of the memory queues are “committed” to the database so as not to lose any data. These transport queues should be monitored in order to establish a baseline of activity and performance levels. If there is a problem with processing any of the messages then the messages will stay inside the queue until the problem is resolved. An administrator can use the Queue Viewer (Exchange Management Console) to correct any problems with the queues.