Hello Michael,

If you haven't seen it already, the IRIS Server Migration Guide contains a list of items outside of databases that you can export/import (such as web app definitions and tasks). You might find that useful as a starting point / reference.

You would need to custom-design a solution if you wanted to intermittently sync your other instances based on these exports.

Hello Ravi,

This is probably a better question for the WRC. You've redacted some information (the domain name) that could be helpful in understanding this behavior, and I suppose you'd be comfortable sharing those specifics with them. I'd look into the details of your environment such as permissions, etc., and make sure you followed the installation documentation.

Running the Installer on Linux or macOS

https://docs.intersystems.com/irisforhealth20201/csp/docbook/Doc.View.cls?KEY=HXIHINST_install#HXIHINST_attended_linux_macos

Note that only Mac 10.13/10.14 are supported for that version of IRIS for Health, and for development only.

Supported Technologies

https://docs.intersystems.com/irisforhealth20201/csp/docbook/Doc.View.cls?KEY=ISP_technologies#ISP_platforms

There is no 1 universal answer to explain 100% license usage, nor 1 solution to free up the licenses. Longhua Huang asked if a restart would "fix" the license problem, but that entirely depends on what is using the licenses. If you restart and the licenses get used again, you are no better off.

You need to look at what is taking up your licenses and understand what is going on in your application that could be triggering this. Were you running the instance without license issues before? If so, what changed? Maybe it is unusually high levels of activity or some particular action, but it would be unlikely for you and your commenters to be experiencing the same issue.

You can use the methods in this linked documentation to view your license usage. If you can't make progress in investigating, the WRC can work with you to look into your license usage.

I'm not sure I understand your question, but I would strongly warn against using Task Manager to terminate Caché processes. This could cause all sorts of problems including hanging your instance. If you need to stop a process,  you should use methods within Caché. If that doesn't work because the process is stuck at the OS level, then the safest thing to do is restart the instance/server. Failing that, you should reach out to the WRC.

For stopping the instance, I would agree with Kurro that "force" can be used if a clean shutdown can't continue for whatever reason, though you probably want to understand why.

Hi Joe,

That error doesn't indicate that it found the file, it just describes the path where it is looking for the file (per your configuration). If Ensemble can't access a file despite the file existing, this is likely an OS permissions issue. I would check to make sure the OS user Ensemble is using has permission to access the directories/file.

Outside of that, perhaps there would be other helpful evidence in the OS log, Ensemble ^SYSLOG, or the Ensemble event log.

Hello Vermon,

To be clear, SFTP "private key authentication" is really key pair authentication, meaning you need both a private and public key configured. If you just have 1 or the other configured, your service will attempt username authentication instead. The need for both keys is intrinsic to SFTP and is not Caché specific.

Settings for the FTP Inbound Adapter > SSL Config

"Once you indicate you are using SFTP, you can then configure the SFTPPublicKeyFile and SFTPPrivateKeyFile settings. If you supply values for both SFTP Public Key File and SFTP Private Key File, the adapter attempts key pair authentication. It does this in conjunction with the username and password supplied via the Credentials setting, using the password in the Credentials as the passphrase for the private key."

I'd suggest reviewing the following article for suggestions on how you can debug why the key pair authentication is failing:

https://community.intersystems.com/post/using-and-debugging-netsshsession-ssh-connections

Hope that helps!

Hello Yuri,

I am sure your InterSystems sales team would be happy to have an environment configuration planning discussion with you.

Outside of that, take a look at the following documentation. I am also going to link a developer community article series that covers some topics and best practices for Caché that you can apply to IRIS as well.

Vertically Scaling InterSystems IRIS

Preparing to Install InterSystems IRIS

https://community.intersystems.com/post/intersystems-data-platforms-capacity-planning-and-performance-series-index

Hi Kevin,

Just as a quick note, the supported way to change the service user on modern versions is using the setserviceusername command, and not to change the service user manually.

https://docs.intersystems.com/latest/csp/docbook/Doc.View.cls?KEY=GCI_windows#GCI_windows_nonadminperm_change

It wasn't clear to me from your description if you used this, so I'm not sure if manually changing the service could be a part of the problem.

For Caché, the restore should just be compatible. I just tested restoring a 2015 cbk to 2017 and confirmed that. For IRIS you'd need additional steps.

Supported Version Interoperability (docs for Caché 2017.2)

I'd look into confirming that the cbk isn't corrupt for whatever reason. Can you restore it on the original system? Perhaps you can review the checksum? Maybe you can try taking a new online backup or an external backup?

Outside of that, I'd second Robert's suggestion to reach out to the WRC (especially if the problem is urgent). Does the organization you are working with/for have a support contract?

Hello Azezur,

Info on the CSPSystem user can be found in a few places in the docs, like here:

Predefined User Accounts

"Default account representing the Web Gateway when it connects to InterSystems IRIS via Instance Authentication for Normal and Locked-down instances. InterSystems recommends that you change the password for this account from its initial value prior to going into production."

Hi Steve,

I don't have a lot of experience with this but I have heard of a Web Gateway container that includes Apache.

"The webgateway image available from InterSystems, which includes both the Web Gateway and an Apache web server, provides a web server component for containerized deployments of InterSystems IRIS-based applications. Automated deployment of the Web Gateway container can be effected by using manual procedures to develop a CSP.ini file containing the desired Web Gateway configuration, as well as apache2.load and apache2.conf files specifying the desired Apache web server modules and configuration, and placing them in their expected locations in the Web Gateway container (/opt/webgateway/bin/ and /etc/apache2/mods-available/, respectively) as part of the deployment process. The durable %SYS feature and the Web Gateway’s entrypoint application /cspEntryPoint.sh provide a simple way to do this, as the script automatically links these files (plus the CSP.log log file) to the corresponding files on the specified durable %SYS volume."

Hello Mikael,

What do you mean by locking resources? I think Call Interval should be appropriate for the behavior you want, but I'm not sure what complication you're referring to.

A common suggestion here might be the Ensemble schedule handler, but I'd not recommend that as per the documentation this isn't intended for specifying specific processing times, but activation windows for the interface. The documentation also discusses creating a more general scheduled task and having it call CreateBusinessService() and ProcessInput() but this would be much more involved than just using Call Interval.

One set of errors that stood out to me is:

09/25/20-15:45:16:790 (9924) 1 SNMP server failed to start: 0,Error (2) signaling Windows SNMP Service; check Service is installed/started.
09/25/20-15:54:17:010 (8972) 1 Error reading from SNMP port, Windows SNMP Service may have terminated connection.

I'd recommend reviewing the documentation I linked for some other suggestions, but I'd start by trying to verify that snmp works at the Windows level, separate from Caché.