TLS 1.2 Requirements 
*Not required for Vertical Booking

TLS 1.2 requirements work both ways - outgoing and incoming. Customers with 2 Way Push OTA / HTNG Reservation Interface (Travelclick and Synxis) are running IIS on one of their computers. TLS 1.2 will soon be required for incoming connections from your CRS vendor on this computer. You must check with the appropriate vendor to determine the TLS cutoff date for reservation delivery to your server.

If you are a Cloud Hosted customer there is nothing you need to do because we take care of this.

This is different than the TLS 1.2 requirements for credit card processing because those requirements only affect outgoing connections. The requirements discussed here are for incoming connections into your computer that's running IIS.

Meeting this requirement is simple but may require your IT professional's assistance.

1. Ensure that the computer hosting IIS and our OTA / HTNG Reservation Interface web service is running at least Windows 10 or Windows 2012.
   
   
2. Install all Windows updates.
   
   
3. Install the latest .NET Framework
   
   
4. Enable TLS 1.2.
   Import these Registry settings. After you extract the file you can view the .reg file in Notepad to see what it does. This only addresses incoming connections to the server.
   Download Enable TLS 1.2 Registry Entries

Information about these registry settings can be found here. 
https://docs.microsoft.com/en-us/windows-server/security/tls/tls-registry-settings

Here is more information regarding Server 2008R2 and presumably Windows 7.
https://cloudblogs.microsoft.com/microsoftsecure/2017/07/20/tls-1-2-support-added-to-windows-server-2008/

If your software is hosted on the Execu/Tech Cloud Hosting platform then you do not need to worry about TLS 1.2. Since we host your server, we handle this for you.

SSL Certificate Requirements 

*Not required for Vertical Booking

All CRS companies that we work with require a valid SSL certificate to be installed on your server for PUSH delivery of reservations. PUSH delivery means that they connect to your server and deliver the reservations. Please ask your CRS vendor which type of interface you have with them.

It's your responsibility to obtain, install and maintain this SSL certificate into the SSL site created for the interface. Make yourself a reminder of the date that this certificate expires so that you can renew it before this date and avoid any issues with reservation delivery from the CRS. If you're not familiar with how to obtain an SSL certificate, your IT professional should be able to help you. You can also contact the company that your domain is registered though and they may be able to sell you a certificate.

The company you purchase the SSL from should provide instructions on installing the SSL certificate in IIS. Google also has many resources and here are a couple links that Google provides. http://https//docs.microsoft.com/en-us/iis/manage/configuring-security/how-to-set-up-ssl-on-iis ​http://https//www.ssls.com/knowledgebase/how-to-install-an-ssl-certificate-on-iis-10/

If your software is hosted on the Execu/Tech Cloud Hosting platform then you do not need to worry about the SSL Certificate. Since we host your server, we handle this for you.

Web Service
*Not required for Vertical Booking

This Web Service consists of these two files:
ETOTAService.aspx - The Web Service application.
ETOTAService.inc - The Web Service settings. 

The following steps are required for the 2 Way Push Interface.  Because the 2 Way Push Interface involves the CRS posting reservation messages to the PMS, IIS is required to be installed on your server to facilitate this. The 1 Way and 2 Way Pull interfaces do not require the following steps to be performed since all communication is initiated by the PMS. The customer or their IT professional is responsible for the following.  Installing IIS (Microsoft's Internet Information Services) on the PMS server. Obtaining and configuring a static public IP address if it's required by the CRS vendor. This includes configuring all  firewalls and routers to ensure that the public IP address is properly directed to the PMS server. All communications are encrypted on port 443, the default SSL port. If you have a 2 way interface (Rates, Availability, etc. are updated from the PMS to the CRS) then your router / firewall will need to allow outgoing traffic to the CRS URL on port 443. The CRS can give you the URL. Obtaining and configuring a domain name if it's required by the CRS vendor. This is part of the URL that the CRS will use to post reservation information to your server. Often a domain with a unique subdomain (in this example it's the part before mydomain.com) like crs.mydomain.com or reservations.mydomain.com is used, but this is up to you. It is likely required if you already have a website that uses the same domain name but is hosted on another server. Obtaining and installing an SSL certificate on the PMS server. This certificate must be generated for the full domain including the subdomain or it must be a wildcard. Your IT professional will help you with this. We will need the domain name before we can provide the CRS with the PMS URL necessary for the 2 way interface. If your software is hosted on the Execu/Tech Cloud Hosting platform then you do not need to worry about IIS, IP addresses, the domain name or the SSL Certificate. Since we host your server, we handle this for you.

