Experience Sitecore ! | All posts by martin

Experience Sitecore !

More than 200 articles about the best DXP by Martin Miles

Cannot use a Hyper-V disk VHDX image you've been shared with? That's how to manage it properly

Cannot use a Hyper-V disk VHDX image you've been shared with? It can be your colleague's shared VM or a disk exported from Azure VM. Below I am going to describe the steps required to managed it properly.

The first thing one is likely to perform is either importing this disk or creating a new VM without disk and attaching it later. Despite it seems absolutely valid, that will end up with:

If you see the above error it means you've most likely created a VM of 2-nd Generation of Hyper-V, and attached you drive to it. That won't work, but why?

To answer this question let's define the difference between both generations. The main fact about Generation 1 is that it emulates hardware - all required hardware components must be emulated to make the virtual machine work! Special software that can imitate the behaviour of real hardware is included in Hyper-V, as a result the VM can operate with virtual devices. Emulated hardware (that behaves identical to real hardware) includes drivers to most operating systems in order to provide high compatibility.

Generation 1 the emulation works way less productive compared to native equipment and has numerous limitations. Among those:

  • a legacy network adapter
  • IDE controllers with only 2 devices could be attached to each
  • MBR with max disk size of 2TB and not more than 4 partitions.

The 2-nd Generation uses:

  • GPT support (without size and partitions legacy limit) and Secure Boot
  • because of the above - VMs boot (and operate) much faster
  • fewer legacy devices and new faster synthetic hardware used instead
  • better CPU and RAM consumption

UEFI is not just a replacement of BIOS, UEFI extends support of devices and features, including GPT (GUID Partition Table).

Secure Boot is a feature that allows protection against modifying boot loaders and main system files, done by comparing the digital signatures that must be trusted by the OEM.

The solution is quite simple.

What you need to do is create a 1-st Generation VM (without creating a new disk drive) and reference existing VHDX file. That would work and OS will load (slowly but will do). The laziest person would probably stop at this stage, but we progress ahead with converting it to the 2-nd Generation VM. But, how do we?

All you need to do is convert legacy BIOS to UEFI running the following command executed within a 1-st Generation VM:

mbr2gpt.exe /convert /allowFullOS

Please pay attention to the warning: since now you need to boot in UEFI mode.

Now you can turn off the Windows VM, delete existing 1-st Generation VS from Hyper-V Manager (but not the disk drive!), and then create a new 2-nd Generation VM referencing the converted VHDX disk image. Also make sure the attached hard Drive stands first for at the boot sequence order (Firmware tab) and also you may want unchecking Enable Secure Boot switch from the Security tab.

Now you may successfully start your received Hard Drive with a fast and reliable 2-nd Generation VM that manages resources of your host machine in a much reliable and savvy way!

All you need to know about Sitecore 10

As you might have already heard, Sitecore has just released a new major version of its product Sitecore 10, the one initially supposed to be numbered as Sitecore 9.4. Let's take a look at what does it have to offer to better understand why Sitecore decided to "release it louder" by giving a major version number.

During the course of this post I will be writing about:

  1. Overview
  2. Installation
  3. Containers
  4. ASP.NET Core
  5. CLI with Serialization
  6. Horizon
  7. Search
  8. XM / CMS-Only
  9. JSS and SXA
  10. Data Exchange and Connectors
  11. Privacy options
  12. Analytics
  13. EXM
  14. Marketing Automation
  15. Experience Editor
  16. Content Hub
  17. Other changes
  18. Further

1. Overview

Finally, Sitecore 10 has been released. With the release of Sitecore 10, a new era of Sitecore development has started, the mostly anticipated approaches becoming an official part of the platform. This version focuses on product updates and enhancements that provide more development and deployment options, increase usability and improve overall performance – all centered around enabling both Marketing and IT teams equally, thus making it easier and faster to launch and evolve digital customer experiences.

2. Installation

From now on, there are 3 option you may choose from in order to get Sitecore 10 up and running. 

Historically, there was an MSI installer to install Sitecore as well as a ZIP archive to handle things manually. With version 8 comes a third-party Sitecore Instance Manager to simplify the installation along with some housekeeping tasks. It is no longer with us.

1. From Sitecore version 9.0 there was one and only official way to install Sitecore - SIF. A bit complicated for newbies and those who aren't familiar with PowerShell and JSON configurations. 

2. Later on with Sitecore 9.2, we got one more option for that - SIA with its GUI. With every next release SIA became more mature and offered more option. As for now, SIA allows to install Solr on your behalf together with few more things, such as extra validations:

  • validates Solr connectivity
  • validates SQL Server connectivity
  • validates the Sitecore license file
  • displays a progress spinner during the installation process
  • supports the installation of Sitecore Experience Commerce

3. Since version 10.0, Sitecore now officially has support for Docker, Kubernetes and image repositories. Sitecore community has been around containers for a while and we made much commitment to make things happen - you may see my older posts on that. This for sure will help delivery teams move to now famous continuous delivery model, making infrastructure-as-code deployments for Sitecore smoother.

Of course, SIF is still available as the default option for local installation, for example on VMs or when your team is not yet ready for containers.

Register-PSRepository -Name SitecoreGallery -SourceLocation https://sitecore.myget.org/F/sc-powershell/api/v2
Install-Module SitecoreInstallFramework -Force

