Wednesday, August 4, 2010

Exchange: Outlook and OWA attachment issues

Outlook client does not display attachments

There are a number of reasons why this might be the case.
  • See http://knicksmith.blogspot.com/2007/03/exchange-2007-and-outlook-2003-where.html. An issue was resolved by Microsoft in Exchange 2003 Service Pack 1 where Exchange 2007 was incorrectly causing Outlook 2003 to hide inline attachments. Even though you could not see the attachment, if you flagged the email, or clicked forward on the email, the attachment would appear correctly. Also if you selected Save attachments from the file menu, it would still save the attachments. OWA is not affected by this.
  • See http://social.technet.microsoft.com/Forums/en-US/exchangesvrclients/thread/478c326b-486b-461c-9141-dd544b245c75. Symptoms: You can see the attachment in OWA but not in any of the current versions of Outlook. Outlook blocks the attachment completely and there is no way to retrieve it through this interface. This is also more likely to happen when an inhouse application has been programmed to send email with attachments. if the MIME is formatted incorrectly then Outlook will not display it. RFC 2387 describes the intended use of multipart/related:
    http://www.ietf.org/rfc/rfc2387.txt:
    "The Multipart/Related media type is intended for compound objects consisting of several inter-related body parts. For a Multipart/Related object, proper display cannot be achieved by individually displaying the constituent body parts."
    Steps to resolve this issue involve changing the MIME header to Multipart/Mixed instead of Multipart/Related. Multipart/Related will cause the attachment to be considered inline by Outlook. As there is no reference to the attachment in the body, it will then effectively be ignored. OWA has more smarts and is able to determine if an attachment is really inline or not. If it finds no reference to the attachment in the body of the email then it displays the attachment as a separate entity.


Friday, July 9, 2010

Exchange 20xx: Autodiscover and availability Issues




You receive the message: Allow this website to configure server settings?
You test e-mail autoconfiguration and it fails for no apparent reason.












The reason you receive the above error message is because the autodiscover website has been configured to redirect to a different website. For example, you might want to use https://webmail.domain.com/autodiscover/autodiscover.xml as your autodiscover URL. In this case you would redirect http://autodiscover.domain.com/ to that URL.

You may also receive this message if your autodiscover SSL website is not working correctly and fails. In this case, it will try http:// instead of https://. If you happen to have http:// redirected to https:// then you will also receive this message as this counts as a redirect.

You should be able to click the "Dont ask me about this website again" to make the message disappear for good.

Troubleshooting autodiscover messages:

  • Use testexchangeconnectivity.com. It is there to help you find out if problems exist in Exchange client access from the Internet.
  • If the user's primary email address is @domain1.com then is there an autodiscover record configured for this domain (either via an autodiscover website, redirection website, or a SRV record)
  • Check the version of Outlook being used. If it is Outlook 2007 SP1 or RTM then the first thing to do is to update to Outlook 2007 SP2. This can fix a number of issues and also fixes an issue where the e-mail autoconfiguration autodiscover test errors out with 0x8004005 immediately after a line where it appears to succeed (returns a 500 response).
  • Check whether the workstation is joined to the domain. This can determine the status of password storage and determine how you go about troubleshooting this issue.
  • Check the user account credentials stored in the Windows profile. If credentials are stored for Exchange and yet the password has been updated since, you may get a series of password prompts and possibly autodiscover prompts appearing. In Windows XP you can access this by typing UserControl2 into the Start-->Run dialog box.

Using multiple email domains can affect autodiscover
Another issue that can occur with autodiscover is if your organisation uses different email domains. If autodiscover is configured on http://domain.com/ and the email address for the user is @anotherdomain.com then autodiscover will not be resolved. You might want to create SRV records for these domains to redirect users to the autodiscover website.

Authentication on web services and autodiscover virtual directories can affect autodiscover

Another issue that may occur if autodiscover is receiving errors (0x8004005) and Out of Office is returning an error "the server is unavailable". This may be because Windows Authentication may not be enabled on the web services:

get-webservicesvirtualdirectory | Set-WebServicesVirtualDirectory -WindowsAuthentication:$true

How Autodiscover works

