Sharing of calendars is not working.

[JCool]

We have spent a couple of days looking on the forums and the
internet for typical reasons this problem occurs with Zimbra
installations. In particular, we've review LHammond's
detailed install on Ubuntu 10.04 LTS.

We're running Zimbra 8.0 on a Ubuntu 12.04 virtual machine (VMWare) on Windows 7

Our deviations from default install include:

MTA: We wanted to be sure to avoid any interaction with
our production email, so during the install we declined
to change the domain to one which has an MX record.

We made the two changes indicated for this situation:
uncheck "Enable DNS lookups" and set "Relay MTA for external
delivery" to our production MTA. I also changed "Web mail MTA Hostnames"
from localhost to the name of our production MTA.

Default COS: Was not set. Set it to "default" just in case.


Problem: Can't set default user personal calendar to shared.


Settings: The default COS has all Features on except-
Briefcase, Dumpster folder, Mail send later, SMS reminders,
and Enable S/MIME.

The users in question have their COS explicitly set to "default"


So far we've tried:

o rt-click calandar and select "Share calendar". Doesn't
work, selection is greyed-out.

o rt-click calandar and select "Properties / Edit Properties",
click "Add Share..."

When we used "Share with": Internal or External

Share Properties contains this odd information:

To allow others to access this item, direct them to this URL:
ICS: null/service/user/local@host.local/Calendar
View: null/service/user/local@host.local/Calendar.html

We see:

An unknown error (mail.TRY_AGAIN) has occurred.

An unknown error (mail.TRY_AGAIN) has occurred.
method: [unknown]
msg: try again: Unable to connect to the MTA
code: mail.TRY_AGAIN
detail: soap:Receiver
[...]


When we used "Share with": Public

Share Properties prompt contains these odd URLs recommendations:

To allow others to access this item, direct them to this URL:
ICS: null/service/user/local@host.local/Calendar
View: null/service/user/local@host.local/Calendar.html

We see:

An unknown error has occurred.

An unknown error has occurred.
msg: configuration error: incorrect mailbox class: LocalMailbox
code: offline.MISCONFIGURED
detail: soap:Receiver
...

Has anyone seen a similar situation and solved it?

Thank you

[phoenix]

MTA: We wanted to be sure to avoid any interaction with
our production email, so during the install we declined
to change the domain to one which has an MX record.

Then you didn't read the documentation, I guess. It is required that your server has valid DNS A & MX records and also a correct /etc/hosts file. If you wish to avoid any 'interaction' with your production server then use a Split Domain (details in the wiki article of that title).

[JCool]

Hello Bill.

Thanks for the feedback.

The ZCS system does have an A record and /etc/hosts configured. So far all other Zimbra Desktop and administration operations are functioning. This includes e-mail via our production relay MTA. Sharing calendars is the only problem we have run into.

If shared calendars depends on e-mail functioning, we appear to have that requirement covered.

I should have mentioned that this is just an evaluation setup.

It appeared to us the scenario we are attempting was supported given the following information for "Configure DNS":

You must configure a relay host if you do not enable DNS. After ZCS is
installed, go to the Global Settings>MTA tab on the administration console and
uncheck Enable DNS lookups. Enter the relay MTA address to use for external
delivery.
Note: Even if a relay host is configured, an MX record is still required if the
ZCS server is going to receive email from the Internet.

and the instructions "Installing Zimbra Software" indicate the MX record is a suggestion. The relay MTA scenario appeared to be supported.

We'll take another pass in an additionally isolated environment.

[justdave]

What we do for our evaluation/staging environment is just use a different domain name for the staging server, so that we can actually send mail to/from it and not have DNS confused. In our case it's not advertised in the public DNS, but only on our internal DNS, since we're only testing it internally anyway. While technically you don't need the mail routable, having the DNS stuff actually set up correctly (albeit with a different domain name) ensures a closer match with the configuration we use in the production cluster (and what you would eventually use when you deploy it to production since you're just evaluating). If our production domain name is "domain.com" our staging server is "mailstaging.domain.com" for example.