Hi @smiller-circ_2844 , Product activation is required. If you're unable to keep the same MachineID, then you'll need to get an activation code from my.inedo.com. While it's not officially supported and isn't documented, you could "listen" to the activation request that ProGet makes by using a proxy server like Fiddler, and make the same API request with your key. You would then need to add that value to the database. I don't want to give specific instructions on how to do this, because like I mentioned it's not officially supported -- but it's not "too difficult" to do, if you're familiar with the above. Cheers, Steve

I wait for the next official release. i have a workaround with disable the permission

Hi @atripp, Thanks that helped me solve it pretty quickly, just a typo somewhere in the script variables. Very happy to have learned about the verbose setting :-) Justin

@stevedennis This is amazing, what a great feature.

hi @cshipley_6136, We chatted a bit about this as a team today. We believe that the application failed during initialization (i.e. the first web request after starting the service); when this happens, the error message will be returned until you restart the application (container/service). This is by design; there's no way to guess where or why the initialization failed, and if we "crash" the application (and trigger a restart), it can end up in a endless loop and make diagnosing really difficult. In this case, the error is network related (server name not found). That error can be transient when you have network problems, or permanent if it's a typo in the connection string. Since restarting the application (container) fixed it, then it was a transient network issue that happened during initialization. Hope this helps, Steve

@OtterFanboy got it, thanks! So this particular change is a bit more involved unfortunately. For example, if you clicked on "Windows Server", you wouldn't find any drifted servers - which would be confusing, because the environment would show as drift. I'll note this as something to think about for v2023

Hello @OtterFanboy , Thanks for the bug report! We'll fix it via OT-483. That tab only displays if "Configuration drift:" is set to something other than "None", but there should be a "no roles" type of message instead of a crash. Cheers, Alana

Hello @OtterFanBoy123 , I was able to reproduce this; it's a UI regression BuildMaster 2022's new OtterScript editor. This won't impact deployment, the script, or anything like that. I've logged this as BM-3817 and we'll try to get this fixed in the next maintenance release :) Cheers, Alana

@lm thanks for letting us know that it worked! I'm glad you were able to find the issue on GitHub. Looking closer, it is a NuGet client bug; I posted an update on the issue. The only workaround is what you described (setting a separate API key).

It's odd because I haven't updated ProGet (or Ansible) since installing it, and it did work back 5 months ago. You're right, I'll likely need to modify the bootstrap_script if ProGet is not pulling the install.ps1 from the Chocolatey source upon request.

Hello Rich and Alana, thank you for your effort. I wrote my problem as a reminder to the open issue https://github.com/OneGet/oneget/issues/430. We will see what happens Kind regards, Rosario

Hi @Justinvolved , Hundreds of configuration files in one application -- definitely too much. I'd probably seek a different solution if that's the case. But having one or a few per application is okay. There is an Http-Post Operation that you can probably use to make API calls. Conceptually it's similar to the PowerShell Invoke-WebRequest method. I'm not sure what the configuration file would look like (array? map variable?), but there's also a variable function, ($Filecontents()), that could read a file, and an $Eval() function that can can convert text into variables. That said... it might be a bit challenging to do all this in OtterScript. It's not really designed for this. You may be better off writing a global PowerShell script that can process input from a configuration file that you deploy to the working directory. That would also be easier to test as well. Cheers, Alana

Hey Greg, Thanks, changing to C:\Temp solved the issue indeed, so I guess the path was too long. I'm experimenting with the Inedo Agent to make sure I can scale up and not have everything tied to Localhost, seems that was a good call given these subtle differences :-) Cheers, Justin

Thank you very much, it works as it should!

Hi Dan, thanks for the fast reply. It's a Windows 2012 Server. We gonna move Proget to some newer machine and see whats gonna happen. Thanks, Florian

Thanks for clarifying @Justinvolved I was able to reproduce this issue, looks like it was a regression with "releaseless builds". Easy fix... it'll be in the next maintenance release as BM-3808. The release is scheduled for this Friday :) Cheers

You're right, caching SourceLink enabled PDBs would be somewhat useless for outages. Though there are still plenty of "old-school" PDBs around, especially for native code (C/C++).

Thanks Alana!

Ok, thanks for the information.

Hi @lm , We've considered this over the years, but realized it'd be more engineering effort that just changing cookie duration; we'd want to track login sessions on the server side, allow them to be invalidated, etc. It's possible, but it seems the "Remember me" function on most services (GitLab, etc.) seems to be very forgetful anyways (for security purposes), and with Integrated Windows Authentication and browsers managing passwords, it seems not so valuable for the effort. Cheers, Steve