hi Jonathan, can you help me with a test case on the duplicate server issue? Are you trying do an infrastructure import that has the same server name defined twice in the same JSON document?

This can occur if the username/password credentials for Git are invalid, or more commonly, if a Git raft is configured as read-only (which probably doesn't require authentication e.g. GitHub) then is reconfigured to support write operations.

There haven't been any other feature requests for this, and we haven't researched the feasibility of doing it; however we did add Impersonation and Process Isolation, both which were in-demand features.

This appears to be a bug with the ProxyRequest property, i.e. if it's true (the default), the response variable is not set. The tracking issue for this is here: https://github.com/Inedo/inedox-inedocore/issues/91

I haven't been able to reproduce this. What is the exact request you are making to the API that isn't working?

I actually added this but it wasn't released as part of the beta; it will be an option in the Status filter e.g. "Agent error", "Collect/remediate error", and "Any error"

Hello Jonathan, We use Proget to deploy our PSModules. The deployement is driven with an Otter PSEnsure fonction- check if module exist with a specific version, if not deploy - Each new server is linked to an Otter role and after remediation, the module is installed. To update the module, we change version number in a otter variable. Otter remediation make the job We call PS function from local script or from Otter plan directly or from module. Don't know if this your need but it is working fine for us.

Basically, you would create a Git-based raft in both instances of Otter, and have them both point to the same Git repository. The biggest gotcha would be that both instances can potentially update the raft, but as long as you're aware of that it wouldn't be a problem.

I'm just following up to see if you were ever able to work-past this, or if it's still an issue?

Apologies for the delay, I had to reach out to gather this information. What I learned was that this was a custom operation. Below is the link to its source: Yes, I made that operation to accommodate DSC Configuration scripts (multiple DSC operations encapsulated in a PowerShell script). I had built this on a fork of of inedox-windows. I just merged in the latest changes for the main master (it has been 6 months, so there quite a few changes). I have built it, but have not tested it since the merge. https://github.com/MarkRobertJohnson/inedox-windows/blob/dsc-ensure-config/Windows/InedoExtension/Operations/EnsurePSDscScriptOperation.cs

Hello Alana I agree. I know that one server should be assign to a single Environment. I already use Role for the Applications (One Role = One Application), but I cannot have 1 or more server per environment as our dev team and test team like to have plenty of environment so I need to consolidate multiple environment to one server. I am already using BuildMaster (with many Pipeline Stage) to deploy to a single server the environment I want. It was a request to improve Otter which already good to make my work more simple. I understand it might not be very simple to do it. Thank you for the reply Best regards Philippe

Are you saying you can't create a job from a template? The main purpose of the template is: Instead of specifying the plan and server targeting each time you create a job, you can create a job template that will specify these for you. The template can also specify variables that will need to be entered when the job is run. While this can save you a few steps when running jobs, the biggest benefit of job templates is that, once defined, you can now trigger jobs using a the job trigger API. This will allow you to use nearly any other tool, such as Jenkins or a PowerShell script, to trigger an Otter orchestration job. However, we plan to expand it to be a lot more useful with better variable selection, etc.

Got it! Then this would likely fall inline with an upcoming major feature, and the communication between Otter servers ("main" and "secondary" as you describe) would be done using API/HTTPS/Web requests, in a direction of ("Publisher" -> "Listener").

Unfortunately the Native API is essentially a database wrapper, and one of the few things that can't be handled at the database layer is encryption. While we want to create a resource credential API at some point, in the meantime, the only workaround would be to encrypt/decrypt the secrets yourself, using the Encryption Key stored in your configuration file.

Apologies - I broke that endpoint earlier ironically by accidentally disabling logging :( It should work now; I also note that you can request a key at https://my.inedo.com and manually enter it.

The latest agent can be downloaded from: https://inedo.com/support/documentation/inedoagent/versions

That worked great. Thanks!

Hi Dean Install and test :). It is working fine. Thank you for the resolution.

I will wait :) Thank you for your fast reaction Cdt Philippe

Just as an FYI, we're continuing our investigation and exploration of this under ticket EDO-5623 UPDATE: we've addressed a lot of these in the current version of Otter.