Hi @gbeckett,

Glad to hear it is working for you! Please let us know if you run into any other issues.

Thanks,
Rich

Hi @gbeckett,

I just pushed out a pre-release version of ProGet 2025.24-rc.3 and can be installed via InedoHub. Please see our our guide on installing pre-release verions for more information. Please let us know if you have nay problems.

Thanks,
Rich

Hi @phil-sutherland,

Thanks for sending this over to us. This looks to be a regression in the PostgreSQL migration. I have created a ticket, PG-3241, to fix the issue. This will be fixed in the next maintenance release of ProGet 2025.24, due out on March 20, 2026.

Thanks,
Rich

Hi @gbeckett,

It looks like there was a merge issue and part of this fix was undone. I have created a new ticket, PG-3240 to fix it. If you would like, I can create a pre-release of ProGet 2025.24 with the fix that you can install now. If not, the fix will be released at the end of next week in ProGet 2025.24.

Thanks,
Rich

Hi @Valentijn,

We had a hiccup in one of our edge nodes that was preventing this version from showing up. If you check now, it should be available.

Thanks,
Rich

Hi @phil-sutherland_3118,

There is nothing off the top of my head that would fix this. The next step would be to see your LDAP queries and potentially some example data. It would probably be best to wait until you get a license if you do not feel comfortable sharing that data on the forums. If you care to look, you can see our code for both our AD User Directories and our OpenLDAP/Generic LDAP user directories on our GitHub repo: https://github.com/inedo/inedox-inedocore

Thanks,
Rich

Hi @sirko_6724,

Please let us know what you figure out. When we built our OpenLDAP user directory, we built it based on OpenLDAP's best practices for groups and this is the first time we have seen an issue with groups missing the member attribute. I know you are adverse to making changes to your OpenLDAP server, but another option would be to populate the users on the groups using a Dynamic List. That would allow you to add the user's dn to the group without having to change all the records.

Thanks,
Rich

Hi @phil-sutherland_3118,

Just to confirm, are you using an Active Directory domain or OpenLDAP doimain in your environment? Your initial post makes it sound like you are using Active Directory and not OpenLDAP. If you are connecting to Active Directory, you can use the following two LDAP settings to get groups and members:

• For List User's Groups: (&(objectCategory=group)(member:1.2.840.113556.1.4.1941:=%s)) and for get a groups
• For List Group's Members: (&(objectCategory=user)(memberOf:1.2.840.113556.1.4.1941:=%s))

These will only work when using our OpenLDAP/GenericLDAP user directory and connecting to an Active Directory domain, OpenLDAP domains do not implement these special queries.

That other forums post is a OpenLDAP domain that is using custom attributes for groups.

Thanks,
Rich

Hi @phil-sutherland_3118,

That is expected behavior. ProGet will always strip off the domain suffix from the username. Users in the past have created multiple user directories (one for each suffix) and then using the username@suffix (ex: user.name@company.group) as the login.

An alternative approach is to use the OpenLDAP/GenericLDAP user directory instead. It requires you to enter the AD-based LDAP attributes and queries, but it will not strip off the domain suffix.

Thanks,
Rich

Hi @caspacokku_2900,

Thanks for posting this! We are happy to hear you up and running! We are currently reviewing a default value for the concurrent request limit in ProGet. As more and more package managers push towards a larger dependency tree, this limit is becoming a requirement for some feeds (cargo, npm, and NuGet being among the highest).

Thanks,
Rich

Hi @michael-day_7391,

Thanks for sending this over! We'll get this resolved within the next couple of maintenance releases of ProGet.

Thanks,
Rich

Hi @michael-day_7391,

What version of Windows Server are you running?

When generating that command, ProGet will call Environment.UserName to determine the username the service is running as. I'm guessing this is returning the computer account instead of NETWORK SERVICE. I have crated a ticket, PG-3219, to review it, but I would like to test it on the same version of Windows Server as you.

Thanks,
Rich

Hi @michael-day_7391,

The docs say to use NETWORK SERVICE because that is the default account ProGet users when it's installed. You need to use the username of the account that the ProGet service is running as. If your ProGet service is running as MYDOMAIN\PROGET-SERVER$", then your netsh command should use that. If it is using NETWORK SERVICE, then you should be use NETWORK SERVICE. If you want to switch to a different username, then you need to first remove the urlacl by running the following, then re-add it with the correct name.

