Hi @jimbobmcgee , Very cool! We did not forget about this, just got a bit behind on feature requests (which this got classified on) with ProGet 2026 coming out. However, we've added this to our BuildMaster/Otter 2026 roadmap to review and incorporate. We plan to start on that relatively soon, and it may be something we can easily back-port to BuildMaster/Otter 2025. We'll update once we make progress on this :) Cheers, Alana

Hi @jimbobmcgee , Thanks for all the details; we plan to review/investigate this via OT-518 in an upcoming maintenance release, likely in the next few two-week cycles. -- Dean

@stevedennis I understand not wanting to go in blind on something so low-level. For what it is worth, the monkey-patch I applied has been stable, so far, in my lab environment. Let me know if you need me to test a build, prior to Otter 2025.

Hi Dean, Setting RaftItemType_Code = 7 in this instance worked for me. Appreciate the list of valid types. Thanks for all of your help! Scott

@jimbobmcgee excellent thanks!! Release has been published then :)

Hello @atripp Oups ! I made a mistake, I used master instead of main for the branch. It is working fine Sorry for this Best regards PhilippeC.

@atripp Thanks for the update

@rhessinger, I can confirm that 2023.3 has fixed the issue. Thank you very much!

@atripp Good to know Thanks

Hi @atripp Thanks for the tips. Best regards Philippe

Hi @jimbobmcgee , The "Bad handshake" error is occurring (as you probably guessed) while trying to establish SSL tunnel. This basically occurs at the operating system level, and is usually a total mystery. The underlying error seems to be coming from SSPIWrapper.AcquireCredentialsHandle, and is just this: (0x8009030D): The credentials supplied to the package were not recognized I have absolutely no idea what that means, but... there's a ton of things I found via searching. A few articles are suggesting that it means lack of access to read the private key Maybe it's in the wrong folder (on the Otter server)? I think it needs to be in "Personal" folder of "Machine" certificates, but it sounds like it's definitely something wrong with Otter reading the certificate.... Let us now if you find out more! Hope that helps, Alana

Hi @jimbobmcgee, I just wanted to let you know that we just released Otter 2023 and it includes the name filter on the List action type on the Infrastructure API. Thanks, Rich

@jimbobmcgee said in Apply-Template adding unexpected CR newline chars: Without wanting to hold you to a particular date, what is the typical release timeframe? We're targeting BuildMaster 2023 for Q3/Q4 and Otter for Q4. We don't have any dates beyond that at this point. And it sounds like you understand quite well why we're not so keen to jump on making relatively easy changes - definitely a lot to consider. We have a lot of "product debt" like this and have learned to be a lot more cautious. That said, I think as long as it's documented it's probably okay. That's the hard part of course (writing docs) - but there's a Note attributes that can be added to explain things as well. cheers!

I thought I was wrong

Hi @philippe-camelio_3885 , We haven't investigated or changed this code in very many years (especially within the last year), so I wouldn't expect a changed result. Can you try the same troubleshooting steps as above? To find out where the invalid JSON is? Maybe it's comma again? FYI - we use Newtonsoft.Json for both serializing and deserializing (as you can see from error). It's really odd to be generating invalid JSON, but that's what the message is It could be related to an obscure bug, etc. We just have no idea and haven't investigated in past year. Thanks, Alana

Thanks

Hi @jimbobmcgee , The "Secret key" field is just an arbitrary string that needs to match on both the Agent and the Otter Server; it needs to be unique across your servers, as its used to uniquely identify an incoming agent connection. The UI generates a random string, but you can enter whatever you'd like. There needs to be a Server record on the Otter server (i.e. on the "Servers" page) before an agent can connect to Otter. This is true for either Incoming or Outgoing communication modes. This is often called "server registration". One option is to servers self-register in Incoming mode; you can have the the following script on first boot: Generate a random string ("secret key"); you could use a GUID use the Infrastructure API from the server to "register" the server using that key edit the agent configuration file to have that key start the Inedo agent service Hope that helps, Alana

@OtterFanboy got it, thanks! So this particular change is a bit more involved unfortunately. For example, if you clicked on "Windows Server", you wouldn't find any drifted servers - which would be confusing, because the environment would show as drift. I'll note this as something to think about for v2023

Good news

Hi @philippe-camelio_3885, This has been fixed and will be released in Otter 3.0.13 which is expected to be released on October 22nd 2021. Thanks, Dan