Due to security regulations, certain customers must disable TLS protocols 1.0 and 1.1. However, when they do this and use only TLS 1.2, they lose connectivity from the TRIRIGA Reserve Outlook add-in.
The problem was that the add-in was compiled with .NET 4.0 which doesn’t support TLS 1.2. The fix is to explicitly force support for the TLS 1.2 protocol. Moving forward, the IBM TRIRIGA Workplace Reservation Manager add-in is now able to communicate with the TRIRIGA server over the TLS 1.2 protocol.
[Admin: To see other related posts, use the Add-in tag or TLS tag.]
When opening any meeting in the Microsoft Outlook calendar, the TRIRIGA Reserve Outlook add-in will connect to the TRIRIGA server and send a small package.
This happens regardless of whether the meeting was created with the TRIRIGA add-in or not. When opening an appointment (which has no participants, in contrast to a meeting), there is no connection to the TRIRIGA server. It can be reproduced by opening Fiddler, opening Outlook, and then opening any item in the calendar that has participants (i.e. a meeting).
The consequence of this is that a session is opened for the user on the TRIRIGA server, taking up capacity on the server, thereby reducing the number of real users that the system can support. Has anyone else noticed this behavior? Can it be changed through configuration?
If you attempt to install the Reserve Outlook add-in into a folder within C:\Program Files\… the information provided on the command line such as URL is NOT copied into the user’s outlook.properties file. However, if you select any other folder in the computer as an install location, then the details are updated into the outlook.properties file.
The problem with using any other location is that those locations are not trusted by Windows. As such, the application when invoked forces a popup which, due to the expired application signing certificate, is not pretty. This is quite scary and is likely to result in many of the users declining the installation.
Because the files are sent to the users’ computers silently, they will not be aware that the add-in has been deployed into their machine. Any popup around email is worrying, so it is easy to see people taking the Don’t Install option.
Single sign-on (SSO) solutions need to provide a mechanism for basic authentication according to the documentation in the “Requirements for single sign-on requests in the TRIRIGA Application Platform” for the TRIRIGA CAD Integrator, BIM, and Reserve Outlook Add-in. SAML does not support this for non-browser-based applications.
SAML is a technology that was designed for browsers, not integration applications such as CAD Integrator, BIM, Reserve Outlook Add-in, or other integration technologies. IBM TRIRIGA does not support Security Assertion Markup Language (SAML) or credential-less login mechanisms such as SmartCard or Common Access Card (CAC) as a method of authentication for its non-browser clients such as CAD Integrator, BIM, and the Reserve Outlook add-in. SAML and SmartCard/CAC do not support basic authentication for non-browser-based clients.
The best practice, if using SAML or SmartCard/CAC, is to authenticate directly to TRIRIGA on a separate process server or integration server as opposed to the SSO-enabled application server. These users will need to know their TRIRIGA user name and password to sign in with this solution. An alternative best practice would be to set up a separate non-SAML SSO solution for non-browser client users, which can support basic or NTLM authentication. Similarly, SmartCard/CAC users would need to know their SmartCard/CAC user name and password to sign in with this solution.
[Admin: The same article is also posted in the IBM TRIRIGA blog and Watson IoT Support blog.]
The Outlook Reserve add-in is not functioning properly. What I see inside the app is that the top of the form inside the add-in appears momentarily, with the “Book Selected Room” button nearly off the page, such that you can only see the left edge. Then that whole bar goes away, including the button. The “Book Selected Room” button at the bottom and most other controls never come into focus. So no reservations can be made.
It is necessary to ensure that the correct registry entry exists, and that Internet Explorer (IE) Compatibility View mode is not set. The registry location is different depending on whether you are running the 32-bit or 64-bit version of Microsoft Outlook:
- With 32-bit Outlook, this is the registry key that will matter: HKLM/Software/Wow6432Node/Microsoft/Internet Explorer/Main/FeatureControl/FEATURE_BROWSER_EMULATION
- With 64-bit Outlook, this is the registry key that will matter: HKLM/Software/Microsoft/Internet Explorer/Main/FeatureControl/FEATURE_BROWSER_EMULATION
[Admin: The same article is also posted in the Watson IoT Support blog.]
A room’s “Calendar View” tab is not rendering as expected when it is brought up through Outlook.
Steps to replicate:
- Launch Microsoft Outlook that has been enabled with the TRIRIGA Outlook add-in.
- Connect to the Exchange server.
- Navigate to “Calendar”.
- Open a new meeting.
- Click to open one of the available rooms that are listed.
The room’s “General” tab renders as expected, but the room’s “Calendar View” tab does not. Where you would expect to see a calendar view, none is present. Nothing is present in the “Reservation Calendar” section.
We needed to upgrade the Google Web Toolkit (GWT) library to version 2.7. Moving forward, an issue has been resolved in the Reservation Outlook add-in, which prevented the room availability and room calendars from showing when viewing or creating a TRIRIGA appointment.
There are several locations:
[Admin: This post is related to the 06.08.15 post about how Outlook 2013 disables the Reserve add-in. To see other related posts, use the Outlook or Add-in tag.]