Before I can start looking into the new features of SDL Web 8.5 I need to install it. So I thought I’d share the experience as part of this post. For those not so familiar with installing SDL Web or SDL Tridion it is a very simple process.
I’ll be using the “Single-machine example installation guide for SDL Web” guide available in the online documentation.
For my test, I’ll be using a DS11_V2 Standard configuration (2 Cores, 14GB RAM) in Microsoft Azure Cloud, running Windows Server 2016 and SQL Server 2016 SP1 Standard Edition.
This setup could easily be reproduced in Amazon AWS or on-premise, using either a shared file-system or an Amazon S3 Bucket.
Installing the CME (GUI, Databases & Services)
Follow the basic steps in the online documentation guide, briefly:
- Optional: Install Web Server Role (I like to do this before running installer, so I can remove the default website and use port 80)
- Create MTSUser account (either locally or on your domain)
- Create databases, based on your requirements, using the provided PowerShell scripts
- Run installer and follow wizard steps (optional unattended install for scripted environments)
Trying Microsoft Azure Blob Storage for Binaries
A notable difference (besides the new branding) in SDL Web 8.5 is the ability to store binaries outside of the Content Manager database. This is a big benefit, as in larger implementations these images, videos and documents can really swell the database size.
To enable it follow the steps here and the outline below:
- In the Azure Portal, create a Storage Account
- In the Storage Account, select ‘Blobs’
- Create a new ‘Container’ with Access type of ‘Blob’
- Update the Tridion.ContentManager.config file, with the associated Azure Blob Storage snippets, using
- Container name as blobFolder
- Key from Access Keys window as accountKey
- Storage account name from Access Keys window as accountName
- Restart IIS
- Upload binaries, and begin to see them appear in your Azure Blob Storage
To explore your blob storage you can use a free Microsoft tool, Storage Explorer, from which you can download and open the binaries in an appropriate program.
In terms of what appears in the SDL Web database, the change is quite simple. The binary record still exists in the database (ITEMS table), but instead of referencing a BINARY_ID (in the BINARIES table) they now have a BLOB_ID.
My exploration into this new feature has been using a new, blank database. If you’re upgrading there are migration scripts to move back and forth between the different storage options, as described here.
One thing to note on migrations, is that SDL Web relies on the configuration in the Tridion.ContentManager.config file to know where to look for binaries. When you migrate from the default database storage to one of the other options you won’t have a problem, as SDL Web knows the database details (assuming it is coded as the fallback). However, if you migrate from one of the other options to any other type make sure you have the fallbackPermanentContentStorage specified or you will see results like below. Adding the fallbackPermanentContentStorage makes the old storage mechanism read-only, so everything still works until the migration script has executed.
I also found that I needed to restart the SDL Web Content Manager Service Host service in order for changes to apply; The documentation only mentions restarting IIS.
Overall, a very simple process. I can really see this improvement being high on the list of reasons to upgrade to SDL Web 8.5 for several of my recent clients.