• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1343
  • Last Modified:

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

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?
0
willlandymore
Asked:
willlandymore
  • 12
  • 4
  • 2
1 Solution
 
willlandymoreAuthor 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?
0
 
endital1097Commented:
where are your cas servers located?
run the following and attempt to connect to the url using ie
get-oabvirtualdirectory | fl internalurl
0
 
willlandymoreAuthor 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....

0
Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

 
endital1097Commented:
Try the cmdlet again with
-server casname
0
 
willlandymoreAuthor 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.
0
 
e_aravindCommented:
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?
0
 
willlandymoreAuthor Commented:
they are all Public and Web-based....
0
 
e_aravindCommented:
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
0
 
willlandymoreAuthor 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...
0
 
e_aravindCommented:
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
0
 
willlandymoreAuthor 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
0
 
willlandymoreAuthor 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
0
 
willlandymoreAuthor 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."
0
 
e_aravindCommented:
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
0
 
willlandymoreAuthor 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.
0
 
willlandymoreAuthor 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
0
 
willlandymoreAuthor Commented:
seems to be something that can be fixed in Outlook. Found this thread on another forum that got it to work.
http://social.technet.microsoft.com/Forums/en-US/exchangesvrclients/thread/30669975-5c14-4ffd-b297-c767ded09625

Thanks for the help guys.
0
 
willlandymoreAuthor Commented:
worked like a charm
0

Featured Post

Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

  • 12
  • 4
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now