First and foremost, an InedoAgent will respond to any request with the proper AES encryption token (like a password), so if you don't want BuildMaster talking to a server/agent, then don't configure a valid connection to that agent. Are you connecting your Standbox server to the same SQL SErver database? This is a big problem, don't do it... ** Never have two instances of buildMaster talk to the same database ** Are you restoring a database back up to sandbox? It's strongly not recommended, because of the problem you describe. The agents will be configured to talk to eachother. Instead,, when setting up a sandbox, create a representative and testable version of your applications and processes. /you'll never be able to get a "perfect test" (since you can't talk to exact same servers), so at best you should test the broad functionality instead of the connectivity.

The Execute SQL Operation will only capture output specitically printed to the host. To capture the output of select statements, you might want to use a tool like "isql.exe" instead, that prints the results of a select statement to the console.

Manage Pipelines cannot be scoped to an environment, because pipelines are not associated with an environment. They deploy to a series of environments. you can restrict deployment to environments. You can restrict editing of configuration file instances to a particular environment, and as long as that configuration file is associated with an environment.

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.

OMG I totally overlooked that. Thanks!

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

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

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

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

I believe there was a fix for this (issue: BM-2392 - FIX: Variable bulk edit for releases and release packages checks for Admin_ConfigureBuildMaster task instead of Releases_Manage) in v5.6.9

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

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.

Outstanding, thanks Alana

It's certainly possible, many of these are already built-in Operations in BuildMaster.

This was broken due to IIS authentication issue.

It's really hard to say; if the built-in testing functionality within the user directory screens aren't providing any useful information, then you'll need to run the same code that BuildMAster does to try to isolate/trap further errors. https://github.com/Inedo/inedox-inedocore/blob/master/InedoCore/Common.BuildMasterOtterProGet/UserDirectories/ADUserDirectory.cs This is the user directory code; it's quite simple, and is using Microsoft's LDAP libraries.

Sorry, but I can't complete Create Account form because I have registered one sometime ago for this email.

Can you share a screenshot of your retention policy, and show you what you expect to be deleted? It might be easiest to submit a ticket for this.

Copying John's answer from StackOverflow: Maps are specified as %(key: value), here is an example plan that should help: set %map = %(Web.config: @("Web.Beta.config", "Web.Release.config")); foreach $key in @MapKeys(%map) { set @values = %map[$key]; Log-Information `$key = $key; Log-Information `@values = $Join(", ", @values); } Sleep 3;