Hi @Jon , Unfortunately it's "not that simple", and this will require a bit of troubleshooting to figure out what the issue is, precisely. There are a lot of areas where this could occur, and we can't add a generalized "job killer" until we understand what the issue is. You'll have to dig in behind the scenes (Admin > Executions) and identify exactly where things are freezing. The last log message will indicate that. Try to find as many examples as possible. Keep in mind that Otter is not not really "connected" to a server, and a server does not (and cannot) "call home". Instead, Operations (i.e. OtterScript) opens a connection to a server, sends a command, then disconnects. All network errors we've ever seen in this process will yield a crash. However, unless explicitly specified, a command will not timeout. So this means if you run a PowerShell script that basically just says "sleep indefinitely", then the Execution will never complete. Obviously no one would write that script, but some PowerShell scripts have a consequence of that. No built in Operation should ever cause that to happen, which is why we need to know precisely where this is happening. Best, Alana

Hi @Jon Based on my experience, you need to add a configuration to each role like an ensure-file a dummy file to force the drift detection and the remediation for each role. Having a role without a configuration leave the status in unknown state. Hope this help Best regards PhilippeC.

Hi @dario-wigger_0347, The configuration looks okay, and is basically what we have documented. So I think it ought to work... From here, I would start by monitoring the HTTP traffic between Maven and ProGet. You can use a tool like Fiddler Classic on Windows or Wireshark. What you should see is: Maven issues a request, and ProGet returns a 401 with WWW-Authenticate: Basic header Maven reissues the request, sending a Authorization: Basic XXXXXXX The XXXXX will be Base64 encoded api:your-api-key. If you don't see that, then something else is wrong. I would post it and maybe we can help. You can also try downloading maven artifacts from an "Incognito" window. Your browser should also prompt you for a username/password, and then you can enter api and your api key. Thanks, Alana

Hi @gdivis, thank you for your response. I think it is a little bit confusing in general. Just for clarification: We are not using any symbol packages at all (neither .symbols.nupgk nor .snupkg). We are only embedding PDBs right into our .nupgk files. But it would be nice to strip the PDBs on package download. We can achieve this on ProGet by activating the symbol server for the legacy format. I was just confused on why I have to use "legacy" for this approach since it is also standard to embedd the PDBs instead of using symbol packages. I guess normally it won't be necessary to enable a symbol server if you are using embedded PDBs. But we want to see the symbol information for our packages and we want to be able to strip the PDBs on download. It seems to be more of a hack to use the legacy symbol server for this but we achieve our goals doing so. No need to file a bug for this. Thank you, Caterina

For the modules, 2 ways Create a second role which depend on the previous one and use Ensure-psmodule function to add the required module You don t need the set psgallery to be trusted if you use the Force in the Ensure-psmodule Cf https://docs.inedo.com/docs/otter-reference-operations-powershell-ensure-powershell-module

Hi @Justinvolved, The easiest way to setup a test environment for this would be to setup an instance of Otter (free edition is fine). Then once you have checked out https://github.com/Inedo/inedox-windows and made your changes, you can package the extension using the Inedo Extension Packager. This is available as a .NET tool. You can then navigate to the extensions page and upload the extension file to Otter. You may need to modify the AssemblyVersion in AssemblyInfo.cs to a version newer than the installed version to get it to pick it up as the lastest. Alternatively, you can copy that extension file to the Extensions.ExtensionsPath and restart Otter to have it pick up as well. The command I typically run to package the extension is: inedoxpack pack InedoExtension Windows.upack -o --build=Debug I run that command from the the solution file's directory. Hope this helps! If you have any questions, please let me know. Thanks, Rich

Hi @Justinvolved, Would you be able to send us the output of Get-Module -ListAvailable on PowerShell 5.1? I would like to take a look and see if there is anything causing a parsing error in Otter. If it is not safe to post here, you can email it to support@inedo.com and prefix the subject with [QA-1405] and then comment back here when you have sent it. Thanks, Rich

Hi @rhessinger Thanks, but I don't think we will need a pre-release. The remaining problem is basically a convenience issue (getting from the report to the package's info page with one click). Everything else seems to work as expected with the latest pgscan version.

Hi Alana, thanks for the information!

Hi @richard-allen_8963 , I'm afraid I'm really not sure how different versions the NuGet client tools behave in different scenarios... just really how ProGet works in implementing the Vulnerabilities information on the NuGet API. This API is used by Visual Studio, and in our testing, they show up as we expected -- so if you're not seeing the desired behavior, that's where you'd want to look. Using something like Fiddler, you can see what's being called. I do know there is an older, NuGet.org-only API that the tools may be calling. But we only implement the one I mentioned above. Best, Alana

Hi @andy222 , The Git issue should be resolved; that was related to some authentication issues with newer versions of GitHub Enterprise. It broke a lot of tools across the board, apparently. Anyway, I see it just got fixed today. Check out BuildMaster 2023.10-rc.5 if you can How about pushing a NuGet package instead? That's a much more common scenario (folks migrating from Octopus), and it's one we're going to add some good first-class support for in BuildMaster 2024. Thanks, Alex

Hello @atripp You save my day. Increasing the timeout resolve the pb. Thank you

Hi @atripp Thanks you for the tips Beste reagrds PhilippeC.

Hum, difficult to reproduce. it happens with new server. I will see if I can make a simple reproducible test case

@stevedennis This is perfect. I greatly appreciate this, Steve.

Hi @Justinvolved , Application Pools seem to run under a special user account (not NETWORK SERVICE, but like IIS\AppPoolName), so you need to give that user access. In any case, make sure to restart the app pool/IIS, otherwise the permissions may not cascade? It can be a bit tricky unfortunately. Cheers, Alana

Hi @Srinidhi-Patwari_0272 , In your command, you're specifying D:\ProGet as the target directory. The configuration files are written to %PROGRAMDATA%\Inedo\SharedConfig\. Cheers, Alana

Hi Adam, Thanks for the response. I think a rate limit on the API for Free licenses would be fair - I'd prefer that to a capability restriction in any case :-). The script I've been working is an evolution of a very basic one I wrote about 5 years ago that simply deletes the *.nupkg files off the filesystem storage if they're older than a certain date, so the package versions that my new one is deleting via the API are mostly a historic backlog of the version "stub" records - going forward the daily deletions will be a lot fewer so a rate limit wouldn't be an issue. This is all part of some work we're doing to migrate our Azure VM-based ProGet Free instance to an Azure Kubernetes container instance - we actually got it working pretty quickly and we're happy we can remove another VM from our infrastructure landscape. It's also going to allow us to reduce our Azure resource costs by quite a bit, so I'm hoping I can make a case to our team lead that we should re-invest that in an annual Basic license to take advantage of some of the additional features - I'm particularly interested in the package scanning and license scanning capabilities so . As an aside, I did find a small snag with the official Inedo ProGet container registry - it was mostly a problem our side but I'll post a separate ticket about it for completeness... Thanks again. M