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

If you need to supply credentials when connecting to the domain, make sure "Specific list..." is selected, and enter it as: domain.local,CredentialName Where CredentialName is the name of set of Username & Password resource credentials created via Admin > Change User Directory > Advanced > AD Credentials > Create

Thanks for the quick update John. Definitely looking forward to the 5.1 release now, once it is out of Beta.

Ok, I use this KB 2 days ago and i added netbios name, fqdn but same problem. I try to change the user context but same pb. Error 503 - service unvailabable I will change my stack of web and i will go to install IIS...but is strange for an editor to indicate don't use "web integrade proget server" Thanks.

Copying from associated support ticket: It's not a bug per se, more of a design flaw with the introduction of external package stores. Basically, it checked to see if the package could be opened and if not, deleted it from the DB. However, there are many reasons a package might not be accessible (network down, invalid S3 credentials, disk inaccessible, S3 down, etc.), so this functionality was removed since then.

Good questions; You can configure ProGet to block packages with "unassessed" vulnerabilities; this is not the default configuration because a lot of times vulnerabilities are discovered after you've already been using a package anyways That's true, but maybe we could expand webhooks? I'm not sure, but it seems like it could be a feature request if it's something you'd actually want to use, etc.

The tracking issue for this is here: PG-1309

This is actually an artifact of the OData specification from when ProGet was first developed - that was actually the preferred format specified, and NuGet.org didn't support $format=json, so we just followed the OData spec. Anyway, those are just .NET DateTime Ticks in there (and the +0 just indicates UTC), so in your example it would just be: new DateTime(636650168208570000, DateTimeKind.Utc) Of course, if we had it to do over again, it would be something more sensible like ISO-8601.

Hello William, This will be fixed in ProGet 5.1.2. (PG-1294)

The error is generic and there are many reasons why the SSL/TLS negotiation may fail. ServicePointManager.SecurityProtocol property selects the version of the Secure Sockets Layer (SSL) or Transport Layer Security (TLS) protocol to use for new connections; existing c# connections aren't changed. Make sure the ServicePointManager settings are made before the HttpWebRequest is created, else it will not work. Also, you have to enable other security protocol versions to resolve this issue: ServicePointManager.Expect100Continue = true; ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 SecurityProtocolType.Tls SecurityProtocolType.Tls11 SecurityProtocolType.Ssl3; //createing HttpWebRequest after ServicePointManager settings HttpWebRequest request = (HttpWebRequest)WebRequest.Create("https://google.com/api/") If you create HttpWebRequest before the ServicePointManager settings it will fail and shows the error message.

Hi George, Do you have any suggestion that I can do to fix this issue?. Thank you.

Confirmed that was the issue, thanks Tod.

It's possible it may work (I can't verify) if you specify the port in the domain controller host value under advanced settings (i.e. enter your-dc-server:636 as the value). See the LDAP Advanced Settings documentation for info on how to find that page to configure that value. If that doesn't work, I suspect a code change is needed - it is not clear via the Microsoft documentation what the default AuthenticationType is for this call: https://github.com/Inedo/inedox-inedocore/blob/master/InedoCore/InedoExtension/UserDirectories/ADUserDirectory.cs#L268

The sales team does not check posts on this forum. Please use the ProGet Quote Request form for quote inquiries: https://inedo.com/proget/pricing/request-quote

The issue that you linked has since long been resolved; it was a problem with our beta v4. At that time, the problem was the ProGet was "leaking" some connections (i.e. not properly disposing, as your DBA noted). So, if you're seeing the problem now, it's unfortunately not so "simple" of a problem to fix. It basically means that there is some sort of latency between the web/database servers and/or the database is not able to respond to queries as fast as the web server is making them. There's a lot of things that can cause these, from fragmented indexes to low resources on the database server. Do you know what changed recently? Etc. I'm afraid increasing the connection pool likely won't help :/

ProGet is licensed per server, so if you were to have two servers (even if one is just a test / pre-production environment), you would be required to a purchase a separate license. However, if it's just for migration purposes, then you can use your existing license for the migration period.

Basically you need to make sure all three servers have the same machineKey in the machine.config section. OrchardCMS has a nice docs page on it: http://docs.orchardproject.net/en/latest/Documentation/Setting-up-a-machine-key/

Hey! It did solve my problem, thank you so much! Have a great week-end. :)