I've been working on an international deployment of Sitecore recently, and resolving some problems around how publishing raises remote events has demonstrated that there are some things about the publishing process that I didn't entirely understand... I doubt this is a common scenario, but it still seems worth writing down what I've learned – So here's another crib sheet for my future self:
I love that lead to some fun... So I moved eagerly to Let's Encrypt when the tooling supported Windows reasonably well, and set myself up with a certificate with multiple SANs authenticated via their "HTTP proofs" mechanism, and it all worked fine, despite it being a bit of a pain that I had to expose port 80 for sites I only wanted accessible via port 443.
But I realised recently that they now offer wildcard certs that would make my life simpler, and that there is now decent support for DNS-based proof-of-ownership. So recently I tried moving my server over to this model – and there was a bit of friction. Entirely PEBCAK though – so I'm writing this down for the next time I forget how DNS works 😉
When I wrote my first blog post here
**
in February 2014 I
definitely
did not imagine still being at it 200 posts and five-and-a-bit years later. Originally I set myself a challenge of writing something once a week for a year, just to see if I could motivate myself to do it.
Honestly, I didn't really think I'd manage to keep it up for the entire twelve months, let alone still be here now – but somehow it's become part of my routine. I may have scaled down to a post every fortnight, as kids and other responsibilities took over more of my time, but the process of making myself notes about issues I encounter as I'm working, and then writing them up when I have free moments has become part of my working life now...
Following on from my recent post about how I was able to mess up my life by getting Marketing Automation connection strings wrong, I hit another interesting issue with MA – this time around content languages...
I had another of my fun chats with Sitecore Support recently, for an issue that seemed to get no useful results in Google when I looked. So, as is my way, I'm filling that search-engine void today. This turned out to be entirely my fault – but it seems like the sort of mistake that others might encounter too... So if you've deployed a distributed instance of Sitecore and found Marketing Automation was behaving oddly, read on...
I hit an interesting issue recently: Some code that worked fine on a QA instance of Sitecore had been deployed for UAT and was now failing with an odd error message. Whilst this issue was entirely our fault, there wasn't much in Google about the error messages I was seeing, so I'm trying to correct that problem today...
I've been looking at adjusting SIF scripts for a production deployment recently, and realised that sometimes you'd like SIF to generate random passwords for you, but you need them logged so you can reuse them in scripts you're crafting for other roles. It doesn't do that out of the box, but it turns out it's actually quite simple:
I was asked to do some configuration on a remote computer recently, and discovered that the security-concious network admins had locked down the ability for me to share my local computer's files with the server via RDP and the ability to get to services like OneDrive. I had a collection of config files I had been asked to deploy, and manually creating each file on the server and copying over its contents seemed like a lot of hassle. So I tried a trick with PowerShell to make my life easier...
One of the projects I'm working on at the moment came with a requirement to change Sitecore v9.1 from running with the default SQL Security accounts to trusted connections using specific Active Directory accounts that the client provided. While there's a bit of work to do to enable this, it shouldn't be too tough. But trying to be a bit clever, I hit upon an issue which seemed worth documenting...
A couple of times recently, I've found myself needing to deploy files that come wrapped in a
.tar.gz
archive onto servers. On your desktop that's not too much of a problem – you just run the installer for your preferred
3rd party tool, or maybe
use the new Unixy shell
and you get on with it. But on client servers security can be higher and you don't always get the option to run any old installer. So I needed an alternative...