administrators

Hi @imm0rtalsupp0rt ,

Great, thanks! I'll share the pull request with our technical writing members; they handle the HOWTO type articles and may want to add more screenshots, etc. But that intro paragraph will really help them.

Changing the texts is trivial; it'll be implemented via PG-3278 in the next maintenance release of ProGet 2026. FYI I also changed description too:

Chocolatey Community Packages

Cache and filter packages from the Chocolatey Community Repository (CCR).

Cheers,
Alana

Hi @Nils-Nilsson ,

FYI this is available in inedo/proget:26.0.1-ci.7 should you want to give it a shot!

Cheers,
Alana

Hi @Valentijn ,

This looks like some consequence of a platform change (we went from .NET8 to .NET10), but it's hard to say.... I wonder if there's some kind of issue with the mixed bindings (i.e. using port sharing for https, but not for http).

What does your <WebServer> node look like in your configuration file?
https://docs.inedo.com/docs/installation/configuration-files

Can you try it without port sharing? So basically just http://*:8624, https://*:443

Thanks,
Alana

Hi @Nils-Nilsson,

We identified the issue with the UI and have fixed it in PG-3277. This will be released next week in ProGet 2026.1.

As for the UserNotFoundException after the rollback, that is most likely related to your cookies. Once the cookie expired, it then let you login again. You can verify that by using an private/incognito window and logging in or clearing your cookies and logging in again.

Thanks,
Rich

Hi @Ashley ,

It should have been; I just double-checked and see a commit for "Add full PEP 700 conformance for PyPI feeds" that appears to add the fields discussed here and some more.

Thanks,
Steve

@Nils-Nilsson FYI quick update, but it does look like LDAP searching is having issues in the UI.. so perhaps it's some kind of UI//library upgrade regression. Anyway we'll update once we have a fix.

Hi @Nils-Nilsson,

Aside from library/dependency upgrades, I'm not aware of any changes to AD/LDAP that would yield this change. So it's definitely possible a dependency update caused that, we'll keep our eyes out... but things did pass our ordinary LDAP/AD testing, so any other info would be really helpful ... like if it's easy to do a new testing instance so you can upgrade/downgrade to find if that's definitely the issue.

As for permissions/tasks, there were definitely no changes here. The tasks/permissions data were not touched as part of the upgrade, nor was the data/schema changed; the renaming of "Feed Groups" to "Feed & Project Groups" is entirely cosmetic.

Behind the scenes (in the database), it's still FeedGroup_Id. The only schema changes were related to creating new tables for vulnerability data and adding a column to projects table to support grouping. There were no data updates.

Thanks,
Steve

Hi @ybaskar-temp_3339 ,

Thanks for confirming that.

I think it'd be worth exploring how to change those migration/environment constraints. While it's unfortunate to "lose history" and need to navigate to a separate instance, there's a moderate amount of risk in things simply not working the way it did before.... we're talking a decade of evolution, including platform, architectural, and even usage changes.

That said, for an in-place upgrade, here's the approach that I would use.

1. Use the Legacy (Traditional) installer to get to BuildMaster 6.1.
2. Verify things work as expected on BuildMaster 6.1, agents updated, etc
3. Upgrade to BuildMaster 6.2, again using the traditional installer
4. Verify things work as expected in same manner
5. Uninstall
6. Ensure all components (iis site, service, program files.... except database, artifacts) have been removed
7. Install BuildMaster 2025 as per normal, pointing to existing database

Note that there's a decent change that you'll run into database or binding errors after #7, so make sure to run buildmaster.service.exe run from the commandline to better see messages and errors if things don't start up.

Cheers,
Steve

@steviecoaster sure thing!

https://github.com/inedo/inedo-docs/tree/master/Content/proget/feeds/chocolatey#.md

There's a "hidden in plain sight" GitHub link under the heading of each article, mostly for us :)

Figured a PR/example would be easier than back-forth on forums. Thanks!

Hi @pg_user_8607 ,

Unfortunately, the only information we receive from the underlying library is LdapReferralException, so there's nothing else we can log. My understand is that the server is limiting the information and you ought to see more information from the LDAP/AD server's query logs (they are like HTTP access logs). That's the absolute best place to look.

In our experience, a referral typically means the domain name is incorrect (e.g. user@domain.com instead of user@domain.local), but it could be any of the things you mentioned to. Unfortunately, LDAP/AD configuration can be a pain in rare cases (which it sounds like you are), and there's just no way around that.

As for monitoring, here is what we recommend:

• periodic monitoring of the /health endpoint (every 5 minutes)
• (optional) HTTP access logs (retain for 7 days)

There's nothing required beyond that. Those "container logs" (i.e. proget console output) that you see are primarily intended for us (product engineers) to troubleshoot problems and there's not much value in trying to use/storing them.

For a tool like ProGet, trying to do extract/monitor detailed metrics is counter productive and leads to information overload. Many "errors" are not problems are a total waste of everyone's time to troubleshoot.

For auditing, ProGet maintains internal audit logs (you can query them from the database if you really want to "export" them), or you can use webhooks if you want to publish events. But again, we don't think that's productive; they just become a "secondary log" that no one looks because it's harder to query than ProGet database.

For authentication-related information, a combination of HTTP log monitoring (403 errors) and LDAP/AD server is the best thing to check.

Cheers,
Steve