We will be adding a few fixes to help with retrying after indexing issues in the next maintenance release, as well as some more logging to figure out what is going wrong in these cases. Long term, we will also be redoing a lot of the indexing logic to eliminate these types of problems (but that probably will happen in a minor/major release.)

In this case, the web server user simply doesn't have permission to query the service status. You can ignore this message or increase the web server user's privileges.

Looks like a bug; IIS detection does not work on 2012 unless 4.5.1 is also installed. Will be fixed in maintenance release, but you should install 4.5.1 anyway since it has a bunch of bugfixes.

Most likely, the user that ProGet is running under is having difficulty requesting this information; you can try to restart the ProGet service, or the WMI service, and if all else, just reboot the server.

Thank you. I have replaced the contents of the WebApp and Service folders with the contents of the 3.1.0 manual installation zip file (except the config files of course). This seems to work as well. I think it is more or less the same effect as what you did by uninstalling and reinstalling, although your method is probably a bit safer! Luckily the database schema doesn't seem to have any updates in 3.1.1 that means it doesn't work with 3.1.0.

Curious, what versions of PowerShell do you have installed on the machine with the ProGet service, and also on the remote machine?

That action will package and deploy in much the same way as Visual Studio does when you click "Publish" for the solution, so it should only include the correct transformed configuration based on the publish profile selected.

Looks like Chocolatey now requires the description field to have a value, whereas pre-v0.9.8 it did not require one. We've updated the editor for v3.1.1 to require a description, though this will not impact existing data, so you'd still have to edit existing descriptions so that they have a value.

Thank you for the report - this will be fixed in the maintenance release coming out today (v3.1.1)

Thanks for the report - I'll have a dev take a look at this and fix it for the next version, which should hopefully be out today (8/14/14).

If the projects are located under a different root, it's easiest just to use multiple Get Latest actions if you don't want to get the entire root in one action.

Good questions, take a look at the Upgrade Notes for each minor version from 4.0 to 4.4, this will detail any breaking changes, but those are generally related to SDK and API use. If you have not developed your own personal custom extension, then you can ignore the SDK breaking changes. To make a backup of all BuildMaster settings, simply backup the BuildMaster SQL Server database. The installer should give you the option to do that as well provided the software is installed on the same server that hosts the database.

I'm not sure the component we use to FTP supports negated wildcards, but you can simply add a Delete Files action before this that operates on *.config Alternatively (if you don't want to delete because you may re-use the files), you can use the Synchronize/Transfer Files action to a temporary directory (e.g. ~\Ftp) and use a !*.config mask on that to not transfer the configs, then use the FTP action from ~\Ftp as the source directory.

Yes, SQL Server 2014 is supported - I will update that article.

I figured it out. In the setup screen, the "TFS Server Name" instructions do not specify that a project collection needs to be included in the URL. Once I added the project collection name to the end of the example URL given on the setup screen I was able to connect.

It's unlikely this will be supported. There is no way to identify from metadata a symbol package vs a regular package... you have to open the zip file and see if it contains pdb/src files... which means we'd have to download every version of every package in a remote feed. If Microsoft / NuGet team ever implements a mechanism for identifying , then it's a possibility.

Thanks - somehow I missed that in the docs before. I will add this as an open issue (PG-221).

Predicates in combination with variables (e.g. the Set Variable Value action, $BackupDB = true, then check for that later as necessary) are a good idea for the meantime. We've had requests that imported deployables should be allowed to be dependencies and that feature is scheduled for a future version.

Can you verify that: the TFS services are accessible over port 80 there is no firewall blocking that port access to the root path is open (e.g. /tfs, you can test this by trying http://windows2012r2-1/tfs/DefaultCollection instead [or whatever collection name you're looking for])

The XML you have: <ReleaseDeployables><ReleaseDeployables> should be <ReleaseDeployables><ReleaseDeployable> (notice the missing s on the inner element).