Sitefinity Troubleshooting Examples

Support checks relevant Sitefinity settings and tries to reproduce the issue on a clean project. If not successful, Support provides self-troubleshooting guidance* but does not investigate the performance issue on the customer project or environment. If the issue reproduces on a clean project, Support logs a bug following Sitefinity Bug Fixing Policy and checks whether a workaround via the product UI is available.

At the Assisted level, the customer is responsible for collecting memory dumps and analyzing them until clear steps to reproduce on a clean project are identified.

*Self-troubleshooting guidance includes:

• KB articles about common performance issues.
• Sitefinity Diagnostics module doc.
• MS docs on collecting and analyzing Memory Dump.
• Suggesting links to 3rd party tools for narrowing down the issue.

If the issue is not reproducible on a clean project, Support gets the customer application to set it up in a known-good environment. If the issue does not reproduce that means that the problem is caused by the customer environment*. If the issue reproduces, Support removes all customizations from the project and determines whether the issue continues to reproduce. If the issue does not reproduce the case turns into Customer Application Isolation type case. If the issue continues to reproduce Support checks whether the database or project configurations are causing the performance issue.

At any stage of the investigation Support may host a meeting with the customer to get more information (Exploratory screen-sharing sessions).

If the cause of the issue is determined to be a product defect, Support researches whether a viable workaround exists using the product UI or API.

*At this level, Support does not troubleshoot the environment and points the customer towards the documentation to configure the environment correctly

Support helps the customer to collect the data necessary for analyzing the performance problem. Once the data is collected Support analyzes it to narrow down the  cause to the product, customization or setup/environment. If the cause is a customization, Support isolates the customization (See: After upgrading, Sitefinity does not start) and troubleshoots it (See: After upgrading Sitefinity, the project customizations no longer function properly). If the issue is caused by environment Support works with the customer to troubleshoot the environment (See: The Sitefinity Admin App is experiencing an exception error that only occurs on the production environment).

Support requests the error log and steps to reproduce. Support provides guidance to the customer to find a stable reproduction pattern. This includes asking various questions and suggesting that the customer tests more isolated scenarios (for example: test on one node only, with different users, different content items, etc.). When the customer finds a stable reproduction pattern, Support attempts to reproduce the issue on a clean project following the same steps. If Support reproduces the issue successfully Support confirms that the issue is caused by a product defect, logs a bug following Bug fixing policy and checks whether a workaround via the product UI is available. If the issue does not reproduce on a clean project that confirms that it is caused by an unidentified customization. The case becomes an Application Isolation type case in terms of how troubleshooting continues.

If the issue is not reproducible on a clean project, Support gets the customer application to set it up in a known-good environment. Support attempts to reproduce the issue on the customer project using a broad range of tests. Assuming the issue also reproduces intermittently on the known-good environment the case turns into Customer Application Isolation type case. If the issue does not reproduce at all on the known-good environment that means that the problem is caused by the customer environment*.

*At this level, Support does not troubleshoot the environment and points the customer towards our documentation to configure the environment correctly

Support implements additional custom logging in the product or customer application for the customer to deploy on their environment in order to gather information about the issue. If the cause is a customization, Support isolates the customization and troubleshoots it. If the issue is caused by environment Support works with the customer to troubleshoot the environment.

Support searches whether the error is documented in the knowledgebase and provides the relevant resources. If knowledge about the specific error is not present Support requests information about the setup of the customer environment and sends the corresponding official documentation and KB articles.

Same as Assisted.

Support confirms that the issue is not reproducible on other environments. Support may host a meeting with the customer and their infrastructure team to discuss what the differences are between a working and a non-working environment. Support may also attempt to replicate the environment in-house or implement additional custom logging in the product or customer application for troubleshooting purposes. When some differences are identified Support works with the customer to isolate which one is causing the issue and configure the environment properly.

Support checks for error logs and provides information about related known errors. Support explains that Sitefinity supports the OpenID Connect specification and that for the integration to work Oracle needs to support the same specification as an identity provider. Support provides documentation about the expected Sitefinity input/output parameters and refers the customer to the OpenId Connect protocol specification and Oracle Support.

Support cross references relevant Sitefinity settings with the OpenID discovery endpoint of the external Auth provider and validates correctness. Support informs the customer about any identified mismatches. It is up to the customer to correct the mismatches. If a mismatch is not discovered Support recommends that the customer validates that each http response from the external Auth provider conforms to the OpenID specification. Support recommends network monitoring tools that the customer can use (Fiddler Everywhere)

Support attempts to configure the Oracle Authentication Provider* on a clean Sitefinity project and provides the customer with the setup steps. If unsuccessful, Support asks the customer to engage Oracle support for direct collaboration. In such cases the end customer organizes and participates in the entire communication. Support works with Oracle support to find resolution of the problem.

* Depending on the 3rd party product, Support may create an account for testing or request that the customer provides one.

Support provides documentation articles about the SiteSync and Export for Deployment features. Additionally, Support answers the customer questions specific to either feature (for example: can you sync Permissions using SiteSync). The customer would need to determine the pros and cons of each feature for their business case and make a decision based on the available documentation of the features.

