You can connect the ARCHIBUS Web Central Room Reservations application to Microsoft Exchange Servers by configuring the ARCHIBUS Extension for Exchange Integration. The ARCHIBUS Extension for Exchange Integration is installed as part of the Reservations application installation. When using this configuration, the ARCHIBUS Room Reservations form within Web Central presents the usual ARCHIBUS room reservation information, such as scheduling for rooms, equipment, services, and catering. However, with Exchange integration:
If you have configured Exchange integration, a listener can optionally be enabled or disabled. If the listener is enabled, changes made in Exchange calendars are propagated to Web Central, and Web Central receives a notification of the new meeting from Exchange. Web Central compares the meeting in Exchange with the reservation in Web Central. If the reservation was created with the Outlook Plug-in, the two meetings should match. If they don’t match (for example, because the meeting has been modified via Outlook Web Access after creating it), the reservation in Web Central is updated.
The Exchange listener is not compatible with Exchange 2007 and should be used only for Exchange 2010 SP1 and up.
When the meeting in Exchange is created and notifications are sent to the attendees, the listener account also receives the invitation. The listener account is an email address that is required for automated processing of meeting updates from Exchange with the Exchange listener. This account will be added to all meetings created in Exchange via Web Central and the ARCHIBUS Outlook Plug-In.
When any update is done to the meeting via OWA, the Plug-In, Web Central, or any other client, after verifying that the reservation is in sync, the Exchange listener receives the updated invitation and accepts it. The response from the listener means that the listener account has verified that the reservation and meeting are in sync.
Note: When reservations are updated with the listener enabled, the change is immediately applied to the requestor's calendar. The requestor does not receive email saying it was updated; rather, they get a notification that the listener account has accepted the change. There is only a separate notification email for the requestor when the meeting is canceled.
The Exchange Listener doesn’t sign out any license; if the meeting organizer updates a meeting, or if an attendee responds to a meeting from Outlook Web Access, this action doesn’t sign out a license.
The following restrictions apply only for enabling Exchange integration in the Web Central Reservations application. The Outlook Plug-In does not require a specific Exchange version.
Note: Although SP3 is required for Exchange 2007, the exchange.version property in reservations.properties should be set to Exchange2007_SP1. This is because the exchange.version property defines the Exchange Web Services (EWS) API version to use for communication between Web Central and Exchange. This API has not been updated with every Service Pack release of Exchange 2007; hence, the EWS API version Exchange2007_SP1 should be used for connecting to Exchange 2007 SP3.
Note: Reservations interface with Exchange 2013 / Office 365. To properly detect the new appointment status 'Working Elsewhere,' the system administrator should set the exchange.version property in reservations.properties to 'Exchange2010_SP2'. When using a lower API version, appointments marked as 'Working Elsewhere' will not be displayed on the attendee time line.
When using mixed Exchange environments, you need to set the API version to the lowest Exchange version in use, so all connected Exchange servers should be Exchange 2010 SP2 or higher to support displaying 'Working Elsewhere' events on the attendee time line.
Note: When deploying with WebSphere, be aware that the standard WebSphere 8.5.0 tries to connect using SSLv3, but this is rejected by Office 365. To resolve the issue, ensure that the application server connects to Exchange with TLS, and NOT with SSLv3 .
For deployment requirements for the Reservation Outlook Plug-In, see Reservations Plug-In for Microsoft Outlook: Installation.
Exchange 2010_SP1 or later is required for enabling the Exchange Listener.
Note: Although Exchange 2010 SP1 is always required, if your deployment uses mixed versions, you can use the listener by combining Exchange 2010 with an older Exchange version and Autodiscover. See Using the Exchange listener in mixed Exchange environments.
When configuring the application with Exchange integration, if you're going to connect using Office 365, note the following:
https://outlook.office365.com/EWS/Exchange.asmx.If your Exchange environment includes different Exchange versions, you can use the Web Central Reservations Application with Exchange Integration for all users, regardless of the Exchange version of the server hosting their mailbox. This is done using Exchange Autodiscover, a web service that helps Microsoft Exchange administrators configure user profile settings for clients running Outlook
You enable Autodiscover by leaving the
exchange.url property in the reservations.properties file empty.
When Autodiscover is enabled, for each mailbox, the ARCHIBUS Extension for Exchange Integration:
Note:The impersonation credentials specified in reservations.properties file must be accepted by all Exchange servers having one of the mailboxes to impersonate..
If you have an Exchange environment that uses different Exchange versions, using the Web Central Reservations Application with Exchange integration, you can enable the Exchange listener to track changes done via Outlook Web Access, or any other Exchange client.
To use the listener in mixed Exchange environments:
exchange.url property in the reservations.properties file empty.exchange.resourceAccount) on an Exchange server version 2010 SP1 or later, regardless of the Exchange version where the users' mailboxes are placed. Be aware that:
exchange.resourceAccount is not placed on an Exchange 2010 SP1 or later version.The Autodiscover process imposes long delays when retrieving free/busy information for attendees that cannot be impersonated. For example, if the email addresses are invalid, or for external people for example, then the Autodiscover process takes a long time to finally decide that no endpoints are available.
When using Exchange integration, the exchange.linkedDomains property is used to speed up retrieval of free/busy information by listing the specific domains the application should try to impersonate. Entering domains for this property is recommended for Exchange integration, and can be used whether or not you are using Autodiscover. See exchange.linkedDomains.
If Autodiscover is enabled, and the linkedDomains property is null, then Autodiscover is initiated for all email addresses.If the linkedDomains property has values entered, then Autodiscover is initiated for only the entered domains.
The application caches the results, so after the initial delay, the attendee Timeline loads faster, similar to the time it takes without Autodiscover enabled. However, the first time you try to load free/busy times for an invalid email address, this takes about 50 seconds. The second time, with caching, it takes only 3 seconds. The Timeline gives a "loading..." message while the processing occurs.
Most of the delay in processing comes from external users, which could take about 50 seconds to process. For internal people, processing time could be between 2 and 10 seconds. Adding the exchange.linkedDomains property would ensure that the application does not try to impersonate the external users, which would significantly reduce the processing time.
To configure Exchange integration:
[application directory]\WEB-INF\config\context\applications\reservations.properties file
reservations.configurationFile=classpath:com/archibus/app/reservation/exchange-integration-context.xml
reservations.configurationFile=classpath:com/archibus/app/reservation/exchange-integration-context-remoting.xml
Note: With the listener enabled, requestors will be receiving email notifications from the listener account. For this reason, it is recommended that you give this account a descriptive name that clarifies the reason for the emails. For example, you could name the account 'Room Reservations Service.'
Note: By having two different properties (the organizerAccount and resourceAccount), the administrator can control whether the resourceAccount is added to all meetings (for the Exchange listener), and whether non-Exchange users can create reservations without the one decision influencing the other.
Note: The resource account is automatically added to all reservations when having the listener enabled. The listener uses the resource account for automatic updates from Exchange to Web Central. For this reason, this account mailbox can be configured to automatically archive old meetings, as well as to automatically remove attachments from the meetings.
Note:If the listener is not used, the exchange.resourceAccount property should be empty. If not empty, it will be added to all meetings regardless of whether the listener is enabled (to support a clustered environment). For clustered environments, each instance needs this property
An example of this property when it is set:
exchange.url=https://server.domainname.local/EWS/Exchange.asmx
exchange.projectId=HQ-Sybase-Runtime
Note: The exchange.enableTracing property is no longer needed, as the Reservation application now traces all connection issues between Web Central and Exchange to the archibus.log file, instead of the standard output. See Enabling Exchange tracing through logging.xml.
When using Exchange integration, this property is used to speed up retrieving free/busy information by listing the domains the application should try to impersonate. When this property is empty, connecting to Exchange is attempted for all email addresses, including external attendees.The property is recommended for Exchange integration, and can be used whether or not you are using Autodiscover.
exchange.linkedDomains=: tgd.com,sub.tgd.net
Note: Listing all subdomains is not required. For example, if you have sub1.tgd.com and sub2.tgd.com, adding tgd.com to the list would be sufficient.
The following properties are not required:
Note: This application parameter applies to the Web Central Reservations application with or without Exchange integration.It is not applicable to the Outlook Plug-In.
To enable the tracing of all connection issues between Web Central and Exchange to the archibus.log file, edit WEB-INF/config/context/logging/logging.xml and change the priority value of com.archibus.app.reservation.exchange into <priority value="trace" />
You can create two mailboxes, one for the organizerAccount and one for the resourceAccount.
No special permissions are required for these mailboxes, although the service account should be allowed to impersonate them. Typically, the organizerAccount would be a shared mailbox, and the resourceAccount would be a resource mailbox, but any type of mailbox will work. Although using the same mailbox for both organizerAccount and resourceAccount is an option, this is not recommended for performance reasons.
On Exchange 2010, using a resource mailbox allows additional configurations, such as always deleting non-calendar emails, deleting attachments from incoming meeting requests, deleting the body and/or subject of meeting requests, and automatically adding the name of the organizer to the meeting subject.
Note: Automatic processing of requests should not be enabled, as this is handled by the ARCHIBUS Reservations Application.
In addition to the special options for resource mailboxes, both mailboxes can be hidden from Exchange address lists, and their Free/Busy information can be hidden. These options can be set from the command line, or by using the Exchange Management Console. See the Exchange documentation for more information on these configurations.
When using Exchange 2010 SP1 and up, you can configure access restrictions for Exchange Web Services (EWS) for the entire organization, per user, and per application via HTTP User Agent. By default, no restrictions are applied. However, if access to EWS has been disabled or limited, then it must be enabled.
Exchange Web Services are enabled by default on Exchange Servers with the Client Access Server Role installed. By default, no access restrictions are applied.
For Java 1.5, the System Administrator will have to store the certificate in the trust key store. This is not required for java 1.6.
Exchange Impersonation is a mechanism that allows a single Windows Active Directory account to act on behalf of other users on a Microsoft Exchange mailbox, as if they were performing the action themselves. For details on setting up Exchange Impersonation, see Using Exchange Impersonation.
| Copyright © 1984-2016, ARCHIBUS, Inc. All rights reserved. |