Many people user MS outlook configuration to request read receipts of every email. An issue is observed for the users who use this configurations. Although emails requesting read receipts are read the notification is sent out that the email was deleted without reading.
Solution: Exchange 2010 SP1 – Email Request for Read Receipt is giving false notification that "Your email was deleted without being read"
Indeed, this is an extremely critical bug in Microsoft Exchange 2010 SP1 RU3 V2. To fix this problem you must request a non publically available hotfix KB2471964 from MS PSS by calling them.
This is supposed to be fixed in next release of Exchange Server 2010 SP1 update.
Sound a weird question? Yes, it shocked me too. One of my customers run Symantech BrightMail Gateway for their inbound email handling. This appliance has multiple accepted domain names configured. We were amazed to see some domain names not having an associated MX records yet they were receiving emails from internet. I though of digging down more into this just because it was interesting 🙂
For most of us the equation is extremely simple, No MX no email. But I learned something extremely interesting today. RFC 2821 says you can receive emails even if you do not have a MX record for your domain name.
Below text comes from RFC 2821
5. Address Resolution and Mail Handling Once an SMTP client lexically identifies a domain to which mail will be delivered for processing (as described in sections 3.6 and 3.7), a DNS lookup MUST be performed to resolve the domain name . The names are expected to be fully-qualified domain names (FQDNs): mechanisms for inferring FQDNs from partial names or local aliases are outside of this specification and, due to a history of problems, are generally discouraged. The lookup first attempts to locate an MX record associated with the name. If a CNAME record is found instead, the resulting name is processed as if it were the initial name. If no MX records are found, but an A RR is found, the A RR is treated as if it was associated with an implicit MX RR, with a preference of 0, pointing to that host. If one or more MX RRs are found for a given name, SMTP systems MUST NOT utilize any A RRs associated with that name unless they are located using the MX RRs; the "implicit MX" rule above applies only if there are no MX records present. If MX records are present, but none of them are usable, this situation MUST be reported as an error.
This clearly means if the IP address associated with your exchange server is the same that resolves to your domain name’s IP address and you do not have any MX records configured in your DNS, you can still receive emails from the sending server compliant to RFC 2821.
Exchange Server 2007 and Exchange Server 2010 both applications are compliant to the mentioned RFC. Although I did not test this scenario yet this information might help you resolving your questions if you faced similar issue like I did.
This is one of the most annoying error that you may probably face with your HT servers and they stop sending emails to MBX servers. There are multiple things that you need to go through to fix this problem. This post is just provide some common troubleshooting steps that can be performed if you face this problem. I faced this one toady in one of my customer’s Exchange 2007 SP2 environment.
This error is most likely generated by permissions issue in active directory. The best bet to find out these problems is using ExBPA. In this particular case the permissions were messed up at the server object level in active directory. Inherited permissions from parent objects got removed due to some reasons.
Here are few things that you should try in this case:
- First off, make sure your active directory replication is not experiencing any problems.
- All domain controllers, global catalogs have the correct time and synchronized with your designated NTP server.
Make sure your HT and MBX server’s records are correctly registered in DNS and name resolution works perfectly fine. In some cases, you might want to add PTR records for all of your MBX, DS and HT Servers
Make sure your Default Domain Controller Policy had Exchange Server group added in Manage auditing and security log located at
- You can use net time /set \ntpservername if you find any issue discrepancies in the time.
Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesUser Rights Assignment of your default domain controller policies.
One more things in basic troubleshooting is to check the logon account used for Microsoft Exchange Mail Submission service on mailbox server. It should be set to Local System and Transport Service on Hub transport server should be set to run as Network Service
Once you have made sure all these things are in place the permissions are something that we need to concentrate on.
- Use EXBPA to ensure that none of the Exchange Server objects have permissions inheritance blocked on them. If you have you should see something similar to below:
- If you really see something like above then the inheritance of permissions to these objects must be allowed. To do this follow below steps:
- Open ADSIEDIT.MSC and browse to the location CN=<Exchange Server Name>,CN=Servers,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=Exchange Geek Inc,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Domain,DC=local
- Right click on the server object that was found not inheriting permissions from parent, Select properties, select Security Tab, Click Advanced button and check the check box “
- We are not done yet. There are few more permissions we should check even after allowing inheritance on this object. Follow the previous step to get to security tab of the properties window of Exchange Server object
- As you see in above screenshot below permissions should be assigned to the Exchange Server security group:
These permissions should be checked on all HT servers and MBX servers using ADSIEDIT and they must be as shown above.
Force the replication across the site and make sure that all permissions are replicated to all the global catalogs in that site at least.
- Store Constrained Delegation – Allow
- Store read and write access – Allow
- Store read only access – Allow
- Store transport access – Allow
Hope that helps!
Have you already tried removing an Exchange 2010 Server from your environment? If yes then you must have faced this error at least once. If you are removing an Exchange 2010 server from your environment then then you must also remove the databases hosted on that server where user mailboxes are. In case you have mailboxes then exchange will not allow you performing uninstall of the server.
While we remove an Exchange Server from environment we do need to clean up the mailboxes from all databases on that server ( This applies to legacy and Exchange 2010 Servers too). But most of the times when you run the cmdlet Remove-MailboxDatabase, you would face an error like:
This mailboxdatabase contains one or more mailboxes or arbitration mailboxes.
To get a list of all mailboxes in this database, run the command Get-Mailbox -Database <Database ID>. To get a list of all arbitration mailboxes in this database, run the command Get-Mailbox – Database <Database ID> – Arbitration, Before you can remove this mailbox database, you must disable, move, or remove user mailboxes and move arbitration mailboxes.
Exchange 2010 makes it little tricky to remove all mailboxes because of some hidden mailboxes which are not visible in EMC and EMS unless a special switch is passed to Get-Mailbox cmdlet.
If you haven’t heard of this thing before then the question on your mind is absolutely correct. What are these mailboxes and why do exchange 2010 need them?
Exchange 2010 introduces a new feature called moderated transport and Exchange Server 2010 uses these mailboxes for managing moderated transport. I wrote a blog post about moderated emails in Exchange 2010 last year. This post will help you understanding what is the moderated transport with an example. Read it here Configuring Message Moderation for Email Delivery to DLs in Exchange 2010 . The linked document is just an example of the things that moderated transport can do for you. To see these mailboxes use Get-Mailbox –Database DB001 –Arbitration.
Coming back to the original topic of removing these mailboxes used for moderated transport here is how we remove them:
- First make sure that you have moved / removed all your mailboxes to some other database and no results are returned when you run Get-Mailbox – Database DB001
- Then run Get-Mailbox –Database DB001 –Arbitration | Remove-Mailbox –RemoveLastArbitrationMailboxAllowed:$True
- This command will remove all arbitration mailboxes and then you can remove your databases using Remove-MailboxDatabase -Identity DB001 -RemoveLastArbitrationMailboxAllowed:$True
- Confirm your action when EMS asks you to do so and you are done