Sitecore Content Delivery – Error after upgrade EXM 3.5 [SOLVED]

Couple weeks ago I was working on a Sitecore upgrade from 8.2 update 2 to 8.2 update 5 in order to also get EXM updated from 3.4 to 3.5 due Azure requirements.

My scenario had a Content Delivery and a Content Management which was properly upgraded to Sitecore 8.2 update 5 & to EXM 3.5 by following their upgrade guides.

I managed to get Sitecore 8.2 update 5 and EXM 3.5 in both nodes, however, Content Delivery keeps showing the following error after received the EXM 3.5 files.

1

The requested failed with the error message:

<html><head><title>Object moved</title></head><body>

<h2>Object moved to <a href=”/404?item=%2femailcampaign%2fecmclientservice&user=extranet%5cAnonymous&site=modules_website”>here</a>.</h2>

</body></html>

CRAP! What am I going to do?

Well, let’s double check the EXM Upgrade Instructions…

maxresdefault

AHA! Found something interesting…

“During the installation, all the .aspx pages, .asmx web services, and the .ashx handlers have been moved to the \Sitecore\modules\Web\EXM folder of the instance.”

The EXM Upgrade Instructions suggested applying a URL Rewrite rule in IIS

<rewrite>
<rules>
<rule name="ExmSitecoreFolderRule">
<match url="^(.*)ConfirmSubscription.aspx|DedicatedDispatchService.asmx|ECMClientService.asmx|RedirectUrlPage.aspx|RegisterEmailOpened.ashx|Unsubscribe.aspx|UnsubscribeFromAll.aspx)"/>
<action type="Rewrite" url="sitecore modules/Web/EXM/{R:2}" />
</rule>
</rules>
</rewrite>

BUT didn’t work here ūüė¶

I started compare files before vs after the upgrade, and find myself with the ConnectionStrings.config which uses ecmclientservice.asmx webservice from the Content Management node

<add name="EmailCampaignClientService" connectionString="url=http://sitecore-cm/sitecore%20modules/web/emailcampaign/ecmclientservice.asmx;timeout=60000" />

Well, as the upgrade instructions said that the path has changed, let’s see what happens

<add name="EmailCampaignClientService" connectionString="url=http://sitecore-cm/sitecore%20modules/web/exm/ecmclientservice.asmx;timeout=60000" />

ConnectionStrings.config¬†saved, re-load Sitecore¬†Content Delivery¬†node…

maxresdefault

…voil√°!

2.PNG

I hope you liked it, and thanks for reading!

And I’ll see you on my next post!

Advertisements

Sitecore 9 – From requirements perspective, what has changed?

Last year I have written a similar blog post about being at Sitecore 8.2 and I thought that everyone was excited, well, I was WRONG! I didn’t know nothing until couple weeks ago once¬†Sitecore¬†9¬†has been announced!

sitecore9-twitter-loop.gif

A lot of changes on Sitecore 9 and I am sure you will notice those as soon as you start the installation but let’s check what has changed from requirements perspective!

.NET Framework

Sitecore XP 9.0 now requires .NET Framework 4.6.2 or later, which means that our supported Operating Systems also changed

Operating System

  • Server
    • Windows Server 2016
    • Windows Server 2012 R2
  • Workstation
    • Windows 10 (32 & 64-bit)
    • Windows 8.1 (32 & 64-bit)

Please note that accordingly to Sitecore Installation guide 9.0 the following Operating System are not compatible anymore

  • Windows 2012 (64-bit)
  • Windows 2008 R2 SP2
  • Windows 8 (32 & 64-bit)

You may get yourself asking “I was able to install Sitecore 9 on my Windows 2012. Is there a reason why should I avoid to have it?”

That’s a good thing to her, Sitecore 9 running in a non-supported environment… YAY!

However, you should be aware that you might be on your own if anything goes wrong. In other words, quoting Mark Cassidy (again!)

It comes down to support [read more…]

Database

  • Microsoft SQL Server 2016 SP1
    • It is the required and ONLY supported version for the Experience Database (xDB)
  • Microsoft SQL Server¬† 2014 SP2
    • Does not support the Experience Database (xDB)

“Sitecore XP 9.0 rev. 171002 does not currently support MongoDB or Oracle database for the Experience Database (xDB). Support will be added in future versions of Sitecore.”

Search

  • Solr 6.6.1
    • Solr now is the default search provider
  • Azure Search
    • Now supported but for Azure Cloud PaaS deployments only
  • Lucene
    • Lucene only supports Content Search and does not support xConnect

And there’s more….

excitedSitecore9

Sitecore Installation Framework (aka SIF), xConnect, SSL everywhere and lot of new things but these are topics for a later conversation, until then here are good articles to get yourself familiar with Sitecore9

Thanks for reading, and I hope you enjoyed it!

And I’ll see you on my next post!

 