1. Install IIS with the ASP.NET role. Otherwise, IIS won't recognize the service and may return a "404" error.
   
   
2. They must have a SSL certificate, but they can get this after the install.
   The SSL certificate must be added to the "https" Site Bindings for the where ETOTAService.aspx was installed. Your certificate name will be different than the one in this image.
   
   
   
3. Provide Execu/Tech with the folder associated with this site.
   
   
4. Provide Execu/Tech with the domain for this site.
   
   Execu/Tech will typically perform the rest of these steps.
   
   
5. The web service can be installed in:
   • The default site
   • A new site
   • Sub folder in the WebRes site if it is also installed. WebRes
     
     
6. Place the two files in the folder provided by the customer. It is best to create sub folders, just to make it more obvious to anyone looking at the folders and also to separate different brands of interfaces on the same computer, should that ever happen.
   An example of this folder structure is "inetpub\wwwroot\ETOTAService\". 
   
   
   
   
   • In this example, it's installed in its own folder in the 'default' site. WebRes can also reside in this folder, which is why you create the sub folders "\ETOTAService\".
   • Once the customer has provided the URL to the folder they created, you can give them the URL to the web service. This URL must be provided to the CRS. 
   • In the example, if the URL was "HTTPS://ota.customer.com" then the url for the interface would be "HTTPS://ota.customer.com/ETOTAService/ETOTAService.aspx"
   • The interface URL (PMS URL) must be given to Execu/Tech and the CRS provider (Travelclick, etc.)
   • IMPORTANT NOTE
     If the customer created a new site for the interface, the site's folder will be the root folder of the interface. 
     If the site's folder is "C:\inetpub\wwwroot\ETOTAService\" then the PMS URL will be "HTTPS://ota.customer.com/ETOTAService.aspx" 
     
     
7. The IIS App Pool user (Local machine, not the domain) or IIS_IUSRS group must have full permissions to the "RQFiles" folder.
   
   
8. The settings file "ETOTAService.inc" must be edited. You can edit it in Notepad or any other text editor. Be careful not to mess up the "<%" and "%>" at the beginning and end of the file.
   You may have to grant your Windows user full permissions to this folder to edit.
   
   • RequestFolder - This is the path to the "RQFiles" folder from the Web Service computer. 
   • ResponseFolder - This is the path to the "RSFiles" folder from the Web Service computer. 
   • ResID_Source - This isn't used, yet, but enter a one word name, all caps, for the interface brand. (TRAVELCLICK, WINDSURFER, etc.)
     
     
9. Test the PMS URL. Enter it into a browser and you should see the following message.
   OTA / HTNG message expected. Nothing received - OTA/HTNG Interface - Execu/Tech Systems, Inc. - www.execu-tech.com - 850.747.0581 
   
   
   
   

