Anders Wahlqvist
Mar 26, 2019
(8 votes)

Using routing rules to validate a site before go live/swap (DXC Service)

During a deployment in DXC Service a temporary slot is created where the new version of the site is pushed, prepared and warmed up. If everything looks good during the manual validation step, it will finally be swapped with the previous version of the web app.

The new version of the site is usually accessible via the following link:

The recommendation is to have a default site with a "*" binding or at least add the hostname above in the site bindings of the CMS (see "Before going live") to make this URL work, but what if you need to validate more sites before you feel comfortable swapping the deployment slot? Or if this binding just isn't added for some reason?

Consider the following setup as an example:

When trying to browse this site through the slot-address mentioned above, it would just respond with a 404 like this:

Some implementations might also expect certain host headers to be used which could make validation of the slot quite tricky.

This is where routing rules can help!

So what are routing rules? How can I use them?

Routing rules is a Azure feature that makes it possible to route traffic via one of the hostnames assigned to the web app to one of its slots. During DXC Service deployments, the deployment engine will automatically attempt to configure routing rules for the slot so that any of the assigned hostnames can be tested in the slot, this is done just before the "warmup step" in the deployment. Before the slot is swapped (the complete/go live step), these rules are removed again. The rule is configured so that no production traffic is routed to the slot (100% to "production slot" and 0% to the deployment slot) while still allowing the routing rule to be used if a special cookie is added.

Using a cookie to browse the slot using a custom hostname

While there are actually two ways of triggering this behavior, using a cookie is the most reliable way. You simply need to add a cookie named "x-ms-routing-name" to your browser session with the value of the slot you want to browse (which for DXC Service deployments will be "slot").

The following example shows how it can be achieved in Chrome:

  1. Browse the hostname you want to use, for example (you might want to use "incognito"/"private"-mode to avoid having this cookie stored in your normal session after you've validated the slot, or make sure you remember to remove it)

  2. Press F12, go the the "Application"-tab and expand "Cookies on the left hand side:

  3. Double-click under the last cookie in the list and enter "x-ms-routing-name" as the cookie name:

  4. Enter the slotname in the "value" field for the new cookie, for DXC Service deployments, the name should simply be "slot":

  5. Press Enter, and refresh the page and you will be browsing the slot using the hostname you entered in step 1!

It is also possible to use a query string to trigger this behavior, you simply add "?x-ms-routing-name=slot" to the address, however, this method isn't as reliable since requests issued by scripts on the site could still be routed to the "production slot", so it's recommended to use the "cookie method" instead.

How are routing rules used during deployments then?

During deployments in DXC Service, routing rules are used to check the status of the warmup process, the deployment engine will look for a hostname to use in the application initialization-section of Web.config.

If you want to check what hostname was used to validate the slot during the deployment you can check the deployment output log, after each site in the deployment has been warmed up the results are posted to the log which includes a "ManualValidationLink":

This link can be used directly in the browser, but since the cookie method is more reliable, it's recommended to use that instead (but you could of course still find and copy the cookie name and value from this link!)

Mar 26, 2019


Matthew Boniface
Matthew Boniface May 9, 2019 06:47 AM

This is awesome, thanks Anders!

Tahir Naveed
Tahir Naveed Jun 10, 2019 03:12 PM

Good share. Thanks for sharing. 

Anders Wahlqvist
Anders Wahlqvist Jun 11, 2019 02:26 PM

Thanks for reading! Glad you find it useful! @Matthew @Tahir

Darren Sunderland
Darren Sunderland Nov 7, 2019 10:14 AM

This was really helpful when implementing automated testing in a CI/CD pipeline, for a multi-site solution. It enables me to validate all sites and provide greater confidence to all of our different stakeholders.

Anders Wahlqvist
Anders Wahlqvist Nov 7, 2019 01:13 PM

Glad to hear that @Darren, that's a great use case for this feature!

Drew Douglas
Drew Douglas Jan 27, 2020 08:42 PM


Looks like it's using a modified domain in my log, now, withouth the query string:


Is this valid only after warmup, or during all of deployment, or can I use this any time to hit the slot site?

Anders Wahlqvist
Anders Wahlqvist Jan 28, 2020 07:50 AM

@Drew That is the default hostname we assign to the deployment slot, so it's fine to use that, it's always there. We will however stop the slots when deployments are done so it won't be that useful outside of a deployment's warmup phase (that's when the slot is started).

Kristian Adrup
Kristian Adrup Mar 17, 2021 10:01 PM

@Anders you write that the routing rule is removed just before swap, but that doesn't seem to be the case as I continue to get x-ms-routing-name and TiPMix cookies set from the site. I'm trying to get the most out of the China CDN by caching markup and these cookies are affecting my hit ratio negatively since Cloudflare don't want to cache something with a set-cookie. Like you say the slot is stopped after swap, so there's no point in keeping the routing rule around. Any help on this would be appreciated.

Kristian Adrup
Kristian Adrup Mar 18, 2021 12:15 AM

Hello again! After looking att more sites, I see that only about a third of our DXP sites set these routing cookies. That seems promising. Hopefully you know what the issue is. They all use paasportal deployments if that matters.

Anders Wahlqvist
Anders Wahlqvist Mar 18, 2021 08:02 AM

@Kristian Adrup: That does sound a bit weird. We do cleanup the routing rules after each deploy so it's definitely not expected. The only thing I can currently think of is if a routing rule has been left there (potentially for another slot on the web app used during some migration job or something in the platform). Doesn't affect the web app per se but could explain why you still see these cookies. Could you send in a support ticket and mention my name in it and ask them to escalate it (could mention this blogpost as well)? Then I can get some environment information and investigate the root cause.

Please login to comment.
Latest blogs
Telemetry correlation for Scheduled Jobs in Optimizely

I previously demonstrated how to correlate telemetry to Azure Application Insights within a Hangfire job. But how about those jobs that are built a...

Stefan Holm Olsen | Mar 23, 2023 | Syndicated blog

Fixing Optimizely Content Syncing/Caching Issues on the DXP pre CMS.Core 12.13.0

Hi all, With our recent deployments to the DXP for .NET 6 projects (one a new build and one an upgrade) our clients had raised issues where there...

Scott Reed | Mar 23, 2023

Handle hostnames, schedule jobs and role access when synchronizing content

The Environment Synchronizer module helps you to set your environment into a known state after synchronizing databases between environments. In thi...

Ove Lartelius | Mar 23, 2023 | Syndicated blog

4 tips and tricks for Hangfire on Optimizely CMS

Here are four useful tricks I always apply to any site where I use Hangfire (code included).

Stefan Holm Olsen | Mar 21, 2023 | Syndicated blog