The actual SIF version for Sitecore 10.0 is 2.3.0, to ensure you've got it right type in:

Get-Module SitecoreInstallFramework –ListAvailable

Check if you have got 2.3.0 along with 2.3.0 folder as well in WindowsPowershell folder - then you're ready to install Sitecore 10 using SIF.

You may be interested in reading:

3. Containers

Firstly announced as supported in Sitecore 9.3, Sitecore released version 10.0 out-of-the-box support for containers - now it is an official option to develop or instantiate Sitecore and other services with containers. To help Sitecore developers learn, use, and get started quickly with Docker, there is comprehensive documentation available on developing with Sitecore on containers.

Sitecore has docker container images for Sitecore XP and XM along with non-prod images for MSSQL, Solr and Redis for developers, publicly available from Sitecore image repository. In this initial version, SXA is supported. Now you don't need to build images yourself. There are also liveness and readiness health check endpoints which are especially useful with containers.

1. Sitecore Experience Platform 10.0.0 uses Docker Compose as the container orchestrator on developer workstations. Docker Compose is a simple container deployment tool that is bundled with Docker for Windows. Sitecore container images can be deployed with other tools but we recommend that you use Docker Compose to deploy the containers that form the Sitecore Experience Platform.

2. Sitecore Experience Platform 10.0.0 uses Kubernetes (K8s) as the default orchestrator for deploying production environments. The Sitecore XP Kubernetes specification files that are used to map the minimum required configuration parameters between the Sitecore software containers are provided as a reference.

Sitecore customers are expected to extend these specifications to support their own requirements. It is the responsibility of each Sitecore customer to ensure that their production deployments meet the standards for stability and security set by their organization.

Why are containers important? In general, if you’ve been doing your development with virtual machines or local installations, moving to a Docker-driven development and infrastructure flow will be highly beneficial for you. In general, you can address four major areas:

  • No more need for a long onboarding process for new team members
  • Eliminates pain of having several Sitecore instances especially of various versions in parallel
  • No more "works on my machine" errors
  • Improved operational capabilities with new monitoring and security support
  • Better computer resources management due to process isolation opposing running full OS VM
  • Much more reliable continuous delivery model
  • No need to "install" Sitecore - images are already pre-built for you
  • Infrastructure-as-code approach (IaC) has proven its efficiency and finally landed the world of Sitecore

Adopting Docker and Kubernetes into your workflow will let your team focus on actual development rather than wasting time on repetitive ops, providing standard tooling they need to work on those changes.

4. ASP.NET Core

I don't think anyone missed out all the noise around ASP.NET Core which is an open-source, cross-platform framework for building fast, cloud-based web apps on Windows, macOS, or Linux. Some of Sitecore features prior to version 10 are already based on ASP.NET Core - Publishing Service, Identity Service, Sitecore Commerce websites, not to mention Sitecore Host to support many features like that. However, the core rendering of pages and components still remains dependent  on the legacy of .NET Framework - which terminates at version 4.8 and won't go ahead. With .NET 5 release by the end of 2020, Sitecore has a long term strategy with Sitecore Host and the rest of development moving to .Net Core.

.NET Framework is still there in Sitecore 10 for legacy rendering, but since now we've got a Headless development option allows teams to build applications faster on the latest .NET Core technology. It is really cool especially for those pure back-end developers who just don't want to learn JavaScript and those customers who don't need fully javascripted SPA-like application.

Headless development with ASP.NET Core brings developers same JSS-like advantages, development and runtime isolation for a site, delivering a better development experience. There is a new SDK for headless ASP.NET Core rendering in Sitecore 10. 
Using the same headless services that power JSS, you deliver experiences that work in Experience Editor, track and provide marketing capabilities, but work faster. You can use placeholders, field renderings, model bindings in ASP.NET Core as normal:

  • faster and lighter
  • run headless via the ASP.NET Rendering SDK
  • works in Experience Editor
  • supports routing
  • compiling your rendering code won't cause an app pool recycle in the platform
  • only connect to Sitecore when need to: making changes to the presentation layer, pushing them, debugging in a seconds
  • remote rendering host - developers can build straight from VS into the rendering host and test changes without recycling all of Sitecore every time. 

And a cherry on a cake - there's a Getting Started Template that demonstrates all the features for the release all together. Not to say that works well with your development version running in Docker containers. The code is available on GitHub. To install latest template type:
dotnet new -i Sitecore.DevEx.Templates --nuget-source https://sitecore.myget.org/F/sc-packages/api/v3/index.json
Looking forward to see full support for ASP.NET Core 5 in the next releases of Sitecore.

5. CLI with Serialization

As we've been shown at Sitecore MVP Summit last year, Sitecore developed Command Line Interface (CLI) to interact with a Sitecore instance. The expectation is to be able doing pretty much everything from command line and in that sense it will intersect (or may even absorb) PowerShell Extensions. In order to attract developers to CLI - they decided to start with serialization. 

It was quite a surprise that Sitecore got to proper built-in way to serialize items from or deploy items into Sitecore - only using third-party tooling. Now this release of the CLI Sitecore is standardizing the tooling and approaches for serialization. Its initial release allows you serializing, pushing items with further publishing, by combining the best of TDS and Unicorn.

To support the security one need to login in via interactive or automated authentication flows, integrated with Identity Server.

