Coveo for Sitecore - Endpoint deprecation issues and resolution - TLDR

Coveo planned to deprecate their Coveo for Sitecore endpoint and requested clients to use Organization specific endpoint for better control over traffic and rate limiting. I wrote a blog article earlier and provided the steps to migrate to the organization specific endpoint. 

Coveo for Sitecore - Endpoint Deprecation & Migrate to Organization Specific Endpoint: https://www.nehemiahj.com/2024/08/coveo-for-sitecore-endpoint-deprecation.html

Even after migrating to the right organization specific endpoint, we were still informed that we are using the deprecated endpoint and we may have issues to analytics and search related API calls. In Coveo Administration Console, Visit browser / event browser feature does not show the endpoint being used for the incoming traffic. 

So every time, we wanted to test whether it reaches the right endpoint, we worked with Coveo support and they provided the results. Results were contradictory. Sometimes it reached the right endpoint and sometimes it reached the wrong one 🤷‍♀️. Our setup is described below.

• We have Cloudflare as our entry point. 
• Azure Front Door is used for routing as we have multiple legacy sites and Sitecore sites. 
• Sitecore site is hosted in Azure VM as IaaS setup. 
• Coveo for Sitecore module is used to setup the Coveo related pages. 

As Coveo support requested, I did few changes to Cloudflare and Azure Front Door.