Sitecore – Heartbeat.aspx throws Error 500 (SOLVED)

A few weeks ago I was working in an installation using Sitecore 8.2 update 2 in a Virtual Machine at Azure.

As per you can see in the diagram below, I have 2 Content Delivery behind a Load Balancer to split the traffic.scenario

After setting up the Azure Load Balancer, I noticed that the traffic never went through and the¬†Virtual Machines¬†weren’t responding on¬†HTTP, so I have decided to test it locally.

Connect locally, and make sure Sitecore is alive

I connected in both CD1 & CD2, and as expected Sitecore loaded up just fine!

Weird! I might be missed something at Azure Load Balancer level.

Connect to Azure Portal and check Load Balancer configuration

I checked configuration by configuration until reached out Health Probe which is used to verify if the website is available or not

healthprobe

So, my HealthProbe is looking for /sitecore/service/heartbeat.aspx, and for some reason cannot use it which is causing the failures to access the website from outside passing by the Azure Load Balancer.

Connect locally, and make sure Heartbeat.aspx works

I connected one more time on both CD1 to access the Heartbeat address http://localhost/sitecore/service/heartbeat.aspx and it was failing with the following error message

heartbeat.aspx_error.png

The same error was occurring on CD2, so let’s dig in!

Check Sitecore logs for detailed information

In Sitecore logs, I have found the following entry

Sitecore_heartbeat_logs

At least tells me something, and looks like Heartbeat didn’t like the way one of my databases in¬†ConnectionStrings.config¬†is set but which one?

I have googled the error and found a post from my colleague and Sitecore MVP Glen McInnis named Azure Traffic Manager and Sitecore Herartbeat where he shows an example to exclude LocalSQLServer and Webforms Remote using Sitecore.Services.Heartbeat.ExcludeConnection inside of Sitecore.config

However, at this point, it wasn’t clear which database was the issue – if any! – and I had to do it by trial and error. And as expected the last show did the trick!

Reporting.apikey was the root cause of it, and accordingly to Sitecore Database Connection Strings for Configuring Servers it is optional for Content Delivery and Content Management Servers!

Well, if that’s the case, then I have two options:

1.Comment out directly on ConnectionStrings.config

<!– <add name=”reporting.apikey” connectionString=”” /> –>

OR

2. Add a proper exclusion using Sitecore.Services.Heartbeat.ExcludeConnection inside of Sitecore.config

<setting name=”Sitecore.Services.Heartbeat.ExcludeConnection” value=”LocalSqlServer|reporting.apikey” />

Recommended read

  1. Sitecore Heartbeat
  2. Azure Traffic Manager and Sitecore Heartbeat
  3. Creating an Internet-facing load balancer using the Azure portal

I hope you liked it, and thanks for reading!

And I’ll see you on my next post!

WebDAV must be disabled on Content Delivery Server

While I was playing around with Sitecore Diagnostics Tool, I faced some problems with a WebDAV error in my Content Delivery node that says

webdav_error

WebDAV must be disabled on Content Delivery server

WebDAV is enabled. It is recommended to disable this feature on CD servers using the WebDAV.Enabled setting

After googled it, I’ve followed¬†these steps from Alex Shyba’s blog

  1. Remove WebDAV config references within log4net
  2. Remove WebDAV config references within system.WebServer
  3. Remove WebDAV config references within httpHandlers
  4. Disable Sitecore.WebDAV.config

THE ERROR SIMPLY DIDN’T GO AWAY! What would be my next option?!?! Let my friends from Sitecore StackExchange know, and that’s what I did when I asked this question

Sitecore Diagnostics Tool shows WebDAV must be disabled on CD but it is already

One more time Jo√£o Neto shows up and said

The assembly that evaluates if the WebDAV is enabled is the Sitecore.DiagnosticsToolset.Tests. I managed to disassemble it and found that it checks the following Sitecore configuration to determine whether WebDAV is enabled or not:

/configuration/sitecore/settings/setting[@name=’WebDAV.Enabled’]
/configuration/sitecore/pipelines/initialize/processor[@type=’Sitecore.Pipelines.Loader.CheckWebDAVConfiguration, Sitecore.Kernel’]
/configuration/sitecore/pipelines/preprocessRequest/processor[@type=’Sitecore.Pipelines.PreprocessRequest.WebDAVCustomHandler, Sitecore.Kernel’]
/configuration/sitecore/pipelines/group[@name=’WebDAV’]
/configuration/sitecore/webdav
/configuration/sitecore/scheduling/agent[@type=’Sitecore.Tasks.CleanupFDAObsoleteMediaData’]
/configuration/sitecore/scheduling/agent[@type=’Sitecore.Tasks.WebDAVOptionsCleanupAgent’]
/configuration/sitecore/mediaLibrary/mediaPrefixes/prefix[@value=’$(webDAVPrefix)’]

