Free Busy - Troubleshooting: Difference between revisions
Line 3: | Line 3: | ||
<div class="col-md-12 ibox-content"> | <div class="col-md-12 ibox-content"> | ||
= Free/Busy Troubleshooting = | = Free/Busy Troubleshooting = | ||
{{KB|{{ | {{KB|{{Supported}}|{{ZCS 8.8}}|{{ZCS 8.7}}|{{ZCS 8.6}}|{{ZCS 8.0}}|}} | ||
==Purpose== | ==Purpose== | ||
Explain in deep level the Free/Busy Troubleshooting | Explain in deep level the Free/Busy Troubleshooting |
Revision as of 17:37, 12 February 2019
Free/Busy Troubleshooting
Purpose
Explain in deep level the Free/Busy Troubleshooting
Resolution
In the process of making the request for free/busy data, the code translates the request using the domain within the zimbraPublicServiceHostname. The domain that is set within zimbraPublicServiceHostname must be reachable. If not, the request will timeout and no data will be provided to the requester.
The ZCS server uses the zimbraMailTransport setting and fbqueue folder to obtain the Free/Busy data for an internal user. A successful lookup will write the following into the access.log
11.11.11.11 - - [10/Sep/2015:17:29:31 +0000] "GET /service/pubcal/freebusy.ifb?acct=User@domain.com&s=1436825927000&e=1442182727000 HTTP/1.0" 200 - "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:40.0) Gecko/20100101 Firefox/40.0" 411
If there is an issue with zimbraMailTransport or fbqueueue, the following error will occur within the mailbox.log on the server of the user who is making the request:
2015-07-23 13:11:34,082 ERROR [qtp509886383-85:https://10.999.99.99:8443/service/pubcal/freebusy.ifb?acct=user@domain.com&s=1437071121000&e=1442427921000] [] fb - can't find free/busy provider for user user@domain.com
If this issue occurs, you will need to insure that the zimbraMailTransport setting is correctly set for the user:
zmprov ga user@domain.com zimbraMailTransport
Also you will need to insure that zimbra user owns the fbqueue folder and it has read and write access to the folder.
/opt/zimbra/fbqueue
In the case where both accounts do not reside on the same server, you will need to insure that the system has the ability to send the request between each server. If port 8443/443 or 8080/80 is inaccessible then the attempt will also fail.
Each account has the ability to limit access to their personal Free/Busy data.
zmprov ga user@domain.com zimbraACE
- Don't let anyone see my free/busy information
zimbraACE: 00000000-0000-0000-0000-000000000000 all -viewFreeBusy
- Allow only users of my domain to see my free/busy information
zimbraACE: 7152f996-c550-400b-8090-500c3dab3272 dom viewFreeBusy
- Allow only users of internal domains to see my free/busy information
zimbraACE: 00000000-0000-0000-0000-000000000000 all viewFreeBusy
- Allow only the following internal users to see my free/busy information
zimbraACE: e7d68c77-6aad-4683-a845-74e64378faf6 usr viewFreeBusy
- If configuration is set to NULL or the following, it's set to "Allow both internal and external users to see my free/busy information":
zimbraACE: 99999999-9999-9999-9999-999999999999 pub viewFreeBusy
You can test going directory to the mailbox server by using the following example:
curl --insecure https://domain.com/service/pubcal/freebusy.ifb?acct=user@domain.com&s=<Start Time>&e=<End Time>
We have seen issues were data from an appointment can cause Free/Busy lookup issues. To insure that this is not occurring, you will need to export the calendar to an ICS file and import it into a test account. If Free/Busy issue still occur on the test account, please open a support case and include the ics file for review.
A request from the web client will use soap calls. Within /opt/zimbra/docs/soap-calendar.txt file there is an examples the soap call that is performed, the following is the snip it of the example:
// GetFreeBusyRequest // // (f)ree (b)usy busy-(t)entative busy-(u)navailable or (n)o-data elements // <GetFreeBusyRequest s="RANGE_START_MSECS_GMT" e="RANGE_END_MSECS_GMT" [uid="zimbraId/email,..."] // DEPRECATED // comma-separated list of zimraId or email // each value can be zimbraId or email [id="zimbraId,..."] // comma-separated list of zimbraId [name="email,..."] // comma-separated list of email // For accounts listed in uid/id/name above, f/b search will be done for all calendar folders. // To view free/busy for a single folder in a particular account, use the <usr> format below. [excludeUid="UID of appointment to exclude from free/busy search"] > [<usr [id="zimbraId] [name="email"] // either id or email must be specified [l="folder id"] // calendar folder id; if omitted, get f/b on all calendar folders />]* </GetFreeBusyRequest> <GetFreeBusyResponse> <usr id="id"> // id is always account email; it is not zimbraId as the attribute name may suggest <f s="START_MSECS_GMT" e="END_MSECS_GMT"/>* <b s="START_MSECS_GMT" e="END_MSECS_GMT"/>* <t s="START_MSECS_GMT" e="END_MSECS_GMT"/>* <u s="START_MSECS_GMT" e="END_MSECS_GMT"/>* // a.k.a. out of office <n s="START_MSECS_GMT" e="END_MSECS_GMT"/>* // could not retrieve data for that user </usr> <GetFreeBusyResponse>
The following is an example of a soap debug call that can be found within the mailbox.log:
2015-07-23 11:18:12,227 TRACE [qtp509886383-296252:https://10.999.99.99:8443/service/soap/GetFreeBusyRequest] [name=teater@domain.com;;mid=9;ip=10.99.99.805;ua=ZimbraWebClient - FF39 (Mac)/8.6.0_GA_1169;] soap - C: <soap:Envelope xmlns:soap="http://www.w3.org/2003/05/soap-envelope"> <soap:Header> <context xmlns="urn:zimbra"> <userAgent name="ZimbraWebClient - FF39 (Mac)" version="8.6.0_GA_1169"/> <session id="1569"/> <notify seq="1"/> <account by="name">tester@domain.com</account> <format type="js"/> <csrfToken>0_3e8691960c0f772884a1cb34c766a0f8f8ef09f1</csrfToken> </context> </soap:Header> <soap:Body> <GetFreeBusyRequest uid="user@domain.com" s="1437634800000" e="1437721200000" excludeUid="-1" xmlns="urn:zimbraMail"/> </soap:Body> </soap:Envelope>
Free/Busy issue from Zimbra Connector for Outlook (ZCO) =
If the system is configured for SSL, Outlook 2013 has a known bug that limits the free/busy string. Because of this, the URL that is created within Outlook during startup does not contain the session AUTHKEY. Do to the missing AUTHKEY, the request is coming from an unknown user and the request can fail do to ACE rules or the rejection of the URL. We are currently waiting for Microsoft to address this limitation.
The ZCO connector does not call Free/Busy information but sets the Free/Busy Search string within the client. Because of this, the ZCO debug logging will not contain any logging of obtaining free busy data. During the startup of Outlook the ZCO connector will reset the URL within File, Options, Calendar, Free Busy Options…
Free/Busy URL that's created during startup will resemble the following:
https://domain.com/service/pubcal/freebusy.ifb?acct=%name%@%server%&s=1432563654000&e=1437834054000&zauthtoken=<Token>
To test the URL the user or admin can update %name%@%server% with the email address of the user they wish to obtain Free/Busy data. For example:
https://domain.com/service/pubcal/freebusy.ifb?acct=user@domain.com&s=1432563654000&e=1437834054000&zauthtoken=<Token>
Then drop the string into any browser and an ics file should be downloaded to the system. Open the ice file and a successful download should contain data similar to the following
BEGIN:VCALENDAR PRODID:Zimbra-Calendar-Provider VERSION:2.0 METHODUBLISH BEGIN:VFREEBUSY ORGANIZER:mailto:user@domain.com DTSTAMP:20141112T012409Z DTSTART:20141029T180450Z DTEND:20141229T180450Z URL:https://mail.cumulusnetworks.com/service/pubcal/freebusy.ifb?acct=user@domain.com&s=1414605890000&e=1419876290000 FREEBUSY;FBTYPE=BUSY-TENTATIVE:20141029T200000Z/20141029T213000Z FREEBUSY;FBTYPE=BUSY-TENTATIVE:20141103T193000Z/20141103T210000Z FREEBUSY;FBTYPE=BUSY:20141105T170000Z/20141105T180000Z FREEBUSY;FBTYPE=BUSY-TENTATIVE:20141105T210000Z/20141105T223000Z FREEBUSY;FBTYPE=BUSY:20141106T160000Z/20141106T170000Z FREEBUSY;FBTYPE=BUSY-TENTATIVE:20141110T193000Z/20141110T210000Z FREEBUSY;FBTYPE=BUSY:20141112T170000Z/20141112T180000Z FREEBUSY;FBTYPE=BUSY-TENTATIVE:20141112T210000Z/20141112T223000Z
If the download does not contain the FREEBUSY data, then the issue is no on the Connector.
Additional Content
- Not additional content