Category: Troubleshooting

Emails in users “Inbox” are automatically moved to a folder (not created by user), labeled “Junk”

Scenario:

A new email arrives, it sits in the “Inbox” anywhere from a few seconds to a few minutes before it moves to a folder labeled “Junk”. This is not the default “Junk E-Mail” folder in Outlook/OWA.

Issue:

Client has a Samsung Galaxy device configured to view users mailbox.

Solution: 

  1. Go into the E-Mail application on the Samsung Galaxy
  2. Press the Menu Key, select Settings, then General Settings
  3. Select Spam addresses and remove any addresses that should not be in there, such as your corporate domain.

Advertisement

Reading a Memory .dmp File

Scenario:  A server performed a hard shutdown and restarted. You want to figure out the faulting process that cause this crash.

Steps:

1.  Make sure you have downloaded and installed BlueScreenView and WDK 8 (Windows Driver Kit).

2.  Open BlueScreenView.  If you have copied the dmp files to your computer, make sure you put them in C:windowsminidump folder.

Click on the dmp file and it will tell you what driver caused the blue screen.  You can also change the lower pane mode in the Options menu to see the actual Blue Screen on the server or the drivers in the crash stack. This will give you somewhat of an idea of what caused the crash.


3.  To find more information in the crash dump file, use WDK. Open a Elevated Command Prompt and navigate to the following directory: C:Program Files (x86)Windows Kits8.0Debuggersx64

4.  Copy the Dump file (.dmp) locally. On Server 2012, this is in the %SystemRoot%MiniDump folder.

5. Type the following:

kd –z C:windowsMiniDumpWindowsmemory.dmp

.logopen c:debuglog.txt

.sympath srv*c:symbols*http://msdl.microsoft.com/download/symbols

.reload;!analyze -v;r;kv;lmnt;.logclose;q

6. Review the results by opening c:debuglog.txt.  Search for the Process_Name and other relevant information and it will tell you the faulting processes and information.

Scenario: Customer is running Exchange 2010 and Exchange 2013 servers in coexistence. The servers have the latest rollups and patches. Users using Outlook 2013 with mailbox on Exchange 2013 are not able to edit calendar of an Exchange 2010 mailbox user.

Note that customer is running Windows 7(sp1) and Outlook 2013 sp1

Resolution:  Run windows update and ensure Outlook and Office 2013 are all patched to this version: 15.0.4615.1000

The attempt to connect to http://server/powershell using “Kerberos” authentication failed: Connecting to remote server failed with the following error message: The WinRM client cannot process the request because the server name cannot be resolved

Error message: The attempt to connect to http://server/powershell using “Kerberos” authentication failed: Connecting to remote server failed with the following error message: The WinRM client cannot process the request because the server name cannot be resolved
Resolution: Try any of the options below
  
Option 1: 
Close console
Delete:  “C:Users[User Profile]AppDataRoamingMicrosoftMMCExchange Managment Console”
Try connecting again. It should re-query the servers
Option 2:
Close EMC
Delete the following registry value from the server: 
  HKCUSoftwareMicrosoftExchangeServerv14AdminToolsNodeStructureSettings
Reopen your EMC .
Option 3
If you know a working server’s name, launch the console
Right Click on Microsoft Exchange, Click on Add Exchange forest
Under specify the FQDN or URL running the remote powershell instance, type the fqdn of the server

Click OK

Incorrect message size reported using IMAP with a Pine client

​Issue: Incorrect message size reported using IMAP with a Pine client

Synopsis: In order for Exchange to return the exact size, it must rebuild the MIME which can have a performance impact on large messages or deeply nested attachments. The default setting is to return an estimate of the size to improve performance and since most other IMAP clients don’t have any problems if the size is wrong.

You can enable the exact size for everyone with:
Set-ImapSettings –EnableExactRFC822Size:$true

Or only for a specific user:
Set-CASMailbox “IMAP User” -ImapUseProtocolDefaults:$false -ImapEnableExactRFC822Size:$true

More info:

http://social.technet.microsoft.com/Forums/exchange/en-US/21adbe96-e21b-458a-8242-2c3894b9d7cf/imappopsettings-and-enableexactrfc822size-false?forum=exchangesvrgenerallegacy

HTTP 413 Errors in IIS logs with ActiveSync and Certificate Based Authentication

Scenario: After setting up Certificate Based Authentication for ActiveSync, users on mobile devices may experience the following error message: “Cannot Send Mail.The message was rejected by the server because it is too large”. When you check the IIS logs, you may see HTTP 413 errors. Our Environment: Exchange 2013, Windows Server 2012, IIS 8.0.
Reason: The client connection was dropped to prevent DeadLock. The server requests renegotiation for certificate authentication, and the content length the client is trying to send is larger than the value of the UploadReadAheadSizemetabase property in IIS.
WorkAround: The workaround below will re-bind the certificate to enable client certificate negotiation upfront.
Re-bind the certificate and enable ClientCertNegotiation:
1. netsh http show sslcert <– Copy the results to notepad.
2. netsh http delete sslcert hostnameport=<hostnameport>:443
3. netsh http add sslcert hostnameport=<hostname>:443 certhash=<certhash> appid=<appid> certstorename=MY clientcertnegotiation=enable <– Use copied results from step 1 to fill in these values)
Note: We have a separate IIS Site with EAS setup for Certificate Based Authentication. We use a separate certificate on this site so we can enable clientcertnegotiation on the certificate. Another work around would be to change the UploadReadAheadSize on the Web Server, the website that hosts the EAS subsite, and the EAS subsite.

Delivery status notifications in Exchange Server

Non-delivery reports (NDRs) are system messages that report the delivery status of a message to the sender. The messages are a subclass of a general message information structure that is known as delivery status notifications. Delivery status notifications describe three kinds of situations:

  • Success (2.X.X numeric codes)
  • Persistent transient failure (4.X.X numeric codes)
  • Permanent failures (5.X.X numeric codes)

NDRs are generated when a message cannot be delivered. If the computer can detect the reason for the failed delivery, it maps the reason onto a status code, and a corresponding error message is printed. For NDRs, most numeric error codes are reported in the form of “5.X.X” and are described as permanent failures. However, certain transient conditions cause “4.X.X” codes. 

Reference: