We have a Sitecore system running in containers, and we wanted to add a new publishing target. This is another copy of the WEB database; ours is called “preview”, and it is so that editors can check published content before it goes live.

I followed Sitecore’s documentation about how to do this – and do take note of steps 4 and 5. They’re new, and I missed them to begin with:

• In the App_Data\items\ folder, make a copy of the Web folder.
• Rename the copy of the folder and the .dat file inside it. Use the database name (for example, web_preview) instead of web for the folder name and the file name (so the filename is similar to items.web_preview.dat).

It turns out that’s important – without it you’ll get an exception on startup.

However, after doing that, we still had problems with our preview database; the CM server kept throwing an exception.

From the Sitecore logs we could see the instance was shutting down just after it tries to cache content from our new preview database at startup. We also found if we removed the configuration for preview then the site worked just fine. So it was definitely related to our new publishing target. We began to suspect the Connection String.

Now, our instance is running in containers, so the connection strings are… interesting. They are NOT defined in connectionstrings.config, like you might be used to. This was our connectionstrings.config inside our container…

As you can see, those connection strings are clearly dummy default data; they’re not going to connect anything. Rather, the connection strings for our instance are defined in environment variables that are set on our pod when it is created – note the configBuilders attribute at the defined at the top of the connection strings file. This is the YAML that defines those environment variables (and note, it is using other variables within the strings).

These connection string environment variables are then read by a configuration builder, which makes them available to the application:

You can see that it matches the settings based on a prefix “SITECORE_CONNECTIONSTRINGS_”, and we assumed that those then became our connection strings. We assumed that if we added the environment variables in for our “Preview” connection string, then it would be available, and simply work.

However, we were wrong. We missed something – the “Strict” mode mentioned above. Documentation about this is here, but here’s the essential bit:

Okay, so Strict mode requires that the setting already exists, and it will replace it’s value. We had assumed that the behaviour was like Greedy mode – that it would just add the connection string even if it doesn’t exist.

It seems that there are 2 options to fix this – we could change to use Greedy mode, but we weren’t sure if that would affect anything else, or we could add a preview connection string into our connectionstrings.config file – even though none of the values in there would ever be used.

That’s what we did. It means that in strict mode there is a pre-existing value for the Configuration Builder to replace the value of.

Tada! Problem fixed, and our preview database now works in our containerised CM.