I have justed tested some uploads with 2022.24 and it seems to work fine now, thanks!

Hi @apxltd, thanks for the insights! I half expected this to be way more complicated than I had hoped for, but one can dream...

I hate to say this, but its working now. Without making any configuration changes, I uninstalled Otter via the Inedo hub, rebooted the server, then reinstalled Otter. I was then able to add an agentless server without issue. I'm obviously happy that it's now working, but I'm sorry for making you look into this. Thanks.

Hi @pfeigl, Thanks for letting us know. It looks like this is related to how HEAD requests were handled. I went and added that header to head requests also. This will be tracked in PG-2300 and will be released in ProGet 2022.25. Thanks, Rich

Hi @OtterFanboy, Good catch. I'll get the documentation updated shortly to reflect this. The older version of the Inedo Agent was only a 32-bit requirement, but we changed it to a 64-bit requirement in the newer agents. Unfortunately, I don't remember which version it changed in though. Thanks, Rich

@lm said in HTTPS with self hosted ProGet and internal web server: There is updated documentation with step-by-step instructions here: Thank you. I was confused by the section "IIS & Web Hosting on Windows". I only searched in "ProGet". It should also be mentioned to open the other port as well which should be pretty obvious but who knows. I now only need someone here to provide a certificate.

Hi @testintergraph_2317, It looks like there was a hiccup in the release of the updated InedoCore extension. You should now see the ability to upgrade to the InedoCore v2.2.1 version. That includes AD v4. Sorry about the confusion there. Thanks, Rich

Hi @priyanka-m_4184 , thanks for updating; yes in this case, it must be a really large package file? 30min is long time, and the upack client must be timing out then.

Hi @arozanski_1087, I just wanted to let you know that we just released a new version of pgscan, 1.4.2. Going forward it will automatically scan npm packages anytime it is scanning for NuGet packages using a .NET solution or project, there will not be any new parameter needed to enable the search. We are still working on adding yarn support, but that one will take us a bit of time to add. We will update you when that one is ready to be used. Thanks, Rich

Hi @OtterFanboy , I was able to identify/fix this as BM-3818; looks like the issue was purging a deployed build from a deployed release causes the overview page to crash. You can work-around this by finding that release on the main "Releases" tab and purging it too. Cheers, Steve

I tested the new version (local, brand-new installation) and now all corrections to version numbers are consistent. Thanks for the quick fix!

Hi @joacim-svensson_8194 , That should have worked, but it's of course possible there's a bug. Can you confirm steps? Is this basically what you did? Create Two feeds (Feed1 and Feed2), download a vulnerable package in each feed Create Two Vuln Sources (OssIndex1, OssIndex2), associate each to each feed Run the "Vuln Downloader" Job, and see two identical vulnerabilities added to ProGet Assess the vulnerabilities differently (1 = Block, 2= Ignore) Package should Blocked on Feed1, and allowed on Feed2 I want to make sure we're following the steps you did, so we can test this. Cheers, Steve

Hi @smiller-circ_2844 , Product activation is required. If you're unable to keep the same MachineID, then you'll need to get an activation code from my.inedo.com. While it's not officially supported and isn't documented, you could "listen" to the activation request that ProGet makes by using a proxy server like Fiddler, and make the same API request with your key. You would then need to add that value to the database. I don't want to give specific instructions on how to do this, because like I mentioned it's not officially supported -- but it's not "too difficult" to do, if you're familiar with the above. Cheers, Steve

I wait for the next official release. i have a workaround with disable the permission

Hi @atripp, Thanks that helped me solve it pretty quickly, just a typo somewhere in the script variables. Very happy to have learned about the verbose setting :-) Justin

@stevedennis This is amazing, what a great feature.

hi @cshipley_6136, We chatted a bit about this as a team today. We believe that the application failed during initialization (i.e. the first web request after starting the service); when this happens, the error message will be returned until you restart the application (container/service). This is by design; there's no way to guess where or why the initialization failed, and if we "crash" the application (and trigger a restart), it can end up in a endless loop and make diagnosing really difficult. In this case, the error is network related (server name not found). That error can be transient when you have network problems, or permanent if it's a typo in the connection string. Since restarting the application (container) fixed it, then it was a transient network issue that happened during initialization. Hope this helps, Steve

@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

Hello @OtterFanboy , Thanks for the bug report! We'll fix it via OT-483. That tab only displays if "Configuration drift:" is set to something other than "None", but there should be a "no roles" type of message instead of a crash. Cheers, Alana

Hello @OtterFanBoy123 , I was able to reproduce this; it's a UI regression BuildMaster 2022's new OtterScript editor. This won't impact deployment, the script, or anything like that. I've logged this as BM-3817 and we'll try to get this fixed in the next maintenance release :) Cheers, Alana