There is no erros in that log.

You can just use the license key on the new server.

For completeness: An alternate approach is to create a private source server and update to both the source server and to the Universal Feed from out in-house deployment tool. But we were hope that we could have pig-backed on what you already had. Oh well. Thanks.

Verified - the problem is resolved after upgrade to 4.6.1. Thanks!

https://github.com/PowerShell/PowerShellGet/issues/76

The problem is the CpuResetInterval parameter; it is missing the attribute to identify minutes, so it is treating it as seconds. I fixed this here, and it will be fixed in the next release of the extensionhttps://github.com/Inedo/inedox-windows/issues/10 AS a work-around, you can just specify the value in seconds (300 instead of 5). But this will become 300 minutes after you upgrade, so might be best to not set it for now.

An "Access to the path is denied" message is coming from Windows. Permissions aside, a likely culprit is anotherr process (anti virus, backup, etc) is locking the file and preventing access. Sometimes you'll need to use ProcMon to identify what this is. ProGet does not requests locks when reading files.

thanks for the report; the label should say "top-level items", not "everything".

I see; have you've tried putting in your npmjs username and password in the connector? If that doesn't work, then it's not a supported scenario.

Thanks!!!!!! That will help a lot.

We'll add that as a proposed feature. I think the only issue aside from a small query/performance issue in implementation is that dependencies can change for different versions, so we'd really just be showing the latest version's dependencies there. Still, we are already doing that with certain fields like description, so that's not too bad...

The only thing that will yield this message -- The process cannot access the file '...' because it is being used by another process. -- is another process having a lock on that file. Windows does not provide information about which process that is. So, you'll need to use a tool like procmon to see file handles, and identify the culprit.

Thanks for the additional feedback! Do keep in mind that this was simply one possible work-around for a bug in the NuGet client that they fixed more than a year ago. Also do note that, when you grant a user Feeds_AddPackage to a user, they only have access to do that task. Which in this case, is very minimal. They do not become ProGet administrators, etc. In Windows, you can actually configure all users to be "Domain Administrators" (or have "root" open in Linux). We offer the same flexibility in ProGet, and you can configure ProGet to be as secure or open as needed. This is actually a very common feature in software/vendor products and, like most software vendors, we empower users to decide how secure or open to make their instance based on their specific needs and requirements. Unfortunately we can't offer specific advice to everyone on our forums on how to decide which policies suit them, but we do have some training and certification courses which offer lots of security topics (including awareness of the "security hole" you described, as well as lots of other potential attack vectors). You seem to be quite passionate about organizational security (i.e. InfoSec), which is awesome! There's a ton of great sources out there, but I would highly recommend you follow Krebs on Security and Schneier on Security. Those are some great starting points which you can use to starting learning how to develop best practices in your own organization :)

Thanks. That was the problem. After updating the Windows extension from 5.5.0 to 5.6.0 the powershell command is working again.

The admin tool does not currently add the user back; but you can do so directly in the database; the tables are fairly straightforward. To reinstall, make sure to drop the database after install well. It does not get removed by default.

It's still on our roadmap, but it was pushed back to 4.7.

SOLVED Human error on my part. Thought it best to state this so that others don't waste anytime on the thread.

This is a "false positive". See KB#1113: Anti-malware False Positives, Code Signing, and Safety of Inedo Products for more information. Please Report the False Positive! Please let your malware protection provider know about the false positive; the more people who do, the greater the chance they won't flag these in the future