With next releases, CLI will add more functionality, but what is even more thrilling, a plugin system for adding new commands via NuGet is also expected. And since it will cover all the aspects of creating and managing content, one can even create a wrapper over it implementing own version of Content Editor with any set of features (in fact, there's no need to since we've got Horizon, keep reading below). 

For those who prefer GUI over command line, there is also a wrapper available over existing set of serialization CLI-features of Sitecore for Visual Studio, a new member of the Sitecore Developer Collection that does Sitecore Content Serialization from a GUI within Visual Studio - similar to TDS did before.

More reading:

6. Horizon

The first version of the new content editing experience called Horizon has been released with Sitecore 9.3 and there has been a lot of buzz around new editing interface since then. That first version was quite limited with supported functionalities.

Now with the second release of Sitecore, it supports more functionalities:

  • Multi-site and multi-lingual are now supported and added to the user interface
  • Drag & drop support in the page tree to organize your site’s structure
  • Content Hub integration
  • Keyboard shortcuts 
  • SXA sites are also supported with all the above
Horizon Content is a content manager that you use to manage content without a presentation layer. In Content you can see meta data for each field and you can edit content that is not accessible in Pages

Speaking of SXA sites, the integration to SXA has been improved to support editing directly on the page for all supported field types and also do site-specific images and datasources. A tighter integration between SXA and Horizon editing will be coming over the course of the Sitecore 10 series.

A new dedicated field editor experience allows you to edit page metadata that is not directly editable on the page. This allows you to edit other types of fields without the WYSIWYG interface. This is also useful for editing ‘headless’ content that is not intended for a page. Using the new Content view allows you to see all the content items, not just the pages, and edit your data in the Horizon field editor.

Extending Horizon with plugins is not yet available, however is expected with oncoming releases.

With assets in Sitecore Content Hub DAM, you can now leverage that rich media in the Horizon editor instead of only using the native Sitecore Experience Platform media library. This allows your marketing team to have a better flow from Content Hub to your web channel.

Sooner or later this should have happened - Sitecore XP 10.0.0 deprecates Azure Search and it will be completely removed ​in a future release​. If you are starting a new Sitecore project, please use Solr as your search engine.

What I especially love with Sitecore over the years, they do admit and fix previously done mistakes. Azure Search was not fully compatible since day one, I personally struggles so much with it. Finally it will leave Sitecore.

Sitecore XP no longer from passes malformed content to Solr​ ​-it now filters and validates content prior sending it to Solr​.

Last but not the least, Sitecore 10 now requires Solr version 8.4.0 to work with.

8. XM / CMS-Only

Few version ago, Sitecore came up with a lightweight and very fast CMS-only version of its product, opposing full XP with full-powered analytics and much more things around it. However for some reason there was not rule engine personalization coming with XM topology which was not right: for those not needing the full xConnect, still want get use use of some basic personalization or implementing custom conditions, especially valuable for SXA websites. Finally that got fixed and one can now run simple personalization on lightweight XM installations. This functionality contains session-based and device rules that do not depend on tracker or marketing definitions available in the XM package.

Please refer to the list of personalization conditions available for XM to find out more.

9. JSS 14.0 and SXA version 10.0

There are not much of new JSS features with this release, the changes are mostly relate to the stability improvements and support for new platform features. Thus, new JSS can now successfully handle forwarded deployment requests when it is installed behind a reverse proxy as it is in Docker. Exactly the same applies to SXA.

SXA keeps having its versions aligned to the platform release, in order to avoid the confusion.

For more details on what's new, please read the following:

10. Data Exchange and Connectors

Changes in Data Exchange Framework (DEF):

  • Additional field types added to CMP Connector
  • You can now sync a single contact
  • Respond to live events on the site

Sitecore Connect for Salesforce Marketing Cloud allows teams to work in Salesforce Marketing Cloud and leverage the rich visitor analytics data stored in xDB. Now, with the latest release, xDB information can be more easily sent to SalesForce. You can make use of this connection in real-time, no need to wait for a nightly batch. A new Sitecore Marketing automation activity, specifically for Salesforce Marketing Cloud, allows marketers to configure a realtime event to integrate with SFMC.

By connecting directly to the Salesforce Marketing Cloud, marketing teams can respond to events in Sitecore and immediately send information about the current visitor over to Salesforce Marketing Cloud and place visitors into Journey Builder marketing automation plans. This means that you can respond across all your channels to events, in real-time, in the marketing automation tool that you use.

Please read this link for more details on SalesForce Connector.

11. Privacy options

Previous releases of the platform have progressively been improving the privacy tools available to teams looking to meet with regulatory needs and customer privacy demands. In Sitecore 10, new support has been added to help you on your journey. Sitecore 10.0 and later provides API calls and configuration options that makes it easier to enforce explicit consent for tracking a contact's activity on your websites.“Update consent settings” now allows you to remove contacts from marketing messages or all messages. In general, there are two new "rights":

1. Right to be forgotten. With this release, Sitecore Forms makes it easier for you to support erasing this personal identifiable data that is saved via the out-of-the-box Save data submit action. This includes redacting submission values, removing any associations to xDB Contacts, and deleting any files uploaded by the visitor. At the same time this approach still allows marketing teams to see reporting data, despite being anonymized.