1. Copy the contents of the "To Hotel Folder" folder into the Hotel folder.
   
   
2. Run" ETHTNG.EXE" and fill in the settings.  You might get an error the first time you run the application because the settings file doesn't exist.
   Items in RED are provided by the CRS.
   
   

   Basic Settings
   Set the PMS Company Number in the file "garimptc.fil".	Set the PMS Company Number in the file "garimptc.fil". This file is located in the Execu/Tech software folder and can be edited with Notepad or any other text editor.
   Hotel Name	This is the hotel's name.
   Use custom name separator	The default name separator is a comma. If you use something different, check the box and you can choose from the following: , / \ | ; : -
   Don't Delete Request	Check this to leave the previous XML request. This allows you to quickly retry the same request over and over.  This should only be used when debugging problems.
   Proxy Settings	Some network configurations require the use of a proxy server. Your IT professional will need to provide these settings.
   HTTP / XML Settings
   PMS URL	This is the URL to the PMS Web Service. Not required with a "Pull" interface.
   CRS URL 1	This is the URL to the CRS Web Service for retrieving reservations.
   CRS URL 2	This is the URL to the CRS Web Service for sending rates, availability, restrictions and reservation message responses. If you only received one URL, enter that URL here also.
   Use Default CRS URLs	Click this to insert the default CRS URLs used by the selected CRS vendor.
   Username	This is the interface username.
   Password	This is the interface password.
   Hotel Property Code	This is the Hotel's property code with the CRS.
   Chain Code	This is the hotel's "Chain Code" that is assigned by the CRS. Rarely used.
   Interface Type	This is the brand of the interface.
   HTTP PUSH / PULL	Whether the CRS "pushes" reservations to us or we "pull" them from the CRS. "Push" means that the CRS uses our Web Service to send messages to us. "Pull" means that we use their Web Service to request messages.
   Multi Res	Checked if the CRS sends more than one reservation in a message.
   HTNG	Checked if the CRS uses the HTNG specs.
   Single Request	Checked if the CRS sends more than one message type (New, Modified, Cancelled) in a message.
   Check PULL messages every [  ] seconds.	This is the interval, in seconds, that the "Pull" interface will check for changes. Some CRS companies have preferred intervals.
   File Settings
   Request (Inbound)	This is the path to the "RQFiles" folder.
   Response (Outbound)	This is the path to the "RSFiles" folder.
   Execu/Suite Folder	This is the path to the HOTEL folder.
   Save Requests	Checked only when testing and you need to save a copy of the XML message from the CRS.
   Remappping
   Copy Reservation Source	Checked if you want the reservation source (Expedia, etc) placed in the Company field.
   Override Market Segment	Checked if you want to override the CRS Market Segment code with the specified code.
   Override Source of Business	Checked if you want to override the CRS Source of Business code with the specified code.
   PMS Rate Use?	Checked if you want to use the specified rate code with the interface. YOU MUST USE AT LEAST 1 RATE.  The interface will only update a single RatePlanCode for each PMS Rate Code. For example, PMS Rate Code 2 can update the CRS RatePlanCode "RACK" but not both "RACK" and "AARP". Ask your CRS vendor about linked rates. These linked rates might be 10% lower or $5.00 less than the master rate that the PMS updates. By using linked rates, the PMS can update the CRS RatePlanCode "RACK" with PMS rate code 2, which will cause all of the CRS  RatePlanCodes that are linked to "RACK" to be updated as well. *In all cases, regardless of the rate or rate code, we will post the dollar amount provided by the CRS. This ensures that the guest will always be charged the rate they agreed to when booking even if there is a miss-match in the PMS.
   RatePlanCode	This is the Rate Plan Code in the CRS.  This comes from your CRS and is not determined by or provided by Execu/Tech.
   Category	2 way only. This is the Rate Plan Category in the CRS  This comes from your CRS and is not determined by or provided by Execu/Tech.
   ShortDesc	2 way only. This is the Short Description of the rate plan.  This comes from your CRS and is not determined by or provided by Execu/Tech.
   LongDesc	2 way only. This is the Long Description of the rate plan.  This comes from your CRS and is not determined by or provided by Execu/Tech.
   2 Way
   Enable 2 way interface	Checked if the 2 way interface is used.
   Number of days	This is the number of days of data that the CRS will accept. Typically 180 or 365, but ask the CRS vendor. The interface supports sending 1 - 730 days.
   Send Rates	Checked if the 2 way interface will send rates.
   Send Availability	Checked if the 2 way interface will send availability.
   Send Minimum Length of Stay	Checked if the 2 way interface will send minimum length of stay.
   Payment
   	Contact Exeu/Tech Systems for assistance with configuring tokenization. No payments will be collected by the interface but you do have the option of tokenizing card data.
   Check for PULL reservations now	If this is a pull interface, this will send a request to retrieve any pending reservation messages. Most PUSH interfaces will return an error to this request.
   Send Ping Test (Vertical Booking)	This will send a Ping Test to Vertical Booking using the credentials you entered on the HTTP / XML Settings tab. This verifies connectivity and valid credentials.
   Show popup debug messages?	Check this to see popup messages to assist in debugging a problem.  This should only be used when debugging problems.
   Save UNENCRYPTED log in RQFiles\log\DebugLog.txt Only for emergency debugging. Log deletes on app restart.	Checking this box does exactly what it says. Only do this when testing. The setting is reset and logs are deleted when the app restarts.
   Test with UNENCRYPTED xml file in RQFiles folder	This allows you to test with unencrypted XML files. This setting resets when the app restarts.
   Encrypt?	Encryption is permanently enabled and can no longer be disabled with this setting. If you need to test or view unencrypted data, use the previously mentioned options.

   
   
3. Save the settings and create a Scheduled Task that runs on startup. Use the System user unless the PMS folder or RQFiles and RSFiles foders are on other computers. In that case, the customer will need to provide a user with permissions to these folders.

1. Create a Scheduled Task. Use the System user unless the PMS folder or RQFiles and RSFiles foders are on other computers. In that case, the customer will need to provide a user with permissions to these folders.
   
   
2. Every setting you see is for testing purposes. Don't change them.

1. *Not required for Vertical Booking
   Test the URL of the Execu/Suite Web Service if it was installed. You should see the following message.
    "OTA / HTNG message expected. Nothing received - OTA/HTNG Interface - Execu/Tech Systems - www.execu-tech.com - 850.747.0581"
2. Make sure the Scheduled Tasks are running.