A client attempts to connect to the SCP to get an autodiscover URL. If the client is not domain-connected then this will fail.

A client attempts to connect to domain.com and autodiscover.domain.com based on the user's primary SMTP address. It tries https first and then http.

See http://technet.microsoft.com/en-us/library/bb124251.aspx for a more detailed description.

Basic troubleshooting steps

When auto-discover stops working, you may find that your Out-Of-Office and Free/Busy (availability) stop working too.

Start the Outlook client. Hold CTRL and right click the OL icon in the system tray. Select Test Email Auto-configuration. Enter the email address and password. Select "Use Autodiscover" but deselect all the Guessmart checkboxes. Click Test. On the XML tab, ensure it is connecting to the correct autodiscover URL. You may receive one of the following errors as defined by Microsoft.

0x80072EE7 – ERROR_INTERNET_NAME_NOT_RESOLVED
This error is usually caused by a missing host record for the Autodiscover service in the Domain Naming service.

0X80072F17 – ERROR_INTERNET_SEC_CERT_ERRORS
This error is usually caused by an incorrect certificate configuration on the Exchange 2007 computer that has the Client Access server role installed.

0X80072EFD – ERROR_INTERNET_CANNOT_CONNECT
This error is usually caused by issues that are related to Domain Naming service.

0X800C820A – E_AC_NO_SUPPORTED_SCHEMES
This error is usually caused by incorrect security settings in Outlook 2007.

- If this is a workstation connected to the domain and able to reach Active Directory, ensure it gets a URL from the SCP in Active Directory and is able to connect to it. If it retrieves a URL but fails in using it, check that the URL can be accessed by pasting it into an Internet Explorer window. It may be that TMG or the proxy is blocking access to that server. The resolution in this case may be to add the URL to the proxy exceptions list.

- If this is a workstation that is not domain-connected, check that the correct URL is returned. If not, it has not been configured correctly as the external URL on the internet facing CAS server(s). If the URL is correct then try to paste the auto-discover URL into Internet Explorer and see if the autodiscover XML pops up.

- If you have an issue with seeing free/busy data for other users then try to enable logging in Outlook 2007 > Tools > Options > Other > Advanced Options > Select Enable logging (troubleshooting) > OK > Restart Outlook > Try to view free / busy information for another user > Go to the %temp% folder and open olkdisc.log file and locate the files in the olkas directory. These files can often provide information about which service is not functioning correctly.






- If you have an issue with seeing free/busy data for other users then review the event log for event id's: 4001, 4003, 4005, and 4011. Possible solutions for these errors are contained at http://technet.microsoft.com/en-us/library/bb397225(EXCHG.80).aspx

- Use the test-OutlookWebServices cmdlet to troubleshoot the availability service. For example, Test-OutlookWebServices -id:user1@mydomain.com -TargetAddress: user2@mydomain.com

- If you have an issue with seeing free/busy data for other users then check if there are any cross-forest timeout issues. Details are contained in the URL http://technet.microsoft.com/en-us/library/bb397225(EXCHG.80).aspx

- Check the SCP point in Active Directory Sites and Services by enabling the "View Services Node" option. It is under Services > Microsoft Exchange > Org Name > Administrative Groups > Admin Group Name > Servers > Server Name > Protocols > Autodiscover. These SCP points can be administered using the Set-ClientAccessServer cmdlet.

- If the issue is with external users, then use the website http://www.testexchangeconnectivity.com/ to check that your configuration is correct.

- If you have issues and you are using multiple SMTP namespaces then you will want to check out http://www.msexchange.org/articles_tutorials/exchange-server-2010/management-administration/exchange-autodiscover.html

- Check that IIS is started on all servers

- Check that the OWA application pool, OAB application pool, and EWS application pool are all running and started with no errors.

- If you receive an authentication error (such as 500 service not availabile or 400 login time-out) then you may need to rebuild the virtual directories.

Verify Configuration
Ensure you have configured the following: -
- Configure your internal URLs for all virtual directories. These should be automatically configured as the server name. Configure external URLS only on your Internet facing CAS servers. See http://technet.microsoft.com/en-us/library/bb691323(EXCHG.80).aspx for details on how to do this. The external URL will either be the name of a CAS server or an NLB that is sitting in front of a number of CAS servers.
- Configure certificates on each Exchange servers and TMG servers as required. These should be trusted by clients.
- Add all Exchange CAS servers to a proxy exceptions list - generally either using WPAD or Group Policy.