2. Right to object. A second change in this release regards making it easier to enforce and manage consent choices. Visitor tracking now requires that giving explicit consent.and marketing teams need to respect and store these choices and make decisions on them. The new consent management tools available in the platform allow for implementation teams to configure sites to require explicit consent before the Sitecore tracking will begin. The tracker is now able to be disabled based on the consent settings stored for the user, and xDB supports the ability to store these consent settings and persist it across visits for the contact.

This allows marketing teams to add additional consent requirements for specific sites that need to meet stricter privacy guidelines.

12. Analytics

Getting insights from Sitecore’s analytics reports is great, but previously one could not filter on specific segments. Now, there is a new filtering functionality available in all reports! 

This means that you can use Segments created from List Manager based on all sorts of segmentation rules as filters on your analytics. In the past when the “Use as analytics filter” was enabled in a Segment, you needed to apply some extra configuration to have this filter available in your reports. Now, this filter is available in the analytics reports without any extra configuration:

  • Target segments of contacts via predefined rules and then report based on that segment
  • Report on the performance of key audience groups
  • Push an email to a segmented list and then see the impact across the site

This is great, because with the extensive set of available segmentation rules, it’s very easy to zoom into the analytics for these specific segments focusing on a group of contacts.

13. EXM

Before Sitecore 9.2, there were no standard templates available OOB at all. Now, with Sitecore 10 we've got even more new additional templates added to the product: 

  • Left Image Block
  • Right Image Block
  • Image Focus

This saves much time for the customers using EXM from developing such email templates from scratch, as these templates can become a great starting point at the cost of a single click. But what is really great - these templates are completely customizable to using Scriban, similar to editing rendering variants in SXA.

14. Marketing Automation

Firstly, Marketing Automation has been reworked to allow for more efficient loading of xConnect data, there are performance improvements in XConnect for customers who do not use Marketing Automation. It does not load contacts and interactions unless there is an inactive or active plan.

Secondly, there are new rules around birthdays added to engage with contacts around their birth date. You can now do things like:

  • sending offers X days in advance of their birthday
  • sending greetings on their birthday
  • sending reminders and follow-up with your customer some number of days after their birthday

Thirdly, usability improved by rephrasing and redefining rules and settings, as well as security changes.

15. Experience Editor

Ladies and gentlemen, let me introduce the feature mostly wanted and requested by marketers which we finally got! The feature which on its own may save hundreds of hours for you content or marketing teams. And here is it:

All content pasted from Word into Rich Text Field is cleaned. Therefore no more Ms Word styling coming into a field, just pure content.

This might look as a minor improvement, but a lot of authors have been waiting for easier workflow going from their Ms Word documents into Sitecore rich text fields. Previously, authors often broke the styling on a site as their copy-pasted content included extra unwanted markup from their documents that conflicted with the styles already on a site. With the new changes, clean source HTML is created that preserves the content and the styling especially for those customers who aren't using Content Hub.

16. Content Hub

Once again I want to clarify very common confusion. Content Hub isn't just a replacement for Media Library. Quite opposite - Sitecore Content Hub is now the central hub for all media content in their DAM, but also content models defined in CMP. And Sitecore is just only one of the channels of content publishing with the web channel is only one channel consuming this content. Current release expands how much content can be managed in CMP and then integrated to the Sitecore Experience Platform. With support for additional field types, this allows marketing teams to centralize more of their content creation into Content Hub and still leverage this with their web teams. With the addition of a taxonomy import, marketing teams can also make sure that the taxonomy associations they make in Content Hub will persist into the content items in Sitecore.

17. Other changes

Just go through them in a form of a bullet list:

  • Sitecore PowerShell Extensions version 6.1.1 is accompanying this platform release.
  • With Sitecore 9.2 we've got Active Personalization report. Now with version 10 numerous performance optimizations have been put in the active personalization list, including infinite scrolling, caching, lazy loading, and back-end optimizations
  • You can now abort currently running jobs - another widely demanded feature.
  • Session State has been optimized for performance, expecting a 10-15% faster response time for CD servers.
  • The Shared Session State database is now disabled by default, but can be enabled if required.
  • Application map support has been one of the highest requested features for operations teams running their infrastructure on Azure, now it's possible to view and diagnose the xConnect stack directly in the application map, with monitoring and diagnosing allowing to start tracing requests.
  • Massive performance improvements to xDB change tracking achieved by changing the way changes are tracked in xDB. This allows for a faster processing when there is a high volume of changes being made, while simultaneously being less heavy on server resources.
  • A new page that automatically collects basic information about your Identity Server instance has been added.
  • You can configure service pages (Error, Not Found, and so on) for each website on content tree structure.
  • There is also already available Sitecore Commerce 10.0 that works on top of Sitecore XP 10.0.

18. Further reading

This is not the full list of changes and features coming with this so much promising Sitecore 10 release. You may use the links below for your own investigation:

Sitecore RSS Feed revised by using Content Search API instead of unproductive Sitecore Query

I am working on a large multilingual website with several dozens of thousands pages are available in numerous languages. It also features news being released on a daily basis by tens of news editors under plenty of nested categories. Thus it was matter of time for me to be asked to implement an adequate RSS Feed solution to expose all the possible data.

Luckily, Sitecore has built-in RSS Feed feature, but unfortunately it has very limited implementation by data driven using Sitecore Queries, obviously this is quite a legacy feature was added into Sitecore way before version 7.0 with its revolutionary Content Search API. 

