Ready to Start Your Career?

Exchange 2010 Problem: Some Users Can't Send Nor Receive Emails Anymore

Author's profile image

January 1, 2016

Hello, at first sorry for eventual bad english. Recently my colleagues and i ran into a Problem occuring at our biggest customer. We are running an Exchange 2010 Server. After a Crash of the Domain Controler, we had to re-roll the entire Server (only the Domain Controler). After that re-roll, there are suddenly 3 E-Mail Adresses in our Exchange, that can't send and that can't receive E-mails. Everytime they want to send ther is a Error Message that Looks like this(some data is censored): #554 5.2.0 STOREDRV.Deliver.Exception:StoragePermanentException.MapiExceptionJetErrorReadVerifyFailure; Failed to process message due to a permanent exception with message Die Verarbeitung der Zustellungszeit kann nicht abgeschlossen werden. 16.55847:19100000, 17.43559:00000000A6020000000000000000000000000000, 255.23226:00000000, 255.27962:0A000000, 255.27962:0E000000, 255.27962:0A000000, 255.27962:9E000000, 255.17082:06FCFFFF, 0.18273:00000000, 4.21921:06FCFFFF, 255.27962:FA000000, 255.1494:43000000, 255.1238:0F010480, 4.33375:0F010480, 4.36685:0F010480, 1.36537:0B001F0E, 6.5587:0F0104800B001F0E0F010480, 4.33375:0F010480, 1.36537:B0845380, 6.5587:0F010480B08453800F010480, 4.64931:0F010480, 1.36537:00800800, 6.5587:0F010480008008000F010480, 4.33375:0F010480, 4.13300:06FCFFFF, 0.37373:03001100, 4.45565:06FCFFFF, 4.43265:06FCFFFF, 4.63741:06FCFFFF, 0.55895:B0840110, 4.5041:06FCFFFF, 4.4465:06FCFFFF, 4.6833:06FCFFFF, 0.50217:0300DD3F, 4.5093:06FCFFFF, 4.5318:06FCFFFF, 4.10104:06FCFFFF, 0.57449:40001900, 4.6025:05000780, 4.5257:05000780, 4.4606:06FCFFFF, 255.1750:00000000, 0.26849:2D000000, 255.21817:06FCFFFF ## Received: from --------------------- by --------------------- with mapi id ----------; Wed, 4 May 2016 16:32:54 +0200 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: binary From: ---------------- To: ------------------ Subject: --------------------- Thread-Topic: ---------------------- Thread-Index: AdGmEWgoHi0+qhi0Sfuck8PEQSwvWg== Date: Wed, 4 May 2016 16:32:33 +0200 Message-ID: ------------------- Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: ---------------- MIME-Version: 1.0 X-Originating-IP: ------------- X-Auto-Response-Suppress: DR, OOF, AutoReply Does somebody know what this could be and how to solve it? Thank you very much! What do you mean "re-roll" the server? Did you revert your DC to a snapshot of a previous date? Are there other domain controllers in that domain? If you reverted to a previous date, were the affected accounts created after the date the DC reverted back to? Can you see the mailbox in Exchange? Have you tried removing the association between the user and their mailbox, and then reattach the mailbox to the user, or even create a new mailbox and see if the users can send from that one? Sorry for all the questions, but posting the error the user sees when they try to send an email isnt the first place I would look when troubleshooting. I would look at the logs on the Exchange server itself. Well, the fact that you installed Exchange on a Domain Controller is mistake number one. There must have been extenuating circumstances at hand for you to take such desperate measures with your Exchange Server. I frequently work on my company's Exchange Server, though I am an Engineer. Typically, if there is an issue that only effects a few of the clients, then the issue can be traced to VPN issues, either connection errors, credential resets, or a hard reset of the preset configurations. Why would you re-roll the server to begin with? I understand that the server crashed, but re-rolling it most likely could have been avoided.... First, to rule out the most common of these issues, you should contact them and find out what credentials they are using to access the server. If their credentials match up with what you have in Active Directory, you should check to see if they have been locked out of AD. That combination of VPN access denial is the most common, at least the most common in my company. Second, you need to examine their configurations for the Exchange Server. I find that most I.T. Departments in medical facilities (my company's clients are all hospitals, cancer centers, etc.) generally use Perl for their configurations. Perl works well with RegEx, and the DB is most commonly MSSQL or MySQL. Regardless of the specifics, cross referencing their configurations is step two of the troubleshooting process. Third, there may be an issue on your end, which is most likely the cause. You should access your EMC, and then reference their accounts with what you had listed prior to the re-roll. If your department is running proficiently, you will have the EMC data logged on a spare drive within the server. -----Check the Client Access tab within the Organization Configuration tab -----Check the Server Configuration tab -----Check the Recipient Configuration tab There's a few different possibilities when dealing with the Exchange Server, but these are the most common causes of your specific incident. If worse gets worse, then you can enter the Hub Transport, and then allow the server to accept SMTP correspondence. This is a last resort type issue. One easily adapted change could take care of your issue. You could always create new accounts for the three of them, and then transfer their logs into the new accounts. This is what I would do if all else fails. Good luck to you. 1-Make sure those clients have a set of credentials in AD and if not create new credentials for them and create newe mailboxes for them 2-If they already have make sure that there is not any denial policy existed on the network firewall or gateway 3-If they connect through vpn service, create new profile and new group policy for them in the firewall 4-If the thoughts above could not help you, then recreate your mailboxes Hi everybody, first of all, thank you very much for your tips until now. We read our way through the Exchange Log but we couldn't find anything suspicious. So we decided to delete the affected profiles and create them again. Right now they are working properly, the only incident that followed was, that the Exchange Server just randomly disconnectet the mailboxes of these profiles from the Server. Once again thank you very much for your help. Right now, i woudl say this topic can be seen as closed.
Schedule Demo