I am trying to install Sitecore 9.1 in distributed (on premises) architecture, I have 4 servers:

  • 1-cd
  • 1-cm
  • 1-solr
  • 1-sql,reporting and processing

I tweaked the script to install each separately with respective json files in respective, and I could see application created successfully.

I need to verify the individual application is fine. I could verify CM, CD, by verifying default home page.

How do I verify other process precisely the following app installed in other servers?

  • xxx.sitecore.collection
  • xxx.sitecore.identityserver
  • xxx.sitecore.ma
  • xxx.sitecore.reporting
  • xxx.sitecore.processingEngine
  • xxx.sitecore.refdata
  • xxx.sitecore.reporting
  • xxx.sitecore.search
  • xxx.sitecore.rep
  • xxx.sitecore.prc

Any help would be much appreciated.

  • Off topic, but just to make you aware. If you have perpetual license, that install requires 2 production licenses and two non-prod licenses. Just figured this out myself.
    – Chris Auer
    Commented Mar 5, 2019 at 20:48

2 Answers 2


Validating Installations

To understand how to validate all of the different parts of Sitecore, you first must understand what parts exist, why they exist, and how they work together. We'll begin with a short definition of terms.

In the world of Sitecore 9.1, there are three PRIMARY applications in play. One or more instances of Sitecore, 1 implementation of xConnect, and 1 implementation of Identity Server.

Identity Server

This should be a pretty transparent service. However, if something is not working right, you will NOT be able to log into Sitecore. This is ONLY available in Sitecore 9.1 or higher and not used in Sitecore 9.0.

Sitecore Instance(s)

In the world of Sitecore, there can be multiple instances of the application of Sitecore.

  • Content Management (CM)
  • Content Delivery (CD)
  • Processing (PRC)
  • Reporting (REP)
  • Dedicated Dispatch Server (DDS, used for EXM)

Each of these instances is the same application, just installed multiple times with slight configuration change. What that means is that verifying an install is pretty much identical across all of these instances, which some varied nuance.

1. Verify the Sitecore Log (ALL Instances)

Each instance of Sitecore will generate log files when the web application pool (or worker process) spins up. These will be in the App_Data\logs folder. If you are not generating logs, there is something at the IIS level seriously wrong.

2. Inspect the Sitecore log(s) (ALL Instances)

Taking a peek into the Sitecore log (log.yyyymmdd<.hhmmss>.txt), we should see the standard Sitecore spin up log messages. From there, we should NOT see error messages. If you do, that instance is not validated.

PROTIP: If you are a new Sitecore Developer, memorizing by heart the elements of a Sitecore log, especially on startup, can help you learn a lot, about what Sitecore is doing under the covers.

3. Login to Sitecore and inspect modules. (CM Only)

Logging into Sitecore, on the CM, is our first test to understanding if everything is starting to wire up correctly.

  • On the Launchpad, the Analytics graphs should load, even if there's no data. The empty graphs should load. If they do not load, even after a couple of refreshes, this may be caused by an issue communicating with the Reporting instance of Sitecore or the Reference Data service of xConnect (more on that later).
  • Open the Content Editor and make sure you can browse items. Issues here might indicate an issue with SQL.
  • Attempt to do a search of items in the Content Editor. This will reveal issues with Solr or your indexing mechanism.
  • Open up the Experience Editor. This ensures the rendering engine is working (more appropriate once the custom code has been applied).
  • On up Control Panel, and rebuild indexes. This will also point to issues with the indexing mechanism.

If all of the above checks out, then you can be pretty confident that Content Management, SQL Server, and Indexer (Solr, Azure, etc) are working as expected.

4. Test the Website Front end (CD only)

This is a pretty easy test. Once the custom code is deployed (or if just using the default Sitecore sample site) loading up the home page should reveal a page. If it does, you can be confident about the CD's, assuming you also checked the log files.

5. Test Analytics.

