There are several buzzwords over the past few years that are finally starting to become realistic from a strategic and technical perspective. This has become especially clear after several announcements during Sitecore Symposium in October.
These terms and concepts have created ambiguity for Sitecore clients and partners alike as they signal significant shifts in Sitecore’s market posture.
Composable
A composable Digital Experience Platform is an integrated set of core technologies that support the composition, management, delivery and optimization of contextualized digital experiences.
It is purpose-build to be easy to use and implement, adapting to and enhancing the existing tech stack.
– Sitecore Symposium 2022
Composability puts an emphasis on choosing the best products for your business needs. This may not always mean the product you need is from Sitecore. With that said, Sitecore has most of the bases covered with their new suite of products:
Headless
Headless has been a topic in almost all conversations around Sitecore since the release of the Javascript Services (JSS) module in 2017. In order to understand what headless means, we have to take a step back and look at a pattern called Jamstack.
Jamstack
Jamstack is an architectural approach that decouples the web experience layer from data and business logic, improving flexibility, scalability, performance, and maintainability.
Jamstack removes the need for business logic to dictate the web experience.
It enables a composable architecture for the web where custom logic and 3rd party services are consumed through APIs.
Sitecore’s Headless Module seeks to create a full-featured set of APIs for accessing content to be rendered using a front-end technology of your choice. For most Sitecore clients and partners, this choice is made based on the capabilities and strengths of your team.
Sitecore has gone a step further and established a partnership with Vercel, the creators of NextJS. This partnership streamlines a development team’s ability to take a site from concept to market in a much shorter period of time than with the traditional rendering model.
SaaS
SaaS is a deployment model that stands for Software as a Service. There are two other models: IaaS and PaaS, both of which continue to be supported by Sitecore. The primary differentiator between these three deployment models is the amount of concern that the client or partner has over the underlying platform and infrastructure.
SaaS aims to minimize those concerns while providing a consistent product across the entire customer base.
Sitecore XM Cloud is the successor to Experience Platform and is a full-fledged SaaS product. It alleviates many of the challenges associated with managing the Sitecore Platform and puts them squarely on the shoulders of the experts: Sitecore. While there are some tradeoffs around customization, many of those concerns are mitigated with the composable and headless architecture, allowing customers to choose the products they need while having ultimate flexibility in how content is presented on their site.
In my next post, I’ll walk through some common roadmap scenarios for Sitecore customers who want to stay on the Sitecore path, but are looking for strategic inspiration.
In a previous post, I walked through the process of creating an Azure Active Directory tenant that can be managed by a Sitecore development team. Today, I’ll continue this thread by walking through two key concepts:
Setting up your team in Active Directory
Configuring Sitecore Identity with your Active Directory tenant
I’m approaching this post from the perspective of a development team that may need to quickly standup several instances of Sitecore to support multiple streams of project work. The idea is to create standardized, repeatable environments that only require one-time creation of users and permissions. For this reason, I’m leaving client stakeholders out of this initial setup process.
App Registration
Multiple apps can be registered with Azure Active Directory. This would allow a development team to register multiple instances of Sitecore with an Active Directory tenant. The steps for creating the registration are as follows:
Enter a name for the App and the redirect URI in this format: https://{{SitecoreIdentityHost}}/signin-oidc
Click ‘Register’
Select ‘Authentication’ and make sure that the ‘ID Tokens…’ checkbox is checked
Select ‘Manifest’, which opens a Json document. Update the ‘groupMembershipClaims’ attribute value to: ‘SecurityGroup’
Under the ‘Overview’ section, note the ‘Application (client) ID’ and ‘Directory (tenant) ID’. These are crucial for configuring Sitecore Identity.
Team Setup
Every Sitecore development team is different. Some teams are comprised of developers only. Others are fully scaled-out with architects, development (FED, BED, Sitecore), QA, Business Analysts and Project Management. I’m going to setup my Active Directory groups to mimic the structure of my team. If you have a different structure, please use this as a guide and not a prescriptive solution.
Security Groups
The first thing we’ll do is create Security Groups in Active Directory that will map to Sitecore user roles.
Open the Active Directory tenant again
Select ‘Groups’
Select ‘New Group’
Enter the Group Name and Group Description and click ‘Create’
Make sure to document the Group name and ObjectID of each group as they are created. You’ll need these for role mapping in Sitecore.
Sitecore Identity Configuration
Now that your groups are created, it is time to configure Sitecore Identity with the claims transformations for each group. These transformations will map the objectId of the SecurityGroup to a role in Sitecore. I’m using Sitecore Identity 6.0.0, which can be found here:
For simplicity, we’re going to assign the ARCH and DEV-SC Security Groups as Sitecore Admins and the other groups will be Content Authors. My templated configuration file looks like this:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Once you’ve configured Sitecore Identity to map each Security Group to a role in Sitecore, you can manually copy this file to your Sitecore Identity application in the following directory:
Once you’ve copied your file, make sure to restart the application, whether it’s local or in Azure. You can now add yourself to each of the Security Groups that you’ve created. This allows you to verify that authentication and authorization are both working as expected.
Summary
We’ve walked through the process for configuring Azure AD and Sitecore Identity to support a full-scale Sitecore development team. Once you’ve created your team, there are just a few small administrative tasks that are required for onboarding new team members or clients.
Team Members
To onboard a new team member, you must invite them to Active Directory and add them to the appropriate Security Group. To off-board a team member you must remove them from Active Directory. Sometimes this will be done for you if the team member is leaving the organization.
New Projects & Environments
When a new project is spinning up, there are two steps for enabling your Sitecore team:
Copy the Sitecore.Plugin.IdentityProvider.AzureAd.xml file that you’ve configured to your new Sitecore Identity environments.
Add an App Registration for all new Sitecore Identity environments to Active Directory
Up Next
Securing Headless Sitecore using Vercel SSO
Securing Sitecore Authoring sites
Automation
I’m working on automating this process through ARM templates and Docket asset images. More to come once I’ve proven this out.
You may never have to create another Sitecore account again
Introduction
In a previous post, I talked about why Single Sign On is the most important feature to enable early on in a project.
This is part two in a series on how to take Sitecore Identity to the Next Level. This article establishes a foundation by overcoming one of the biggest hurdles in implementing SSO with Azure Active Directory: creating and managing an Azure Active Directory organization, otherwise known as a tenant.
In a later post I’ll show you how to create your own tenant along with users and security groups. This eliminates the dependency on another team to manage a tenant for you, making it easier for your team to get up and running quickly.
If you follow these steps, you could expand on this concept by spinning up multiple Sitecore instances that are connected to the same AD tenant. You may never have to create another Sitecore account again.
Reference
As you are aware, Sitecore is built on Microsoft technologies, which are designed to run in Azure. While this article will give you the basics, I’m a huge proponent of Microsoft’s learning catalog. This gives developers a rich background in the technologies that they are using every day. If you want to review the official learning for Azure Active Directory, I highly recommend the Manage Identities and Governance in Azure learning path, which is part of the Azure Administrator certification path.
Tenant Creation
Azure Active Directory has several feature tiers. For the purposes of this demonstration, we only need the feature sets of the Free tier.
You can then select ‘Manage Tenants’, which provides a list of all the Active Directory tenants that you are a member.
From here, you can select the ‘Create’ button to create your own tenant
This will start the tenant creation ‘wizard’ with the Basics. Select ‘Azure Active Directory’
Click the ‘Next: Configuration’ button
Enter your organization name and initial domain name. IMPORTANT: The initial domain name field must be unique and will have `.onmicrosoft.com` appended to it.
Select ‘Next: Review + create’
Double-check your initial domain and then click the ‘Create’ button
In Summary
You now know how to create your own, free Active Directory tenant. You can experiment with some of the premium features or start adding users and groups. A word of caution: Azure AD tenants are foundational. The more you add to it, the harder it is to delete the organization if you don’t need it.
Up Next
Single Tenant Azure / Multi-tenant Sitecore – setting up users, groups and app registration for a Sitecore development team
Single Sign-On (SSO) is the most important feature to enable early in application development. Nobody wants to manage another password, especially across multiple environments. Allowing stakeholders to login with their existing credentials dramatically accelerates user acquisition and engagement when designing a world-class digital experience.
Sitecore has integrated with Azure Active Directory (and other authentication providers) for many years using tools available in the marketplace. It wasn’t until the introduction of Sitecore Identity in Sitecore 9.1 that the integration with Azure Active Directory came Out-Of-The-Box (OOTB).
“You can use Federated Authentication for front-end login (on a content delivery server), and we recommend you always use Sitecore Identity for all Sitecore (back-end) authentication.”
There are lots of helpful articles from the Sitecore community that provide detailed steps on how to configure the Content Management and Identity roles to use popular providers such as Azure Active Directory, Okta and others.
Instead, I plan to cover more of the front-end benefits of Single Sign-On and Sitecore Identity.
Up Next
Over the next few posts, I’ll be covering some topics that are not discussed as frequently or in much detail. Since I work primarily with Azure, I’ll be focusing on Azure Active Directory as the provider of choice:
For those who don’t know me or haven’t met me, my name is Chet Potvin and I live with my family in the suburbs of Chicago. I’ve been working with the Sitecore platform for almost 5 years. I’ve enjoyed working with Sitecore because of its flexibility and potential. I’ve picked up a lot of experience on the Managed Services and Implementation sides of the coin. I have applied for the prestigious Sitecore MVP award twice and have yet to be selected.
This year, Sitecore launched an MVP mentorship program that pairs prospective MVPs with a mentor. As a new mentee, I’ve been working with my mentor to establish a roadmap and set regular meetings to track progress. The purpose of this post is to publish a plan and possibly inspire any other Sitecore experts to pursue their own goal of becoming an MVP.
As I continue grow my Sitecore career, my primary goal is to give back to the community that has given me so much. This all starts with this post. One of the toughest things for me is to put a vision or experience down on paper. It takes me a long time; however I know my Sitecore experiences can help others with their projects. Therefore, my goal is to post twice a month to further myself and share my knowledge.
Some of the future topics that I’ll be polling the community:
Headless Blueprint – This is a set of tools, walkthroughs and design systems that I’ve used to successfully deliver Headless sites for my clients.
Sitecore + Vercel – A match made in heaven
Preparing for XM Cloud – Sitecore SaaS is getting closer. What can we do for our clients to get them ready?
Upping Your Relevancy – it’s no secret that I love Solr. I want to share more of what I’ve learned in this area.
If you’re jumping into the Sitecore Community Pool or these topics piqued your interest, please reach out and say ‘Hi’.
When you purchase a product, the first thing that you notice is the packaging. What do you think when you first open a product with thoughtful packaging? For me, there’s an initial assumption of quality based on the care taken to prepare the item for consumers.
Similar assumptions can be drawn from well-packaged software. When a development team is tasked with maintaining, improving or recreating a solution, the first impression of that software is critical. Packaging is the first indicator of quality. If the team determines the code base to be of low quality, they may opt for a total rewrite instead of simple maintenance increasing costs in both the short and long term.
With any Sitecore solution, there are portable libraries that need to be included with the solution to facilitate environment setup. In several cases, I’ve seen development teams add those portable libraries into source control. Most of the time this is because the team is unaware of other options. This article discusses package managers and how your team can leverage these tools to create your own distributable packages.
Source control is designed for pre-compiled code. Adding compiled code to your repository creates bloat in your repo and makes versioning and upgrades very challenging. Package Managers solve this problem and others.
What is a package manager?
A package manager keeps track of what software is installed on your computer, and allows you to easily install new software, upgrade software to newer versions, or remove software that you previously installed. As the name suggests, package managers deal with packages: collections of files that are bundled together and can be installed and removed as a group.
There are a myriad of popular package managers that you use everyday: Nuget, NPM, Chocolatey to name some of the most common for dot net devs. When I mention Nuget, most developers are very familiar with the consumption of public packages posted on nuget.org or public Sitecore packages at myget.org.
Options for publishing and hosting your own packages depend on who you want to consume those packages. If you can open-source your code, hosting in a public feed like nuget.org is an option. For others, their code is proprietary and should only be distributed amongst a small group. Private feeds accomplish this goal. Myget will host a private feed for you, but at a cost.
Most people aren’t aware that you can host your very own private packages directly within Azure DevOps using the Artifacts feature. I use these feeds to publish Sitecore support, TDS and Helix foundation modules for my teams. This feature is free if you have a Visual Studio subscription. I’m going to talk about Helix Modules in a later post, so for now I’m going to focus on the Sitecore Support use case.
One ‘perk’ of being a Sitecore certified developer is that I get access to the Sitecore support pipeline. When the support team determines that a patch is required, the Sitecore team will generally compile some code and zip the library up with some instructions for installation. I wish support could provide these libraries as part of a feed, but the overhead of maintaining that feed for each customer would become unmanageable pretty quickly.
Instead, I use a tool called Nuget Package Explorer to create a package with the necessary assemblies included and then publish to my Azure DevOps Artifacts feed. Let’s walk through those steps:
Create your Nuget Package
Install Nuget Package Explorer using Chocolatey
choco install nugetpackageexplorer
Download your files from Sitecore support
Unzip those files to a folder on your machine, i.e.
c:\nuget\lib
Open Nuget Package Explorer
Create a new package
Update the package metadata on the left-hand side by clicking on the icon with the card and the pencil. The key required attributes to update here are:
Id (i.e. Sitecore.Support.999999)
Version – This is very important. I’ve left the default here in the past, but the Sitecore version number would help developers understand whether the package applies to their solution.
Add content to your package by right-clicking on the ‘package contents’ pane and selecting ‘Add Lib Folder’
Right-click on the ‘lib’ folder and select ‘Add Existing File…’
Select your binaries
Save the package to disk. i.e.
C:\nuget\localrepo
Publish Your Package
Create your feed
Connect to your feed
Select Nuget.exe
Download a recent copy of nuget to a local folder. i.e.
c:\nuget\
If you don’t have a recent copy of Visual Studio on your machine, you can download and install the credential provider
Using the nuget cli, push your package to your feed with Powershell i.e.
c:\nuget\nuget.exe push -Source "My Nuget Feed" -ApiKey az "C:\nuget\localrepo\Sitecore.Support.999999.nupkg"
If prompted, enter your ADO credentials
With the publish complete, you can now add your feed url to Visual Studio or using your solution’s nuget.config
Browse for your package in Visual Studio
Install the package to any dependent projects
Conclusion
This does require a bit more time to setup, but it will save your team a ton of time when setting up their development, testing and production environments.
Now that I’ve explained the purpose of Package Managers and how to host and publish to your own private Nuget feed, the next post will discuss the Principles of Package Management and how those principles are applied to Sitecore Helix.
I run a Sitecore study hall with my development team for the purpose of establishing a solid foundation for new Sitecore developers and to keep certifications current for our experienced team members.
For every one of my cohorts, the single most challenging aspect of working with Sitecore 9.x is the installation of Solr
Cheeto
I cut my teeth on Solr when I first started learning Sitecore and I had zero experience with building a search index. Two years later I can say that I’m an enthusiast.
Many developers may dismiss search as a second class citizen when it comes to the installation and configuration of your Sitecore installation.
Your search index is just as important to the Sitecore infrastructure as your SQL Server repository.
Cheeto
If you want a site that actually performs well in your development environment and at scale, you should build your site so that your search index can also scale.
Many architects will leverage Azure Search for staging and production environments. This is a reasonable option, but I have not had a good experience. This is primarily due to the lack of an on-premise option for installing Azure search on a developer’s machine. This leads to environments that do not mirror each other in terms of foundational technology, making it a challenge to support.
I’m going to walk you through the process of setting up Sitecore to run on a cloud-managed instance of Solr. The provider I’ve chosen is SearchStax, because of their existing relationship with Sitecore.
Key Terms
SolrCloud – A high availability option for running Solr
Zookeeper – A centralized configuration repository (minimizes configuration at the node level)
Node – a single instance of Solr. A node can host multiple cores.
Core – A physical document repository
Shart – When you fart and mess your pants.
Shard – A subset of documents within a collection
Collection – A logical pointer for a set of documents or a bundle of shards (thankfully not sharts)
Solr and SolrCloud are not separate things; Solr is the application while SolrCloud is a mode of running Solr. The alternative to running Solr in SolrCloud mode is running it in standalone mode which is most, if not all of our installs today.
Advantages of SolrCloud
Centralized configuration management using ZooKeeper
Index replication
Failover
Load balancing
Distributed queries
Scalability
Search Topologies
SCH is short for Search
SCH0 – Your search node is running on the same machine as Sitecore.
0 dedicated instances.
SCH1 – A single search node on its own, dedicated machine
SCHx – Multiple search nodes running in a clustered environment
SCH1 and SCHx are typically setup as virtual machines or using a hosted provider. Setting up your own virtual machine requires in-depth knowledge of Solr configuration, while a hosted provider eliminates the need for this knowledge.
This walkthrough will install a SCH1 topology against Sitecore 9.1 (XP0) using a hosted provider.
Configuration Steps
I assume that you already have a vanilla version of Sitecore 9.1 installed on your machine. If you don’t, I recommend using SIFless 2.2 with the SCH0 topology (Solr installed locally).
Create single Solr node (SCH1) in SearchStax ~ 10 mins
Add basic security ~ 1min
Run Zookeeper and Collection Scripts ~ 5 mins
Update Sitecore ConnectionString ~ 1 min
Populate ManagedSchema ~ 5 min
Rebuild indexes ~ 5 min
Creating your Solr Node in SearchStax
SearchStax offers a 14 day free trial which has allowed me to experiment with their offering and establish whether it can be configured to work with Sitecore 9.1.
After signing up for the trial, you will create your deployment within the Cloud Manager.
We’ll be working within the CloudManager in this example
The deployment requires:
Name
Cloud Provider
Region
Plan
Tier
Solr Version
For the trial, your options are limited to AWS as the cloud provider and you can create either a single or clustered node in the lowest pricing tier. For this example, Solr 7.2.1 is being used for Sitecore 9.1.
An example single node deployment (SCH1)
The deployment process takes a few minutes and you will receive an email once the deployment is completed.
Securing your Node
Adding security to a SearchStax node is simple. You can add IP address whitelisting or basic authentication with the click of a button. I’m choosing basic auth to demonstrate the functionality. Whitelisting is tricky in a Sitecore PaaS environment since the App Services have a range of outbound IP addresses.
Under your server settings, select Security and then Auth.
First you’ll need to enable Authentication. This will force a restart of your node.
Next, add a user. I’m naming my user searchuser to follow Sitecore’s database user naming standards like: masteruser, coreuser, etc. I give this user admin privileges because it will need to be able to create, read and write collections.
Keep this username and password handy as you’ll need it later for the automated script that creates the Solr collections.
Solr Collection Configuration with Zookeeper
The next step is to configure Solr collections to match the default Sitecore indexes. Since SolrCloud can have multiple nodes, it doesn’t make sense to house the configuration for each collection within the node. A Zookeeper ensemble helps us isolate the configuration so that it can be managed centrally.
Sitecore and SearchStax do provide some documentation on configuration within ZooKeeper, but at the time of writing, these documents fail to point out that each collection requires its own configuration uploaded to Zookeeper. This detail took many hours to resolve.
The documentation above also uses the ZooKeeper CLI to upload the configuration files. This batch file has different versions based on the version of Solr you are using and is not particularly easy to use with Powershell. Luckily for us, SearchStax has a useful REST API which abstracts away the details of the Zookeeper CLI.
I’ve managed to automate this entire process using a pair of Powershell scripts.
IMPORTANT: Powershell historically has not done a good job with multipart form submissions. For this reason, the Zookeeper configuration requires Powershell Core. If you use Chocolatey, you can easily install the package in Windows with this command:
choco install powershell-core
Before you can run the scripts, you will need to collect some required parameter information:
Search Stax Account Name
Search Stax Deployment ID
Search Stax Username
Search Stax Password
Solr Cluster Host
Solr Username
Solr Password
You can find your Search Stax Account Name in the top-right corner of the screen when you are logged-in.
You can find your Deployment ID when you click on the deployment you just created within the Cloud Manager. The deployment ID is in the url:
The Search Stax username and password are used for connecting to the Zookeeper API provided by SS. You created these items when you signed up for your SS account.
The Solr Cluster Host is located under the Server management tab and looks similar to this:
The Solr username and password come from the basic auth security that you setup against your Solr node in the steps above.
TL;DR;
Now that you’ve collected all of your parameters, head on over to Github to clone the repository for automating this setup process:
Execute this script from Powershell Core. After each configuration is uploaded and each collection is created, you should receive a Success or Failure message.
Connecting Sitecore to the Hosted Node
Once you’ve uploaded your Zookeeper configuration and created the Sitecore collections, you’ll connect Sitecore to your Solr instance. As you may know, there are several connection strings in Sitecore 9.1 that will need to be updated:
It’s a good idea to restart the Sitecore and xConnect sites in IIS after making these connection string changes.
Populate the Managed Schema
Next you’ll need to login to Sitecore and open the Control Panel. Under the Indexing group, select ‘Populate Solr Managed Schema’
Select all of the indexes and click the Populate button
Rebuild the Indexes
Next you’ll need to rebuild the indexes within the Control Panel. Select the indexing manager, select all of the indexes and hit the Rebuild button.
After-Thoughts
I have not found any SIF templates that support SolrCloud installation. I’m sure that will be the topic of a later post.
The two documents provided by Sitecore and SearchStax indicate that you should append ‘;solrCloud=true’ to the end of your connection strings. I have not had any luck with this configuration.