Free/Busy across "corporate" and POP3 connections

[thorod36]

Environment is Exchange 2k on Win2k Advanced server and mix of OL2k, OLXP and
OL2k3 clients. Most users are outside network where Exchange resides and
connect with POP3 client. I am able to set up free/busy so that in testing
both local and POP3 clients save their calendars to an intranet server, and
on the POP3 client, I can retrieve the free/busy info in a meeting request.
the problem is in retrieving the info on the local (non-POP3) client when
trying to set up a meeting. I have used ftp and http locations for the
free/busy data. I have even tested using a shared directory. It appears
that the non-POP3 client doesn't even attempt to go to the http site as there
is no www log entry showing attempted access.

Essentially, POP3 clients can view the free/busy data but "Corporate"
clients cannot.

Any help is appreciated.

Thanks,
TR

 

[thorod36]

Some observations about what I think is happening:

"Corporate" (direct) connection to Exchange server uses the public folder
Schedule+ Free... for it's free/busy searches while the POP3 client has no
access to that folder so it will use the connection/location configured in
the Calendar options, Free/Busy section. (ie ftp://server/folder/%name%.vfb)

The Corporate client does not appear to search in the location configured in
the Calendar options even though it can update it's own information there.
(why is it available for this client if it isn't used?)

I have not found a way to sync the data in the 2 locations or at least
update the system Schedule+ folder with data from the free/busy search
folder.

This means that "corporate users" only see the free/busy data of other
"corporate users" while the POP3 users can see the free/busy times of any
user that sends their data to the proper location.

Therefore, if you have mixed "corporate" clients and POP3 clients you are SOL.

If you have any ways around or through these problems I appreciate your input.

Thanks,
TR

 

[thorod36]

Follow up on this:

I have found a work-around; The problem appears to be the GAL does not
include SMTP address info for the local accounts since it is not sending
those internal mails over the internet. By having "corporate" users set up a
Directory Account to LDAP on the server and using that address book to select
recipients of meeting requests, the SMTP address of the recipients is
included and the Internet Free/Busy location is searched.