The error you shared was: An error occurred processing a PUT request to {url}: Invalid user name or password. A PUT request is what the NuGet client does to push packages to a feed. You'd want to look for a message related to GET or other requests. But, if you're seeing an unknown, then the problem is likely authentication related, but you'd have to look in the error log, it could be a bad url too... You can always try run fiddler, and attach ProGet to the fiddler proxy server to see precicely the requests that proget is making as well.

If the feed is reporting "healthy" that means that an initial check passed. The 500-status errors will be logged on Admin > Error Logs; without seeing those, it's not really possible for us to advise on what the issue is. Hopefully that will give insight as to what could be failing. You may need to attach a proxy server between ProGet and MyGet (e.g., install Fiddler on the server, then point ProGet to use the Fiddler proxy), in order to capture the traffic.

I updated the default schema on the security group I was using to dbo and I was able to run a successful install. Thank you!

After upgrading both the ProGet VM and our (potentially underpowered) Active Directory VM to more cores/more RAM, we seem to have worked around the issue. Thanks for the tips!

ProGet is designed for enterprise/organizational package management, and this is simply not a requirement or desired at all in those environments. So, it's highly unlikely we will add first-class support for this. Some organizations have created custom user directories for this purpose, which is possible with the SDK. Note: if you are a component company, you may want to contact us to see about partnering. We work with a handful of component vendors who use ProGet as a "back/middle-end" and then have a very simple customer-facing front-end on top of ProGet that integrates with their CRM, authentication, etc.

This is not currently supported. If you are a component company, you may want to contact us to see about partnering. We work with a handful of component vendors who use ProGet as a "back/middle-end" and then have a very simple customer-facing front-end on top of ProGet that integrates with their CRM, authentication, etc.

We just updated our server from 4.0.8 to 4.2.0 and now we encounter this problem too. After confirming that the package/version should be deleted, you are redirected back to the feed but the package/version is still there. In the log there are no errors whatsoever and the recent error log shows "There are no recent errors."

The Jenkins / ProGet Plugin has been updated to Version 0.3 with the following changes: Expand variable correctly Some basic validation on the version number If you update, then it should work!

i updated to PowerShellGet 1.1.1.0 and it solved my issues. Release Notes PowerShellCore support Security enhancements including the enforcement of catalog-signed modules during installation - Authenticated Repository support Proxy Authentication support Responses to a number of user requests and issues

This was a regression in 4.1.2, but it is fixed now in 4.1.3.

angular-cli gave me problems. It tries to retrieve dependent packages from https://registry.npmjs.org. ( https urls don't works on our dev pc's) At the moment I also configured the server with the feed as my proxy server, so at least that traffic passes over this server for all package handling. (I also have github and such) Tnx for any info you can provide Stijn

Can you share both the .nuspec and packages.config file? That would help quite a bit.

Sorry for a late follow up on this. So one place where this solution falls apart is that your Jenkins add-on for BuildMaster does not support the meta-tags in the version field.

It's hard to say where the issue lies, but I would suggest to attach ProGet to a proxy server like Fiddler, so you can watch the requests that are made to npm vs MyGet. Ideally, a request to ProGet or MyGet should look and behave the same as a request to npmjs.org. But npm is an undocumented protocol, and there are a lot of quirks, so oftentimes it doesn't.

With regards to my question above, I have found this blog article that has helped me: https://richardspowershellblog.wordpress.com/2015/01/04/creating-a-powershellget-repository/ It talks about Proget and using a Nuget feed type, but the same methodology applies using the Powershell feed type.

It's hard to say, there's also the possibility that it's a bug; please keep in mind the npm "protocol" is undocumented, and lot of odd quirks that vary from client version to version, so it's possible this particular package is constructed in a way that we didn't account for. In this situation, the best way to see what the problem is, use a tool like Fiddler or Wireshark, and see which specific query ProGet is responding differently to.

Can you provide more information on how to reproduce this? Ideally, if you could attach Fiddler or similar to capture the specific query that is causing the error, that will help us repro.

Thank you Alana, this makes sense. I was trying to use a NuGet feed type. This answers my question.

Sorry on the slow reply; this is extremely difficult to debug, because it involves a very complex set-up and expertise in undocumented LDAP/AD/NETBIOS conventions, as you might imagine… The problem is that the underlying libraries are returning that useless “server not available” error when trying to lookup the NETBIOS doman name. Here is how that query is constructed. private string GetNetbiosDomainName(string dnsDomainName) { string netbiosDomainName = string.Empty; DirectoryEntry rootDSE = new DirectoryEntry(string.Format("LDAP://{0}/RootDSE", dnsDomainName)); string configurationNamingContext = rootDSE.Properties["configurationNamingContext"][0].ToString(); DirectoryEntry searchRoot = new DirectoryEntry("LDAP://cn=Partitions," + configurationNamingContext); DirectorySearcher searcher = new DirectorySearcher(searchRoot); searcher.SearchScope = SearchScope.OneLevel; searcher.PropertiesToLoad.Add("netbiosname"); searcher.Filter = string.Format("(&(objectcategory=Crossref)(dnsRoot={0})(netBIOSName=*))", dnsDomainName); SearchResult result = searcher.FindOne(); if (result != null) { netbiosDomainName = result.Properties["netbiosname"][0].ToString(); } return netbiosDomainName; } Basically, it’s trying to enumerate all partitions and try to locate the netbiosname property. This is important to do because sometimes a credential will be sent to ProGet in a NETBIOSNAME\username or username@NETBIOSNAME format. The failure could be happening in one of two places (where the Properties collection is accessed), but shouldn’t be happening in either. Any assistance in identifying this would be helpful. We could just ignore this error, and assume that that a failed NETBIOSNAME resolution means the domain name is always the same, but we'd prefer not to just ignore errors like this...