@Dan_Woolf Sounds good, thanks for the response.

Hi @arozanski_1087, Technically they do not need to run as the same account, but it does simplify things. Especially since they share the configuration file that contains the connection string. Also, please make sure that your IIS has the correct features installed. You can see the Configuring IIS Roles & Features for Inedo Products documentation for that information. Were you using that exact service account previously on the integrated web server install? If you were there shouldn't be any iossue connecting from IIS then. Thanks, Rich

Hi Alana, Thanks for the information. I've reinstalled ProGet and IIS several times and at attempt four it suddenly worked fine. So I'm not touching the setup anymore and will keep it as-is now! Thanks, Eelko

Make sure to set the Web.BaseUrl setting in Admin > Advanced Settings as well.

Thanks Alana, once I installed the certificate into my 'Trusted Root Certification Authorities' and restarted the docker daemon on my client machine, things are working nicely. Thanks again for your help!

This seems to be related to a specific package that you have in your repository. Most likely it's bad/invalid metadata, and the specifics were not anticipated and thus it's crashing trying to read it. Unfortunately we would need to know a bit more about that package, and why it's causing this problem.

Assuming you don't any server misconfiguration or SQL Server latency issues, then the biggest performance bottleneck tends to be the network. Each client/user will make dozens or hundreds of simultaneous requests, often using machines more powerful than the server, and these requests can be expensive... particularly if you're using connectors... because they have to be forwarded to another server. These requests "pile up" and eventually, the underlying infrastructure can't handle it (IIS, network card, etc), and you start getting timeouts like that. This is where load-balancing comes in, and is pretty important in your configuration as you add users and packages. See How to Prevent Server Overload in ProGet to learn more.

Issue solved. wrong role was applied, target server has no IIS feature installed.

Well maybe it could be useful to at least integrate into the configuration of the application. This would be a good option if you'd choose that you don't want it to be found in online search results.

Noticed this is already reported https://inedo.com/support/questions/8463

Integrated Mode is correct for newer versions of our products - sometime between now and then it changed from classic to integrated. I'll put in a note to fix that in the docs.

Hi Travis, thank you for the additional update. I was very confused by this as well... the problem is the documentation that says if "LDAP" is enabled... it should say "if Integrated Authentication is enabled then the API key is ignored". When those docs were written, those 2 were 1 in the same. I guess the whole point of this is to never use a feed "NuGet API key" since it duplicates what the "ProGet API keys" already do in terms of authentication.

Hi Megha, Ensure application dont have selection of appPool right now, may be you can try create a powershell like below might solve your problem for time being. param( [parameter(mandatory=$true)] $iisAppPoolName, [parameter(mandatory=$true)] $iisAppName ) Import-Module WebAdministration #gets the iis application name $iisApp = get-item 'IIS:\Sites\Default Web Site' if((Test-Path ("IIS:\AppPools" + $iisAppPoolName)) -and (Test-Path ("IIS:\Sites\Default Web Site" + $iisAppName))) { #set the app pool to the application #Set-ItemProperty IIS:\Sites'Default Web Site'$iisAppName -Name applicationpool -Value $iisAppPoolName Set-ItemProperty -path IIS:\Sites'Default Web Site'$iisAppName -name applicationPool -value $iisAppPoolName -Force Write-Host $iisAppPoolName“ configured to web site: “$iisAppName } else { Write-Host "The App Pool/site does not exists" -ForegroundColor Yellow Write-Error "Failed to add application to the app pool" exit } Thanks, Srinivas

I had the same issue. What seems to solve this is to add "static content" in IIS features link

It seems like something changed in security settings - Publish Packages task got "private" scope. [image: vo6hmcg.png] I droped "Publishers" and added them again, scope has been changed to "all feeds" and problem gone! [image: NEDd3NU.png] Seems it's an upgrade bug because the scope option can't be set in free version... [image: 8qyYRQ3.png]

Hello Jim, Is there anything in Event Viewer → System from Service Control Manager, or anything from ProGet in the Application section of the event viewer?

If you upgrade to the latest v5.6 (currently 5.6.11), then it should work OK!

Aside from following the general back-up/restore instructions (database / package store / config files), there's nothing else to configure on ProGet. If you're getting errors, then something wasn't migrated properly. If a different file path is reported in an error, then a different file path is configured in the new instance; check out the error message under ADmin > Errors to see what the 500 was getting.

That particular error message is a result of the connection string missing from the configuration file. Please ensure there is a key present in both web.config and in ProGet.Service.exe.config. Most likely, someone had inadvertantly deleted it from the configuration file when attempting to configure the server in IIS. <add key="InedoLib.DbConnectionString" value="Data Source=...;Initial Catalog=ProGet;Integrated Security=SSPI" />