This is the harder part. We need to make sure that Analytics is working. But it's a multipart checklist.

  1. Generate some visits on the CD. Make a special note on how long the session time out is and make sure you allow that time to pass before proceeding. (Default is 20 minutes, and this can be found in the web.config of the CD role).
  2. If the system is working appropriately, after the session timeout, you should begin to see analytics flowing into Sitecore's Experience Analytics (on the CM server).
    1. If you do, then you have just validated, xConnect Collection Service, xConnect Collection Search Service, xConnect Reference Data, Sitecore Processing, and lastly Sitecore Reporting.
    2. IF YOU DO NOT, Houston we have a problem. This problem means that there could be one to many failures happening along the way. Which leads us to verification of xConnect.

xConnect Implementation

xConnect is a collection of .NET Core services running 5(6) distinct responsibilities:

  • Collection (IIS Site, API)
  • Collection Search (Windows Service or Azure WebJob)
  • Reference Data (IIS Site, API)
  • Marketing Automation Engine (Windows Service or Azure WebJob)
  • Marketing Automation Reporting (IIS Site, API)
  • Processing Engine (Windows Service or Azure Webjob, New in Sitecore 9.1, not in 9.0)

1. Verify xConnect Internal Communication

Collection, Collection Search, and Reference Data all talk to each other, frequently. They are very chatty. This means, that if you look at the IIS W3SCV Logs for each of the IIS sites running Collection and Reference Data, you'll see requests going back and forth. The status codes in the IIS logs should always be 200 for each request. 500's, 401's, and 403's, all indicate there is a specific issue with those services.

NOTE: on a busy content delivery site, with LOTS of traffic, the CD is constantly talking to the Collection Service. This means you can see requests in the IIS log from the CD server, hitting the Collection Service. These should always be 200's.

PROTIP: 99.99% of the time there's an issue here, it's certificate related.

2. Verify and Inspect xConnect Service Logs (ALL Instances)

In the App_data\logs folder for the IIS Sites, or the App_data\jobs\continous\<service name>\App_data\logs folder for the windows services, inspect the logs and ensure there are no Applicaiton Errors being logged. When everything is running smoothly, these log files are NOT written to frequently.

3. Test Marketing Automation Reporting service

On the Content Management Server, open up Marketing Automation, and go into a plan (or create a plan). Start the plan, and then click reports. The reports should load (even if zero's) and not provide an error. Errors at this point indicate an issue that particular service (again probably certificates)

4. Testing the Marketing Automation Engine

There's no way to really test this service, except to ... well... start a plan and see if you can get a contact to go into it. Monitor the application log for errors, otherwise, just assume it's working.

That is in a nutshell, how to test all of the instances. Any issues, along the way, will require immense amount of troublehsooting that is really outside the scope of this answer.

  • thanks for this, was literally in the process of writing something for an internal document for a project I am working on haha
    – Anicho
    Commented Mar 5, 2019 at 14:43
  • 3
    I will send an invoice. ;-P Commented Mar 5, 2019 at 15:50
  • Nice write up @PeteNavarra
    – Chris Auer
    Commented Mar 5, 2019 at 20:51
  • Thank you @PeteNavarra. Appreciate your time for the detailed response. surely will update after verification .
    – Avinash J
    Commented Mar 6, 2019 at 4:23
  • Hey @PeteNavarra Great !!!!. verified all the logs its been two weeks and analytics works like Charm. the above instructions set a benchmark for me to test . but harder was to go to each server as i had 9 on premise serve and verify. Thanks a Ton.
    – Avinash J
    Commented Aug 2, 2020 at 9:01

You should be able to test all this, by making sure all of the xconnect sites work from the CM server.

Most will just return a time if you browse to the homepage.

Further to that just checking that all the Marketing Applications work in the admin console should be enough.

  • Yes All the app process returns a time .
    – Avinash J
    Commented Aug 2, 2020 at 9:02

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.