• Bypass Cache for Coveo requests in Cloudflare. Bypassed for any URL path /coveo/rest/*
• Disable cache and WAF in Azure Front Door - We didn't use WAF and Cache in Azure Front Door. So no changes were implemented. 

Scenario 1: Disabled the Sitecore proxy

Disabled the Sitecore proxy through the command center. How to do it: https://docs.coveo.com/en/3401/coveo-for-sitecore-v5/disable-the-reverse-proxy.

Result: All Coveo requests reached the correct organization endpoint. I could even see it in the network tab as Coveo requests are routed directly from client browser to Coveo organization endpoint domain. 

Scenario 2: Enabled the Sitecore proxy & requests from internet

This is a regular scenario where proxy is enabled in Sitecore and requests were made from internet. 

Result: All Coveo requests reached the deprecated endpoint. Coveo requested us to implement Bypass cache in Cloudflare and disable cache & WAF in Azure Front Door as mentioned above. But Coveo support mentioned that requests are sent to deprecated endpoint. 

Scenario 3: Enabled the Sitecore proxy & requests sent inside Sitecore Server

This was just a random request I made and Coveo support checked their side whether it is sent to deprecated endpoint or not. 

Result: All Coveo requests reached the correct organization endpoint. 

Coveo support brought in core engineering team to the discussion and they were skeptical that some rules in Cloudflare or Azure Front Door transforms the domain to the wrong domain. I was sure that there is no outbound rules which could have caused this issue. They asked us involve our network team to investigate as there is no problem with Coveo. 

In-Depth Analysis

Enabled Coveo Debug Logging:

We enabled Coveo Debug logging to understand the domain which is used to send the Coveo proxy request. To enable debug logging, you can modify the <log4net> <logger> section in this file \App_Config\Include\Coveo\Coveo.SearchProvider.Custom.config. 

After enabling debug logging, Coveo related logs were captured in Coveo.Search.txt file. It clearly showed that we are sending the traffic to Organization specific endpoint (which is the correct endpoint) in all the scenarios. We had to prove that to Coveo by other means. 

Captured Coveo Header Information with Domain:

Since I cannot install any sort of network tools in the server, I created a simple .NET app to read the incoming request and log the header details in a text file. I hosted it in a separate development Azure VM with public access. The bindings for this app are Coveo deprecated endpoint and Coveo organization specific endpoint domain. In the Sitecore Azure VM, I added the Coveo organization endpoint domain and deprecated endpoint domain in the server host file pointing to the development VM. 

So any requests to Coveo deprecated endpoint and organization endpoint will reach the app hosted in the development VM. I logged the entire request header information in both the scenarios. From my side, I confirmed that all the requests are having the right endpoint so it is not our problem but something to do with Coveo network side. We asked Coveo support to involve their network team and we shared the entire log information. 

End Result

Coveo Support found the issue at their side. When the Sitecore proxied request reached Coveo and if it has X-Forwarded-Host header, then Coveo considered as invalid request and routed all traffic to deprecated endpoint. The request did not have X-Forwarded-Host header if we send the request inside the server (without Cloudflare or Azure Front Door) so those requests were marked as valid and routed to organization endpoint. Unfortunately we do not have any control to customize the request to Coveo using Sitecore proxy as it is part of the Coveo for Sitecore module. 

On Nov13th 2024, Coveo support released the fix at their side and we gave a couple of Visit IDs to test and they confirmed that it reached the organization endpoint. Also, Coveo extended their deprecation deadline to one last time to June 3rd 2025. 

The X-Forwarded-Host (XFH) header is a de-facto standard header for identifying the original host requested by the client in the Host HTTP request header. Host names and ports of reverse proxies (load balancers, CDNs) may differ from the origin server handling the request, in that case the X-Forwarded-Host header is useful to determine which Host was originally used. - Mozilla Developer Docs.

Since we have Cloudflare and Azure Front Door, the X-Forwarded-Host header is added to the request and it reached Sitecore server. Coveo for Sitecore module uses the headers from the original request, transforms only a set of headers with different value and copies the rest of the headers from original request to the proxied Coveo request. 

Once Coveo made changes at their side, this started to work for every Coveo clients. 

Our traffic data is also moving towards organization specific endpoint.

Happy Customers 😊😊😊

XM Apps API - Use Case for large organizations

In one of my previous blog article, I discussed about the newly introduced XM Apps API to manage XM Cloud Apps. What could be the use case for these APIs? 

I worked for a multinational confectionery, food, and snack food company client that had over 160 brands. They were using Sitecore XP, .NET-based applications, and other technologies for their brand sites. One of the pain points for the brand managers was the inability to quickly set up, build, and launch promotional sites. About 10 years ago, we proposed a solution that allowed brand managers to request new Sitecore, .NET, or other tech stack sites through a centralized portal. With the approval of IT and other stakeholders, the setup for a new Sitecore site would be ready for the brand manager and their development agency in just 20 minutes. Previously, this process had an SLA of 3-4 days due to various manual tasks. We automated everything, reducing the setup time to 20 minutes, enabling the development agency to start developing using existing reusable components and launch the site within an hour.

With XM Cloud Site management features along with the XM Apps API, large organization can make use of centralized internal portal to tie up with XM Apps API to setup, launch and destroy sites in a matter of seconds to few minutes. With automation, there is a huge impact to the speed with low/no manual errors. 

Explanation

1. Brand manager wants to launch a promotional site for an upcoming event. 
2. Brand manager requests a new site using Centralized Site Request portal. As part of the request, budget, project code to charge to manage XM Cloud and other relevant platforms to host a site, development agency details with all the developer information including email, name and other details, project sponsor information are added. 
3. IT and other stakeholders of the organization review the request and approve it. 
4. The centralized site request tool is based on Task-Oriented Architecture. Adds the list of tasks in the queue. Agent (start with a simple PowerShell scripts) takes each pending tasks and executes it in the order as configured. 
5. With XM Apps API and the availability of other APIs, these tasks can be executed in the matter of seconds to minutes. 
6. Development agency will be informed automatically and development can be started immediately. 

Can It Be Done?

Certainly. Even with Sitecore XP hosted in IaaS with no support of APIs, we were able to bring down the Site setup SLA from 3 days to 20 minutes with this kind of automation 10 years ago. With the availability of XM Cloud APIs and other APIs, large organization can be benefitted to automate and manage huge number of requests with no manual errors. 

Happy Customers!

XM to XM Cloud Migration tool - 2.1 - Installation and Dependencies

In the previous article, I provided a brief introduction of XM to XM Cloud Migration Tool. In this article, installation, dependencies and installation steps are explained.   

Installation

• Once downloaded, extract the content in a folder. 
• In the source CM instance, install the package, SitecorePackage.zip, which is available in the extracted folder. 

• Once the package is installed, you will see a folder (_MigrationHarness) in the CM root folder and it has all the dependencies needed for the tool to work.
• Additionally, two configuration changes are necessary. 
• web.config: Add the following configuration under existing parent XML elements. 
  
  

• Sitecore.Services.Client.config to allow access to entity and item services. Instead of modifying the Sitecore configurations directly, you can apply the patch as below. Important: Remove this setting once the migration is over as it allows access to all entities and Item Services. 
  
  

• Run the executables in Admin mode and start migrating content. There are two executables. 
• XMMigration.exe - For migrating using CLI
• XMMigrationGUI.exe - For migrating using GUI

Uninstallation

Since the dependencies are contained in a separate single folder - (_MigrationHarness), uninstallation is simple. 

• Delete _MigrationHarness folder 
• Revert web.config change. 
• Remove the Sitecore patch file for Sitecore.Services.SecurityPolicy setting. 

XM to XM Cloud Migration tool - 2.1 - Introduction

XM Cloud: Sitecore’s cloud-native, SaaS enterprise-ready CMS that creates content once and delivers across any channel for unforgettable customer experiences. So many years, Sitecore CMS has been deployed in On-Prem and PaaS. Migration from one On-Prem to another On-Prem was harder but doable using direct database access where we can backup and restore it in the target environment and migrate the content. With XM Cloud as a SaaS product, this is not possible anymore. We need certain tools which can access XM Cloud SaaS platform and migrate the content. One of the tool created by Sitecore is XM to XM Cloud Migration Tool. It was first introduced in 2023 with the aim of migrating a large chunk of content (as-is) from On-Prem to XM Cloud. 

XM Cloud Migration Tool Image (AI-Generated)

XM to XM Cloud Migration Tool - v1 (Deprecated)

XM to XM Cloud Migration Tool version 1 was introduced in 2023. 

• Supports Sitecore v10.1+
• On-Prem only
• Uses Sitecore Content Serialization (SCS) and Sitecore CLI under the hood

This tool worked but it was slow since content needs to be serialized in the source system, migrated and then pushed into the target system. Many Sitecore customers who are using either in 8x or 9x are not able to use this tool for their XM Cloud migration. 

XM to XM Cloud Migration Tool - v2.1

The newly introduced v2.1 during the Sitecore Symposium 2024 has significant improvements and features. 

• Supports Sitecore v9.1+
• On-Prem and PaaS 
• Uses Google's Protocol Buffer format (Protobuf)
• No longer dependent on Sitecore CLI or Sitecore SCS.
• Dependencies are installed using a Sitecore package. 
• Dependencies are contained in a single folder (easier to uninstall)

Essential Facts to Be Aware Of

• Before migrating content, templates need to be migrated first. 
• Take caution in migrating System folders. Migrate only custom created items. 
• Supports only migrating media items stored in database or Azure blobs.

Though this tool was created by Sitecore, it is not well-documented in the Sitecore documentation portal (don't know the reason 😊) but markdown are available in the tools download zip. You can download the tool here. 

In the next article, we will discus on installation and uninstallation.