Many of us have been there: whether it’s a matter of containerizing an existing solution, moving an instance to a different machine, or even just setting up our local development environment, many Sitecore developers had to square off with a non-functional XConnect instance.

Last week was the third time in my career, so I decided to make a little experiment: I configured an instance completely from scratch in a VM that never had Sitecore running on it, and documented all the steps that led from an empty wwwroot folder to a working XConnect site.

For reference, I’m installing XConnect version 10.1.0, on a Windows 10 server running IIS 10; additionally, I assume that Sitecore software prerequisites have already been set up.

• First and foremost, ensure that your Databases, Solr instance and TLS/SSL Certificates are in place. I will not go into the details of setting up  SQL Server or a SOLR instance, but if you need to set up your security certificates from scratch you can use this Powershell script. Doing so will create 4 certificates in your machine’s Personal store; of those, the Sitecore Development Root certificate must be copied in the Trusted Root Certification Authorities store.
• Whatever TLS/SSL certificate you’re going to use, ensure that the LOCAL SERVICE, XConnect Application Pool, CM / CD Application Pools and Identity Server Application Pool users have access to it; you can do so by right-clicking the XConnect certificate in the Personal store, selecting “All Tasks” and “Manage Private Keys”:

                                 

• Configure your XConnect site to Accept Client Certificates:

• Also, be sure to note down the Thumbprint of your XConnect certificate by double-clicking on it in the Personal store and selecting Details:

• Having done this, update all the instances of ConnectionStrings.config and AppSettings.config with the correct SQL Server Connection Strings, SOLR server URL and XConnect Certificate Thumbprint;
• If your local SOLR service is not HTTPS, you may have to search throughout the .xml files in the XConnect folder for all the <RequireHttps>….</RequireHttps> entries and change it to “false”;
• Ensure that the proper users (typically IIS_IUSRS, NETWORK SERVICE and/or the IIS App Pool user) all have access to the IIS folder where XConnect is running from;
• If your IIS version has this option, ensure that in the HTTPS bindings for the XConnect website, “Disable TLS 1.3 over TCP” is checked:

• Create the three separate Windows Services associated to XConnect; put the .exe path between brackets, and add the string “-service” at the end of it, for example:

“C:\inetpub\wwwroot\sc101sc.xconnect\App_Data\jobs\continuous\AutomationEngine\Sitecore.MAEngine.exe” “-service”
“C:\inetpub\wwwroot\sc101sc.xconnect\App_Data\jobs\continuous\ProcessingEngine\Sitecore.ProcessingEngine.exe” “-service”
“C:\inetpub\wwwroot\sc101sc.xconnect\App_Data\jobs\continuous\IndexWorker\Sitecore.XConnectSearchIndexer.exe” “-service”

and use the NT AUTHORITY\LocalService user as Logon Account; then start them.

• Finally, ensure that a valid Sitecore License is present in the App_Data folder of each of those services.

This should result in a working XConnect instance; if for some reason it doesn’t, please feel free to let me know.