Ajcody-Server-Issues-Being-Investigated: Difference between revisions

Line 17: Line 17:
  zmprov fc -a license
  zmprov fc -a license
  zmsoap -z GetLicenseRequest
  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====
====What Should Count Against License====

Revision as of 20:45, 9 February 2015

Attention.png - This article is NOT official Zimbra documentation. It is a user contribution and may include unsupported customizations, references, suggestions, or information.

Issues Being Investigated

Actual Server Issues Being Investigated Homepage

Please see Ajcody-Server-Issues-Being-Investigated

License Issues

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

Please see:

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

Please see:

Workaround is :

  • zmcontrol stop
  • zmcontrol start

Tested on 5.0.9

  • license count 5
    • created two resources
  • license count 7
    • zmcontrol stop
    • zmcontrol start
  • license count 5

Performance Issues When Using Mini-Cal And You Have zimbraMailCanonicalAddress Set To Domains You Don't Have

Background Bugs:

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
      •  ldap stop
      •  ldap start
    • zmlocalconfig -e zimbra_require_interprocess_security=0
    • To update the postfix configuration files.
      • /opt/zimbra/libexec/zmmtainit
    • To update amavis config files.
      • /opt/zimbra/libexec/zmmtaconfig amavis
    • 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.

Upgrade Issues

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

Please see:

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.

Jump to: navigation, search