Hi @gdivis, I've just installed v7.0.14 and the behaviour seems improved. On the original thread track; Using hub v1.3.7 the upgrade from v7.0.13 to v7.0.14 went through without getting stuck. After upgrade, both Test and Production web pages were able to load in less than 2 minutes. There is CPU spiking; but seems more spread out and the max memory is now two thirds of what it was; however within 6 minutes of startup its back around the 160MB - 350MB (it was idling at 160MB before upgrade) which is a definite improvement. Thanks, Paul

Hi @rhessinger, Thanks for the fix in 7.0.14 Loving your work once again !! [image: 1637601792944-a5e9bb54-bdf1-41ac-b4a9-c4e29e00c4b3-image.png] Regards, Paul

Hi Rich, Just installed 7.0.14; thanks for the fix Regards, Paul

Hi @jev_1362, The file should be saved on the server in the storage path. Can you check and see if that file exists locally on the server? You can find the storage path for your asset directory by navigateing to Assets and then clicking the pencil to the right of the asset directory. Then click the Storage & Retention tab and you will see your storage path there. Also, do you see any errors int eh diagnostics center when you try to download that file? Thanks, Dan

Hi @lukel_3991, I think we have two different issues that are happening here. The first one it seems to not be synchronizing over the extensions. What version of PowerShell do you have installed on your remote server and the otter server? The PowerShell based agent-less servers connect using PSRemoting over WSMAN. Could you please try to connect to your remote server using Enter-PSSession in PowerShell on your Otter server and try to run some commands to make a temp folder and write a file to it using the same credentials Otter users to connect to that server? It almost feels like there may be a permissions issue. The other issue seems like their could an issue with your OtterScript itself. Would you be able to share the OtterScript you are trying to run? Thanks, Dan

Hi @tcddpmonqxvfmiuyla_2318, No problem, thanks for updating with what you found the problem to be. Thanks, Dan

Hi @forcenet_4316, Thanks for bringing this to our attention. I'm not sure how this slipped through, but I made sure it is fixed in the next release, ProGet 6.0.3. The final fix is tracked via PG-2043. Thanks, Rich

Hi @r-riedinger_1931 , That error indicates that the database code (Stored Proc) didn't get updated, or is somehow out of sync with the installed version. Is it possible that you're pointing to an older database? You may want to run the installer again, just to make sure. Dean

Hi @shiv03_9800 , thanks for the detailed report on these! We've identified these as OT-440 and OT-441, and they will be fixed in the next Otter maintenance release (3.0.14), scheduled for tomorrow. Cheers, Steve

Thank you for your fast response. Just updated to 6.0.2-ci-3 and it is fixed

@harald-somnes-hanssen_2204 unfortunately not; a feed index provides details about only the latest version of a package. You need a separate query to find details about all versions of a package, and then would need to do that query for each package in an index Instead, it's better to just have a feed of approved packages that developers could use. This will let you also filter for other problems like quality. We recently published some advice about, but it's for nuget feeds. https://blog.inedo.com/nuget/package-approval-workflow It would work the same way for npm though

@Stephen-Schaff We're also considering locking down nuget.org, so the more info we have in ProGet, the better.

@Dan_Woolf, Thanks. This will help me a lot.

Thanks Nanci for your response. I exactly don't know how variables are being passed from one step to the other in same block of code to the other. Otter script documentation is not so clear on it. I have created separate thread fore that. If you can answer that. Setting Runtime Variable From Powershell Script Thanks

@gdivis Thank you very much (it works).

Hello, This is unfortunately due to bugs in the PowerShellGet & PowerShell Gallery API that aren't feasible to workaround. Basically, the API is reporting different versions than the package file, which makes working with local/cached packages and remote packages painful like this. However, it seems like it's going to be addressed by Microsoft, finally, in PowerShellget v3. In any case, given your architecture (i.e. "Machines on our network cannot connect to PSGallery direct due to the firewall and are only allowed to retrieve via this one feed."), we recommend using a Package Approval Workflow instead. create an 'unapproved-powershell' and approved-powershell feed create a connector on 'unapproved-powershell' to PSGallery.org Promote packages from unapproved-powershell to approved-powershell This will totally eliminate the "bad API" problem as well. Cheers, Alana

Hello Alana, Yes my first guess was also application Pool shutdown and wakeup. Thats not the problem as the website will stay slow all the time. Also its reproducable that two browsers on the same machine work with completly different speed. I will provide logs of the page you mentioned when i run in that problem again. Clearing cache did reproducable solve the problem. Of course the first call might take a second longer, but after that it works fine. Best Regards Dario

@forcenet_4316 great, sounds good! Actually we didn't end up shipping 6.0.0 yet (we will soon), so I just changed PG-2011 to target 5.3.40, which is scheduled for release on Friday. This way it will be in both.

Thanks @drew-stinnett_4680 ! I've updated the documentation with a link to this discussion.