netsh http delete urlacl url==https://*:443/

The event viewer error Windows event viewer shows event id 1000, can be ignored. That is a default message that shows because we configure the URL binding in code.

The netsh http add sslcert command should only be used when you are using a haostname binding, since you are unsign *:443, you should not need this.

While you are working through this issue, I would change UseHttpsRedirection="True" to UseHttpsRedirection="False" in your config so you can still access the site over HTTP until you get this figured out. The ERR_CONNECTION_CLOSED message typically indicates an issue with the certificate binding. The most common issue that can cause this is when the permissions are incorrect on your certificate.

1. Open the Certificate Manager using Window's MMC
2. Navigate to Certificates (Local Computer) -> YOUR_STORE (ex: Personal) -> Certificates
3. Right click on the certificate and select All Tasks -> Manage Private Keys
4. And give read access to your service account

See more in our Troubleshooting guide.

Can you verify the permissions on the certificate?

Thanks,
Rich

Hi @caspacokku_2900,

I apologize for the confusion. I meant that running through the test example you provided (looks like that comment has since been deleted) and this new one, I was unable to recreate both the PostgreSQL errors and the "The given key 'version' was not present in the dictionary." error. I'm thinking the dictionary error is related to either the PostgreSQL errors or a hiccup in the network connection where the response was not fully returned, but had a successful response code causing the request to still be cached. What is also confusing is that the cache should refresh the request after 30 minutes. This means if the caching is causing the issue, it should resolve itself within 30 minutes. Also, I see you have set the metadata caching to 100, which cargo hits pretty quickly. I typically set that to 1000 requests in a crates.io connector because cargo is a very chatty client.

The main reason I was asking for a reproduction case is that I wanted to rule out an error in parsing the cargo metadata. With this latest test case you provided, I can verify that everything appears to be parsing correctly. I ran this build 30 times back to back with your settings and connector caching enabled (both metadata and crate caching). In between each build, I cleared the local registry cache and ran cargo clean. I was not able to reproduce these errors or cause issues with the connector cache. This leads me to believe that there is an environmental factor that is causing this issue. Can you please check with your IT team to see if there is anything they are seeing (external HTTP request manipulation, network packets dropping, RAM correction errors, etc..) on your server?

Thanks,
Rich

Hi @parthu-reddy,

That error looks to be an error that happens when the web server is shutting down and a message is stuck in the queue. We plan to fix this in the next maintenance release, PG-3214. It should be fin to ignore. Were you seeing something specific happening in ProGet when this error was happening?

Thanks,
Rich

Hi @caspacokku_2900,

Thanks for sending an example over. I did test this, but I was unable to recreate the postgres errors you were seeing. If you are using ProGet as a mirror to crates.io, one thing that may be helpful is to modify the Dependency Resolution on the Feed Properties page. Standard resolution has to check in ProGet to determine if the dependency exists or not to determine when to tall the cargo client to use ProGet vs crates.io. That will help with the retries and getting rate limited on crates.io. These are things to just help reduce load from Cargo on the ProGet server.

Does this happen every time you pull packages using cargo?

Thanks,
Rich

Hi @parthu-reddy,

Sorry about that, I got hung up on the request logging, let me dig into this a bit more. Are you using PostgreSQL or SQL Server?

Thanks,
Rich

Hi @parthu-reddy,

This was an oversight on our part. The UI just updates a value in the ProGet.confg file. If you update the ProGet.config file on the other two servers and add EnableRequestLogging="true" RequestLoggingDirectory="C:\ProGetLogs" to the WebServer node, that will enable HTTP request logging on those two servers as well.

I'm going to update the docs to include how to enable this when using a Load Balanced/HA configuration. I have also added a ticket, PG-3211, to update the UI to give guidance on this configuration.

Thanks,
Rich

Hi @caspacokku_2900,

Would you be able to send us over a Cargo.toml that can recreate the errors you are seeing? Although this all points to server overload, that will at least allow me to attempt to recreate the errors you are seeing.

Thanks,
Rich

Hi @matthias-schmitz_2037,

We actually were made aware of this by another customer this week (PG-3201) and we will be releasing a fix this Friday in ProGet 2025.19.

Thanks,
Rich