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.
- 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).
- 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).
- If you do, then you have just validated, xConnect Collection Service, xConnect Collection Search Service, xConnect Reference Data, Sitecore Processing, and lastly Sitecore Reporting.
- 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.
