Situation
I just spent the last 3-4 hours doing this research for some random issues as listed below. What resulted was a pretty comprehensive Tshoot OAB/GAL issues outline. Thought I would share.
Issue is (seemingly) random users get created but never show in the GAL – no pattern.
Issue is (seemingly) random users cannot see all users in GAL – no pattern.
- If you create a brand new Outlook profile on a newly installed client with a newly created account, in cached mode, are you able to download a full OAB successfully (this happens automatically with a new OL profile).
o If yes, do you see the "missing" account ?
o If yes, then the OAB is the correct one, and is correctly being updated.
- If no, you have a problem with syncing your OAB. It should point only to the GAL and if it does, and there are no sync errors, it MUST contain the errant account if this appears correctly in the GAL.
The answer to the short experiment above drives which of the following choices to pursue.
1. Can you see the Contact if you turn off Outlook Cached Mode?
2. Does the Contact resolve in Outlook Web Access?
3. Can others see the Contact?
4. Ensure that the user’s default external e-mail address and the windows e-mail address (AD attribute) are exactly the same.
5. If you have a client in cached mode that is not updating the OAB, remove/rename *.oab files in their %userprofile%\Local Settings\Application Data\Microsoft\Outlook. Next time you start Outlook it will re-download the address book and create new OAB files. The problem was the oab files got corrupt and would not catch new updates.
6. If it continues to happen, try excluding these oab files from your anti-virus scanner.
7. Recreate the users Outlook Profile and download all the content fresh
8. folder underneath OAB named d33d3462-etc-etc where the OAB resides had read only permissions set for authenticated users. The OAB folder did not have that permission.
9. On the e2010 server, make sure the Microsoft exchange file distribution service is running.
10. Make sure the recipient that does not show up has an x500 address entry
11. Does anything show in a BPA from e2003?
12. Does anything show in a BPA from e2010?
13. Which server is the OAB generator? Anything in the event log there?
14. Make an e2010 server the OAB generator
a. Any ol2003? Then you need PF distribution
b. Only OL2007 or higher? Use e2010 and web distribution
These seem fairly on point:
The domain controller that you are using for OAB gen specified in the 9117
event isn’t seeing that user. Make sure there is not a 9325 in the
application log skipping him because of a bad attribute. You can download a
copy of OABInteg from http://code.msdn.com/oabinteg. Use an online profile
and run oabinteg /s:srvname /t:proxytest /v:2 /l and look at the errors in
the log.
Try deleting the user's oab files then have him redownload.
Go to C:\Users\username\AppData\Local\Microsoft\Outlook
Delete all files with .oab
Outlook, send\receive download address book.
Also did you move this user to another new mailbox store? If so make sure the mailbox store has been set to use the default OAB.
Exchange 2007/2010 Web services and Autodiscover Ultimate Troubleshooting Guide
I decided to put this ultimate guide to spare the hustle and allow smoother and nicer web services experience.
Well, let us first list the directories that are used in the Exchange web service:
· EWS is used for OOF, Scheduling assistance and free+busy Lookup.
OAB provides offline address book download services for client.
Autodiscover is used to provide users with autodiscover service.
EAS provides ActiveSync services to Windows Mobile based devices.
OWA provides outlook web access for users.
ECP provides Exchange control panel feature for Exchange 2010 users only.
Issues that might be resolved using the troubleshooting steps here:
· You cannot set the OOF using outlook client, you receive the server not available error.
You cannot view free/busy information for other users.
You cannot use scheduling assistance, also you might receive not free/busy information data retrieved.
You cannot download Offline Address book errors.
You cannot use autodiscover externally.
Certificate mismatch error in autodiscover, users prompted to trust certificate in outlook 2007/2010.
I will update this post to include all of the errors that I face and solve in my work or on EE to help experts all over EE to quickly solve their issues.
First let us start by the configuration required post Exchange 2007/2010 installation for the above to work correctly:
Configure External and Internal URLs for OWS, ref: http://technet.microsoft.com/en-us/library/bb691323(EXCHG.80).aspx
· You have to configure the internal URL to be the server name in case you have multiple servers in NLB.
External URL will be the URL used by users to access webmail e.g. https://mail.domain.com/owa
Mail.domain.com in multiple CAS servers will be the NLB FQDN.
Configure External and Internal URLs for OAB, ref: http://technet.microsoft.com/en-us/library/bb123710.aspx
This will point if multiple CAS servers are used then this will point to NLB FQDN.
If single server used this will point to the internal server FQDN in the internal URL, and the mail.domain.com which is used by webmail users.
Configure the autodiscover internal URL:
· You will use the powershell cmdlet : Set-ClientAccessServer –Identity <CAS Server Name> -AutoDiscoverServiceInternalUri: <Internal URL>, this FQDN must match the URL included in the certificate.
If you cannot use autodiscover.domain.com internally (you have a domain name of domain.local and you must use it), you will get a certificate miss match error, you will have to include the internal name in the certificate if you purchase an external certificate.
If you have multiple CAS in NLB this will be the NLB FQDN.
You cannot set autodiscover external URL since outlook will try to access https://autodiscover.domain.com/autodiscover/autodiscover.xml, this behavior is by design and cannot be changed.
Autodiscover.domain.com must be included in the certificate that you assign to IIS if you purchasing a certificate externally from 3rd party provider.
Configure EAS internal and External URLs, ref: http://technet.microsoft.com/en-us/library/bb629533(EXCHG.80).aspx
· This URL will point to the NLB FQDN internally
This IRL will point to NLB FQDN Externally.
Configure the EWS (which provides availability, OOF) internal and external URLs
· You can set the internal FQDN and External FQDN using: get-webservicesvirtualdirectory | Set-WebServicesVirtualDirectory –InternalUrl: https://url.domain.local/EWS/Exchange.asmx –ExternalURl: https://url.domain.com/EWS/Exchange.asmx
after all of the above settings you have to take into considerations the following note:
· All of the above uses https connection, so SSL certificate must be configured and assigned to IIS on the CAS servers.
Since all of the above uses https, if you have a proxy traffic might be affected.
Make sure that clients can access the URL internally and externally, you can do that by going to the above URL using IE or Firefox and validate that you can access them.
For some people after doing the above configuration you still receive some errors so make sure of the following:
· IIS is started.
OWA application pool, OAB application pool and EWS application pool are running and started with no errors
If you receive authentication error, error 500 service not available, error 400 login time out, or unspecified error you will need to rebuild your virtual directories. You can do that as following:
· For OWA:
Get-owavirtualdirectory | remove-owavirtualdirectory
New-owavirtualdirectory.
You can repeat this step for EWS (webservicesdirectory), OAB (OABvirtualdirectory) and autodiscover(autodiscovervirtualdirectory)
You will have to note that you will need to re-configure any customizations you made to OWA after removing and deleting it, also you will have to redo any internal and external URL configuration you have did in the past
Troubleshooting Offline Address Book Generation on Exchange 2010
After migrating from Exchange 2007 to Exchange 2010, we began noticing that address book downloads failed during a manual send/receive operation with:
‘error (0x8004010F) operation failed. An object cannot be found.’
Basically, this error is happening because Outlook 2007 and higher clients rely on web based distribution of the offline address book, and that address book is not found on the CAS Server.
The fix is to enable the Default Offline Address book on the mailbox server for Web-based distribution:
This setting does not go into effect immediately. If you want to force it to start working immediately, you need to perform these steps:
1) Update the address book
2) Restart the File Distribution Service on the CAS Server
Performing this step will cause the CAS to download a copy of the OAB from the Mailbox server, see this post for more info on the Exchange File Distribution service.
3) Force Active Directory to sync (repadmin /syncall /APed)
Now, when you force a send/receive from Outlook, the address book will download cleanly!
There are other reasons why clients may be getting error 0x8004010F, check out this post for more information: http://blogs.msdn.com/dgoldman/archive/2008/10/01/understanding-why-error-code-0x8004010f-is-thrown-when-trying-to-download-an-oab.aspx
Also, if you are getting Event 9320 in your event logs, you can safely ignore those per this blog:
No comments:
Post a Comment