Thursday, July 8, 2010

What would I have on my computer?

Microsoft Office (or Open Office if I want a free version)
Microsoft Visio and Project
iTunes (for the iPhone)
VMWare Workstation or Virtual PC
PDF 995 (Print to PDF documents)
Adobe Acrobat Reader
Infrarecorder (CD Burner)
Shockwave / Flash Player
Comodo Firewall and AV
Daemon Tools
Firefox
Notepad++
Irfan Viewer
Open Movie Editor
FileZilla
CMD Prompt Here
.Net Framework

Friday, July 2, 2010

Active Directory: Reset the DSRM password in Active Directory

If you are still able to log into the server through normal operation, you can reset the DSRM password using NTDSUTIL. See http://support.microsoft.com/kb/322672 for Windows Server 2003.

If you cannot access the server in normal mode, you will need to use a hacking tool to reset the DSRM password on that server. Try using a tool such as http://www.ubcd4win.com/ or http://www.hiren.info/pages/bootcd.

Outlook 2007: Outlook prompting for password issue

Symptoms: Outlook 2007 clients are prompting for password when connecting to Exchange 2007.

Possible solutions if affecting single users:

  • Open the profile settings and make sure there is no checkbox in "Always prompt for user name and password" on the Security tab
  • Check credential manager. It may be storing an incorrect password for the user and Outlook may be using this to connect to Exchange. Run control userpasswords2. On the Advanced tab, select "Manage Passwords". Remove any entries to the Exchange server. Alternatively, erase the server name and enter "S1" or the simple name of your global catalog server and leave the password blank. If prompted again, enter your username and password and check off "remember my password" one last time and it should not prompt again.
  • Try typing in the username by including the domain name. i.e. DOMAINNAME\Username. This has been known to resolve the issue.
  • In the task tray, hold down CTRL Key and right click the Outlook icon and select Test Email Auto Configuration. Uncheck Use Guessmart and Secure Guessmart Authentication. Click Test. When the test is completed, view the XML results.
  • Check that the autodiscover URLs are in the proxy exceptions list.
  • Open the following path: In Vista: \Users\YourUserName\AppData\Roaming\Microsoft Once open you will see numerous folders including a “protect” folder. Delete the “protect” folder. When you have deleted the protect folder, restart Outlook. You will be requested to enter your password again, but it will be the last time.
    Check that an Internet security product is not blocking a port.

Possible solutions if affecting a large number of people:



  • Open IIS on theExchange server and checked the following directories under the default website: the root site, oab, autodiscover. Under the directory security tab, click Edit in the Secure Communications section. If you have "require SSL" checked and the 128 bit encryption, but under Client Certificates, it is set to ignore, then this may be the problem. Change this to "Accept" for each of the folders and restart IIS. This may not be a satisfactory solution for everyone.
  • Try to connect to the autodiscover URLs listed in the SCP and in Exchange Management Console.
  • Make sure the OABurl is set to https and not http
  • In the task tray, hold down CTRL Key and right click the Outlook icon and select Test Email Auto Configuration. Uncheck Use Guessmart and Secure Guessmart Authentication. Click Test. When the test is completed, view the XML results. If the URL for the OAB is starting with HTTP instead of HTTPS then you may need to change this from the Exchange Management Console. Do an iisreset and test again.
    Make sure integrated security is enabled on the virtual directories where required.
  • Ensure Offline Address Book has been migrated to Exchange 2007.
  • Look at the properties of the autodiscover virtual directory and ensure a version of ASP is selected. If none is selected, clients may be prompted for password.
  • Ensure Windows authentication is enabled on the Autodiscover virtual directory.
  • See http://support.microsoft.com/kb/236032

If the problem exists when using RPC over HTTP:

