We are only aware of that message occurring in the two cases I mentioned, and haven't had reports of the contrary. From here, please use a tool like Fiddler or Wireshark to identify the exact request/response patterns that are happening. You can see the authentication headers sent, and it's possible there's a typo or something in a name or password.

We take problems very seriously, but we need to prioritize where to spend engineering resources tracking down problems. This was a edge case that we could not reproduce, and had a very minor impact, and only affected a very small number of free users with a very specific configuration; a free user was able to track down the underlying cause and we fixed it.

Hi,

the script who is stored in a global module

##AH:UseTextMode
module ParseURL<out $JsonFile>

{

set $URL = $DEPLOYABLE_URL;

set $PATH = $DEPLOYABLE_PATH;

set @MYLIST = @();

Log-Debug Split URL /;

foreach $DATA in @Split($URL,"/")
{
    # Log-Debug $Data;
    set $DATA = $Trim($DATA);

    if $DATA != ""
    {
        set @MYLIST = @ListInsert(@MYLIST, $DATA);
    }
}

......

Sometimes, it works, but the major part of the time I have the error resumed above.
I found nothing in the diagnostic center et nothing in the event viewer of the widows server.

Does exist other logs somewhere ?

Kind Regards

You can reset the Admin user account password by stopping the ProGet Windows service, then running ProGet.Service.exe and selecting the "ResetAdminPassword" option. Make sure to restart the Windows service when finished.

Can you give us a little more context? Like, what is your OtterScript overall?

One possibility is that the INedoCore extension had a load error, though I suspect you'd have another problem if that were the case.

Hello,

I've added an ExitCode output parameter to the SHCall operation.

You can download a preview build of the extension from here: https://ci.appveyor.com/project/Inedo/inedox-linux/build/1.0.3-CI.7/artifacts

Currently assets do not have any user-definable metadata like this, I guess because that would make them a lot like packages? Assets also aren't intended to be like a "SharePoint replacement", which is why we don't want to put a lot of extra features like versioning, etc. These are also hard to replicate, etc.

That being said, we are open to changes, so please consider using the Feature Request Process. Note that, we also want to evaluate "why" and "how this would be used", and that's part of the feature/change process.

Thanks.

FYI: Retention policies should be ignored on free versions. But UNKNOWN does indicate the service user; so it's likely a retention policy job (which is run as part of feed cleanup).

You can see the logs of those, and maybe see some more info...

There is a task attribute called "Delete Package". Just make sure you have a Task that has that attribute. You can see more info about it here:

https://inedo.com/support/documentation/proget/administration/security/creating-tasks

ProGet most definitely does not "lose package" on an upgrade, so there must have been some sort of configuration change, either in the ProGet software (retention policy, package store), or external to the software (files deleted from disk).

It's highly unlikely that this configuration changed as part of the upgrade, particularly from those versions. Most likely, your database backups just happened to be dated from before the upgrade because the installer will auto-backup for you; so, the upgrade is really a red herring. You can search ProGet's audit logs to see if anyone in the software deleted them.

But regardless, if the package files are gone, and you don't have them backed up (the installer will not do this for you), then they are gone. There's nothing you can do, so I think your idea of searching for fragments from user caches, and then uploading those, is the best you can do.

NOTE: Unless you explicitly configured a retention policy for ProGet to delete files, the software will not delete these files on disk. Even when you delete a feed or uninstall the software, the package files remain. We do this for safety purposes.

Please make sure to read our backup and restore instructions.

Definitely not, they are on the low-end of the medium size... and just to be clear you shouldn't be calling dbo.Dashboards_GetDashboardInfo with more than 10 packages. It's only designed/tested for 0, 1, and 10.

Based on the table sizes and distribution, there's no reason it should be performing so slowly. Actually it works fast even on instances with 100x the packages that you have.

Maybe there's something else with your data that we can't see based on the tables you sent us. You should be able to view/edit the code of the procedure and underlying database views; perhaps you can find something by investigating the queries and data relationships?

Without seeing your log, I really don't know. But in this case...

WARN : 2018-02-21 22:37:21Z - ID: 107;	Name: BUILD-SOURCE;	Scope: Release

We have a legacy release template variable called "BULID-SOURCE". This will only show up in an application's settings page, it will not show up under global.

So how can we find the application? well, if I run this query, SELECT Scoped_Application_Id FROM VariableDeclarations WHERE VariableDeclaration_Id=107 I can find the application id. From there, I can enter it in the navigation bar, and find the variables.

Yes. But hmm ... maybe it's a disabled application? You should be able to find those in the VariableDeclarations table; those IDs refer to those.

These Legacy Template Variables (Release, Build, Execution, Promotion) are defined at the application-level, not at the system-level.

If you View Full Log, you should be able to find a block that looks something like this:

WARN : 2018-02-21 22:37:21Z - Legacy template variable declarations found:
WARN : 2018-02-21 22:37:21Z - ID: 107;	Name: BUILD-SOURCE;	Scope: Release
WARN : 2018-02-21 22:37:21Z - ID: 92;	Name: BUILD-SOURCE;	Scope: Release
WARN : 2018-02-21 22:37:21Z - ID: 108;	Name: BUILD-SOURCE;	Scope: Release
WARN : 2018-02-21 22:37:21Z - ID: 109;	Name: BUILD-SOURCE;	Scope: Release
WARN : 2018-02-21 22:37:21Z - ID: 111;	Name: BUILD-SOURCE;	Scope: Release
WARN : 2018-02-21 22:37:21Z - ID: 112;	Name: BUILD-SOURCE;	Scope: Release
WARN : 2018-02-21 22:37:21Z - ID: 113;	Name: BUILD-SOURCE;	Scope: Release

If that's not enough information to locate, you can look directly in the SQL Server Database to find out.

I'm afraid I don't really understand the requirements for what you're trying to accomplish...

Here are the differences between the two extensibility points:

• A Package Filter allows all locally-stored ProGet packages to be filtered from being shown in feeds by additional logic.
• A Package Access Rule Allows for rules to block downloads of packages based on additional logic.

The Package Access Rule is used by the Whitesource extension, so you can reference how that works. We don't have any publicly available uses of Package Filters; it was incorporated for a very specific usecase with publicly-available feeds.

I'm sorry, I accidently replied to here instead of this post. Please disregard it; the issue has nothign to do with your license.

I don't have an answer to your question, but another engineer will help soon. Note that if you have a paid license you can use a support ticket.

But someone will respond to this soon!

Yes, it just involves changing the license key.

Please refer to License Key Management

I'm afraid we don't have a guide on Azure-hosted AD at the moment, but from talking with other customers, they said they used the Advanced Configuration documented here https://inedo.com/support/documentation/various/ldap/ldap-active-directory

Single sign-on is unscheduled so I don't have a timeline, but it seems quite soon from what 've heard... 2019/Q1 or even Q4.

ProGet already supports Azure-hosted AD Authentication; if you're looking for Federated Authentication (single-sign on), that support is coming across all of our products.