Hi @forbzie22_0253, Unfortunately, this is still required. By default on Windows, HTTP.sys reserves all ports below port 1024. The netsh http add urlacl url=https://*:443/ user="NETWORK SERVICE" tells HTTP.sys that NETWORK SERVICE can register port 443 and listen to all traffic on it bypassing HTTP.sys. If you specified a domain, https://my-domain.com:443 instead of https:://*:443, then HTTP.sys will handle all traffic but will allow NETWORK SERVICE to subscribe at that domain. HTTP.sys will still handle all traffic though. That will then cause the integrated web server (IWS) to use HTTP.sys instead of Kestrel, which is why we recommend the port binding method. This is all outside of IIS. That reason is also we added documentation on how to Use IIS as a reverse proxy. Hope this helps! Thanks, Rich

Hi @joris.guex, Sorry for the delay - I've been out of the office for a bit. I've logged this as PG-3379, scheduled for the next release of ProGet 2026.12 on Oct 2. I haven't looked at the code yet, but it should be another trivial fix to bring this fully up to spec. Thanks! -Greg

Hi @sai.pabbareddy, Glad to hear it all works as expected! Thanks, Rich

Hi @sai.pabbareddy, My apologies. Looks like I typoed the date on that other post. I had the day of Friday correct, but the date should have been Sept 18, 2026. It will be releasing later today (normally in the evening in EST). I updated that response also to have the correct date. Thanks, Rich

@rhessinger Thanks.

@atripp , Thanks for the info.

@atripp, Went back through your docs and our own notes trying to pin down a specific page, and honestly — we can't find one. The closest we got was a page showing how to create a Specified License Rule (e.g., setting GPL-3.0 to noncompliant), but every example there is clearly a user-configured policy, not a factory default. We think our original impression was a general one from early research rather than something we can point to a specific article for, so no need to go hunting on our end — sounds like it was just an assumption on our part rather than something your docs actually claimed. Good to have it confirmed either way: no default license rule ships out of the box, and creating one (GPL or otherwise) is expected as part of setting up a feed. We'll document it that way. Thanks, Sai

Hi @seanl_4808 , Like SAML, OIDC is not intended for developer/CLI tools, but desktop-based applications. I'm not aware of any client-tooling that supports or plans to support OIDC, so there's no sense in having a sever-based tool supported OIDC. API keys are considered the modern/secure solution. The reason that WIA/OIDC is considered less secure comes down to reducing the attack surface. A rouge user or process would be able to do very little with a limited-access ProGet API key, compared with domain credentials. Thanks, Alana

Hi @sai.pabbareddy , A 500 is an system error and would be logged under Admin > Diagnostic Center. It's possible there was system overload, network issues, who knows. I wouldn't worry about it. A 403 is a permission error that would be caused by configuration. It sounds like you resolved it by changing/modifying configuration, waiting for a cache to clear, etc. Thanks, Alana

Hi @sai.pabbareddy, [1] Here is some more information on PVRS vs CVSS: https://guides.inedo.com/vulnerability-management/cvss-pvrs/ Long story short, PVRS is designed for OSS dependencies and analyzes risk differently, in particular taking into account the custom risk profile you enter in ProGet (under Policies). [2] The NU1902 advisory comes from a vulnerability.base.json file that is cached both on the client end and ProGet end; you need to clear the http caches on NuGet (which you did), and ProGet will invalidate it about once an hour. You can force invalidation by restarting the service (Admin > Service) or manually assessing vulnerabilities (Admin > Vulnerabilities > Reassess), but that should only appear for test purposes. In a normal workflow the client will aggressively cache this file, and there's no real harm in having outdated information when following our recommended workflows. On that note.... we do NOT recommend you block downloads. It will actually lower your organization's security posture, not improve it. Please review this to learn how to "contain" properly: https://guides.inedo.com/vulnerability-management/containment/ Thank you, Alana

Crazy ... and this issue is still open https://gitlab.com/gitlab-org/gitlab/-/work_items/588736 That way the combination is not usable... I really wonder how the build in dotnet nuget tooling is working with the group feed.

Hey there, very nice to see this topic discussed here. Just my two cents: I'm running Grafana Alloy as a sidecar container, exporting the ProGet console output and the Nginx logs to a central Grafana instance. This gives me some visibility into how the application is running. Exporting the Logs from the database table via OpenTelemetry to some SIEM would be very nice too.

@atripp award for fastest forum response goes to you yep that seems to have solved it :) simple enough ;) Thanks! Maybe it would be an idea to highlight or add a little orange "stalled" badge on the ones in the list that causes the warning? Just a nice to have. Cheers Carl

