Installation

The hostname should always be something other than localhost for all websites and services when configuring SEI, even if everything is installed on the same machine. The reason is that it can create instability while using the product if a hostname is set as localhost, particularly for an embedded application that does not work with localhost.

If a specific user is used for the authentication to a website or a service, validations are done to verify if the given user is valid. This validation is only an indicator to warn you of potential issues when authenticating.

For example, if you get the following warning, it might be because you do not have the required setup to access the specified domain:

To change the current domain of the machine:

1. Search for View advanced system settings.

2. Select the Computer Name tab.

3. Click the Change... button.

4. Change the domain name in the Domain field.

If no domain exists, follow the steps described here: https://www.groovypost.com/howto/join-a-windows-10-client-domain/.

When https is selected for the Web Server or Scheduler API, a certificate needs to be provided. If the wrong certificate is selected during the installation, it returns an error and SEI cannot be successfully installed.

When a certificate for IIS is installed, it is located either in the Personal or Web Hosting folders.

To view the IIS certificate:

• Open Manage computer certificates.

  

Some certificates install multiple certificates at once. The certificate that needs to be selected for the website using https is the one that is also present in IIS under Server Certificates.

To view the server certificates:

1. Open IIS.

   

2. Double-click Server Certificates.

To get around this issue, please follow the following steps:

1. Navigate to the installation directory of the SEI Server (default is C:\Program Files\Sage\SEI Server).

2. If the WebServer directory exists, skip to step 5.

3. Create a WebServer directory (casing is very important).

4. Run the installation/upgrade (it will fail again).

5. Right click on the WebServer directory and click Properties.

6. Navigate to the Security tab.

7. You will be prompted to fix the permissions.

   

8. Click Reorder.

   

9. Click OK in the Properties popup.

10. Run the installation/upgrade again (it should succeed this time).

When accessing the Program and Features or Apps and Features, you notice that the icon for the application is missing and you are unable to uninstall.

To remove the application:

1. Verify that the application is already uninstalled by checking if the application files are absent in your installation path.

2. If it is not the case, open the Programs and Features or Apps and Features window.

3. Double-click the SEI Server application.

4. A pop-up window is displayed. Click Yes to uninstall the SEI application.

   

5. If the application was not removed, use the downloaded package to uninstall it.

6. To make sure SEI is completely uninstalled, follow these steps.

To keep the application:

• If you wish to keep SEI installed, copy the downloaded package to the cache package folder shown in the initial error message.

  

If something goes wrong during an upgrade, the process will rollback and the package will re-install the previous version the application. For security reasons, the installer does not save the password of any previously used custom accounts and is therefore unable to reconfigure the permissions during rollback.

If you were using custom accounts for any applications or services, you will have to reconfigure them manually using the following procedure.

Perform these steps for the Web Server and the Scheduler API :

1. Open IIS.

2. Click Application Pools.

3. Right-click WebServer.SEI and select Advanced Settings.

4. Scroll down to Identity.

5. Click the ellipsis button on the right.

6. Select Custom Account.

7. Click Set and enter your custom account credentials.

   

8. Click OK in each screen.

9. Repeat these steps for the Scheduler API by right-clicking Scheduler.SEI.

The error “SchedSecureObjectsRollback: Failed to store ACL rollback information with error 0x80070002 – continuing” can sometimes be found in the installation logs even after a successful install.

This error is caused by a background process that runs when gathering rollback information in case of a failure. This error can be ignored as it is expected and would not cause any problem with the installation, nor would it block a rollback should it be needed.

You get this error during the SEI preparation step of the installation: "The components WebServer and Scheduler were not accessible during the preparation phase. Please read the log files for more details."

This is due to an incompatibility issue with IIS 8.5, which is used by Windows Server 2012 R2.

This issue can occur with the following SEI versions:

• 2022 R1

• 2021 R2.4

• 2021 R1.2

• 9.5.1176

You need to apply the following workaround to fix this issue.

1. Open the Web.config file. Access C:\Program Files\Sage\SEI Server\WebServer\Web.config.

2. Locate the requestfiltering tag.

3. Remove the removeServerHeader attribute.

   

4. Save the file.

5. Restart the application pools:

   1. Press the Windows key + R to open the Run window.

   2. Enter inetmgr and press the Enter key.

   3. On the left pane, click the little arrow to expand the connection.

   4. In the Application Pools tab:

      • Right-click Scheduler.SEI and select Start.

      • Right-click WebServer.SEI and select Start.

   

