Hi @brandon_owensby_2976 , As I mentioned earlier, this is an issue with the dotnet container for Windows, not BuildMaster:, The underlying error appears to becoming from the dotnet tooling. Though it's hard to say without troubleshooting further. Basically, something in the stack is calling the Linux tool id , which isn't going to work on a Windows container. When you installed Git (which is basically a Linux tool), it must have included a Windows-version of id . That allowed the dontnet container to then work. You're probably the first person whose tried to use the dotnet container without installing Git as well ;) As for a better way, just run on a small Linux VM instead on your Windows desktop (Hyper V). You're going to run into a lot of headaches if you try to use Docker Desktop. Thanks, Steve

Hi @hardik.turakhia, Using nginx as a reverse-proxy in front of ProGet is definitely the easiest way. I'm guessing you already took a look at our example nginx config file. When it comes to certificates, I find that it's easiest to use .pem files on Linux. There are a lot of guides out there on how to convert certificates to .pem files and configure them in nginx. The best source is to check with your SSL provider on how to create a fullchain (includes the intermediate certificates) .pem file. We do have some notes in the HTTPS on Windows guide in the update config section that has some commands on how to convert a .pfx file to .pem, which includes some crossover with converting .crt files to .pem files. If you are planning to use a dynamic SSL provider like Let's Encrypt, certbot has an extension called certbot-nginx on most distros or via snap on ubuntu/debian distros. That will configure nginx for you. Thanks, Rich

Hi @sai.pabbareddy, If you could pull a full LDAP trace/packate capture that would be great. I also setup a single-domain/single-dc. I can even share my setup as I used a VM and docker to set it up. My VM is a base alpine install with docker, docker-compose, and nano installed. Here is my the compose file I tested with. NOTE: my container uses the host network mode because that was the only way I could get it to bind the port in Samba. This is probably not needed if ProGet sat in the same Docker network as the Samba container. version: '3.8' services: samba-test-ad: image: diegogslomp/samba-ad-dc:latest container_name: samba_test_ad hostname: DC1 privileged: true network_mode: host environment: - REALM=PLANETEXPRESS.COM - DOMAIN=PLANETEXPRESS - ADMIN_PASS=GoodNewsEveryone123! - DNS_FORWARDER=8.8.8.8 # NOTE: "ports" was removed because network_mode: host opens the container ports on the host natively samba-provisioner: image: alpine:latest container_name: samba_provisioner depends_on: - samba-test-ad # Shares host network context to communicate with the main container smoothly network_mode: host volumes: - /var/run/docker.sock:/var/run/docker.sock entrypoint: - /bin/sh - -c - | apk add --no-cache docker-cli echo "🚀 Monitoring Active Directory operational readiness..." while true; do if docker exec samba_test_ad /usr/local/samba/bin/samba-tool user list >/dev/null 2>&1; then break fi echo "⏳ Samba is compiling directory tree schema... checking back in 3s" sleep 3 done echo "🔌 Active Directory Engine Online and Accepting Modifications!" echo "--- Creating Test Groups ---" docker exec samba_test_ad /usr/local/samba/bin/samba-tool group add ship_crew || true docker exec samba_test_ad /usr/local/samba/bin/samba-tool group add admin_staff || true echo "--- Creating Pre-populated Test Users ---" docker exec samba_test_ad /usr/local/samba/bin/samba-tool user create fry FryPassword123! --given-name='Philip' --surname='Fry' --mail-address='fry@planetexpress.com' || true docker exec samba_test_ad /usr/local/samba/bin/samba-tool user create leela LeelaPassword123! --given-name='Turanga' --surname='Leela' --mail-address='leela@planetexpress.com' || true docker exec samba_test_ad /usr/local/samba/bin/samba-tool user create professor ProfPassword123! --given-name='Hubert' --surname='Farnsworth' --mail-address='professor@planetexpress.com' || true echo "--- Assigning Group Members ---" docker exec samba_test_ad /usr/local/samba/bin/samba-tool group addmembers ship_crew fry,leela || true docker exec samba_test_ad /usr/local/samba/bin/samba-tool group addmembers admin_staff professor || true echo "✅ Active Directory data successfully populated! Setup complete." Then for my ProGet configuration, I created a new V5: Active Directory and here were the settings: General Name: V5: Samba 4 Domain: planetexpress.com User name: Administrator Password: GoodNewsEveryone123! Connection Domain Controller Host: <IP Address of my VM> LDAP Connection: Use LDAP Then I tested using Load user by username for the user fry in the group ship_crew. For recursive groups I used the user Administrator and the Group Denied RODC Password Replication Group. Then I added ship_crew to the Administer task and I logged in using fry/FryPassword123!. Thanks, Rich

@atripp Hi Alana, Thanks for the clarification!

Hi @amy.j , Without a reliable publish date, there's no reasonable way to rely on an automated compliance rule that relies on the publish date. I would recommend developing a Maven-specific approach, since this feed type is so limited. You've probably noticed it already, but license detection is also not very reliable. But, I wouldn't worry too much about it. Keep in mind: the Java ecosystem seems to publish much less frequently than JavaScript there are fewer transient dependencies in Java version ranges tend to be less popular and much more conservative Also there seems to be an issue with pulling in certain jar files, eg, when org.springframework:spring-webflux 6.2.19 is promoted no jar file is listed - so cannot be consumed. This has happened for a few packages. This is probably related to that unreliable Maven Index file. The Maven API does not support "file listing", so there's no automated way to know what artifacts are contained within a particular release. You just "kinda know" by reading the project's release notes, etc. Early on, we just "assumed" there would always a .jar file, but I guess that's not the case because there are .war and .ear files too. We also considered parsing the web-based file listing page (e.g. spring-webflux/6.2.19, but a lot of repositories don't provide a listing. We're open to ideas, but it's just an unfortunately limited ecosystem. Thanks, Alana

Hi @sai.pabbareddy , Those are both "packages" that contain the same kind of license (ProGet Enterprise). A single ProGet Enterprise license will allow you to configure a ProGet instance as a HA/cluster. "Enterprise Essentials" contains ONE license of ProGet Enterprise and no services "Enterprise Complete" contains TWO licenses of ProGet Enterprise plus services Organizations will often get two licenses of ProGet Enterprise to create two different environments (one Production, one DR/Testing/Training). Hope that helps clarify :) Thanks, Alana

We've scheduled PG-3386 to resolve the slow multi-build analysis on Postgres. It will be included in ProGet 2026.12, which is scheduled for release on Oct 2.

Hi @amy.j , This package is a bit weird in that (1) it uses a file-embedded licenses, (2) there are 172 contained files, and (3) some of those files don't follow standard naming conventions. When those things happen, I think we get results like this. The easiest way to work-around this is to just assign a license directly to the package using the Purl (i.e. pkg:pypi/charset_normalizer@3.5.1). You can do that by editing the MIT license type. Thanks, Alana

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.