Hi @certificatemanager_4002 , The API is a bit harder to use than just pgutil, so I'd suggest to use pgutil instead and it's easy to make a simple mistake like encoding something incorrectly. Without studying your code and having direct access to your ProGet instance, I cannot tell you what the issue is. But, since pgutil works we know the API is fine; here is the code that pgutil uses to delete the user: https://github.com/Inedo/pgutil/blob/thousand/Inedo.ProGet/ProGetClient.cs#L744 would suggest to use a local proxy tool like fiddler classic, proxyamn, postman, etc., that can capture and analyze local HTTP traffic so you can see the difference between what your code is doing and what pgutil is doing. Thanks, Alana

Hi @rob , When using the the subject name, the X509NameType.SimpleName is extracted and compared. Here's the specific logic: x509Store.Certificates.Where(c => c.GetNameInfo(X509NameType.SimpleName, false).Equals(config.Subject, StringComparison.OrdinalIgnoreCase)).OrderByDescending(c => c.NotAfter).FirstOrDefault() So if the "wrong" Server1 is being selected, I'm guessing it shares the same simple name. In scenarios like this, we recommend renaming the certificate (e.g. ProGetSsl), using a file, or the thumbprint. Thanks, Alana

Hi @gdivis Thank you so much for your support. Best regards

Hi @federico.conoscenti , Universal Package do support arbitrary metadata in the manifest file, and ProGet will display that on the UI. It's technically possible to add arbitrary metadata to other package files as well, although obviously ProGet could never know about or display that. However this metadata is not intended for searching or indexing. ProGet does not support "arbitrary, server-side metadata" for any package types. In other words, you cannot simply "tag" or "annotate" otherwise packages after they've been added to ProGet. This is intentional and by design, as it keeps the metadata contained to the manifest file (which is stored within the package file itself), which effectively makes it "cryptographically sealed" and cannot be tampered with. So, as you migrate from Artifactory, you'll need to change your workflows to support a more modern, package mindset. In case you haven't seen it already, we have a Migrating from Artifactory to ProGet Guide that you may find helpful. Best, Alana

Thanks for the feedback @lukas.christel_6718 In the year and a half since my last rant, it doesn't look like the state of OCI Registries has changed much. I haven't been seeing any real adoption beyond some quirky or niche uses cases like Flux, due to all the reasons I mentioned earlier. It's a terrible repository format. That said, S3 (or the API I should say) seems to have become a kind of standard, and we're seeing a lot of users switch to S3 alternatives that use the S3 API: https://blog.inedo.com/proget/s3-alternatives For example, we've switched to Wasabi and have saved a ton in egress fees. You should probably have some kind of S3-esque thing in your organization already -- and if not, you should set one up. ProGet Asset Directories are convenient, but they aren't designed to solve the same problems as cloud-like storage. Cheers, Alex

Hi @fhusson_1634 (and cc/ @dan.brown_0128), We conducted some research into MCP Servers and MCP Registries (or "Metaregistries" as they are technically called). However, based that, it doesn't make sense for us to pursue at this time or likely in the future. I'll share my (new) understanding; I don't think MCP Registries will be a thing a year or two from now. First issues comes down to quality. If you take a look at the Official MCP Registry, you'll see it's almost entirely just a bunch of AI-generated MCP Servers published by vibe coders. This one kid basically spammed the MCP Registry with hundreds of named-mcp-utilities, which appear to be like leftpad but for slop coding. There's just no sense in even attempting to curate MCP Servers from this mess - it's 99% rubbish on a good day. So best case scenario... you would have to point to a private MCP Registry, which are far and few between. The major AI tools (Claude, etc) just use a curated list of plugins that do the same thing. Second issue comes down to instability. The MCP Registry protocol has been changing quite a bit and isn't remotely stable enough to reliability aggregate or curate. Since AI agents are what's "talking" to an MCP registry, the protocol doesn't reaaaaaaaly need to be API-stable. Finally, it's pretty much obsolete already. The "old" (i.e. few months ago) way of communicating with MCP Servers was using a streamable-http interface, where your LLM and the MCP server "chatted" over a quasi-API. But now it's done through "MCP Server" packages. These days, your LLM agent now just "chats" using some specially-built npm or pypi MCP package. There are a ton available, just search "mcp" on npmjs.org for example. The LLM basically just downloads/runs these packages in a sandbox scripting environment, and the package then forwards that to a real API somewhere. ProGet already supports "MCP" packages. They are just regular npm/pypi packages. And, it turns out... the AI coding tools (Claude et al) already support private package registries. And that's exactly how a lot of our users have been working with ProGet for their AI-assisted teams. They curate these mcp packages just like they would any other. The future will probably just be packages. I have no idea if MCP will even be a thing in the future. It's just a "quasi API for LLMs". But it's clear that it's heading towards packages already, and I imagine that some ecosystems may add additional metadata inside packages to give the LLM usage instructions. Who knows. Best, Alex