Monday, February 29, 2016

Tips for configuring the SDL Tridion Cache Channel Service

When installing and configuring cache, you may have one of these two scenarios below:

Scenario 1: The deployer, CCS and websites all reside in the same server

When the deployer, CCS and websites are running on the same server, open the cd_storage_conf.xml of one of these components and make the following changes:
·         Enable caching by setting the following flag to true:
            <ObjectCache Enabled=“true">
·         Leave the RMI section commented out:

<!-- RMI CacheChannel Connector example                              
 <RemoteSynchronization Queuesize="128" ServiceMonitorInterval="10000" FlushCacheDuringDisconnectInterval="20000">
     <Connector Class="com.tridion.cache.RMICacheChannelConnector" Host="" Port="1099" />
</RemoteSynchronization>  -->
·         Enable the item types that you would like to cache, by explicitly adding the cached element and setting it to true:

<Item typeMapping="Metadata" cached="true"(..)/>
<Item typeMapping="ComponentVisit" cached="true" (..)/>
<Item typeMapping="DynamicLinkInfo" cached="true"(..)/>
After saving these changes, ensure to copy this new version of the cd_storage_conf.xml to the other two components, as the deployer, CCS and websites need to have a matching cd_storage_conf.xml.

Scenario 2: The deployer, CCS and/or the websites reside in different servers

  1. Open the cd_storage_conf.xml of the deployer and make the following changes:
·         Enable caching by setting the following flag to true:
<ObjectCache Enabled=“true">

·         Enable the RMI section:
 <RemoteSynchronization Queuesize="128" ServiceMonitorInterval="10000" FlushCacheDuringDisconnectInterval="20000">
<Connector Class="com.tridion.cache.RMICacheChannelConnector" Host="" Port="1099" />
·         Change the IP address and port of the ConnectorClass to match the IP address of the CCS, for example:

<Connector Class="com.tridion.cache.RMICacheChannelConnector" Host="" Port="1099" />

·         Enable the item types that you would like to cache, by explicitly adding the cached element and setting it to true:

<Item typeMapping="Metadata" cached="true"(..)/>
<Item typeMapping="ComponentVisit" cached="true" (..)/>
<Item typeMapping="DynamicLinkInfo" cached="true"(..)/>

Save the changes and restart the deployer application. 

2. Navigate to the cd_storage_conf.xml of the CCS that is running on a different server than the deployer. Make the following changes to the cd_storage_conf.xml:
·         Enable caching by setting the following flag to true:
            <ObjectCache Enabled=“true">
·         Leave the RMI section commented out:

<!-- RMI CacheChannel Connector example                              
 <RemoteSynchronization Queuesize="128" ServiceMonitorInterval="10000" FlushCacheDuringDisconnectInterval="20000">
     <Connector Class="com.tridion.cache.RMICacheChannelConnector" Host="" Port="1099" />
</RemoteSynchronization>  -->
·         Copy the item types configured to be cached of the deployer’s cd_storage_conf.xml, following the example above:

<Item typeMapping="Metadata" cached="true"(..)/>
<Item typeMapping="ComponentVisit" cached="true" (..)/>
<Item typeMapping="DynamicLinkInfo" cached="true"(..)/>

      Save these changes and restart the Tridion Cache Channel Service.
      3. Navigate now to the website’s cd_storage_conf.xml and if it is running on the same server as the deployer, make the same changes as in step 1. Otherwise, if the website is running on the same server as the CCS, then make the same changes as proposed in step 2.

Note: Points to keep in mind when you are configuring scenario 2:

When there are multiple network cards, the following error might be logged on the cd_core.log when trying to connect to the CCS:

Could not connect to Cache Channel Service on startup, will attempt again in 10000ms
com.tridion.cache.CacheException (…)
Caused by: java.rmi.ConnectException: Connection refused to host:; nested exception is: Connection timed out: connect
at sun.rmi.transport.tcp.TCPEndpoint.newSocket(Unknown Source)
at sun.rmi.transport.tcp.TCPChannel.createConnection(Unknown Source)
at sun.rmi.transport.tcp.TCPChannel.newConnection(Unknown Source)
at sun.rmi.server.UnicastRef.newCall(Unknown Source)