Based on that answer, I went back to my Sitecore instance and thought that ShowConfig.aspx might show it if still enabled

Once I accessed http://sc81u0/sitecore/admin/showconfig.aspx, I searched item by item listed in the Sitecore.DiagnosticsToolset.Tests

  • WebDAV.Enabled
  • Sitecore.Pipelines.Loader.CheckWebDAVConfiguration, Sitecore.Kernel
  • Sitecore.Pipelines.PreprocessRequest.WebDAVCustomHandler, Sitecore.Kernel
  • WebDAV
  • Sitecore.Tasks.CleanupFDAObsoleteMediaData
  • Sitecore.Tasks.WebDAVOptionsCleanupAgent
  • webDAVPrefix

It turns out that the parameter Sitecore.Tasks.CleanupFDAObsoleteMediaData was in ShowConfig.aspx, which means it was enabled, and to my surprise inside of SwitchMasterToWeb.config as you notice in the image below

SitecoreTasksCleanupoFDAObsoleteMediaData

As SwitchMasterToWeb.config must be enabled in a Content Delivery environment, the solution was to comment out the following code

Before comment

commentSwitchMasterToWeb

After comment

commentSwitchMasterToWeb2

After saving SwtichMasterToWeb.config, I ran the Sitecore Diagnostics Tool again and the error didn’t show up!

IMPORTANT

Ensure that the SwitchMasterToWeb.config file is applied as the latest one in the list of configuration changes.

BONUS

For those – as myself – didn’t know what Sitecore.Tasks.CleanupFDAObsoleteMediaData is used for, I’ve asked in Sitecore StackExchange group prior to¬†publishing this post.

What is Sitecore.Tasks.CleanupFDAObsoleteMediaData in SwitchMasterToWeb.config?

Accordingly to Mark Cassidy

“FDA is short for File Drop Area – as in WebDAV File Drop Area
It’s a field type that allows content editors to drag and drop media data (well files) directly into the CMS via WebDAV.
It machine generates folder names to drop these files into; this cleanup task will remove any of these machine generated folders that may no longer be in use.”

And by enabling SwitchMasterToWeb you enable the CleanupFDAObsoleteMediaData, and seems that Sitecore Diagnostic Tool understands that this option is related to WebDAV.

Thanks for reading, and I hope you enjoyed it!

And I’ll see you on my next post!

System admins and Sitecore: Installing Sitecore and its different roles

This is the next article in a series dedicated to system administrators working with Sitecore.

Assuming you have read the first part of this series dedicated to System Administrators, you should now have some background in Sitecore and know that there are 12 ways for systems admins to contribute before, during and after a implementation.

Read more…

 

Using Sitecore Diagnostics Tool

Wouldn’t be great to get an inspection in your Sitecore instance prior to deliver it either to development or in a production environment?

Well, couple weeks ago while discussing some points about Sitecore instances, my colleague Jo√£o Neto introduced to me the Sitecore Diagnostics Tool which seems to be a great tool where you’ll be able to automatically diagnosing Sitecore sites.

The first thing to do, let’s download and install the tool! The installation is a pretty straightforward process but if you prefer, I’ve listed the instructions here.

Assuming that you’ve installed the SDT, let’s move forward and click Next in the Welcome Screen

Configure resources to run diagnostics on

At this point, you can either select a Local Sitecore Instance or an SSPG Package, for now, I’ll choose a Sitecore instance previously installed, and click Next

ResourcetoRun

Select tests to run by choosing appropriate categories

Here you’ll be able to choose what sort of tests will be applicable to your Sitecore, and in which categories would you like to review it.

For example, my local Sitecore is a Content Delivery node and I’d like to check for Server Configuration then I’d choose as follows

TestperCategory

And click Start to perform the test.

It shouldn’t take long but you will see a similar¬†Running diagnostics¬†screen

RunningDiagnostics

Once tests are completed, you’ll receive a notification that¬†Analysis completed¬†then click¬†View Results¬†at the bottom

AnalysisCompleted

And¬†View the results here, simply click on the C:\users\…\SitecoreDiagnosticsReport link – just in case you missed, the reports are located here C:\users\[username]\Documents\Sitecore\Diagnostics Tool\

Results

Once you open the HTML file, it will look like the image below

Report1.PNG

By scrolling down in your report, you’ll notice some warnings and errors if any. For example, my report shows that I forgot to enable couple config files as you can see

Report2

Before moving forward and let everyone knows that the Sitecore is ready to go, I’ll need to fix those issues and guarantee that my Sitecore that plays Content Management role is properly set.

Once I get the errors fixed, the best thing is that you can simply click Restart at the bottom, and all the options from the last test will be automatically chosen for an easier way to verify your instance again.

I hope you liked it, and thanks for reading!

And I’ll see you in my next post.