If you are working RPC over https you are using or basic, or NTLM authentication, you need to be sure you are working NTLM. Now in order to ensure that outlook not uses any cached password we need to do the following. Go to Control Panel>User AcountsPress on Advanced Tab button. Click on Manage Passwords button. Review stored passwords , and if you see IP address of your mail server you should delete it.
Now we need to patch te registry
Click StartRun
Type regedit and press enter
Go to HKLM\SYSTEM\CurrentControlSet\Control\Lsa\
Find lmcompatibilitylevel DWORD parameter
Double-click on it and change its value to 3

Wednesday, June 30, 2010

Outlook: Outlook Signature is corrupted

Symptoms:
Any text that is not bold would turn out bold when creating a new email, and visa versa.

The following steps did not resolve the issue:
Creating a new Outlook profile or creating a new signature.

Outlook can be configured to use Word as the text editor for new emails. This means that the normal.dot configuration will apply to these emails. If the signature is doing something funny when you go to create a new text file, it will most likely be an issue with this file.

Resolution:
Close all office programs. Rename normal.dot which for Outlook 2003/Windows XP is under the user profile under Application Settings\Microsoft\Templates. Start Outlook again and create a new email. The issue should now be resolved.

Note: This may cause a Word instance to appear in the background. Close Outlook, start Word, close Word, start Outlook. This has resolved this issue.

Wednesday, June 16, 2010

Outlook: Offline Folder (OST) issues

This article lists many of the ways in which you can troubleshoot an issue with the Outlook offline mail file. This file is often refered to as an OST.

Determine more about the issue:
  • Record the error messages that are appearing.
  • An error at the beginning that asks if you would like to start in online or offline mode indicates that Outlook believes there is a discrepancy between the information in the OST and the mailbox.
  • Record the steps taken in order to receive the error condition. In some cases, the computer has to be shutdown, disconnected from the network and restarted before the OST issue will reveal itself.
  • Have the user log onto another computer and perform the tests using the same version of Windows and Office if possible.
  • Create a new test user with mailbox on the computer where the fault occurs, and see if the same issues occur.

Try the following steps to resolve an OST issue:

  • Ensure the user has read/write access to the OST file location.
  • Create a new profile and at the same time, change the location of the OST. If there is autoconfiguration involved, there may be a %username% in the location. Remove this and replace with a real path instead, as well as setting a name for the OST that does not already exist in that location. When it asks to create a new OST, click Yes. Finish the profile creation and set it to open when Outlook is next opened. The error message should generally be resolved by this step.
  • Shutdown Outlook and rename the OST file. Restart Outlook and check if the issue reoccurs. Note: If the user has been writing to their OST and it has not been synchronised to the server, you will lose this information. Try to determine first if this is the case.
  • Create a new Outlook profile.
  • If the user is running Outlook 2003, you may try upgrading to Office 2007. This has been proven to resolve some OST issues (where the OST itself does not appear to be at fault).
  • Try performing an uninstall and reinstall of Office. This has been proven to not resolve some OST issues.
  • Empty out the deleted items folder. Deleted items may have become corrupted or too large.
  • Remove any delegates on the mailbox. Delegates may have become corrupted and/or orphaned.
  • Export any inbox rules and then delete what is there. Rules can become corrupted. These can be re-imported when testing is complete.
  • Right click on a folder in Outlook and select properties. Select the synchronisation tab and check if the folder has synchronised successfully. If the synchronisation tab is not available then you may not be in cached mode. See KB842284. To synchronise all folders, press Send/Receive All. To synchronise just a single folder, select the folder and select Send/Receive this folder only.
  • Replace the Exchange server service support files for Outlook. In Office 2007, rename the C:\Program Files\Microsoft Office\Office12\emsmdb32.dll. Go to Add/Remove Programs, select Reinstall or repair, then Reinstall. In Offce 2003 you should rename emsabp32.dll, emsmdb32.dll, emsui32.dll, then reinstall Office. See KB842284.
  • Try running the OSTScan tool to check for corruption. Run without the automatic repair first. It will create a report in the deleted items folder. Check the report for issues. Rerun the tool in repair mode if required. See http://office.microsoft.com/en-us/outlook-help/scan-and-repair-corrupted-outlook-data-files-HA010075831.aspx?pid=CH100788841033#BM2
  • Try moving the mailbox to a new Exchange server if this is an option.