You see a Rolling back action message during the installation and the wizard displays the message mentioned above at the end of the installation. This is because the SEI components are not being installed in the proper order.

You must install some IIS features on the SEI Server before running the component installation again.

Select the following features under Web Server > Management Tools:

• IIS Management Console

• IIS Management Compatibility

• IIS Metabase Compatibility

You get a Windows pop-up and the SEI installation cannot proceed. This is because Windows has blocked the server executable to protect the computer.

To fix this issue:

1. Locate the SEI Server - WIN64.exe file.

2. Right-click the file and select Properties.

3. In the General tab, select the Unblock option.

   

4. Click OK.

When installing the Scheduler API in HTTPS, some URL rewrite rules are added to the web.config file. You might receive the following error message as regards to these rules.

You may also receive the Gzip option error message:

This issue may be caused by your antivirus blocking the SEI installation or ASP .Net 6 not being detected by IIS.

To fix this issue:

• Check your antivirus logs and add a temporary exception for C:\Program Files\Sage\SEI Server\Server, or disable your antivirus temporarily.

If the issue persists, perform these steps:

1. Try a repair of .Net 6 on the server:

   1. Try a repair of Microsoft .Net runtime 6.x.x (x64).

   2. Try a repair of Microsoft .Net runtime 6.x.x (x86).

   3. Try a repair of Microsoft ASP.Net Core 6.x.x (x64) – Shared Framework (x64).

   4. Try a repair of Microsoft ASP.Net Core 6.x.x (x64) – Shared Framework (x86).

   5. Try a repair of Microsoft .Net 6.x.x – Windows Server Hosting.

2. Try a repair of WebDeploy 3.6 and Web Platform 5.0.

3. Restart the server.

4. Install SEI server package.

For secure communication with your HTTPS certificate and TLS, we recommend utilizing the following ciphers:

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: This cipher suite employs the Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) key exchange, RSA for server authentication, AES-128 in Galois/Counter Mode (GCM) for data encryption, and SHA-256 for integrity verification. It provides a strong level of security for your application.

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384: Similar to the previous cipher, this suite utilizes the ECDHE key exchange, RSA authentication, AES-256 in GCM mode for encryption, and SHA-384 for integrity. It offers a higher level of security with a larger AES key size.

These cipher suites ensure that your communication remains confidential, secure, and protected against unauthorized access or tampering. They support the TLS 1.2 protocol and higher versions.

It's important to regularly update and maintain your HTTPS certificate and TLS configuration to benefit from the latest security enhancements. We advise following industry best practices and consulting security professionals to ensure your setup remains secure and up to date.

This wait type usually indicates that the SQL Server is short of the resources it needs to properly execute some workloads. Watch out for other adjacent wait types such as HTMEMO to help identify the root cause.

Most of the time, the limited resource is memory. In such cases, it is important to take a closer look at the available memory allocated to SQL Server and its usage, as well as the TempDB size and usage when these workloads are being processed.

Leveraging the Query Store can also help identify adjacent workloads.

Solutions

• Increase the max memory allowed to your SQL Server instance. This setting is often overlooked and a default value may be applied automatically at installation time.

  

• Allocate or add more RAM to the host.

• Identify adjacent or concurrent workloads such as backups, heavy scheduled jobs, data transfers and delay or reschedule them.

• Use the Query Store to identify the recent queries with heavy impacts on resources and optimize those.

CXSYNC_PORT is a more granular division from the CXPACKET wait type that was introduced in Azure SQL Database and SQL Server 2022 and will be included in the CXPACKET wait type in previous versions.

These wait types typically indicate that the SQL Server process has to spend time orchestrating parallel query executions. While this wait type is pretty common and is not generally a cause for concern, alarms can be raised when the wait time for a given query is disproportionate compared to its CPU time, as this indicates that a given query was put on hold for an excessive amount of time.

This is typically a symptom of insufficient processing power (CPU), but can be tricky to properly interpret. While reducing parallelism of some workloads reduces the wait times for the CXPACKET/CXSYNC_PORT wait types, it does not guarantee that the overall time to finish the workload will be lower than before.

Solutions

Keeping the above in consideration, there are a few recommendations to explore and experiment with:

• Identify queries from concurrent workloads to Nectari with a high level of parallelism. This can be achieved by checking the query execution plan of requests. Reducing the parallelism of these queries can help reduce the time spent by the SQL Server orchestrating them, but at the potential cost of performance.

• Verify that the statistics and indexes of tables involved in queries with high wait times are up to date and efficient. Optimizing the speed of these queries will lower the overload load on the SQL Server instance.