This error occurs because RMI picks up randomly one of the available IP addresses, causing these connectivity issues. The solution is to force the RMI to pick up a specific IP address. This needs to be configured in the server that has the deployer and/or website that wants to communicate to the CCS running on another server.
To achieve this, open the Windows Registry and navigate to HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Tridion\Content Delivery\General  and adding this new String jvmarg1 with value: -Djava.rmi.server.hostname=correctIP.

If you don't see the Tridion key present in the Windows Registry, go ahead and create that entry and the other ones too.

This is how the new String should look like:

I add these screenshots because I had some difficulties finding an example that showed how I should add this entry. This will require a restart of the CCS for changes to be refreshed.

When enabling RMI, keep in mind that:
Java assigns a random port for the CCS (besides the one where the CCS is running) and the deployer needs full access to that server to be able to subscribe and send messages to the Cache;
This requires completely disabling the firewalls active on all servers involved for the communication to pass through. If, for security reasons you cannot disable these firewalls, you can opt for installing the deployer and CCS in the same server instead.

Wednesday, July 1, 2015

SDL Tridion: How to enable SSL (Secure Sockets Layer) in a .net deployer?

This article assumes that you have a valid SSL certificate ready. Below you can find the steps that are required to be able to successfully publish to a HTTS deployer that has SSL enabled. 

Open IIS and navigate to your deployer website and, in the ‘Features’ view select ‘SSL Settings’;

Check the box ‘Require SSL’ and in the ‘Client Certificates’ choose Accept.

Add a new HTTPS Binding to your deployer:
a. Select Type: https;
b. By default, it will assign port 443, change it if desired;
c. Fill in the hostname;
d. In the SSL Certificate, add the certificate you have created.

Select again your HTTP deployer application and, in the ‘Features View’, select ‘Authentication’ and ensure that only ‘Basic Authentication’ is enabled.

Open the web.config of your deployer and ensure to add this section inside the<configuration> element:

                   <binding name="HttpsBinding" maxReceivedMessageSize="2097152" maxBufferSize="2097152">
                   <readerQuotas maxArrayLength="81920" maxBytesPerRead="5120" maxDepth="32" maxNameTableCharCount="81920" maxStringContentLength="2097152" />
                   <security mode="Transport">
                       <transport clientCredentialType="None" />

Import your certificate as mentioned in the SDL Tridion Docs

Restart your Transport Service and the Deployer application.

Test that you can access the new https upload page by opening the browser and typing: https://servername:443/httpupload.aspx

If this works, you are now ready to add your new HTTPS publication target and to start publishing!

Thursday, May 7, 2015

SDL Tridion: Tips to troubleshoot and resolve the 'Throttling' status

The throttling status should be a temporary state, so although you might see some items in the Publishing Queue with that state, it should resolve itself once the deployer has available threads to pick up more packages. In case the items stay 'stuck' in this status, there are a few things you can check that I enumerate below:

·         As mentioned in the documentation, ensure that the window size is equal to or larger than the total number of Transport Service threads configured on the Content Manager side. This settings can be found in the cd_transport_conf.xml, as follows:

<Workers NormalPriorityPoolSize="5" HighPriorityPoolSize="5" TransportPriorityPoolSize="5"/>

By default, this section is commented out and these are the default values. If the deployer’s window size is lower than 5 then you need to change it to ensure that it is set to 5 or higher.

·         Check if the database maintenance tasks for the broker database are in place and the frequency that these tasks are being executed; To rule out that it is database related, re-run the maintenance tasks and verify if that helps.

·               The throttling might be related to large items being deployed and therefore requiring a longer database connection. You can increase the transaction timeout present in the cd_storage_conf.xml. By default, this timeout is set to 2 minutes (120000 milliseconds):

 <Transaction Timeout="120000" MonitorInterval="5000"/> -->

Start with increasing this timeout to 5 minutes and verify if that helps.

