- 1 Issues Being Investigated
- 1.1 Actual Server Issues Being Investigated Homepage
- 1.2 License Issues
- 1.3 Performance Issues When Using Mini-Cal And You Have zimbraMailCanonicalAddress Set To Domains You Don't Have
- 1.4 5.0.7+ Performance & Hanging Issues
- 1.5 Upgrade Issues
Issues Being Investigated
Actual Server Issues Being Investigated Homepage
Please see Ajcody-Server-Issues-Being-Investigated
Getting License Details Via Soap - Consumed Licenses
First, flush the cache on all servers for the license information. Then do the query via soap.
zmprov fc -a license zmsoap -z GetLicenseRequest
Two lines that are generally of interest are, for example :
<attr name="TotalAccounts">3</attr> <attr name="ArchivingAccounts">3</attr>
What Should Count Against License
Real accounts, as listed in admin console under Addresses > Accounts. The admin account will count against this but the ham, spam, and wiki ones will not.
Accounts or entries listed under : Aliases , Distribution Lists, Resources should not. See below for bug about Resources though.
Deleted Accounts Still Show In Use
- "deleted accounts don't update license count till server restart"
Another suggestion if zimbra restarts don't work, as zimbra:
zmprov fc license
When you have multi ZCS servers:
zmprov fc -a license
Resources Counting Against License
- "resources should not count against the licensed user count"
Workaround is :
Tested on 5.0.9
- license count 5
- created two resources
- license count 7
- license count 5
Performance Issues When Using Mini-Cal And You Have zimbraMailCanonicalAddress Set To Domains You Don't Have
Do you have any user's with the variable zimbraMailCanonicalAddress set using a domain that is not within your Zimbra infrastructure? There was case that had that set for a particular user to a domain they didn't have within Zimbra and the symptom showed as a performance issue within the mini-calendar & calendar. The root cause was actually the ldap lookups occurring in the background (those against the zimbraMailCanonicalAddress domain).
- One work around was setting:
zmlocalconfig -e ldap_starttls_supported=0
zmlocalconfig -e zimbra_require_interprocess_security=0
- To update the postfix configuration files.
- To update amavis config files.
- Then restart the system. Still need to double check this will be necessary.
- The other workaround was to remove the zimbraMailCanonicalAddress variable.
5.0.7+ Performance & Hanging Issues
Administrators might or might not catch this events being tied to calendars or ics data. Here's what I've gather from other cases so far about the issue, there's about 5 of them I've seen. None are resolved at this time (July 23, 08), so use with caution.
1. bug: http://bugzilla.zimbra.com/show_bug.cgi?id=29596 The resolution for this bug would involve an upgrade to 5.0.8 .
- One customer has reported the upgrade to 5.0.8 has resolved their issue so far. They also confirm that the ics files were being processed with much faster times as logged in mailbox.log
- Second customer has confirmed upgrade to 5.0.8 has resolved their issue.
2. Check a the thread dump if the message is getting stuck during an invite email delivery to a conference room. You can guess the calendar object based on the emails in the conference room's Inbox.
3. Also check their recurrence expansion configuration in LDAP with:
"zmprov gacf | grep zimbraCalendarRecurrence".
On a clean install you should see:
zimbraCalendarRecurrenceDailyMaxDays: 730 zimbraCalendarRecurrenceMaxInstances: 0 zimbraCalendarRecurrenceMonthlyMaxMonths: 360 zimbraCalendarRecurrenceOtherFrequencyMaxYears: 1 zimbraCalendarRecurrenceWeeklyMaxWeeks: 520 zimbraCalendarRecurrenceYearlyMaxYears: 100
If these are set to 0, the sysadmin enabled near-infinite expansion on purpose. If these are missing, it's an upgrade problem. The code will default the values to 0 and thus infinite loop. Set them to the above values to avoid long expansions.If these are set to 0, please set to the above values to avoid long exp.
- One customer has reported that the variables weren't set and they set them to the defaults. Restarted zimbra and issues appear to be resolved. They are holding off on 5.0.8 upgrade at this point.
4. Also you are might hitting bug ( http://bugzilla.zimbra.com/show_bug.cgi?id=28397 - this is a private bug) or something similar like this caused by an offending appointment. You can also find out the mailbox (conference room/user) and put it into maintenance mode to keep the mails flowing. Then try to flush the queue.
Please check the Support Portal page for the most recent issues related to newly released ZCS versions. That is were "issues" are generally posted when we discover "new" situations arising from newly released versions.
Very Long Upgrade Times
zmfixperms Causing Long Upgrade Times - HSM Configurations Effected Usually
- "zmfixperms : pass in directories not to touch OR don't include other dirs unless -extended specified"
Upper Case Hostname Causes Problems With Install/Upgrade
I believe this is new for version 5.0.8+. Until you adjust the case, the installer script will not continue. It's usually picking up the upper case hostname from the server's /etc/hosts entry. Please don't do this, use upper case in your hosts file ... Unix is not Windows.
- Make the install case insensitive on hostname