Hi @Justinvolved ,
Application Pools seem to run under a special user account (not NETWORK SERVICE, but like IIS\AppPoolName), so you need to give that user access.
In any case, make sure to restart the app pool/IIS, otherwise the permissions may not cascade? It can be a bit tricky unfortunately.
Cheers,
Alana
Hi @caterina ,
Thanks for sending this; looking over the SBOM, it looks like the scope is incorrectly encoded in the package.
<purl>pkg:npm/%40ampproject/remapping@2.2.1</purl><purl>pkg:npm/@ampproject/remapping@2.2.1</purl>Are you using pgscan to generate this? I think so, and in that case it seems to be a bug. We may wish to have ProGet also accept it, but I'm not sure.
FYI, here is a minimal SBOM that demonstrates the issue:
<?xml version="1.0" encoding="utf-8"?>
<bom serialNumber="urn:uuid:6109c18a7f7c403b9f9f11ff73c8fe34" version="1" xmlns="http://cyclonedx.org/schema/bom/1.2">
<metadata>
<timestamp>2024-01-17T08:23:58.4621303Z</timestamp>
<component type="application">
<name>Test</name>
<version>1.0.0</version>
</component>
</metadata>
<components>
<component type="library">
<name>@ampproject/remapping</name>
<version>2.2.1</version>
<purl>pkg:npm/@ampproject/remapping@2.2.1</purl>
</component>
</components>
</bom>
When npm/@ is replaced with npm/%40, the file is imported as expected.
Cheers,
Alana
In your command, you're specifying D:\ProGet as the target directory. The configuration files are written to %PROGRAMDATA%\Inedo\SharedConfig\.
Cheers,
Alana
Hi @andy222 ,
Based on the error/stack trace, it looks like you're getting a HTML page as a response instead of the expected JSON. I don't know what url is being queried, but it's clearly incorrect.
Looking at the OtterSCript, you shouldn't be specifying an ApiKey and EndpointUrl when also specifying a Source, since BuildMaster will automatically discover those from the source. I suspect this is where the issue is.
Try this instead:
ProGet::Download-Asset temp/TestEnvVariables_Win.zip
(
Source: directory::Assets,
To: C:\temp
);Hi @mike_5084 ,
Thanks for sharing this! Few things I wanted to share...
Retention Rules are definitely the way to do house keeping; it's much simpler and is something that just works in the background
We're definitely aware of this particular deletion issue, but it's tricky to reproduce (even using your scenario)... that said, we do have a patch for FeedPackageVersions_DeletePackageVersion available, but we're waiting for some other users to test it before releasing in the mainline. It sounds like you already deleted the packages, so it's not a big impact.
We introduced the Common Packages in ProGet 2023, and we will likely introduce a "Rate limit" of some kind in ProGet 2024 Free edition, since retention policies are one of the features that help "sell" ProGet to managers 
Cheers,
Adam
Thanks @caterina , confirming receipt! We will review this in the next week or so, please stay tuned.
@philippe-camelio_3885 that's a lot of namespaces! Sure, great idea, I logged it to BM-3922
I'm not sure if we can sort repository names however; those come in a "paged" UI, but we might :) At least you can search for those by typing.
Hi @andy222 ,
The workflow you describe -- TeamCity (CI) + BuildMaster (CD) -- is definitely supported.
However, artifacts are "pulled" (imported) from a TeamCity build. There are two patterns:
That being said, you can also create a TeamCity (CI) + ProGet (Package Repository) + BuildMaster (CD) workflow. This scenario is the closest to the "Octopus Deploy" workflow (i.e. TeamCity pushes a NuGet package), and a number of users will use this as a kind of "bridge" to migrate away from Octopus.
Cheers,
Alana
Hi @caterina ,
Can you share an SBOM that I can use to reproduce this? Doesn't need to be the whole one, just one that contains an example of a scoped package that you're not seeing.
Cheers,
Alana
@philippe-camelio_3885 thanks for the bug report!
we'll get fixed via OT-506 in an upcoming maintenance release :)
Hi @sbaeurle ,
I'm glad to issue is mostly resolved now!
In general, ProGet issues 500 errors when there are problems like database connections, overload, etc. We have not seen a 401 issued in a case like that. That's not to say it didn't happen to you, but that's not how ProGet will behave.
401/403 are only issued on API endpoints calls; if there's an error during authentication (like if you added an intentional bug to a procedure that checks the api key validity), then a 500 should be issued.
Cheers,
Alana
Hi @Justinvolved ,
This is a symptom that the web application lacks permission to control the service. There is an ancient tool called subinacl.exe that can fix this. We also have an ancient article based on that tool, but don't have anything updated:
https://inedo.com/support/kb/1090/granting-service-control-privileges
I did a quick search and found this content piece that also explains it
https://www.winhelponline.com/blog/view-edit-service-permissions-windows/?expand_article=1
Let us know what you find, we'd love to get that article updated :)
Cheers,
Alana
Hi @manager_7279 ,
This is likely because of a lack of database permissions; you'll need to grant permissions to the BuildMaster database in the local SQL Server database. We don't have a step-by-step guide for that, but it involves giving that user BuildMasterUser_Role permission using something like SQL Server Management Studio.
As an alternative, you can install the Inedo agent on the BuildMaster server (defaults to Local System) and then connect to that instead of localhost.
Cheers,
Alana
Hi @manager_7279 ,
Stopping/Starting IIS application pools requires administrative access. Looking at your stack trace, it seems like you're trying to stop an application pool on localhost (i.e. the server that BuildMaster is running on)?
That's not a common requirement; instead you'd stop/start an application on a different server.
In any case, the BuildMaster service runs under NETWORK SERVICE, and will not have permission to modify IIS application pools on localhost. So if you plan to do this (i.e. stop/start IIS on localhost), then you will need to make the BuildMaster server run under LOCAL SYSTEM instead of NETWORK SERVICE.
This will likely also require you to update database permissions, to allow LOCAL SYSTEM to connect to the database as well.
Alana
Sounds like a plan :)
Let us know if we can help , or if you run into any issues!
Hi @sbaeurle ,
That's definitely strange; there's really nothing in ProGet that would cause intermittent 403s.
If you aren't doing so already, I would suggest switching to using API Keys in ProGet instead of LDAP. Make sure they are not "Personal Keys" but Feed keys. That will eliminate any potential issue with LDAP queries returning inconsistent results.
Otherwise, you'd almost need to capture those bad requests and see how they're different. ProGet does not have a means of capturing HTTP traffic, so you'd have to use something like Fiddler or Wireshark.
Cheers,
Alana
@scampbell_8969 excellent, please stay tuned, we'll get back within a couple weeks
The easiest solution to this is to set the parent folder's as you'd desire. For example, if you're deploying everything to c:\Websites\<app_name> then just set c:\Websites to be [COMPUTER NAME]\Users .
You can also write a PowerShell script to change permissions, but that's more complex and I recommend just using the parent-folder
Thanks,
Alana
Hi @scampbell_8969 ,
The screenshot is not yet available, it's code that we're testing.
In the meantime, you need to navigate to the package in a ProGetfeed, then assign the license. It will add a special url like package:// that is used to associate the package with the license.
Can you email the files to support at inedo dot com, with the subject [QA-1368], then we can ffind it? Just let us know when you email the files
Hi @scampbell_8969,
It's hard to say without knowing which specific packages you're referring to, but there are several known issues with ProGet 2023's license detection. It is something we're currently redoing in ProGet 2024. We plan to get this new detection logic in ProGet 2023, at least as a preview feature, in the coming weeks
Here's a screenshot of working code:
I assume these are all publicly available packages. Can you share the SBOM files for your Releases? This will be extremely valuable for us to test with.
It's kinda hard to find packages with embedded licenses to be honest.
Thanks,
Alana
I think I understand your question; but just to make sure...
You have two servers with the inedo-runner role, and you're using the Acquire/Release operations like this:
Acquire-Server
(
Role: inedo-runner,
AcquiredServer => $AcquiredServer
);
###### code that uses $AcquiredServer some how #####
Release-Server
(
Role: inedo-runner,
Server: $AcquiredServer
);
However, you'd like the same server to be acquired more than once, so that you could run two or three simultaneous operations on inedo-runner servers, instead of just one?
I'm afraid that's not possible, and isn't something we plan to add to the roadmap any time soon. One option is to create a second role inedo-runner2, and then use that to Aquire servers half the time 
Cheers,
Alana
Hi @mike_5084 ,
Note that running ProGet as a server cluster will require a ProGet Enterprise license. So I think you may want to use Azure Container Services? That's usually what we see most ProGet Basic users use on Azure (aside from a VM).
Under the hood, Azure Kubernetes/Container Services uses Docker. We support ProGet running on Docker, and have some instructions which you've certainly seen:
https://docs.inedo.com/docs/installation-linux-docker-guide
However, we don't support Azure directly, as we're not familiar enough with Azure to advise what Azure-specific commands are required, how to troubleshot Azure-errors, what networking configuration is required on Azure, etc.
Contrast this with Windows, where we can typically advise on how to do nearly all Windows admin/troubleshooting things, from managing the Windows certificate store to changing service configuration using sc.exe, etc.
That being said, if you can "translate" our documentation to Azure, and are comfortable setting it all up, then you should be fine.
Alana
Hi @jw,
According to the comments in our code...
// kestrel will not do port sharing in .NET6 (despite what docs imply), so use http.sys
// Revisit in .NET8 - https://github.com/dotnet/aspnetcore/issues/39640
foreach (var u in urls)
{
var m = urlRegex.Match(u);
if (m.Success && m.Groups[1].Value is not "*" and not "localhost")
{
useHttpSys = true;
break;
}
}
This was something that was considered for .NET7, but clearly that never happened :)
The general suggestion is to use a reverse proxy to reuse the ports.
Cheers,
Alana
Thanks for reporting this; we'll get this fixed the next maintenance release (shipping this friday) via PG-2544
Alana
Hi @chowarth_6088 ,
Can you give some more details about the errors that you're receiving, and how to reproduce this?
Thanks,
Alana
Hi @Justinvolved ,
The biggest consideration for using "separate applications" is versioning and independent deployment. For example, our extensions are all separate applications, but nearly all of them are bundled with product release. For example, see the the the %ExtensionVersions variable on a recent build of BuildMaster.
The Git::Checkout-Code will default to $Commit and $Repository variable functions for the BranchOrCommit and From arguments; those variable functions contain the values that you selected when creating a build. So you can just specify different values as needed.
See: https://docs.inedo.com/docs/buildmaster-git-source-control#build-scripts-operations
Likewise, the Deploy-Artifact operation defaults to $ApplicationName, $BuildNumber, Default, etc, so you can specify values as needed.
But like all things in software, no matter what approach you use, it will probably end up being "wrong" and you'll want to redo it later. So just plan on doing a "v2" down the line :)
Alana
Hi @sbaeurle ,
That is strange; ProGet will issue a 403 when the request is unauthorized, meaning that authentication (name/password) was correct, but the user/key doesn't have permission. That isn't really an error that would happen intermittently on the ProGet side.
It's possible that ProGet isn't issuing a 403 error. Is there some kind of authentication in front of ProGet, on the azure side? ProGet does not log these requests, so your best bet may be to monitor traffic and see if you identify what is issuing the 403.
Best,
Alana
Hi @devadmins_4004,
I haven't tried to reproduce this yet, but I looked the code briefly and am not sure why it wouldn't work. Is this ProGet 2023?
What is the specific response? Response code + body if possible.
I wonder if you could try to use the username of api and the password of your api key?
Thanks,
Alana
Hi @cshipley_6136 ,
We recommend using the /health monitoring endpoint. As you can see, it makes a connection to the database by calling that stored procedure.
We do not recommend calling other URLs; and there is no reason another page would work. Calling other pages will impact performance and likely yield incorrect results.
You're right, it might have to do with a "connection pool" problem -- but that's all managed at the driver level. You can control connection pool settings by changing connection string values, but to be honest we have no idea what the impact will be.
Your best bet is to open a case with Microsoft, who has the expertise to know how to troubleshoot these intermittent "error 40's". They may have specialized tools or "secret debugging commands" you can use.
This is all happening at the operating-system or driver-level, and while we're doing our absolute best to help you troubleshoot, but we have never seen this happen before and our main resource is searching google. And this is not an easy error to search for,..as you've probably noticed.
Please keep us in the loop.
Best,
Alana
Thanks @cshipley_6136 ; they're both the same "error 40" - which is a hostname/dns issue.
I doubt its a bug in the SQL Server driver (but it could be)... the most likely culprit is some kind of networking/configuration issues.
I would try to identify what's happening around that timestamp, network changes, etc. This is where our expertise in troubleshooting is not so strong. It's a really easy error to reproduce (just enter a wrong host name in the connection string, disable dns, unplug a network cable, etc), but tracing the underlying cause requires lots of poking around on the network.
Hi @cshipley_6136 ,
Unfortunately we're really at a loss for how to troubleshoot the SQL Server further, and it's happening at the driver level. I'm not trying to "pass the buck" here, but it's most definitely NOT a ProGet issue (as in, code that we wrote and have control over).
This must be happening at a lower-level (like the sql server driver, dns resolution, kubernetes, front-end caching, etc).
Most likely, the / vs /health is related to caching an error, or some "deep internal" behavior of the SQL server driver (or bug on Linux?) that we're not aware of.
From here, it's going to make sense to bring in Microsoft, who will know how to troubleshoot/diagnose this further. The "TCP Provider, error: 40" is so generic, and means the same thing as Chrome's "name not resolved". Aside from the obvious, we have no idea what could cause such an error, nor do we know how to troubleshoot.
They may have some "secret flags" in the connection string that you can enable, etc.
I tried to search for help, but there are like one thousand results that are all over the place, from clearing DNS caching to rebooting, etc.
On our end, our code doesn't deal with any of these things... we just use the driver to invoke SQL Server commands. Here is the entirety of the /health code:
private static readonly LazyCached<IList<Feed>> feeds = new(() => DB.Feeds_GetFeeds(false).Select(f => Feed.GetFeed(f)).ToList());
protected override async Task ProcessRequestAsync(AhHttpContext context)
{
context.Response.ContentType = "application/json";
using var writer = new JsonTextWriter(new StreamWriter(context.Response.OutputStream, InedoLib.UTF8Encoding)) { Formatting = Formatting.Indented };
// added for specific customer and not documented (EDO-9257)
if (string.Equals(context.Request.QueryString["dbcache"], "false", StringComparison.InvariantCultureIgnoreCase))
feeds.Invalidate();
writer.WriteStartObject();
writer.WritePropertyName("applicationName");
writer.WriteValue("ProGet");
try
{
var _ = feeds.Value;
writer.WritePropertyName("databaseStatus");
writer.WriteValue("OK");
writer.WritePropertyName("databaseStatusDetails");
writer.WriteNull();
}
catch (Exception ex)
{
writer.WritePropertyName("databaseStatus");
writer.WriteValue("Error");
writer.WritePropertyName("databaseStatusDetails");
writer.WriteValue(ex.Message);
}
writer.WritePropertyName("extensionsInstalled");
writer.WriteStartObject();
foreach (var e in ExtensionsManager.GetExtensions())
{
writer.WritePropertyName(e.Name);
writer.WriteValue(e.Version.ToString());
}
writer.WriteEndObject();
var license = LicensingInformation.Current;
writer.WritePropertyName("licenseStatus");
if (!license.IsValid)
{
writer.WriteValue("Error");
writer.WritePropertyName("licenseStatusDetail");
writer.WriteValue(license.LicenseKeyStatusDescription);
}
else
{
writer.WriteValue("OK");
writer.WritePropertyName("licenseStatusDetail");
writer.WriteNull();
}
writer.WritePropertyName("versionNumber");
writer.WriteValue(versionNumber.Value);
writer.WritePropertyName("releaseNumber");
writer.WriteValue(releaseNumber.Value);
var serviceStatus = await ProGetServiceMessenger.GetStatusAsync();
writer.WritePropertyName("serviceStatus");
writer.WriteValue(serviceStatus.Status == ExtendedServiceStatus.Running ? "OK" : "Error");
writer.WritePropertyName("serviceStatusDetail");
writer.WriteValue(serviceStatus.Status != ExtendedServiceStatus.Running ? serviceStatus.ErrorText : null);
var r = replicationStatus.Value;
writer.WritePropertyName("replicationStatus");
if (r != null)
{
writer.WriteRawValue(JsonConvert.SerializeObject(r, Formatting.Indented));
}
else
{
writer.WriteNull();
}
writer.WriteEndObject();
}
To "translate" what's happening, the stored procedure Feeds_GetFeeds is invoked to test database connectivity. It's invoked following all of Microsoft's guidance for using the SQL Server driver.
An "Invalid credentials specified" basically translates to "invalid username/password". In this case, it doesn't matter that the user has permissions or not (authorization) -- they simply can't login (authentication).
I would try this without chocolatey; you can simply visit the API urls in an "incognito" browser directly, and enter the username/password prompts from the browser. This should be a browser-prompt, and not the ProGet log-in page.
Once you can access the API urls, that will give you an idea of whether the LDAP is workikng or not.
Cheers,
Alana
First, note that ProGet 2023 requires a data migration, and if that failed then you will likely have a lot of other issues: https://docs.inedo.com/docs/proget-upgrade-2023
I don't have enough info with the errors reported to know where the problems are, but I'll share some general information.
ProGet 2022+ also uses a new platform (.NET6 vs .NET4); in general .NET6 performs better/faster, but .NET4 seems to handle "underpowered" hardware better. You can mimic the behavior of .NET4 by setting the Web.ConcurrentRequestLimit to between 200 to 500.
The "package not found" is a separate error, but may be related to a migration. It's hard to say, but it's easy to troubleshoot. You should be able to navigate to the package (string-width 4.2.3) and download it from the UI. If you get a file not found error, then investigate where that file is.
Cheers,
Alana
If you're using Windows Integrated Authentication, then all requests will be already authenticated against the domain before reaching ProGet. So in this context, "Anonymous" really means "all domain users".
If you want to restrict only certain domain users, then you should create an active directory group. I believe the group "Domain Computers" is a special group (i.e. not a security group), and it's not returned in ordinary LDAP queries that ProGet makes.
Best,
Alana
Hi @paul_6112 ,
That's really peculiar; what must be happening is that PowerShell is returning multiple results, so the variable is automatically being being created as a list:
https://github.com/Inedo/inedox-scripting/blob/master/Scripting/InedoExtension/Functions/PsEvalVariableFunction.cs#L52
Digging further, it's like related to some issue with value detection/conversion:
https://github.com/Inedo/inedox-scripting/blob/master/Scripting/InedoExtension/PowerShell/PSUtil.cs#L205
Unfortunately it's a bit of rabbit hole from here; it's just as likely a bug in .NET6 powershell libraries as it is our code. But hopefully you can play around and find a work around? I'm at a loss, and we're pretty heads-down in ProGet 2024 planning at the moment, so hard to find the likely half-a-day to explore this further.
I'll add this to our BuildMaster 2024 roadmap, but if anyone else experiences this (or we get a ticket) we'll investigate it further.
Cheers,
Alana
Hi @paul_6112,
I'm not able to reproduce this; I tried something similar, a script that looks just like this:
Set-BuildVariable MyVar
(
Value: $PSEval("(Get-TimeZone).Id")
);
There's a lot of moving parts in the case you gave, so best to use something simpler to try to repro. Like Get-TimeZone. It'd be good if you "play around" and figure out what specifically is causing the behavior.
Cheers,
Alana
If you upgrade to ProGet Basic edition, you will no longer have those warnings.
One of the License Restrictions is how you've configured your connectors in ProGet (free edition cannot connect to ProGet) feeds, so that's what's triggering the warning.
Thanks,
Alana
Note that replied to the ticket you submitted (EDO-9822), but I'll provide a partial reply ...
I can't find a paid license key associated with ProGet for your company
All I can see is a free license and a really old license -- however support was never renewed so it's not eligible for free upgrades to ProGet 2023. If you're using that, you'll need to purchase a license.
Happy to help with that of course!
Thanks,
Alana
Hi @paul_6112 ,
How can I justify to the security teams that I am running unsupported software version
Well.... technically none of your software is supported since you are a free user 
But otherwise you can either upgrade the agents or link them to this post where an Inedo engineer advised it's fine in your scenario. Or if you can suggest a way to clarify the docs... we recently reformatted that download page and split into "supported" and "unsupported".
So I can actually test that the automatic upgrade does work, which version of the Agent should be installed to prove it would take place ?
Without digging in the code I'm not sure, but I'm pretty sure this functionality was disabled in BuildMaster 7 - the sentence mentioning it in the docs was obviously not removed. Instead, you will likely get some kind of warning on older versions.
The failure rate was relatively low (~0.1% or so), but it's high enough that it's not worth risk for customers.
Thanks,
Alana
Hi @paul_6112 , we could definitely be more consistent here.
The listing is generally called "Deployments & Executions" , which we shorten to "Deploys".
I'll make a note in our roadmap to review this!
Hi @paul_6112 ,
It sounds like there is some kind of proxy issue. We will investigate this via the other ticket.
We don't plan on removing Inedo Samples... just the "Application Templates" feature, which basically allowed users to maintain a gallery of your own templates or samples.
Cheers,
Alana
Hi @paul_6112,
There are no issues w/ using v49 or v50 in newer versions of BuildMaster; the bug is just with older (but still supported) versions of BuildMaster.
The "critical bug" is that an improperly-formatted encryption key in the agent's configuration file will cause the agent to not crash, but instead fallback to unencrypted mode. Newer versions of BuildMaster will detect this configuration problem. v46 does not have this bug.
Cheers,
Alana
Hi @paul_6112 thanks for the report -- this is a known issue/regression in our internal UI library with focus- it only impacts a very few number of pages, but it's on our list to eventually address
Hi @paul_6112,
Thanks for the report; looks like this is a regression that can happen after upgrade; to work around this
Templates and API Endpoint Url of https://proget.inedo.com/upack/BuildMasterTemplates/You can use a different URL if you have a ProGet universal feed of course.
This will be fixed in next maintenance release via BM-3908.
This should solve the issue. And as an FYI, application templates are now deprecated in favor of "cloning" a "template" application.
Hi @paul_6112 ,
I just updated the documentation to clarify our Inedo Agent Upgrade guidance:
You shouldn't upgrade unless you are directed by a version of your Inedo tool (Otter, BuildMaster, etc) or an Inedo support engineer.
In this case, you wouldn't be prompted to upgrade if you're using v46 or v49, so we really don't suggest upgrading. There's zero benefit and a nonzero cost (time to upgrade, risk of problems, etc).
Keep in mind that the Inedo Agent is really just a lightweight "agent host", and the "actual agent" is upgraded transparently all the time.
Cheers,
Alana
Hi @paul_6112
In that case, you may want to try restarting the service? It's possible the proxy change didn't get reflected...
Thanks,
Alana
Hi @paul_6112,
It definitely looks like the proxy settings need to be configured/changed. You can configure and test the Proxy settings under Admin > Proxy. That page also has a "Test" button that you can try different URLs.
With a Proxy configured and allowing;
my.indeo.com
proget.indeo.com
Now this is probably a typo on the forums, but just in case not... inedo.com not indeo.com
Hope that helps,
Alana
Hi @neo ,
If you haven't seen it already, here is our guide for migrating a ProGet instance:
https://docs.inedo.com/docs/migrate-a-proget-installation-to-a-new-server
That generalizes our advice as much as possible. And since you're using such an an older version of ProGet, you should also upgrade this as well.
Note that our professional services team can usually handle this for you for a very low cost; the service isn't listed on the page, but we offer it via the support channel.
Flat/fixed cost of $995. Eligible to ProGet users through Dec 31, 2023. Our professional services team will help every step of the way. Often, a migration/upgrade involve a lot of steps and back-and-forth, including:
If that's of interest, please fill out the form on this page (select "Other services not listed"):
https://inedo.com/professional-services
Cheers,
Alana
@Srinidhi-Patwari_0272 here is some information about HTTPS support on Windows:
https://docs.inedo.com/docs/installation-windows-https-support
However.... as Dean mentioned, this is something you'll need to work with your network team (a domain administrator) on, as the cert needs to be trusted, etc.
I'm not totally sure I understand, but when you do a silent install you need to specify a connection string.
So you would just specify the connection string you need like this I guess
hub.exe install ProGet:5.2.3 --ConnectionString="Data Source=externals,qlserver.corp.local; Databse=ProGet;Integrated Security=True;"