What is wrong with this old-fashioned Sitecore Query:

  • it is limited in its applicable functionality
  • has complicated synthax
  • isn't easy to debug and troubleshoot, especially on complex conditions
  • is slooooooow (even fast query is slow!)
  • talks to database and generates cache for touched items
That was absolutely obvious that I should use Content Search API. I googled around and came across some implementation done by Douglas Couto for Sitecore 7 and Lucene. I reworked it to be compatible for versions 9.*+ and added few new features.

It is available at my GitHub repository (and readMe file is quite explanatory there)
Once you get the items from either TDS serialization or Sitecore package, a new Content search section is added to RSS Feed template to drive the data out of Content Search API rather than Sitecore Query:

All the benefits of Content Search API are available to you from now on. Using this new section one may fine tune the data to be exposed by not just certain page templates, but also filter to be located under specific node, has certain tags and specify recency criteria for that filtered data.

Hope this helps!

Walkthrough: Using Publishing Targets in order to create preview environment with Sitecore 9.3

I made this 22-minutes long video in order to demonstrate how one can create a preview environment by creating a new publishing target on an example of vanilla Sitecore 9.3.

Adding new publishing target is very helpful when you:

  1. would allow content authors to demonstrate the content being not in a final state
  2. want to demonstrate that content to an audience without access to your Sitecore instance

This demo shows how to create a publishing target database, assign it to a designated hostname and then also to create an index for a given preview database. It also demonstrates the difference between publishing content in non-final-state into both live and preview databases.

Hope it helps!

Why CNAB could be a game-changer for Docker containers and how Sitecore can benefit from that?


Currently, in order to run Sitecore in docker locally, one has to pull the code from a GitHub repository, build it (if not done yet, or pull already built images from a Docker registry), set the license file, and say "up" to docker-compose. Not to say the prerequisites required. If dealing with a cloud, then the deployment into Kubernetes is required, which also demands adequate skills.

Imagine an ideal situation where you don't need to do all the things, but just pull a "managing" image from a remote registry, and this image itself will care about running "all the things" internally, such as prerequisites, pulling the dependent images, preparing the environments, network and dependencies, doing alternative steps to docker-compose and much more.

Or going far beyond that: shipping is as a traditional GUI installer for non-technical people or deploying that same image into a cloud, any cloud, ready to use, does not that look as such desirable? What if I tell you this technology is already available and you can use it? Please welcome the new universal spec for packaging distributed apps created by Microsoft and Docker:

Cloud-Native Application Bundles or simply CNAB

Firstly, what the heck is CNAB at all? Using Cloud Native Application Bundle, a developer has an option of deploying the app either locally at his dev. machine, or in a public cloud as it bolts together containers and services into a seamless whole, placing a strong focus on standardization. It is an open-source specification that aims to facilitate the bundling, installing, and managing of containerized apps. With this bundle, users can define resources that can then be deployed to a number of run-time environments, such as Docker, Azure, Kubernetes, Helm, automation services (such as those used by GitOps), and more.

At a first glance, that task is supposed to be solved by Docker itself. However, when dealing with largely scaled hybrid infrastructures, its standard features become insufficient. Thus, CNAB is an attempt of standardizing the process of packaging, deployment, and lifecycle management of distributed apps on a basis of Kubernetes, Helm, Swarm, and others by using a unified JSON-based package format. 

Recently the CNAB spec reached version 1.0, which means it is ready for production deployment. The spec itself is now broken down into several chapters:

  • CNAB explains the fundamentals of the CNAB core 1.0.
  • CNAB Registry will describe how CNAB bundles can be stored inside of OCI Registries (this section is not yet complete).
  • CNAB Security explains the mechanisms for signing, verifying, and attesting CNAB packages.
  • CNAB Claims describes the CNAB Claims system, shows how records of CNAB installations formatted for storage
  • CNAB Dependencies describes how bundles can define dependencies on other bundles.


Each of the organizations has provided its own tools that demonstrate CNAP capabilities: Microsoft released Duffle, while Docker shipped Docker app. Docker Desktop application is fully compatible with CNAB from May 2019.

CNAB is not the only solution for managing the cloud applications lifecycle. For example, Kubernetes has Сrossplane manager as well as package manager Helm. However, CNAB is the first ever solution that supports several most popular tools and is platform-agnostic. By the way, CNAB can also work with Helm and I came across a sample of it at GitHub.

Duffle is a simple command line tool that interacts with Cloud-Native Application Bundles - helping you package and unpackage distributed apps for deployment on whatever cloud platforms and services you use. Its goal is to exercise all parts of the specification and this tool also comes with very handy VS Code extensions, one of which named Duffle Coat allows you to create native executable installer (*.exe) of your bundle:

This results in the proper installer that will install and configure you Sitecore 9.3 locally from bundle image stored at docker registry:

Once again, instead of local Sitecore installations (like SIA does), we are having this CNAB installer that installs the platform from a Docker registry and with no prerequisites required at all! And CNAB bundle cares about all the dependencies and parameters. What magic!

Another tool, Porter, is Microsoft’s CNAB builder that gives you building blocks to create a cloud installer for your application, handling all the necessary infrastructure and configuration setup. It is a declarative authoring experience that lets you focus on what you know best: your application. The power of Porter is coming from using mixins giving CNAB authors smart components that understand how to adapt existing systems, such as Helm, Terraform, or Azure, into CNAB actions.

