Sitecore Express Upgrade Tool 2.0 Issue

2017-07-102017-07-10 Andy BurnsMigrationLeave a comment

So, you’re doing an upgrade. You copy the live system, run through the upgrade, and test it, before repeating the ‘upgrade’ bit during content freeze with the latest data. So far, so normal; it’s a sensible way to check your system before the big update.

Picture this, if you will. You’ve done the upgrade with a snapshot of the data. It’s taken months. You tested, fixed, tested, fixed, and you’re happy to start the content freeze, run the express migration tool, and go live. So you run the Express Migration tool 2.0, and then try logging in as Admin to check it worked…

Continue reading “Sitecore Express Upgrade Tool 2.0 Issue” →

NullReferenceException in Sitecore.ExperienceExplorer.Business.Pipelines .HttpRequest.EnableExperienceModePipeline.Process

2017-05-042017-05-03 Andy BurnsDefaultSite, Sites, webconfigLeave a comment

Recently I was upgrading a site to Sitecore 8.2.1, and I received the following error:

Okay, WTF? There’s not a lot of information about this error, and I’d never seen it before. I ended up doing my usual trick – decompiling Sitecore to see what this method does. Here’s what I found…

…and the bit underlined in red set my “stupidity radar” screaming. This line is:

string database = SiteContext.GetSite(Settings.Preview.DefaultSite).SiteInfo.Database;

If GetSite() returns null, you’ll get a null reference exception, because they didn’t bother to check the returned variable before trying to use its ‘SiteInfo’ property.

It does offer a clue, though. Our upgraded system lacks a site called ‘website‘. That is, in our config, under the <sites> node, there is no <site ... > called ‘website‘. However, the DefaultSite setting in Sitecore.config still had its default value of ‘website‘.

We changed it to the name of our site, and this error was resolved.

This server could not prove that it is … its security certificate is from [missing_subjectAltName]

2017-05-03 Andy BurnsChrome, HTTPS, SSLLeave a comment

Yesterday, I had a working development site suddenly start throwing SSL errors:

The error message was:

This server could not prove that it is [Server Name] its security certificate is from [missing_subjectAltName]

Huh? What broke this?

Well, it turns out that Chrome had updated to Chrome 58, which removed support for the “Common Name” field. Instead, we’re supposed to use the “Subject Alternative Name” (SAN) field. That’s unfortunate; the IIS ‘Create Certificate Request‘ option we’d used resulted in a certificate with no Subject Alternative Name field. That could be a result of how it was handled – I didn’t create the certificate – but it looks like Windows MakeCert doesn’t handle Subject Alternative Names, so I wouldn’t be surprised if this is a general Windows issue.

The SSL cert continued to work without a SAN just fine in IE, but Firefox and Chrome now demand it, and so were throwing SSL errors.

Now, it seems that the Subject Alternative Name is what we’re actually supposed to use, and that publicly trusted certs have used both fields for years – but in our development server, using our own CA, that wasn’t the case.

See How to Request a Certificate With a Custom Subject Alternative Name.

Sign up for Sitecore Security Notifications

2017-04-26 Andy BurnsSecurityLeave a comment

I was asked the other day, where do you sign up for Sitecore’s security notifications? Well, I get them – but I don’t think I ever did. I suspect it was just part of doing their developer’s course.

However, you can apparently do this here: http://www.sitecore.net/landing/xc/2016/xc-ops-sitecore-security-notifications

I’ve not tried it, though.

Sitecore shell wouldn’t work over HTTPS

2017-04-26 Andy BurnsHTTPSLeave a comment

I was working at a customer recently who’s Sitecore instance wasn’t accessible over HTTPS. It was a single server, and the site itself was working just fine over HTTPS, so that begged the question – why?

The error we were getting was:

Sitecore.Context.ContentDatabase returns null.

We were using HTTPS, and it’s worth noting that rather than redirecting all HTTP traffic to HTTPS with IIS, they were using C# code and a Response.Redirect() call in their page itself, which is… unusual. It also means that HTTP traffic to Sitecore shell is not redirected – the content page layout isn’t loaded, so their redirect wouldn’t happen.

Eventually, I found the following in a patch file:
<site name="shell"> <patch:attribute name="port">80</patch:attribute> </site> <site name="login"> <patch:attribute name="port">80</patch:attribute> </site>

Interesting. Shell and login were being tied to port 80 – but HTTPS uses 443.

I removed this patch, and suddenly Sitecore was available over HTTPS again.

For Sitecore, specify MongoDB connections in lower case…

2017-03-31 Andy BurnsMongoDBLeave a comment

You wouldn’t think this was 2017, but here we are again struggling with upper and lower case again.

In a Sitecore instance I had the following connection string to MongoDB:

<add name="analytics" connectionString="mongodb://mongo.ourserver.local/XXXX_analytics" />

However, something was wrong with the instance; installing packages on it didn’t work (which is VERY strange – why does it need MongoDB? That doesn’t make sense! Anyway…)

Looking in the log, I found:

36404 00:00:26 ERROR Exception when executing agent processing/taskAgent Exception: MongoDB.Driver.MongoCommandException Message: Command 'findAndModify' failed: exception: db already exists with different case already have: [xxxx_tracking_live] trying to create [XXXX_tracking_live] (response: { "errmsg" : "exception: db already exists with different case already have: [xxxx_tracking_live] trying to create [XXXX_tracking_live]", "code" : 13297, "ok" : 0.0 }) Source: MongoDB.Driver at MongoDB.Driver.Operations.CommandOperation`1.Execute(MongoConnection connection)

Ah. So MongoDB would happily:

Try to find the repository with the name containing capitals (“XXXX_analytics”)
Correctly fail (repository doesn’t exist), and then create the repository with the name rendered to lower case (“xxxx_analytics”)
Try to find the repository with the name containing capitals again (“XXXX_analytics”)
Incorrectly fail to find the repository due to the case difference, and then try to create the repository a second time with the name renadered to lower case.

This is stupid. If one method ignores case, so should the others. I don’t mind which way it works – obey or ignore case – but it needs to be consistent.

Turn off Auth on Solr

2017-03-30 Andy BurnsSearch, solrLeave a comment

Okay, so you probably shouldn’t be doing this – but should you install Solr using the Bitnami stack – like I usually would – it will ask you to set up a usename and password to connect with.

This is a good thing (much better than MongoDB’s “Insecure by default” configuration) – but what if you don’t want it (e.g. for your shared dev Solr instance)?

Edit \solr-xxxx\apache-solr\conf\solr.conf
Set AuthType to “None”
Remove “Require User ” line
Restart service.

That should do it.

Andy Burns' Blog

Whatever I'm working on