·         Check the transport timeout setting and verify if the transport is polling for a status for long enough:
o   By default, the transport polls for 30 minutes or 900 times, as set in the cd_transport_conf.xml:

<Polling MaxAttempts="900" Timeout="15" Interval="5000"/>

o   If the deployer has a high load of packages to handle, the timeout setting or maxAttempts might not be sufficient. If you see that, despite the throttling status displayed in the publishing queue, that the items are successfully deployed, then increase the timeout setting so that the transport can poll the status for a longer period of time. I usually start by setting the timeout to 30 minutes, as follows:

<Polling MaxAttempts="900" Timeout="30" Interval="5000"/>

Thursday, March 26, 2015

SDL Tridion: Items might fail to deploy with message: ' org.hibernate.exception.DataException: String or binary data would be truncated'

Regardless of the SDL Tridion version you are running on, when deploying items, you might experience the following message:

org.hibernate.exception.DataException: String or binary data would be truncated
at ~[sqljdbc4.jar:na]
at ~[sqljdbc4.jar:na]
at ~[sqljdbc4.jar:na]
at$PrepStmtExecCmd.doExecute( ~[sqljdbc4.jar:na]
at ~[sqljdbc4.jar:na]
at ~[sqljdbc4.jar:na]

In the occasions that I have come across this error message, it was due to the transport package containing multimedia components with Russian characters. The title of these multimedia components then contains non-legal characters for the URL which requires the URL encoding to convert the title into a readable URL. To accomplish that, it will introduce more characters and then exceeding the character 255 character limit. This limit is set at both file system and database levels.

To overcome this error message and publish the items successfully, you can choose one of the following options: 
  •  Avoid non-legal characters in the file names; 
  • Decrease the length of the file name.

Friday, March 13, 2015

SDL Tridion: How to resolve 'com.tridion.configuration.ConfigurationException: No RequestData for WebGUI' when enabling WebGUI monitoring in the cd_monitor_conf.xml?

While enabling the WebGUI monitoring in the cd_monitor_conf.xml of SDL Tridion 2011 SP1 HR2, I got the following error message:

 ERROR Agent - TMA-AG-30000 Failed to get Agent instance
com.tridion.configuration.ConfigurationException: No RequestData for WebGUI
    at com.tridion.monitor.polling.XMLHTTPHealthMonitor.configure( ~[cd_monitor.jar:na]
    at com.tridion.monitor.Agent.configureHealthMonitors( [cd_monitor.jar:na]
    at com.tridion.monitor.Agent.configure( [cd_monitor.jar:na]
    at com.tridion.monitor.Agent.<init>( [cd_monitor.jar:na]
    at com.tridion.monitor.Agent.getInstance( [cd_monitor.jar:na]
    at com.tridion.monitor.Agent.main( [cd_monitor.jar:na]

At first I had this configuration:

<XmlHttpServiceHealthMonitor ServiceType="WebGUI" PollInterval="1m" TimeoutInterval="30s">
            <Request URL="http://servername:portnumber/WebUI/Models/TCM54/Services/General.svc/GetUserName"/>
             <Authentication Scheme="NTLM" Domain="domain" Username="username" Password="password"/>
            <!-- <Header Name="CustomHeader" Value="CustomValue"/> -->
            <!-- <Response SuccessPattern="/string[text()='domain\user']"/> -->

And looking at the documentation, it mentioned that the RequestData element is optional, I thought it wouldn't be required. Moreover, I wasn't sure what exactly RequestData it expects.

I then found out with the help of a colleague that we indeed need to specify the RequestData element as follows:

         <XmlHttpServiceHealthMonitor ServiceType="WebGUI" PollInterval="1m" TimeoutInterval="30s">
            <Request URL="http://localhost:81/WebUI/Models/TCM54/Services/General.svc/GetUserName" RequestData="CoreServiceRequest.xml"/>
             <Authentication Scheme="NTLM" Domain="." Username="administrator" Password="tridion"/>
            <!-- <Header Name="CustomHeader" Value="CustomValue"/> -->
            <!-- <Response SuccessPattern="/string[text()='domain\user']"/> -->

After applying this change, we need to create the CoreServiceRequest.xml (under Tridion_Home\bin) with this content:

<s:Envelope xmlns:s=""><s:Body><GetCurrentUser xmlns=""/></s:Body></s:Envelope>

When restarting the Tridion Monitoring Service, it will now log:

HealthCheckStartEvent - TMA-PO-00000 Scheduled HealthCheckStartEvent for service WebGUI at

Wednesday, March 11, 2015

SDL Tridion: Why does the cd_transport.log show warning: ' JAXBUtil - State file removal failed' and how to address it?

You might come across this type of warning being logged in your cd_transport.log or cd_core.log of the server where your Transport Service is running:

WARN  JAXBUtil - State file removal failed: TRIDION_HOME\bin\transactions\tcm_0-1234-66560.state.xml

This warning is related to the Java version installed. If you are using Java 6 or higher, the jars jaxb-api.jar and jaxb-impl.jar are now embedded in the java version itself and no longer need to be available in the lib folder of your Tridion installation.
To remove this warning, check the TRIDION_HOME\lib folder and if you find these jars present, proceed to remove them. If you have a deployer(s) running in the same server, the same step will apply.
Let’s say you have removed the jars from the lib folder or they were already not there and you are still seeing this warning being logged. This could mean that the endorsed folder of a previous java version that required these jars (Java 5 and previous) is still present in the system. Navigate to the JAVA_HOME\lib\endorsed folder and if you find jaxb-api.jar and jaxb-impl.jar, proceed to remove them. After this step, restart your Tridion services and the warning should now be addressed!

Monday, March 9, 2015

Cleanup OpenSource Powershell Script - "Delete files older than x-days" - can interfere with SDL Tridion transactions folder: How to avoid this?

In my last post, I talked about how the anti-virus scan can impact publishing and which folders to ensure to exclude from scanning. 

After that post, I came across another issue that showed me that not only anti-virus scanning is to be kept in mind when configuring Tridion servers.

I came then across an issue where the items suddenly remained in 'Ready for Transport' in the Publishing Queue and then noticed that the 'TRIDION_HOME\bin\transactions' folder was no longer a regular folder but instead turned into a flat file. 

After further investigation, it turned out that there was a daily scheduled task cleaning up the transactions folder. While this is a common and recommended practice to clean up old tridion files, this task was removing the transactions folder and causing this strange behavior.

The powershell script that this scheduled task was executing, is an open source powershell script that can be found in the following link:

 If you are making using of such script on your servers, it is important to keep in mind that, by default, this script handles folder deletion as follows:  

*Default mode, only delete folders that became empty after the script deleted all files in the folder, this includes the root folder.

The moment this script is running on your server, if there happens to be any activity in the transactions folder, this script will remove its content and also the transactions folder. 

At that moment, the items will then show in the Publishing Queue that they are ‘Ready for Transport’. In such situation, you might then restart your SDL Tridion Transport Service and notice that the items will still remain in the same state. If you inspect the ‘ TRIDION_HOME\bin’ folder, it might be showing the transactions as a flat file. Please note that this behavior will only happen if, at the time the script was executed the Transport was busy also processing items. 

To ensure that you don’t come across this issue, you will need to modify the script to include one of the following switches that are available:

* -NoFolder switch, no folders are deleted including the root folder.
* -CleanFolders switch, all empty folders in the path will be deleted, this however excludes the root folder.

As an example, you would then update your script to something similar to this:

# Cleaning Transactions folder
.\deleteold.ps1 -FolderPath "D:\Tridion\transactions" -FileAge 5 -log "D:\Tridion\log\cleanup" –autolog –NoFolder


# Cleaning Transactions folder
.\deleteold.ps1 -FolderPath "D:\Tridion\transactions" -FileAge 5 -log "D:\Tridion\log\cleanup" –autolog –CleanFolders

After this change, your Transport Service will always happily process items!

Note: After reading this blog post, a customer reported that this issue can also happen when there are still files present in the transactions folder and not just when the folder is empty. Please keep also this in mind and ensure to implement the change above to completely avoid the issue also in the scenario that there are some old .state.xml files left in the transactions folder.