And of course, Docker App is a CNAB builder and installer that leverages the Docker Compose format to define your applications. To facilitate developer-to-operator handover, you can add metadata and run-time parameters. These applications can easily be shared using existing container registries. Docker App is available as part of the latest Docker release.

Bundle manifest file
As I said above, the specification defines the way of packaging distributed application of various formats. CNAB includes package definition (named bundle.json) used for describing an app, as well as a special image (also called invocation image) for its installation. A bundle.json is similar to a docker-compose.yml file in that it describes a complex configuration for image deployment. The difference is, the CNAB bundle is very clearly defined as to how it should be laid out, encoded, and where all associated files must reside. It contains:

  • The schema version.
  • Top-level package information.
  • Information on invocation images.
  • Map of images.
  • Specification for parameter override (with a reference to a validation schema).
  • List of credentials.
  • Optional description of custom actions.
  • A list of outputs produced by the application.
  • A set of schema definitions is used to validate input.
Here is a sample of bundle.json file below:
   "description":"An example 'thin' helloworld Cloud-Native Application Bundle",
         "description":"my microservice",
         "email":"[email protected]",
         "name":"Matt Butcher",
         "description":"the hostname produced installing the bundle",
         "description":"The port that the back-end will listen on",
You may read more about bundle.json format at CNAB.io official page.

How about Azure?
For Azure, we also have got the solution, Azure CNAB Quickstarts library. It demonstrates how one can use bundles for deploying applications and solutions and how to create their own bundles. The library is designed to be optimized for bundles that use Azure resources but is not limited to Azure only. There is CI/CD workflow in the repository using custom GitHub Actions to enable the automatic building of bundles and publishing of bundles to a public Azure Container Registry. The library supports bundles made using Porter tool I mentioned above, a tool capable of building, publishing, invoking, and updating bundles.

Final thoughts
Likely CNAB becomes a game-changer for 2020, as we get more and more into containerized deployments and orchestrating them in the clouds. The specification is quite new and not too many companies are using it at the moment, but there is an ever-growing interest in it. Since all the major vendors are now ready, I am quite sure it will boost the whole industry in the coming months!

Hope you find this post helpful and get your own hand on CNAB shortly!

Sitecore Docker breaks when running Build.ps1 with "hcsshim::PrepareLayer failed in Win32: Incorrect function. (0x1)" message

Recently I was trying to build docker images from the main Sitecore repository, and got quite a weird message.

hcsshim::PrepareLayer - failed failed in win32 : Incorrect function. (0x1)

This message is not self-explanatory and it fired up when the actual build for the first image took place, in my case that was SQL server 2017. Some other details: quite fress and new instance of Windows 10 x64 build 1909, using Hyper-V, no docker / images previously been utilized at thtis computer.

After few hours long googling, I came to understanding that was caused by c:\windows\system32\cbfsconnectnetrdr2017.dll referenced by autorun. There is one halpful tool that helps out troubleshoouting such issues - Sysinternals Autoruns. Here is the output generated by Autoruns for my system:

What is that DLL and how did it get to my machine? CBFSConnect is a known library for creating and managing virtual filesystems for cloud storage providers such as such as Box, Dropbox etc., and this DLL is a kernel mode system drive. Sometimes it may be a leftover from a previously installed software, that was not uninstalled fully and properly.

Depending no your system you may see this DLL as either:

  • C:\Windows\system32\cbfsconnectnetrdr2017.dll  - for newer systems, or
  • C:\Windows\System32\drivers\cbfs6.sys
You may check if it is running or no tby running  a command-line utility for common minifilter driver management operations command (a command-line utility for common minifilter driver management operations):

The easiest I found was to just simply rename this driver. Once restarted, docker build worked well.

Hope this helps someone

Tip of the day: running Sitecore Docker from within Hyper-V virtual machine is in fact possible

Why not to run Docker containers from within a Hyper-V virtual machine? 

Well, when you are trying to install Docker Desktop for Windows, it installs correctly. But running it will prompt you about Hyper-V is required for Docker to work.

Programs and Features on its turn shows you that Hyper-V is greyed out, so you cannot install it from there

Not everyone knows, but Hyper-V in fact allows having nested virtual machines. That means running docker is also possible from within a VM. All you need is just running one PowerShell command from outside of your container:

Set-VMProcessor -VMName _YOUR_VM_NAME_TO_ENABLE_ -ExposeVirtualizationExtensions $true

What it does - just adds virtualization features into a virtual processor of outer VM, similar to those you got at you physical CPU. Thus you need to run this command of the VM switched off.

Once done, Sitecore perfectly builds and work if Docker running within a virtual machine. For those who are total beginner and scary to mess the things around their host machines - this could be an option. However there is of course a performance penalty from double virtualization.

Finally, the main trick! Just because you've added virtualization extensions into a virtual processor of your VM, you may run docker in process isolation mode, relatively to the build number of VM's operation system. Will explain it on the following example: imagine, your host machine runs Windows 10 build 1809, but got no problems of running Windows 10 build 1909 in a Hyper-V machine there. Now, you after you enable virtualization extensions to that virtual machine (that runs 1909), you will be able to install docker within that virtual machine, and run 1909-built images in process isolation, natively to that VM: 1909-built images run on 1909- machine! But at the same time you will be able to run those same images only in hyper-v mode on the (outer) host machine, because it has 1809 and cannot run non-matching images in process isolation mode.

