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.
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.
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
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.
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.
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?
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.
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.
Publish Your Package
Create your feed
Connect to your feed
Download a recent copy of nuget to a local folder. i.e.
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
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
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.
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.
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
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.
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.
The deployment requires:
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.
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
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:
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: