We help IT Professionals succeed at work.

Check out our new AWS podcast with Certified Expert, Phil Phillips! Listen to "How to Execute a Seamless AWS Migration" on EE or on your favorite podcast platform. Listen Now

x

can't see free/busy information for users in another site...

willlandymore
on
Medium Priority
1,465 Views
Last Modified: 2012-05-11
I have an Exchange 2010 SP1 box here in our location and if you open the scheduling assistant for an appointment you can see all of the local users as intended. However, we have another AD site with another Exchange box and if you enter a user from that DB it will show up with the / / / / / /
through it and say:

"No free/busy information could be retrieved"

This is a very slow WAN link but since all e-mail relaying works between the boxes I couldn't see this as being the issue.
I have also been into the Public Folder Management Console and the free/busy (public folder DB's) from each server are replicating to each other so shouldn't I be able to see the information about all users in the Exchange organization?
Comment
Watch Question

Author

Commented:
one other thing....

we have two servers in a DAG and this behavior only seems to show up if we fail over to the other box.

What commands can I run to set the URL for autodiscover so that I can run it on both servers to make sure they're using the same URL?
where are your cas servers located?
run the following and attempt to connect to the url using ie
get-oabvirtualdirectory | fl internalurl

Author

Commented:
one CAS server is in one site and then the other is in the other site across that WAN link.

The get-oabvirtualdirectory command seems to just sit there forever and not return anything though....

Try the cmdlet again with
-server casname

Author

Commented:
okay, one returned:

http://alias.domain.com/OAB

and the other was:

http://server.domain.com/OAB

The primary server where the DB is mounted has that generic alias and the other one is just using the hostname.
Do you see these URLs @ the InternalURL correct?

At your "Exchange Management Console"
Organization Configuration
Mailbox
"Offline Address Book"
What is the "Distribution Mechanism"?
Is that an "Web-Based" alone? or both Public and web-based?

Author

Commented:
they are all Public and Web-based....
1. Can you share the results of the "Test email autoconfiguration" from few affected client machines?


Outlook "Test email autoconfiguration"
Add any "E-mail address"
clear the "Use Guessmart" and "Secure Guessmart Authentication"
Click Test
Concentrate on the Results and Log tabs

2. On those affected machines, can we access the OAB URLs?
If the OAB URL is something like this
http://xxx.com/OAB/b4a6e051-183f-429a-b2d5-90873e30067c

Add the Oab.xml @ the send and see the results.
http://xxx.com/OAB/b4a6e051-183f-429a-b2d5-90873e30067c/oab.xml

Author

Commented:
The autodiscover found the settings very quickly and displayed successfully.

The only thing that I wasn't sure about was the OOF and OAB.

For the OAB URL it's listing the primary DAG member (which is fine) but for the OOF one it's displaying the secondary box.

The URLs are accessible from the machines...
Do have the IIS\CAS on the "primary DAG member"?

If yes
Can you check if the files @ the servers are good\correct?

C:\Program Files\Microsoft\Exchange Server\ExchangeOAB --> should be the place for the MBX server OAB files

Also do check @
C:\Program Files\Microsoft\Exchange Server\ClientAccess\OAB\b4a6e051-183f-429a-b2d5-90873e30067c

--> this should be the place for the CAS server OAB Files (web distribution)

Note: the GUID would be different @ your place

Author

Commented:
yes, ISS/CAS is on the primary DAG member.

yes, that path is there (except is has the v14 folder after the Exchange Server one) and has the OAB files within.

Yes, the other path is there with GUID folder and the LZX files in there

Author

Commented:
one thing about this really slow link...they have a different OAB on their side, but that's why I added the SCHEDULE + FREE BUSY folder to the replication so it went to both.

Could it be that it just hasn't had time to make it across? If it has to send the whole thing that could take a while over this link

Author

Commented:
I also checked out the OAB's we have and when I click on the one in the other location and then the 'distribution' tab I get:

"Error found when loading objects, please use command line to edit query full list. Error: an IIS directory entry could not be created. The remote procedure call failed and did not execute."
Looks like the web-distribution got some issues:

>> can you do a physical examination @ the OAB V.directories


we can delete and recreate the OAB virtual directories using the commands

remove-oabvirtualdirectory
and
new-oabvirtualdirectory

Author

Commented:
I found that in the .../ClientAccess/OAB folder the web.config file did not have read for everyone on it. Once I changed that on the other server I can browse to the https://server/oab and I get the same response from that one as I do from ours. Before it was giving me a 500 error.

Now when I put in a user in the other location the 'no information' comes up instantly and before it took a long time. I'm going to see if it will send the information over from the other box and wait for a little....

I'll let you know if there is a change.

Author

Commented:
now when you enter a person from either location it brings up the lines for them and then puts a string beside their name (which never happened before) which has something like /o=domain.com/ou=recipients/cn=persons name
Unlock this solution and get a sample of our free trial.
(No credit card required)
UNLOCK SOLUTION

Author

Commented:
worked like a charm
Unlock the solution to this question.
Thanks for using Experts Exchange.

Please provide your email to receive a sample view!

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

OR

Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.