Hope this helps!

I have been awarded the Sitecore Most Valuable Professional Technology Award in 2020

Great news for me!

Just got an email saying I was awarded Sitecore Most Valuable Professional Technology Award for the oncoming year.

I feel very excited and carry on plenty of brave plans for the 2020. My main efforts will be applied in two main areas: containers and JSS, at least as I see that now. Apart from will take all of my best to get selected as a speaker for a big audience conference and keep going developing Sifon, as it is quite promissing tool (unfortunately it is so tought with finding and allocation long timeslots for it).

In any case, I am pleased to stay as MVP and hope to meet you at the events later this year.

Welcome Sifon - a must-have tool for any Sitecore developer,to simplify most of you day-today DevOps activities

UPDATE 23/12/2019: There has much been done since this post originally, Sifon is now working on remote machines as well as it supports Sitecore Commerce. The main news, however, is that it now got a website with documentation, demos, roadmap, and other project-related items. Thus, it would be best to refer to it - https://Sifon.UK.

Do you love PowerShell as much as I do?

Along the time, Sitecore gains more and more new features, its architecture obtains some existing features split out into microservices. Maintenance becomes even more complicated and time-consuming. Just as an example, a few years back in time we had only 3 databases coming with the platform, while now there are more than 15. 

Luckily, PowerShell as a scripting technology comes us with assistance, providing the console-based API to most of the OS and platform management features. Now it becomes possible to automate quite complex procedures just by scripting them out. Take a look at Sitecore XP installer for example, or at even depicting the complexity - an installer script for Sitecore Commerce with almost a hundred steps. How long did it take you to run it all? That confirms the statement on how PowerShell became an inevitable part of developers' lives.

But here we come to another problem. The number of scripts we have grows quite quickly, as the number of standard tasks grows. And at some moment I start noticing that something goes wrong with it. Those who read my blog from time to time may have noticed, that I am kind of a productivity maniac, and being such a person, I start thinking and analyzing where the productivity bottlenecks are while working with PowerShell. What do you think they are?

Firstly, scripting means typing. Typing means typos. Typing means forgetting the syntax. Regardless of how one is perfect as a typist, interaction with a keyboard has its own expenses. The good news is that PowerShell addresses these issues by providing interactive help and autocompletion. But it still consumes your time, compared to the UI operations (of course, those with proper UX and well-designed).

Secondly, we have more ready-to-use scripts and we need them all to be stored somewhere. Somewhere on a filesystem, of course. Those smart and best use GitHub gists (they can be also secret, not only public), and since recent ones can have also private GitHub accounts, so what I know few people do is just create private repositories of their entire scripts libraries. The benefits are clear - if these libraries are well organized and properly structured - it gives immediate access to some specific script one may need to find and access. The principal criteria here is time-to-access and the GitHub repo provides that for sure, of course, you may use any other version control hosting providers, subject to velocity.

Thirdly, sensitive information. Scripts call, other scripts, that in turn call another script (modules) that in turn call APIs - that similar nesting we typically have with our OOP languages. The issue comes from those outer-level scripts that contain some sensitive parameters, such as usernames, passwords, secrets, tokens, and similar. You don't store all of the above at external source control hostings, even if that's a private repo, do you? If you do, I can recommend you a few really worthy courses on information security. Of course, a developer can parametrize all sensitive information and bubble it up to an external script, so that it comes to input parameters. But then we face a bottleneck issue I described first. Not just one has to provide parameters but need to type them manually and to store the values somewhere, which turns in a payload of accessing those values. Still not good. 

In any case, the reality is that plenty of such scripts are bloated across the hard drive, which still comes to all the issues described above.

Finally, when it comes to sharing those puter scripts, we meet the same story of separating sensitive data and environmental-specific values from pure business logic.

Of course, developers do value their time and try to find compromises. I am not exclusive and decided to go my own developer's way, which you may guess means developing something bespoke. So please welcome Sifon - a must-have tool for any Sitecore developer, to simplify most of your day-to-day DevOps activities.

But before going ahead - a bit of intro. Without a deep understanding of all the requirements, I still made an early prototype of a given tool to address some of my problems somewhere back in November 2018. Greatly impressed by Sitecore Instance Manager (also known as SIM) I decided to return a graphical installer to Sitecore, which was missing out by those days. That of course was achieved, however, the most valuable feature was the ability to back up the entire Sitecore instance state, clean up the web folder and databases and restore it back from a folder. All that in just a minute time, which seemed to be nothing comparing even to installation with SIF. Something extremely helpful, when you develop with Helix principles and often need to create rollback points before trying some complicated PoCs or for example to a clean just installed version of Sitecore, in order to perform deployment on a clean instance.

That software start saving my time significantly, right from the moment of its creation! Later I added a few more frequently used functions into it, such as installing modules, Solr, rebuilding indexes and full republish, adding HTTP bindings to an instance, and moving its SSL certificates into trusted storage. I shared this PoC with a few of my colleagues working on the same project saving their time as well. 

But I could not share it with the entire Sitecore community, to my regret. Firstly, due to unstable code coming out of PoC sitting on top of another PoC and so on, turning Proof of Concept into the Proof of Hell. Secondly not just a project architecture was put under a big question mark, but also the whole concept should be revised. 

