https://wiki.zimbra.com/api.php?action=feedcontributions&user=Gren+Elliot&feedformat=atomZimbra :: Tech Center - User contributions [en]2024-03-29T00:05:46ZUser contributionsMediaWiki 1.39.0https://wiki.zimbra.com/index.php?title=CalDav_Support&diff=63466CalDav Support2017-04-13T17:09:37Z<p>Gren Elliot: /* CalDAV Support */</p>
<hr />
<div>{{BC|Community Sandbox}}<br />
__FORCETOC__<br />
<div class="col-md-12 ibox-content"><br />
=CalDAV Support=<br />
{{KB{{ZCS 8.7}}}}<br />
<br />
== RFCs supported by Zimbra's CalDAV implementation ==<br />
{| class="wikitable"<br />
! style="text-align:left;"| Standard ID<br />
! URL<br />
! Description<br />
|-<br />
| RFC 5545<br />
| https://tools.ietf.org/html/rfc5545<br />
| Internet Calendaring and Scheduling Core Object Specification (iCalendar)<br />
|-<br />
| RFC 2616<br />
| https://tools.ietf.org/html/rfc2616<br />
| Hypertext Transfer Protocol -- HTTP/1.1<br />
|-<br />
| RFC 2617<br />
| https://tools.ietf.org/html/rfc2617<br />
| HTTP Authentication: Basic and Digest Access Authentication<br />
|-<br />
| RFC 4918<br />
| https://tools.ietf.org/html/rfc4918<br />
| HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)<br />
|-<br />
| RFC 4791<br />
| https://tools.ietf.org/html/rfc4791<br />
| Calendaring Extensions to WebDAV (CalDAV)<br />
|-<br />
| RFC 6638<br />
| https://tools.ietf.org/html/rfc6638<br />
| Scheduling Extensions to CalDAV<br />
|-<br />
| RFC 5995<br />
| https://tools.ietf.org/html/rfc5995<br />
| Using POST to Add Members to Web Distributed Authoring and Versioning (WebDAV) Collections<br />
This is the preferred mechanism for creating new entries in the calendar. Using the PUT<br />
method with a final name that doesn't strictly match the form "<UID>.ics" will always fail.<br />
Using POST allows the server to choose the final name.<br />
|-<br />
| RFC 6764<br />
| https://tools.ietf.org/html/rfc6764<br />
| Locating Services for Calendaring Extensions to WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV)<br />
The Zimbra server implements the well-known URI for CalDAV. See section 9.1.1.<br />
This specification can also be useful as a reference for how to configure DNS to make<br />
client configuration easier.<br />
|-<br />
| RFC 5397<br />
| https://tools.ietf.org/html/rfc5397<br />
| WebDAV Current Principal Extension<br />
|-<br />
| RFC 5689<br />
| https://tools.ietf.org/html/rfc5689<br />
| Extended MKCOL for Web Distributed Authoring and Versioning (WebDAV)<br />
This is the preferred way to create new calendars<br />
|-<br />
| draft-daboo-caldav-extensions-01<br />
| https://tools.ietf.org/html/draft-daboo-caldav-extensions-01<br />
| Section 4 - supported-calendar-component-sets<br />
We use this because our calendar collections are typed. They can contain either<br />
events or tasks but not both.<br />
|-<br />
| RFC 3253 (partial)<br />
| https://tools.ietf.org/html/rfc3253<br />
| Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)<br />
See Section 3.6 (Report method) and 3.8 (DAV:expand-property Report)<br />
|-<br />
| RFC 3744<br />
| https://tools.ietf.org/html/rfc3744<br />
| Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol<br />
|-<br />
| caldav-proxy (Apple extension)<br />
| https://github.com/apple/ccs-calendarserver/blob/master/doc/Extensions/caldav-proxy.txt<br />
| Calendar User Proxy Functionality in CalDAV<br />
|}<br />
<br />
=== Known limitations ===<br />
<br />
# Attachments are not currently supported via the CalDAV API. Attachments created by other Zimbra APIs are ignored within CalDAV.<br />
# New Calendar items cannot be created via PUT to a URL unless the component of the URL matches the form <UID>.ics where <UID> is the iCalendar UID of the calendar data being created.<br />
<br />
== Client configuration ==<br />
* [[Accessing_Zimbra_Collaboration_Server_with_iCal_and_Calendar|How to configure Mac OS Calendar to access all your Zimbra Calendars]]<br />
* [[Accessing_Zimbra_Collaboration_Server_with_Thunderbird#Viewing_your_Zimbra_Calendar_using_Lightning|How to configure Thunderbird's Lightning plugin to access an individual Zimbra Calendar]]<br />
<br />
== Historical CalDAV support ==<br />
<br />
Older versions of Zimbra used a radically different mechanism for supporting CalDAV - see [[Historical_CalDAV_Support|Historical CalDAV Support]]<br />
<br />
{{Article Footer|Zimbra Collaboration 8.7|04/06/2017}}<br />
[[Category:Clients]]<br />
[[Category:Architecture and Components]]</div>Gren Elliothttps://wiki.zimbra.com/index.php?title=CardDAV&diff=63465CardDAV2017-04-13T16:49:32Z<p>Gren Elliot: /* RFCs supported by Zimbra's CardDAV Server implementation */</p>
<hr />
<div>{{BC|Community Sandbox}}<br />
__FORCETOC__<br />
<div class="col-md-12 ibox-content"><br />
=CardDAV Server Support=<br />
{{KB{{ZCS 8.7}}}}<br />
<br />
== RFCs supported by Zimbra's CardDAV Server implementation ==<br />
{| class="wikitable"<br />
! style="text-align:left;"| Standard ID<br />
! URL<br />
! Description<br />
|-<br />
| RFC 2426<br />
| https://tools.ietf.org/html/rfc2426<br />
| vCard MIME Directory Profile (VCARD Version 3.0)<br />
|-<br />
| RFC 2616<br />
| https://tools.ietf.org/html/rfc2616<br />
| Hypertext Transfer Protocol -- HTTP/1.1<br />
|-<br />
| RFC 2617<br />
| https://tools.ietf.org/html/rfc2617<br />
| HTTP Authentication: Basic and Digest Access Authentication<br />
|-<br />
| RFC 4918<br />
| https://tools.ietf.org/html/rfc4918<br />
| HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)<br />
|-<br />
| RFC 6352<br />
| https://tools.ietf.org/html/rfc6352<br />
| CardDAV: vCard Extensions to Web Distributed Authoring and Versioning (WebDAV)<br />
|-<br />
| RFC 5995<br />
| https://tools.ietf.org/html/rfc5995<br />
| Using POST to Add Members to Web Distributed Authoring and Versioning (WebDAV) Collections<br />
This is the preferred mechanism for creating new entries in an addressbook collection.<br />
|-<br />
| RFC 6764<br />
| https://tools.ietf.org/html/rfc6764<br />
| Locating Services for Calendaring Extensions to WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV)<br />
The Zimbra server implements the well-known URI for CardDAV. See section 9.1.2.<br />
This specification can also be useful as a reference for how to configure DNS to make<br />
client configuration easier.<br />
|-<br />
| RFC 5397<br />
| https://tools.ietf.org/html/rfc5397<br />
| WebDAV Current Principal Extension<br />
|-<br />
| RFC 5689<br />
| https://tools.ietf.org/html/rfc5689<br />
| Extended MKCOL for Web Distributed Authoring and Versioning (WebDAV)<br />
This is the preferred way to create new addressbook collections<br />
|-<br />
| RFC 3253 (partial)<br />
| https://tools.ietf.org/html/rfc3253<br />
| Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)<br />
See Section 3.6 (Report method) and 3.8 (DAV:expand-property Report)<br />
|-<br />
| RFC 3744<br />
| https://tools.ietf.org/html/rfc3744<br />
| Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol<br />
|}<br />
<br />
=== Known Issues ===<br />
* Some addressbook clients only support 1 addressbook collection.<br />
<br />
=Introduction=<br />
Zimbra 8.7 supports the CardDAV standard. Supported clients are Apple Address Book, Sunbird, and others. Connectivity is supported with or without a ZCS reverse proxy server.<br />
<br />
=Configuring Addressbook clients to access the Zimbra CardDAV server=<br />
==Apple Address Book for OS X 10.6 (Snow Leopard)==<br />
#Address Book -> Preferences -> Accounts<br />
#Click the "+" to add a new account.<br />
#Configure account details<br />
#*'''Account type:''' CardDAV<br />
#*'''User name:''' your_zcs_useraccount@domain.tld<br />
#*'''Password:''' zcsUserAccountPassword<br />
#*'''Server address:''' zcsserver.domain.tld:port<br />
#*: Be sure to include the port specification when configuring Apple AB to ensure the account is setup correctly. Use 443 if your ZCS server supports the default HTTPS port. Otherwise, specify 80 if your server does not support HTTPS and listens for HTTP on the default port 80.<br />
#Click Create.<br />
#: An error may display after configuring account details that states:<br />
#: '''''Address Book couldn't discover the account settings for the CardDAV server "zcsserver.domain.tld:port". Make sure the user name and server address are correct, then click Create.'''''<br />
#: If you receive this error, check the settings with your ZCS server administrator and try again.<br />
#Close AB preferences.<br />
<br />
Apple Address Book is now setup for CardDAV to your Zimbra server.<br />
<br />
==Apple iOS 4 for iPhone/iPad/iPod Touch==<br />
#Settings -> Mail, Contacts, Calendars -> Add Account... -> Other<br />
#Add CardDAV Account<br />
#Configure account details<br />
#*'''Server:''' zcsserver.domain.tld:port<br />
#*: Be sure to include the port specification when configuring CardDAV for iOS 4 to ensure the account is setup correctly. Use 443 if your ZCS server supports the default HTTPS port. Otherwise, specify 80 if your server does not support HTTPS and listens for HTTP on the default port 80.<br />
#*'''User Name:''' your_zcs_useraccount@domain.tld<br />
#*'''Password:''' zcsUserAccountPassword<br />
#*'''Description:''' Zimbra<br />
#Tap Next.<br />
#Accept the SSL certificate warning if applicable.<br />
iOS 4 is now setup for CardDAV to your Zimbra server. To use, navigate to the Contacts app and locate the group with the description provided during setup. Then, search for contacts.<br />
<br />
==Android==<br />
#Install CardDAV-Sync ([http://dmfs.org/carddav/ http://dmfs.org/carddav/])<br />
#Settings -> Accounts & sync<br />
#Tap '''Add account'''<br />
#Configure account details<br />
#*'''Server name:''' zcsserver.domain.tld:port<br />
#*: Be sure to include the port specification if you do not use standard ports (i.e. 80 for http and 443 for https)<br />
#*'''Use SSL:''' leave checked if you want to connect using SSL, un-check otherwise<br />
#*'''Username:''' your_zcs_useraccount@domain.tld<br />
#*'''Password:''' zcsUserAccountPassword<br />
#Tap Next<br />
#Confirm SSL warning if you use a self signed certificate (and the fingerprint matches your certificate)<br />
#Tap the address book you want to sync<br />
#Enter account name (i.e. the description)<br />
#Un-check '''sync from server to phone only''' if you want two-way-sync<br />
#Tap Finish and confirm warning about two-way-sync if necessary<br />
<br />
CardDAV-Sync starts immediately to sync your contacts. To edit settings for this account tap your new account and select '''Edit account settings'''<br />
<br />
=References and Resources=<br />
*[https://bugzilla.zimbra.com/show_bug.cgi?id=46297 Bug 46297] CardDAV not working correctly n Mac OS X Snow Leopard Address Book<br />
*[https://bugzilla.zimbra.com/show_bug.cgi?id=50595 Bug 50595] CardDAV fails in 6.0.8 for Evolution and Mac Address Book<br />
*[https://bugzilla.zimbra.com/show_bug.cgi?id=50133 Bug 50133] can't setup CalDAV account in iCal on MacOS 10.6<br />
*[https://bugzilla.zimbra.com/show_bug.cgi?id=59352 Bug 59352] Contact is not getting forwarded completely<br />
*[https://bugzilla.zimbra.com/show_bug.cgi?id=75160 Bug 75160] Truncates contact when exported or synched<br />
*[[Ajcody-Apple-Mac-Issues#CardDAV|Ajcody's Apple Mac Issues for CardDAV]]<br />
*[[CalDav_and_SunBird|CalDAV on SunBird]]<br />
<br />
Please update this page if you have information on configuring other clients.<br />
{{Article Footer|Zimbra Collaboration 8.7|04/13/2017}}</div>Gren Elliothttps://wiki.zimbra.com/index.php?title=CardDAV&diff=63464CardDAV2017-04-13T16:46:28Z<p>Gren Elliot: /* Configuring CardDAV */</p>
<hr />
<div>{{BC|Community Sandbox}}<br />
__FORCETOC__<br />
<div class="col-md-12 ibox-content"><br />
=CardDAV Server Support=<br />
{{KB{{ZCS 8.7}}}}<br />
<br />
== RFCs supported by Zimbra's CardDAV Server implementation ==<br />
{| class="wikitable"<br />
! style="text-align:left;"| Standard ID<br />
! URL<br />
! Description<br />
|-<br />
| RFC 2426<br />
| https://tools.ietf.org/html/rfc2426<br />
| vCard MIME Directory Profile (VCARD Version 3.0)<br />
|-<br />
| RFC 2616<br />
| https://tools.ietf.org/html/rfc2616<br />
| Hypertext Transfer Protocol -- HTTP/1.1<br />
|-<br />
| RFC 2617<br />
| https://tools.ietf.org/html/rfc2617<br />
| HTTP Authentication: Basic and Digest Access Authentication<br />
|-<br />
| RFC 4918<br />
| https://tools.ietf.org/html/rfc4918<br />
| HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)<br />
|-<br />
| RFC 6352<br />
| https://tools.ietf.org/html/rfc6352<br />
| CardDAV: vCard Extensions to Web Distributed Authoring and Versioning (WebDAV)<br />
|-<br />
| RFC 5995<br />
| https://tools.ietf.org/html/rfc5995<br />
| Using POST to Add Members to Web Distributed Authoring and Versioning (WebDAV) Collections<br />
This is the preferred mechanism for creating new entries in an addressbook collection.<br />
|-<br />
| RFC 6764<br />
| https://tools.ietf.org/html/rfc6764<br />
| Locating Services for Calendaring Extensions to WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV)<br />
The Zimbra server implements the well-known URI for CardDAV. See section 9.1.2.<br />
This specification can also be useful as a reference for how to configure DNS to make<br />
client configuration easier.<br />
|-<br />
| RFC 5397<br />
| https://tools.ietf.org/html/rfc5397<br />
| WebDAV Current Principal Extension<br />
|-<br />
| RFC 5689<br />
| https://tools.ietf.org/html/rfc5689<br />
| Extended MKCOL for Web Distributed Authoring and Versioning (WebDAV)<br />
This is the preferred way to create new calendars<br />
|-<br />
| RFC 3253 (partial)<br />
| https://tools.ietf.org/html/rfc3253<br />
| Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)<br />
See Section 3.6 (Report method) and 3.8 (DAV:expand-property Report)<br />
|-<br />
| RFC 3744<br />
| https://tools.ietf.org/html/rfc3744<br />
| Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol<br />
|}<br />
<br />
=Introduction=<br />
Zimbra 8.7 supports the CardDAV standard. Supported clients are Apple Address Book, Sunbird, and others. Connectivity is supported with or without a ZCS reverse proxy server.<br />
<br />
=Configuring Addressbook clients to access the Zimbra CardDAV server=<br />
==Apple Address Book for OS X 10.6 (Snow Leopard)==<br />
#Address Book -> Preferences -> Accounts<br />
#Click the "+" to add a new account.<br />
#Configure account details<br />
#*'''Account type:''' CardDAV<br />
#*'''User name:''' your_zcs_useraccount@domain.tld<br />
#*'''Password:''' zcsUserAccountPassword<br />
#*'''Server address:''' zcsserver.domain.tld:port<br />
#*: Be sure to include the port specification when configuring Apple AB to ensure the account is setup correctly. Use 443 if your ZCS server supports the default HTTPS port. Otherwise, specify 80 if your server does not support HTTPS and listens for HTTP on the default port 80.<br />
#Click Create.<br />
#: An error may display after configuring account details that states:<br />
#: '''''Address Book couldn't discover the account settings for the CardDAV server "zcsserver.domain.tld:port". Make sure the user name and server address are correct, then click Create.'''''<br />
#: If you receive this error, check the settings with your ZCS server administrator and try again.<br />
#Close AB preferences.<br />
<br />
Apple Address Book is now setup for CardDAV to your Zimbra server.<br />
<br />
==Apple iOS 4 for iPhone/iPad/iPod Touch==<br />
#Settings -> Mail, Contacts, Calendars -> Add Account... -> Other<br />
#Add CardDAV Account<br />
#Configure account details<br />
#*'''Server:''' zcsserver.domain.tld:port<br />
#*: Be sure to include the port specification when configuring CardDAV for iOS 4 to ensure the account is setup correctly. Use 443 if your ZCS server supports the default HTTPS port. Otherwise, specify 80 if your server does not support HTTPS and listens for HTTP on the default port 80.<br />
#*'''User Name:''' your_zcs_useraccount@domain.tld<br />
#*'''Password:''' zcsUserAccountPassword<br />
#*'''Description:''' Zimbra<br />
#Tap Next.<br />
#Accept the SSL certificate warning if applicable.<br />
iOS 4 is now setup for CardDAV to your Zimbra server. To use, navigate to the Contacts app and locate the group with the description provided during setup. Then, search for contacts.<br />
<br />
==Android==<br />
#Install CardDAV-Sync ([http://dmfs.org/carddav/ http://dmfs.org/carddav/])<br />
#Settings -> Accounts & sync<br />
#Tap '''Add account'''<br />
#Configure account details<br />
#*'''Server name:''' zcsserver.domain.tld:port<br />
#*: Be sure to include the port specification if you do not use standard ports (i.e. 80 for http and 443 for https)<br />
#*'''Use SSL:''' leave checked if you want to connect using SSL, un-check otherwise<br />
#*'''Username:''' your_zcs_useraccount@domain.tld<br />
#*'''Password:''' zcsUserAccountPassword<br />
#Tap Next<br />
#Confirm SSL warning if you use a self signed certificate (and the fingerprint matches your certificate)<br />
#Tap the address book you want to sync<br />
#Enter account name (i.e. the description)<br />
#Un-check '''sync from server to phone only''' if you want two-way-sync<br />
#Tap Finish and confirm warning about two-way-sync if necessary<br />
<br />
CardDAV-Sync starts immediately to sync your contacts. To edit settings for this account tap your new account and select '''Edit account settings'''<br />
<br />
=References and Resources=<br />
*[https://bugzilla.zimbra.com/show_bug.cgi?id=46297 Bug 46297] CardDAV not working correctly n Mac OS X Snow Leopard Address Book<br />
*[https://bugzilla.zimbra.com/show_bug.cgi?id=50595 Bug 50595] CardDAV fails in 6.0.8 for Evolution and Mac Address Book<br />
*[https://bugzilla.zimbra.com/show_bug.cgi?id=50133 Bug 50133] can't setup CalDAV account in iCal on MacOS 10.6<br />
*[https://bugzilla.zimbra.com/show_bug.cgi?id=59352 Bug 59352] Contact is not getting forwarded completely<br />
*[https://bugzilla.zimbra.com/show_bug.cgi?id=75160 Bug 75160] Truncates contact when exported or synched<br />
*[[Ajcody-Apple-Mac-Issues#CardDAV|Ajcody's Apple Mac Issues for CardDAV]]<br />
*[[CalDav_and_SunBird|CalDAV on SunBird]]<br />
<br />
Please update this page if you have information on configuring other clients.<br />
{{Article Footer|Zimbra Collaboration 8.7|04/13/2017}}</div>Gren Elliothttps://wiki.zimbra.com/index.php?title=CardDAV&diff=63463CardDAV2017-04-13T16:44:44Z<p>Gren Elliot: /* References and Resources */</p>
<hr />
<div>{{BC|Community Sandbox}}<br />
__FORCETOC__<br />
<div class="col-md-12 ibox-content"><br />
=CardDAV Server Support=<br />
{{KB{{ZCS 8.7}}}}<br />
<br />
== RFCs supported by Zimbra's CardDAV Server implementation ==<br />
{| class="wikitable"<br />
! style="text-align:left;"| Standard ID<br />
! URL<br />
! Description<br />
|-<br />
| RFC 2426<br />
| https://tools.ietf.org/html/rfc2426<br />
| vCard MIME Directory Profile (VCARD Version 3.0)<br />
|-<br />
| RFC 2616<br />
| https://tools.ietf.org/html/rfc2616<br />
| Hypertext Transfer Protocol -- HTTP/1.1<br />
|-<br />
| RFC 2617<br />
| https://tools.ietf.org/html/rfc2617<br />
| HTTP Authentication: Basic and Digest Access Authentication<br />
|-<br />
| RFC 4918<br />
| https://tools.ietf.org/html/rfc4918<br />
| HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)<br />
|-<br />
| RFC 6352<br />
| https://tools.ietf.org/html/rfc6352<br />
| CardDAV: vCard Extensions to Web Distributed Authoring and Versioning (WebDAV)<br />
|-<br />
| RFC 5995<br />
| https://tools.ietf.org/html/rfc5995<br />
| Using POST to Add Members to Web Distributed Authoring and Versioning (WebDAV) Collections<br />
This is the preferred mechanism for creating new entries in an addressbook collection.<br />
|-<br />
| RFC 6764<br />
| https://tools.ietf.org/html/rfc6764<br />
| Locating Services for Calendaring Extensions to WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV)<br />
The Zimbra server implements the well-known URI for CardDAV. See section 9.1.2.<br />
This specification can also be useful as a reference for how to configure DNS to make<br />
client configuration easier.<br />
|-<br />
| RFC 5397<br />
| https://tools.ietf.org/html/rfc5397<br />
| WebDAV Current Principal Extension<br />
|-<br />
| RFC 5689<br />
| https://tools.ietf.org/html/rfc5689<br />
| Extended MKCOL for Web Distributed Authoring and Versioning (WebDAV)<br />
This is the preferred way to create new calendars<br />
|-<br />
| RFC 3253 (partial)<br />
| https://tools.ietf.org/html/rfc3253<br />
| Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)<br />
See Section 3.6 (Report method) and 3.8 (DAV:expand-property Report)<br />
|-<br />
| RFC 3744<br />
| https://tools.ietf.org/html/rfc3744<br />
| Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol<br />
|}<br />
<br />
=Introduction=<br />
Zimbra 8.7 supports the CardDAV standard. Supported clients are Apple Address Book, Sunbird, and others. Connectivity is supported with or without a ZCS reverse proxy server.<br />
<br />
=Configuring CardDAV=<br />
==Apple Address Book for OS X 10.6 (Snow Leopard)==<br />
#Address Book -> Preferences -> Accounts<br />
#Click the "+" to add a new account.<br />
#Configure account details<br />
#*'''Account type:''' CardDAV<br />
#*'''User name:''' your_zcs_useraccount@domain.tld<br />
#*'''Password:''' zcsUserAccountPassword<br />
#*'''Server address:''' zcsserver.domain.tld:port<br />
#*: Be sure to include the port specification when configuring Apple AB to ensure the account is setup correctly. Use 443 if your ZCS server supports the default HTTPS port. Otherwise, specify 80 if your server does not support HTTPS and listens for HTTP on the default port 80.<br />
#Click Create.<br />
#: An error may display after configuring account details that states:<br />
#: '''''Address Book couldn't discover the account settings for the CardDAV server "zcsserver.domain.tld:port". Make sure the user name and server address are correct, then click Create.'''''<br />
#: If you receive this error, check the settings with your ZCS server administrator and try again.<br />
#Close AB preferences.<br />
<br />
Apple Address Book is now setup for CardDAV to your Zimbra server.<br />
<br />
==Apple iOS 4 for iPhone/iPad/iPod Touch==<br />
#Settings -> Mail, Contacts, Calendars -> Add Account... -> Other<br />
#Add CardDAV Account<br />
#Configure account details<br />
#*'''Server:''' zcsserver.domain.tld:port<br />
#*: Be sure to include the port specification when configuring CardDAV for iOS 4 to ensure the account is setup correctly. Use 443 if your ZCS server supports the default HTTPS port. Otherwise, specify 80 if your server does not support HTTPS and listens for HTTP on the default port 80.<br />
#*'''User Name:''' your_zcs_useraccount@domain.tld<br />
#*'''Password:''' zcsUserAccountPassword<br />
#*'''Description:''' Zimbra<br />
#Tap Next.<br />
#Accept the SSL certificate warning if applicable.<br />
iOS 4 is now setup for CardDAV to your Zimbra server. To use, navigate to the Contacts app and locate the group with the description provided during setup. Then, search for contacts.<br />
<br />
==Android==<br />
#Install CardDAV-Sync ([http://dmfs.org/carddav/ http://dmfs.org/carddav/])<br />
#Settings -> Accounts & sync<br />
#Tap '''Add account'''<br />
#Configure account details<br />
#*'''Server name:''' zcsserver.domain.tld:port<br />
#*: Be sure to include the port specification if you do not use standard ports (i.e. 80 for http and 443 for https)<br />
#*'''Use SSL:''' leave checked if you want to connect using SSL, un-check otherwise<br />
#*'''Username:''' your_zcs_useraccount@domain.tld<br />
#*'''Password:''' zcsUserAccountPassword<br />
#Tap Next<br />
#Confirm SSL warning if you use a self signed certificate (and the fingerprint matches your certificate)<br />
#Tap the address book you want to sync<br />
#Enter account name (i.e. the description)<br />
#Un-check '''sync from server to phone only''' if you want two-way-sync<br />
#Tap Finish and confirm warning about two-way-sync if necessary<br />
<br />
CardDAV-Sync starts immediately to sync your contacts. To edit settings for this account tap your new account and select '''Edit account settings'''<br />
<br />
=References and Resources=<br />
*[https://bugzilla.zimbra.com/show_bug.cgi?id=46297 Bug 46297] CardDAV not working correctly n Mac OS X Snow Leopard Address Book<br />
*[https://bugzilla.zimbra.com/show_bug.cgi?id=50595 Bug 50595] CardDAV fails in 6.0.8 for Evolution and Mac Address Book<br />
*[https://bugzilla.zimbra.com/show_bug.cgi?id=50133 Bug 50133] can't setup CalDAV account in iCal on MacOS 10.6<br />
*[https://bugzilla.zimbra.com/show_bug.cgi?id=59352 Bug 59352] Contact is not getting forwarded completely<br />
*[https://bugzilla.zimbra.com/show_bug.cgi?id=75160 Bug 75160] Truncates contact when exported or synched<br />
*[[Ajcody-Apple-Mac-Issues#CardDAV|Ajcody's Apple Mac Issues for CardDAV]]<br />
*[[CalDav_and_SunBird|CalDAV on SunBird]]<br />
<br />
Please update this page if you have information on configuring other clients.<br />
{{Article Footer|Zimbra Collaboration 8.7|04/13/2017}}</div>Gren Elliothttps://wiki.zimbra.com/index.php?title=CardDAV&diff=63462CardDAV2017-04-13T16:43:36Z<p>Gren Elliot: /* Introduction */</p>
<hr />
<div>{{BC|Community Sandbox}}<br />
__FORCETOC__<br />
<div class="col-md-12 ibox-content"><br />
=CardDAV Server Support=<br />
{{KB{{ZCS 8.7}}}}<br />
<br />
== RFCs supported by Zimbra's CardDAV Server implementation ==<br />
{| class="wikitable"<br />
! style="text-align:left;"| Standard ID<br />
! URL<br />
! Description<br />
|-<br />
| RFC 2426<br />
| https://tools.ietf.org/html/rfc2426<br />
| vCard MIME Directory Profile (VCARD Version 3.0)<br />
|-<br />
| RFC 2616<br />
| https://tools.ietf.org/html/rfc2616<br />
| Hypertext Transfer Protocol -- HTTP/1.1<br />
|-<br />
| RFC 2617<br />
| https://tools.ietf.org/html/rfc2617<br />
| HTTP Authentication: Basic and Digest Access Authentication<br />
|-<br />
| RFC 4918<br />
| https://tools.ietf.org/html/rfc4918<br />
| HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)<br />
|-<br />
| RFC 6352<br />
| https://tools.ietf.org/html/rfc6352<br />
| CardDAV: vCard Extensions to Web Distributed Authoring and Versioning (WebDAV)<br />
|-<br />
| RFC 5995<br />
| https://tools.ietf.org/html/rfc5995<br />
| Using POST to Add Members to Web Distributed Authoring and Versioning (WebDAV) Collections<br />
This is the preferred mechanism for creating new entries in an addressbook collection.<br />
|-<br />
| RFC 6764<br />
| https://tools.ietf.org/html/rfc6764<br />
| Locating Services for Calendaring Extensions to WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV)<br />
The Zimbra server implements the well-known URI for CardDAV. See section 9.1.2.<br />
This specification can also be useful as a reference for how to configure DNS to make<br />
client configuration easier.<br />
|-<br />
| RFC 5397<br />
| https://tools.ietf.org/html/rfc5397<br />
| WebDAV Current Principal Extension<br />
|-<br />
| RFC 5689<br />
| https://tools.ietf.org/html/rfc5689<br />
| Extended MKCOL for Web Distributed Authoring and Versioning (WebDAV)<br />
This is the preferred way to create new calendars<br />
|-<br />
| RFC 3253 (partial)<br />
| https://tools.ietf.org/html/rfc3253<br />
| Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)<br />
See Section 3.6 (Report method) and 3.8 (DAV:expand-property Report)<br />
|-<br />
| RFC 3744<br />
| https://tools.ietf.org/html/rfc3744<br />
| Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol<br />
|}<br />
<br />
=Introduction=<br />
Zimbra 8.7 supports the CardDAV standard. Supported clients are Apple Address Book, Sunbird, and others. Connectivity is supported with or without a ZCS reverse proxy server.<br />
<br />
=Configuring CardDAV=<br />
==Apple Address Book for OS X 10.6 (Snow Leopard)==<br />
#Address Book -> Preferences -> Accounts<br />
#Click the "+" to add a new account.<br />
#Configure account details<br />
#*'''Account type:''' CardDAV<br />
#*'''User name:''' your_zcs_useraccount@domain.tld<br />
#*'''Password:''' zcsUserAccountPassword<br />
#*'''Server address:''' zcsserver.domain.tld:port<br />
#*: Be sure to include the port specification when configuring Apple AB to ensure the account is setup correctly. Use 443 if your ZCS server supports the default HTTPS port. Otherwise, specify 80 if your server does not support HTTPS and listens for HTTP on the default port 80.<br />
#Click Create.<br />
#: An error may display after configuring account details that states:<br />
#: '''''Address Book couldn't discover the account settings for the CardDAV server "zcsserver.domain.tld:port". Make sure the user name and server address are correct, then click Create.'''''<br />
#: If you receive this error, check the settings with your ZCS server administrator and try again.<br />
#Close AB preferences.<br />
<br />
Apple Address Book is now setup for CardDAV to your Zimbra server.<br />
<br />
==Apple iOS 4 for iPhone/iPad/iPod Touch==<br />
#Settings -> Mail, Contacts, Calendars -> Add Account... -> Other<br />
#Add CardDAV Account<br />
#Configure account details<br />
#*'''Server:''' zcsserver.domain.tld:port<br />
#*: Be sure to include the port specification when configuring CardDAV for iOS 4 to ensure the account is setup correctly. Use 443 if your ZCS server supports the default HTTPS port. Otherwise, specify 80 if your server does not support HTTPS and listens for HTTP on the default port 80.<br />
#*'''User Name:''' your_zcs_useraccount@domain.tld<br />
#*'''Password:''' zcsUserAccountPassword<br />
#*'''Description:''' Zimbra<br />
#Tap Next.<br />
#Accept the SSL certificate warning if applicable.<br />
iOS 4 is now setup for CardDAV to your Zimbra server. To use, navigate to the Contacts app and locate the group with the description provided during setup. Then, search for contacts.<br />
<br />
==Android==<br />
#Install CardDAV-Sync ([http://dmfs.org/carddav/ http://dmfs.org/carddav/])<br />
#Settings -> Accounts & sync<br />
#Tap '''Add account'''<br />
#Configure account details<br />
#*'''Server name:''' zcsserver.domain.tld:port<br />
#*: Be sure to include the port specification if you do not use standard ports (i.e. 80 for http and 443 for https)<br />
#*'''Use SSL:''' leave checked if you want to connect using SSL, un-check otherwise<br />
#*'''Username:''' your_zcs_useraccount@domain.tld<br />
#*'''Password:''' zcsUserAccountPassword<br />
#Tap Next<br />
#Confirm SSL warning if you use a self signed certificate (and the fingerprint matches your certificate)<br />
#Tap the address book you want to sync<br />
#Enter account name (i.e. the description)<br />
#Un-check '''sync from server to phone only''' if you want two-way-sync<br />
#Tap Finish and confirm warning about two-way-sync if necessary<br />
<br />
CardDAV-Sync starts immediately to sync your contacts. To edit settings for this account tap your new account and select '''Edit account settings'''<br />
<br />
=References and Resources=<br />
*[https://bugzilla.zimbra.com/show_bug.cgi?id=46297 Bug 46297] CardDAV not working correctly n Mac OS X Snow Leopard Address Book<br />
*[https://bugzilla.zimbra.com/show_bug.cgi?id=50595 Bug 50595] CardDAV fails in 6.0.8 for Evolution and Mac Address Book<br />
*[https://bugzilla.zimbra.com/show_bug.cgi?id=50133 Bug 50133] can't setup CalDAV account in iCal on MacOS 10.6<br />
*[https://bugzilla.zimbra.com/show_bug.cgi?id=59352 Bug 59352] Contact is not getting forwarded completely<br />
*[https://bugzilla.zimbra.com/show_bug.cgi?id=75160 Bug 75160] Truncates contact when exported or synched<br />
*[[Ajcody-Apple-Mac-Issues#CardDAV|Ajcody's Apple Mac Issues for CardDAV]]<br />
*[[CalDav_and_SunBird|CalDAV on SunBird]]<br />
<br />
Please update this page if you have information on configuring other clients.<br />
{{Article Footer|Zimbra Collaboration 6.0|04/16/2014}}</div>Gren Elliothttps://wiki.zimbra.com/index.php?title=CardDAV&diff=63461CardDAV2017-04-13T16:42:38Z<p>Gren Elliot: /* CardDAV */</p>
<hr />
<div>{{BC|Community Sandbox}}<br />
__FORCETOC__<br />
<div class="col-md-12 ibox-content"><br />
=CardDAV Server Support=<br />
{{KB{{ZCS 8.7}}}}<br />
<br />
== RFCs supported by Zimbra's CardDAV Server implementation ==<br />
{| class="wikitable"<br />
! style="text-align:left;"| Standard ID<br />
! URL<br />
! Description<br />
|-<br />
| RFC 2426<br />
| https://tools.ietf.org/html/rfc2426<br />
| vCard MIME Directory Profile (VCARD Version 3.0)<br />
|-<br />
| RFC 2616<br />
| https://tools.ietf.org/html/rfc2616<br />
| Hypertext Transfer Protocol -- HTTP/1.1<br />
|-<br />
| RFC 2617<br />
| https://tools.ietf.org/html/rfc2617<br />
| HTTP Authentication: Basic and Digest Access Authentication<br />
|-<br />
| RFC 4918<br />
| https://tools.ietf.org/html/rfc4918<br />
| HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)<br />
|-<br />
| RFC 6352<br />
| https://tools.ietf.org/html/rfc6352<br />
| CardDAV: vCard Extensions to Web Distributed Authoring and Versioning (WebDAV)<br />
|-<br />
| RFC 5995<br />
| https://tools.ietf.org/html/rfc5995<br />
| Using POST to Add Members to Web Distributed Authoring and Versioning (WebDAV) Collections<br />
This is the preferred mechanism for creating new entries in an addressbook collection.<br />
|-<br />
| RFC 6764<br />
| https://tools.ietf.org/html/rfc6764<br />
| Locating Services for Calendaring Extensions to WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV)<br />
The Zimbra server implements the well-known URI for CardDAV. See section 9.1.2.<br />
This specification can also be useful as a reference for how to configure DNS to make<br />
client configuration easier.<br />
|-<br />
| RFC 5397<br />
| https://tools.ietf.org/html/rfc5397<br />
| WebDAV Current Principal Extension<br />
|-<br />
| RFC 5689<br />
| https://tools.ietf.org/html/rfc5689<br />
| Extended MKCOL for Web Distributed Authoring and Versioning (WebDAV)<br />
This is the preferred way to create new calendars<br />
|-<br />
| RFC 3253 (partial)<br />
| https://tools.ietf.org/html/rfc3253<br />
| Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)<br />
See Section 3.6 (Report method) and 3.8 (DAV:expand-property Report)<br />
|-<br />
| RFC 3744<br />
| https://tools.ietf.org/html/rfc3744<br />
| Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol<br />
|}<br />
<br />
=Introduction=<br />
Zimbra 6.0 supports the CardDAV standard. Supported clients are Apple Address Book, Sunbird, and others. Connectivity is supported with or without a ZCS reverse proxy server.<br />
<br />
=Configuring CardDAV=<br />
==Apple Address Book for OS X 10.6 (Snow Leopard)==<br />
#Address Book -> Preferences -> Accounts<br />
#Click the "+" to add a new account.<br />
#Configure account details<br />
#*'''Account type:''' CardDAV<br />
#*'''User name:''' your_zcs_useraccount@domain.tld<br />
#*'''Password:''' zcsUserAccountPassword<br />
#*'''Server address:''' zcsserver.domain.tld:port<br />
#*: Be sure to include the port specification when configuring Apple AB to ensure the account is setup correctly. Use 443 if your ZCS server supports the default HTTPS port. Otherwise, specify 80 if your server does not support HTTPS and listens for HTTP on the default port 80.<br />
#Click Create.<br />
#: An error may display after configuring account details that states:<br />
#: '''''Address Book couldn't discover the account settings for the CardDAV server "zcsserver.domain.tld:port". Make sure the user name and server address are correct, then click Create.'''''<br />
#: If you receive this error, check the settings with your ZCS server administrator and try again.<br />
#Close AB preferences.<br />
<br />
Apple Address Book is now setup for CardDAV to your Zimbra server.<br />
<br />
==Apple iOS 4 for iPhone/iPad/iPod Touch==<br />
#Settings -> Mail, Contacts, Calendars -> Add Account... -> Other<br />
#Add CardDAV Account<br />
#Configure account details<br />
#*'''Server:''' zcsserver.domain.tld:port<br />
#*: Be sure to include the port specification when configuring CardDAV for iOS 4 to ensure the account is setup correctly. Use 443 if your ZCS server supports the default HTTPS port. Otherwise, specify 80 if your server does not support HTTPS and listens for HTTP on the default port 80.<br />
#*'''User Name:''' your_zcs_useraccount@domain.tld<br />
#*'''Password:''' zcsUserAccountPassword<br />
#*'''Description:''' Zimbra<br />
#Tap Next.<br />
#Accept the SSL certificate warning if applicable.<br />
iOS 4 is now setup for CardDAV to your Zimbra server. To use, navigate to the Contacts app and locate the group with the description provided during setup. Then, search for contacts.<br />
<br />
==Android==<br />
#Install CardDAV-Sync ([http://dmfs.org/carddav/ http://dmfs.org/carddav/])<br />
#Settings -> Accounts & sync<br />
#Tap '''Add account'''<br />
#Configure account details<br />
#*'''Server name:''' zcsserver.domain.tld:port<br />
#*: Be sure to include the port specification if you do not use standard ports (i.e. 80 for http and 443 for https)<br />
#*'''Use SSL:''' leave checked if you want to connect using SSL, un-check otherwise<br />
#*'''Username:''' your_zcs_useraccount@domain.tld<br />
#*'''Password:''' zcsUserAccountPassword<br />
#Tap Next<br />
#Confirm SSL warning if you use a self signed certificate (and the fingerprint matches your certificate)<br />
#Tap the address book you want to sync<br />
#Enter account name (i.e. the description)<br />
#Un-check '''sync from server to phone only''' if you want two-way-sync<br />
#Tap Finish and confirm warning about two-way-sync if necessary<br />
<br />
CardDAV-Sync starts immediately to sync your contacts. To edit settings for this account tap your new account and select '''Edit account settings'''<br />
<br />
=References and Resources=<br />
*[https://bugzilla.zimbra.com/show_bug.cgi?id=46297 Bug 46297] CardDAV not working correctly n Mac OS X Snow Leopard Address Book<br />
*[https://bugzilla.zimbra.com/show_bug.cgi?id=50595 Bug 50595] CardDAV fails in 6.0.8 for Evolution and Mac Address Book<br />
*[https://bugzilla.zimbra.com/show_bug.cgi?id=50133 Bug 50133] can't setup CalDAV account in iCal on MacOS 10.6<br />
*[https://bugzilla.zimbra.com/show_bug.cgi?id=59352 Bug 59352] Contact is not getting forwarded completely<br />
*[https://bugzilla.zimbra.com/show_bug.cgi?id=75160 Bug 75160] Truncates contact when exported or synched<br />
*[[Ajcody-Apple-Mac-Issues#CardDAV|Ajcody's Apple Mac Issues for CardDAV]]<br />
*[[CalDav_and_SunBird|CalDAV on SunBird]]<br />
<br />
Please update this page if you have information on configuring other clients.<br />
{{Article Footer|Zimbra Collaboration 6.0|04/16/2014}}</div>Gren Elliothttps://wiki.zimbra.com/index.php?title=CalDav_Support&diff=63460CalDav Support2017-04-13T16:21:16Z<p>Gren Elliot: /* CalDAV Support */</p>
<hr />
<div>{{BC|Community Sandbox}}<br />
__FORCETOC__<br />
<div class="col-md-12 ibox-content"><br />
=CalDAV Support=<br />
{{KB{{ZCS 8.7}}}}<br />
<br />
== RFCs supported by Zimbra's CalDAV implementation ==<br />
{| class="wikitable"<br />
! style="text-align:left;"| Standard ID<br />
! URL<br />
! Description<br />
|-<br />
| RFC 5545<br />
| https://tools.ietf.org/html/rfc5545<br />
| Internet Calendaring and Scheduling Core Object Specification (iCalendar)<br />
|-<br />
| RFC 2616<br />
| https://tools.ietf.org/html/rfc2616<br />
| Hypertext Transfer Protocol -- HTTP/1.1<br />
|-<br />
| RFC 2617<br />
| https://tools.ietf.org/html/rfc2617<br />
| HTTP Authentication: Basic and Digest Access Authentication<br />
|-<br />
| RFC 4918<br />
| https://tools.ietf.org/html/rfc4918<br />
| HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)<br />
|-<br />
| RFC 4791<br />
| https://tools.ietf.org/html/rfc4791<br />
| Calendaring Extensions to WebDAV (CalDAV)<br />
|-<br />
| RFC 6638<br />
| https://tools.ietf.org/html/rfc6638<br />
| Scheduling Extensions to CalDAV<br />
|-<br />
| RFC 5995<br />
| https://tools.ietf.org/html/rfc5995<br />
| Using POST to Add Members to Web Distributed Authoring and Versioning (WebDAV) Collections<br />
This is the preferred mechanism for creating new entries in the calendar. Using the PUT<br />
method with a final name that doesn't strictly match the form "<UID>.ics" will always fail.<br />
Using POST allows the server to choose the final name.<br />
|-<br />
| RFC 6764<br />
| https://tools.ietf.org/html/rfc6764<br />
| Locating Services for Calendaring Extensions to WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV)<br />
The Zimbra server implements the well-known URI for CalDAV. See section 9.1.1.<br />
This specification can also be useful as a reference for how to configure DNS to make<br />
client configuration easier.<br />
|-<br />
| RFC 5397<br />
| https://tools.ietf.org/html/rfc5397<br />
| WebDAV Current Principal Extension<br />
|-<br />
| RFC 5689<br />
| https://tools.ietf.org/html/rfc5689<br />
| Extended MKCOL for Web Distributed Authoring and Versioning (WebDAV)<br />
This is the preferred way to create new calendars<br />
|-<br />
| RFC 3253 (partial)<br />
| https://tools.ietf.org/html/rfc3253<br />
| Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)<br />
See Section 3.6 (Report method) and 3.8 (DAV:expand-property Report)<br />
|-<br />
| RFC 3744<br />
| https://tools.ietf.org/html/rfc3744<br />
| Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol<br />
|-<br />
| caldav-proxy (Apple extension)<br />
| https://github.com/apple/ccs-calendarserver/blob/master/doc/Extensions/caldav-proxy.txt<br />
| Calendar User Proxy Functionality in CalDAV<br />
|}<br />
<br />
=== Known limitations ===<br />
<br />
# Attachments are not currently supported via the CalDAV API. Attachments created by other Zimbra APIs are ignored within CalDAV.<br />
# New Calendar items cannot be created via PUT to a URL unless the component of the URL matches the form <UID>.ics where <UID> is the iCalendar UID of the calendar data being created.<br />
<br />
== Client configuration ==<br />
* [[Accessing_Zimbra_Collaboration_Server_with_iCal_and_Calendar|How to configure Mac OS Calendar to access all your Zimbra Calendars]]<br />
* [[Accessing_Zimbra_Collaboration_Server_with_Thunderbird#Viewing_your_Zimbra_Calendar_using_Lightning|How to configure Thunderbird's Lightning plugin to access an individual Zimbra Calendar]]<br />
<br />
== Historical CalDAV support ==<br />
<br />
Older versions of Zimbra used a radically different mechanism for supporting CalDAV - see [[Historical_CalDAV_Support|Historical CalDAV Support]]<br />
<br />
{{Article Footer|Zimbra Collaboration 8.7|04/06/2017}}<br />
[[Category:Clients]]<br />
[[Category:Architecture and Components]]</div>Gren Elliothttps://wiki.zimbra.com/index.php?title=CalDav_Support&diff=63459CalDav Support2017-04-13T16:20:10Z<p>Gren Elliot: /* CalDAV Support */</p>
<hr />
<div>{{BC|Community Sandbox}}<br />
__FORCETOC__<br />
<div class="col-md-12 ibox-content"><br />
=CalDAV Support=<br />
{{KB{{ZCS 8.7}}}}<br />
<br />
== RFCs supported by Zimbra's CalDAV implementation ==<br />
{| class="wikitable"<br />
! style="text-align:left;"| Standard ID<br />
! URL<br />
! Description<br />
|-<br />
| RFC 5545<br />
| https://tools.ietf.org/html/rfc5545<br />
| Internet Calendaring and Scheduling Core Object Specification (iCalendar)<br />
|-<br />
| RFC 2616<br />
| https://tools.ietf.org/html/rfc2616<br />
| Hypertext Transfer Protocol -- HTTP/1.1<br />
|-<br />
| RFC 2617<br />
| https://tools.ietf.org/html/rfc2617<br />
| HTTP Authentication: Basic and Digest Access Authentication<br />
|-<br />
| RFC 4918<br />
| https://tools.ietf.org/html/rfc4918<br />
| HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)<br />
|-<br />
| RFC 4791<br />
| https://tools.ietf.org/html/rfc4791<br />
| Calendaring Extensions to WebDAV (CalDAV)<br />
|-<br />
| RFC 6638<br />
| https://tools.ietf.org/html/rfc6638<br />
| Scheduling Extensions to CalDAV<br />
|-<br />
| RFC 5995<br />
| https://tools.ietf.org/html/rfc5995<br />
| Using POST to Add Members to Web Distributed Authoring and Versioning (WebDAV) Collections<br />
This is the preferred mechanism for creating new entries in the calendar. Using the PUT<br />
method with a final name that doesn't strictly match the form "<UID>.ics" will always fail.<br />
Using POST allows the server to choose the final name.<br />
|-<br />
| RFC 6764<br />
| https://tools.ietf.org/html/rfc6764<br />
| Locating Services for Calendaring Extensions to WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV)<br />
The Zimbra server implements the well-known URI for CalDAV. See section 9.1.1.<br />
This specification can also be useful as a reference for how to configure DNS to make<br />
client configuration easier.<br />
|-<br />
| RFC 5397<br />
| https://tools.ietf.org/html/rfc5397<br />
| WebDAV Current Principal Extension<br />
|-<br />
| RFC 5689<br />
| https://tools.ietf.org/html/rfc5689<br />
| Extended MKCOL for Web Distributed Authoring and Versioning (WebDAV)<br />
This is the preferred way to create new calendars<br />
|-<br />
| RFC 3253 (partial)<br />
| https://tools.ietf.org/html/rfc3253<br />
| Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)<br />
See Section 3.6 (Report method) and 3.8 (DAV:expand-property Report)<br />
|-<br />
| RFC 3744<br />
| https://tools.ietf.org/html/rfc3744<br />
| Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol<br />
|-<br />
| caldav-proxy (Apple extension)<br />
| https://github.com/apple/ccs-calendarserver/blob/master/doc/Extensions/caldav-proxy.txt<br />
| Calendar User Proxy Functionality in CalDAV<br />
|-<br />
| calendarserver-principal-property-search (Apple extension)<br />
| Undocumented?<br />
| ?<br />
|}<br />
<br />
=== Known limitations ===<br />
<br />
# Attachments are not currently supported via the CalDAV API. Attachments created by other Zimbra APIs are ignored within CalDAV.<br />
# New Calendar items cannot be created via PUT to a URL unless the component of the URL matches the form <UID>.ics where <UID> is the iCalendar UID of the calendar data being created.<br />
<br />
== Client configuration ==<br />
* [[Accessing_Zimbra_Collaboration_Server_with_iCal_and_Calendar|How to configure Mac OS Calendar to access all your Zimbra Calendars]]<br />
* [[Accessing_Zimbra_Collaboration_Server_with_Thunderbird#Viewing_your_Zimbra_Calendar_using_Lightning|How to configure Thunderbird's Lightning plugin to access an individual Zimbra Calendar]]<br />
<br />
== Historical CalDAV support ==<br />
<br />
Older versions of Zimbra used a radically different mechanism for supporting CalDAV - see [[Historical_CalDAV_Support|Historical CalDAV Support]]<br />
<br />
{{Article Footer|Zimbra Collaboration 8.7|04/06/2017}}<br />
[[Category:Clients]]<br />
[[Category:Architecture and Components]]</div>Gren Elliothttps://wiki.zimbra.com/index.php?title=CalDav_Support&diff=63458CalDav Support2017-04-13T15:16:10Z<p>Gren Elliot: /* CalDAV Support */</p>
<hr />
<div>{{BC|Community Sandbox}}<br />
__FORCETOC__<br />
<div class="col-md-12 ibox-content"><br />
=CalDAV Support=<br />
{{KB{{ZCS 8.7}}}}<br />
{{WIP}}<br />
<br />
== RFCs supported by Zimbra's CalDAV implementation ==<br />
'''Warning:This is a work in progress'''<br />
<br />
{| class="wikitable"<br />
! style="text-align:left;"| Standard ID<br />
! URL<br />
! Description<br />
|-<br />
| RFC 5545<br />
| https://tools.ietf.org/html/rfc5545<br />
| Internet Calendaring and Scheduling Core Object Specification (iCalendar)<br />
|-<br />
| RFC 4918<br />
| https://tools.ietf.org/html/rfc4918<br />
| HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)<br />
|-<br />
| RFC 4791<br />
| https://tools.ietf.org/html/rfc4791<br />
| Calendaring Extensions to WebDAV (CalDAV)<br />
|-<br />
| RFC 6638<br />
| https://tools.ietf.org/html/rfc6638<br />
| Scheduling Extensions to CalDAV<br />
|-<br />
| RFC 5995<br />
| https://tools.ietf.org/html/rfc5995<br />
| Using POST to Add Members to Web Distributed Authoring and Versioning (WebDAV) Collections<br />
This is the preferred mechanism for creating new entries in the calendar. Using the PUT<br />
method with a final name that doesn't strictly match the form "<UID>.ics" will always fail.<br />
Using POST allows the server to choose the final name.<br />
|-<br />
| RFC 6764<br />
| https://tools.ietf.org/html/rfc6764<br />
| Locating Services for Calendaring Extensions to WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV)<br />
The Zimbra server implements the well-known URI for CalDAV. See section 9.1.1.<br />
This specification can also be useful as a reference for how to configure DNS to make<br />
client configuration easier.<br />
|-<br />
| RFC 5397<br />
| https://tools.ietf.org/html/rfc5397<br />
| WebDAV Current Principal Extension<br />
|-<br />
| RFC 5689<br />
| https://tools.ietf.org/html/rfc5689<br />
| Extended MKCOL for Web Distributed Authoring and Versioning (WebDAV)<br />
This is the preferred way to create new calendars<br />
|-<br />
| RFC 3253 (partial)<br />
| https://tools.ietf.org/html/rfc3253<br />
| Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)<br />
See Section 3.6 (Report method) and 3.8 (DAV:expand-property Report)<br />
|-<br />
| RFC 3744<br />
| https://tools.ietf.org/html/rfc3744<br />
| Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol<br />
|-<br />
| caldav-proxy (Apple extension)<br />
| https://github.com/apple/ccs-calendarserver/blob/master/doc/Extensions/caldav-proxy.txt<br />
| Calendar User Proxy Functionality in CalDAV<br />
|}<br />
<br />
<br />
=== Known limitations ===<br />
<br />
# Attachments are not currently supported via the CalDAV API. Attachments created by other Zimbra APIs are ignored within CalDAV.<br />
# New Calendar items cannot be created via PUT to a URL unless the component of the URL matches the form <UID>.ics where <UID> is the iCalendar UID of the calendar data being created.<br />
<br />
== Client configuration ==<br />
* [[Accessing_Zimbra_Collaboration_Server_with_iCal_and_Calendar|How to configure Mac OS Calendar to access all your Zimbra Calendars]]<br />
* [[Accessing_Zimbra_Collaboration_Server_with_Thunderbird#Viewing_your_Zimbra_Calendar_using_Lightning|How to configure Thunderbird's Lightning plugin to access an individual Zimbra Calendar]]<br />
<br />
== Historical CalDAV support ==<br />
<br />
Older versions of Zimbra used a radically different mechanism for supporting CalDAV - see [[Historical_CalDAV_Support|Historical CalDAV Support]]<br />
<br />
{{Article Footer|Zimbra Collaboration 8.7|04/06/2017}}<br />
[[Category:Clients]]<br />
[[Category:Architecture and Components]]</div>Gren Elliothttps://wiki.zimbra.com/index.php?title=CalDav_Support&diff=63455CalDav Support2017-04-13T14:55:47Z<p>Gren Elliot: /* CalDAV Support */</p>
<hr />
<div>{{BC|Community Sandbox}}<br />
__FORCETOC__<br />
<div class="col-md-12 ibox-content"><br />
=CalDAV Support=<br />
{{KB{{ZCS 8.7}}}}<br />
{{WIP}}<br />
<br />
== RFCs supported by Zimbra's CalDAV implementation ==<br />
'''Warning:This is a work in progress'''<br />
<br />
{| class="wikitable"<br />
! style="text-align:left;"| Standard ID<br />
! URL<br />
! Description<br />
|-<br />
| RFC 5545<br />
| https://tools.ietf.org/html/rfc5545<br />
| Internet Calendaring and Scheduling Core Object Specification (iCalendar)<br />
|-<br />
| RFC 4918<br />
| https://tools.ietf.org/html/rfc4918<br />
| HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)<br />
|-<br />
| RFC 4791<br />
| https://tools.ietf.org/html/rfc4791<br />
| Calendaring Extensions to WebDAV (CalDAV)<br />
|-<br />
| RFC 6638<br />
| https://tools.ietf.org/html/rfc6638<br />
| Scheduling Extensions to CalDAV<br />
|-<br />
| RFC 5995<br />
| https://tools.ietf.org/html/rfc5995<br />
| Using POST to Add Members to Web Distributed Authoring and Versioning (WebDAV) Collections<br />
This is the preferred mechanism for creating new entries in the calendar. Using the PUT<br />
method with a final name that doesn't strictly match the form "<UID>.ics" will always fail.<br />
Using POST allows the server to choose the final name.<br />
|-<br />
| RFC 5397<br />
| https://tools.ietf.org/html/rfc5397<br />
| WebDAV Current Principal Extension<br />
|-<br />
| RFC 5689<br />
| https://tools.ietf.org/html/rfc5689<br />
| Extended MKCOL for Web Distributed Authoring and Versioning (WebDAV)<br />
This is the preferred way to create new calendars<br />
|-<br />
| RFC 3253 (partial)<br />
| https://tools.ietf.org/html/rfc3253<br />
| Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)<br />
See Section 3.6 (Report method) and 3.8 (DAV:expand-property Report)<br />
|-<br />
| RFC 3744<br />
| https://tools.ietf.org/html/rfc3744<br />
| Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol<br />
|-<br />
| caldav-proxy (Apple extension)<br />
| https://github.com/apple/ccs-calendarserver/blob/master/doc/Extensions/caldav-proxy.txt<br />
| Calendar User Proxy Functionality in CalDAV<br />
|-<br />
| calendarserver-principal-property-search (Apple extension)<br />
| Undocumented?<br />
| ?<br />
|}<br />
<br />
=== Known limitations ===<br />
<br />
# Attachments are not currently supported via the CalDAV API. Attachments created by other Zimbra APIs are ignored within CalDAV.<br />
# New Calendar items cannot be created via PUT to a URL unless the component of the URL matches the form <UID>.ics where <UID> is the iCalendar UID of the calendar data being created.<br />
<br />
== Client configuration ==<br />
* [[Accessing_Zimbra_Collaboration_Server_with_iCal_and_Calendar|How to configure Mac OS Calendar to access all your Zimbra Calendars]]<br />
* [[Accessing_Zimbra_Collaboration_Server_with_Thunderbird#Viewing_your_Zimbra_Calendar_using_Lightning|How to configure Thunderbird's Lightning plugin to access an individual Zimbra Calendar]]<br />
<br />
== Historical CalDAV support ==<br />
<br />
Older versions of Zimbra used a radically different mechanism for supporting CalDAV - see [[Historical_CalDAV_Support|Historical CalDAV Support]]<br />
<br />
{{Article Footer|Zimbra Collaboration 8.7|04/06/2017}}<br />
[[Category:Clients]]<br />
[[Category:Architecture and Components]]</div>Gren Elliothttps://wiki.zimbra.com/index.php?title=CalDav_Support&diff=63454CalDav Support2017-04-13T14:21:19Z<p>Gren Elliot: /* RFCs supported by Zimbra's CalDAV implementation */</p>
<hr />
<div>{{BC|Community Sandbox}}<br />
__FORCETOC__<br />
<div class="col-md-12 ibox-content"><br />
=CalDAV Support=<br />
{{KB{{ZCS 8.0}}}}<br />
{{WIP}}<br />
<br />
== RFCs supported by Zimbra's CalDAV implementation ==<br />
'''Warning:This is a work in progress'''<br />
<br />
{| class="wikitable"<br />
! style="text-align:left;"| Standard ID<br />
! URL<br />
! Description<br />
|-<br />
| RFC 5545<br />
| https://tools.ietf.org/html/rfc5545<br />
| Internet Calendaring and Scheduling Core Object Specification (iCalendar)<br />
|-<br />
| RFC 4918<br />
| https://tools.ietf.org/html/rfc4918<br />
| HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)<br />
|-<br />
| RFC 4791<br />
| https://tools.ietf.org/html/rfc4791<br />
| Calendaring Extensions to WebDAV (CalDAV)<br />
|-<br />
| RFC 6638<br />
| https://tools.ietf.org/html/rfc6638<br />
| Scheduling Extensions to CalDAV<br />
|-<br />
| RFC 5995<br />
| https://tools.ietf.org/html/rfc5995<br />
| Using POST to Add Members to Web Distributed Authoring and Versioning (WebDAV) Collections<br />
This is the preferred mechanism for creating new entries in the calendar. Using the PUT<br />
method with a final name that doesn't strictly match the form "<UID>.ics" will always fail.<br />
Using POST allows the server to choose the final name.<br />
|-<br />
| RFC 5397<br />
| https://tools.ietf.org/html/rfc5397<br />
| WebDAV Current Principal Extension<br />
|-<br />
| RFC 5689<br />
| https://tools.ietf.org/html/rfc5689<br />
| Extended MKCOL for Web Distributed Authoring and Versioning (WebDAV)<br />
This is the preferred way to create new calendars<br />
|-<br />
| RFC 3253 (partial)<br />
| https://tools.ietf.org/html/rfc3253<br />
| Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)<br />
See Section 3.6 (Report method) and 3.8 (DAV:expand-property Report)<br />
|-<br />
| RFC 3744<br />
| https://tools.ietf.org/html/rfc3744<br />
| Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol<br />
|}<br />
<br />
=== Known limitations ===<br />
<br />
# Attachments are not currently supported via the CalDAV API. Attachments created by other Zimbra APIs are ignored within CalDAV.<br />
# New Calendar items cannot be created via PUT to a URL unless the component of the URL matches the form <UID>.ics where <UID> is the iCalendar UID of the calendar data being created.<br />
<br />
== Client configuration ==<br />
* [[Accessing_Zimbra_Collaboration_Server_with_iCal_and_Calendar|How to configure Mac OS Calendar to access all your Zimbra Calendars]]<br />
* [[Accessing_Zimbra_Collaboration_Server_with_Thunderbird#Viewing_your_Zimbra_Calendar_using_Lightning|How to configure Thunderbird's Lightning plugin to access an individual Zimbra Calendar]]<br />
<br />
== Historical CalDAV support ==<br />
<br />
Older versions of Zimbra used a radically different mechanism for supporting CalDAV - see [[Historical_CalDAV_Support|Historical CalDAV Support]]<br />
<br />
{{Article Footer|Zimbra Collaboration 8.0|04/06/2017}}<br />
[[Category:Clients]]<br />
[[Category:Architecture and Components]]</div>Gren Elliothttps://wiki.zimbra.com/index.php?title=CalDav_Support&diff=63453CalDav Support2017-04-13T14:11:50Z<p>Gren Elliot: /* RFCs supported by Zimbra's CalDAV implementation */</p>
<hr />
<div>{{BC|Community Sandbox}}<br />
__FORCETOC__<br />
<div class="col-md-12 ibox-content"><br />
=CalDAV Support=<br />
{{KB{{ZCS 8.0}}}}<br />
{{WIP}}<br />
<br />
== RFCs supported by Zimbra's CalDAV implementation ==<br />
'''Warning:This is a work in progress'''<br />
<br />
{| class="wikitable"<br />
! style="text-align:left;"| Standard ID<br />
! URL<br />
! Description<br />
|-<br />
| RFC 5545<br />
| https://tools.ietf.org/html/rfc5545<br />
| Internet Calendaring and Scheduling Core Object Specification (iCalendar)<br />
|-<br />
| RFC 4918<br />
| https://tools.ietf.org/html/rfc4918<br />
| HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)<br />
|-<br />
| RFC 4791<br />
| https://tools.ietf.org/html/rfc4791<br />
| Calendaring Extensions to WebDAV (CalDAV)<br />
|-<br />
| RFC 6638<br />
| https://tools.ietf.org/html/rfc6638<br />
| Scheduling Extensions to CalDAV<br />
|-<br />
| RFC 5995<br />
| https://tools.ietf.org/html/rfc5995<br />
| Using POST to Add Members to Web Distributed Authoring and Versioning (WebDAV) Collections<br />
This is the preferred mechanism for creating new entries in the calendar. Using the PUT<br />
method with a final name that doesn't strictly match the form "<UID>.ics" will always fail.<br />
Using POST allows the server to choose the final name.<br />
|-<br />
| RFC 5397<br />
| https://tools.ietf.org/html/rfc5397<br />
| WebDAV Current Principal Extension<br />
|-<br />
| RFC 5689<br />
| https://tools.ietf.org/html/rfc5689<br />
| Extended MKCOL for Web Distributed Authoring and Versioning (WebDAV)<br />
This is the preferred way to create new calendars<br />
|-<br />
| RFC 3253 (partial)<br />
| https://tools.ietf.org/html/rfc3253<br />
| Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)<br />
See Section 3.6 (Report method) and 3.8 (DAV:expand-property Report)<br />
|-<br />
| RFC 3744<br />
| https://tools.ietf.org/html/rfc3744<br />
| Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol<br />
|}<br />
<br />
== Client configuration ==<br />
* [[Accessing_Zimbra_Collaboration_Server_with_iCal_and_Calendar|How to configure Mac OS Calendar to access all your Zimbra Calendars]]<br />
* [[Accessing_Zimbra_Collaboration_Server_with_Thunderbird#Viewing_your_Zimbra_Calendar_using_Lightning|How to configure Thunderbird's Lightning plugin to access an individual Zimbra Calendar]]<br />
<br />
== Historical CalDAV support ==<br />
<br />
Older versions of Zimbra used a radically different mechanism for supporting CalDAV - see [[Historical_CalDAV_Support|Historical CalDAV Support]]<br />
<br />
{{Article Footer|Zimbra Collaboration 8.0|04/06/2017}}<br />
[[Category:Clients]]<br />
[[Category:Architecture and Components]]</div>Gren Elliothttps://wiki.zimbra.com/index.php?title=CalDav_Support&diff=63452CalDav Support2017-04-13T12:55:30Z<p>Gren Elliot: /* RFCs supported by Zimbra's calendar implementation */</p>
<hr />
<div>{{BC|Community Sandbox}}<br />
__FORCETOC__<br />
<div class="col-md-12 ibox-content"><br />
=CalDAV Support=<br />
{{KB{{ZCS 8.0}}}}<br />
{{WIP}}<br />
<br />
== RFCs supported by Zimbra's CalDAV implementation ==<br />
'''Warning:This is a work in progress'''<br />
<br />
* RFC 4918 WebDAV - https://tools.ietf.org/html/rfc4918<br />
* RFC 4791 Calendaring Extensions to WebDAV (CalDAV) https://tools.ietf.org/html/rfc4791<br />
* RFC 6638 Scheduling Extensions to CalDAV - https://tools.ietf.org/html/rfc6638<br />
<br />
== Client configuration ==<br />
* [[Accessing_Zimbra_Collaboration_Server_with_iCal_and_Calendar|How to configure Mac OS Calendar to access all your Zimbra Calendars]]<br />
* [[Accessing_Zimbra_Collaboration_Server_with_Thunderbird#Viewing_your_Zimbra_Calendar_using_Lightning|How to configure Thunderbird's Lightning plugin to access an individual Zimbra Calendar]]<br />
<br />
== Historical CalDAV support ==<br />
<br />
Older versions of Zimbra used a radically different mechanism for supporting CalDAV - see [[Historical_CalDAV_Support|Historical CalDAV Support]]<br />
<br />
{{Article Footer|Zimbra Collaboration 8.0|04/06/2017}}<br />
[[Category:Clients]]<br />
[[Category:Architecture and Components]]</div>Gren Elliothttps://wiki.zimbra.com/index.php?title=CalDav_Support&diff=63443CalDav Support2017-04-06T10:36:26Z<p>Gren Elliot: /* CalDAV Support */</p>
<hr />
<div>{{BC|Community Sandbox}}<br />
__FORCETOC__<br />
<div class="col-md-12 ibox-content"><br />
=CalDAV Support=<br />
{{KB{{ZCS 8.0}}}}<br />
{{WIP}}<br />
<br />
== RFCs supported by Zimbra's calendar implementation ==<br />
'''Warning:This is a work in progress'''<br />
<br />
* RFC 4918 WebDAV - https://tools.ietf.org/html/rfc4918<br />
* RFC 4791 Calendaring Extensions to WebDAV (CalDAV) https://tools.ietf.org/html/rfc4791<br />
* RFC 6638 Scheduling Extensions to CalDAV - https://tools.ietf.org/html/rfc6638<br />
<br />
== Client configuration ==<br />
* [[Accessing_Zimbra_Collaboration_Server_with_iCal_and_Calendar|How to configure Mac OS Calendar to access all your Zimbra Calendars]]<br />
* [[Accessing_Zimbra_Collaboration_Server_with_Thunderbird#Viewing_your_Zimbra_Calendar_using_Lightning|How to configure Thunderbird's Lightning plugin to access an individual Zimbra Calendar]]<br />
<br />
== Historical CalDAV support ==<br />
<br />
Older versions of Zimbra used a radically different mechanism for supporting CalDAV - see [[Historical_CalDAV_Support|Historical CalDAV Support]]<br />
<br />
{{Article Footer|Zimbra Collaboration 8.0|04/06/2017}}<br />
[[Category:Clients]]<br />
[[Category:Architecture and Components]]</div>Gren Elliothttps://wiki.zimbra.com/index.php?title=Historical_CalDAV_Support&diff=63442Historical CalDAV Support2017-04-06T10:16:12Z<p>Gren Elliot: Created page with "=Historical CalDAV Support= {{KB|{{Unsupported}}|{{ZCS 5.0}}||}} {{Archive}}{{WIP}} For Zimbra Collaboration 8.0 and later, see CalDAV support ''What foll..."</p>
<hr />
<div>=Historical CalDAV Support=<br />
{{KB|{{Unsupported}}|{{ZCS 5.0}}||}}<br />
{{Archive}}{{WIP}}<br />
<br />
For Zimbra Collaboration 8.0 and later, see [[CalDav_Support|CalDAV support]]<br />
<br />
''What follows is archival documentation for earlier versions of Zimbra Collaboration''<br />
<br />
Fully supported from ZCS 5.0 until some version prior to Zimbra Collaboration 8.0 (exact cutover needs further research) using [http://tomcat.apache.org/connectors-doc-archive/jk2/jk2/davhowto.html Apache 2.x/mod-dav - Tomcat/jk2].<br />
<br />
Client settings:<br />
* [[CalDAV_with_Leopard_iCal|Apple iCal on Mac&nbsp;OS&nbsp;X 10.5 Leopard]]<br />
* [[Accessing_Zimbra_Collaboration_Suite_with_Thunderbird#Accessing_your_Zimbra_Calendar_using_Lightning_with_CalDAV_.28Only_works_with_ZCS_5.0.2B_and_Lightning_0.8.2B.29|Accessing your Zimbra Calendar using Thunderbird add-on Lightning with CalDAV]] or [[Thunderbird & Lightning]].<br />
* [[CalDav_and_SunBird]]<br />
{{Article Footer|Zimbra Collaboration 5.0|04/16/2014}}<br />
[[Category:Clients]]</div>Gren Elliothttps://wiki.zimbra.com/index.php?title=CalDav_Support&diff=62839CalDav Support2016-09-19T15:09:39Z<p>Gren Elliot: </p>
<hr />
<div>{{BC|Community Sandbox}}<br />
__FORCETOC__<br />
<div class="col-md-12 ibox-content"><br />
=CalDAV Support=<br />
{{KB|{{Unsupported}}|{{ZCS 5.0}}||}}<br />
{{Archive}}{{WIP}}<br />
<br />
For Zimbra Collaboration 8.7 8.6, 8.5, 8.0, see:<br />
<br />
* [[Accessing_Zimbra_Collaboration_Server_with_iCal_and_Calendar|How to configure Mac OS Calendar to access all your Zimbra Calendars]]<br />
* [[Accessing_Zimbra_Collaboration_Server_with_Thunderbird#Viewing_your_Zimbra_Calendar_using_Lightning|How to configure Thunderbird's Lightning plugin to access an individual Zimbra Calendar]]<br />
<br />
==Historical CalDAV support==<br />
''What follows is archival documentation for earlier versions of Zimbra Collaboration''<br />
<br />
Fully supported from ZCS 5.0+ using [http://tomcat.apache.org/connectors-doc-archive/jk2/jk2/davhowto.html Apache 2.x/mod-dav - Tomcat/jk2].<br />
<br />
Client settings:<br />
* [[CalDAV_with_Leopard_iCal|Apple iCal on Mac&nbsp;OS&nbsp;X 10.5 Leopard]]<br />
* [[Accessing_Zimbra_Collaboration_Suite_with_Thunderbird#Accessing_your_Zimbra_Calendar_using_Lightning_with_CalDAV_.28Only_works_with_ZCS_5.0.2B_and_Lightning_0.8.2B.29|Accessing your Zimbra Calendar using Thunderbird add-on Lightning with CalDAV]] or [[Thunderbird & Lightning]].<br />
* [[CalDav_and_SunBird]]<br />
{{Article Footer|Zimbra Collaboration 5.0|04/16/2014}}<br />
[[Category:Clients]]</div>Gren Elliothttps://wiki.zimbra.com/index.php?title=CalDAV_with_Leopard_iCal&diff=62838CalDAV with Leopard iCal2016-09-19T14:54:00Z<p>Gren Elliot: </p>
<hr />
<div>{{Archive}}=Introduction=<br />
<br />
For details on how to configure Calendar for Apple MacOS with Zimbra Collaboration 8.7, 8.6, 8.5, or 8.0, see:<br />
<br />
https://wiki.zimbra.com/index.php?title=Accessing_Zimbra_Collaboration_Server_with_iCal_and_Calendar<br />
<br />
''The following archive material is maintained for reference for use with obsolete versions of Zimbra.''<br />
<br />
Zimbra 5.0 Supports the CalDAV standard. This allows users to publish and subscribe to calendars, share them collaboratively, synchronize between multiple users and synchronize between multiple devices.<br />
<br />
The CalDAV standard is an extension to the WebDAV standard for accessing calendars on a WebDAV server. Apple's iCal.app client (called Calendar in more recent versions of MacOS) supports the CalDAV standard.<br />
<br />
CalDAV models calendar events as HTTP resources in iCalendar format, and models calendars containing events as WebDAV collections. <br />
<br />
When using CalDAV with iCal.app, all of the user's calendars are added to iCal.app<br />
<br />
=Requirements=<br />
<br />
#Zimbra Collaboration Suite 5.0 RC2 or Higher<br />
#MacOS 10.5 or Higher <br />
<br />
==Zimbra Connector for iSync==<br />
<br />
'''Note. This connector is not supported with modern versions of Zimbra. CalDAV should be used instead.'''<br />
<br />
The Zimbra Connector for iSync syncs Zimbra calendars to iCal for Tiger (10.4) and Leopard (10.5). The sync is done using SOAP instead of CalDAV -- unless you are running Mac OS 10.5 or previous and you you care about sync'ing contacts in addition to calendars, choose iSync. Otherwise, don't bother with with it, and setup your calendars as CalDAV calendars in iCal.<br />
<br />
=Configuration=<br />
<br />
In Leopard (10.5), open iCal and go to: Preferences > Accounts. Then:<br />
<br />
* Click the + (plus sign) to add an acocunt<br />
* Enter a description; and enter the Zimbra username and password<br />
* Click the arrow to expand "Server Settings"<br />
* For the Account URL enter: <tt>http(s)://<server></tt>, in other words,<tt><nowiki>https://mail.example.com</nowiki></tt> -- iCal supports CalDAV principal concept so you'll notice that iCal will expand it to say: <tt><nowiki>http(s)://<server>/principals/users/<username></nowiki></tt><br />
<br />
''Note: You must not append anything after the servername when using iCal. There is an iCal bug that will cause it to fail. The URL should look like: http://host.server.com and not http://host.server.com/''<br />
<br />
* You're done -- hit Add.<br />
<br />
=Errors due to self-signed certificates=<br />
If your Zimbra server is using a self-signed certificate the subsciption to the server may fail with error -9813. In this case browse to your Zimbra server via Safari (using https) - accept the offered certificate permanently in all instances and close and reopen iCal.<br />
<br />
Reference: http://discussions.apple.com/thread.jspa?threadID=1505865&tstart=149<br />
<br />
==Older MacOS (Tiger and older) ==<br />
iCal on Tiger and older release only support ics import and export, not the full CalDAV. The ics import mode is not compatible with CalDAV at all, and the usage is completely different.<br />
<br />
In order to use ics import mode, first the user needs to export the calendar folder as ics, save to a file, then import the file into the target calendar application. Using ics import mode, the changes made to the 3rd party calendar is saved as a local copy, and ''does not automatically synchronize with Zimbra server''.<br />
<br />
When using CalDAV client, the changes are immediately saved to the server, unless the client is run in the offline mode. There is no manual file based synchronization needed as with ics import mode.<br />
<br />
=Resources=<br />
http://www.zimbra.com/forums<br />
http://caldav.calconnect.org/<br />
http://ietf.osafoundation.org/caldav/<br />
<br />
[[Category:OSX]]<br />
[[Category:Clients]]</div>Gren Elliothttps://wiki.zimbra.com/index.php?title=Accessing_Zimbra_Collaboration_Server_with_Thunderbird&diff=62837Accessing Zimbra Collaboration Server with Thunderbird2016-09-19T13:51:17Z<p>Gren Elliot: /* Introduction */</p>
<hr />
<div>{{BC|Community Sandbox}}<br />
__FORCETOC__<br />
<div class="col-md-12 ibox-content"><br />
=Accessing Zimbra Collaboration with Thunderbird=<br />
{{KB|{{Unsupported}}|{{ZCS 8.6}}|{{ZCS 8.5}}|{{ZCS 8.0}}|}}<br />
{{WIP}}<br />
<div class="col-md-9 ibox-content"><br />
<div class="thumbnail img-thumbnail">https://wiki.zimbra.com/images/4/42/Thunderbird-imap-banner.png</div><br />
</div><br />
=Introduction=<br />
With Zimbra Collaboration Server, you are able to access your email using the Mozilla Thunderbird messaging and collaboration client. Optionally, you can view your Zimbra Calendar using the separate Lightning Add-on for Thunderbird.<br />
<br />
This guide shows you how to access to your Zimbra Mail and Calendar using Thunderbird 2 with the Lightning 0.5 Add-On.<br />
<br />
=Before You Begin=<br />
This guide assumes that you have already installed Thunderbird and, optionally, have already installed the Lightning Add-on. For more information on downloading and installing this software, go to Mozilla's Thunderbird page, '' http://www.mozilla.com/en-US/thunderbird/'' .<br />
<br />
To access your email, you must have the following information:<br />
* '''Your Zimbra email address and password'''.<br />
* '''Incoming mail server'''. This is usually in the form of mail.domain.com.<br />
* '''Outgoing mail server (SMTP)'''. This is usually in the form of smtp.domain.com.<br />
<br />
Your system administrator will be able to give you this information if you do not already have it.<br />
<br />
=Accessing your Zimbra Mail with Thunderbird=<br />
To access your Zimbra Mail, you must first create an account in Thunderbird. The following steps guide you through setting up a new account in Thunderbird.<br />
<br />
====To create a new account in Thunderbird====<br />
1.- Go to '''File > New > Account'''. This will open the Account Wizard.<br />
If you have just opened Thunderbird for the first time, the Account Wizard will automatically open. Enter the name you want to appear in the '''From''' field of your outgoing emails in the '''Your Name''' field. Enter your Zimbra email address into the '''Email Address''' field. Click '''Next'''.<br />
<div class="thumbnail img-thumbnail">https://wiki.zimbra.com/images/a/aa/Thunderbird-imap-001.png</div><br/><br />
2.- Thunderbird will try to get the Autodiscover information using some different technologies, after a few seconds Thunderbird will prompt with some Autodiscover information, if the data is not what you expect, you mus click in the Manual config button:<br />
<div class="thumbnail img-thumbnail">https://wiki.zimbra.com/images/a/ae/Thunderbird-imap-002.png</div><br/><br />
<br />
3.- Select '''IMAP''' o '''POP3''' for the Incoming Email, you must be change the Server Hostname with your correct information. Introduce the SMTP Server Hostname as well. Zimbra recommends always use secure channels, so you can select SSL for both, IMAP/POP3 and SMTP.<br />
'''''Note:''' By default, Thunderbird will use a secure connection for your incoming and outgoing servers using TLS. If your servers require a secure connection, such as SSL, you must set this after you exit the Account Wizard. To change your secure connection setting'''<br />
<div class="thumbnail img-thumbnail">https://wiki.zimbra.com/images/b/b1/Thunderbird-imap-003.png</div><br/><br />
<br />
4.- Verify that the information displayed is correct. If any information is incorrect, update the information. When the account information is correct, click '''Done'''.<br />
<div class="thumbnail img-thumbnail">https://wiki.zimbra.com/images/6/69/Thunderbird-imap-004.png</div><br/><br />
<br />
Your settings are saved, and the Account Wizard closes. You are now able to access your Zimbra Mail.<br />
<br />
If your incoming server and outgoing server use not secure connections, you will need to configure this before you are able to access your mail. Additionally, if you did not specify an outgoing server when you were setting up your Zimbra email account, you will not be able to send outgoing messages yet. See the next section in order to change your server settings.<br />
<br />
=Changing Your Server Settings=<br />
If your incoming server and outgoing server doesn't use secure connections, you will need to configure this before you are able to access your mail. Additionally, if your Outgoing Server (SMTP) is not set to the correct server, you will not be able to send outgoing messages. Use the following directions to change your server settings.<br />
<br />
==To change the secure connection settings for your incoming mail server==<br />
1.- In Thunderbird, go to '''Tools>Account Settings''' or '''right-click''' in your Email account and '''Settings'''<br />
<div class="thumbnail img-thumbnail">https://wiki.zimbra.com/images/3/37/Thunderbird-imap-005.png</div><br/><br />
2.- Select '''Server Settings''', which is located under your Zimbra email account profile, listed on the left. Your Server Settings are displayed.<br />
<div class="thumbnail img-thumbnail">https://wiki.zimbra.com/images/a/a5/Thunderbird-imap-006.png</div><br/><br />
3.- Under '''Security Settings''', select whether to use '''TLS if available''', '''TLS''', or '''SSL'''. Select '''Never''' if you do not want to use a secure connection. Select whether to use secure authentication.<br />
4.- Click '''OK''' to save your settings.<br />
<br />
==To change the secure connection settings for your outgoing mail server==<br />
1.- In Thunderbird, go to '''Tools>Account Settings''' or '''right-click''' in your Email account and '''Settings'''<br />
<div class="thumbnail img-thumbnail">https://wiki.zimbra.com/images/3/37/Thunderbird-imap-005.png</div><br/><br />
2.- Select '''Outgoing Server (SMTP)''', which is located at the bottom of the Settings list on the left. Your Outgoing Server (SMTP) Settings are displayed.<br />
3.- Select the outgoing server for your Zimbra email account, and click '''Edit'''.<br />
<div class="thumbnail img-thumbnail">https://wiki.zimbra.com/images/3/3f/Thunderbird-imap-007.png</div><br/><br />
4.- In the SMTP Server dialog, under '''Security and Authentication''', select whether to use '''TLS if available''', '''TLS''', or '''SSL'''. Select '''No''' if you do not want to use a secure connection. Click '''OK'''.<br />
<div class="thumbnail img-thumbnail">https://wiki.zimbra.com/images/3/38/Thunderbird-imap-008.png</div><br/><br />
5.- Click '''OK''' to save your settings.<br />
<br />
==To add an outgoing server to your Zimbra email account==<br />
1.- In Thunderbird, go to '''Tools>Account Settings''' or '''right-click''' in your Email account and '''Settings'''<br />
<div class="thumbnail img-thumbnail">https://wiki.zimbra.com/images/3/37/Thunderbird-imap-005.png</div><br/><br />
2.- Select '''Outgoing Server (SMTP)''', which is located at the bottom of the Settings list on the left. Your Outgoing Server (SMTP) Settings are displayed.<br />
3.- Click '''Add'''.<br />
<div class="thumbnail img-thumbnail">https://wiki.zimbra.com/images/6/60/Thunderbird-imap-009.png</div><br/><br />
4.- In the SMTP Server dialog, enter the following information:<br />
<div class="thumbnail img-thumbnail">https://wiki.zimbra.com/images/9/99/Thunderbird-imap-010.png</div><br/><br />
* '''Description'''. Enter a name for your outgoing server.<br />
* '''Server name'''. Enter the name of your outgoing server. This is usually in the form of smtp.domain.com<br />
* '''Port'''. This is 465 by default. If your SMTP server has a different port number, enter it here. Non secure connections needs to select port 25.<br />
* '''User Name.''' Enter your Zimbra email account user name.<br />
* '''Secure Connection'''. Select whether to use '''TLS if available''', '''TLS''', or '''SSL'''. Select '''No''' if you do not want to use a secure connection.<br />
<br />
Click '''OK'''.<br />
5.- In the Account Settings dialog, select your Zimbra email account, located in the Settings list on the left.<br />
6.- Select the Zimbra outgoing server from the '''Outgoing Server (SMTP)''' drop-down list in your Account Settings.<br />
<div class="thumbnail img-thumbnail">https://wiki.zimbra.com/images/0/08/Thunderbird-imap-011.png</div><br/><br />
7.- Click '''OK'''.<br />
<br />
==Configure Thunderbird to use IMAP properly==<br />
Wehn you use IMAP, you might want to have all the Drafts, Sent messages, Junk, and Trash folders fully synced between your Zimbra account and your Thunderbird Client. This steps shows you how to configure it properly.<br />
1.- The first step is '''Subscribe''' to the proper IMAP Folders, press '''right-click''' in your Email account name, and select '''Subscribe'''<br />
<div class="thumbnail img-thumbnail">https://wiki.zimbra.com/images/2/2f/Thunderbird-imap-012.png</div><br/><br />
2.- Subscribe to the proper Folders like '''Drafts, Junk, Sent''' and '''Trash'''.<br />
<div class="thumbnail img-thumbnail">https://wiki.zimbra.com/images/c/c8/Thunderbird-imap-013.png</div><br/><br />
3.- Go back and then, go to '''Tools>Account Settings''' or '''right-click''' in your Email account and '''Settings'''<br />
<div class="thumbnail img-thumbnail">https://wiki.zimbra.com/images/3/37/Thunderbird-imap-005.png</div><br/><br />
4.- Go to '''Copies & Folders''' and then select where you want to save your Sent emails, your Drafts as well as your templates (you can use the Drafts folder in the Zimbra server)<br />
<div class="thumbnail img-thumbnail">https://wiki.zimbra.com/images/6/6c/Thunderbird-imap-014.png</div><br/><br />
5.- Go now to '''Junk Settings''', and activate the option to move the Junk messages into the folder localted in the IMAP account.<br />
<div class="thumbnail img-thumbnail">https://wiki.zimbra.com/images/6/6e/Thunderbird-imap-015.png</div><br/><br />
6.- Finally in '''Server Settings''', set your Trash Folder to point into your IMAP Trash folder.<br />
<div class="thumbnail img-thumbnail">https://wiki.zimbra.com/images/c/ca/Thunderbird-imap-016.png</div><br/><br />
<br />
===Examples===<br />
You will be able to see the same messages now in your Thunderbird as well in your Web Client inside the Sent, Junk, Drafts and Trash folders:<br />
'''Sent Example'''<br />
<div class="thumbnail img-thumbnail">https://wiki.zimbra.com/images/c/c5/Thunderbird-imap-017.png</div><br/><br />
<br />
'''Junk Example'''<br />
<div class="thumbnail img-thumbnail">https://wiki.zimbra.com/images/d/dd/Thunderbird-imap-018.png</div><br/><br />
<br />
'''Trash Example'''<br />
<div class="thumbnail img-thumbnail">https://wiki.zimbra.com/images/6/6a/Thunderbird-imap-019.png</div><br/><br />
<br />
=Viewing your Zimbra Calendar using Lightning=<br />
The following steps show you how to read your Zimbra Calendar with Thunderbird using the [https://www.mozilla.org/en-US/projects/calendar/ '''Lightning Add-on''']. These instructions assume that you have already installed Lightning 0.5 at least, [https://support.mozilla.org/en-US/kb/installing-lightning-thunderbird '''Thunderbird comes with Lightning since the version 38'''].<br />
==To view your Zimbra Calendar using Lightning and CalDAV==<br />
The recommended way to connect your Zimbra Calendar and Thunderbird is using Lightning and CalDAV. You will be able to do all the typical actions in a Calendar, and you will synchronize with your Zimbra Server, as follows:<br />
* Create appointments<br />
* Edit appointments created from the Web Client or another device<br />
* Delete appointments<br />
* Move appointments<br />
* Dismiss appointments<br />
* etc.<br />
===Zimbra Calendar and requirements===<br />
Since Zimbra Collaboration 6, you don't need any additional step or configuration in your server. You need to know the Calendar name that you want to use in the CalDAV client. The final URL to use in the CalDAV client would be:<br />
https://zimbra.example.com/dav/<USERNAME>/CalendarNAME<br />
You can also add your credentials into the URL. Note that this includes your password, which may not be recommended. <br />
https://<USERNAME>:<PASSWORD>@zimbrahost.example.com/dav/<USERNAME>/Calendar<br />
<br />
For example, this uses Calendar2:<br />
<div class="thumbnail img-thumbnail">https://wiki.zimbra.com/images/a/a5/Thunderbird-caldav-001.png</div><br/><br />
<br />
===Thunderbird instructions===<br />
* 1. Click on the '''Calendars''' tab, in the top left of your Thunderbird application.<br />
<div class="thumbnail img-thumbnail">https://wiki.zimbra.com/images/4/4a/Thunderbird-caldav-002.png</div><br/><br />
<br />
* 2. Click right-click '''New'''. A Create New Calendar dialog will display.<br />
<div class="thumbnail img-thumbnail">https://wiki.zimbra.com/images/9/9f/Thunderbird-caldav-003.png</div><br/><br />
<br />
* 3. Select '''On the Network'''. Click '''Next'''.<br />
<div class="thumbnail img-thumbnail">https://wiki.zimbra.com/images/4/4e/Thunderbird-caldav-004.png</div><br/><br />
<br />
* 4. Select '''CalDAV'''. In the '''Location''' field, enter the URL of your Zimbra Calendar, and click '''Next'''.<br />
<div class="thumbnail img-thumbnail">https://wiki.zimbra.com/images/e/eb/Thunderbird-caldav-005.png</div><br/><br />
<br />
* 5. Enter a name for your Zimbra Calendar in the '''Name''' field. Select a color for your Calendar, and click '''Next'''.<br />
<div class="thumbnail img-thumbnail">https://wiki.zimbra.com/images/0/0a/Thunderbird-caldav-006.png</div><br/><br />
<br />
* 6. Enter your username and password, if prompted.<br />
<div class="thumbnail img-thumbnail">https://wiki.zimbra.com/images/6/62/Thunderbird-caldav-007.png</div><br/><br />
<br />
* 7. You will be able to see all the Appointments in your Zimbra Web Client, and you will be able to edit them, delete them, etc.<br />
<div class="thumbnail img-thumbnail">https://wiki.zimbra.com/images/7/74/Thunderbird-caldav-008.png</div><br/><br />
<br />
===Shared Calendar & Tasks in Thunderbird===<br />
You can use as well all the Zimbra sharing power with Thunderbird and CalDAV, for example: Imagine that you are the Responsible Person for one Department and you want to create a Calendar per each Technician, and a Tasks List, like in the next diagram:<br />
<div class="thumbnail img-thumbnail">https://wiki.zimbra.com/images/a/a0/Thunderbird-share.png</div><br />
<br />
The Responsible must create each Calendar or Tasks List and share with the rest of Technicians, giving them the read-only or read-write permission. You must be careful with the location of the Calendars, or Tasks List, for example if you create the Tasks List called Technician Bob, inside your own Task List, the URL to share will be > '''https://zimbra.example.com/dav/RESPONSIBLEUSERNAME/Tasks/Technician%20Bob''' You can see here an example:<br />
<div class="thumbnail img-thumbnail">https://wiki.zimbra.com/images/7/7c/Thunderbird-tasks-008.png</div><br />
<br />
In this example, the Responsible creates a Tasks List for Technician Bob, is the same procedure for Calendars as well. Go to the Responsible Tasks, and right-click > New Task List<br />
<div class="thumbnail img-thumbnail">https://wiki.zimbra.com/images/5/5a/Thunderbird-tasks-003.png</div><br />
<br />
Then, write the name for the Tasks List, in this case Technician Bob, you will need later the %20 in the URL, if you can, it's much better to use - or _ instead space.<br />
<div class="thumbnail img-thumbnail">https://wiki.zimbra.com/images/b/b5/Thunderbird-tasks-004.png</div><br />
<br />
Edit then the new Tasks List with right-click > Properties and select Add share<br />
<div class="thumbnail img-thumbnail">https://wiki.zimbra.com/images/6/66/Thunderbird-tasks-005.png</div><br />
<br />
In the email field, select the Bob's emails address, and select the role you want for Bob, read-only or read-write.<br />
<div class="thumbnail img-thumbnail">https://wiki.zimbra.com/images/3/3d/Thunderbird-tasks-006.png</div><br />
<br />
Now, you can tell to Bob the URL that he must use to connect to the shared resources, Calendar, Tasks, etc. The URL will be the Responsible one, like '''https://zimbra.example.com/dav/RESPONSABLEUSERNAME/Tasks/Technician%20Bob''' even if the URL points to the Responsible, because Bob has access to that concrete resource, Bob just need to write his credentials when Thunderbird asks about them.<br />
<div class="thumbnail img-thumbnail">https://wiki.zimbra.com/images/6/6f/Thunderbird-tasks-007.png</div><br />
<br />
===Log trace when sync===<br />
When the appointments are pulled from the Zimbra Server to the CalDAV client, you will be able to see the next log traces in the '''/opt/zimbra/logs/mailbox.log'''. You can see that these came from Thunderbird with Lightning:<br />
<pre>2015-08-06 13:48:03,704 INFO [btpool0-14://zimbra86.zimbra.io/dav/admin/Calendar2/] [aname=admin@zimbra.io;ip=20.90.30.30;ua=Mozilla/5.0 (Windows NT 6.1;; WOW64;; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 Lightning/4.0.1.2;] FileUploadServlet - saveUpload(): received Upload: { accountId=1def13c4-aea7-401d-9665-8007079a29c3, time=Thu Aug 06 13:48:03 EDT 2015, size=150, uploadId=8f67c628-d165-4efb-a8a9-b5fb75314939:7c78f0c6-fda4-4d1e-b4f6-705f7dd8a0e5, name=null, path=null }<br />
2015-08-06 13:48:03,720 INFO [btpool0-14://zimbra86.zimbra.io/dav/admin/Calendar2/] [name=admin;aname=admin@zimbra.io;ip=20.90.30.30;ua=Mozilla/5.0 (Windows NT 6.1;; WOW64;; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 Lightning/4.0.1.2;] dav - DavServlet operation PROPFIND to /home/admin/Calendar2/ (depth: zero) finished in 18ms<br />
2015-08-06 13:48:03,763 INFO [btpool0-14://zimbra86.zimbra.io/dav/admin/Calendar2/] [aname=admin@zimbra.io;ip=20.90.30.30;ua=Mozilla/5.0 (Windows NT 6.1;; WOW64;; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 Lightning/4.0.1.2;] FileUploadServlet - saveUpload(): received Upload: { accountId=1def13c4-aea7-401d-9665-8007079a29c3, time=Thu Aug 06 13:48:03 EDT 2015, size=144, uploadId=8f67c628-d165-4efb-a8a9-b5fb75314939:1dd719a2-7648-4420-b74b-eafb337435df, name=null, path=null }<br />
2015-08-06 13:48:03,787 INFO [btpool0-14://zimbra86.zimbra.io/dav/admin/Calendar2/] [aname=admin@zimbra.io;ip=20.90.30.30;ua=Mozilla/5.0 (Windows NT 6.1;; WOW64;; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 Lightning/4.0.1.2;] dav - DavServlet operation PROPFIND to /home/admin/Calendar2/ (depth: one) finished in 25ms<br />
2015-08-06 13:48:03,832 INFO [btpool0-14://zimbra86.zimbra.io/dav/admin/Calendar2/] [aname=admin@zimbra.io;ip=20.90.30.30;ua=Mozilla/5.0 (Windows NT 6.1;; WOW64;; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 Lightning/4.0.1.2;] FileUploadServlet - saveUpload(): received Upload: { accountId=1def13c4-aea7-401d-9665-8007079a29c3, time=Thu Aug 06 13:48:03 EDT 2015, size=262, uploadId=8f67c628-d165-4efb-a8a9-b5fb75314939:ebd1f398-f7a7-4530-bbc7-bd6292195163, name=null, path=null }<br />
2015-08-06 13:48:03,845 INFO [btpool0-14://zimbra86.zimbra.io/dav/admin/Calendar2/] [name=admin;aname=admin@zimbra.io;ip=20.90.30.30;ua=Mozilla/5.0 (Windows NT 6.1;; WOW64;; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 Lightning/4.0.1.2;] dav - DavServlet operation REPORT to /home/admin/Calendar2/ (depth: one) finished in 14ms</pre><br />
<br />
==Read-Only, not recommended - To view your Zimbra Calendar using Lightning and ICS==<br />
'''Note: These instructions will allow you to view your calendar using Thunderbird with the Lightning Add-on. You will not be able to create or edit appointments, meetings, or events.'''<br />
1. Open the Zimbra Web Client, and click the '''Calendar''' tab.<br />
2. Right click '''Calendar''' in the Calendar List pane, and select '''Share Calendar''' from the right-click menu.<br />
The URL of your Calendar is located at the bottom of the Share Properties dialog. Write down or copy this URL.<br />
<br />
:[[Image:TB_Share_Properties.png]]<br />
<br />
3. Open Thunderbird.<br />
<br />
4. Click the '''Calendars''' tab in the lower left of your Thunderbird application.<br />
<br />
:[[Image:TB_Lightning_Pane.png]]<br />
<br />
5. Click '''New'''. A Create New Calendar dialog will display.<br />
<br />
6. Select '''On the Network'''. Click '''Next'''.<br />
<br />
:[[Image:TB_Create_New_Calendar.png]]<br />
<br />
7. Select '''iCalendar (ICS)'''. In the '''Location''' field, enter the URL of your Zimbra Calendar. Click '''Next'''.<br />
<br />
:[[Image:TB_Locate_Your_Calendar.png]]<br />
<br />
8. Enter a name for your Zimbra Calendar in the '''Name''' field. Then, select a color for your Calendar. Click '''Next'''.<br />
<br />
:[[Image:TB_Customize_Your_Calendar.png]]<br />
<br />
9. Enter your username and password, if prompted.<br />
<br />
'''''Note:''' If you are not prompted, and access to the calendar fails, a workaround that I found is using a Calendar URL in this scheme - not elegant to put a password inside this URL; but the only way that worked for me ([[User:HenningSprang|HenningSprang]]):''<br />
<pre><br />
webcal://<USERNAME>:<PASSWORD>@zimbrahost.example.com/home/<USERNAME>/Calendar<br />
</pre><br />
<br />
10. Click '''Finish'''.<br />
<br />
=Feature Differences When Using Thunderbird=<br />
<br />
If you have used the Zimbra Web Client, note that the following features are different when using Thunderbird as a client.<br />
<br />
* To view mail folders that you have created using the Zimbra Web Client, you must subscribe to them.<br />
* Thunderbird may not always expunge deleted items or old drafts. These messages will be visible if you access your mail using Zimbra Web Client.<br />
* Lightning does not use notifications for upcoming events and meetings.<br />
* The Lightning Add-On may not automatically refresh your Zimbra Calendar. To see the most recent version of your Calendar, right-click and select '' Reload Remote Calendars'' .<br />
* Lightning only records a single set of authentication information for all remote calendars. If you have already set up access to another remote calendar using Lightning, you may encounter authentication errors when attempting to view your Zimbra calendar.<br />
<br />
=Accessing your addressbook using CardBook=<br />
A recent add-on available on the Thunderbird market allow your desktop client to connect to the DAV API of Zimbra and synchronize all the contacts.<br />
<br />
First of all you need to [https://addons.mozilla.org/fr/thunderbird/addon/cardbook/ download] the extention on the market and follow the how to provided in order to activate and present the cardbood extention.<br />
<br />
One done, click on "add addressbook".<br />
You will start the wizard. In it the first window select the "on the network" option and then "next"<br />
<br />
[[File:Thunderbird-Contact-01.png]]<br />
<br />
On the second panel you will need to fill the different fileds according to your environment :<br />
<br />
[[File:Thunderbird-Contact-02.png]]<br />
*URL : https://ZIMBRA_SERVER/dav/USER@DOMAIN.TLD/Contacts<br />
*Username : User@DOMAIN.TLD <br />
*Password : YOUR_PASSWORD<br />
<br />
You will need to validate the setting in order to finish the installation.<br />
<br />
We have now our contacts synchronized with Thunderbird.<br />
<br />
[[File:Thunderbird-Contact-03.png]]<br />
<br />
{{Article_Footer|ZCS 8.6, 8.5, 8.0.x, 7.0.x|10/10/2007}}<br />
<br />
[[Category: Clients]]<br />
{{NeedSME|Jorge|SME2|Gayle B.}}</div>Gren Elliothttps://wiki.zimbra.com/index.php?title=Admin_Console_Performance_Issues_when_using_Delegated_Admin&diff=62200Admin Console Performance Issues when using Delegated Admin2016-06-20T16:22:04Z<p>Gren Elliot: /* Zimbra 8.6 patch 2 and later patch levels */</p>
<hr />
<div>{{BC|Certified}}<br />
__FORCETOC__<br />
<div class="col-md-12 ibox-content"><br />
=Admin Console Performance Issues when using Delegated Admin=<br />
{{KB|{{ZC}}|{{ZCS 9.0}}|{{ZCS 8.7}}|}}<br />
{{WIP}}<br />
<br />
'''Note''': This information is related to [https://bugzilla.zimbra.com/show_bug.cgi?id=97743 Bug 97743].<br />
<br />
== Overview ==<br />
If you are experiencing significant admin console performance issues when using delegated admin, upgrade to version 8.6 Patch 2 or version 8.7<br />
If you still encounter performance issues, adjust these configuration settings:<br />
<br />
=== Zimbra 8.7 and later ===<br />
<br />
Adjust these settings in LDAP<br />
<br />
* zimbraShortTermAllEffectiveRightsCacheExpiration (default: 50s)<br />
* zimbraShortTermAllEffectiveRightsCacheSize (default: 128)<br />
* zimbraShortTermGranteeCacheExpiration (default: 50s)<br />
* zimbraShortTermGranteeCacheSize (default: 128)<br />
<br />
=== Zimbra 8.6 patch 2 and later patch levels ===<br />
<br />
Configure these LC keys:<br />
<br />
* short_term_all_effective_rights_cache_expiration (default: 50000)<br />
* short_term_all_effective_rights_cache_size (default: 128)<br />
* short_term_grantee_cache_expiration (default: 50000)<br />
* short_term_grantee_cache_size (default: 128)<br />
<br />
'''Note''': The default sizes are 128, with default expirations in milliseconds. Using higher values is not recommended.<br />
<br />
== LDAP key descriptions ==<br />
<br />
=== zimbraShortTermAllEffectiveRightsCacheSize ===<br />
<br />
Maximum number of entries in the short term All Effective Rights cache.<br />
<br />
This cache can improve performance by avoiding recomputing All Effective Rights of named entries like accounts frequently in a short period of time.<br />
<br />
Can disable the cache be specifying a value of 0<br />
<br />
The default value is '''128'''<br />
<br />
=== zimbraShortTermAllEffectiveRightsCacheExpiration ===<br />
<br />
Maximum time an entry in the short term All Effective Rights cache will be regarded as valid.<br />
<br />
If value is 0, the cache is disabled.<br />
<br />
The cache is particularly useful when significant use is made of delegated administration.<br />
<br />
All Effective Rights are computations of the rights that named entries like accounts have - although when used, they are checked separately.<br />
<br />
The longer the value of this setting is, the more stale the view of the details is likely to be. For this reason, the '''maximum''' accepted value is 30m.<br />
Larger values will be treated as being 30m<br />
<br />
The default value is '''50s'''<br />
<br />
=== zimbraShortTermGranteeCacheSize ===<br />
<br />
Maximum number of entries in the short term Grantee cache.<br />
<br />
This cache can improve performance by avoiding recomputing details frequently in a short period of time, for instance for each entry in search results.<br />
<br />
Can disable the cache be specifying a value of 0<br />
<br />
The default value is '''128'''<br />
<br />
=== zimbraShortTermGranteeCacheExpiration ===<br />
<br />
Maximum time an entry in the Grantee cache will be regarded as valid.<br />
<br />
If value is 0, the cache is disabled.<br />
<br />
The cache is particularly useful when significant use is made of delegated administration.<br />
<br />
Grantees objects provide a view of what rights a grantee has - although those are checked separately.<br />
<br />
The longer the value of this setting is, the more stale the view of the details is likely to be. For this reason, the '''maximum''' accepted value is 30m.<br />
Larger values will be treated as being 30m<br />
<br />
The default value is '''50s'''<br />
<br />
{{Article Footer|Zimbra Collaboration 9.0, 8.7 |05/05/2015}}</div>Gren Elliothttps://wiki.zimbra.com/index.php?title=Admin_Console_Performance_Issues_when_using_Delegated_Admin&diff=62199Admin Console Performance Issues when using Delegated Admin2016-06-20T16:21:25Z<p>Gren Elliot: /* Zimbra 8.7 and later */</p>
<hr />
<div>{{BC|Certified}}<br />
__FORCETOC__<br />
<div class="col-md-12 ibox-content"><br />
=Admin Console Performance Issues when using Delegated Admin=<br />
{{KB|{{ZC}}|{{ZCS 9.0}}|{{ZCS 8.7}}|}}<br />
{{WIP}}<br />
<br />
'''Note''': This information is related to [https://bugzilla.zimbra.com/show_bug.cgi?id=97743 Bug 97743].<br />
<br />
== Overview ==<br />
If you are experiencing significant admin console performance issues when using delegated admin, upgrade to version 8.6 Patch 2 or version 8.7<br />
If you still encounter performance issues, adjust these configuration settings:<br />
<br />
=== Zimbra 8.7 and later ===<br />
<br />
Adjust these settings in LDAP<br />
<br />
* zimbraShortTermAllEffectiveRightsCacheExpiration (default: 50s)<br />
* zimbraShortTermAllEffectiveRightsCacheSize (default: 128)<br />
* zimbraShortTermGranteeCacheExpiration (default: 50s)<br />
* zimbraShortTermGranteeCacheSize (default: 128)<br />
<br />
=== Zimbra 8.6 patch 2 and later patch levels ===<br />
<br />
* short_term_all_effective_rights_cache_expiration (default: 50000)<br />
* short_term_all_effective_rights_cache_size (default: 128)<br />
* short_term_grantee_cache_expiration (default: 50000)<br />
* short_term_grantee_cache_size (default: 128)<br />
<br />
'''Note''': The default sizes are 128, with default expirations in milliseconds. Using higher values is not recommended.<br />
<br />
== LDAP key descriptions ==<br />
<br />
=== zimbraShortTermAllEffectiveRightsCacheSize ===<br />
<br />
Maximum number of entries in the short term All Effective Rights cache.<br />
<br />
This cache can improve performance by avoiding recomputing All Effective Rights of named entries like accounts frequently in a short period of time.<br />
<br />
Can disable the cache be specifying a value of 0<br />
<br />
The default value is '''128'''<br />
<br />
=== zimbraShortTermAllEffectiveRightsCacheExpiration ===<br />
<br />
Maximum time an entry in the short term All Effective Rights cache will be regarded as valid.<br />
<br />
If value is 0, the cache is disabled.<br />
<br />
The cache is particularly useful when significant use is made of delegated administration.<br />
<br />
All Effective Rights are computations of the rights that named entries like accounts have - although when used, they are checked separately.<br />
<br />
The longer the value of this setting is, the more stale the view of the details is likely to be. For this reason, the '''maximum''' accepted value is 30m.<br />
Larger values will be treated as being 30m<br />
<br />
The default value is '''50s'''<br />
<br />
=== zimbraShortTermGranteeCacheSize ===<br />
<br />
Maximum number of entries in the short term Grantee cache.<br />
<br />
This cache can improve performance by avoiding recomputing details frequently in a short period of time, for instance for each entry in search results.<br />
<br />
Can disable the cache be specifying a value of 0<br />
<br />
The default value is '''128'''<br />
<br />
=== zimbraShortTermGranteeCacheExpiration ===<br />
<br />
Maximum time an entry in the Grantee cache will be regarded as valid.<br />
<br />
If value is 0, the cache is disabled.<br />
<br />
The cache is particularly useful when significant use is made of delegated administration.<br />
<br />
Grantees objects provide a view of what rights a grantee has - although those are checked separately.<br />
<br />
The longer the value of this setting is, the more stale the view of the details is likely to be. For this reason, the '''maximum''' accepted value is 30m.<br />
Larger values will be treated as being 30m<br />
<br />
The default value is '''50s'''<br />
<br />
{{Article Footer|Zimbra Collaboration 9.0, 8.7 |05/05/2015}}</div>Gren Elliothttps://wiki.zimbra.com/index.php?title=Admin_Console_Performance_Issues_when_using_Delegated_Admin&diff=62198Admin Console Performance Issues when using Delegated Admin2016-06-20T16:20:36Z<p>Gren Elliot: /* Admin Console Performance Issues when using Delegated Admin */</p>
<hr />
<div>{{BC|Certified}}<br />
__FORCETOC__<br />
<div class="col-md-12 ibox-content"><br />
=Admin Console Performance Issues when using Delegated Admin=<br />
{{KB|{{ZC}}|{{ZCS 9.0}}|{{ZCS 8.7}}|}}<br />
{{WIP}}<br />
<br />
'''Note''': This information is related to [https://bugzilla.zimbra.com/show_bug.cgi?id=97743 Bug 97743].<br />
<br />
== Overview ==<br />
If you are experiencing significant admin console performance issues when using delegated admin, upgrade to version 8.6 Patch 2 or version 8.7<br />
If you still encounter performance issues, adjust these configuration settings:<br />
<br />
=== Zimbra 8.7 and later ===<br />
<br />
* zimbraShortTermAllEffectiveRightsCacheExpiration (default: 50s)<br />
* zimbraShortTermAllEffectiveRightsCacheSize (default: 128)<br />
* zimbraShortTermGranteeCacheExpiration (default: 50s)<br />
* zimbraShortTermGranteeCacheSize (default: 128)<br />
<br />
=== Zimbra 8.6 patch 2 and later patch levels ===<br />
<br />
* short_term_all_effective_rights_cache_expiration (default: 50000)<br />
* short_term_all_effective_rights_cache_size (default: 128)<br />
* short_term_grantee_cache_expiration (default: 50000)<br />
* short_term_grantee_cache_size (default: 128)<br />
<br />
'''Note''': The default sizes are 128, with default expirations in milliseconds. Using higher values is not recommended.<br />
<br />
== LDAP key descriptions ==<br />
<br />
=== zimbraShortTermAllEffectiveRightsCacheSize ===<br />
<br />
Maximum number of entries in the short term All Effective Rights cache.<br />
<br />
This cache can improve performance by avoiding recomputing All Effective Rights of named entries like accounts frequently in a short period of time.<br />
<br />
Can disable the cache be specifying a value of 0<br />
<br />
The default value is '''128'''<br />
<br />
=== zimbraShortTermAllEffectiveRightsCacheExpiration ===<br />
<br />
Maximum time an entry in the short term All Effective Rights cache will be regarded as valid.<br />
<br />
If value is 0, the cache is disabled.<br />
<br />
The cache is particularly useful when significant use is made of delegated administration.<br />
<br />
All Effective Rights are computations of the rights that named entries like accounts have - although when used, they are checked separately.<br />
<br />
The longer the value of this setting is, the more stale the view of the details is likely to be. For this reason, the '''maximum''' accepted value is 30m.<br />
Larger values will be treated as being 30m<br />
<br />
The default value is '''50s'''<br />
<br />
=== zimbraShortTermGranteeCacheSize ===<br />
<br />
Maximum number of entries in the short term Grantee cache.<br />
<br />
This cache can improve performance by avoiding recomputing details frequently in a short period of time, for instance for each entry in search results.<br />
<br />
Can disable the cache be specifying a value of 0<br />
<br />
The default value is '''128'''<br />
<br />
=== zimbraShortTermGranteeCacheExpiration ===<br />
<br />
Maximum time an entry in the Grantee cache will be regarded as valid.<br />
<br />
If value is 0, the cache is disabled.<br />
<br />
The cache is particularly useful when significant use is made of delegated administration.<br />
<br />
Grantees objects provide a view of what rights a grantee has - although those are checked separately.<br />
<br />
The longer the value of this setting is, the more stale the view of the details is likely to be. For this reason, the '''maximum''' accepted value is 30m.<br />
Larger values will be treated as being 30m<br />
<br />
The default value is '''50s'''<br />
<br />
{{Article Footer|Zimbra Collaboration 9.0, 8.7 |05/05/2015}}</div>Gren Elliothttps://wiki.zimbra.com/index.php?title=Multiple_SSL_Certificates,_Server_Name_Indication_(SNI)_for_HTTPS&diff=61762Multiple SSL Certificates, Server Name Indication (SNI) for HTTPS2016-05-04T10:24:50Z<p>Gren Elliot: /* Troubleshooting */</p>
<hr />
<div>{{BC|Certified}}<br />
__FORCETOC__<br />
<div class="col-md-12 ibox-content"><br />
=Multiple SSL Certificates, Server Name Indication (SNI) for HTTPS=<br />
{{KB|{{ZC}}|{{ZCS 8.7}}||}}<br />
{{WIP}}<br />
<div class="alert alert-dark fade in"> <p><strong>Note: This feature will not enable SSL Certificate for IMAP/POP or smtps connections. [https://bugzilla.zimbra.com/show_bug.cgi?id=103362 RFE #103362]</strong> </p></div> <br />
<br />
[https://en.wikipedia.org/wiki/Server_Name_Indication '''Server Name Indication (SNI)'''] is an extension to the TLS computer networking protocol by which a client indicates which hostname it is attempting to connect to at the start of the handshaking process. This allows a server to present multiple certificates on the same IP address and TCP port number and hence allows multiple secure (HTTPS) websites (or any other Service over TLS) to be served off the same IP address without requiring all those sites to use the same certificate. It is the conceptual equivalent to HTTP/1.1 name-based virtual hosting, but for HTTPS. The desired hostname is not encrypted, so an eavesdropper can see which site is being requested.<br />
<br />
To make SNI useful, as with any protocol, the vast majority of visitors must use web browsers that implement it. Users whose browsers do not implement SNI are presented with a default certificate and hence are likely to receive certificate warnings. [https://en.wikipedia.org/wiki/Server_Name_Indication Source:Wikipedia]<br />
<br />
==Getting Started==<br />
Zimbra Collaboration supports SSL SNI starting at the 8.7 Release. The support requires and uses features of the Proxy service (which is actually required by Zimbra Collaboration 8.7 anyway)<br />
[[File:Zimbra-ssl-sni-001.png]]<br />
<br />
==Prerequisites==<br />
* Zimbra proxy service must be installed and enabled on the server. In a multi server environment, these steps should be performed on the proxy node<br />
* You should have a signed certificate + matching key pair and the trusted chain certs from your CA (Certificate Authority) (This is a common issue, so please, make sure you check your files before deploying them)<br />
* You can bind Multiple SSL Certificates to just one ipv4 address, which will pair to the respective domain names. For example:<br />
1.1.1.1 => example.com<br />
1.1.1.1=> otherdomain.com<br />
and you could even have another IPv4 address, for Customer reasons with other group of SSL Certificates, even different type of SSL Certificates:<br />
3.3.3.3 => yetanotherdomain.com (A Comodo Wildcard SSL Certificate)<br />
3.3.3.3 => thisisanotherdomain.com (A free Let's Encrypt SSL Certificate)<br />
3.3.3.3 => customer001.net (A RapidSSL Certificate)<br />
etc.<br />
<br />
===Browser support for SNI===<br />
The following browsers do offer support for SNI, however Zimbra hasn't tested all of them, it is the responsibility of the web-browser, to support the application part of SNI :<br />
{|class="wikitable sortable"<br />
! Software !! Type !! Supported !! Notes !! Supported since<br />
|-<br />
| Internet Explorer || Web browser || <i class="fa fa-check-circle"></i> || Since version 7 on Vista (not supported on XP) || 2006<br />
|-<br />
| Mozilla Firefox || Web browser || <i class="fa fa-check-circle"></i> || Since version 2.0 [https://bugzilla.mozilla.org/show_bug.cgi?id=116169#c26 Reference 116169] || 2006<br />
|-<br />
| curl || Command-line tool and library || <i class="fa fa-check-circle"></i> || Since version 7.18.1 || 2008<br />
|-<br />
| Safari || Web browser || <i class="fa fa-check-circle"></i> || Not supported on XP ||<br />
|-<br />
| Google Chrome || Web browser || <i class="fa fa-check-circle"></i> || Since 6.0 || 2010<br />
|-<br />
| BlackBerry OS || Web browser || <i class="fa fa-check-circle"></i> || 7.2 or later ||<br />
|-<br />
| Windows Mobile || Web browser ||<i class="fa fa-check-circle"></i> || Some time after 6.5<ref>{{cite web|url=http://blogs.msdn.com/b/ieinternals/archive/2009/12/07/certificate-name-mismatch-warnings-and-server-name-indication.aspx |title=Understanding Certificate Name Mismatches |publisher=Blogs.msdn.com |date= |accessdate=2011-03-08}}</ref> ||<br />
|-<br />
| Android default browser || Web browser || <i class="fa fa-check-circle"></i> || Honeycomb (3.x) for tablets and Ice Cream Sandwich (4.x) for phones<ref>{{cite web|url=https://code.google.com/p/android/issues/detail?id=12908 |title=Android issue 1290 - Https websites that support Server Name Indication (SNI) don't work |publisher=Code.google.com |date=2010-12-01 |accessdate=2011-12-13}}</ref> || 2011<br />
|-<br />
| wget || Command-line tool || <i class="fa fa-check-circle"></i> || Since version 1.14 || 2012<br />
|-<br />
| Nokia Browser for Symbian || Web browser || <i class="fa fa-times"></i> || ||<br />
|-<br />
| Opera Mobile || Web browser || <i class="fa fa-times"></i> || Not supported on Series60 ||<br />
|-<br />
|}<br />
<br />
==Configuring the IP address per domain==<br />
* 1. Add the new domain, in this case '''example.com'''. Set '''zimbraVirtualHostName''' to '''mail.example.com''' and '''zimbraVirtualIPAddress''' to '''1.2.3.4'''. Make sure the zimbraVirtualHostName is set to the name which will be used to access the domain (URL) and the SSL certificate is signed for the same name.<br />
zmprov md example.com zimbraVirtualHostName mail.example.com zimbraVirtualIPAddress 1.2.3.4<br />
<br />
'''NOTE: If the server is behind a firewall and NAT'ed with an external address, make sure external requests for "mail.example.com" hit the aliased IP address and not the actual local IP address of server.'''<br />
<br />
==Verifying and Preparing the Certificates==<br />
We should have three files received from the CA (might vary depending on the Certificate Authority). The server (domain) certificate, and two chain certs. Also, you should have an existing key file (which was used to generate the csr)<br />
* 1. Save the '''example.com certificate''', '''key''' and '''chain files''' to a directory '''/tmp/example.com.''' You can receive single or multiple chain certs from your CA. Here we have two chain certs from the CA. i.e. example.com.root.crt and example.com.intermediate.crt.<br />
ls /tmp/example.com<br />
example.com.key<br />
example.com.crt<br />
example.com.root.crt<br />
example.com.intermediate.crt<br />
<br />
* 2. Add the chain certs to a single file called example.com_ca.crt<br />
cat example.com.root.crt example.com.intermediate.crt >> example.com_ca.crt<br />
<br />
* 3. Confirm if the key and certificate matches and chain certs completes the trust. As zimbra user:<br />
/opt/zimbra/bin/zmcertmgr verifycrt comm /tmp/example.com/example.com.key /tmp/example.com/example.com.crt /tmp/example.com/example.com_ca.crt<br />
<br />
<br />
** Check the output, it should say something like this. If not, make sure you have the correct key and chain cert files.<br />
** Verifying '/tmp/example.com.crt' against '/tmp/example.com.key'<br />
Certificate '/tmp/example.com.crt' and private key '/tmp/example.com.key' match.<br />
** Verifying '/tmp/example.com.crt' against '/tmp/example.com_ca.crt'<br />
Valid certificate chain: /tmp/example.com.crt: OK<br />
<br />
==Deploying the Certificate or Certificates on the domain==<br />
* 1. Add the domain certificate and chain files to a single file called '''example.com.bundle'''<br />
cat example.com.crt example.com_ca.crt >> example.com.bundle<br />
<br />
* 2. Run the following command as the '''zimbra''' user to save the certificates and key in LDAP:<br />
/opt/zimbra/libexec/zmdomaincertmgr savecrt example.com example.com.bundle example.com.key<br />
** Saving domain config key zimbraSSLCertificate...done.<br />
** Saving domain config key zimbraSSLPrivateKey...done.<br />
** The syntax is:<br />
/opt/zimbra/libexec/zmdomaincertmgr savecrt <domainname> <certificate with chain certs> <keyfile><br />
<br />
* 3. Run the following command as the '''zimbra''' user to deploy the domain certificate. This will save the certificate and key as '''/opt/zimbra/conf/domaincerts/example.com''':<br />
/opt/zimbra/libexec/zmdomaincertmgr deploycrts<br />
** Deploying cert for example.com...done.<br />
<br />
== Proxy Check ==<br />
Run these commands on proxy hosts, or on the server if it's Single Server: <br />
* zimbraReverseProxySNIEnabled should be set to TRUE in server and global config. <br />
zmprov mcf zimbraReverseProxySNIEnabled TRUE<br />
<br />
== Re-write and restart Proxy ==<br />
* Restart the proxy to re-write the changes to proxy config<br />
zmproxyctl restart<br />
<br />
* Once the restart is successfull, try to access the domain using the URL which is set in "zimbraVirtualHostName" over https. And check the certificate loaded in the browser. In this case the URL will be https://example.com<br />
<br />
=Testing=<br />
You can go now to a Web browser and check that for each different '''zimbraVirtualHostName''', you see a different SSL certificate and that its details are correct for that virtualhostname.<br />
<br />
=Troubleshooting=<br />
* If you do not see the correct domain cert by accessing the domain with its zimbraVirtualHostName (example.com). Make sure that the https connection from the Internet/intranet is going to the server's local IP address which is defined in '''zimbraVirtualIPAddress''', and make sure you have activated '''zimbraReverseProxySNIEnabled''' to '''TRUE'''<br />
<br />
* If you are using multiple proxy servers or adding new proxy servers, make sure you copy all the contents of '''/opt/zimbra/conf/domaincerts/''' to all the proxy servers. '''Otherwise the proxy service will fail to start.'''<br />
<br />
=Known Issues=<br />
* [https://bugzilla.zimbra.com/show_bug.cgi?id=102913 Bug 102913 - '''Multiple SSL domains on single server (SNI) for HTTPS connections''']<br />
* [https://bugzilla.zimbra.com/show_bug.cgi?id=103362 Bug 103362 - '''Multiple SSL domains on single server (SNI) for IMAPS/POP3S connections''']<br />
<br />
{{Article Footer|Zimbra Collaboration Suite 8.7|03/05/2016}}<br />
{{NeedSME|Jorge|SME2|Copyeditor}}<br />
<br />
[[Category:Certified]]<br />
[[Category:Certificates]]<br />
[[Category:ZCS 8.7]]</div>Gren Elliothttps://wiki.zimbra.com/index.php?title=Multiple_SSL_Certificates,_Server_Name_Indication_(SNI)_for_HTTPS&diff=61761Multiple SSL Certificates, Server Name Indication (SNI) for HTTPS2016-05-04T10:22:23Z<p>Gren Elliot: /* Testing */</p>
<hr />
<div>{{BC|Certified}}<br />
__FORCETOC__<br />
<div class="col-md-12 ibox-content"><br />
=Multiple SSL Certificates, Server Name Indication (SNI) for HTTPS=<br />
{{KB|{{ZC}}|{{ZCS 8.7}}||}}<br />
{{WIP}}<br />
<div class="alert alert-dark fade in"> <p><strong>Note: This feature will not enable SSL Certificate for IMAP/POP or smtps connections. [https://bugzilla.zimbra.com/show_bug.cgi?id=103362 RFE #103362]</strong> </p></div> <br />
<br />
[https://en.wikipedia.org/wiki/Server_Name_Indication '''Server Name Indication (SNI)'''] is an extension to the TLS computer networking protocol by which a client indicates which hostname it is attempting to connect to at the start of the handshaking process. This allows a server to present multiple certificates on the same IP address and TCP port number and hence allows multiple secure (HTTPS) websites (or any other Service over TLS) to be served off the same IP address without requiring all those sites to use the same certificate. It is the conceptual equivalent to HTTP/1.1 name-based virtual hosting, but for HTTPS. The desired hostname is not encrypted, so an eavesdropper can see which site is being requested.<br />
<br />
To make SNI useful, as with any protocol, the vast majority of visitors must use web browsers that implement it. Users whose browsers do not implement SNI are presented with a default certificate and hence are likely to receive certificate warnings. [https://en.wikipedia.org/wiki/Server_Name_Indication Source:Wikipedia]<br />
<br />
==Getting Started==<br />
Zimbra Collaboration supports SSL SNI starting at the 8.7 Release. The support requires and uses features of the Proxy service (which is actually required by Zimbra Collaboration 8.7 anyway)<br />
[[File:Zimbra-ssl-sni-001.png]]<br />
<br />
==Prerequisites==<br />
* Zimbra proxy service must be installed and enabled on the server. In a multi server environment, these steps should be performed on the proxy node<br />
* You should have a signed certificate + matching key pair and the trusted chain certs from your CA (Certificate Authority) (This is a common issue, so please, make sure you check your files before deploying them)<br />
* You can bind Multiple SSL Certificates to just one ipv4 address, which will pair to the respective domain names. For example:<br />
1.1.1.1 => example.com<br />
1.1.1.1=> otherdomain.com<br />
and you could even have another IPv4 address, for Customer reasons with other group of SSL Certificates, even different type of SSL Certificates:<br />
3.3.3.3 => yetanotherdomain.com (A Comodo Wildcard SSL Certificate)<br />
3.3.3.3 => thisisanotherdomain.com (A free Let's Encrypt SSL Certificate)<br />
3.3.3.3 => customer001.net (A RapidSSL Certificate)<br />
etc.<br />
<br />
===Browser support for SNI===<br />
The following browsers do offer support for SNI, however Zimbra hasn't tested all of them, it is the responsibility of the web-browser, to support the application part of SNI :<br />
{|class="wikitable sortable"<br />
! Software !! Type !! Supported !! Notes !! Supported since<br />
|-<br />
| Internet Explorer || Web browser || <i class="fa fa-check-circle"></i> || Since version 7 on Vista (not supported on XP) || 2006<br />
|-<br />
| Mozilla Firefox || Web browser || <i class="fa fa-check-circle"></i> || Since version 2.0 [https://bugzilla.mozilla.org/show_bug.cgi?id=116169#c26 Reference 116169] || 2006<br />
|-<br />
| curl || Command-line tool and library || <i class="fa fa-check-circle"></i> || Since version 7.18.1 || 2008<br />
|-<br />
| Safari || Web browser || <i class="fa fa-check-circle"></i> || Not supported on XP ||<br />
|-<br />
| Google Chrome || Web browser || <i class="fa fa-check-circle"></i> || Since 6.0 || 2010<br />
|-<br />
| BlackBerry OS || Web browser || <i class="fa fa-check-circle"></i> || 7.2 or later ||<br />
|-<br />
| Windows Mobile || Web browser ||<i class="fa fa-check-circle"></i> || Some time after 6.5<ref>{{cite web|url=http://blogs.msdn.com/b/ieinternals/archive/2009/12/07/certificate-name-mismatch-warnings-and-server-name-indication.aspx |title=Understanding Certificate Name Mismatches |publisher=Blogs.msdn.com |date= |accessdate=2011-03-08}}</ref> ||<br />
|-<br />
| Android default browser || Web browser || <i class="fa fa-check-circle"></i> || Honeycomb (3.x) for tablets and Ice Cream Sandwich (4.x) for phones<ref>{{cite web|url=https://code.google.com/p/android/issues/detail?id=12908 |title=Android issue 1290 - Https websites that support Server Name Indication (SNI) don't work |publisher=Code.google.com |date=2010-12-01 |accessdate=2011-12-13}}</ref> || 2011<br />
|-<br />
| wget || Command-line tool || <i class="fa fa-check-circle"></i> || Since version 1.14 || 2012<br />
|-<br />
| Nokia Browser for Symbian || Web browser || <i class="fa fa-times"></i> || ||<br />
|-<br />
| Opera Mobile || Web browser || <i class="fa fa-times"></i> || Not supported on Series60 ||<br />
|-<br />
|}<br />
<br />
==Configuring the IP address per domain==<br />
* 1. Add the new domain, in this case '''example.com'''. Set '''zimbraVirtualHostName''' to '''mail.example.com''' and '''zimbraVirtualIPAddress''' to '''1.2.3.4'''. Make sure the zimbraVirtualHostName is set to the name which will be used to access the domain (URL) and the SSL certificate is signed for the same name.<br />
zmprov md example.com zimbraVirtualHostName mail.example.com zimbraVirtualIPAddress 1.2.3.4<br />
<br />
'''NOTE: If the server is behind a firewall and NAT'ed with an external address, make sure external requests for "mail.example.com" hit the aliased IP address and not the actual local IP address of server.'''<br />
<br />
==Verifying and Preparing the Certificates==<br />
We should have three files received from the CA (might vary depending on the Certificate Authority). The server (domain) certificate, and two chain certs. Also, you should have an existing key file (which was used to generate the csr)<br />
* 1. Save the '''example.com certificate''', '''key''' and '''chain files''' to a directory '''/tmp/example.com.''' You can receive single or multiple chain certs from your CA. Here we have two chain certs from the CA. i.e. example.com.root.crt and example.com.intermediate.crt.<br />
ls /tmp/example.com<br />
example.com.key<br />
example.com.crt<br />
example.com.root.crt<br />
example.com.intermediate.crt<br />
<br />
* 2. Add the chain certs to a single file called example.com_ca.crt<br />
cat example.com.root.crt example.com.intermediate.crt >> example.com_ca.crt<br />
<br />
* 3. Confirm if the key and certificate matches and chain certs completes the trust. As zimbra user:<br />
/opt/zimbra/bin/zmcertmgr verifycrt comm /tmp/example.com/example.com.key /tmp/example.com/example.com.crt /tmp/example.com/example.com_ca.crt<br />
<br />
<br />
** Check the output, it should say something like this. If not, make sure you have the correct key and chain cert files.<br />
** Verifying '/tmp/example.com.crt' against '/tmp/example.com.key'<br />
Certificate '/tmp/example.com.crt' and private key '/tmp/example.com.key' match.<br />
** Verifying '/tmp/example.com.crt' against '/tmp/example.com_ca.crt'<br />
Valid certificate chain: /tmp/example.com.crt: OK<br />
<br />
==Deploying the Certificate or Certificates on the domain==<br />
* 1. Add the domain certificate and chain files to a single file called '''example.com.bundle'''<br />
cat example.com.crt example.com_ca.crt >> example.com.bundle<br />
<br />
* 2. Run the following command as the '''zimbra''' user to save the certificates and key in LDAP:<br />
/opt/zimbra/libexec/zmdomaincertmgr savecrt example.com example.com.bundle example.com.key<br />
** Saving domain config key zimbraSSLCertificate...done.<br />
** Saving domain config key zimbraSSLPrivateKey...done.<br />
** The syntax is:<br />
/opt/zimbra/libexec/zmdomaincertmgr savecrt <domainname> <certificate with chain certs> <keyfile><br />
<br />
* 3. Run the following command as the '''zimbra''' user to deploy the domain certificate. This will save the certificate and key as '''/opt/zimbra/conf/domaincerts/example.com''':<br />
/opt/zimbra/libexec/zmdomaincertmgr deploycrts<br />
** Deploying cert for example.com...done.<br />
<br />
== Proxy Check ==<br />
Run these commands on proxy hosts, or on the server if it's Single Server: <br />
* zimbraReverseProxySNIEnabled should be set to TRUE in server and global config. <br />
zmprov mcf zimbraReverseProxySNIEnabled TRUE<br />
<br />
== Re-write and restart Proxy ==<br />
* Restart the proxy to re-write the changes to proxy config<br />
zmproxyctl restart<br />
<br />
* Once the restart is successfull, try to access the domain using the URL which is set in "zimbraVirtualHostName" over https. And check the certificate loaded in the browser. In this case the URL will be https://example.com<br />
<br />
=Testing=<br />
You can go now to a Web browser and check that for each different '''zimbraVirtualHostName''', you see a different SSL certificate and that its details are correct for that virtualhostname.<br />
<br />
=Troubleshooting=<br />
* If you do not see domain cert by accessing the domain with its zimbraVirtualHostName (example.com). Make sure the https connection from Internet/intranet is going to server's local IP address which is defined in zimbraVirtualIPAddress, and make sure you have activated zimbraReverseProxySNIEnabled to TRUE<br />
<br />
* If you are using multiple proxy servers or adding new proxy servers, make sure you copy all the contents of /opt/zimbra/conf/domaincerts/ among all proxy servers. '''Otherwise proxy service will fail to start.'''<br />
<br />
<br />
=Known Issues=<br />
* [https://bugzilla.zimbra.com/show_bug.cgi?id=102913 Bug 102913 - '''Multiple SSL domains on single server (SNI) for HTTPS connections''']<br />
* [https://bugzilla.zimbra.com/show_bug.cgi?id=103362 Bug 103362 - '''Multiple SSL domains on single server (SNI) for IMAPS/POP3S connections''']<br />
<br />
{{Article Footer|Zimbra Collaboration Suite 8.7|03/05/2016}}<br />
{{NeedSME|Jorge|SME2|Copyeditor}}<br />
<br />
[[Category:Certified]]<br />
[[Category:Certificates]]<br />
[[Category:ZCS 8.7]]</div>Gren Elliothttps://wiki.zimbra.com/index.php?title=Multiple_SSL_Certificates,_Server_Name_Indication_(SNI)_for_HTTPS&diff=61760Multiple SSL Certificates, Server Name Indication (SNI) for HTTPS2016-05-04T10:06:12Z<p>Gren Elliot: /* Deploying the Certificate or Certificates on domain */</p>
<hr />
<div>{{BC|Certified}}<br />
__FORCETOC__<br />
<div class="col-md-12 ibox-content"><br />
=Multiple SSL Certificates, Server Name Indication (SNI) for HTTPS=<br />
{{KB|{{ZC}}|{{ZCS 8.7}}||}}<br />
{{WIP}}<br />
<div class="alert alert-dark fade in"> <p><strong>Note: This feature will not enable SSL Certificate for IMAP/POP or smtps connections. [https://bugzilla.zimbra.com/show_bug.cgi?id=103362 RFE #103362]</strong> </p></div> <br />
<br />
[https://en.wikipedia.org/wiki/Server_Name_Indication '''Server Name Indication (SNI)'''] is an extension to the TLS computer networking protocol by which a client indicates which hostname it is attempting to connect to at the start of the handshaking process. This allows a server to present multiple certificates on the same IP address and TCP port number and hence allows multiple secure (HTTPS) websites (or any other Service over TLS) to be served off the same IP address without requiring all those sites to use the same certificate. It is the conceptual equivalent to HTTP/1.1 name-based virtual hosting, but for HTTPS. The desired hostname is not encrypted, so an eavesdropper can see which site is being requested.<br />
<br />
To make SNI useful, as with any protocol, the vast majority of visitors must use web browsers that implement it. Users whose browsers do not implement SNI are presented with a default certificate and hence are likely to receive certificate warnings. [https://en.wikipedia.org/wiki/Server_Name_Indication Source:Wikipedia]<br />
<br />
==Getting Started==<br />
Zimbra Collaboration supports SSL SNI starting at the 8.7 Release. The support requires and uses features of the Proxy service (which is actually required by Zimbra Collaboration 8.7 anyway)<br />
[[File:Zimbra-ssl-sni-001.png]]<br />
<br />
==Prerequisites==<br />
* Zimbra proxy service must be installed and enabled on the server. In a multi server environment, these steps should be performed on the proxy node<br />
* You should have a signed certificate + matching key pair and the trusted chain certs from your CA (Certificate Authority) (This is a common issue, so please, make sure you check your files before deploying them)<br />
* You can bind Multiple SSL Certificates to just one ipv4 address, which will pair to the respective domain names. For example:<br />
1.1.1.1 => example.com<br />
1.1.1.1=> otherdomain.com<br />
and you could even have another IPv4 address, for Customer reasons with other group of SSL Certificates, even different type of SSL Certificates:<br />
3.3.3.3 => yetanotherdomain.com (A Comodo Wildcard SSL Certificate)<br />
3.3.3.3 => thisisanotherdomain.com (A free Let's Encrypt SSL Certificate)<br />
3.3.3.3 => customer001.net (A RapidSSL Certificate)<br />
etc.<br />
<br />
===Browser support for SNI===<br />
The following browsers do offer support for SNI, however Zimbra hasn't tested all of them, it is the responsibility of the web-browser, to support the application part of SNI :<br />
{|class="wikitable sortable"<br />
! Software !! Type !! Supported !! Notes !! Supported since<br />
|-<br />
| Internet Explorer || Web browser || <i class="fa fa-check-circle"></i> || Since version 7 on Vista (not supported on XP) || 2006<br />
|-<br />
| Mozilla Firefox || Web browser || <i class="fa fa-check-circle"></i> || Since version 2.0 [https://bugzilla.mozilla.org/show_bug.cgi?id=116169#c26 Reference 116169] || 2006<br />
|-<br />
| curl || Command-line tool and library || <i class="fa fa-check-circle"></i> || Since version 7.18.1 || 2008<br />
|-<br />
| Safari || Web browser || <i class="fa fa-check-circle"></i> || Not supported on XP ||<br />
|-<br />
| Google Chrome || Web browser || <i class="fa fa-check-circle"></i> || Since 6.0 || 2010<br />
|-<br />
| BlackBerry OS || Web browser || <i class="fa fa-check-circle"></i> || 7.2 or later ||<br />
|-<br />
| Windows Mobile || Web browser ||<i class="fa fa-check-circle"></i> || Some time after 6.5<ref>{{cite web|url=http://blogs.msdn.com/b/ieinternals/archive/2009/12/07/certificate-name-mismatch-warnings-and-server-name-indication.aspx |title=Understanding Certificate Name Mismatches |publisher=Blogs.msdn.com |date= |accessdate=2011-03-08}}</ref> ||<br />
|-<br />
| Android default browser || Web browser || <i class="fa fa-check-circle"></i> || Honeycomb (3.x) for tablets and Ice Cream Sandwich (4.x) for phones<ref>{{cite web|url=https://code.google.com/p/android/issues/detail?id=12908 |title=Android issue 1290 - Https websites that support Server Name Indication (SNI) don't work |publisher=Code.google.com |date=2010-12-01 |accessdate=2011-12-13}}</ref> || 2011<br />
|-<br />
| wget || Command-line tool || <i class="fa fa-check-circle"></i> || Since version 1.14 || 2012<br />
|-<br />
| Nokia Browser for Symbian || Web browser || <i class="fa fa-times"></i> || ||<br />
|-<br />
| Opera Mobile || Web browser || <i class="fa fa-times"></i> || Not supported on Series60 ||<br />
|-<br />
|}<br />
<br />
==Configuring the IP address per domain==<br />
* 1. Add the new domain, in this case '''example.com'''. Set '''zimbraVirtualHostName''' to '''mail.example.com''' and '''zimbraVirtualIPAddress''' to '''1.2.3.4'''. Make sure the zimbraVirtualHostName is set to the name which will be used to access the domain (URL) and the SSL certificate is signed for the same name.<br />
zmprov md example.com zimbraVirtualHostName mail.example.com zimbraVirtualIPAddress 1.2.3.4<br />
<br />
'''NOTE: If the server is behind a firewall and NAT'ed with an external address, make sure external requests for "mail.example.com" hit the aliased IP address and not the actual local IP address of server.'''<br />
<br />
==Verifying and Preparing the Certificates==<br />
We should have three files received from the CA (might vary depending on the Certificate Authority). The server (domain) certificate, and two chain certs. Also, you should have an existing key file (which was used to generate the csr)<br />
* 1. Save the '''example.com certificate''', '''key''' and '''chain files''' to a directory '''/tmp/example.com.''' You can receive single or multiple chain certs from your CA. Here we have two chain certs from the CA. i.e. example.com.root.crt and example.com.intermediate.crt.<br />
ls /tmp/example.com<br />
example.com.key<br />
example.com.crt<br />
example.com.root.crt<br />
example.com.intermediate.crt<br />
<br />
* 2. Add the chain certs to a single file called example.com_ca.crt<br />
cat example.com.root.crt example.com.intermediate.crt >> example.com_ca.crt<br />
<br />
* 3. Confirm if the key and certificate matches and chain certs completes the trust. As zimbra user:<br />
/opt/zimbra/bin/zmcertmgr verifycrt comm /tmp/example.com/example.com.key /tmp/example.com/example.com.crt /tmp/example.com/example.com_ca.crt<br />
<br />
<br />
** Check the output, it should say something like this. If not, make sure you have the correct key and chain cert files.<br />
** Verifying '/tmp/example.com.crt' against '/tmp/example.com.key'<br />
Certificate '/tmp/example.com.crt' and private key '/tmp/example.com.key' match.<br />
** Verifying '/tmp/example.com.crt' against '/tmp/example.com_ca.crt'<br />
Valid certificate chain: /tmp/example.com.crt: OK<br />
<br />
==Deploying the Certificate or Certificates on the domain==<br />
* 1. Add the domain certificate and chain files to a single file called '''example.com.bundle'''<br />
cat example.com.crt example.com_ca.crt >> example.com.bundle<br />
<br />
* 2. Run the following command as the '''zimbra''' user to save the certificates and key in LDAP:<br />
/opt/zimbra/libexec/zmdomaincertmgr savecrt example.com example.com.bundle example.com.key<br />
** Saving domain config key zimbraSSLCertificate...done.<br />
** Saving domain config key zimbraSSLPrivateKey...done.<br />
** The syntax is:<br />
/opt/zimbra/libexec/zmdomaincertmgr savecrt <domainname> <certificate with chain certs> <keyfile><br />
<br />
* 3. Run the following command as the '''zimbra''' user to deploy the domain certificate. This will save the certificate and key as '''/opt/zimbra/conf/domaincerts/example.com''':<br />
/opt/zimbra/libexec/zmdomaincertmgr deploycrts<br />
** Deploying cert for example.com...done.<br />
<br />
== Proxy Check ==<br />
Run these commands on proxy hosts, or on the server if it's Single Server: <br />
* zimbraReverseProxySNIEnabled should be set to TRUE in server and global config. <br />
zmprov mcf zimbraReverseProxySNIEnabled TRUE<br />
<br />
== Re-write and restart Proxy ==<br />
* Restart the proxy to re-write the changes to proxy config<br />
zmproxyctl restart<br />
<br />
* Once the restart is successfull, try to access the domain using the URL which is set in "zimbraVirtualHostName" over https. And check the certificate loaded in the browser. In this case the URL will be https://example.com<br />
<br />
=Testing=<br />
You can go now to a Web browser and check the different zimbraVirtualHostName, and you will see that they will present to you different SSL certificates, the corresponding one per each virtualhostname.<br />
<br />
=Troubleshooting=<br />
* If you do not see domain cert by accessing the domain with its zimbraVirtualHostName (example.com). Make sure the https connection from Internet/intranet is going to server's local IP address which is defined in zimbraVirtualIPAddress, and make sure you have activated zimbraReverseProxySNIEnabled to TRUE<br />
<br />
* If you are using multiple proxy servers or adding new proxy servers, make sure you copy all the contents of /opt/zimbra/conf/domaincerts/ among all proxy servers. '''Otherwise proxy service will fail to start.'''<br />
<br />
<br />
=Known Issues=<br />
* [https://bugzilla.zimbra.com/show_bug.cgi?id=102913 Bug 102913 - '''Multiple SSL domains on single server (SNI) for HTTPS connections''']<br />
* [https://bugzilla.zimbra.com/show_bug.cgi?id=103362 Bug 103362 - '''Multiple SSL domains on single server (SNI) for IMAPS/POP3S connections''']<br />
<br />
{{Article Footer|Zimbra Collaboration Suite 8.7|03/05/2016}}<br />
{{NeedSME|Jorge|SME2|Copyeditor}}<br />
<br />
[[Category:Certified]]<br />
[[Category:Certificates]]<br />
[[Category:ZCS 8.7]]</div>Gren Elliothttps://wiki.zimbra.com/index.php?title=Multiple_SSL_Certificates,_Server_Name_Indication_(SNI)_for_HTTPS&diff=61759Multiple SSL Certificates, Server Name Indication (SNI) for HTTPS2016-05-04T10:02:19Z<p>Gren Elliot: /* Verifying and Preparing the Certificates */</p>
<hr />
<div>{{BC|Certified}}<br />
__FORCETOC__<br />
<div class="col-md-12 ibox-content"><br />
=Multiple SSL Certificates, Server Name Indication (SNI) for HTTPS=<br />
{{KB|{{ZC}}|{{ZCS 8.7}}||}}<br />
{{WIP}}<br />
<div class="alert alert-dark fade in"> <p><strong>Note: This feature will not enable SSL Certificate for IMAP/POP or smtps connections. [https://bugzilla.zimbra.com/show_bug.cgi?id=103362 RFE #103362]</strong> </p></div> <br />
<br />
[https://en.wikipedia.org/wiki/Server_Name_Indication '''Server Name Indication (SNI)'''] is an extension to the TLS computer networking protocol by which a client indicates which hostname it is attempting to connect to at the start of the handshaking process. This allows a server to present multiple certificates on the same IP address and TCP port number and hence allows multiple secure (HTTPS) websites (or any other Service over TLS) to be served off the same IP address without requiring all those sites to use the same certificate. It is the conceptual equivalent to HTTP/1.1 name-based virtual hosting, but for HTTPS. The desired hostname is not encrypted, so an eavesdropper can see which site is being requested.<br />
<br />
To make SNI useful, as with any protocol, the vast majority of visitors must use web browsers that implement it. Users whose browsers do not implement SNI are presented with a default certificate and hence are likely to receive certificate warnings. [https://en.wikipedia.org/wiki/Server_Name_Indication Source:Wikipedia]<br />
<br />
==Getting Started==<br />
Zimbra Collaboration supports SSL SNI starting at the 8.7 Release. The support requires and uses features of the Proxy service (which is actually required by Zimbra Collaboration 8.7 anyway)<br />
[[File:Zimbra-ssl-sni-001.png]]<br />
<br />
==Prerequisites==<br />
* Zimbra proxy service must be installed and enabled on the server. In a multi server environment, these steps should be performed on the proxy node<br />
* You should have a signed certificate + matching key pair and the trusted chain certs from your CA (Certificate Authority) (This is a common issue, so please, make sure you check your files before deploying them)<br />
* You can bind Multiple SSL Certificates to just one ipv4 address, which will pair to the respective domain names. For example:<br />
1.1.1.1 => example.com<br />
1.1.1.1=> otherdomain.com<br />
and you could even have another IPv4 address, for Customer reasons with other group of SSL Certificates, even different type of SSL Certificates:<br />
3.3.3.3 => yetanotherdomain.com (A Comodo Wildcard SSL Certificate)<br />
3.3.3.3 => thisisanotherdomain.com (A free Let's Encrypt SSL Certificate)<br />
3.3.3.3 => customer001.net (A RapidSSL Certificate)<br />
etc.<br />
<br />
===Browser support for SNI===<br />
The following browsers do offer support for SNI, however Zimbra hasn't tested all of them, it is the responsibility of the web-browser, to support the application part of SNI :<br />
{|class="wikitable sortable"<br />
! Software !! Type !! Supported !! Notes !! Supported since<br />
|-<br />
| Internet Explorer || Web browser || <i class="fa fa-check-circle"></i> || Since version 7 on Vista (not supported on XP) || 2006<br />
|-<br />
| Mozilla Firefox || Web browser || <i class="fa fa-check-circle"></i> || Since version 2.0 [https://bugzilla.mozilla.org/show_bug.cgi?id=116169#c26 Reference 116169] || 2006<br />
|-<br />
| curl || Command-line tool and library || <i class="fa fa-check-circle"></i> || Since version 7.18.1 || 2008<br />
|-<br />
| Safari || Web browser || <i class="fa fa-check-circle"></i> || Not supported on XP ||<br />
|-<br />
| Google Chrome || Web browser || <i class="fa fa-check-circle"></i> || Since 6.0 || 2010<br />
|-<br />
| BlackBerry OS || Web browser || <i class="fa fa-check-circle"></i> || 7.2 or later ||<br />
|-<br />
| Windows Mobile || Web browser ||<i class="fa fa-check-circle"></i> || Some time after 6.5<ref>{{cite web|url=http://blogs.msdn.com/b/ieinternals/archive/2009/12/07/certificate-name-mismatch-warnings-and-server-name-indication.aspx |title=Understanding Certificate Name Mismatches |publisher=Blogs.msdn.com |date= |accessdate=2011-03-08}}</ref> ||<br />
|-<br />
| Android default browser || Web browser || <i class="fa fa-check-circle"></i> || Honeycomb (3.x) for tablets and Ice Cream Sandwich (4.x) for phones<ref>{{cite web|url=https://code.google.com/p/android/issues/detail?id=12908 |title=Android issue 1290 - Https websites that support Server Name Indication (SNI) don't work |publisher=Code.google.com |date=2010-12-01 |accessdate=2011-12-13}}</ref> || 2011<br />
|-<br />
| wget || Command-line tool || <i class="fa fa-check-circle"></i> || Since version 1.14 || 2012<br />
|-<br />
| Nokia Browser for Symbian || Web browser || <i class="fa fa-times"></i> || ||<br />
|-<br />
| Opera Mobile || Web browser || <i class="fa fa-times"></i> || Not supported on Series60 ||<br />
|-<br />
|}<br />
<br />
==Configuring the IP address per domain==<br />
* 1. Add the new domain, in this case '''example.com'''. Set '''zimbraVirtualHostName''' to '''mail.example.com''' and '''zimbraVirtualIPAddress''' to '''1.2.3.4'''. Make sure the zimbraVirtualHostName is set to the name which will be used to access the domain (URL) and the SSL certificate is signed for the same name.<br />
zmprov md example.com zimbraVirtualHostName mail.example.com zimbraVirtualIPAddress 1.2.3.4<br />
<br />
'''NOTE: If the server is behind a firewall and NAT'ed with an external address, make sure external requests for "mail.example.com" hit the aliased IP address and not the actual local IP address of server.'''<br />
<br />
==Verifying and Preparing the Certificates==<br />
We should have three files received from the CA (might vary depending on the Certificate Authority). The server (domain) certificate, and two chain certs. Also, you should have an existing key file (which was used to generate the csr)<br />
* 1. Save the '''example.com certificate''', '''key''' and '''chain files''' to a directory '''/tmp/example.com.''' You can receive single or multiple chain certs from your CA. Here we have two chain certs from the CA. i.e. example.com.root.crt and example.com.intermediate.crt.<br />
ls /tmp/example.com<br />
example.com.key<br />
example.com.crt<br />
example.com.root.crt<br />
example.com.intermediate.crt<br />
<br />
* 2. Add the chain certs to a single file called example.com_ca.crt<br />
cat example.com.root.crt example.com.intermediate.crt >> example.com_ca.crt<br />
<br />
* 3. Confirm if the key and certificate matches and chain certs completes the trust. As zimbra user:<br />
/opt/zimbra/bin/zmcertmgr verifycrt comm /tmp/example.com/example.com.key /tmp/example.com/example.com.crt /tmp/example.com/example.com_ca.crt<br />
<br />
<br />
** Check the output, it should say something like this. If not, make sure you have the correct key and chain cert files.<br />
** Verifying '/tmp/example.com.crt' against '/tmp/example.com.key'<br />
Certificate '/tmp/example.com.crt' and private key '/tmp/example.com.key' match.<br />
** Verifying '/tmp/example.com.crt' against '/tmp/example.com_ca.crt'<br />
Valid certificate chain: /tmp/example.com.crt: OK<br />
<br />
==Deploying the Certificate or Certificates on domain==<br />
* 1. Add the domain certificate and chain files to a single file called example.com.bundle<br />
cat example.com.crt example.com_ca.crt >> example.com.bundle<br />
<br />
* 2. Run following to save the certificates and key in ldap database, as zimbra user:<br />
/opt/zimbra/libexec/zmdomaincertmgr savecrt example.com example.com.bundle example.com.key<br />
** Saving domain config key zimbraSSLCertificate...done.<br />
** Saving domain config key zimbraSSLPrivateKey...done.<br />
** The syntax is:<br />
/opt/zimbra/libexec/zmdomaincertmgr savecrt <domainname> <certificate with chain certs> <keyfile><br />
<br />
* 3. Run following to deploy the domain certificate. This will save the certificate and key as /opt/zimbra/conf/domaincerts/example.com , as zimbra user:<br />
/opt/zimbra/libexec/zmdomaincertmgr deploycrts<br />
** Deploying cert for example.com...done.<br />
<br />
== Proxy Check ==<br />
Run these commands on proxy hosts, or on the server if it's Single Server: <br />
* zimbraReverseProxySNIEnabled should be set to TRUE in server and global config. <br />
zmprov mcf zimbraReverseProxySNIEnabled TRUE<br />
<br />
== Re-write and restart Proxy ==<br />
* Restart the proxy to re-write the changes to proxy config<br />
zmproxyctl restart<br />
<br />
* Once the restart is successfull, try to access the domain using the URL which is set in "zimbraVirtualHostName" over https. And check the certificate loaded in the browser. In this case the URL will be https://example.com<br />
<br />
=Testing=<br />
You can go now to a Web browser and check the different zimbraVirtualHostName, and you will see that they will present to you different SSL certificates, the corresponding one per each virtualhostname.<br />
<br />
=Troubleshooting=<br />
* If you do not see domain cert by accessing the domain with its zimbraVirtualHostName (example.com). Make sure the https connection from Internet/intranet is going to server's local IP address which is defined in zimbraVirtualIPAddress, and make sure you have activated zimbraReverseProxySNIEnabled to TRUE<br />
<br />
* If you are using multiple proxy servers or adding new proxy servers, make sure you copy all the contents of /opt/zimbra/conf/domaincerts/ among all proxy servers. '''Otherwise proxy service will fail to start.'''<br />
<br />
<br />
=Known Issues=<br />
* [https://bugzilla.zimbra.com/show_bug.cgi?id=102913 Bug 102913 - '''Multiple SSL domains on single server (SNI) for HTTPS connections''']<br />
* [https://bugzilla.zimbra.com/show_bug.cgi?id=103362 Bug 103362 - '''Multiple SSL domains on single server (SNI) for IMAPS/POP3S connections''']<br />
<br />
{{Article Footer|Zimbra Collaboration Suite 8.7|03/05/2016}}<br />
{{NeedSME|Jorge|SME2|Copyeditor}}<br />
<br />
[[Category:Certified]]<br />
[[Category:Certificates]]<br />
[[Category:ZCS 8.7]]</div>Gren Elliothttps://wiki.zimbra.com/index.php?title=Multiple_SSL_Certificates,_Server_Name_Indication_(SNI)_for_HTTPS&diff=61758Multiple SSL Certificates, Server Name Indication (SNI) for HTTPS2016-05-04T09:58:06Z<p>Gren Elliot: /* Configuring the IP address per domain */</p>
<hr />
<div>{{BC|Certified}}<br />
__FORCETOC__<br />
<div class="col-md-12 ibox-content"><br />
=Multiple SSL Certificates, Server Name Indication (SNI) for HTTPS=<br />
{{KB|{{ZC}}|{{ZCS 8.7}}||}}<br />
{{WIP}}<br />
<div class="alert alert-dark fade in"> <p><strong>Note: This feature will not enable SSL Certificate for IMAP/POP or smtps connections. [https://bugzilla.zimbra.com/show_bug.cgi?id=103362 RFE #103362]</strong> </p></div> <br />
<br />
[https://en.wikipedia.org/wiki/Server_Name_Indication '''Server Name Indication (SNI)'''] is an extension to the TLS computer networking protocol by which a client indicates which hostname it is attempting to connect to at the start of the handshaking process. This allows a server to present multiple certificates on the same IP address and TCP port number and hence allows multiple secure (HTTPS) websites (or any other Service over TLS) to be served off the same IP address without requiring all those sites to use the same certificate. It is the conceptual equivalent to HTTP/1.1 name-based virtual hosting, but for HTTPS. The desired hostname is not encrypted, so an eavesdropper can see which site is being requested.<br />
<br />
To make SNI useful, as with any protocol, the vast majority of visitors must use web browsers that implement it. Users whose browsers do not implement SNI are presented with a default certificate and hence are likely to receive certificate warnings. [https://en.wikipedia.org/wiki/Server_Name_Indication Source:Wikipedia]<br />
<br />
==Getting Started==<br />
Zimbra Collaboration supports SSL SNI starting at the 8.7 Release. The support requires and uses features of the Proxy service (which is actually required by Zimbra Collaboration 8.7 anyway)<br />
[[File:Zimbra-ssl-sni-001.png]]<br />
<br />
==Prerequisites==<br />
* Zimbra proxy service must be installed and enabled on the server. In a multi server environment, these steps should be performed on the proxy node<br />
* You should have a signed certificate + matching key pair and the trusted chain certs from your CA (Certificate Authority) (This is a common issue, so please, make sure you check your files before deploying them)<br />
* You can bind Multiple SSL Certificates to just one ipv4 address, which will pair to the respective domain names. For example:<br />
1.1.1.1 => example.com<br />
1.1.1.1=> otherdomain.com<br />
and you could even have another IPv4 address, for Customer reasons with other group of SSL Certificates, even different type of SSL Certificates:<br />
3.3.3.3 => yetanotherdomain.com (A Comodo Wildcard SSL Certificate)<br />
3.3.3.3 => thisisanotherdomain.com (A free Let's Encrypt SSL Certificate)<br />
3.3.3.3 => customer001.net (A RapidSSL Certificate)<br />
etc.<br />
<br />
===Browser support for SNI===<br />
The following browsers do offer support for SNI, however Zimbra hasn't tested all of them, it is the responsibility of the web-browser, to support the application part of SNI :<br />
{|class="wikitable sortable"<br />
! Software !! Type !! Supported !! Notes !! Supported since<br />
|-<br />
| Internet Explorer || Web browser || <i class="fa fa-check-circle"></i> || Since version 7 on Vista (not supported on XP) || 2006<br />
|-<br />
| Mozilla Firefox || Web browser || <i class="fa fa-check-circle"></i> || Since version 2.0 [https://bugzilla.mozilla.org/show_bug.cgi?id=116169#c26 Reference 116169] || 2006<br />
|-<br />
| curl || Command-line tool and library || <i class="fa fa-check-circle"></i> || Since version 7.18.1 || 2008<br />
|-<br />
| Safari || Web browser || <i class="fa fa-check-circle"></i> || Not supported on XP ||<br />
|-<br />
| Google Chrome || Web browser || <i class="fa fa-check-circle"></i> || Since 6.0 || 2010<br />
|-<br />
| BlackBerry OS || Web browser || <i class="fa fa-check-circle"></i> || 7.2 or later ||<br />
|-<br />
| Windows Mobile || Web browser ||<i class="fa fa-check-circle"></i> || Some time after 6.5<ref>{{cite web|url=http://blogs.msdn.com/b/ieinternals/archive/2009/12/07/certificate-name-mismatch-warnings-and-server-name-indication.aspx |title=Understanding Certificate Name Mismatches |publisher=Blogs.msdn.com |date= |accessdate=2011-03-08}}</ref> ||<br />
|-<br />
| Android default browser || Web browser || <i class="fa fa-check-circle"></i> || Honeycomb (3.x) for tablets and Ice Cream Sandwich (4.x) for phones<ref>{{cite web|url=https://code.google.com/p/android/issues/detail?id=12908 |title=Android issue 1290 - Https websites that support Server Name Indication (SNI) don't work |publisher=Code.google.com |date=2010-12-01 |accessdate=2011-12-13}}</ref> || 2011<br />
|-<br />
| wget || Command-line tool || <i class="fa fa-check-circle"></i> || Since version 1.14 || 2012<br />
|-<br />
| Nokia Browser for Symbian || Web browser || <i class="fa fa-times"></i> || ||<br />
|-<br />
| Opera Mobile || Web browser || <i class="fa fa-times"></i> || Not supported on Series60 ||<br />
|-<br />
|}<br />
<br />
==Configuring the IP address per domain==<br />
* 1. Add the new domain, in this case '''example.com'''. Set '''zimbraVirtualHostName''' to '''mail.example.com''' and '''zimbraVirtualIPAddress''' to '''1.2.3.4'''. Make sure the zimbraVirtualHostName is set to the name which will be used to access the domain (URL) and the SSL certificate is signed for the same name.<br />
zmprov md example.com zimbraVirtualHostName mail.example.com zimbraVirtualIPAddress 1.2.3.4<br />
<br />
'''NOTE: If the server is behind a firewall and NAT'ed with an external address, make sure external requests for "mail.example.com" hit the aliased IP address and not the actual local IP address of server.'''<br />
<br />
==Verifying and Preparing the Certificates==<br />
We should have three files received from the CA (might variate depending on the Certificate Authority). The server (domain) certificate, two chain certs. And we have existing key file (which was used to generate the csr)<br />
* 1. Save the '''example.com certificate''', '''key''' and '''chain files''' to a directory '''/tmp/example.com.''' You can receive single or multiple chain certs from your CA. Here we have two chain certs from the CA. i.e. example.com.root.crt and example.com.intermediate.crt.<br />
ls /tmp/example.com<br />
example.com.key<br />
example.com.crt<br />
example.com.root.crt<br />
example.com.intermediate.crt<br />
<br />
* 2. Add the chain certs to a single file called example.com_ca.crt<br />
cat example.com.root.crt example.com.intermediate.crt >> example.com_ca.crt<br />
<br />
* 3. Confirm if the key and certificate matches and chain certs completes the trust. As zimbra user:<br />
/opt/zimbra/bin/zmcertmgr verifycrt comm /tmp/example.com/example.com.key /tmp/example.com/example.com.crt /tmp/example.com/example.com_ca.crt<br />
<br />
<br />
** Check the output, it should say something like this. If not, make sure you have correct key and chain cert files.<br />
** Verifying '/tmp/example.com.crt' against '/tmp/example.com.key'<br />
Certificate '/tmp/example.com.crt' and private key '/tmp/example.com.key' match.<br />
** Verifying '/tmp/example.com.crt' against '/tmp/example.com_ca.crt'<br />
Valid certificate chain: /tmp/example.com.crt: OK<br />
<br />
==Deploying the Certificate or Certificates on domain==<br />
* 1. Add the domain certificate and chain files to a single file called example.com.bundle<br />
cat example.com.crt example.com_ca.crt >> example.com.bundle<br />
<br />
* 2. Run following to save the certificates and key in ldap database, as zimbra user:<br />
/opt/zimbra/libexec/zmdomaincertmgr savecrt example.com example.com.bundle example.com.key<br />
** Saving domain config key zimbraSSLCertificate...done.<br />
** Saving domain config key zimbraSSLPrivateKey...done.<br />
** The syntax is:<br />
/opt/zimbra/libexec/zmdomaincertmgr savecrt <domainname> <certificate with chain certs> <keyfile><br />
<br />
* 3. Run following to deploy the domain certificate. This will save the certificate and key as /opt/zimbra/conf/domaincerts/example.com , as zimbra user:<br />
/opt/zimbra/libexec/zmdomaincertmgr deploycrts<br />
** Deploying cert for example.com...done.<br />
<br />
== Proxy Check ==<br />
Run these commands on proxy hosts, or on the server if it's Single Server: <br />
* zimbraReverseProxySNIEnabled should be set to TRUE in server and global config. <br />
zmprov mcf zimbraReverseProxySNIEnabled TRUE<br />
<br />
== Re-write and restart Proxy ==<br />
* Restart the proxy to re-write the changes to proxy config<br />
zmproxyctl restart<br />
<br />
* Once the restart is successfull, try to access the domain using the URL which is set in "zimbraVirtualHostName" over https. And check the certificate loaded in the browser. In this case the URL will be https://example.com<br />
<br />
=Testing=<br />
You can go now to a Web browser and check the different zimbraVirtualHostName, and you will see that they will present to you different SSL certificates, the corresponding one per each virtualhostname.<br />
<br />
=Troubleshooting=<br />
* If you do not see domain cert by accessing the domain with its zimbraVirtualHostName (example.com). Make sure the https connection from Internet/intranet is going to server's local IP address which is defined in zimbraVirtualIPAddress, and make sure you have activated zimbraReverseProxySNIEnabled to TRUE<br />
<br />
* If you are using multiple proxy servers or adding new proxy servers, make sure you copy all the contents of /opt/zimbra/conf/domaincerts/ among all proxy servers. '''Otherwise proxy service will fail to start.'''<br />
<br />
<br />
=Known Issues=<br />
* [https://bugzilla.zimbra.com/show_bug.cgi?id=102913 Bug 102913 - '''Multiple SSL domains on single server (SNI) for HTTPS connections''']<br />
* [https://bugzilla.zimbra.com/show_bug.cgi?id=103362 Bug 103362 - '''Multiple SSL domains on single server (SNI) for IMAPS/POP3S connections''']<br />
<br />
{{Article Footer|Zimbra Collaboration Suite 8.7|03/05/2016}}<br />
{{NeedSME|Jorge|SME2|Copyeditor}}<br />
<br />
[[Category:Certified]]<br />
[[Category:Certificates]]<br />
[[Category:ZCS 8.7]]</div>Gren Elliothttps://wiki.zimbra.com/index.php?title=Multiple_SSL_Certificates,_Server_Name_Indication_(SNI)_for_HTTPS&diff=61757Multiple SSL Certificates, Server Name Indication (SNI) for HTTPS2016-05-04T09:55:44Z<p>Gren Elliot: /* Prerequisites */</p>
<hr />
<div>{{BC|Certified}}<br />
__FORCETOC__<br />
<div class="col-md-12 ibox-content"><br />
=Multiple SSL Certificates, Server Name Indication (SNI) for HTTPS=<br />
{{KB|{{ZC}}|{{ZCS 8.7}}||}}<br />
{{WIP}}<br />
<div class="alert alert-dark fade in"> <p><strong>Note: This feature will not enable SSL Certificate for IMAP/POP or smtps connections. [https://bugzilla.zimbra.com/show_bug.cgi?id=103362 RFE #103362]</strong> </p></div> <br />
<br />
[https://en.wikipedia.org/wiki/Server_Name_Indication '''Server Name Indication (SNI)'''] is an extension to the TLS computer networking protocol by which a client indicates which hostname it is attempting to connect to at the start of the handshaking process. This allows a server to present multiple certificates on the same IP address and TCP port number and hence allows multiple secure (HTTPS) websites (or any other Service over TLS) to be served off the same IP address without requiring all those sites to use the same certificate. It is the conceptual equivalent to HTTP/1.1 name-based virtual hosting, but for HTTPS. The desired hostname is not encrypted, so an eavesdropper can see which site is being requested.<br />
<br />
To make SNI useful, as with any protocol, the vast majority of visitors must use web browsers that implement it. Users whose browsers do not implement SNI are presented with a default certificate and hence are likely to receive certificate warnings. [https://en.wikipedia.org/wiki/Server_Name_Indication Source:Wikipedia]<br />
<br />
==Getting Started==<br />
Zimbra Collaboration supports SSL SNI starting at the 8.7 Release. The support requires and uses features of the Proxy service (which is actually required by Zimbra Collaboration 8.7 anyway)<br />
[[File:Zimbra-ssl-sni-001.png]]<br />
<br />
==Prerequisites==<br />
* Zimbra proxy service must be installed and enabled on the server. In a multi server environment, these steps should be performed on the proxy node<br />
* You should have a signed certificate + matching key pair and the trusted chain certs from your CA (Certificate Authority) (This is a common issue, so please, make sure you check your files before deploying them)<br />
* You can bind Multiple SSL Certificates to just one ipv4 address, which will pair to the respective domain names. For example:<br />
1.1.1.1 => example.com<br />
1.1.1.1=> otherdomain.com<br />
and you could even have another IPv4 address, for Customer reasons with other group of SSL Certificates, even different type of SSL Certificates:<br />
3.3.3.3 => yetanotherdomain.com (A Comodo Wildcard SSL Certificate)<br />
3.3.3.3 => thisisanotherdomain.com (A free Let's Encrypt SSL Certificate)<br />
3.3.3.3 => customer001.net (A RapidSSL Certificate)<br />
etc.<br />
<br />
===Browser support for SNI===<br />
The following browsers do offer support for SNI, however Zimbra hasn't tested all of them, it is the responsibility of the web-browser, to support the application part of SNI :<br />
{|class="wikitable sortable"<br />
! Software !! Type !! Supported !! Notes !! Supported since<br />
|-<br />
| Internet Explorer || Web browser || <i class="fa fa-check-circle"></i> || Since version 7 on Vista (not supported on XP) || 2006<br />
|-<br />
| Mozilla Firefox || Web browser || <i class="fa fa-check-circle"></i> || Since version 2.0 [https://bugzilla.mozilla.org/show_bug.cgi?id=116169#c26 Reference 116169] || 2006<br />
|-<br />
| curl || Command-line tool and library || <i class="fa fa-check-circle"></i> || Since version 7.18.1 || 2008<br />
|-<br />
| Safari || Web browser || <i class="fa fa-check-circle"></i> || Not supported on XP ||<br />
|-<br />
| Google Chrome || Web browser || <i class="fa fa-check-circle"></i> || Since 6.0 || 2010<br />
|-<br />
| BlackBerry OS || Web browser || <i class="fa fa-check-circle"></i> || 7.2 or later ||<br />
|-<br />
| Windows Mobile || Web browser ||<i class="fa fa-check-circle"></i> || Some time after 6.5<ref>{{cite web|url=http://blogs.msdn.com/b/ieinternals/archive/2009/12/07/certificate-name-mismatch-warnings-and-server-name-indication.aspx |title=Understanding Certificate Name Mismatches |publisher=Blogs.msdn.com |date= |accessdate=2011-03-08}}</ref> ||<br />
|-<br />
| Android default browser || Web browser || <i class="fa fa-check-circle"></i> || Honeycomb (3.x) for tablets and Ice Cream Sandwich (4.x) for phones<ref>{{cite web|url=https://code.google.com/p/android/issues/detail?id=12908 |title=Android issue 1290 - Https websites that support Server Name Indication (SNI) don't work |publisher=Code.google.com |date=2010-12-01 |accessdate=2011-12-13}}</ref> || 2011<br />
|-<br />
| wget || Command-line tool || <i class="fa fa-check-circle"></i> || Since version 1.14 || 2012<br />
|-<br />
| Nokia Browser for Symbian || Web browser || <i class="fa fa-times"></i> || ||<br />
|-<br />
| Opera Mobile || Web browser || <i class="fa fa-times"></i> || Not supported on Series60 ||<br />
|-<br />
|}<br />
<br />
==Configuring the IP address per domain==<br />
* 1. Add the new domain, in this case example.com. Set '''zimbraVirtualHostName''' to '''mail.example.com''' and '''zimbraVirtualIPAddress''' to '''1.2.3.4'''. Make sure the zimbraVirtualHostName is set to the name which will be used to access the domain (URL) and the SSL certificate is signed for same name.<br />
zmprov md example.com zimbraVirtualHostName mail.example.com zimbraVirtualIPAddress 1.2.3.4<br />
<br />
'''NOTE: If the server is behind firewall and NAT'ed with external address, make sure the external requests for "mail.example.com" hits the aliased IP address and not the actual local IP of server.'''<br />
<br />
==Verifying and Preparing the Certificates==<br />
We should have three files received from the CA (might variate depending on the Certificate Authority). The server (domain) certificate, two chain certs. And we have existing key file (which was used to generate the csr)<br />
* 1. Save the '''example.com certificate''', '''key''' and '''chain files''' to a directory '''/tmp/example.com.''' You can receive single or multiple chain certs from your CA. Here we have two chain certs from the CA. i.e. example.com.root.crt and example.com.intermediate.crt.<br />
ls /tmp/example.com<br />
example.com.key<br />
example.com.crt<br />
example.com.root.crt<br />
example.com.intermediate.crt<br />
<br />
* 2. Add the chain certs to a single file called example.com_ca.crt<br />
cat example.com.root.crt example.com.intermediate.crt >> example.com_ca.crt<br />
<br />
* 3. Confirm if the key and certificate matches and chain certs completes the trust. As zimbra user:<br />
/opt/zimbra/bin/zmcertmgr verifycrt comm /tmp/example.com/example.com.key /tmp/example.com/example.com.crt /tmp/example.com/example.com_ca.crt<br />
<br />
<br />
** Check the output, it should say something like this. If not, make sure you have correct key and chain cert files.<br />
** Verifying '/tmp/example.com.crt' against '/tmp/example.com.key'<br />
Certificate '/tmp/example.com.crt' and private key '/tmp/example.com.key' match.<br />
** Verifying '/tmp/example.com.crt' against '/tmp/example.com_ca.crt'<br />
Valid certificate chain: /tmp/example.com.crt: OK<br />
<br />
==Deploying the Certificate or Certificates on domain==<br />
* 1. Add the domain certificate and chain files to a single file called example.com.bundle<br />
cat example.com.crt example.com_ca.crt >> example.com.bundle<br />
<br />
* 2. Run following to save the certificates and key in ldap database, as zimbra user:<br />
/opt/zimbra/libexec/zmdomaincertmgr savecrt example.com example.com.bundle example.com.key<br />
** Saving domain config key zimbraSSLCertificate...done.<br />
** Saving domain config key zimbraSSLPrivateKey...done.<br />
** The syntax is:<br />
/opt/zimbra/libexec/zmdomaincertmgr savecrt <domainname> <certificate with chain certs> <keyfile><br />
<br />
* 3. Run following to deploy the domain certificate. This will save the certificate and key as /opt/zimbra/conf/domaincerts/example.com , as zimbra user:<br />
/opt/zimbra/libexec/zmdomaincertmgr deploycrts<br />
** Deploying cert for example.com...done.<br />
<br />
== Proxy Check ==<br />
Run these commands on proxy hosts, or on the server if it's Single Server: <br />
* zimbraReverseProxySNIEnabled should be set to TRUE in server and global config. <br />
zmprov mcf zimbraReverseProxySNIEnabled TRUE<br />
<br />
== Re-write and restart Proxy ==<br />
* Restart the proxy to re-write the changes to proxy config<br />
zmproxyctl restart<br />
<br />
* Once the restart is successfull, try to access the domain using the URL which is set in "zimbraVirtualHostName" over https. And check the certificate loaded in the browser. In this case the URL will be https://example.com<br />
<br />
=Testing=<br />
You can go now to a Web browser and check the different zimbraVirtualHostName, and you will see that they will present to you different SSL certificates, the corresponding one per each virtualhostname.<br />
<br />
=Troubleshooting=<br />
* If you do not see domain cert by accessing the domain with its zimbraVirtualHostName (example.com). Make sure the https connection from Internet/intranet is going to server's local IP address which is defined in zimbraVirtualIPAddress, and make sure you have activated zimbraReverseProxySNIEnabled to TRUE<br />
<br />
* If you are using multiple proxy servers or adding new proxy servers, make sure you copy all the contents of /opt/zimbra/conf/domaincerts/ among all proxy servers. '''Otherwise proxy service will fail to start.'''<br />
<br />
<br />
=Known Issues=<br />
* [https://bugzilla.zimbra.com/show_bug.cgi?id=102913 Bug 102913 - '''Multiple SSL domains on single server (SNI) for HTTPS connections''']<br />
* [https://bugzilla.zimbra.com/show_bug.cgi?id=103362 Bug 103362 - '''Multiple SSL domains on single server (SNI) for IMAPS/POP3S connections''']<br />
<br />
{{Article Footer|Zimbra Collaboration Suite 8.7|03/05/2016}}<br />
{{NeedSME|Jorge|SME2|Copyeditor}}<br />
<br />
[[Category:Certified]]<br />
[[Category:Certificates]]<br />
[[Category:ZCS 8.7]]</div>Gren Elliothttps://wiki.zimbra.com/index.php?title=Multiple_SSL_Certificates,_Server_Name_Indication_(SNI)_for_HTTPS&diff=61756Multiple SSL Certificates, Server Name Indication (SNI) for HTTPS2016-05-04T09:47:53Z<p>Gren Elliot: /* Getting Started */</p>
<hr />
<div>{{BC|Certified}}<br />
__FORCETOC__<br />
<div class="col-md-12 ibox-content"><br />
=Multiple SSL Certificates, Server Name Indication (SNI) for HTTPS=<br />
{{KB|{{ZC}}|{{ZCS 8.7}}||}}<br />
{{WIP}}<br />
<div class="alert alert-dark fade in"> <p><strong>Note: This feature will not enable SSL Certificate for IMAP/POP or smtps connections. [https://bugzilla.zimbra.com/show_bug.cgi?id=103362 RFE #103362]</strong> </p></div> <br />
<br />
[https://en.wikipedia.org/wiki/Server_Name_Indication '''Server Name Indication (SNI)'''] is an extension to the TLS computer networking protocol by which a client indicates which hostname it is attempting to connect to at the start of the handshaking process. This allows a server to present multiple certificates on the same IP address and TCP port number and hence allows multiple secure (HTTPS) websites (or any other Service over TLS) to be served off the same IP address without requiring all those sites to use the same certificate. It is the conceptual equivalent to HTTP/1.1 name-based virtual hosting, but for HTTPS. The desired hostname is not encrypted, so an eavesdropper can see which site is being requested.<br />
<br />
To make SNI useful, as with any protocol, the vast majority of visitors must use web browsers that implement it. Users whose browsers do not implement SNI are presented with a default certificate and hence are likely to receive certificate warnings. [https://en.wikipedia.org/wiki/Server_Name_Indication Source:Wikipedia]<br />
<br />
==Getting Started==<br />
Zimbra Collaboration supports SSL SNI starting at the 8.7 Release. The support requires and uses features of the Proxy service (which is actually required by Zimbra Collaboration 8.7 anyway)<br />
[[File:Zimbra-ssl-sni-001.png]]<br />
<br />
==Prerequisites==<br />
* Zimbra proxy service must be installed and enabled on the server. In multi server environment, follow these steps on the proxy node<br />
* You should have a signed certificate + matching key pair and the trusted chain certs from your CA (Certificate Authority) (This is a common issue, so please, make sure you check your files before deploy the files)<br />
* You can bind Multiple SSL Certificates to just one ipv4 addresses, which will pair to the respective domain name. For example:<br />
1.1.1.1 => example.com<br />
1.1.1.1=> otherdomain.com<br />
and you could even have another IPv4, for Customer reasons with other group of SSL Certificates, even different type of SSL Certificates:<br />
3.3.3.3 => yetanotherdomain.com (A Comodo Wildcard SSL Certificate)<br />
3.3.3.3 => thisisanotherdomain.com (A free Let's Encrypt SSL Certificate)<br />
3.3.3.3 => customer001.net (A RapidSSL Certificate)<br />
etc.<br />
<br />
===Browser support for SNI===<br />
The following browsers do offer support for SNI, however Zimbra hasn't tested all of them, it will be responsibility of the web-browser, to support the application part of SNI :<br />
{|class="wikitable sortable"<br />
! Software !! Type !! Supported !! Notes !! Supported since<br />
|-<br />
| Internet Explorer || Web browser || <i class="fa fa-check-circle"></i> || Since version 7 on Vista (not supported on XP) || 2006<br />
|-<br />
| Mozilla Firefox || Web browser || <i class="fa fa-check-circle"></i> || Since version 2.0 [https://bugzilla.mozilla.org/show_bug.cgi?id=116169#c26 Reference 116169] || 2006<br />
|-<br />
| curl || Command-line tool and library || <i class="fa fa-check-circle"></i> || Since version 7.18.1 || 2008<br />
|-<br />
| Safari || Web browser || <i class="fa fa-check-circle"></i> || Not supported on XP ||<br />
|-<br />
| Google Chrome || Web browser || <i class="fa fa-check-circle"></i> || Since 6.0 || 2010<br />
|-<br />
| BlackBerry OS || Web browser || <i class="fa fa-check-circle"></i> || 7.2 or later ||<br />
|-<br />
| Windows Mobile || Web browser ||<i class="fa fa-check-circle"></i> || Some time after 6.5<ref>{{cite web|url=http://blogs.msdn.com/b/ieinternals/archive/2009/12/07/certificate-name-mismatch-warnings-and-server-name-indication.aspx |title=Understanding Certificate Name Mismatches |publisher=Blogs.msdn.com |date= |accessdate=2011-03-08}}</ref> ||<br />
|-<br />
| Android default browser || Web browser || <i class="fa fa-check-circle"></i> || Honeycomb (3.x) for tablets and Ice Cream Sandwich (4.x) for phones<ref>{{cite web|url=https://code.google.com/p/android/issues/detail?id=12908 |title=Android issue 1290 - Https websites that support Server Name Indication (SNI) don't work |publisher=Code.google.com |date=2010-12-01 |accessdate=2011-12-13}}</ref> || 2011<br />
|-<br />
| wget || Command-line tool || <i class="fa fa-check-circle"></i> || Since version 1.14 || 2012<br />
|-<br />
| Nokia Browser for Symbian || Web browser || <i class="fa fa-times"></i> || ||<br />
|-<br />
| Opera Mobile || Web browser || <i class="fa fa-times"></i> || Not supported on Series60 ||<br />
|-<br />
|}<br />
<br />
==Configuring the IP address per domain==<br />
* 1. Add the new domain, in this case example.com. Set '''zimbraVirtualHostName''' to '''mail.example.com''' and '''zimbraVirtualIPAddress''' to '''1.2.3.4'''. Make sure the zimbraVirtualHostName is set to the name which will be used to access the domain (URL) and the SSL certificate is signed for same name.<br />
zmprov md example.com zimbraVirtualHostName mail.example.com zimbraVirtualIPAddress 1.2.3.4<br />
<br />
'''NOTE: If the server is behind firewall and NAT'ed with external address, make sure the external requests for "mail.example.com" hits the aliased IP address and not the actual local IP of server.'''<br />
<br />
==Verifying and Preparing the Certificates==<br />
We should have three files received from the CA (might variate depending on the Certificate Authority). The server (domain) certificate, two chain certs. And we have existing key file (which was used to generate the csr)<br />
* 1. Save the '''example.com certificate''', '''key''' and '''chain files''' to a directory '''/tmp/example.com.''' You can receive single or multiple chain certs from your CA. Here we have two chain certs from the CA. i.e. example.com.root.crt and example.com.intermediate.crt.<br />
ls /tmp/example.com<br />
example.com.key<br />
example.com.crt<br />
example.com.root.crt<br />
example.com.intermediate.crt<br />
<br />
* 2. Add the chain certs to a single file called example.com_ca.crt<br />
cat example.com.root.crt example.com.intermediate.crt >> example.com_ca.crt<br />
<br />
* 3. Confirm if the key and certificate matches and chain certs completes the trust. As zimbra user:<br />
/opt/zimbra/bin/zmcertmgr verifycrt comm /tmp/example.com/example.com.key /tmp/example.com/example.com.crt /tmp/example.com/example.com_ca.crt<br />
<br />
<br />
** Check the output, it should say something like this. If not, make sure you have correct key and chain cert files.<br />
** Verifying '/tmp/example.com.crt' against '/tmp/example.com.key'<br />
Certificate '/tmp/example.com.crt' and private key '/tmp/example.com.key' match.<br />
** Verifying '/tmp/example.com.crt' against '/tmp/example.com_ca.crt'<br />
Valid certificate chain: /tmp/example.com.crt: OK<br />
<br />
==Deploying the Certificate or Certificates on domain==<br />
* 1. Add the domain certificate and chain files to a single file called example.com.bundle<br />
cat example.com.crt example.com_ca.crt >> example.com.bundle<br />
<br />
* 2. Run following to save the certificates and key in ldap database, as zimbra user:<br />
/opt/zimbra/libexec/zmdomaincertmgr savecrt example.com example.com.bundle example.com.key<br />
** Saving domain config key zimbraSSLCertificate...done.<br />
** Saving domain config key zimbraSSLPrivateKey...done.<br />
** The syntax is:<br />
/opt/zimbra/libexec/zmdomaincertmgr savecrt <domainname> <certificate with chain certs> <keyfile><br />
<br />
* 3. Run following to deploy the domain certificate. This will save the certificate and key as /opt/zimbra/conf/domaincerts/example.com , as zimbra user:<br />
/opt/zimbra/libexec/zmdomaincertmgr deploycrts<br />
** Deploying cert for example.com...done.<br />
<br />
== Proxy Check ==<br />
Run these commands on proxy hosts, or on the server if it's Single Server: <br />
* zimbraReverseProxySNIEnabled should be set to TRUE in server and global config. <br />
zmprov mcf zimbraReverseProxySNIEnabled TRUE<br />
<br />
== Re-write and restart Proxy ==<br />
* Restart the proxy to re-write the changes to proxy config<br />
zmproxyctl restart<br />
<br />
* Once the restart is successfull, try to access the domain using the URL which is set in "zimbraVirtualHostName" over https. And check the certificate loaded in the browser. In this case the URL will be https://example.com<br />
<br />
=Testing=<br />
You can go now to a Web browser and check the different zimbraVirtualHostName, and you will see that they will present to you different SSL certificates, the corresponding one per each virtualhostname.<br />
<br />
=Troubleshooting=<br />
* If you do not see domain cert by accessing the domain with its zimbraVirtualHostName (example.com). Make sure the https connection from Internet/intranet is going to server's local IP address which is defined in zimbraVirtualIPAddress, and make sure you have activated zimbraReverseProxySNIEnabled to TRUE<br />
<br />
* If you are using multiple proxy servers or adding new proxy servers, make sure you copy all the contents of /opt/zimbra/conf/domaincerts/ among all proxy servers. '''Otherwise proxy service will fail to start.'''<br />
<br />
<br />
=Known Issues=<br />
* [https://bugzilla.zimbra.com/show_bug.cgi?id=102913 Bug 102913 - '''Multiple SSL domains on single server (SNI) for HTTPS connections''']<br />
* [https://bugzilla.zimbra.com/show_bug.cgi?id=103362 Bug 103362 - '''Multiple SSL domains on single server (SNI) for IMAPS/POP3S connections''']<br />
<br />
{{Article Footer|Zimbra Collaboration Suite 8.7|03/05/2016}}<br />
{{NeedSME|Jorge|SME2|Copyeditor}}<br />
<br />
[[Category:Certified]]<br />
[[Category:Certificates]]<br />
[[Category:ZCS 8.7]]</div>Gren Elliothttps://wiki.zimbra.com/index.php?title=Zimbra_Collaboration_repository&diff=61587Zimbra Collaboration repository2016-04-05T07:46:07Z<p>Gren Elliot: /* How to create a local repository */</p>
<hr />
<div>{{BC|Community Sandbox}}<br />
__FORCETOC__<br />
<div class="col-md-12 ibox-content"><br />
=Zimbra Collaboration Repository=<br />
{{KB|{{Unsupported}}|{{ZCS 8.7}}|||}}<br />
<br />
=How it works=<br />
Starting in Zimbra Collaboration 8.7, Zimbra uses repositories for 3rd party packages, in the first step towards having the whole product fully installable from repositories.<br />
<br />
[[File:Zimbra-repository.png|800px]]<br />
<br />
=How to create a local repository=<br />
Many Customers do not allow Internet access from their servers to the Internet, which means Zimbra's 8.7 installer will not be able to reach the Zimbra repository and be able to finish the Installation.<br />
<br />
In order to successfully install Zimbra 8.7 within such a network, this Wiki will cover all the steps needed to create a local Zimbra mirror where a Company can clone our repo to a mirror, and the rest of the internal servers will take the needed packages locally from the mirror server. Section B in the image above is an example of this type of layout.<br />
<br />
==Creating a local repository using an Ubuntu OS==<br />
Follow these steps to create a local repository or mirror using Ubuntu OS for the dedicated server.<br />
<br />
First step will be sure we have the latest packages:<br />
apt-get update<br />
===Installing Python===<br />
Then we need to install the python packages:<br />
apt-get install python-pip<br />
<br />
===Installing Amazon Web Services CLI===<br />
Once we have installed python, it's time to install the Amazon Web Services CLI, by running the next command<br />
pip install awscli<br />
<br />
===Cloning the packages from our Official Repository ===<br />
It's time to download all the packages from our official Repository to the local folder, first step it's create the local folder<br />
root@repo:~#mkdir /var/repositories<br />
root@repo:~#cd /var/repositories<br />
====Cloning the packages for Ubuntu====<br />
If you are planning to install Zimbra on your Ubuntu VM/Servers, then run the next command to download the Ubuntu packages:<br />
root@repo:~# /usr/local/bin/aws s3 sync s3://repo.zimbra.com/apt/87 ./apt/87 --no-sign-request --delete<br />
====Cloning the packages for RHEL/CentOS====<br />
If you are planning to install Zimbra on your RHEL/CentOS VM/Servers, then run the next command to download the RHEL/CentOS packages:<br />
/usr/local/bin/aws s3 sync s3://repo.zimbra.com/rpm/87 ./rpm/87 --no-sign-request --delete<br />
<br />
===Installing & configuring Nginx===<br />
Then we need to serve the packages using nginx, let's start for the basic steps to install nginx:<br />
root@repo:~# apt-get install nginx<br />
<br />
Zimbra strongly recommends using a valid SSL certificate for the repository server. Put the '''zimbra-wilcard.crt''' (must contain the CRT and the CA) and the '''zimbra-wilcard.key''' inside the next folder:<br />
root@repo:~# mkdir /etc/nginx/certs<br />
Let's go now to configure our Nginx server, first backup the default config and create a new one:<br />
root@repo:~# mv /etc/nginx/sites-available/default /etc/nginx/sites-available/default.bak<br />
root@repo:~# touch /etc/nginx/sites-available/default<br />
You can use the next example to fill your Repository configuration<br />
<pre>root@repo:~# vi /etc/nginx/sites-available/default<br />
server {<br />
listen 443 ssl;<br />
ssl_certificate /etc/nginx/certs/zimbra-wilcard.crt;<br />
ssl_certificate_key /etc/nginx/certs/zimbra-wilcard.key;<br />
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;<br />
ssl_ciphers HIGH:!aNULL:!MD5;<br />
## Let your repository be the root directory<br />
root /var/repositories;<br />
<br />
## Always good to log<br />
access_log /var/log/nginx/repo.access.log;<br />
error_log /var/log/nginx/repo.error.log;<br />
<br />
## Prevent access to Reprepro's files<br />
location ~ /(db|conf) {<br />
deny all;<br />
return 404;<br />
}<br />
}</pre><br />
And, restart your nginx service<br />
<pre>root@repo:~# service nginx restart<br />
* Restarting nginx nginx<br />
...done.</pre><br />
<br />
==Creating a local repository using a RHEL/CentOS==<br />
Pending<br />
===Installing Python===<br />
Pending<br />
===Installing Amazon Web Services CLI===<br />
Pending<br />
===Cloning the packages from our Official Repository ===<br />
Pending<br />
====Cloning the packages for Ubuntu====<br />
Pending<br />
====Cloning the packages for RHEL/CentOS====<br />
Pending<br />
===Installing & configuring Nginx===<br />
Pending<br />
<br />
=How to configure the Zimbra Server for Ubuntu=<br />
In this demo scenario, will install a new instance of Zimbra Collaboration server with Ubuntu as the operating system<br />
<br />
==Configure the sources list==<br />
You must add your local repository to your Ubuntu Configuration, please note you must change '''trusty''' (Ubuntu 14.04) to '''precise''' if you are running Ubuntu 12.04:<br />
<pre>root@zimbra86:~/# vi /etc/apt/sources.list.d/zimbra-mirror.list<br />
deb [arch=amd64] https://repo.zimbra.io/apt/87 trusty zimbra<br />
deb-src [arch=amd64] https://repo.zimbra.io/apt/87 trusty zimbra</pre><br />
<br />
==Adding the Zimbra Repository key==<br />
You must add the next Zimbra key to the apt keychain<br />
<pre>root@zimbra86:~# apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 9BE6ED79<br />
Executing: gpg --ignore-time-conflict --no-options --no-default-keyring --homedir /tmp/tmp.FfpLxMcUiQ --no-auto-check-trustdb --trust-model always --keyring /etc/apt/trusted.gpg --primary-keyring /etc/apt/trusted.gpg --keyserver keyserver.ubuntu.com --recv-keys 9BE6ED79<br />
gpg: requesting key 9BE6ED79 from hkp server keyserver.ubuntu.com<br />
gpg: key 9BE6ED79: public key "Zimbra Packaging Services <packaging-devel@zimbra.com>" imported<br />
gpg: Total number processed: 1<br />
gpg: imported: 1 (RSA: 1)</pre><br />
<br />
==Check if the Zimbra Server is ready==<br />
You can check if everything is alright by running the next commands, where you can search by one Zimbra package:<br />
<pre>apt-get update<br />
<pre>root@zimbra86:~# aptitude search zimbra-nginx<br />
p zimbra-nginx - nginx Binaries <br />
p zimbra-nginx-dbg - nginx binary debug information</pre><br />
<br />
==Installing Zimbra Collaboration 8.7==<br />
Last but not least, download the Zimbra Collaboration 8.7 package and run the '''./install.sh''' as usual.<br />
*Note: You will not need to install the OS dependencies like in the past, the new Zimbra Collaboration 8.7 installation script take care of it<br />
<br />
During the question about use '''Zimbra's package repository''', '''type N''', so the system will use your local repository<br />
Use Zimbra's package repository [Y] n<br />
<br />
The installation will continue as usual, and will finish properly.<br />
<br />
=Keep the local Repository up to date=<br />
The challenge while using local repository is keep it up to date, you must run the next commands always before run any upgrade or update on the Zimbra Servers<br />
/usr/local/bin/aws s3 sync s3://repo.zimbra.com/apt/87 ./apt/87 --no-sign-request --delete<br />
/usr/local/bin/aws s3 sync s3://repo.zimbra.com/rpm/87 ./rpm/87 --no-sign-request --delete<br />
<br />
'''*Note: You can create a simple bash script and cron it every day, for example.'''<br />
=Known issues=<br />
==SSL issues==<br />
This error it's not related to Zimbra, but sometimes if you don't have a valid CA, or the CA is missing in the .crt file that you use for Nginx, when run apt-get update on the Zimbra server you can see the next error:<br />
W: Failed to fetch https://repo.zimbra.io/87/dists/precise/zimbra/source/Sources server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none<br />
You can fix it by adding your CA inside the '''/etc/ssl/certs/ca-certificates.crt''' on the Zimbra server</div>Gren Elliothttps://wiki.zimbra.com/index.php?title=Zimbra_Collaboration_repository&diff=61578Zimbra Collaboration repository2016-04-04T17:43:32Z<p>Gren Elliot: /* Installing & configuring Nginx */</p>
<hr />
<div>{{BC|Community Sandbox}}<br />
__FORCETOC__<br />
<div class="col-md-12 ibox-content"><br />
=Zimbra Collaboration Repository=<br />
{{KB|{{Unsupported}}|{{ZCS 8.7}}|||}}<br />
<br />
=How it works=<br />
Starting in Zimbra Collaboration 8.7, Zimbra uses repositories for 3rd party packages, in the first step towards having the whole product fully install-able from repositories.<br />
<br />
[[File:Zimbra-repository.png|1024px]]<br />
<br />
=How to create a local repository=<br />
Many Customers might not allow Internet access from their servers to the Internet, so Zimbra's 8.7 installation tools will not be able to reach the Zimbra repository and be able to finish the Installation.<br />
<br />
In order to successfully install Zimbra 8.7 within such customers' networks, this Wiki will cover all the steps needed to create a local Zimbra mirror where a Company can clone our repo, and the rest of the internal servers will take the needed packages locally from the mirror server, you can see an example on the above image, in section B.<br />
<br />
==Creating a local repository using an Ubuntu OS==<br />
Follow these steps to create a local repository or mirror using Ubuntu OS for the dedicated server.<br />
<br />
First step will be sure we have the latest packages:<br />
apt-get update<br />
===Installing Python===<br />
Then we need to install the python packages:<br />
apt-get install python-pip<br />
<br />
===Installing Amazon Web Services CLI===<br />
Once we have installed python, it's time to install the Amazon Web Services CLI, by running the next command<br />
pip install awscli<br />
<br />
===Cloning the packages from our Official Repository ===<br />
It's time to download all the packages from our official Repository to the local folder, first step it's create the local folder<br />
root@repo:~#mkdir /var/repositories<br />
root@repo:~#cd /var/repositories<br />
====Cloning the packages for Ubuntu====<br />
If you are planning to install Zimbra on your Ubuntu VM/Servers, then run the next command to download the Ubuntu packages:<br />
root@repo:~# /usr/local/bin/aws s3 sync s3://repo.zimbra.com/apt/87 ./apt/87 --no-sign-request --delete<br />
====Cloning the packages for RHEL/CentOS====<br />
If you are planning to install Zimbra on your RHEL/CentOS VM/Servers, then run the next command to download the RHEL/CentOS packages:<br />
/usr/local/bin/aws s3 sync s3://repo.zimbra.com/rpm/87 ./rpm/87 --no-sign-request --delete<br />
<br />
===Installing & configuring Nginx===<br />
Then we need to serve the packages using nginx, let's start for the basic steps to install nginx:<br />
root@repo:~# apt-get install nginx<br />
<br />
Zimbra strongly recommends using a valid SSL certificate for the repository server. Put the '''zimbra-wilcard.crt''' (must contain the CRT and the CA) and the '''zimbra-wilcard.key''' inside the next folder:<br />
root@repo:~# mkdir /etc/nginx/certs<br />
Let's go now to configure our Nginx server, first backup the default config and create a new one:<br />
root@repo:~# mv /etc/nginx/sites-available/default /etc/nginx/sites-available/default.bak<br />
root@repo:~# touch /etc/nginx/sites-available/default<br />
You can use the next example to fill your Repository configuration<br />
<pre>root@repo:~# vi /etc/nginx/sites-available/default<br />
server {<br />
listen 443 ssl;<br />
ssl_certificate /etc/nginx/certs/zimbra-wilcard.crt;<br />
ssl_certificate_key /etc/nginx/certs/zimbra-wilcard.key;<br />
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;<br />
ssl_ciphers HIGH:!aNULL:!MD5;<br />
## Let your repository be the root directory<br />
root /var/repositories;<br />
<br />
## Always good to log<br />
access_log /var/log/nginx/repo.access.log;<br />
error_log /var/log/nginx/repo.error.log;<br />
<br />
## Prevent access to Reprepro's files<br />
location ~ /(db|conf) {<br />
deny all;<br />
return 404;<br />
}<br />
}</pre><br />
And, restart your nginx service<br />
<pre>root@repo:~# service nginx restart<br />
* Restarting nginx nginx<br />
...done.</pre><br />
<br />
==Creating a local repository using an Ubuntu OS==<br />
Pending<br />
===Installing Python===<br />
Pending<br />
===Installing Amazon Web Services CLI===<br />
Pending<br />
===Cloning the packages from our Official Repository ===<br />
Pending<br />
====Cloning the packages for Ubuntu====<br />
Pending<br />
====Cloning the packages for RHEL/CentOS====<br />
Pending<br />
===Installing & configuring Nginx===<br />
Pending<br />
<br />
=How to configure the Zimbra Server=<br />
In this demo scenario, will install a new Zimbra Collaboration server<br />
<br />
==Configure the sources list==<br />
You must add your local repository to your Ubuntu Configuration, please note you must change '''trusty''' (Ubuntu 14.04) for '''precise''' if you are running Ubuntu 12.04:<br />
<pre>root@zimbra86:~/# vi /etc/apt/sources.list.d/zimbra-mirror.list<br />
deb [arch=amd64] https://repo.zimbra.io/apt/87 trusty zimbra<br />
deb-src [arch=amd64] https://repo.zimbra.io/apt/87 trusty zimbra</pre><br />
<br />
==Adding the Zimbra Repository key==<br />
You must add the next Zimbra key to the apt keychain<br />
<pre>root@zimbra86:~# apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 9BE6ED79<br />
Executing: gpg --ignore-time-conflict --no-options --no-default-keyring --homedir /tmp/tmp.FfpLxMcUiQ --no-auto-check-trustdb --trust-model always --keyring /etc/apt/trusted.gpg --primary-keyring /etc/apt/trusted.gpg --keyserver keyserver.ubuntu.com --recv-keys 9BE6ED79<br />
gpg: requesting key 9BE6ED79 from hkp server keyserver.ubuntu.com<br />
gpg: key 9BE6ED79: public key "Zimbra Packaging Services <packaging-devel@zimbra.com>" imported<br />
gpg: Total number processed: 1<br />
gpg: imported: 1 (RSA: 1)</pre><br />
<br />
==Check if the Zimbra Server is ready==<br />
You can check if everything is alright by running the next commands, where you can search by one Zimbra package:<br />
<pre>apt-get update<br />
<pre>root@zimbra86:~# aptitude search zimbra-nginx<br />
p zimbra-nginx - nginx Binaries <br />
p zimbra-nginx-dbg - nginx binary debug information</pre><br />
<br />
==Installing Zimbra Collaboration 8.7==<br />
Last but not least, download the Zimbra Collaboration 8.7 package and run the '''./install.sh''' as usual.<br />
*Note: You will not need to install the OS dependencies like in the past, the new Zimbra Collaboration 8.7 installation script take care of it<br />
<br />
During the question about use '''Zimbra's package repository''', '''type N''', so the system will use your local repository<br />
Use Zimbra's package repository [Y] n<br />
<br />
The installation will continue as usual, and will finish properly.<br />
<br />
=Keep the local Repository up to date=<br />
The challenge while using local repository is keep it up to date, you must run the next commands always before run any upgrade or update on the Zimbra Servers<br />
/usr/local/bin/aws s3 sync s3://repo.zimbra.com/apt/87 ./apt/87 --no-sign-request --delete<br />
/usr/local/bin/aws s3 sync s3://repo.zimbra.com/rpm/87 ./rpm/87 --no-sign-request --delete<br />
<br />
'''*Note: You can create a simple bash script and cron it every day, for example.'''<br />
=Known issues=<br />
==SSL issues==<br />
This error it's not related to Zimbra, but sometimes if you don't have a valid CA, or the CA is missing in the .crt file that you use for Nginx, when run apt-get update on the Zimbra server you can see the next error:<br />
W: Failed to fetch https://repo.zimbra.io/87/dists/precise/zimbra/source/Sources server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none<br />
You can fix it by adding your CA inside the '''/etc/ssl/certs/ca-certificates.crt''' on the Zimbra server</div>Gren Elliothttps://wiki.zimbra.com/index.php?title=Zimbra_Collaboration_repository&diff=61577Zimbra Collaboration repository2016-04-04T17:42:03Z<p>Gren Elliot: /* How to create a local repository */</p>
<hr />
<div>{{BC|Community Sandbox}}<br />
__FORCETOC__<br />
<div class="col-md-12 ibox-content"><br />
=Zimbra Collaboration Repository=<br />
{{KB|{{Unsupported}}|{{ZCS 8.7}}|||}}<br />
<br />
=How it works=<br />
Starting in Zimbra Collaboration 8.7, Zimbra uses repositories for 3rd party packages, in the first step towards having the whole product fully install-able from repositories.<br />
<br />
[[File:Zimbra-repository.png|1024px]]<br />
<br />
=How to create a local repository=<br />
Many Customers might not allow Internet access from their servers to the Internet, so Zimbra's 8.7 installation tools will not be able to reach the Zimbra repository and be able to finish the Installation.<br />
<br />
In order to successfully install Zimbra 8.7 within such customers' networks, this Wiki will cover all the steps needed to create a local Zimbra mirror where a Company can clone our repo, and the rest of the internal servers will take the needed packages locally from the mirror server, you can see an example on the above image, in section B.<br />
<br />
==Creating a local repository using an Ubuntu OS==<br />
Follow these steps to create a local repository or mirror using Ubuntu OS for the dedicated server.<br />
<br />
First step will be sure we have the latest packages:<br />
apt-get update<br />
===Installing Python===<br />
Then we need to install the python packages:<br />
apt-get install python-pip<br />
<br />
===Installing Amazon Web Services CLI===<br />
Once we have installed python, it's time to install the Amazon Web Services CLI, by running the next command<br />
pip install awscli<br />
<br />
===Cloning the packages from our Official Repository ===<br />
It's time to download all the packages from our official Repository to the local folder, first step it's create the local folder<br />
root@repo:~#mkdir /var/repositories<br />
root@repo:~#cd /var/repositories<br />
====Cloning the packages for Ubuntu====<br />
If you are planning to install Zimbra on your Ubuntu VM/Servers, then run the next command to download the Ubuntu packages:<br />
root@repo:~# /usr/local/bin/aws s3 sync s3://repo.zimbra.com/apt/87 ./apt/87 --no-sign-request --delete<br />
====Cloning the packages for RHEL/CentOS====<br />
If you are planning to install Zimbra on your RHEL/CentOS VM/Servers, then run the next command to download the RHEL/CentOS packages:<br />
/usr/local/bin/aws s3 sync s3://repo.zimbra.com/rpm/87 ./rpm/87 --no-sign-request --delete<br />
<br />
===Installing & configuring Nginx===<br />
Then we need to serve the packages using nginx, let's start for the basic steps to install nginx:<br />
root@repo:~# apt-get install nginx<br />
<br />
Zimbra strongly recommends to use a valid SSL certificate for the repository server, put the '''zimbra-wilcard.crt''' (must contain the CRT and the CA) and the '''zimbra-wilcard.key''' inside the next folder:<br />
root@repo:~# mkdir /etc/nginx/certs<br />
Let's go now to configure our Nginx server, first backup the default config and create a new one:<br />
root@repo:~# mv /etc/nginx/sites-available/default /etc/nginx/sites-available/default.bak<br />
root@repo:~# touch /etc/nginx/sites-available/default<br />
You can use the next example to fill your Repository configuration<br />
<pre>root@repo:~# vi /etc/nginx/sites-available/default<br />
server {<br />
listen 443 ssl;<br />
ssl_certificate /etc/nginx/certs/zimbra-wilcard.crt;<br />
ssl_certificate_key /etc/nginx/certs/zimbra-wilcard.key;<br />
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;<br />
ssl_ciphers HIGH:!aNULL:!MD5;<br />
## Let your repository be the root directory<br />
root /var/repositories;<br />
<br />
## Always good to log<br />
access_log /var/log/nginx/repo.access.log;<br />
error_log /var/log/nginx/repo.error.log;<br />
<br />
## Prevent access to Reprepro's files<br />
location ~ /(db|conf) {<br />
deny all;<br />
return 404;<br />
}<br />
}</pre><br />
And, restart your nginx service<br />
<pre>root@repo:~# service nginx restart<br />
* Restarting nginx nginx<br />
...done.</pre><br />
<br />
==Creating a local repository using an Ubuntu OS==<br />
Pending<br />
===Installing Python===<br />
Pending<br />
===Installing Amazon Web Services CLI===<br />
Pending<br />
===Cloning the packages from our Official Repository ===<br />
Pending<br />
====Cloning the packages for Ubuntu====<br />
Pending<br />
====Cloning the packages for RHEL/CentOS====<br />
Pending<br />
===Installing & configuring Nginx===<br />
Pending<br />
<br />
=How to configure the Zimbra Server=<br />
In this demo scenario, will install a new Zimbra Collaboration server<br />
<br />
==Configure the sources list==<br />
You must add your local repository to your Ubuntu Configuration, please note you must change '''trusty''' (Ubuntu 14.04) for '''precise''' if you are running Ubuntu 12.04:<br />
<pre>root@zimbra86:~/# vi /etc/apt/sources.list.d/zimbra-mirror.list<br />
deb [arch=amd64] https://repo.zimbra.io/apt/87 trusty zimbra<br />
deb-src [arch=amd64] https://repo.zimbra.io/apt/87 trusty zimbra</pre><br />
<br />
==Adding the Zimbra Repository key==<br />
You must add the next Zimbra key to the apt keychain<br />
<pre>root@zimbra86:~# apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 9BE6ED79<br />
Executing: gpg --ignore-time-conflict --no-options --no-default-keyring --homedir /tmp/tmp.FfpLxMcUiQ --no-auto-check-trustdb --trust-model always --keyring /etc/apt/trusted.gpg --primary-keyring /etc/apt/trusted.gpg --keyserver keyserver.ubuntu.com --recv-keys 9BE6ED79<br />
gpg: requesting key 9BE6ED79 from hkp server keyserver.ubuntu.com<br />
gpg: key 9BE6ED79: public key "Zimbra Packaging Services <packaging-devel@zimbra.com>" imported<br />
gpg: Total number processed: 1<br />
gpg: imported: 1 (RSA: 1)</pre><br />
<br />
==Check if the Zimbra Server is ready==<br />
You can check if everything is alright by running the next commands, where you can search by one Zimbra package:<br />
<pre>apt-get update<br />
<pre>root@zimbra86:~# aptitude search zimbra-nginx<br />
p zimbra-nginx - nginx Binaries <br />
p zimbra-nginx-dbg - nginx binary debug information</pre><br />
<br />
==Installing Zimbra Collaboration 8.7==<br />
Last but not least, download the Zimbra Collaboration 8.7 package and run the '''./install.sh''' as usual.<br />
*Note: You will not need to install the OS dependencies like in the past, the new Zimbra Collaboration 8.7 installation script take care of it<br />
<br />
During the question about use '''Zimbra's package repository''', '''type N''', so the system will use your local repository<br />
Use Zimbra's package repository [Y] n<br />
<br />
The installation will continue as usual, and will finish properly.<br />
<br />
=Keep the local Repository up to date=<br />
The challenge while using local repository is keep it up to date, you must run the next commands always before run any upgrade or update on the Zimbra Servers<br />
/usr/local/bin/aws s3 sync s3://repo.zimbra.com/apt/87 ./apt/87 --no-sign-request --delete<br />
/usr/local/bin/aws s3 sync s3://repo.zimbra.com/rpm/87 ./rpm/87 --no-sign-request --delete<br />
<br />
'''*Note: You can create a simple bash script and cron it every day, for example.'''<br />
=Known issues=<br />
==SSL issues==<br />
This error it's not related to Zimbra, but sometimes if you don't have a valid CA, or the CA is missing in the .crt file that you use for Nginx, when run apt-get update on the Zimbra server you can see the next error:<br />
W: Failed to fetch https://repo.zimbra.io/87/dists/precise/zimbra/source/Sources server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none<br />
You can fix it by adding your CA inside the '''/etc/ssl/certs/ca-certificates.crt''' on the Zimbra server</div>Gren Elliothttps://wiki.zimbra.com/index.php?title=Zimbra_Collaboration_repository&diff=61576Zimbra Collaboration repository2016-04-04T17:37:26Z<p>Gren Elliot: /* How it works */</p>
<hr />
<div>{{BC|Community Sandbox}}<br />
__FORCETOC__<br />
<div class="col-md-12 ibox-content"><br />
=Zimbra Collaboration Repository=<br />
{{KB|{{Unsupported}}|{{ZCS 8.7}}|||}}<br />
<br />
=How it works=<br />
Starting in Zimbra Collaboration 8.7, Zimbra uses repositories for 3rd party packages, in the first step towards having the whole product fully install-able from repositories.<br />
<br />
[[File:Zimbra-repository.png|1024px]]<br />
<br />
=How to create a local repository=<br />
We understand that many Customers might not allow the Internet access from the servers to Internet, so the Zimbra's 8.7 installation will not be able to reach the Zimbra repository and be able to finish the Installation. For that reason, this Wiki will cover all the steps to create a local Zimbra mirror where a Company can clone our repo, and the rest of the internal servers will take the needed packages locally from the mirror server, you can see an example on the above image, in the section B.<br />
<br />
==Creating a local repository using an Ubuntu OS==<br />
Follow these steps to create a local repository or mirror using Ubuntu OS for the dedicated server.<br />
<br />
First step will be sure we have the latest packages:<br />
apt-get update<br />
===Installing Python===<br />
Then we need to install the python packages:<br />
apt-get install python-pip<br />
<br />
===Installing Amazon Web Services CLI===<br />
Once we have installed python, it's time to install the Amazon Web Services CLI, by running the next command<br />
pip install awscli<br />
<br />
===Cloning the packages from our Official Repository ===<br />
It's time to download all the packages from our official Repository to the local folder, first step it's create the local folder<br />
root@repo:~#mkdir /var/repositories<br />
root@repo:~#cd /var/repositories<br />
====Cloning the packages for Ubuntu====<br />
If you are planning to install Zimbra on your Ubuntu VM/Servers, then run the next command to download the Ubuntu packages:<br />
root@repo:~# /usr/local/bin/aws s3 sync s3://repo.zimbra.com/apt/87 ./apt/87 --no-sign-request --delete<br />
====Cloning the packages for RHEL/CentOS====<br />
If you are planning to install Zimbra on your RHEL/CentOS VM/Servers, then run the next command to download the RHEL/CentOS packages:<br />
/usr/local/bin/aws s3 sync s3://repo.zimbra.com/rpm/87 ./rpm/87 --no-sign-request --delete<br />
<br />
===Installing & configuring Nginx===<br />
Then we need to serve the packages using nginx, let's start for the basic steps to install nginx:<br />
root@repo:~# apt-get install nginx<br />
<br />
Zimbra strongly recommends to use a valid SSL certificate for the repository server, put the '''zimbra-wilcard.crt''' (must contain the CRT and the CA) and the '''zimbra-wilcard.key''' inside the next folder:<br />
root@repo:~# mkdir /etc/nginx/certs<br />
Let's go now to configure our Nginx server, first backup the default config and create a new one:<br />
root@repo:~# mv /etc/nginx/sites-available/default /etc/nginx/sites-available/default.bak<br />
root@repo:~# touch /etc/nginx/sites-available/default<br />
You can use the next example to fill your Repository configuration<br />
<pre>root@repo:~# vi /etc/nginx/sites-available/default<br />
server {<br />
listen 443 ssl;<br />
ssl_certificate /etc/nginx/certs/zimbra-wilcard.crt;<br />
ssl_certificate_key /etc/nginx/certs/zimbra-wilcard.key;<br />
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;<br />
ssl_ciphers HIGH:!aNULL:!MD5;<br />
## Let your repository be the root directory<br />
root /var/repositories;<br />
<br />
## Always good to log<br />
access_log /var/log/nginx/repo.access.log;<br />
error_log /var/log/nginx/repo.error.log;<br />
<br />
## Prevent access to Reprepro's files<br />
location ~ /(db|conf) {<br />
deny all;<br />
return 404;<br />
}<br />
}</pre><br />
And, restart your nginx service<br />
<pre>root@repo:~# service nginx restart<br />
* Restarting nginx nginx<br />
...done.</pre><br />
<br />
==Creating a local repository using an Ubuntu OS==<br />
Pending<br />
===Installing Python===<br />
Pending<br />
===Installing Amazon Web Services CLI===<br />
Pending<br />
===Cloning the packages from our Official Repository ===<br />
Pending<br />
====Cloning the packages for Ubuntu====<br />
Pending<br />
====Cloning the packages for RHEL/CentOS====<br />
Pending<br />
===Installing & configuring Nginx===<br />
Pending<br />
<br />
=How to configure the Zimbra Server=<br />
In this demo scenario, will install a new Zimbra Collaboration server<br />
<br />
==Configure the sources list==<br />
You must add your local repository to your Ubuntu Configuration, please note you must change '''trusty''' (Ubuntu 14.04) for '''precise''' if you are running Ubuntu 12.04:<br />
<pre>root@zimbra86:~/# vi /etc/apt/sources.list.d/zimbra-mirror.list<br />
deb [arch=amd64] https://repo.zimbra.io/apt/87 trusty zimbra<br />
deb-src [arch=amd64] https://repo.zimbra.io/apt/87 trusty zimbra</pre><br />
<br />
==Adding the Zimbra Repository key==<br />
You must add the next Zimbra key to the apt keychain<br />
<pre>root@zimbra86:~# apt-key adv --keyserver keyserver.ubuntu.com --recv-keys 9BE6ED79<br />
Executing: gpg --ignore-time-conflict --no-options --no-default-keyring --homedir /tmp/tmp.FfpLxMcUiQ --no-auto-check-trustdb --trust-model always --keyring /etc/apt/trusted.gpg --primary-keyring /etc/apt/trusted.gpg --keyserver keyserver.ubuntu.com --recv-keys 9BE6ED79<br />
gpg: requesting key 9BE6ED79 from hkp server keyserver.ubuntu.com<br />
gpg: key 9BE6ED79: public key "Zimbra Packaging Services <packaging-devel@zimbra.com>" imported<br />
gpg: Total number processed: 1<br />
gpg: imported: 1 (RSA: 1)</pre><br />
<br />
==Check if the Zimbra Server is ready==<br />
You can check if everything is alright by running the next commands, where you can search by one Zimbra package:<br />
<pre>apt-get update<br />
<pre>root@zimbra86:~# aptitude search zimbra-nginx<br />
p zimbra-nginx - nginx Binaries <br />
p zimbra-nginx-dbg - nginx binary debug information</pre><br />
<br />
==Installing Zimbra Collaboration 8.7==<br />
Last but not least, download the Zimbra Collaboration 8.7 package and run the '''./install.sh''' as usual.<br />
*Note: You will not need to install the OS dependencies like in the past, the new Zimbra Collaboration 8.7 installation script take care of it<br />
<br />
During the question about use '''Zimbra's package repository''', '''type N''', so the system will use your local repository<br />
Use Zimbra's package repository [Y] n<br />
<br />
The installation will continue as usual, and will finish properly.<br />
<br />
=Keep the local Repository up to date=<br />
The challenge while using local repository is keep it up to date, you must run the next commands always before run any upgrade or update on the Zimbra Servers<br />
/usr/local/bin/aws s3 sync s3://repo.zimbra.com/apt/87 ./apt/87 --no-sign-request --delete<br />
/usr/local/bin/aws s3 sync s3://repo.zimbra.com/rpm/87 ./rpm/87 --no-sign-request --delete<br />
<br />
'''*Note: You can create a simple bash script and cron it every day, for example.'''<br />
=Known issues=<br />
==SSL issues==<br />
This error it's not related to Zimbra, but sometimes if you don't have a valid CA, or the CA is missing in the .crt file that you use for Nginx, when run apt-get update on the Zimbra server you can see the next error:<br />
W: Failed to fetch https://repo.zimbra.io/87/dists/precise/zimbra/source/Sources server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none<br />
You can fix it by adding your CA inside the '''/etc/ssl/certs/ca-certificates.crt''' on the Zimbra server</div>Gren Elliothttps://wiki.zimbra.com/index.php?title=Autodiscover&diff=61358Autodiscover2016-02-25T15:20:06Z<p>Gren Elliot: /* Identified Support/Known Issues */</p>
<hr />
<div>{{BC|Community Sandbox}}<br />
__FORCETOC__<br />
<div class="col-md-12 ibox-content"><br />
=Autodiscover for Outlook, Exchange Activesync and Exchange Web Services=<br />
{{KB|{{Unsupported}}|{{ZCS 8.6}}|{{ZCS 8.5}}|}}<br />
{{WIP}}<br />
Autodiscover uses the Network Edition features Exchange Activesync (EAS) and Exchange Web Services (EWS) to allow any Mail Client that supports Autodiscover to configure the appropriate Server settings for Communication, so you don’t have to input all the configuration manually. It’s very useful for IT Administrators and for all Users. <br />
Autodiscover also uses SSL certificates. For several years, Microsoft has recommended the use of Public domain names for Active Directory domains to avoid the use of non-public TLD like domain.local.<br />
<br />
==How does Autodiscover work?==<br />
Outlook, or the Mail App, has a few ways to look for domain information when configuring itself based on the user's email address. <br />
* 1. Post to '''https://example.com/Autodiscover/Autodiscover.xml'''<br />
* 2. Post to '''https://autodiscover.example.com/Autodiscover/Autodiscover.xml'''<br />
* 3. Same as the previous but in HTTP '''http://autodiscover.example.com/Autodiscover/Autodiscover.xml'''<br />
* 4. Autodiscover uses the DNS SRV lookup and will get the '''autodiscover.tcp.example.com''' that will reply to "'''mail.example.com'''"<br />
[[File:Autodiscover-th.png|960px]]<br />
===Example using just the DNS SRV record in Zimbra===<br />
Let's say I want to set up Outlook as john@example.com, but my site does not have the required Autodiscovery XML files set up. I enter that email address in Outlook, now Outlook does the following:<br />
* Autodiscover posts to '''https://example.com/Autodiscover/Autodiscover.xml'''. This fails.<br />
* Autodiscover posts to '''https://autodiscover.example.com/Autodiscover/Autodiscover.xml'''. This fails.<br />
* Autodiscover performs the following redirect check: GET '''http://autodiscover.example.com/Autodiscover/Autodiscover.xml'''. This fails.<br />
* Autodiscover uses DNS SRV lookup for '''autodiscover.tcp.example.com''', and then "'''mail.example.com'''" is returned.<br />
* Outlook asks permission from the user to continue with Autodiscover to post to '''https://mail.example.com/autodiscover/autodiscover.xml'''.<br />
* Autodiscover's POST request is successfully posted to '''https://mail.example.com/autodiscover/autodiscover.xml'''.<br />
<br />
==Creating the proper DNS entries==<br />
To set the proper DNS, you should have 2 different DNS entries.<br />
* The first one is a CNAME DNS entry pointing to the proper Zimbra FQDN, for example autodiscover.zimbra.io to zimbra86.zimbra.io. Please be aware that the SSL Certificate needs to have the autodiscover.zimbra.io inside using a Wildcard Certificate or a SAN for the record, or Autodiscover will fail in this step:<br />
<div class="thumbnail img-thumbnail">https://wiki.zimbra.com/images/c/c5/Autodiscover-DNS-001.png</div><br/><br />
'''If you are using CLI''', add the next into the domain ZONE file:<br />
autodiscover IN CNAME mail.example.com<br />
* The second DNS record that we need is the SRV one, with the Zimbra FQDN, the service, the protocol, the priority, the weight, the port, and the hostname. For example, using Bind you will need to add a DNS entry like the next one:<br />
<div class="thumbnail img-thumbnail">https://wiki.zimbra.com/images/c/ce/Autodiscover-DNS-002.png</div><br/><br />
'''Note:''' You can play with the priority and weight of the DNS record for an Autodiscovery HA based in DNS.<br />
'''If you are using CLI''', add the next into the domain ZONE file:<br />
_autodiscover._tcp IN SRV 0 0 443 mail.example.com<br />
<br />
==Check the Autodiscover using the DNS ==<br />
You can check if you have the proper DNS configuration using the regular DNS tools provided by your Operating System. This doesn't necessarily mean that your Autodiscover works in the Zimbra server, but at least you can see if you have properly configured your DNS Server.<br />
===In Microsoft Windows===<br />
You can test it in Microsoft Windows using nslookup, open a CMD, and introduce the next command to test your Autodiscover DNS record:<br />
nslookup -q=srv _autodiscover._tcp.example.com<br />
<div class="thumbnail img-thumbnail">https://wiki.zimbra.com/images/c/c1/Autodiscover-DNS-003.png</div><br/><br />
===In Linux/OS X===<br />
You can test it in Linux or OS X using dig, open a terminal/console, and introduce the next command to test your Autodiscover DNS record:<br />
dig _autodiscover._tcp.example.com SRV<br />
<div class="thumbnail img-thumbnail">https://wiki.zimbra.com/images/0/00/Autodiscover-DNS-004.png</div><br/><br />
<br />
==Check the Autodiscover using the Official Online Microsoft Tool==<br />
Microsoft has an Online tool where we can test the Autodiscovery, if needed: https://testconnectivity.microsoft.com/ <br />
<br />
===Check the Autodiscover for an EAS environment===<br />
'''Important note:''' You will receive an error if you do not enable the EAS functionality to the account you are testing. Enable the Mobile Sync Feature in the COS.<br />
<div class="thumbnail img-thumbnail">https://wiki.zimbra.com/images/a/ae/Autodiscover-005.png</div><br/><br />
<br />
You will see the next window, then select the option called '''Microsoft Exchange ActiveSync Connectivity Tests > Exchange ActiveSync Autodiscover'''<br />
<div class="thumbnail img-thumbnail">https://wiki.zimbra.com/images/a/aa/Autodiscover-006.png</div><br/><br />
<br />
In the next window, use an account where you can login into your Zimbra server to test Autodiscover. '''Note:''' Please use a test account that you can delete later, or use an account where you can change the password after this test.<br />
<div class="thumbnail img-thumbnail">https://wiki.zimbra.com/images/e/e2/Autodiscover-007.png</div><br/><br />
<br />
After a few seconds, you will be able to see the results. In this case everything seems to be OK:<br />
<div class="thumbnail img-thumbnail">https://wiki.zimbra.com/images/4/44/Autodiscover-008.png</div><br/><br />
<br />
If we click Expand All, we can see the steps that Autodiscover tried to work. As explained before, the only step that works here is the DNS one because:<br />
* First, in example.com I don't have the Zimbra Server, I have my regular Website.<br />
* Second, because autodiscover.example.com doesn't have the proper SSL certificate. I have a SSL certificate for mail.example.com for example.<br />
* Third, finally the DNS record is valid, and Outlook can use this method to get the configuration.<br />
<div class="thumbnail img-thumbnail">https://wiki.zimbra.com/images/1/16/Autodiscover-009.png</div><br/><br />
====The autodiscover Log trace for EAS====<br />
You can see under the /opt/zimbra/log/mailbox.log the attempt of the Autodiscover and the final OK response, you can see in the Autodiscover content the Exchange Activesync data:<br />
<pre>2015-08-04 18:32:34,804 INFO [qtp509886383-258:https://127.0.1.1:8443/Autodiscover/Autodiscover.xml] [oip=134.170.52.124;] AutoDiscoverServlet - Handling autodiscover request...<br />
2015-08-04 18:32:34,808 WARN [qtp509886383-258:https://127.0.1.1:8443/Autodiscover/Autodiscover.xml] [oip=134.170.52.124;] AutoDiscoverServlet - No basic auth header in the request<br />
2015-08-04 18:32:34,808 WARN [qtp509886383-258:https://127.0.1.1:8443/Autodiscover/Autodiscover.xml] [oip=134.170.52.124;] AutoDiscoverServlet - HTTP/1.1 401 Unauthorized<br />
2015-08-04 18:32:35,072 INFO [qtp509886383-258:https://127.0.1.1:8443/Autodiscover/Autodiscover.xml] [oip=134.170.52.124;] AutoDiscoverServlet - Handling autodiscover request...<br />
2015-08-04 18:32:35,081 INFO [qtp509886383-258:https://127.0.1.1:8443/Autodiscover/Autodiscover.xml] [oip=134.170.52.124;] AutoDiscoverServlet - Response: <?xml version="1.0"?><br />
<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><br />
<Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/mobilesync/responseschema/2006"><br />
<Culture>en:en</Culture><br />
<User><br />
<DisplayName>admin</DisplayName><br />
<EMailAddress>admin@zimbra.io</EMailAddress><br />
</User><br />
<Action><br />
<Settings><br />
<Server><br />
<Type>MobileSync</Type><br />
<Url>https://zimbra86.zimbra.io:8443/Microsoft-Server-ActiveSync</Url><br />
<Name>https://zimbra86.zimbra.io:8443/Microsoft-Server-ActiveSync</Name><br />
</Server><br />
</Settings><br />
</Action><br />
</Response><br />
</Autodiscover></pre><br />
<br />
2015-08-04 18:32:35,081 INFO [qtp509886383-258:https://127.0.1.1:8443/Autodiscover/Autodiscover.xml] [oip=134.170.52.124;] AutoDiscoverServlet - sending autodiscover response...<br />
<br />
===Check the Autodiscover for an EWS environment===<br />
'''Important note:''' You will receive an error if you will not enable the EWS functionality to the account you will test. You need to enable EWS Feature in the COS.<br />
'''Important note:''' EWS only works if you have the Proxy role installed and properly configured.<br />
<br />
<div class="thumbnail img-thumbnail">https://wiki.zimbra.com/images/5/5d/Autodiscover-004.png</div><br/><br />
<br />
You will see the next window, then select the option called '''Microsoft Office Outlook Connectivity Tests > Outlook Autodiscover'''<br />
<div class="thumbnail img-thumbnail">https://wiki.zimbra.com/images/1/16/Autodiscover-000.png</div><br/><br />
<br />
In the next Window, use an account where you can login into your Zimbra server to test Autodiscover. '''Note:''' Please use a test account that you can delete later, or use an account where you can change the password after this test.<br />
<br />
<div class="thumbnail img-thumbnail">https://wiki.zimbra.com/images/4/4c/Autodiscover-001.png</div><br/><br />
<br />
After a few seconds, you will be able to see the results. In this case everything seems to be OK:<br />
<div class="thumbnail img-thumbnail">https://wiki.zimbra.com/images/3/3c/Autodiscover-002.png</div><br/><br />
<br />
If we click Expand All, we can see the steps that Autodiscover tried to work. As explained before, the only step that works here is the DNS one because:<br />
* First, in example.com I don't have the Zimbra Server, I have my regular Website.<br />
* Second, because autodiscover.example.com doesn't have the proper SSL certificate. I have a SSL certificate for mail.example.com for example.<br />
* Third, finally the DNS record is valid, and Outlook can use this method to get the configuration.<br />
<div class="thumbnail img-thumbnail">https://wiki.zimbra.com/images/b/b1/Autodiscover-003.png</div><br/><br />
====The autodiscover Log trace for EWS====<br />
You can see under the /opt/zimbra/log/mailbox.log the attempt of the Autodiscover and the final OK response, you can see in the Autodiscover content the EWS data:<br />
<pre>2015-08-04 18:37:40,648 INFO [qtp509886383-286:https://127.0.1.1:8443/Autodiscover/Autodiscover.xml] [oip=134.170.52.123;] AutoDiscoverServlet - Handling autodiscover request...<br />
2015-08-04 18:37:40,654 WARN [qtp509886383-286:https://127.0.1.1:8443/Autodiscover/Autodiscover.xml] [oip=134.170.52.123;] AutoDiscoverServlet - cannot parse body: <br />
2015-08-04 18:37:40,654 WARN [qtp509886383-286:https://127.0.1.1:8443/Autodiscover/Autodiscover.xml] [oip=134.170.52.123;] AutoDiscoverServlet - HTTP/1.1 400 Body cannot be parsed<br />
2015-08-04 18:37:41,345 INFO [qtp509886383-288:https://127.0.1.1:8443/Autodiscover/Autodiscover.xml] [oip=134.170.52.123;] AutoDiscoverServlet - Handling autodiscover request...<br />
2015-08-04 18:37:41,354 WARN [qtp509886383-288:https://127.0.1.1:8443/Autodiscover/Autodiscover.xml] [oip=134.170.52.123;] AutoDiscoverServlet - No basic auth header in the request<br />
2015-08-04 18:37:41,354 WARN [qtp509886383-288:https://127.0.1.1:8443/Autodiscover/Autodiscover.xml] [oip=134.170.52.123;] AutoDiscoverServlet - HTTP/1.1 401 Unauthorized<br />
2015-08-04 18:37:41,611 INFO [qtp509886383-288:https://127.0.1.1:8443/Autodiscover/Autodiscover.xml] [oip=134.170.52.123;] AutoDiscoverServlet - Handling autodiscover request...<br />
2015-08-04 18:37:41,617 INFO [qtp509886383-288:https://127.0.1.1:8443/Autodiscover/Autodiscover.xml] [oip=134.170.52.123;] AutoDiscoverServlet - Response: <?xml version="1.0"?><br />
<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/responseschema/2006" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><br />
<Response xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a"><br />
<User><br />
<DisplayName>admin</DisplayName><br />
<EmailAddress>admin@zimbra.io</EmailAddress><br />
<DeploymentId>dacff30e-ee1d-4b5e-98f1-037a6a45dbfd</DeploymentId><br />
</User><br />
<Account><br />
<AccountType>email</AccountType><br />
<Action>settings</Action><br />
<Protocol><br />
<Type>EXCH</Type><br />
<EwsUrl>https://zimbra86.zimbra.io:8443/ews/Exchange.asmx</EwsUrl><br />
</Protocol><br />
</Account><br />
</Response><br />
</Autodiscover></pre><br />
<br />
==Configure the Mail Clients==<br />
Now that you have your Autodiscover properly configured, you can follow the next Articles to configure your Mail clients:<br />
* [[Windows_Mail_app_using_EAS_(Exchange_ActiveSync)|Windows Mail app using EAS (Exchange ActiveSync) in Windows 8, 8.1 and Windows 10]]<br />
* [[Outlook_2016_For_Mac_And_EWS_Setup|Outlook 2016 for Mac and EWS Setup]]<br />
* [[Exchange_ActiveSync(EAS)_Outlook_2013|Outlook 2013 using EAS (Exchange ActiveSync)]]<br />
* [[Ajcody-Outlook_2011_For_Mac_And_EWS_Setup|Outlook 2011 For Mac And EWS Setup With Screenshots]]<br />
<br />
==Identified Support/Known Issues==<br />
Known issues include the following bugs:<br />
* [https://bugzilla.zimbra.com/show_bug.cgi?id=85262 '''Bug 85262'''] - Admin: Add Appendix to Admin Guide which documents the various autodiscovery settings<br />
* The Zimbra Environment must have a properly configured setting for [[Enabling_Zimbra_Proxy#Documents_.26_Sharing|'''zimbraPublicServiceHostname''']] at the start in order for Autodiscover to be successfully configured.<br />
<br />
{{Article Footer|ZCS 8.6, 8.5|08/04/2015}}<br />
{{NeedSME|Jorge|SME2|Gayle B.}}<br />
<br />
[[Category:Certified]]<br />
[[Category:Mobile]]<br />
[[Category:ZCS 8.6]]<br />
[[Category:ZCS 8.5]]</div>Gren Elliothttps://wiki.zimbra.com/index.php?title=Installing_a_LetsEncrypt_SSL_Certificate&diff=61137Installing a LetsEncrypt SSL Certificate2015-12-07T17:06:27Z<p>Gren Elliot: /* Verify your commercial certificate. */</p>
<hr />
<div>{{BC|Community Sandbox}}<br />
__FORCETOC__<br />
<div class="col-md-12 ibox-content"><br />
=Installing a Let's Encrypt SSL Certificate=<br />
{{KB|{{Unsupported}}|{{ZCS 8.0}}|{{ZCS 7.0}}|}}<br />
{{WIP}}<br />
<br />
[[File:Letsencrypt-en.png|1024px]]<br />
<br />
==Purpose==<br />
Step by Step Wiki/KB article to install a Let's Encrypt Commercial Certificate. <br />
'''Disclaimer'''<br />
The Let’s Encrypt Client is '''BETA SOFTWARE'''. It contains plenty of bugs and rough edges, and it should be tested thoroughly in staging environments before use on production systems.<br />
For more information regarding the status of the project, please see https://letsencrypt.org. Be sure to check out the [https://community.letsencrypt.org/t/frequently-asked-questions-faq/26#topic-title Frequently Asked Questions (FAQ)].<br />
<br />
==Resolution==<br />
Let’s Encrypt is a new Certificate Authority: It’s free, automated, and open. It could be an option to protect Zimbra Servers with a valid SSL certificate; however, please be aware that is a Beta for now. Some stuff could not work or have issues, so use it at your own risk.<br />
<br />
===Installing Let's Encrypt on a Zimbra Server===<br />
Let's Encrypt must be installed on one Linux machine to obtain the proper SSL Certificate, CA Intermediate, and Private Key. It is not required that it be on the same Zimbra Server, but it could save time and help to obtain the renewals, etc.<br />
* First Step is to stop the jetty or nginx service at Zimbra level<br />
zmproxyctl stop<br />
zmmailboxdctl stop<br />
* Second step is to Install git on the Server (apt-get install git/yum install git), and then do a git clone of the project on the folder we want<br />
** Note: On RedHat/CentOS 6 you will need to enable the EPEL repository before install.<br />
git clone https://github.com/letsencrypt/letsencrypt<br />
cd letsencrypt<br />
* Let's now run Let's Encrypt in auto mode and use the certonly option, because for now the project can't automatically install the cert on Zimbra servers.<br />
root@zimbra86:~/tmp/letsencrypt# ./letsencrypt-auto certonly<br />
** (This step only happens the first time. This process will not occur when renewing the SSL Certificate if using the same machine.) The process will download all of the OS dependencies that Let's Encrypt needs, and after a few minutes:<br />
<pre>Creating virtual environment...<br />
Updating letsencrypt and virtual environment dependencies...../root/.local/share/letsencrypt/local/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/util/ssl_.py:90: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.<br />
InsecurePlatformWarning<br />
./root/.local/share/letsencrypt/local/lib/python2.7/site-packages/pip/_vendor/requests/packages/urllib3/util/ssl_.py:90: InsecurePlatformWarning: A true SSLContext object is not available. This prevents urllib3 from configuring SSL appropriately and may cause certain SSL connections to fail. For more information, see https://urllib3.readthedocs.org/en/latest/security.html#insecureplatformwarning.<br />
InsecurePlatformWarning<br />
</pre><br />
*** The process will ask for an Email Address in case of emergency contact or to recover the lost key.<br />
<br />
[[File:Letsencrypt-002.png]]<br />
<br />
*** The process will ask if we agree with the ToS.<br />
<br />
[[File:Letsencrypt-003.png]]<br />
<br />
**** In case we run a renewal, or a request for a new FQDN, the process will just take a few seconds.<br />
Updating letsencrypt and virtual environment dependencies.......<br />
Running with virtualenv: /root/.local/share/letsencrypt/bin/letsencrypt certonly<br />
*** Let's Encrypt will prompt for the domain to protect, in this lab case (zimbra86.zimbra.io):<br />
<br />
[[File:Letsencrypt-004.png]]<br />
<br />
* The process will take a few seconds to validate and then will end:<br />
<pre>IMPORTANT NOTES:<br />
- Congratulations! Your certificate and chain have been saved at<br />
/etc/letsencrypt/live/zimbra86.zimbra.io/fullchain.pem. Your cert<br />
will expire on 2016-03-04. To obtain a new version of the<br />
certificate in the future, simply run Let's Encrypt again.<br />
- If like Let's Encrypt, please consider supporting our work by:<br />
<br />
Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate<br />
Donating to EFF: https://eff.org/donate-le</pre><br />
<br />
===Where are the SSL Certificate Files?===<br />
You can find all your files under '''/etc/letsencrypt/live/$domain''', where $domain is the fqdn you used during the process:<br />
<pre>root@zimbra86:/etc/letsencrypt/live/zimbra86.zimbra.io# ls -al<br />
total 8<br />
drwxr-xr-x 2 root root 4096 Dec 5 16:46 .<br />
drwx------ 3 root root 4096 Dec 5 16:46 ..<br />
lrwxrwxrwx 1 root root 42 Dec 5 16:46 cert.pem -> ../../archive/zimbra86.zimbra.io/cert1.pem<br />
lrwxrwxrwx 1 root root 43 Dec 5 16:46 chain.pem -> ../../archive/zimbra86.zimbra.io/chain1.pem<br />
lrwxrwxrwx 1 root root 47 Dec 5 16:46 fullchain.pem -> ../../archive/zimbra86.zimbra.io/fullchain1.pem<br />
lrwxrwxrwx 1 root root 45 Dec 5 16:46 privkey.pem -> ../../archive/zimbra86.zimbra.io/privkey1.pem</pre><br />
<br />
===Build the proper Intermediate CA plus Root CA===<br />
Let's Encrypt is almost perfect, but during the files the process built, they just add the chain.pem file without the root CA.<br />
You must to use the IdenTrust root Certificate and merge it after the chain.pem<br />
* [https://www.identrust.com/certificates/trustid/root-download-x3.html https://www.identrust.com/certificates/trustid/root-download-x3.html]<br />
Your chain.pem should look like:<br />
<pre><br />
-----BEGIN CERTIFICATE-----<br />
MIIEqDCCA5CgAwIBAgIRAJgT9HUT5XULQ+dDHpceRL0wDQYJKoZIhvcNAQELBQAw<br />
PzEkMCIGA1UEChMbRGlnaXRhbCBTaWduYXR1cmUgVHJ1c3QgQ28uMRcwFQYDVQQD<br />
Ew5EU1QgUm9vdCBDQSBYMzAeFw0xNTEwMTkyMjMzMzZaFw0yMDEwMTkyMjMzMzZa<br />
MEoxCzAJBgNVBAYTAlVTMRYwFAYDVQQKEw1MZXQncyBFbmNyeXB0MSMwIQYDVQQD<br />
ExpMZXQncyBFbmNyeXB0IEF1dGhvcml0eSBYMTCCASIwDQYJKoZIhvcNAQEBBQAD<br />
ggEPADCCAQoCggEBAJzTDPBa5S5Ht3JdN4OzaGMw6tc1Jhkl4b2+NfFwki+3uEtB<br />
BaupnjUIWOyxKsRohwuj43Xk5vOnYnG6eYFgH9eRmp/z0HhncchpDpWRz/7mmelg<br />
PEjMfspNdxIknUcbWuu57B43ABycrHunBerOSuu9QeU2mLnL/W08lmjfIypCkAyG<br />
dGfIf6WauFJhFBM/ZemCh8vb+g5W9oaJ84U/l4avsNwa72sNlRZ9xCugZbKZBDZ1<br />
gGusSvMbkEl4L6KWTyogJSkExnTA0DHNjzE4lRa6qDO4Q/GxH8Mwf6J5MRM9LTb4<br />
4/zyM2q5OTHFr8SNDR1kFjOq+oQpttQLwNh9w5MCAwEAAaOCAZIwggGOMBIGA1Ud<br />
EwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMH8GCCsGAQUFBwEBBHMwcTAy<br />
BggrBgEFBQcwAYYmaHR0cDovL2lzcmcudHJ1c3RpZC5vY3NwLmlkZW50cnVzdC5j<br />
b20wOwYIKwYBBQUHMAKGL2h0dHA6Ly9hcHBzLmlkZW50cnVzdC5jb20vcm9vdHMv<br />
ZHN0cm9vdGNheDMucDdjMB8GA1UdIwQYMBaAFMSnsaR7LHH62+FLkHX/xBVghYkQ<br />
MFQGA1UdIARNMEswCAYGZ4EMAQIBMD8GCysGAQQBgt8TAQEBMDAwLgYIKwYBBQUH<br />
AgEWImh0dHA6Ly9jcHMucm9vdC14MS5sZXRzZW5jcnlwdC5vcmcwPAYDVR0fBDUw<br />
MzAxoC+gLYYraHR0cDovL2NybC5pZGVudHJ1c3QuY29tL0RTVFJPT1RDQVgzQ1JM<br />
LmNybDATBgNVHR4EDDAKoQgwBoIELm1pbDAdBgNVHQ4EFgQUqEpqYwR93brm0Tm3<br />
pkVl7/Oo7KEwDQYJKoZIhvcNAQELBQADggEBANHIIkus7+MJiZZQsY14cCoBG1hd<br />
v0J20/FyWo5ppnfjL78S2k4s2GLRJ7iD9ZDKErndvbNFGcsW+9kKK/TnY21hp4Dd<br />
ITv8S9ZYQ7oaoqs7HwhEMY9sibED4aXw09xrJZTC9zK1uIfW6t5dHQjuOWv+HHoW<br />
ZnupyxpsEUlEaFb+/SCI4KCSBdAsYxAcsHYI5xxEI4LutHp6s3OT2FuO90WfdsIk<br />
6q78OMSdn875bNjdBYAqxUp2/LEIHfDBkLoQz0hFJmwAbYahqKaLn73PAAm1X2kj<br />
f1w8DdnkabOLGeOVcj9LQ+s67vBykx4anTjURkbqZslUEUsn2k5xeua2zUk=<br />
-----END CERTIFICATE-----<br />
-----BEGIN CERTIFICATE-----<br />
MIIDSjCCAjKgAwIBAgIQRK+wgNajJ7qJMDmGLvhAazANBgkqhkiG9w0BAQUFADA/<br />
MSQwIgYDVQQKExtEaWdpdGFsIFNpZ25hdHVyZSBUcnVzdCBDby4xFzAVBgNVBAMT<br />
DkRTVCBSb290IENBIFgzMB4XDTAwMDkzMDIxMTIxOVoXDTIxMDkzMDE0MDExNVow<br />
PzEkMCIGA1UEChMbRGlnaXRhbCBTaWduYXR1cmUgVHJ1c3QgQ28uMRcwFQYDVQQD<br />
Ew5EU1QgUm9vdCBDQSBYMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB<br />
AN+v6ZdQCINXtMxiZfaQguzH0yxrMMpb7NnDfcdAwRgUi+DoM3ZJKuM/IUmTrE4O<br />
rz5Iy2Xu/NMhD2XSKtkyj4zl93ewEnu1lcCJo6m67XMuegwGMoOifooUMM0RoOEq<br />
OLl5CjH9UL2AZd+3UWODyOKIYepLYYHsUmu5ouJLGiifSKOeDNoJjj4XLh7dIN9b<br />
xiqKqy69cK3FCxolkHRyxXtqqzTWMIn/5WgTe1QLyNau7Fqckh49ZLOMxt+/yUFw<br />
7BZy1SbsOFU5Q9D8/RhcQPGX69Wam40dutolucbY38EVAjqr2m7xPi71XAicPNaD<br />
aeQQmxkqtilX4+U9m5/wAl0CAwEAAaNCMEAwDwYDVR0TAQH/BAUwAwEB/zAOBgNV<br />
HQ8BAf8EBAMCAQYwHQYDVR0OBBYEFMSnsaR7LHH62+FLkHX/xBVghYkQMA0GCSqG<br />
SIb3DQEBBQUAA4IBAQCjGiybFwBcqR7uKGY3Or+Dxz9LwwmglSBd49lZRNI+DT69<br />
ikugdB/OEIKcdBodfpga3csTS7MgROSR6cz8faXbauX+5v3gTt23ADq1cEmv8uXr<br />
AvHRAosZy5Q6XkjEGB5YGV8eAlrwDPGxrancWYaLbumR9YbK+rlmM6pZW87ipxZz<br />
R8srzJmwN0jP41ZL9c8PDHIyh8bwRLtTcm1D9SZImlJnt1ir/md2cXjbDaJWFBM5<br />
JDGFoqgCWjBH4d1QB7wCCZAA62RjYJsWvIjJEubSfZGL+T0yjWW06XyxV3bqxbYo<br />
Ob8VZRzI9neWagqNdwvYkQsEjgfbKbYK7p2CNTUQ<br />
-----END CERTIFICATE-----</pre><br />
<br />
===Verify your commercial certificate. ===<br />
Move to the Let's Encrypt folder with all files '''/etc/letsencrypt/live/$domain''' and then launch the next command as '''root''':<br />
<pre>root@zimbra86:/etc/letsencrypt/live/zimbra86.zimbra.io# /opt/zimbra/bin/zmcertmgr verifycrt comm privkey.pem cert.pem chain.pem <br />
** Verifying cert.pem against privkey.pem<br />
Certificate (cert.pem) and private key (privkey.pem) match.<br />
Valid Certificate: cert.pem: OK</pre><br />
<br />
===Deploy the new Let's Encrypt SSL certificate===<br />
====Copy the private key under Zimbra SSL path====<br />
Before deploying the SSL Certificate, you need to move the privkey.pem under the Zimbra SSL commercial path, like this:<br />
cp /etc/letsencrypt/live/zimbra86.zimbra.io/privkey.pem /opt/zimbra/ssl/zimbra/commercial/commercial.key<br />
<br />
====Final SSL deployment====<br />
Then deploy the certificate as follows: <br />
<pre>root@zimbra86:/etc/letsencrypt/live/zimbra86.zimbra.io# /opt/zimbra/bin/zmcertmgr deploycrt comm cert.pem chain.pem <br />
** Verifying cert.pem against /opt/zimbra/ssl/zimbra/commercial/commercial.key<br />
Certificate (cert.pem) and private key (/opt/zimbra/ssl/zimbra/commercial/commercial.key) match.<br />
Valid Certificate: cert.pem: OK<br />
** Copying cert.pem to /opt/zimbra/ssl/zimbra/commercial/commercial.crt<br />
** Appending ca chain chain.pem to /opt/zimbra/ssl/zimbra/commercial/commercial.crt<br />
** Importing certificate /opt/zimbra/ssl/zimbra/commercial/commercial_ca.crt to CACERTS as zcs-user-commercial_ca...done.<br />
** NOTE: mailboxd must be restarted in order to use the imported certificate.<br />
** Saving server config key zimbraSSLCertificate...failed.<br />
** Saving server config key zimbraSSLPrivateKey...failed.<br />
** Installing mta certificate and key...done.<br />
** Installing slapd certificate and key...done.<br />
** Installing proxy certificate and key...done.<br />
** Creating pkcs12 file /opt/zimbra/ssl/zimbra/jetty.pkcs12...done.<br />
** Creating keystore file /opt/zimbra/mailboxd/etc/keystore...done.<br />
** Installing CA to /opt/zimbra/conf/ca...done.</pre><br />
<br />
Then you need to restart the services, which will restart the nginx or jetty you stopped before:<br />
zmcontrol restart<br />
<br />
===Test the new SSL Certificate===<br />
The last step is to go to your Web Browser and open the URL of your Zimbra server where you installed the Let's Encrypt SSL Certificate:<br />
<br />
[[File:Letsencrypt-006.png|1024px]]<br />
<br />
You can expand the Certificate Information to see the new SSL Certificate your server is using:<br />
<br />
[[File:Letsencrypt-007.png]]<br />
<br />
===Building Multi-SAN SSL Certificate and complex scenarios===<br />
You can do almost everything you need, like Subject Alt Names, different domains, etc. But to see more about this, visit [https://letsencrypt.org/ the web of the official project].<br />
<br />
==Additional Content==<br />
* Let's Encrypt User Manual - https://letsencrypt.readthedocs.org/en/latest/using.html<br />
* Let's Encrypt Official Project - https://letsencrypt.org/<br />
<br />
{{Article Footer|Zimbra Collaboration 8.6, 8.5|12/05/2015}}<br />
{{NeedSME|Jorge|SME2|Copyeditor}}<br />
<br />
[[Category:Certificates]]</div>Gren Elliothttps://wiki.zimbra.com/index.php?title=Zimbra_to_Zimbra_Migration&diff=61080Zimbra to Zimbra Migration2015-11-05T10:07:09Z<p>Gren Elliot: /* Zimbra to Zimbra Migration */</p>
<hr />
<div>{{BC|Community Sandbox}}<br />
__FORCETOC__<br />
<div class="col-md-12 ibox-content"><br />
=Zimbra to Zimbra Migration=<br />
{{KB|{{Unsupported}}|{{ZCS 8.6}}|{{ZCS 8.5}}|{{ZCS 8.0}}}}<br />
{{WIP}}<br />
== Important Note ==<br />
The '''zmztozmig''' tool has very limited functionality and there are currently a number of known issues with it. Also there are much better ways to achieve what zmztozmig was originally intended to do.<br />
<br />
Therefore, Zimbra recommends '''NOT''' using this method, or any other method using the '''zmztomig''' tool. You can find more information in [http://bugzilla.zimbra.com/show_bug.cgi?id=101760 Bug 101760]<br />
<br />
== Introduction==<br />
Here are the recommended Articles you can use to migrate your Server:<br />
* https://wiki.zimbra.com/wiki/Ajcody-Notes-Server-Move<br />
* https://wiki.zimbra.com/wiki/Ajcody-Notes-Server-Move-32-To-64<br />
* https://wiki.zimbra.com/wiki/ZCS_to_ZCS_rsync_Migration<br />
<br />
Other Community articles using imapsync (just for IMAP)<br />
* https://wiki.zimbra.com/wiki/Mail_Migration<br />
* https://wiki.zimbra.com/wiki/Guide_to_imapsync<br />
* https://www.howtoforge.com/how-to-migrate-mailboxes-between-imap-servers-with-imapsync<br />
* https://www.youtube.com/watch?v=OlRKHZHs7Oo<br />
* https://xmission.com/blog/2015/09/09/migrate-your-email-from-google-apps-to-zimbra-collaboration?cid=tw<br />
<br />
=== Known Issues ===<br />
The zmztomig Tool has some Known Issues that must be considered before use it:<br />
* Personas will not be migrated<br />
* Identities will not be migrated<br />
* Domain Resources will not be migrated<br />
* COS will not be Migrated<br />
* User Preferences will not be migrated<br />
* Shared resources will not work after the migration and must be shared with all users again.<br />
* When you have Huge Mailboxes, the Tool often randomly fails to migrate some of the data. Please use the CURL export for these Mailboxes, and import them manually in the new Server.<br />
* More detailed issues in [http://bugzilla.zimbra.com/show_bug.cgi?id=101760 Bug 101760]<br />
<br />
== Importing Data between Different Version of ZCS servers using the Zimbra to Zimbra Migration Tool ==<br />
Use the Zimbra to Zimbra migration tool '''zmztozmig '''to import account data from one Zimbra Collaboration Server to another Zimbra Collaboration Server that is running a different version of ZCS. This tool can be used to import files from ZCS 6.0.6 or later to the latest version of ZCS. <br />
<br />
The process of migrating accounts to a ZCS server running a later version of ZCS includes:<br />
* Provisioning the accounts on the destination server before running zmztozmig <br />
* Editing the '''zmztozmig.conf''' file in '''/opt/zimbra/conf''' on the destination server to configure the import settings<br />
* Running '''zmztozmig '''to import the account’s data to the destination server<br />
<br />
When zmztozmig is used to import files, after the data is imported, the data in the accounts on the destination server are not an exact replica of the data in the accounts on the source server. <br />
And account preferences are not imported. Also, if the destination accounts do not have the same account IDs as they had on the source server, files that were shared and appointments related to the original sender might not work. <br />
<br />
'''Note:''' Since 7.1.3 Zimbra includes a new '''zmmboxmove''' command that has enhanced functionality of zmmailboxmove to handle cross mailstore version migrations (but not across ldap instance like zmztozmig). So, keep using '''zmmailboxmove''' or '''zmmboxmove''' to migrate accounts between accounts with the same LDAP Master.<br />
<br />
==Import and provision accounts from the source LDAP==<br />
1. The first step is to import all the accounts that you want to migrate from one server to another server. Here is an example of the environment:<br />
*Old Zimbra Collaboration Server (Could be ZCS 7.0 and above) - 192.168.211.20<br />
*New Zimbra Collaboration Server (For example with ZCS 8.6) - 192.168.211.129<br />
<br />
[[File:Zimbra-migration-001.png|800px|Zimbra to Zimbra Migration]]<br />
<br />
2. Log in on the Destination Server, and go to '''Tools & Migration''' > '''Account Migration''' > '''Migration Wizard'''.<br />
<br />
[[File:Zimbra-migration-002.png|800px|Zimbra to Zimbra Migration]]<br />
<br />
3. Select the options in the wizard and click '''Next''':<br />
* Type of mail server: '''Zimbra Collaboration Suite'''<br />
* Would you like to import account records? '''Yes'''<br />
* Would you like to import the mail? '''No'''<br />
<br />
[[File:Zimbra-migration-003.png|800px|Zimbra to Zimbra Migration]]<br />
<br />
4. Select the option '''Import from antoher Zimbra LDAP directory''' and click '''Next'''.<br />
<br />
[[File:Zimbra-migration-004.png|800px|Zimbra to Zimbra Migration]]<br />
<br />
5. Select the option that fits with your environment. For example:<br />
* Don't generate random passwords<br />
* Select to use the same password for all accounts<br />
* Require that the user needs to change their password after the first login<br />
* Select SMTP Host '''<- The best option here is don't put any SMTP Host here.'''<br />
<br />
[[File:Zimbra-migration-005.png|800px|Zimbra to Zimbra Migration]]<br />
<br />
This is the Configuration of the Source LDAP, be sure that you can access the source LDAP. Complete these fields with your own data:<br />
* LDAP URL: Can be a hostname of the source Zimbra Collaboration Server, or just the IP.<br />
* Bind DN: Should be per default '''uid=zimbra,cn=admins,cn=zimbra''' but just in case check in the source Zimbra Collaboration Server with the next command<br />
zmlocalconfig -s zimbra_ldap_userdn<br />
* Bind password: Run the next command in the source Zimbra Collaboration Server to obtain the password<br />
zmlocalconfig -s zimbra_ldap_password<br />
* LDAP Filter: Should be the default one, '''(objectclass=zimbraAccount)'''<br />
* LDAP search base: Add the domain or domains that you want to migrate, for example, '''dc=example,dc=com'''<br />
<br />
[[File:Zimbra-migration-006.png|800px|Zimbra to Zimbra Migration]]<br />
<br />
6. Be sure that all the accounts to migrate are in the next screen, these are taken automatically from the source Zimbra LDAP. Click Next, and the process starts. <br />
<br />
[[File:Zimbra-migration-007.png|800px|Zimbra to Zimbra Migration]]<br />
<br />
7. Click '''Next'''.<br />
<br />
[[File:Zimbra-migration-008.png|800px|Zimbra to Zimbra Migration]]<br />
<br />
8. '''Select accounts to import''' and click '''Next'''.<br />
<br />
[[File:Zimbra-migration-010.png|800px|Zimbra to Zimbra Migration]]<br />
<br />
9. Select the accounts that you want to migrate and click '''Next'''.<br />
<br />
[[File:Zimbra-migration-011.png|800px|Zimbra to Zimbra Migration]]<br />
<br />
10. Select the source '''Zimbra Collaboration Server IP''', the '''IMAP over SSL''', add an account and password with privileges, click '''Next'''.<br />
<br />
[[File:Zimbra-migration-012.png|800px|Zimbra to Zimbra Migration]]<br />
<br />
11. An overview of the accounts that will be migrated displays. Click '''Next''' and the wizard start the migration.<br />
<br />
[[File:Zimbra-migration-013.png|800px|Zimbra to Zimbra Migration]]<br />
<br />
[[File:Zimbra-migration-014.png|800px|Zimbra to Zimbra Migration]]<br />
<br />
12. The Progress screen displays errors, this is normal.<br />
<br />
[[File:Zimbra-migration-015.png|800px|Zimbra to Zimbra Migration]]<br />
<br />
13. If you return to the accounts view, all of the accounts are migrated, but the data is not migrated yet. <br />
<br />
[[File:Zimbra-migration-016.png|800px|Zimbra to Zimbra Migration]]<br />
<br />
==Preparing the zmztozmig.conf file ==<br />
Edit the '''zmztozmig.conf''' file in '''/opt/zimbra/conf''' on the destination server to configure the import settings. Account data, including email messages, attachments, contacts, calendar, tasks and briefcase folders for accounts are imported as individual account tgz tar files. <br />
'''Content of the Junk and Trash folders are not imported.''' <br />
<br />
The following information is configured in the file:<br />
<br />
* Login information of the source server<br />
* Login information of the destination server<br />
* Domain mapping from source server to destination server<br />
* Account import details, including which accounts’ to import from and what type of information should be imported<br />
* Record keeping information, including log directory, whether to keep the tar files after migration, directory for failed migration files<br />
* How to resolve account import conflicts ('''resolve''')<br />
* Number of mailboxes to import simultaneously ('''thread''')<br />
* (Optional) Changes to ZimbraMailTransport that may be required<br />
<br />
Following is a description of the parameters that are edited in the '''zmztozmig.conf''' file.<br />
''' '''<br />
{| style="background:#f0f0f0;color:black;width:100%;" border="1" cellpadding="10%" cellspacing="0%" border="1"<br />
<br />
! '''Parameter''' !! '''Description''' !! '''Entered as'''<br />
|- style="background:white; color:black"<br />
! '''SourceZCSServer'''<br />
| IP address or name of the source server.<br />
| '''SourceZCSServer=&lt;<nowiki>source.com</nowiki>&gt;'''<br />
|- style="background:#f0f0f0; color:black"<br />
! '''SourceAdminUser'''<br />
| ZCS administrator name for the source server.<br />
| '''SourceAdminUser=&lt;sourceadmin&gt;'''<br />
|- style="background:white; color:black"<br />
! '''SourceAdminPwd'''<br />
| ZCS administrator password for the source server.<br />
| '''SourceAdminPwd=&lt;adminpswrd&gt;'''<br />
|- style="background:#f0f0f0; color:black"<br />
! '''SourceAdminPort'''<br />
| Source server admin port - 7071<br />
| '''SourceAdminPort=&lt;port&gt;'''<br />
|- style="background:white; color:black"<br />
! '''TargetZCSServer'''<br />
| IP address or name of the destination server where the data is imported.<br />
| '''TargetZCSServer=&lt;<nowiki>destination.com</nowiki>&gt;'''<br />
|- style="background:#f0f0f0; color:black"<br />
! '''TargetAdminUser'''<br />
| ZCS administrator name for the destination server.<br />
| '''TargetAdminUser=&lt;targetadmin&gt;'''<br />
|- style="background:white; color:black"<br />
! '''TargetAdminPwd'''<br />
| ZCS administrator password for the destination server.<br />
| '''TargetAdminPwd=&lt;adminpswrd&gt;'''<br />
|- style="background:#f0f0f0; color:black"<br />
! '''TargetAdminPort'''<br />
| Destination server admin port- 7071.<br />
| '''TargetAdminPort=&lt;port&gt;'''<br />
|- style="background:white; color:black"<br />
! '''Threads''' <br />
| Set the number of accounts to be imported simultaneously. The default is 1.<br />
<br />
Set this at a low number of threads. When you start to import the data, review the source/destination ZCS server CPU usage I/O rate and write to disk per second. If the server has power to run more threads, you can edit the '''zmztozmig.conf''' file to increase the threads one at a time.<br />
<br />
| '''Threads=&lt;n&gt;'''<br />
<br />
|- style="background:#f0f0f0; color:black"<br />
! '''WorkingDirectory'''<br />
| The directory path to where the tar’d account data files are downloaded. <br />
| '''WorkingDirectory=/opt/zimbra/data/zmztozmig/work'''<br />
|- style="background:white; color:black"<br />
! '''FailedDirectory'''<br />
| The directory path to where tar’d account data files are moved if the account import fails.<br />
| '''FailedDirectory=/opt/zimbra/data/zmztozmig/failed'''<br />
|- style="background:#f0f0f0; color:black"<br />
! '''KeepSuccessFiles'''<br />
| '''KeepSuccessFiles''' is set to FALSE. The tar files are deleted after the data is imported. <br />
<br />
If you want to keep the downloaded tar files after they are imported, set this to TRUE.<br />
<br />
| '''KeepSuccessFiles=FALSE'''<br />
|- style="background:white; color:black"<br />
! '''SuccessDirectory'''<br />
| If you set '''KeepSuccessFiles''' to TRUE, identify the directory where tar’d account files are moved after successful imported. <br />
| '''SuccessDirectory=/opt/zimbra/data/zmztozmig/successes'''<br />
|- style="background:#f0f0f0; color:black"<br />
! '''LogDirectory'''<br />
| A common log file, '''ztozlog*.log''', is created for the complete import process and separate log file are created for each account data file that is imported. <br />
<br />
Configure the directory location where log files are saved.<br />
<br />
| '''LogDirectory=/opt/zimbra/data/zmztozmig/logs'''<br />
|- style="background:white; color:black"<br />
! '''DomainMap'''<br />
| If accounts are being migrated from one domain to another domain, specify the source domain and destination domain. <br />
<br />
You can create multiple DomainMap entries if the Accounts list contains accounts from different domains.<br />
<br />
| '''DomainMap=<nowiki>fromdomain.com</nowiki> <nowiki>todomain.com</nowiki>'''<br />
|- style="background:#f0f0f0; color:black"<br />
! '''Accounts'''<br />
| Specify which account’s data should be imported. This is a comma separated list of accounts. <br />
<br />
If data from all accounts on the source server should be imported, enter '''all'''. <br />
<br />
The Domains parameter must be set to list the domain from which the files are being imported.<br />
| '''Accounts=test1@<nowiki>example.com</nowiki>,test2@<nowiki>example.com</nowiki>'''<br />
'''Or'''<br />
'''Accounts=all'''<br />
|- style="background:white; color:black"<br />
!'''Domains'''<br />
| When the Accounts parameter is set to '''all''', identify the domains. <br />
| '''Domains=<nowiki>domain1.example.com</nowiki>, <nowiki>domain2.example.com</nowiki>'''<br />
|- style="background:#f0f0f0; color:black"<br />
! '''Types'''<br />
| Specify the type of data that should be imported. This is a comma separated list. <br />
<br />
To import all content, do not set any values for “types” Comment it out.<br />
<br />
| '''Types=message, conversation'''<br />
<br />
Types are:<br />
* message<br />
* conversation<br />
* contact<br />
* appointment<br />
* task<br />
* briefcase<br />
|- style="background:white; color:black"<br />
! '''Resolve'''<br />
| Use Resolve to determine how to resolve conflicts between the items being imported and the items already in the destination account. <br />
<br />
Only one value at a time can be set.<br />
<br />
Values:<br />
<br />
* '''Skip''' ignores duplicates<br />
* '''Modify''' updates older items<br />
* '''Reset''' deletes the older subfolders <br />
* '''Replace''' means replace the existing items with the items being imported<br />
<br />
| '''Resolve=skip'''<br />
<br />
<br />
|- style="background:#f0f0f0; color:black"<br />
! '''ZimbraMailTransport'''<br />
| Using '''ZimbraMailTransport''' is optional. <br />
<br />
Include this entry if you want to change the '''ZimbraMailTransport''' to some other MTA. <br />
| '''ZimbraMailTransport=smtp:<nowiki>mta.zcs.mail.mydomain.com</nowiki>'''<br />
|}<br />
<br />
==Example of zmztozmig.conf ==<br />
An example of the zmztozmig.conf file looks like:<br />
<br />
<pre>#Source ZCS server IP/name,admin user name and password, server port<br />
SourceZCSServer=192.168.211.20<br />
SourceAdminUser=admin<br />
SourceAdminPwd=PASSADMIN<br />
SourceAdminPort=7071<br />
#Destination/Target ZCS server IP/name,admin user name and password, server port<br />
TargetZCSServer=192.168.211.129<br />
TargetAdminUser=admin<br />
TargetAdminPwd=PASSADMIN<br />
TargetAdminPort=7071<br />
Threads=3<br />
WorkingDirectory=/tmp/ztozmig/mailboxdumps/<br />
FailedDirectory=/tmp/ztozmig/mailboxfailures/<br />
SuccessDirectory=/tmp/ztozmig/successes/<br />
LogDirectory=/opt/zimbra/log/ztozmiglogs<br />
KeepSuccessFiles=FALSE<br />
Domains=zimbra.local<br />
Accounts=all</pre><br />
<br />
==Import Account Data to the New Zimbra Server==<br />
Run the zmztozmig migration tool on the destination server as zimbra. <br />
<br />
'''/opt/zimbra/libexec/zmztozmig –f /opt/zimbra/conf<nowiki>/zmztozmig.co</nowiki>nf'''<br />
<br />
The data on the source server is zipped and imported to the destination server. If you configured '''KeepSuccessFiles''' to FALSE, the tgz file is deleted by default once the account data is imported. <br />
<br />
A common log file, ztozlog*.log, is created for the complete process and separate log files are created for data of each account that is imported. These should be saved until the new account data has been verified.<br />
<br />
This is the end of the import process. An overview of the migration displays:<br />
<pre>[INFO|main:1| 03/18/2015 20:34:57]: ****************SUMMARY************************** <br />
[INFO|main:1| 03/18/2015 20:34:57]: Total Accounts processed : 7 <br />
[INFO|main:1| 03/18/2015 20:34:57]: Successfull Accounts : 7 <br />
[INFO|main:1| 03/18/2015 20:34:57]: Failed accounts : 0 <br />
[INFO|main:1| 03/18/2015 20:34:57]: Total Migration Time(seconds) : 157.949 <br />
[INFO|main:1| 03/18/2015 20:34:57]: ************************************************* </pre><br />
<br />
==Check the differences between Zimbra Collaboration Servers==<br />
Now that everything is imported, check the differences between accounts, for example in the '''Mail''' Tab:<br />
<br />
[[File:Zimbra-migration-017.png|800px|Zimbra to Zimbra Migration]]<br />
<br />
Or, even in the '''Calendar''' Tab:<br />
<br />
[[File:Zimbra-migration-018.png|800px|Zimbra to Zimbra Migration]]<br />
<br />
Note that because the MailboxID is different after the migration, any shared resources will not work. Also, the zmztomig did not migrate the resources of the domain or the user preferences.<br />
<br />
After you verify that the account data was imported correctly, you can delete the account on the source server.<br />
<br />
{{Article_Footer|ZCS 8.6, 8.5, 8.0.x, 7.x |10/10/2011}}<br />
<br />
[[Category:Certified]]<br />
[[Category:Migration]]<br />
[[Category:ZCS 7.0]]<br />
[[Category:ZCS 6.0]]</div>Gren Elliothttps://wiki.zimbra.com/index.php?title=Free_Busy_Interop_for_Exchange&diff=60780Free Busy Interop for Exchange2015-09-15T16:17:30Z<p>Gren Elliot: /* Complex Exchange Environment */</p>
<hr />
<div>{{BC|Community Sandbox}}<br />
__FORCETOC__<br />
<div class="col-md-12 ibox-content"><br />
=Free Busy Interop for Exchange=<br />
{{KB|{{Unsupported}}|{{ZCS 7.0}}|{{ZCS 6.0}}|}}<br />
{{Archive}}{{WIP}}<br />
=Free/busy Provider Framework=<br />
Zimbra provides a framework where the interop with Exchange servers can be added via an extension. Through the extension, Zimbra server can query the free/busy schedule of users on Exchange servers and also propagate free/busy schedule of a Zimbra user to the Exchange server. <br />
<br />
=Interop with Exchange 2003=<br />
<br />
Zimbra server has a default implementation of Exchange free busy provider. The Zimbra server can pull the free/busy schedule of a user on Exchange, and also push the free/busy schedule of a Zimbra user to the Exchange server. The retrieval of free/busy (Exchange to Zimbra) is done via a REST interface<br />
on the Exchange server. The propagation of free/busy (Zimbra to Exchange) is done via WebDAV interface on the Exchange server. In both cases, Zimbra needs to authenticate to the Exchange server via HTTP basic authentication or HTML form based authentication ala OWA.<br />
<br />
In order to enable the default Exchange free busy interop implementation, the following conditions need to be met.<br />
<br />
# There should be a single AD in the system or Global Catalog is available.<br />
# Zimbra server can access HTTP(S) port of IIS on at least one of the Exchange server.<br />
# The Web interface to Exchange public folders <nowiki>(http://server/public/)</nowiki> needs to be available via IIS.<br />
# Zimbra users need to be provisioned as a contact on Active Directory using the same administrative group for each mail domain.<br />
# The Exchange username must be provisioned in the account attribute '''zimbraForeignPrincipal''' for all the Zimbra users.<br />
<br />
The conditions 4 and 5 are required only for Zimbra &rarr; Exchange free/busy replication. With the first three condition met, Exchange &rarr; Zimbra free/busy lookup is still possible.<br />
<br />
After creating the contacts, the '''legacyExchangeDN''' attribute can be verified by running ADSI Edit tool, open the contact object. Search for the attribute '''legacyExchangeDN''' for the contact. For example the attribute value would be:<br />
<br />
legacyExchangeDN : /o=First Organization/ou=First Administrative Group/cn=Recipients/cn=james<br />
<br />
The substrings left and right of '''/cn=Recipients''' are important, and need to be consistent across the Zimbra contacts. The left part '''/o=First Organization/ou=First Administrative Group''' corresponds to the domain attribute '''zimbraFreebusyExchangeUserOrg'''. The value of '''cn''' corresponds to the Exchange account name specified in '''zimbraForeignPrincipal'''.<br />
<br />
There are five global configuration variables on Zimbra to enable the interop with Exchange server.<br />
<br />
*zimbraFreebusyExchangeAuthUsername<br />
*zimbraFreebusyExchangeAuthPassword<br />
*zimbraFreebusyExchangeAuthScheme<br />
*zimbraFreebusyExchangeURL<br />
*zimbraFreebusyExchangeUserOrg<br />
<br />
The '''zimbraFreebusyExchangeAuthUsername''' and '''zimbraFreebusyExchangeAuthPassword''' attributes are used to authenticate against Exchange server on REST and WebDAV interface. <br />
The '''zimbraFreebusyExchangeAuthScheme''' attribute can be set to '''basic''' or '''form''', depending<br />
on how Exchange server is configured. When set to basic, Zimbra will attempt HTTP basic authentication. When set to form, it will POST HTML form to /exchweb/bin/auth/owaauth.dll to get the auth Cookie set. <br />
The '''zimbraFreebusyExchangeURL''' attribute should be set to the URL of the Exchange server. <br />
The '''zimbraFreebusyExchangeUserOrg''' attribute is the first part of the administrative group. Typically they are set to '''/o=First Organization/ou=First Administrative Group'''. Note that the value '''Org''' is from the '''legacyExchangeDN''' attribute of the user, not the DN of the user object.<br />
<br />
Use the '''zmprov''' CLI tool to set the global configuration variables. For example, assuming the user zimbra exists on the Exchange server on exchange.mycompany.com with the password '''changeme''':<br />
<br />
<pre><br />
# zmprov mcf zimbraFreebusyExchangeAuthUsername zimbra<br />
# zmprov mcf zimbraFreebusyExchangeAuthPassword changeme<br />
# zmprov mcf zimbraFreebusyExchangeAuthScheme basic<br />
# zmprov mcf zimbraFreebusyExchangeURL http://exchange.mycompany.com<br />
# zmprov mcf zimbraFreebusyExchangeUserOrg "/o=First Organization/ou=First Administrative Group"<br />
</pre><br />
<br />
Add the Zimbra account to Exchange account mapping to the '''zimbraForeignPrincipal''' attribute. Note that '''zimbraForeignPrincipal''' is a multi value attribute. Be careful not to wipe out the existing values when adding a new one. Use the prefix '''ad:''' in front of the Exchange account username to indicate the usage for Active Directory. <br />
<br />
# zmprov ma james@mycompany.com zimbraForeignPrincipal ad:james<br />
<br />
If there is more than one mail domain, '''zimbraFreebusyExchangeUserOrg''' can be set for each domain. <br />
<br />
# zmprov md anotherdomain.com zimbraFreebusyExchangeUserOrg "/o=AnotherDomain/ou=First Administrative Group"<br />
<br />
=Interop with Exchange 2007=<br />
<br />
See http://wiki.zimbra.com/index.php?title=Setting_Up_Free_Busy_Interop_with_Exchange_2007<br />
<br />
=Interop with Exchange 2010 and above with Exchange web Services=<br />
<br />
See http://wiki.zimbra.com/wiki/Setting_Up_Free_Busy_Interop_with_Exchange_2010<br />
<br />
=Complex Exchange Environment=<br />
<br />
If the Exchange environment does not meet the requirement for above, the default Exchange provider needs to be extended to work in such environment. Zimbra provides a Java interface.<br />
<br />
com.zimbra.cs.fb.ExchangeFreeBusyProvider.ExchangeUserResolver<br />
<br />
The interface requires one method.<br />
<br />
public ServerInfo getServerInfo(String emailAddr);<br />
<br />
The resolver implementation should take an email address of a user on AD, then return '''ServerInfo''' object. If the user is not found in AD it should return null. ServerInfo is defined as:<br />
<br />
<pre><br />
public static class ServerInfo {<br />
public boolean enabled;<br />
public String url;<br />
public String org;<br />
public String cn;<br />
public String authUsername;<br />
public String authPassword;<br />
public AuthScheme scheme;<br />
}<br />
</pre><br />
<br />
Finally, the bootstrapping of the exchange provider can be done via ZimbraExtension. Following is an example to illustrate how this<br />
can be implemented.<br />
<br />
<pre><br />
public class FbExtension implements ZimbraExtension {<br />
public void init() {<br />
ExchangeFreeBusyProvider.registerResolver(new ExchangeUserResolver() {<br />
public ServerInfo getServerInfo(String emailAddr) {<br />
ServerInfo info = new ServerInfo();<br />
info.url = "http://exchange.mycompany.com";<br />
info.authUsername = "zimbra";<br />
info.authPassword = "changeme";<br />
info.scheme = AuthScheme.basic;<br />
info.org = "/o=First Organization/ou=First Administrative Group";<br />
info.cn = emailAddr;<br />
if (emailAddr.indexOf('@') > 0)<br />
info.cn = emailAddr.substring(0, emailAddr.indexOf('@'));<br />
return info;<br />
}<br />
}, 0);<br />
}<br />
<br />
public void destroy() {<br />
}<br />
<br />
public String getName() {<br />
return "ExtensionFbProvider";<br />
}<br />
}<br />
</pre><br />
<br />
=Troubleshooting=<br />
See http://wiki.zimbra.com/index.php?title=Troubleshooting_Exchange_Freebusy_Interop<br />
<br />
<br />
{{Article Footer|5.0.3|10/15/2008}}<br />
<br />
[[Category: Administration]]<br />
[[Category:Configuration]]<br />
[[Category:Clients]]<br />
[[Category:Calendar]]<br />
[[Category:ZCS 5.0]]</div>Gren Elliothttps://wiki.zimbra.com/index.php?title=Free_Busy_Interop_for_Exchange&diff=60779Free Busy Interop for Exchange2015-09-15T16:15:46Z<p>Gren Elliot: /* Complex Exchange Environment */</p>
<hr />
<div>{{BC|Community Sandbox}}<br />
__FORCETOC__<br />
<div class="col-md-12 ibox-content"><br />
=Free Busy Interop for Exchange=<br />
{{KB|{{Unsupported}}|{{ZCS 7.0}}|{{ZCS 6.0}}|}}<br />
{{Archive}}{{WIP}}<br />
=Free/busy Provider Framework=<br />
Zimbra provides a framework where the interop with Exchange servers can be added via an extension. Through the extension, Zimbra server can query the free/busy schedule of users on Exchange servers and also propagate free/busy schedule of a Zimbra user to the Exchange server. <br />
<br />
=Interop with Exchange 2003=<br />
<br />
Zimbra server has a default implementation of Exchange free busy provider. The Zimbra server can pull the free/busy schedule of a user on Exchange, and also push the free/busy schedule of a Zimbra user to the Exchange server. The retrieval of free/busy (Exchange to Zimbra) is done via a REST interface<br />
on the Exchange server. The propagation of free/busy (Zimbra to Exchange) is done via WebDAV interface on the Exchange server. In both cases, Zimbra needs to authenticate to the Exchange server via HTTP basic authentication or HTML form based authentication ala OWA.<br />
<br />
In order to enable the default Exchange free busy interop implementation, the following conditions need to be met.<br />
<br />
# There should be a single AD in the system or Global Catalog is available.<br />
# Zimbra server can access HTTP(S) port of IIS on at least one of the Exchange server.<br />
# The Web interface to Exchange public folders <nowiki>(http://server/public/)</nowiki> needs to be available via IIS.<br />
# Zimbra users need to be provisioned as a contact on Active Directory using the same administrative group for each mail domain.<br />
# The Exchange username must be provisioned in the account attribute '''zimbraForeignPrincipal''' for all the Zimbra users.<br />
<br />
The conditions 4 and 5 are required only for Zimbra &rarr; Exchange free/busy replication. With the first three condition met, Exchange &rarr; Zimbra free/busy lookup is still possible.<br />
<br />
After creating the contacts, the '''legacyExchangeDN''' attribute can be verified by running ADSI Edit tool, open the contact object. Search for the attribute '''legacyExchangeDN''' for the contact. For example the attribute value would be:<br />
<br />
legacyExchangeDN : /o=First Organization/ou=First Administrative Group/cn=Recipients/cn=james<br />
<br />
The substrings left and right of '''/cn=Recipients''' are important, and need to be consistent across the Zimbra contacts. The left part '''/o=First Organization/ou=First Administrative Group''' corresponds to the domain attribute '''zimbraFreebusyExchangeUserOrg'''. The value of '''cn''' corresponds to the Exchange account name specified in '''zimbraForeignPrincipal'''.<br />
<br />
There are five global configuration variables on Zimbra to enable the interop with Exchange server.<br />
<br />
*zimbraFreebusyExchangeAuthUsername<br />
*zimbraFreebusyExchangeAuthPassword<br />
*zimbraFreebusyExchangeAuthScheme<br />
*zimbraFreebusyExchangeURL<br />
*zimbraFreebusyExchangeUserOrg<br />
<br />
The '''zimbraFreebusyExchangeAuthUsername''' and '''zimbraFreebusyExchangeAuthPassword''' attributes are used to authenticate against Exchange server on REST and WebDAV interface. <br />
The '''zimbraFreebusyExchangeAuthScheme''' attribute can be set to '''basic''' or '''form''', depending<br />
on how Exchange server is configured. When set to basic, Zimbra will attempt HTTP basic authentication. When set to form, it will POST HTML form to /exchweb/bin/auth/owaauth.dll to get the auth Cookie set. <br />
The '''zimbraFreebusyExchangeURL''' attribute should be set to the URL of the Exchange server. <br />
The '''zimbraFreebusyExchangeUserOrg''' attribute is the first part of the administrative group. Typically they are set to '''/o=First Organization/ou=First Administrative Group'''. Note that the value '''Org''' is from the '''legacyExchangeDN''' attribute of the user, not the DN of the user object.<br />
<br />
Use the '''zmprov''' CLI tool to set the global configuration variables. For example, assuming the user zimbra exists on the Exchange server on exchange.mycompany.com with the password '''changeme''':<br />
<br />
<pre><br />
# zmprov mcf zimbraFreebusyExchangeAuthUsername zimbra<br />
# zmprov mcf zimbraFreebusyExchangeAuthPassword changeme<br />
# zmprov mcf zimbraFreebusyExchangeAuthScheme basic<br />
# zmprov mcf zimbraFreebusyExchangeURL http://exchange.mycompany.com<br />
# zmprov mcf zimbraFreebusyExchangeUserOrg "/o=First Organization/ou=First Administrative Group"<br />
</pre><br />
<br />
Add the Zimbra account to Exchange account mapping to the '''zimbraForeignPrincipal''' attribute. Note that '''zimbraForeignPrincipal''' is a multi value attribute. Be careful not to wipe out the existing values when adding a new one. Use the prefix '''ad:''' in front of the Exchange account username to indicate the usage for Active Directory. <br />
<br />
# zmprov ma james@mycompany.com zimbraForeignPrincipal ad:james<br />
<br />
If there is more than one mail domain, '''zimbraFreebusyExchangeUserOrg''' can be set for each domain. <br />
<br />
# zmprov md anotherdomain.com zimbraFreebusyExchangeUserOrg "/o=AnotherDomain/ou=First Administrative Group"<br />
<br />
=Interop with Exchange 2007=<br />
<br />
See http://wiki.zimbra.com/index.php?title=Setting_Up_Free_Busy_Interop_with_Exchange_2007<br />
<br />
=Interop with Exchange 2010 and above with Exchange web Services=<br />
<br />
See http://wiki.zimbra.com/wiki/Setting_Up_Free_Busy_Interop_with_Exchange_2010<br />
<br />
=Complex Exchange Environment=<br />
<br />
If the Exchange environment does not meet the requirement for above, the default Exchange provider needs to be extended to work in such environment. Zimbra provides a Java interface.<br />
<br />
com.zimbra.cs.fb.ExchangeFreeBusyProvider.ExchangeUserResolver<br />
<br />
The interface requires one method.<br />
<br />
public ServerInfo getServerInfo(String emailAddr);<br />
<br />
The resolver implementation should take an email address of a user on AD, then return '''ServerInfo''' object. If the user is not found in AD it should return null. ServerInfo is defined as:<br />
<br />
<pre><br />
public static class ServerInfo {<br />
public String url;<br />
public String org;<br />
public String cn;<br />
public String authUsername;<br />
public String authPassword;<br />
public AuthScheme scheme; // basic or form<br />
}<br />
</pre><br />
<br />
Finally, the bootstrapping of the exchange provider can be done via ZimbraExtension. Following is an example to illustrate how this<br />
can be implemented.<br />
<br />
<pre><br />
public class FbExtension implements ZimbraExtension {<br />
public void init() {<br />
ExchangeFreeBusyProvider.registerResolver(new ExchangeUserResolver() {<br />
public ServerInfo getServerInfo(String emailAddr) {<br />
ServerInfo info = new ServerInfo();<br />
info.url = "http://exchange.mycompany.com";<br />
info.authUsername = "zimbra";<br />
info.authPassword = "changeme";<br />
info.scheme = AuthScheme.basic;<br />
info.org = "/o=First Organization/ou=First Administrative Group";<br />
info.cn = emailAddr;<br />
if (emailAddr.indexOf('@') > 0)<br />
info.cn = emailAddr.substring(0, emailAddr.indexOf('@'));<br />
return info;<br />
}<br />
}, 0);<br />
}<br />
<br />
public void destroy() {<br />
}<br />
<br />
public String getName() {<br />
return "ExtensionFbProvider";<br />
}<br />
}<br />
</pre><br />
<br />
=Troubleshooting=<br />
See http://wiki.zimbra.com/index.php?title=Troubleshooting_Exchange_Freebusy_Interop<br />
<br />
<br />
{{Article Footer|5.0.3|10/15/2008}}<br />
<br />
[[Category: Administration]]<br />
[[Category:Configuration]]<br />
[[Category:Clients]]<br />
[[Category:Calendar]]<br />
[[Category:ZCS 5.0]]</div>Gren Elliothttps://wiki.zimbra.com/index.php?title=Admin_Console_Performance_Issues_when_using_Delegated_Admin&diff=59191Admin Console Performance Issues when using Delegated Admin2015-05-05T10:16:49Z<p>Gren Elliot: /* short_term_grantee_cache_expiration */</p>
<hr />
<div>{{WIP}}<br />
<br />
'''Note''': This information is related to Bug 97743. <br />
<br />
== Overview ==<br />
If you are experiencing significant admin console performance issues when using delegated admin, configure the following LC keys to resolve the issue:<br />
<br />
* short_term_all_effective_rights_cache_expiration (default: 50000)<br />
* short_term_all_effective_rights_cache_size (default: 128)<br />
* short_term_grantee_cache_expiration (default: 50000)<br />
* short_term_grantee_cache_size (default: 128)<br />
<br />
'''Note''': The default sizes are 128, with default expirations in milliseconds. Using higher values is not recommended. These keys will be moved to LDAP for 8.7 and 9.0.<br />
<br />
<br />
== LC Key Descriptions: ==<br />
<br />
=== short_term_all_effective_rights_cache_expiration ===<br />
<br />
Maximum time an entry in the short term All Effective Rights cache will be regarded as valid.<br />
If value is 0, the cache is disabled.<br />
The cache is particularly useful when significant use is made of delegated administration.<br />
This cache can improve performance by avoiding recomputing All Effective Rights of named entries<br />
like accounts frequently in a short period of time.<br />
All Effective Rights are computations of the rights that named entries like accounts have - although when used, they are checked separately.<br />
<br />
The longer the value of this setting is, the more stale the view of the details is likely to be.<br />
For this reason, the maximum accepted value is 30m.<br />
Larger values will be treated as being 30m<br />
<br />
The default value is 50000 which is '''50s'''<br />
<br />
This will be replaced in 8.7 and 9.0 with the LDAP attribute:<br />
'''zimbraShortTermAllEffectiveRightsCacheExpiration'''<br />
<br />
=== short_term_all_effective_rights_cache_size ===<br />
<br />
Maximum number of entries in the short term All Effective Rights cache.<br />
This cache can improve performance by avoiding recomputing All Effective Rights of named entries like accounts frequently in a short period of time.<br />
Can disable the cache be specifying a value of 0<br />
<br />
The default value is '''128'''<br />
<br />
This will be replaced in 8.7 and 9.0 with the LDAP attribute: '''zimbraShortTermAllEffectiveRightsCacheSize'''<br />
<br />
=== short_term_grantee_cache_expiration ===<br />
Maximum time an entry in the Grantee cache will be regarded as valid.<br />
If value is 0, the cache is disabled.<br />
This cache can improve performance by avoiding recomputing details frequently in a short period of time, for instance for each entry in search results.<br />
<br />
The cache is particularly useful when significant use is made of delegated administration.<br />
Grantees objects provide a view of what rights a grantee has - although those are checked separately.<br />
<br />
The longer the value of this setting is, the more stale the view of the details is likely to be. For this reason, the maximum accepted value is 30m.<br />
Larger values will be treated as being 30m<br />
<br />
The default value is 50000 which is '''50s'''<br />
<br />
This will be replaced in 8.7 and 9.0 with the LDAP attribute: <br />
'''zimbraShortTermGranteeCacheExpiration'''<br />
<br />
=== short_term_grantee_cache_size ===<br />
<br />
Maximum number of entries in the short term Grantee cache.<br />
This cache can improve performance by avoiding recomputing details frequently in a short period of time, for instance for each entry in search results.<br />
Can disable the cache be specifying a value of 0<br />
<br />
The default value is '''128'''<br />
<br />
This will be replaced in 8.7 and 9.0 with the LDAP attribute: '''zimbraShortTermGranteeCacheSize'''</div>Gren Elliothttps://wiki.zimbra.com/index.php?title=Admin_Console_Performance_Issues_when_using_Delegated_Admin&diff=59190Admin Console Performance Issues when using Delegated Admin2015-05-05T10:16:32Z<p>Gren Elliot: /* short_term_all_effective_rights_cache_expiration */</p>
<hr />
<div>{{WIP}}<br />
<br />
'''Note''': This information is related to Bug 97743. <br />
<br />
== Overview ==<br />
If you are experiencing significant admin console performance issues when using delegated admin, configure the following LC keys to resolve the issue:<br />
<br />
* short_term_all_effective_rights_cache_expiration (default: 50000)<br />
* short_term_all_effective_rights_cache_size (default: 128)<br />
* short_term_grantee_cache_expiration (default: 50000)<br />
* short_term_grantee_cache_size (default: 128)<br />
<br />
'''Note''': The default sizes are 128, with default expirations in milliseconds. Using higher values is not recommended. These keys will be moved to LDAP for 8.7 and 9.0.<br />
<br />
<br />
== LC Key Descriptions: ==<br />
<br />
=== short_term_all_effective_rights_cache_expiration ===<br />
<br />
Maximum time an entry in the short term All Effective Rights cache will be regarded as valid.<br />
If value is 0, the cache is disabled.<br />
The cache is particularly useful when significant use is made of delegated administration.<br />
This cache can improve performance by avoiding recomputing All Effective Rights of named entries<br />
like accounts frequently in a short period of time.<br />
All Effective Rights are computations of the rights that named entries like accounts have - although when used, they are checked separately.<br />
<br />
The longer the value of this setting is, the more stale the view of the details is likely to be.<br />
For this reason, the maximum accepted value is 30m.<br />
Larger values will be treated as being 30m<br />
<br />
The default value is 50000 which is '''50s'''<br />
<br />
This will be replaced in 8.7 and 9.0 with the LDAP attribute:<br />
'''zimbraShortTermAllEffectiveRightsCacheExpiration'''<br />
<br />
=== short_term_all_effective_rights_cache_size ===<br />
<br />
Maximum number of entries in the short term All Effective Rights cache.<br />
This cache can improve performance by avoiding recomputing All Effective Rights of named entries like accounts frequently in a short period of time.<br />
Can disable the cache be specifying a value of 0<br />
<br />
The default value is '''128'''<br />
<br />
This will be replaced in 8.7 and 9.0 with the LDAP attribute: '''zimbraShortTermAllEffectiveRightsCacheSize'''<br />
<br />
=== short_term_grantee_cache_expiration ===<br />
Maximum time an entry in the Grantee cache will be regarded as valid.<br />
If value is 0, the cache is disabled.<br />
This cache can improve performance by avoiding recomputing details frequently in a short period of time, for instance for each entry in search results.<br />
<br />
The cache is particularly useful when significant use is made of delegated administration.<br />
Grantees objects provide a view of what rights a grantee has - although those are checked separately.<br />
<br />
The longer the value of this setting is, the more stale the view of the details is likely to be. For this reason, the maximum accepted value is 30m.<br />
Larger values will be treated as being 30m<br />
<br />
The default value is '''50s'''<br />
<br />
This will be replaced in 8.7 and 9.0 with the LDAP attribute: <br />
'''zimbraShortTermGranteeCacheExpiration'''<br />
<br />
=== short_term_grantee_cache_size ===<br />
<br />
Maximum number of entries in the short term Grantee cache.<br />
This cache can improve performance by avoiding recomputing details frequently in a short period of time, for instance for each entry in search results.<br />
Can disable the cache be specifying a value of 0<br />
<br />
The default value is '''128'''<br />
<br />
This will be replaced in 8.7 and 9.0 with the LDAP attribute: '''zimbraShortTermGranteeCacheSize'''</div>Gren Elliothttps://wiki.zimbra.com/index.php?title=Admin_Console_Performance_Issues_when_using_Delegated_Admin&diff=59189Admin Console Performance Issues when using Delegated Admin2015-05-05T10:15:31Z<p>Gren Elliot: /* short_term_grantee_cache_size */</p>
<hr />
<div>{{WIP}}<br />
<br />
'''Note''': This information is related to Bug 97743. <br />
<br />
== Overview ==<br />
If you are experiencing significant admin console performance issues when using delegated admin, configure the following LC keys to resolve the issue:<br />
<br />
* short_term_all_effective_rights_cache_expiration (default: 50000)<br />
* short_term_all_effective_rights_cache_size (default: 128)<br />
* short_term_grantee_cache_expiration (default: 50000)<br />
* short_term_grantee_cache_size (default: 128)<br />
<br />
'''Note''': The default sizes are 128, with default expirations in milliseconds. Using higher values is not recommended. These keys will be moved to LDAP for 8.7 and 9.0.<br />
<br />
<br />
== LC Key Descriptions: ==<br />
<br />
=== short_term_all_effective_rights_cache_expiration ===<br />
<br />
Maximum time an entry in the short term All Effective Rights cache will be regarded as valid.<br />
If value is 0, the cache is disabled.<br />
The cache is particularly useful when significant use is made of delegated administration.<br />
This cache can improve performance by avoiding recomputing All Effective Rights of named entries<br />
like accounts frequently in a short period of time.<br />
All Effective Rights are computations of the rights that named entries like accounts have - although when used, they are checked separately.<br />
<br />
The longer the value of this setting is, the more stale the view of the details is likely to be.<br />
For this reason, the maximum accepted value is 30m.<br />
Larger values will be treated as being 30m<br />
<br />
The default value is '''50s'''<br />
<br />
This will be replaced in 8.7 and 9.0 with the LDAP attribute:<br />
'''zimbraShortTermAllEffectiveRightsCacheExpiration'''<br />
<br />
=== short_term_all_effective_rights_cache_size ===<br />
<br />
Maximum number of entries in the short term All Effective Rights cache.<br />
This cache can improve performance by avoiding recomputing All Effective Rights of named entries like accounts frequently in a short period of time.<br />
Can disable the cache be specifying a value of 0<br />
<br />
The default value is '''128'''<br />
<br />
This will be replaced in 8.7 and 9.0 with the LDAP attribute: '''zimbraShortTermAllEffectiveRightsCacheSize'''<br />
<br />
=== short_term_grantee_cache_expiration ===<br />
Maximum time an entry in the Grantee cache will be regarded as valid.<br />
If value is 0, the cache is disabled.<br />
This cache can improve performance by avoiding recomputing details frequently in a short period of time, for instance for each entry in search results.<br />
<br />
The cache is particularly useful when significant use is made of delegated administration.<br />
Grantees objects provide a view of what rights a grantee has - although those are checked separately.<br />
<br />
The longer the value of this setting is, the more stale the view of the details is likely to be. For this reason, the maximum accepted value is 30m.<br />
Larger values will be treated as being 30m<br />
<br />
The default value is '''50s'''<br />
<br />
This will be replaced in 8.7 and 9.0 with the LDAP attribute: <br />
'''zimbraShortTermGranteeCacheExpiration'''<br />
<br />
=== short_term_grantee_cache_size ===<br />
<br />
Maximum number of entries in the short term Grantee cache.<br />
This cache can improve performance by avoiding recomputing details frequently in a short period of time, for instance for each entry in search results.<br />
Can disable the cache be specifying a value of 0<br />
<br />
The default value is '''128'''<br />
<br />
This will be replaced in 8.7 and 9.0 with the LDAP attribute: '''zimbraShortTermGranteeCacheSize'''</div>Gren Elliothttps://wiki.zimbra.com/index.php?title=Admin_Console_Performance_Issues_when_using_Delegated_Admin&diff=59188Admin Console Performance Issues when using Delegated Admin2015-05-05T10:14:06Z<p>Gren Elliot: /* short_term_grantee_cache_expiration */</p>
<hr />
<div>{{WIP}}<br />
<br />
'''Note''': This information is related to Bug 97743. <br />
<br />
== Overview ==<br />
If you are experiencing significant admin console performance issues when using delegated admin, configure the following LC keys to resolve the issue:<br />
<br />
* short_term_all_effective_rights_cache_expiration (default: 50000)<br />
* short_term_all_effective_rights_cache_size (default: 128)<br />
* short_term_grantee_cache_expiration (default: 50000)<br />
* short_term_grantee_cache_size (default: 128)<br />
<br />
'''Note''': The default sizes are 128, with default expirations in milliseconds. Using higher values is not recommended. These keys will be moved to LDAP for 8.7 and 9.0.<br />
<br />
<br />
== LC Key Descriptions: ==<br />
<br />
=== short_term_all_effective_rights_cache_expiration ===<br />
<br />
Maximum time an entry in the short term All Effective Rights cache will be regarded as valid.<br />
If value is 0, the cache is disabled.<br />
The cache is particularly useful when significant use is made of delegated administration.<br />
This cache can improve performance by avoiding recomputing All Effective Rights of named entries<br />
like accounts frequently in a short period of time.<br />
All Effective Rights are computations of the rights that named entries like accounts have - although when used, they are checked separately.<br />
<br />
The longer the value of this setting is, the more stale the view of the details is likely to be.<br />
For this reason, the maximum accepted value is 30m.<br />
Larger values will be treated as being 30m<br />
<br />
The default value is '''50s'''<br />
<br />
This will be replaced in 8.7 and 9.0 with the LDAP attribute:<br />
'''zimbraShortTermAllEffectiveRightsCacheExpiration'''<br />
<br />
=== short_term_all_effective_rights_cache_size ===<br />
<br />
Maximum number of entries in the short term All Effective Rights cache.<br />
This cache can improve performance by avoiding recomputing All Effective Rights of named entries like accounts frequently in a short period of time.<br />
Can disable the cache be specifying a value of 0<br />
<br />
The default value is '''128'''<br />
<br />
This will be replaced in 8.7 and 9.0 with the LDAP attribute: '''zimbraShortTermAllEffectiveRightsCacheSize'''<br />
<br />
=== short_term_grantee_cache_expiration ===<br />
Maximum time an entry in the Grantee cache will be regarded as valid.<br />
If value is 0, the cache is disabled.<br />
This cache can improve performance by avoiding recomputing details frequently in a short period of time, for instance for each entry in search results.<br />
<br />
The cache is particularly useful when significant use is made of delegated administration.<br />
Grantees objects provide a view of what rights a grantee has - although those are checked separately.<br />
<br />
The longer the value of this setting is, the more stale the view of the details is likely to be. For this reason, the maximum accepted value is 30m.<br />
Larger values will be treated as being 30m<br />
<br />
The default value is '''50s'''<br />
<br />
This will be replaced in 8.7 and 9.0 with the LDAP attribute: <br />
'''zimbraShortTermGranteeCacheExpiration'''<br />
<br />
=== short_term_grantee_cache_size ===<br />
<attr id="1900" name="zimbraShortTermGranteeCacheSize" type="integer" min="0" cardinality="single" optionalIn="globalConfig,server,alwaysOnCluster" flags="serverInherited,serverPreferAlwaysOn" affectsServices="all" since="8.7.0,9.0.0"><br />
<globalConfigValue>128</globalConfigValue><br />
<desc>Maximum number of entries in the short term Grantee cache.<br />
This cache can improve performance by avoiding recomputing details frequently in a short period of time, for instance for each entry in search results.<br />
Can disable the cache be specifying a value of 0<br />
</desc><br />
</attr></div>Gren Elliothttps://wiki.zimbra.com/index.php?title=Admin_Console_Performance_Issues_when_using_Delegated_Admin&diff=59187Admin Console Performance Issues when using Delegated Admin2015-05-05T10:11:42Z<p>Gren Elliot: /* short_term_all_effective_rights_cache_size */</p>
<hr />
<div>{{WIP}}<br />
<br />
'''Note''': This information is related to Bug 97743. <br />
<br />
== Overview ==<br />
If you are experiencing significant admin console performance issues when using delegated admin, configure the following LC keys to resolve the issue:<br />
<br />
* short_term_all_effective_rights_cache_expiration (default: 50000)<br />
* short_term_all_effective_rights_cache_size (default: 128)<br />
* short_term_grantee_cache_expiration (default: 50000)<br />
* short_term_grantee_cache_size (default: 128)<br />
<br />
'''Note''': The default sizes are 128, with default expirations in milliseconds. Using higher values is not recommended. These keys will be moved to LDAP for 8.7 and 9.0.<br />
<br />
<br />
== LC Key Descriptions: ==<br />
<br />
=== short_term_all_effective_rights_cache_expiration ===<br />
<br />
Maximum time an entry in the short term All Effective Rights cache will be regarded as valid.<br />
If value is 0, the cache is disabled.<br />
The cache is particularly useful when significant use is made of delegated administration.<br />
This cache can improve performance by avoiding recomputing All Effective Rights of named entries<br />
like accounts frequently in a short period of time.<br />
All Effective Rights are computations of the rights that named entries like accounts have - although when used, they are checked separately.<br />
<br />
The longer the value of this setting is, the more stale the view of the details is likely to be.<br />
For this reason, the maximum accepted value is 30m.<br />
Larger values will be treated as being 30m<br />
<br />
The default value is '''50s'''<br />
<br />
This will be replaced in 8.7 and 9.0 with the LDAP attribute:<br />
'''zimbraShortTermAllEffectiveRightsCacheExpiration'''<br />
<br />
=== short_term_all_effective_rights_cache_size ===<br />
<br />
Maximum number of entries in the short term All Effective Rights cache.<br />
This cache can improve performance by avoiding recomputing All Effective Rights of named entries like accounts frequently in a short period of time.<br />
Can disable the cache be specifying a value of 0<br />
<br />
The default value is '''128'''<br />
<br />
This will be replaced in 8.7 and 9.0 with the LDAP attribute: '''zimbraShortTermAllEffectiveRightsCacheSize'''<br />
<br />
=== short_term_grantee_cache_expiration ===<br />
<attr id="1901" name="zimbraShortTermGranteeCacheExpiration" type="duration" cardinality="single" optionalIn="globalConfig,server,alwaysOnCluster" flags="serverInherited,serverPreferAlwaysOn" affectsServices="all" since="8.7.0,9.0.0"><br />
<globalConfigValue>50s</globalConfigValue><br />
<desc>Maximum time an entry in the Grantee cache will be regarded as valid.<br />
If value is 0, the cache is disabled.<br />
This cache can improve performance by avoiding recomputing details frequently in a short period of time, for instance for each entry in search results.<br />
The cache is particularly useful when significant use is made of delegated administration.<br />
Grantees objects provide a view of what rights a grantee has - although those are checked separately.<br />
The longer the value of this setting is, the more stale the view of the details is likely to be. For this reason, the maximum accepted value is 30m.<br />
Larger values will be treated as being 30m<br />
</desc><br />
</attr><br />
<br />
<br />
=== short_term_grantee_cache_size ===<br />
<attr id="1900" name="zimbraShortTermGranteeCacheSize" type="integer" min="0" cardinality="single" optionalIn="globalConfig,server,alwaysOnCluster" flags="serverInherited,serverPreferAlwaysOn" affectsServices="all" since="8.7.0,9.0.0"><br />
<globalConfigValue>128</globalConfigValue><br />
<desc>Maximum number of entries in the short term Grantee cache.<br />
This cache can improve performance by avoiding recomputing details frequently in a short period of time, for instance for each entry in search results.<br />
Can disable the cache be specifying a value of 0<br />
</desc><br />
</attr></div>Gren Elliothttps://wiki.zimbra.com/index.php?title=Admin_Console_Performance_Issues_when_using_Delegated_Admin&diff=59186Admin Console Performance Issues when using Delegated Admin2015-05-05T10:09:25Z<p>Gren Elliot: /* short_term_all_effective_rights_cache_expiration */</p>
<hr />
<div>{{WIP}}<br />
<br />
'''Note''': This information is related to Bug 97743. <br />
<br />
== Overview ==<br />
If you are experiencing significant admin console performance issues when using delegated admin, configure the following LC keys to resolve the issue:<br />
<br />
* short_term_all_effective_rights_cache_expiration (default: 50000)<br />
* short_term_all_effective_rights_cache_size (default: 128)<br />
* short_term_grantee_cache_expiration (default: 50000)<br />
* short_term_grantee_cache_size (default: 128)<br />
<br />
'''Note''': The default sizes are 128, with default expirations in milliseconds. Using higher values is not recommended. These keys will be moved to LDAP for 8.7 and 9.0.<br />
<br />
<br />
== LC Key Descriptions: ==<br />
<br />
=== short_term_all_effective_rights_cache_expiration ===<br />
<br />
Maximum time an entry in the short term All Effective Rights cache will be regarded as valid.<br />
If value is 0, the cache is disabled.<br />
The cache is particularly useful when significant use is made of delegated administration.<br />
This cache can improve performance by avoiding recomputing All Effective Rights of named entries<br />
like accounts frequently in a short period of time.<br />
All Effective Rights are computations of the rights that named entries like accounts have - although when used, they are checked separately.<br />
<br />
The longer the value of this setting is, the more stale the view of the details is likely to be.<br />
For this reason, the maximum accepted value is 30m.<br />
Larger values will be treated as being 30m<br />
<br />
The default value is '''50s'''<br />
<br />
This will be replaced in 8.7 and 9.0 with the LDAP attribute:<br />
'''zimbraShortTermAllEffectiveRightsCacheExpiration'''<br />
<br />
=== short_term_all_effective_rights_cache_size ===<br />
<attr id="1902" name="zimbraShortTermAllEffectiveRightsCacheSize" type="integer" min="0" cardinality="single" optionalIn="globalConfig,server,alwaysOnCluster" flags="serverInherited,serverPreferAlwaysOn" affectsServices="all" since="8.7.0,9.0.0"><br />
<globalConfigValue>128</globalConfigValue><br />
<desc>Maximum number of entries in the short term All Effective Rights cache.<br />
This cache can improve performance by avoiding recomputing All Effective Rights of named entries like accounts frequently in a short period of time.<br />
Can disable the cache be specifying a value of 0<br />
</desc><br />
</attr><br />
<br />
<br />
=== short_term_grantee_cache_expiration ===<br />
<attr id="1901" name="zimbraShortTermGranteeCacheExpiration" type="duration" cardinality="single" optionalIn="globalConfig,server,alwaysOnCluster" flags="serverInherited,serverPreferAlwaysOn" affectsServices="all" since="8.7.0,9.0.0"><br />
<globalConfigValue>50s</globalConfigValue><br />
<desc>Maximum time an entry in the Grantee cache will be regarded as valid.<br />
If value is 0, the cache is disabled.<br />
This cache can improve performance by avoiding recomputing details frequently in a short period of time, for instance for each entry in search results.<br />
The cache is particularly useful when significant use is made of delegated administration.<br />
Grantees objects provide a view of what rights a grantee has - although those are checked separately.<br />
The longer the value of this setting is, the more stale the view of the details is likely to be. For this reason, the maximum accepted value is 30m.<br />
Larger values will be treated as being 30m<br />
</desc><br />
</attr><br />
<br />
<br />
=== short_term_grantee_cache_size ===<br />
<attr id="1900" name="zimbraShortTermGranteeCacheSize" type="integer" min="0" cardinality="single" optionalIn="globalConfig,server,alwaysOnCluster" flags="serverInherited,serverPreferAlwaysOn" affectsServices="all" since="8.7.0,9.0.0"><br />
<globalConfigValue>128</globalConfigValue><br />
<desc>Maximum number of entries in the short term Grantee cache.<br />
This cache can improve performance by avoiding recomputing details frequently in a short period of time, for instance for each entry in search results.<br />
Can disable the cache be specifying a value of 0<br />
</desc><br />
</attr></div>Gren Elliothttps://wiki.zimbra.com/index.php?title=OpenLDAP_Performance_Tuning_8.0&diff=57684OpenLDAP Performance Tuning 8.02015-03-23T16:34:18Z<p>Gren Elliot: /* Mailbox store tuning with LDAP */</p>
<hr />
<div>{{ZC}}{{Article Infobox|{{admin}}|{{ZCS 8.0}}|||}}=Zimbra OpenLDAP Server=<br />
<br />
As of 8.0.0, multiple master LDAP servers can be set up; these servers are authoritative for user information, server configuration, etc. Zimbra recommends having no more than 4 master servers deployed. Replica LDAP servers can be defined to improve performance and to reduce the load on the master servers. All updates are made to the master servers and these updates are then replicated to the replica servers.<br />
<br />
See also the documentation on configuring [http://wiki.zimbra.com/wiki/LDAP_Multi_Master_Replication Multiple Masters].<br />
<br />
You may also wish to read over the entire set of keys available on the [http://wiki.zimbra.com/wiki/OpenLDAP_Tuning_Keys_8.0 OpenLDAP Tuning Keys Wiki].<br />
<br />
== OpenLDAP Server Tuning ==<br />
For best performance, the following settings should be modified. These settings apply to both the master LDAP server and the replica servers.<br />
<br />
* Set the '''threads''' count to an appropriate level. The ZCS default is 8, which is fine for servers with up to 8 real cores. The general rule of thumb is one thread per real core.<br />
<br />
zmlocalconfig -e ldap_common_threads=8<br />
<br />
* Set the '''toolthreads''' count to an appropriate level. The ZCS default is 2. It should be set to 2. The purpose of the toolthreads setting is to decrease the amount of time it takes to slapadd a database.<br />
<br />
zmlocalconfig -e ldap_common_toolthreads=2<br />
<br />
=== Notes on MDB ===<br />
Starting with ZCS 8, Zimbra has moved to using the new MDB backend for OpenLDAP. More information on MDB in general can be found at [http://www.symas.com/mdb/ Symas' MDB information page]. ZCS previously used the HDB backend with BerkeleyDB as the underlying database software. Switching to MDB results in an increase in both read and write performance for the LDAP server over previous ZCS releases. In addition, there are no performance related tuning parameters for MDB. It simply works out of the box. You can find performance metric differences for [http://wiki.zimbra.com/wiki/OpenLDAP_MDB_vs_HDB_performance MDB vs HDB with Zimbra here].<br />
<br />
==== Maximum database size ====<br />
There is one parameter for MDB that deployments may wish to adjust, which is the maximum database size. The default is 80GB on ZCS installations. When ZCS is installed, a [http://en.wikipedia.org/wiki/Sparse_file sparse file] will be created that will be appear to be the same size as the DB maxsize. I.e., there will be a "data.mdb" file on disk that appears to be 80GB in size. In fact, it will only be the size of your actual database. For example:<br />
<br />
zimbra@zre-ldap002:~/data/ldap/mdb/db$ ls -l<br />
total 700<br />
-rw------- 1 zimbra zimbra 85899345920 Nov 29 12:18 data.mdb<br />
-rw------- 1 zimbra zimbra 8192 Nov 29 13:03 lock.mdb<br />
zimbra@zre-ldap002:~/data/ldap/mdb/db$ du -c -h data.mdb<br />
696K data.mdb<br />
696K total<br />
<br />
So the actual size of data.mdb is 696KB, although it appears to be 80GB. The maxsize setting for the database must always be greater than the total size of the LDAP DB or else writes will be rejected, slapd will stop, and data loss may occur. If it is desired to reduce the maxsize of the database to trim down the size of the sparse file, this can be controlled via the following two localconfig keys:<br />
<br />
ldap_db_maxsize<br />
ldap_accesslog_maxsize<br />
<br />
* The first key is for the primary LDAP DB (/opt/zimbra/data/ldap/mdb/db)<br />
* The second key is for the accesslog DB for LDAP masters (/opt/zimbra/data/ldap/accesslog/db)<br />
<br />
Keep in mind that in addition to the size of the data in the database it also needs room for page commits and expansion. If this value is changed to something less than the default of 80GB, careful monitoring of the size of "data.mdb" compared to the maximum size should be implemented.<br />
<br />
====automated database monitoring====<br />
With ZCS 8.0.4 and later, there is a cron job named zmldapmonitordb that runs on the LDAP servers to monitor the size of the MDB databases. By default, it will simply alert the admin account if the MDB database is close to running out of space vs its configured max size. It can be configured to take preemptive action if so desired. There is no need to restart services if one of the following localconfig keys are changed. The related localconfig keys which can be modified via '''zmlocalconfig''' are:<br />
<br />
* ldap_monitor_mdb (default true): Whether or not to monitor the LDAP MDB databases.<br />
* ldap_monitor_alert_only (default true): If true, only generate email alerts. If false, actively adjust the MDB database sizes if possible, and send out an email noting the actions taken.<br />
* ldap_monitor_warning (default 80): The percentage of used space at which to issue a warning alert (and if ldap_monitor_alert_only is false, adjust the MDB maxsize upwards)<br />
* ldap_monitor_critical (default 90): The percentage of used space at which to issue a critical alert (and if ldap_monitor_alert_only is false, adjust the MDB maxsize upwards)<br />
* ldap_monitor_growth (default 25): The percentage of new space to allocate to the MDB database if an alert is triggered and ldap_monitor_alert_only is false<br />
<br />
====mdb_stat utility====<br />
The mdb_stat utility ships with ZCS 8.0.2 and later. It allows the gathering of various information about the state of the MDB database via the command line. Available options are<br />
<br />
* -e: prints database environment information<br />
* -f: prints the freelist information<br />
* -a: prints out the information for all sub-databases (indexes and entry database)<br />
* -s '''sub database''': prints out the information specific to the sub database specified<br />
<br />
Format is:<br />
<code><br />
mdb_stat [-e] [-f] [-a|-s subdb]/path/to/database<br />
</code><br />
<br />
Examples:<br />
<code><br />
mdb_stat -f /opt/zimbra/data/ldap/mdb/db<br />
mdb_stat -a -e -f /opt/zimbra/data/ldap/mdb/db<br />
mdb_stat -s id2e /opt/zimbra/data/ldap/mdb/db<br />
</code><br />
<br />
====mdb_copy utility====<br />
The mdb_copy utility ships with ZCS 8.0.2 and later. It allows one to safely copy an MDB database from one location to another via the command line. This utility can be used while slapd is running.<br />
<br />
Format is:<br />
mdb_copy /src/dir /destination/dir<br />
<br />
Example:<br />
<code><br />
mdb_copy /opt/zimbra/data/ldap/mdb/db /opt/zimbra/backups/ldap/mdb/db<br />
</code><br />
<br />
Note: The copied MDB file will *not* be a sparse file. It will be the actual size of the database. I.e., if your databse is 25MB in size, the resulting copied database will be a full 25MB, and not an 80GB sparse file.<br />
<br />
=== Mailbox store tuning with LDAP ===<br />
If you have more than 500 domains, we suggest adjusting the following local config setting:<br />
<br />
* '''ldap_cache_domain_maxsize'''. This sets the cache of the number of domains in the server. The default is 500. If more than 500 domains are configured, you should adjust this to the lower of the number of domains you have configured and 30,000. For example, with 45,000 domains, set this to 30000.<br />
<br />
# Apply this to all mailbox servers!<br />
zmlocalconfig -e ldap_cache_domain_maxsize=30000<br />
<br />
{{Article_Footer|ZCS 8.0|7/20/2012}}<br />
<br />
[[Category:LDAP]]<br />
[[Category:Performance and Tuning]]<br />
[[Category:ZCS 8.0]]</div>Gren Elliothttps://wiki.zimbra.com/index.php?title=Enabling_and_administering_the_Zimbra_milter&diff=54163Enabling and administering the Zimbra milter2014-02-25T10:19:59Z<p>Gren Elliot: /* Enabling the Milter Server */</p>
<hr />
<div>{{Article Infobox|{{admin}}|{{ZCS 8.0}}|{{ZCS 7.0}}||}}<br />
<br />
==Getting Started==<br />
<br />
The Zimbra milter allows for the regulation of distribution list senders on a Global or server level. When the milter server is enabled, only users who have been granted explicit sending permissions will be allowed. <br />
<br />
==Enabling the Milter Server==<br />
<br />
'''''Note that the Milter server should only be enabled on servers running the MTA.'''''<br />
<br />
Global: Home > Configure > Global Settings > MTA > Milter Server<br />
<br />
Server: Home > Configure > Servers > Select Desired Server > MTA > Milter Server <br />
<br />
*Alternatively using the CLI: <br />
# su - zimbra<br />
$ zmprov modifyConfig zimbraMilterServerEnabled TRUE<br />
<br />
For a specific server (say eg.example.com):<br />
<br />
$ zmprov modifyServer eg.example.com zimbraMilterServerEnabled TRUE<br />
<br />
The above steps will ensure that milter will be automatically started via "zmcontrol start"<br />
<br />
To start the milter manually:<br />
$ zmmilterctl start<br />
<br />
To check the status of the milter:<br />
<br />
$ zmmilterctl status <br />
<br />
Usage: zmmilterctl start|stop|restart|reload|refresh|status<br />
<br />
<br />
*The following will provide examples for granting sender permissions on the CLI:<br />
<br />
*User - grants a user sending permissions to a distribution list<br />
<br />
$ zmprov grr dl distributionlist@domain.com usr user@domain.com sendToDistList <br />
<br />
*Group (distribution list) - grants a group sending rights to distribution list<br />
<br />
$ zmprov grr dl distributionlist@domain.com grp groupdl@domain.com sendToDistList<br />
<br />
*All Entities - allows all entities on the server to send to a distribution list<br />
<br />
$ zmprov grr dl distributionlist@domain.com all sendToDistList<br />
<br />
*Domain - grant all users on a domain sending rights<br />
<br />
$ zmprov grr dl distributionlist@domain.com dom domain.com sendToDistList<br />
<br />
*Public - grant all users both internal/external sending rights<br />
<br />
$ zmprov grr dl distributionlist@domain.com pub sendToDistList<br />
<br />
*After granting or revoking rights for the milter, you must reaload the configuration for the changes to take effect. <br />
<br />
$ zmmtactl reload<br />
<br />
==Verifying permissions for an entity==<br />
<br />
*Checking a single user or entity:<br />
<br />
$ zmprov ckr dl distributionlist@domain.com userorentity@domain.com sendToDistList<br />
ALLOWED<br />
<br />
*Viewing granted permissions for the distribution list:<br />
<br />
1) Get the users Zimbra ID:<br />
<br />
$ zmprov ga user@domain.com |grep -i "zimbraid: "<br />
<br />
2) Check the permissions on the distribution list:<br />
<br />
$ zmprov gdl distributionlist@domain.com |less<br />
<br />
3) Find the 'zimbraACE' entries and compare the users' id:<br />
<br />
zimbraACE: [zimbraId of user] usr sendToDistList<br />
For example;<br />
zimbraACE: c524877c-e0a6-4255-bb1b-d02b35cc2dd5 dom sendToDistList<br />
zimbraACE: 99999999-9999-9999-9999-999999999999 pub sendToDistList<br />
<br />
==Modifying and revoking grants==<br />
<br />
*If you want to remove or modify permissions, you'll need to use 'zmprov rvr' instead of 'zmprov grr'.<br />
<br />
*Example of removing sendToDistList permissions for a user: <br />
<br />
$ zmprov rvr dl distributionlist@domain.com usr user@domain.com sendToDistList<br />
<br />
*After granting or revoking rights for the milter, you must reaload the configuration for the changes to take effect. <br />
<br />
$ zmmtactl reload<br />
<br />
==Troubleshooting the Zimbra milter==<br />
<br />
*Verify the milters settings: <br />
<br />
$ zmmilterctl status <br />
''Milter server is running.''<br />
<br />
$ zmmilterctl status <br />
<br />
Additional information to be posted<br />
<br />
<br />
<br />
<br />
{{Article Footer|Zimbra Collaboration Suite 8 | 2013}}</div>Gren Elliothttps://wiki.zimbra.com/index.php?title=Enabling_and_administering_the_Zimbra_milter&diff=54015Enabling and administering the Zimbra milter2014-02-13T12:16:00Z<p>Gren Elliot: /* Enabling the Milter Server */</p>
<hr />
<div>{{Article Infobox|{{admin}}|{{ZCS 8.0}}|{{ZCS 7.0}}||}}<br />
<br />
==Getting Started==<br />
<br />
The Zimbra milter allows for the regulation of distribution list senders on a Global or server level. When the milter server is enabled, only users who have been granted explicit sending permissions will be allowed. <br />
<br />
==Enabling the Milter Server==<br />
<br />
Global: Home > Configure > Global Settings > MTA > Milter Server<br />
<br />
Server: Home > Configure > Servers > Select Desired Server > MTA > Milter Server <br />
<br />
*Alternatively using the CLI: <br />
# su - zimbra<br />
$ zmprov modifyConfig zimbraMilterServerEnabled TRUE<br />
<br />
For a specific server (say eg.example.com):<br />
<br />
$ zmprov modifyServer eg.example.com zimbraMilterServerEnabled TRUE<br />
<br />
The above steps will ensure that milter will be automatically started via "zmcontrol start"<br />
<br />
To start the milter manually:<br />
$ zmmilterctl start<br />
<br />
To check the status of the milter:<br />
<br />
$ zmmilterctl status <br />
<br />
Usage: zmmilterctl start|stop|restart|reload|refresh|status<br />
<br />
<br />
*The following will provide examples for granting sender permissions on the CLI:<br />
<br />
*User - grants a user sending permissions to a distribution list<br />
<br />
$ zmprov grr dl distributionlist@domain.com usr user@domain.com sendToDistList <br />
<br />
*Group (distribution list) - grants a group sending rights to distribution list<br />
<br />
$ zmprov grr dl distributionlist@domain.com grp groupdl@domain.com sendToDistList<br />
<br />
*All Entities - allows all entities on the server to send to a distribution list<br />
<br />
$ zmprov grr dl distributionlist@domain.com all sendToDistList<br />
<br />
*Domain - grant all users on a domain sending rights<br />
<br />
$ zmprov grr dl distributionlist@domain.com dom domain.com sendToDistList<br />
<br />
*Public - grant all users both internal/external sending rights<br />
<br />
$ zmprov grr dl distributionlist@domain.com pub sendToDistList<br />
<br />
*After granting or revoking rights for the milter, you must reaload the configuration for the changes to take effect. <br />
<br />
$ zmmtactl reload<br />
<br />
==Verifying permissions for an entity==<br />
<br />
*Checking a single user or entity:<br />
<br />
$ zmprov ckr dl distributionlist@domain.com userorentity@domain.com sendToDistList<br />
ALLOWED<br />
<br />
*Viewing granted permissions for the distribution list:<br />
<br />
1) Get the users Zimbra ID:<br />
<br />
$ zmprov ga user@domain.com |grep -i "zimbraid: "<br />
<br />
2) Check the permissions on the distribution list:<br />
<br />
$ zmprov gdl distributionlist@domain.com |less<br />
<br />
3) Find the 'zimbraACE' entries and compare the users' id:<br />
<br />
zimbraACE: [zimbraId of user] usr sendToDistList<br />
For example;<br />
zimbraACE: c524877c-e0a6-4255-bb1b-d02b35cc2dd5 dom sendToDistList<br />
zimbraACE: 99999999-9999-9999-9999-999999999999 pub sendToDistList<br />
<br />
==Modifying and revoking grants==<br />
<br />
*If you want to remove or modify permissions, you'll need to use 'zmprov rvr' instead of 'zmprov grr'.<br />
<br />
*Example of removing sendToDistList permissions for a user: <br />
<br />
$ zmprov rvr dl distributionlist@domain.com usr user@domain.com sendToDistList<br />
<br />
*After granting or revoking rights for the milter, you must reaload the configuration for the changes to take effect. <br />
<br />
$ zmmtactl reload<br />
<br />
==Troubleshooting the Zimbra milter==<br />
<br />
*Verify the milters settings: <br />
<br />
$ zmmilterctl status <br />
''Milter server is running.''<br />
<br />
$ zmmilterctl status <br />
<br />
Additional information to be posted<br />
<br />
<br />
<br />
<br />
{{Article Footer|Zimbra Collaboration Suite 8 | 2013}}</div>Gren Elliothttps://wiki.zimbra.com/index.php?title=Enabling_and_administering_the_Zimbra_milter&diff=54014Enabling and administering the Zimbra milter2014-02-13T12:14:49Z<p>Gren Elliot: /* Enabling the Milter Server */</p>
<hr />
<div>{{Article Infobox|{{admin}}|{{ZCS 8.0}}|{{ZCS 7.0}}||}}<br />
<br />
==Getting Started==<br />
<br />
The Zimbra milter allows for the regulation of distribution list senders on a Global or server level. When the milter server is enabled, only users who have been granted explicit sending permissions will be allowed. <br />
<br />
==Enabling the Milter Server==<br />
<br />
Global: Home > Configure > Global Settings > MTA > Milter Server<br />
<br />
Server: Home > Configure > Servers > Select Desired Server > Milter Server <br />
<br />
*Alternatively using the CLI: <br />
# su - zimbra<br />
$ zmprov modifyConfig zimbraMilterServerEnabled TRUE<br />
<br />
For a specific server (say eg.example.com):<br />
<br />
$ zmprov modifyServer eg.example.com zimbraMilterServerEnabled TRUE<br />
<br />
The above steps will ensure that milter will be automatically started via "zmcontrol start"<br />
<br />
To start the milter manually:<br />
$ zmmilterctl start<br />
<br />
To check the status of the milter:<br />
<br />
$ zmmilterctl status <br />
<br />
Usage: zmmilterctl start|stop|restart|reload|refresh|status<br />
<br />
<br />
*The following will provide examples for granting sender permissions on the CLI:<br />
<br />
*User - grants a user sending permissions to a distribution list<br />
<br />
$ zmprov grr dl distributionlist@domain.com usr user@domain.com sendToDistList <br />
<br />
*Group (distribution list) - grants a group sending rights to distribution list<br />
<br />
$ zmprov grr dl distributionlist@domain.com grp groupdl@domain.com sendToDistList<br />
<br />
*All Entities - allows all entities on the server to send to a distribution list<br />
<br />
$ zmprov grr dl distributionlist@domain.com all sendToDistList<br />
<br />
*Domain - grant all users on a domain sending rights<br />
<br />
$ zmprov grr dl distributionlist@domain.com dom domain.com sendToDistList<br />
<br />
*Public - grant all users both internal/external sending rights<br />
<br />
$ zmprov grr dl distributionlist@domain.com pub sendToDistList<br />
<br />
*After granting or revoking rights for the milter, you must reaload the configuration for the changes to take effect. <br />
<br />
$ zmmtactl reload<br />
<br />
==Verifying permissions for an entity==<br />
<br />
*Checking a single user or entity:<br />
<br />
$ zmprov ckr dl distributionlist@domain.com userorentity@domain.com sendToDistList<br />
ALLOWED<br />
<br />
*Viewing granted permissions for the distribution list:<br />
<br />
1) Get the users Zimbra ID:<br />
<br />
$ zmprov ga user@domain.com |grep -i "zimbraid: "<br />
<br />
2) Check the permissions on the distribution list:<br />
<br />
$ zmprov gdl distributionlist@domain.com |less<br />
<br />
3) Find the 'zimbraACE' entries and compare the users' id:<br />
<br />
zimbraACE: [zimbraId of user] usr sendToDistList<br />
For example;<br />
zimbraACE: c524877c-e0a6-4255-bb1b-d02b35cc2dd5 dom sendToDistList<br />
zimbraACE: 99999999-9999-9999-9999-999999999999 pub sendToDistList<br />
<br />
==Modifying and revoking grants==<br />
<br />
*If you want to remove or modify permissions, you'll need to use 'zmprov rvr' instead of 'zmprov grr'.<br />
<br />
*Example of removing sendToDistList permissions for a user: <br />
<br />
$ zmprov rvr dl distributionlist@domain.com usr user@domain.com sendToDistList<br />
<br />
*After granting or revoking rights for the milter, you must reaload the configuration for the changes to take effect. <br />
<br />
$ zmmtactl reload<br />
<br />
==Troubleshooting the Zimbra milter==<br />
<br />
*Verify the milters settings: <br />
<br />
$ zmmilterctl status <br />
''Milter server is running.''<br />
<br />
$ zmmilterctl status <br />
<br />
Additional information to be posted<br />
<br />
<br />
<br />
<br />
{{Article Footer|Zimbra Collaboration Suite 8 | 2013}}</div>Gren Elliothttps://wiki.zimbra.com/index.php?title=WSDL&diff=53606WSDL2013-12-04T10:07:01Z<p>Gren Elliot: Zimbra WSDL</p>
<hr />
<div>__TOC__<br />
==Where to find Zimbra WSDL documents==<br />
From ZCS 8, your Zimbra server serves 3 different WSDL documents. For instance, if your server is called '''zimbra.example.com''' then the URLs are:<br />
* Admin SOAP API - https://zimbra.example.com/service/wsdl/ZimbraAdminService.wsdl<br />
* User SOAP API - https://zimbra.example.com/service/wsdl/ZimbraUserService.wsdl<br />
* Full SOAP API - https://zimbra.example.com/service/wsdl/ZimbraService.wsdl<br />
<br />
The Full SOAP API includes all of the Admin and User APIs.<br />
Note that these documents include XML schema files like https://zimbra.example.com/service/wsdl/zimbraAccount.xsd<br />
<br />
For additional documentation, see [[SOAP_API_Reference_Material_Beginning_with_ZCS_8.0|SOAP API Reference Material Beginning with ZCS 8.0]]</div>Gren Elliot