Hi @monika-sadlok_5031, That error means that the ProGet application container cannot make a network connection to the the SQL Server container. I would try to restart the containers, start with SQL Server. Make sure it's running. If it's running, you can try connecting to it with another tool like SSMS if you'd like to verify.' Otherwise, on the ProGet side, you can only configure the connection string; upgrading or changing the license key has zero impact on this. If it worked in the past, then it means that the SSQL Server container is not running or your network/container configuration changed. This can be hard to discover exacgtly what changed, so I would recommend "starting from scratch" on a new server/environment, then compare/contrasting what changed. Sometimes it's as simple as a typo or an errant - (dash character) in the wrong place/script. Cheers, Alana

Hi @mikes_4196 , Per the discussion above... can you tell me a bit about "we" (i.e. the size/profile of your organization) and describe how you are using winget in your organization? And why did you use WinGet instead of Chocolatey? Per the discussion above, it does not look like a tool/ecosystem that is usable at scale. I get that it's built in to Windows, but I haven't seen a case study demonstrating a real deployment -- even within teams at Microsoft. The "central repository" is just a giant mess of files in a GitHub repository and can't reasonably be "proxied" via a connector like other feeds. They apparently have "private repositories", but there's no documentation/guidance on how to create/use private packages for end users, so I don't think many are doing this. But open to learning more. Cheers, Alex

Hi @forbzie22_0253 , Similar to the UI, packages are still returned in the API - they just have a flag set to indicate they are unlisted/deprecated. It's up to the client to determine what to do about that. I don't believe the Find-Package cmdlet works with these properties; I think only Visual Studio will hide/warn about them. Thanks, Alana

Dear @dean-houston , Thanks for your guidance. Following the steps in the provided Docker guide, I was able to successfully build a multi-platform image, and the “Fat Manifest Image” information now appears correctly in ProGet. This resolves my question, and I really appreciate your help in clarifying the process.

hi @jaehyung-shin_8059 , If you click on the latest tag, do you see any information about the packages in the container? Container images are scanned on upload if they are small or queued to be scanned in the background if they are large. There are sometimes errors scanning containers, and if so, these errors will be logged... typically under Admin > Executions. -- Dean

@parthu-reddy yes, but we do recommend migrating... There are some known bugs/quirks with Maven (Classic) feeds and we will not fix them. We will likely not migrate them to PostgresSQL, which means you won't be able to migrate to PostgreSQL in ProGet 2025+. So it's likely that ProGet 2027 will not support them.

Hi @parthu-reddy, For a major upgrade, we recommend to schedule a maintenance window and then stop traffic from the load balancer. Then, upgrade the servers. For a maintenance release, it's fine to just upgrade them one at a time. It only take as few minutes to do that. There may be a few errors with the database/code being out of sync, but it likely will not cause any problems. -- Dean

@dean-houston Thanks

Hiya, We changed the setup to root, but still encountered the same issue. Besides rootless container policy we're also doing segmentation of every platform, so only allowing powershellgallery.com wasn't enough. after extented search and looking through logs we saw that the CDN's of powershellgallery were being dropped. Will probably revert the setup and go back rootless after the holidays to see if everything still works flawless, be I guess it will be fine now :) Thanks for your insight!

@sneh-patel_0294 I don't think so, its only displayed on that page...

@forbzie22_0253, From an API standpoint, I believe only npm packages support server-side tags. Rubygems might, but in any case we strongly advise against using them: https://blog.inedo.com/npm/smarter-npm-versioning-with-semver/ Server-side tagging is not likely something we will support in the future. Deprecation and Listing are really only there because many of the client APIs support them. I'd need to see a strong, specific use case. If it's related to quality (e.g. dev, staging, prod), then it's a "hard no" because our solution to quality is prerelease version numbering/tagging with repackaging. I do know that Sonatype Nexus has always supported tagging, but their repository is more of a "fileserver with server-side metadata" and ProGet is package-based. The only documented use case they have for tags has been quality, and our solution/approach is far superior. Cheers, Alex

I am also against DinD because the way I saw it done involved installing a specialized runtime and I'm not particularly crazy about doing that. I'd like to find a more portable way of doing it. I admit I am new to Proget/BuildMaster/Otter and really like it so far. So I am sure that I will engineer some solutions that are, to be frank, Rube Goldburg-esque.

Hi @it4it_9320, That's about the size I'd expect for a connector to that index. So far, I can't get it to grow much beyond that - I'm wondering if this was caused by the transaction rollback after the constraint error happening over and over. In any case, we'll add an explicit VACCUUM after major updates that ought to prevent the index from expanding again. -Greg

@atripp hi, i already searched the internet and found nothing helpful. this is why i turned to you . as said, i will start over and try to give you the output. thanks, udi

Hi @atripp , Thanks for the suggestions. Concerning the LogMessages table, we already have those messages displayed on the OpenShift console, but nothing suspect can be seen. What I'll try is to test a fresh install of the last BuildMaster version and see what difference we have with our "updated" version. I'll keep you in touch. Marc

Hi @paul-kendik_9721 , It looks like you're on the right track with troubleshooting -- the issue is indeed related to SSL/Certificates. This is all handled at the operating system level, which means there's nothing we can do on the application (i.e. ProGet) side of things. Unfortunately, I've never seen this error on a modern Windows server so I don't know what exactly to suggest to fix. I didn't even know TLS 1.0 was enabled on Windows still. Maybe it's not even the server, but like a proxy or some kind of intermediate server? The "good news" is that this is an easily searchable problem, so I would start by searching for "Windows 2022 SSL HandshakeFailure TLS 1.0" and see what comes up. There is certainly some kind of setting on your server taht is causing this problem, I just don't know what to suggest to look for. Please let us know wat you find! Alana

@daniel-lundqvist_1790 no problem.. docker is really confusing/silly... , glad we got it solved :)

@atripp Thanks for your reply... This is a good reason to planify an upgrade! Marc