I wanted it not just to be well maintainable, but extendable. Saying that I mean the ability of each individual working with this program to easily create their own plugins and extensions, addressing some specific task that is shareable or publically open-sourced. Multiplied by Sitecore community efforts that may become an unprecedently helpful tool for all of us, I know you folks are very creative!

So once again, please welcome Sifon. But first of all, what the word Sifon means? 

Sifon is a simplified casual term for a whipping siphon that is used to create carbonated water, often with some fancy tastes. It requires cartridges of gas, also known as chargers, to pressurize the chamber holding the liquid. That very roughly explains the architecture of Sifon tool I am presenting to you today.

In my case, Sifon is a nicely developed PowerShell host with numerous features that allow "playing" any custom PowerShell or C# code in form of plugins. That comes as a curious metaphor - the host itself serves as a siphon body, where plugins stand as an analog for charger cartridges. The main screen looks quite minimalistic:


  • stores credentials and environmental parameters in one place called profile, passing them as the parameters into the code
  • supports multiple profiles for many environments with immediate switching between them by one click
  • "backup-remove-restore" routine comes as built-in and is available immediately after setting up the first profile 
  • profile editor allows the testing connection few basic parameters auto detections but will be extended with more features
  • runs in multithread, responsively updating the progress along with the rest of the corresponding feedback

From the feature list, as for a user, it offers these benefits:

  • keep all your frequently used scripts at the same place, organizing them by nested folders as preferred
  • separate scripts from sensitive parameters, allowing sharing and publishing them open source
  • because of the above, one may create own repository and clone scripts directly into Sifon's plugins directory 

NOTE! Before going ahead, please keep in mind that currently that is just a demo beta, so everything may be subject to changes, especially when it comes to UI. Also, the entire validation layer is disconnected, so please submit data responsibly!

The first thing one needs to do after installation is to set up a profile. As I mentioned above, a profile is an easy-to-switch-between set of parameters applicable to a specific environment. As simple, these parameters from a currently selected profile will be passed over to any script executed, regardless of whether that passed into a built-in feature, PowerShell script, or DLL plugin. It is expected that both mentioned are accepting these parameters, so please refer to the provided example in order to build your own plugins. 

Important! In order for Sifon to function, you must create at least one profile that has a SQL Server connection set up. Otherwise, most of its functions will be greyed out, until required profile data is submitted.

Now, let's take a look at Sifon's built-in "backup - remove - restore" routine. Making backup comes as easy as:

All you need to do is specify the folder to put the backups into, select which instance to backup (you may have many) and decide whether you want to backup databases (select which exactly), web folder, or both.

As you might know, it is always better to deploy Helix-based solutions into a clean environment, so you may want to clean the existing webroot before restoring it into that folder. It is done in a similar manner - from dropdown select which instance to remove and it will prompt you with a webroot folder and installed databases. You just need to check/uncheck what you'd like to remove. Please note that databases can be deleted individually, and by selecting "manual entry" you can list all the databases from all the instances to be selected for removal.

Not to say that restoring looks and also works similar to mentioned above. Simply select a folder with a corresponding backup and select what to restore. If the folder contains only webroot or just databases, you'll be able to restore only what you've got. 

Creating a capsule plugin requires you to write PowerShell in a specific manner, but the two important points to mention are:

1. accepting parameters. Just attach this to the top of your script, and you'll get these parameters auto-provided

    #Comes from profile

2. reporting the progress by write-progress. This is done by the following syntax

Write-Progress -Activity "This is the name of current operation" -CurrentOperation "Step 1" -PercentComplete 10
start-sleep -milli 500
Write-Progress -Activity "This is the name of current operation" -CurrentOperation "Step 2" -PercentComplete 20

You may run test-progress.ps1 script and review its code as it demonstrates how progress output works with PowerShell

Have you ever noticed a light-blue progress bar when installing Sitecore with SIF (as below)?

That's it! It also means plenty of SIF functions can be converted to work with Sifon and will support displaying progress natively. Few of them will be provided upon the release.

List of plugins (capsules) that will be provided upon release through GitHub:

  • all types of package installation: traditional, update-packages and web deploy WDP modules
  • creating an SSL certificate and adding it to the trusted storage
  • enable SPE remoting for a selected instance and further execution of plugins in their context
  • install Solr service, both as single and in-parallel running to already existing service (ie. various versions)

This is the first publically released beta and it is downloadable from this blog post. In the future, it will be distributed from own website along with the documentation, but there will be an easier way of installing it:

choco install sifon

Future plans

  • execute PowerShell scripts in the context of a remote machine by WSMAN (that's already supported, but no UI for it yet)
  • add support microservices of Sitecore, such as xConnect, Identity Server, and Publishing Service
  • in addition to the above, add full support for Commerce, its microservices, and databases
  • be fully compliant with Sitecore 9.2, including official installer script (SIF script coming out of the box)
  • extend custom OutputFormatters to plugins, allowing presenting more friendly console output (currently works at Sifon itself)
  • community plugins available through the GitHub repository
  • once becomes matured, releasing Sifon itself open source

You can download the beta by clicking this link (please download from Sifon website instead). It will already be able to do backups and restore your instances. The samples of capsule plugins are also available through this GitHub. Just compile DLL or drop PowerShell into Scripts folder to get them available via the menu.

Hope you enjoy that and looking forward to your feedback.