Exchange 2010 (Web-based distribution issue, Outlook download OAB issue)
-
Wednesday, January 04, 2012 10:57 PM
Hello,
We recently added an Exchange 2010 server to our organization, have moved all users and public folders over from the Exchange 2007 server. We have not yet decommissioned the Exchange 2007 server. We are having two issues.
*Note: Outlook 2010 is running in cached mode.
The first issue: Enabling Web-based distribution for the Offline Address Book prevents Outlook from downloading the OAB. The only way we can get Outlook to download the OAB is to make sure public folder distribution is enabled, and web-based distribution is disabled. Otherwise it sits there saying "Processing" and never completes the OAB download, and eventually, it just gives up.
Second issue: Outlook is not automatically updating the Offline Address Book (when we have public folder distribution enabled). If you force a Send/Receive Groups (Download Offline Address Book), it does download it. So Exchange is properly updating, Outlook is not properly downloading it by itself.
Previously the Exchange 2007 server would automatically update Outlook after an hour or two. When adding new users to Exchange 2010, they don't appear. That's when I decided to force Outlook to update, and it will download the latest.Is this an Exchange 2010 issue? Nobody has done anything with Outlook to have caused this. It only started after we upgraded to Exchange 2010.
- Edited by Ryan Moat Wednesday, January 04, 2012 11:24 PM
Answers
-
Thursday, February 02, 2012 9:06 PM
Hi Ryan,
Please try the following command, replacing the url for one that includes the internal name of your CAS server. Ensure that the internal name of the server can be resolved in DNS and that you can browse to the Url...
Set-AutodiscoverVirtualDirectory -Identity 'autodiscover (default Web site)' -InternalUrl 'https://exchangeserver.ourdomain.local/Autodiscover/Autodiscover.xml'
Please let me know how you do?
Kind Regards
- Marked As Answer by Ryan Moat Tuesday, February 07, 2012 5:52 PM
All Replies
-
Thursday, January 05, 2012 1:02 AM
Have you changed the generation server to the new 2010 server, and made sure default is set to true?
Also, what if any, messages are returned when you run the following command?
Update-OfflineAddressBook -Identity "Default Offline Address Book" -
Thursday, January 05, 2012 1:38 AM
Yes, the Default Offline Address List has the correct Generation Server, and the Default OAB is set to True on that server.
Interesting. When I did the Update-OfflineAddressBook -Identity "Default Offline Address Book", I get the following message:
The operation couldn't be performed because object 'Default Offline Address Book' couldn't be found on 'DomainControllerHostname.ourdomain.local'.
+ CategoryInfo : NotSpecified: (0:Int32) [Update-OfflineAddressBook], ManagementObjectNotFoundException
+ FullyQualifiedErrorId : 81D133A6,Microsoft.Exchange.Management.SystemConfigurationTasks.UpdateOfflineAddressBook.- Edited by Ryan Moat Thursday, January 05, 2012 1:46 AM
-
Thursday, January 05, 2012 1:52 AM
Oh, never mind. I knew something seemed wrong with that. I did a: Get-OfflineAddressBook.
It returned:
Name Versions AddressLists
------- ----------- ----------------
Default Offline Address List {Version4} {\Default Global Address List}So, if I do a: Update-OfflineAddressBook -Identity "Default Offline Address List", it works and I don't get errors. I guess we named the Address book differently. Hmm. Interesting.
-
Thursday, January 05, 2012 5:13 AMModerator
Hi Ryan,
I got a similar thread with you.
Please give it a try.
http://social.technet.microsoft.com/Forums/en/exchangesvrdeploy/thread/b1570f27-32cb-4843-ae14-47232cc7cf9aHope it helps.
Rowen
TechNet Community Support
-
Thursday, January 05, 2012 9:02 AM
Hello Ryan,
Please can you verify that the OAB URL used by the outlook client matches the defined OAB Url on the mail server.
On a client machine run the "Test Email Autoconfiguration" test by holding down CTRL while right clicking the outlook icon in the system tray. In the test results ensure the OAB URL matches the URL found under "Server Configuration > Client Access > Offline address book distribution tab > OAB Properties.
Kind Regards
-
Thursday, January 05, 2012 5:25 PM
Hello Ryan,
Please can you verify that the OAB URL used by the outlook client matches the defined OAB Url on the mail server.
On a client machine run the "Test Email Autoconfiguration" test by holding down CTRL while right clicking the outlook icon in the system tray. In the test results ensure the OAB URL matches the URL found under "Server Configuration > Client Access > Offline address book distribution tab > OAB Properties.
Kind Regards
Hello,
It doesn't. Well, because we have to use Public Folder Distribution, the "Test Email Autoconfiguration" shows the OAB URL as: Public Folder.
If we enable Web-Based Distribution, the URL shows up correctly; however, with Web-Based Distribution, Outlook won't download the OAB at all. With Public Folder distribution, you can at least tell it to download, and it will. -
Thursday, January 05, 2012 5:37 PMIt is possible my pollinterval is set too high. 480 (8 hours). I should drop that down. I noticed our old server was set at 240. Though I'm not understanding why Web-Based Distribution stops OAB download altogether. But if this works, this solves the Public Folder Distribution problem.
- Edited by Ryan Moat Thursday, January 05, 2012 5:40 PM
-
Thursday, January 05, 2012 10:17 PM
Hi Ryan,
Thanks for coming back. I was looking at resolving web based distribution of the OAB since it was more likely to be the more ideal resolution in many cases. Please can you also check to ensure that the OAB virtual directory is or is not locked down by SSL encryption. If it is then you shall need to ensure that the OAB URL discussed earlier is listed on your SSL certificate.
http://technet.microsoft.com/en-us/library/bb124085.aspx
Regards
-
Thursday, January 05, 2012 10:30 PM
I appreciate the reply. Okay, so the internal and external url for OAB is: https://Hi Ryan,
Thanks for coming back. I was looking at resolving web based distribution of the OAB since it was more likely to be the more ideal resolution in many cases. Please can you also check to ensure that the OAB virtual directory is or is not locked down by SSL encryption. If it is then you shall need to ensure that the OAB URL discussed earlier is listed on your SSL certificate.
http://technet.microsoft.com/en-us/library/bb124085.aspx
Regards
However, RequireSSL is set to False.
I believe we manually set it to be https://, because that was how our old Exchange 2007 server functioned. -
Thursday, January 05, 2012 10:53 PM
Ok, autodiscovery must be working correctly for the OAB to be accessible to the clients. Can you please run Get-AutodiscoverVirtualDirectory and verify that all internal/external URL's are correctly set?
I expect there are some errors within the synchronisation error folders in the mail client, please can you advise what errors these are?
Regards
-
Friday, January 06, 2012 12:19 AM
Interesting. When I do a Get-AutodiscoverVirtualDirectory, neither the old Exchange 2007 and new Exchange 2010 server have an InternalUrl or ExternalUrl. They both are blank.
In Outlook 2010, there are some Modification Resolution and Synchronization Logs. The Synchronization logs are the ones that contain an error:
16:41:01 Synchronizer Version 14.0.6109
16:41:01 Synchronizing Mailbox 'Ryan'
16:41:01 Synchronizing local changes in folder 'Junk E-mail'
16:41:01 Uploading to server 'exchangeservername.ourdomain.local'
16:41:01 Synchronization of some deletions failed.
16:41:01 [0-130]
16:41:01 1 item(s) deleted in online folder
16:41:01 DoneThe other Synchronization log has one difference, it is the Syncrhonizing local changes in folder 'Deleted Items', and it says 8 item(s) deleted in online folder.
-
Friday, January 06, 2012 8:16 AM
I was expecting to see different errors in the synch issues folders, some error numbers in relation to the failing of the OAB download. It's starting to look like autodiscover has not been configured but to see what extent of work is required you can test the autodiscover feature by using the following command..
Test-Outlookwebservices -clientaccessserver casservername
At the very least you shall have to add internal or external URLs to your exchange 2010 server depending on whether you have internal or external clients that need the autodiscover features.
Kind Regards
- Edited by AllBarOne Friday, January 06, 2012 8:23 AM
-
Friday, January 06, 2012 4:49 PM
Alright, I ran the Test-OutlookWebServices command. It came up with an error, and I realized I needed to create the TestCASConnectivityUser.
I see the following URLS:
Autodiscover: https://exchangeserver.ourdomain.local/Autodiscover/Autodiscover.xml
(A valid Autodiscover service connection point was found. The Autodiscover URL on this object is https://exchangeserver.ourdomain.local/Autodiscover/Autodiscover.xml)
(Contacted the Autodiscover service at https://exchangeserver.ourdomain.local/Autodiscover/Autodiscover.xml)
(The AS service is configured for this user in the Autodiscover response received from https://exchangeserver.ourdomain.local/Autodiscover/Autodiscover.xml)
(The OAB service is configured for this user in the Autodiscover response received from https://exchangeserver.ourdomain.local/Autodiscover/Autodiscover.xml)
(The UM Service is configured for this user in the Autodiscover response received from https://exchangeserver.ourdomain.local/Autodiscover/Autodiscover.xml)There are three other AS, OAB, UM messages like those above. They all say Type : Success.
It also says Autodiscover was tested successfully.
These messages follow:
[EXCH] Successfully contacted the AS service at https://exchangeserver.ourdomain.local/EWS/Exchange.asmx
[EXCH] Successfully contacted the UM service at https://exchangeserver.ourdomain.local/EWS/Exchange.asmx
[EXCH] Successfully contacted the AS service at https://mail.ourdomain.com/ews/exchange.asmx
[EXCH] Successfully contacted the UM service at https://mail.ourdomain.com/ews/exchange.asmx
[EXCH] Successfully contacted the AS service at https://exchangeserver.ourdomain.local/EWS/Exchange.asmx
[EXCH] Successfully contacted the UM service at https://exchangeserver.ourdomain.local/EWS/Exchange.asmx- Edited by Ryan Moat Friday, January 06, 2012 5:21 PM
-
Friday, January 06, 2012 5:22 PM
Run the new-TestCasConnectivityUser.ps1 script from the scripts folder on the exchange 2010 server, it is located inside the exchange installation folder, the default location would be C:\Program Files\Microsoft\Exchange Server\V14\
Then run the test-outlookwebservices command again.
Regards
-
Friday, January 06, 2012 6:18 PM
Ah, it looks like you saw my old post before I was able to change it. Yes, I went and created this user. The quote above shows what was returned.Alright, I ran the Test-OutlookWebServices command. It came up with an error, and I realized I needed to create the TestCASConnectivityUser.
I see the following URLS:
Autodiscover: https://exchangeserver.ourdomain.local/Autodiscover/Autodiscover.xml
(A valid Autodiscover service connection point was found. The Autodiscover URL on this object is https://exchangeserver.ourdomain.local/Autodiscover/Autodiscover.xml)
(Contacted the Autodiscover service at https://exchangeserver.ourdomain.local/Autodiscover/Autodiscover.xml)
(The AS service is configured for this user in the Autodiscover response received from https://exchangeserver.ourdomain.local/Autodiscover/Autodiscover.xml)
(The OAB service is configured for this user in the Autodiscover response received from https://exchangeserver.ourdomain.local/Autodiscover/Autodiscover.xml)
(The UM Service is configured for this user in the Autodiscover response received from https://exchangeserver.ourdomain.local/Autodiscover/Autodiscover.xml)There are three other AS, OAB, UM messages like those above. They all say Type : Success.
It also says Autodiscover was tested successfully.
These messages follow:
[EXCH] Successfully contacted the AS service at https://exchangeserver.ourdomain.local/EWS/Exchange.asmx
[EXCH] Successfully contacted the UM service at https://exchangeserver.ourdomain.local/EWS/Exchange.asmx
[EXCH] Successfully contacted the AS service at https://mail.ourdomain.com/ews/exchange.asmx
[EXCH] Successfully contacted the UM service at https://mail.ourdomain.com/ews/exchange.asmx
[EXCH] Successfully contacted the AS service at https://exchangeserver.ourdomain.local/EWS/Exchange.asmx
[EXCH] Successfully contacted the UM service at https://exchangeserver.ourdomain.local/EWS/Exchange.asmx
-
Friday, January 06, 2012 9:06 PM
Hi Ryan,
I am a bit surprised that it passed all tests when the previous test showed no internal or external URL. Something there does not quite add for me. Anyway going by the results you just posted the URL's are nicely in place, obviously the DNS names in these URL's appear on your SSL certificate?
Additionally can you open IIS, highlight the OAB virtual directory in the left pane and then on right open "authentication" > ensure that "windows authentication" is the enabled authentication method?
It might prove useful to use the following and report your findings: Get-OABVirtualDirectory
Please check and confirm that the DNS zone that contains the exchangeserver.ourdomain.local DNS record has the same DNS name as is used generally in users primary email addresses?
In your browser please visit https://exchangeserver.ourdomain.local/Autodiscover/Autodiscover.xml You shall be prompted for auth and then presented with a bunch of xml stuff.
Let me know you do & have a good weekend.
-
Friday, January 06, 2012 11:06 PM
Hi G B Fraser,
Thank you for your speedy responsiveness. I appreciate it. I do agree that something quite isn't right. Honestly, it should work. But something doesn't quite add up.
Okay, here are the results. I viewed the Exchange Subject Alternative Name for our Exchange Cert (not the self-signed).
Here is what we have for the cert:
DNS Name=mail.ourdomain.com
DNS Name=www.mail.ourdomain.com
DNS Name=autodiscover.ourdomain.com
DNS Name=exchangeserver.ourdomain.local
DNS Name=autodiscover.ourdomain.local
DNS Name=exchangeserver <---Just the host name.
OAB Authentication settings:
With the Get-OABVirtualDirectory it shows both the Exchange 2007 and Exchange 2010 server.
Server Name Internal URL External URL
EXCH07 OAB (Default Web Site) https://oldmailserver.ourdomain.local/oab https://mail.ourdomain.com/oab
EXCH10 OAB (Default Web Site) https://exchangeserver.ourdomain.local/oab https://mail.ourdomain.com/oab
I also visited both the https://exchangeserver.ourdomain.local/Autodiscover/Autodiscover.xml and https://mail.ourdomain.com/Autodiscover/Autodiscover.xml websites, and as you said it brought up a login prompt, and an XML page after I logged in.
Interesting...
- Edited by Ryan Moat Friday, January 06, 2012 11:11 PM
-
Friday, January 06, 2012 11:28 PMAlso, I checked the Address Book. A change that I made yesterday did update in the Address Book. It looks like the PollingTime change did make Public Folders update. Though, still, Web-Based Distribution is our preferred method and not Public Folders.
-
Friday, January 06, 2012 11:33 PMHi,
You need to enable BasisAuthentication so do that in EMS.
Get-OabVirtualDirectory | Set-OabVirtualDirectory -BasicAuthentication $True
Note: It's never a good practice to configure any kind of authantication in IIS, when it comes to Exchanges viritualdirectories.
If you have configured redirection in IIS for the Default Web Site, you need to make sure that "Authenticated Users" has read & execute permission on the file web.config that you will find in "C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\OAB" (only if redirection has been configured)
Martina Miskovic - http://www.nic2012.com/ -
Friday, January 06, 2012 11:34 PM
Hi,
Good to know. Thanks Martina.
You need to enable BasisAuthentication so do that in EMS.
Get-OabVirtualDirectory | Set-OabVirtualDirectory -BasicAuthentication $True
Note: It's never a good practice to configure any kind of authantication in IIS, when it comes to Exchanges viritualdirectories.
If you have configured redirection in IIS for the Default Web Site, you need to make sure that "Authenticated Users" has read & execute permission on the file web.config that you will find in "C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\OAB" (only if redirection has been configured)
Martina Miskovic - http://www.nic2012.com/ -
Friday, January 06, 2012 11:37 PM
Just for kicks, I disabled Public Folder Distribution, and enabled Web-Based Distribution. I did a "Test E-mail Autoconfiguration", and the OAB URL appears a little funky:
That /bf3ca425-5e8d-4e9f-af58-b6bb1654c80b/ might be the issue. Don't know why that is there.
OAB URL: https://exchangeserver.ourdomain.local/oab/bf3ca425-5e8d-4e9f-af58-b6bb1654c80b/
OAB URL: https://mail.ourdomain.com/oab/bf3ca425-5e8d-4e9f-af58-b6bb1654c80b- Edited by Ryan Moat Friday, January 06, 2012 11:38 PM
-
Friday, January 06, 2012 11:40 PM
Hi,
That looks good to me.
If you check folder where the oab has been downloaded on the client, it will also have that "funky" path.
C:\Users\<USER>\AppData\Local\Microsoft\Outlook\Offline Address Books\<GUID>
Well, basicauthentication has to be enabled :)
Martina Miskovic - http://www.nic2012.com/ -
Friday, January 06, 2012 11:42 PMIf you didn't update the Filedistribution files when you enabled webdistribution right now, I would recommend it.
Example: Update-FileDistributionService -Identity EX2010 -Type "OAB"
Martina Miskovic - http://www.nic2012.com/ -
Friday, January 06, 2012 11:46 PM
Hi Ryan, good news if it is working. I think we were thinking along similar lines for moment at least, all the checks we had ran through seemed to return positive values and I was hoping for a re test to ensure we still has an issue. To be sure... are cached mode clients now accessing the OAB?
Yes, I agree with Martina in that the OAB Url's look fine.
Kind Regards
- Edited by AllBarOne Friday, January 06, 2012 11:48 PM
-
Saturday, January 07, 2012 12:10 AM
Hi Ryan, good news if it is working. I think we were thinking along similar lines for moment at least, all the checks we had ran through seemed to return positive values and I was hoping for a re test to ensure we still has an issue. To be sure... are cached mode clients now accessing the OAB?
Yes, I agree with Martina in that the OAB Url's look fine.
Kind Regards
Hi G B Fraser,
Unfortunately no. It took a couple minutes for IIS / Exchange to update the change, and I replied before that change must have taken place. It couldn't download the OAB. I had to move it back to Public Folder Distribution.
-
Saturday, January 07, 2012 12:11 AMLet me change it back, and try the Update-FileDistributionService to see if that does anything different. I will report my findings...
-
Saturday, January 07, 2012 12:14 AMOne other tip is to recycle the application pool MSExchangeAutodiscoverAppPool in IIS.
That ususally trigger Outlook to get the new settings quicker.
Martina Miskovic - http://www.nic2012.com/ -
Saturday, January 07, 2012 12:16 AM
After running the Update-FileDistribtuionService command, Outlook is at least giving an error now instead of sitting there for several minutes before failing:
-
Saturday, January 07, 2012 12:18 AMAfter waiting a few more minutes, it just sits at: Progress Processing. No errors. No progress bar. No downloading of the OAB.
It just says Offline address book Connecting to Microsoft Exchange.- Edited by Ryan Moat Saturday, January 07, 2012 12:19 AM
-
Saturday, January 07, 2012 12:22 AM
You do have an OAB configured on all your databases?
Get-MailboxDatabase | ft Name,OfflineaddressbookWas the filedistribution files updated successfully?
Check in: C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\OABAfter you enabled basicauthentication, did you run an IISReset?
Did you recycle the applicationpool MSExchangeAutodiscoverAppPooland restart Outlook?
Martina Miskovic - http://www.nic2012.com/ -
Saturday, January 07, 2012 12:27 AMPlease confirm that you have an "A" record for "autodiscover" in the ourdomain.com or ourdomain.local
dns zones?- Edited by AllBarOne Saturday, January 07, 2012 12:30 AM
-
Saturday, January 07, 2012 1:06 AM
Martina and G B Fraser,
Yes, that is correct. The correct database and default offline address book are associated with each other and set as default. This is the result of the Get-MailboxDatabase | fl Name,OfflineAddressBook cmdlet:
I see 110 LZX files and an oab.xml file in the ClientAccess\OAB\bf3ca425-5e8d-4e9f-af58-b6bb1654c80b folder.
I have BasicAuthentication set to True through the Exchange Shell. I also did an IISReset. I also recycled the applicationpool MSExchangeAutodiscoverAppPool, restarted Outlook.
The task bar icon states: "Microsoft Outlook is syncing folders." (Looks like it is trying to download the address book, but isn't successful, otherwise it wouldn't say that).
When I manually do the download OAB, it sits there at processing, but doesn't budge. I have left it here sitting for about 10 minutes and it is still in the same state as it was. Just doesn't make sense.G B Fraser, yes here is the current "A" record:
-
Saturday, January 07, 2012 1:09 AMOk, good that the files were created.
Did you have redirection configured in IIS?
Martina Miskovic - http://www.nic2012.com/ -
Saturday, January 07, 2012 2:15 AM
Ryan,
Just to be sure, that A record IP points at the exchange 2010 cas? and the name of that DNS zone the A record resides in must match the @yourdomain.com part of users email addresses?
Also, the 2010 exchange server is now holding all roles, yes? So that ClientAccess\OAB\bf3ca425-5e8d-4e9f-af58-b6bb1654c80b path you gave us was on the exchange 2010 server where the cas is correct? I ask because the OAB is created on an mbx server and pulled over to the CAS where clients access it or at least thats how it works in an environment where the mbx and cas roles are split. The guid in bold shown here is the objectguid value of the OAB. There should be a folder by this "guid" style name on the mbx server and the cas servers (if these roles are split).
Additionally and unless comfortable with adsiedit be careful, note the bf3ca425-5e8d-4e9f-af58-b6bb1654c80b Guid above, open adsiedit.msc on a DC and within the configuration partition drill down to CN=Services, CN=Microsoft Exchange, CN=Messaging Organization, CN=Address Lists Containers, CN=Offline Address Lists. Check if there is an entry called CN=Default Offline Address Lists. Open the properties of it if so and verify that the objectGUID value matches the guid in bold above.
Kind Regards
-
Tuesday, January 10, 2012 8:08 PM
Martina and G B Fraser,
I apologize for the delay. Conference time at work, so it is a little busy. Alright, Martina, yes it is good that the files were created. Please remind me about the redirection. Do you mean HTTP Redirect for OAB? If so, that is not enabled in IIS.
G B Fraser, yes, that A record points directly to the IP of the Exchange 2010 server. It is in the ourdomain.local Forward Lookup Zone, which should be correct. That is also correct that the 2010 exchange server is holding all of the roles, except for the Edge Transport role.
I checked ADSIEDIT, and drilled down into that location. The objectGUID is correctly showing.
-
Tuesday, January 10, 2012 8:16 PMHi,
About my question about redirection, I will quote myself :)
If you have configured redirection in IIS for the Default Web Site, you need to make sure that "Authenticated Users" has read & execute permission on the file web.config that you will find in "C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\OAB" (only if redirection has been configured)
...it's also important that the inherited redirection is removed the the OAB Virutualdirectory, but it seems that you have checked that already.
Martina Miskovic - http://www.nic2012.com/ -
Tuesday, January 10, 2012 8:46 PM
Hi Ryan,
Please check this link re the DNS A record which suggests the A record exist within the DNS zone that matches the extension of users email addresses...
To resolve this issue, add a host (A) record in DNS for Autodiscover.domain.com and point to the Exchange 2007 server that has the Client Access server role. For example, if the user’s primary SMTP address is user@contoso.com, the host (A) record you need to add is: autodiscover.contoso.com A <IPaddress>.
From: http://technet.microsoft.com/en-us/library/cc411331(EXCHG.80).aspx
I appreciate that this relates to exchange 2007 but I think it is forward compatible with 2010.
Kind Regards
-
Friday, January 13, 2012 1:01 PM
Hi Ryan,
Is there any update to this scenario? My above post links to an MS article that suggests you should have an internal DNS zone that matches the domain name used in users primary smtp email address. The autodiscover A record should reside inside that zone rather than your .local domain.
Kind Regards
-
Friday, January 20, 2012 5:20 PM
Thanks Martina and AllBarOne (G B Fraser) for the replies and follow-up.
I apologize for the delay! Alright, so web.config did not have a Security Permission for the Authenticated Users. I added that. AllBarOne, we are checking into the A record for our .com domain. It is possible it was deleted. I notified the System Admin for our .com to check. I will report back with my findings.
Thanks,
Ryan
-
Friday, January 20, 2012 5:49 PMIt looks like our .com has an A record, pointing to the public IP of our mail server. It should work. I haven't yet tried enabling web-based distribution after giving "Authenticated Users" Read & Execute permissions on the web.config, yet.
-
Friday, January 20, 2012 6:58 PM
Hi Ryan, welcome back
If Martina's suggestion does not resolve the issue I would be interested to know if web based distribution works when the autodiscover.domain.com A record points at the "internal" IP address of your CAS server instead of your public IP?
Kind Regards
-
Tuesday, January 24, 2012 7:09 PMOk. I was able to try it. Still no luck. Unfortunately for DNS, we are using a public DNS service like GoDaddy, so having the .com autodiscover point to our internal mail server wouldn't work.
- Edited by Ryan Moat Tuesday, January 24, 2012 7:11 PM
-
Tuesday, January 24, 2012 8:39 PM
Hi Ryan,
So your working and testing this solution with external client machines? I was working on the assumption that you were testing with internal clients that had outlook set to work in cached mode as this would be the easier form of testing, sorry. Obviously internal clients shall not download the oab without an internal DNS record in the appropriate internal DNS zone.
Please can you confirm if you suffer this issue with internal, external or both types of clients?
Kind Regards
-
Tuesday, January 24, 2012 10:45 PM
No, you're right, I am testing this solution on internal client machines. Outlook is set to work in cached mode. We do have an internal DNS autodiscover record.
I think I was just a little confused by what you mentioned: "My above post links to an MS article that suggests you should have an internal DNS zone that matches the domain name used in users primary smtp email address. The autodiscover A record should reside inside that zone rather than your .local domain."
-
Wednesday, January 25, 2012 2:27 PM
Hi Ryan,
Please can you open up outlook on a client machine that fails to download the oab. Then bottom left click on the folder icon to display all folders in the mailbox your looking at. In the left pane you shall find a folder called "synch issues", this folder has 3 sub folders, conflicts, local failures and server failures. Please look inside these folders and report back on the errors you find?
Kind Regards
-
Wednesday, January 25, 2012 8:18 PMAlright, so it has been trying to download the address book for 25 minutes. Still no sync issues appearing, but it still is in the "Processing" state, so there haven't been any errors yet. I've noticed some oddities... the public url to webmail completely stops working after enabling web-based distribution. I realized this, because I wanted to send an email through webmail, and the site never loads unless I turn off web-based distribution.
-
Monday, January 30, 2012 10:28 PM
Hi Ryan,
Sorry for the delay, is this still a problem?
I notice that you had http redirection enabled previously and if this was still the case it would potentially explain a lot... http://social.technet.microsoft.com/Forums/da-DK/exchange2010/thread/054edf2c-0aa1-41a9-a71b-3885ab72ff9b Please remember that redirection occurs at the top of the chosen web site as well as on virtual directories within it so please verify no redirection is taking place at all.
To bring myself back up to speed I have reviewed the thread again and would like to know if you get the correct internal and external urls when running Get-AutodiscoverVirtualDirectory? I ask because I see you returned no urls on Jan 6th and I'm unsure if we addressed that point you made.
Kind Regards
-
Thursday, February 02, 2012 7:24 PM
To bring myself back up to speed I have reviewed the thread again and would like to know if you get the correct internal and external urls when running Get-AutodiscoverVirtualDirectory? I ask because I see you returned no urls on Jan 6th and I'm unsure if we addressed that point you made.
Kind Regards
Thank you for the reply. Yes, I somewhat had forgotten. If I do a Get-AutodiscoverVirtualDirectory, there are no internal URLS listed. It is blank.
- Edited by Ryan Moat Thursday, February 02, 2012 7:25 PM
-
Thursday, February 02, 2012 9:06 PM
Hi Ryan,
Please try the following command, replacing the url for one that includes the internal name of your CAS server. Ensure that the internal name of the server can be resolved in DNS and that you can browse to the Url...
Set-AutodiscoverVirtualDirectory -Identity 'autodiscover (default Web site)' -InternalUrl 'https://exchangeserver.ourdomain.local/Autodiscover/Autodiscover.xml'
Please let me know how you do?
Kind Regards
- Marked As Answer by Ryan Moat Tuesday, February 07, 2012 5:52 PM
-
Tuesday, February 07, 2012 5:54 PMIncredible! Thank you so much, that was the answer. I do appreciate every bit of help. Thank you, thank you! Not exactly sure why the AudodiscoverVirtual Directory was blank, but that fixed.
-
Tuesday, February 07, 2012 7:11 PM
Brilliant, well done for the depth of information you provided which in the end was the reason we reached a conclusion.
All the best Ryan.
Regards

