Mucking around TFX2015RC throws up some surprises. Creating a new build XAML build definition / loading an old XAML definition will result in a cryptic build error.
The current fix? Install VS2015RC on the box – minimum installation options should suffice (unless you encounter that weird installation bug that prevents you from doing that).
Hope that Microsoft packages that DLL into TFS directly, rather than required an entire install. Microsoft, are you seeing this???
I’m currently encountering issues with installing VS2015RC on some VMs that I have on hand (W2K12 upgraded to W2K12R2), as TFS XAML builds are not able to succeed without the presence of VS2015RC on them. Symptoms of the errors I encounter include:
- Access Denied on various components during the installation
- Errors logged in installation log file
[1E58:06CC][2015-05-26T15:07:39]i301: Applying execute package: Windows81_x64, action: Install, path: C:\ProgramData\Package Cache\469A82B09E217DDCF849181A586DF1C97C0C5C85\packages\Patch\x86\Windows8.1-KB2999226-x64.msu, arguments: ‘”C:\Windows\SysNative\wusa.exe” “C:\ProgramData\Package Cache\469A82B09E217DDCF849181A586DF1C97C0C5C85\packages\Patch\x86\Windows8.1-KB2999226-x64.msu” /quiet /norestart’
[1E58:06CC][2015-05-26T15:07:39]e000: Error 0x80070005: Failed to open WU service.
[1E58:06CC][2015-05-26T15:07:39]e000: Error 0x80070005: Failed to ensure WU service was enabled to install MSU package.
[1E58:06CC][2015-05-26T15:07:39]e000: Error 0x80070005: Failed to execute MSU package.
[091C:14C8][2015-05-26T15:07:39]e000: Error 0x80070005: Failed to configure per-machine MSU package.
[091C:14C8][2015-05-26T15:07:39]i000: MUX: Installation size in bytes for package: Windows81_x64 MaxAppDrive: 0 MaxSysDrive: 0 AppDrive: 0 SysDrive: 0
Managed to manually install the offending patch, but even after that, the installation still fails. (Thanks @sihuiwsh)
Apparently others have also encountered this problem, will keep an eye out and update here if a solution is found.(https://social.msdn.microsoft.com/Forums/en-US/64baed8c-b00c-40d5-b19a-99b26a11516e/visual-c-redistributable-for-visual-studio-2015-rc-fails-on-windows-server-2012?forum=vssetup&prof=required)
I’ve been messing around TFS2015RC these days, and one of the coolest new feature is the Build vNext Preview. However, it is not smooth sailing and one of the issues that cropped up was that the Build vNext Agent failed to install correctly during the setup process because I forgot to set up the proxy server, which led to the agent not being able to locate the TFS server (TF402467).
Heading back into the TFS Admin Console confirms this.
Attempts to “Change Account” or set the “Work Folder” would fail because of a “corrupt setting.json” file.
Digging into “C:\Program Files\Microsoft Team Foundation Server 14.0\Build” would show a setting.json with seemingly empty values. However, a ConfigureAgent.ps1 seems promising.
Call the powershell script, and provide the required values (assuming you have already sorted out the issue that caused the failure in the first place)
PS C:\Program Files\Microsoft Team Foundation Server 14.0\Build> ./ConfigureAgent.ps1
Enter the name for this agent (default is Agent-TFS2015RCDEMO):
Enter the url for the Team Foundation Server (default is ): http://localhost:8080/tfs
Configure this agent against which agent pool? (default pool name is ‘default’):
Enter the path of work folder for this agent (default is ‘C:\Program Files\Microsoft Team Foundation Server 14.0\Build\_
Would you like to install the agent as a Windows Service (Y/N) (default is Y):
Enter the name of the user account to use for the service (default is NT AUTHORITY\LocalService):
Would you like to unconfigure any existing agent (Y/N) (default is N; the agent will be updated):
Calling agent configure with /RunningAsService
Calling agent configure without /Force
Installing service vsoagent.localhost.Agent-TFS2015RCDEMO…
Service vsoagent.localhost.Agent-TFS2015RCDEMO has been successfully installed.
Creating EventLog source vsoagent.localhost.Agent-TFS2015RCDEMO in log Application…
Configure agent succeeded.
Agent is now running as a Windows Service.
PS C:\Program Files\Microsoft Team Foundation Server 14.0\Build>
Jumping back to the TFS Console Admin, we see that the Build vNext Agent has been set up and running. Yay! Hope this helps someone!
This builds upon my previous post to mix domain and non-domain build servers together. I wanted to have a controller each to manage the various build agents within the domain and non-domain build servers. Enabling this was a piece of cake.
Head over to your TFS Admin Console on your Build Server, and create a new controller.
Reassign each agent to use the new controller by clicking on the Properties link, then update the Controller value.
Skip over to queue a new build. You’ll notice that now you have 2 build controllers to select from. Target the new BC and you’re done!
With some spare time on hand, I wanted to explore if there we were to mix domain-joined build servers with non domain-joined ones, since this could open up a couple of interesting possibilities.
1. Ensure that the target TFS server is reachable, so that we can put proxy and firewall issues aside.
2. Install TFS, but select to only configure Team Foundation Build Service
2. Define the TFS Server, then select the Team Project Collection
3. Enter the credentials that your build service will run as. Ensure that the necessary permissions have been granted, otherwise you’ll get a TF254021 surprise.
4. Continue with the installation, and you’re done!
5. So now you have a non-domain build service (with 2 agents) connected to a domain-joined TFS and Build Controller.
#To set the permissions, make sure that your TFS target is not a Domain Controller. Create a local account (e.g. remotebuild) on TFS, your build controller and your Non-Domain Build Server. Make sure they have the same password. I also added the account to the Project Collection Build Service.
# Make sure that communication on port 9191 from Build Controller to your Build Agent is enabled.
Posted in TFS
Tagged Build Service, TFS
But first, some background. My connection to TFS is via HTTPS, using an internal CA signed SSL Cert.
HTTP works fine(using FQDN), but with custom domain names and HTTPS, sometimes it works, sometime it doesn’t.
When I connect to the HTTPS url via IE, the connection works, but no lock ICON appears. If I repeat the same action inside the VS2013 browser (Ctrl-W, W), a revocation failure dialog sometimes pop up. Regardless of selection, the authentication still fails.
I’ve tried the clear cookie method suggested, disabling cert revocation checks on the server (via netsh) and locally (via gpedit), or at least I think I did, but no luck yet.
This is irritating… Gah!
[Edit] Checked permissions as described here but still no go …
[Edit] Checked that server had a 3+ min delay compared to client, fixed that, cleared cache etc, but still no go…
[Edit] Seems to be no correlation between IE having a lock sign, and the revocation message inside VS browser.
Posted in TFS, Visual Studio
Tagged SSL, TFS