You can reset the Admin user account password by stopping the ProGet Windows service, then running ProGet.Service.exe and selecting the "ResetAdminPassword" option. Make sure to restart the Windows service when finished.

Hello Antoine and Anton, I've filed this as PG-1376.

Hello Florian and Antoine, I've filed this as PG-1376.

Thanks it works. I can then continue my testing and integration. With kind regards.

Hello George, thanks for your quickly answer. Well, I tried to change the proget configuration ports on docker from 6580:80 to 80:80 and the problems have resolved. I Understand that although proget resolve correctly the url request http://proget.local:6580 and redirect the answer to 80 port when i tried to download a package with choco pack -source http://proget.local (previusly correctly uploaded on proget trought the portal) this query always bound to 80 ports and because of this it´s not possible to find the package and download it. I reinforced these arguments when later saw in the dockerfile details that mount the proget image te next string: (/bin/sh -c ([ -f /usr/share/Inedo/SharedConfig/ProGet.config ] || echo '<?xml version="1.0" encoding="utf-8"?><InedoAppConfig>ConnectionString>'"$PROGET_DATABASE"'</ConnectionString><WebServer Enabled="true" Urls="http://*:80/"/></InedoAppConfig>' > /usr/share/Inedo/SharedConfig/ProGet.config) && mono/usr/local/proget/db/bmdbupdate.exe Update /Conn="$PROGET_DATABASE" /Init=yes && exec mono /usr/local/proget/service/ProGet.Service.exe run --mode=both) I hopesfuly to correctly understanded that the issue was here. In any case now I have two current proget running. One on docker on 80/80 ports and other on windows. Thanks for your help.

Hi Alana, Yeah but that seems to be a bit to much. It removes some settings like the connection string. And requires you to have made a backup with each upgrade (it seems I don't have backups since switching to Inedo Hub).

This seems to be related to a specific package that you have in your repository. Most likely it's bad/invalid metadata, and the specifics were not anticipated and thus it's crashing trying to read it. Unfortunately we would need to know a bit more about that package, and why it's causing this problem.

It's fixed. Not only that, but listing the packages also seems faster. Thanks!

Behind the scenes, that's the only difference in how they're stored (and has been for as long as I remember); but I do know that data directly in the database is not officially supported. But for a one-off thing it's fine to do IMO

Since I wanted all of my values in the array to be true to have success in my PSEnsure I thought of different ways I could do this. I settled on counting the items in the array, and using the fact that $true -eq 1 and $false -eq 0 to build a value that should match the count. I added this to the end: $array.ForEach({if ($) {$val += $}}) $array.Count -eq $val Thanks for your help!

I know you can delete all extensions, restart container, then re-download as needed. Its should help!

We've included a fix for this in ProGet 5.1.0, which will likely be released tomorrow. Thanks!

Did you reset to the Built-In authentification options ? If so you can use the default Admin account with the Admin password. You can also browse the database, find the account value and add your user directly in the table.

Yes, that would fix the installer issue and we do recommend moving to SQL Server 2016. The bundled SQL 2005 instance in the old installer was intended more for quick setup for evaluation purposes rather than production use, but we did a very poor job of making that clear. We are fixing that now; we're working on updating all of our installers to detect the SQL Server version and suggest/require an upgrade. Here is the current article about SQL Server requirements - basically it's any version currently supported by Microsoft. Sorry for the confusion, and hope this helps!

The problem was our proxy. npm doesn't use the proxy exceptions that are configured in the system, so after updating them to include the ProGet server domain it works as expected.

Hi, I don't see any EventOccurrenceDetails in my database, and I am trying to troubleshoot why a package did not upload. I spied using Fiddler the HTTP request, and it seems I get back an Invalid API Key error. Has the schema changed? Are log files surfaced in the UI now?

Currently assets do not have any user-definable metadata like this, I guess because that would make them a lot like packages? Assets also aren't intended to be like a "SharePoint replacement", which is why we don't want to put a lot of extra features like versioning, etc. These are also hard to replicate, etc. That being said, we are open to changes, so please consider using the Feature Request Process. Note that, we also want to evaluate "why" and "how this would be used", and that's part of the feature/change process.

Thanks Greg, That cleared it all up for me.

Thanks. FYI: Retention policies should be ignored on free versions. But UNKNOWN does indicate the service user; so it's likely a retention policy job (which is run as part of feed cleanup). You can see the logs of those, and maybe see some more info...

There is a task attribute called "Delete Package". Just make sure you have a Task that has that attribute. You can see more info about it here: https://inedo.com/support/documentation/proget/administration/security/creating-tasks