Hello Clint, This SQL will copy any credentials that BuildMaster has but Otter doesn't to Otter. However, it will not work if BuildMaster and Otter use different encryption keys. You can find the encryption keys for BuildMaster and Otter in app_appSettings.config and in web_appSettings.config. The key will look like this in the file: <add key="Persistence.EncryptionKey" value="[encryption key is here]" /> INSERT INTO [Otter].[dbo].[Credentials] ([Environment_Id], [Credential_Name], [CredentialType_Name], [LegacyConfiguration_Bytes], [Configuration_Xml], [AllowFunctionAccess_Indicator]) -- Omit the line above this comment to test this before running it for real SELECT OE.[Environment_Id] ,BC.[Credential_Name] ,BC.[CredentialType_Name] ,[LegacyConfiguration_Bytes] = NULL ,[Configuration_Xml] = CAST(REPLACE( REPLACE( REPLACE( REPLACE( REPLACE( REPLACE( REPLACE( REPLACE( REPLACE( REPLACE( CAST(BC.[Configuration_Xml] AS VARCHAR(MAX)), '<Inedo.BuildMaster.Extensibility.Credentials.BuildMasterCredentials Assembly="BuildMasterCore">', '<Inedo.Otter.Extensions.Credentials.BuildMasterCredentials Assembly="OtterCore">' ), '<Inedo.BuildMaster.Extensibility.Credentials.OtterCredentials Assembly="BuildMasterCore">', '<Inedo.Otter.Extensions.Credentials.OtterCredentials Assembly="OtterCore">' ), '<Inedo.BuildMaster.Extensibility.Credentials.ProGetCredentials Assembly="BuildMasterCore">', '<Inedo.Otter.Extensions.Credentials.ProGetCredentials Assembly="OtterCore">' ), '<Inedo.BuildMaster.Extensibility.Credentials.PrivateKeyCredentials Assembly="BuildMasterCore">', '<Inedo.Otter.Extensions.Credentials.PrivateKeyCredentials Assembly="OtterCore">' ), '<Inedo.BuildMaster.Extensibility.Credentials.UsernamePasswordCredentials Assembly="BuildMasterCore">', '<Inedo.Otter.Extensions.Credentials.UsernamePasswordCredentials Assembly="OtterCore">' ), '</Inedo.BuildMaster.Extensibility.Credentials.BuildMasterCredentials>', '</Inedo.Otter.Extensions.Credentials.BuildMasterCredentials>' ), '</Inedo.BuildMaster.Extensibility.Credentials.OtterCredentials>', '</Inedo.Otter.Extensions.Credentials.OtterCredentials>' ), '</Inedo.BuildMaster.Extensibility.Credentials.ProGetCredentials>', '</Inedo.Otter.Extensions.Credentials.ProGetCredentials>' ), '</Inedo.BuildMaster.Extensibility.Credentials.PrivateKeyCredentials>', '</Inedo.Otter.Extensions.Credentials.PrivateKeyCredentials>' ), '</Inedo.BuildMaster.Extensibility.Credentials.UsernamePasswordCredentials>', '</Inedo.Otter.Extensions.Credentials.UsernamePasswordCredentials>' ) AS XML) ,BC.[AllowFunctionAccess_Indicator] FROM [BuildMaster].[dbo].[Credentials] BC LEFT OUTER JOIN [Otter].[dbo].[Credentials] OC ON BC.[Credential_Name] = OC.[Credential_Name] LEFT OUTER JOIN [BuildMaster].[dbo].[Environments] BE ON BC.[Environment_Id] = BE.[Environment_Id] LEFT OUTER JOIN [Otter].[dbo].[Environments] OE ON BE.[Environment_Name] = OE.[Environment_Name] WHERE OC.[Credential_Id] IS NULL

Ok, I see that my issue is exactly what is described in https://inedo.com/support/questions/7450. Thanks for the quick reply. I'll update to v5 when it comes out of beta.

Never mind, found the 5.0 beta :-)

I've logged PG-1192 as a change to sort alphabetically, with exception of latest.

If it's an "active" DR (i.e. the servers are running, it's used for testing purposes, etc) then each server would require a license. If it's something like, a snapshot of a server (and isn't running... but could be as soon as production goes off), then you can use the same license. It's similar to a lot of Microsoft (and other vendors) licenses for non-production environments.

This was caused by a connector that was returning a 500 server error. Inedo might want to look into better handling of these errors.

This is by design, and works fine for 95% or more of the use cases. The major benefit to in-process execution is performance; a new process/environment will often take longer to initialize the entire script to run, especially depending on the modules installed. This makes use of lots of small or inline scripts (like a $PSEval(...)) impractically slow. The downside to this is, is that a "bad" PowerShell script can leak memory and cause the overall agent process to balloon. Of course, process environment variables are also shared... but this is much less common, as it is considered an anti-pattern to ps development. However, many scripts are directly translated directly from Linux bash, so the pattern comes through. Anyways, we plan to solve this (and other shared-process problems) by allowing for agent process isolation. Basically, you will be able to do something like with isolation {...} and then all agents would spin up a new process to execute whatever is contained in the block.

There is nothing in particular on ProGet's side that would cause this to happen; you'll really need to explore package-by-package what's wrong. Check some of the other posts, and of course this documentation for how to debug this... https://inedo.com/support/documentation/proget/feed-types/nuget/symbol-and-source-server

There's just the two connection strings (web and service)... you shouldn't be getting timeouts, however. It might be network related?

OMG I totally overlooked that. Thanks!

I am one of the developers, which is why I can assure to you that ProGet is not issuing a 503. This is IIS. However, based on the new information you've provided, it's likely happening because of an abrupt Application Pool termination such as a access violation, stackoverflow, etc. In such a situation, it's not possible for ProGet to log anything; the program (AppPool) immediately crashes. Then IIS issues the 503 error. However, IIS should be logging these in the Windows Event log; so if you can look into what it is, then we can try to debug it further. This is an easy scenario for us to set-up, and it's a common error condition, but we cannot reproduce it.

This may be fixed by ILIB-19, which makes buffering of Docker layer uploads happen in a temporary file instead of in memory. It's very possible that SlimMemoryStream has a bug that only manifests when it has several gigabytes of data in it. microsoft/windowsservercore has a 7GB foreign layer, and I assume you're using the allow-nondistributable-artifacts option on the Docker daemon because you mentioned the system is not connected to the internet, so the next version of ProGet will stop that 7GB upload from being buffered in memory.

Thanks for the answer and bummer I didn't connect that dot when reviewing the upgrade procedures.

Hello Tristen, Are you using a custom package store, such as AWS or Azure, or are the files stored in the default (local filesystem) package store?

Yes. Just remove the "Anonymous" user from any tasks you've given it to permission to; Admin > Security > Tasks.

Thanks Alana. We double checked the PDB files that were being created, and only the .NET 4.5 version was a "full" PDB. After additional investigating we have found the issue. When working with a SDK style project in Visual Studio 2017, the UI does not accurately set the DebugType Full property in the project. For us it left a condition on the PropertyGroup which only applied the DebugType Full element to the net45 version of the assembly. After removing that condition, we are now getting full PDBs created for each version of the assembly.

Alana, thank you for the update. I guess we can consider this closed until such time as we know otherwise.

Hi, please see: https://inedo.com/support/kb/1072/proget-vs-nugetserver

ProGet does not distinguish requests based on http or https (that's a different layer), so there is an error somewhere else in the stack. Are there any relevant logs from PowerShellGet?