Support can host a meeting to discuss the questions that the customer may have and clarify the intended usage of each feature.

Support goes in-depth to understand the business use case. This may include hosting an online meeting to discuss the scenario. Support outlines the pros and cons of each feature as it relates to the business use case. The customer would make an informed decision based on all available information.

Support provides documentation for the Multisite API, Multilingual API and Pages API that are required to perform the action. Support answers any specific questions related to each API. The customer needs to write the necessary code for their use case and test it accordingly.

Support creates a custom code example that will combine the different APIs needed to showcase how to change the content of a Content Block widget that is placed on a page using sample data. The customer needs to test the code and adapt it to cover all of the additional requirements (e.g. personalization, actual data among others).

Same as Advanced.

Support checks the relevant Sitefinity settings considering environment config transformations. If the issue is not identified Support checks the known extension points that might be used in the customer codebase. If the cause is still not found Support implements and deploys custom logging in the customer environment. Support iterates on adding additional logging as needed and works with the internal infrastructure team to check for issues there.

Throughout the troubleshooting process Support also works to find a workaround for the issue. When a viable workaround is found and if the issue does not affect other Sitefinity Cloud customers Support makes reasonable efforts to identify the cause but may decide to freeze the investigation until more data is available.

Same as Assisted.

Support may host an exploratory screen-sharing session with the customer to expedite gathering all details about the issue.

Same as Assisted.

Support may host an exploratory screen-sharing session with the customer to expedite gathering all details about the issue.

Support establishes the versions of Sitefinity before and after the upgrade. Support provides relevant documentation about the breaking changes. Support works with the customer to confirm that the customization is registered correctly and is being invoked by Sitefinity as and when expected. This approach ensures that the Sitefinity product behaves as expected. If the customization produces unexpected results, it will be up to the customer to debug the custom code. If the customer isolates an issue with the Sitefinity API Support investigates it to determine whether it is caused by a defect or a different breaking change that the customer has not accounted for.

Support requests information from the customer about the customization behavior before the upgrade (e.g. video or link to a working pre-upgraded web site where the customization works as intended). Support may also host an exploratory meeting with the customer to clarify those aspects and gather details about what Sitefinity APIs are used in the custom code. Support confirms whether the upgrade caused the issue (breaking change/defect). If the issue is caused by a breaking change in the product, Support suggests the respective modifications as needed.

Support may get the customer project and reproduce the issue on a known-good environment. Support decomposes the customization to the Sitefinity APIs that are used and will research why they produce unexpected results. Support may suggest an alternative solution or validate potential changes on the customer project before providing them to the customer to test.

Support requests error logs or a screenshot of the error (if an error is observed). Based on the error message Support provides relevant resources or instructs the customer to remove customizations to determine which one causes the issue. Once the exact customization is identified the case turns into a Customization troubleshooting type case in terms of how troubleshooting continues.

Support gets the customer application to set it up in a known-good environment and reproduces the issue. Support removes all customizations to confirm that the issue is caused by that. Support works with the customer to narrow down which customization causes the issue. Once the exact customization is identified the case turns into a Customization troubleshooting type case in terms of how troubleshooting continue.

Support may get the customer project and reproduce the issue on a known-good environment. Support decomposes the customization to the Sitefinity APIs that are used and will research why they produce unexpected results. Support may suggest an alternative solution or validate potential changes on the customer project before providing them to the customer to test.

Support searches all available knowledge hubs (product doc, KBs, ticket archive) for existing information. If an exact match solution is found Support provides it to the customer to test and make it production ready. If not Support provides available resources for relevant extension points and recommends logging a feature request.

Support researches the available extension points, APIs and configurations in the product to come up with a customization approach. Support validates that it is feasible on a clean project with sample data. Support summarizes the approach to the customer and provides any code samples that were produced during the research. The customer uses the provided information and samples (if any) to build their production-ready solution.

Same as Advanced

VAPT scan reports are not standardized. They can be produced by automated vulnerability assessment tools or manual penetration testing performed by a security expert. These two methods lead to different results as they may not consider all available security layers of the application and its environment. Therefore, VAPT scan reports often flag items that are not real and cannot be exploited in practice.

At the Assited level Support does not evaluate VAPT scan reports with more than one item or without steps to reproduce. The customer is responsible for triaging each item in the report to confirm its exploitability. The customer needs to submit a separate support case for each of the confirmed vulnerabilities. Each case should contain steps to reproduce the reported vulnerability. If the vulnerability is confirmed it will be assigned a CVSS score that will dictate the appropriate actions described in the Bug Fixing policy. For high and critical scores Support will work with the security experts to find temporary mitigation steps which the client may use until the fix is released.

Same as Assisted.

Support triages the VAPT scan report and consults with the internal security experts to check whether there are items that are real and can be exploited. For all invalid or mitigated items Support provides information on why and how Sitefinity is secure. If any real vulnerabilities are discovered, they will be assigned a CVSS score that will dictate the appropriate actions described in the Bug Fixing policy.

For high and critical scores Support will work with the security experts to find temporary mitigation steps which the client may use until the fix is released.