Wix tools can be used to generate msi installable packages, .exe setup bundles, .msm merge modules, and .msp patches. Getting a wix project built with visual studio is fairly simple. If you are using VS you can install the extension from marketplace and install wix tools to get going in the development environment. Tools available for VS 217, 2015, 2013, 2012 and 2010.

You can setup TFS builds to build wix projects following the instructions in http://wixtoolset.org/documentation/manual/v3/msbuild/wix_with_team_build.html. There is more detailed documentation available in http://wixtoolset.org/documentation/manual/v3/msbuild/. The blog here also useful http://programcsharp.com/blog/post/building-wix-with-msbuild.

However, when you are running a build to package .msi etc using wix project you might notice the build sometimes hangs forever. This happens because of a deadlock when msbuild and wix waiting on the output stream.

To prevent this from happening pass the argument below to build arguments.

/p:RunWixToolsOutOfProc=true

This allows packaging of .msi with wix tool to run normally with TFS builds.

yo team is a great NPM package by Donovan Brown, to automate creation of build and release pipelines. You can use it to generate app with CI/CD in Team Foundation Server 2017 or Visual Studio Team Services. In this post let’s look at how to get it installed, for you to use it to generate CI/CD pipelines

The first requirement is to install node.js and npm latest. You can download it from https://nodejs.org/en/download/. Instruction on installing on windows is here. You can verify the installed version of node and npm by running below commands.

• npm –v
• node -v

Install git following the instructions in https://www.atlassian.com/git/tutorials/install-git 

Install yeoman command line by running npm install –g yo . For more information refer http://yeoman.io/learning/

In a PowerShell window  type yo to see the yeoman options. Select install a generator and hit Enter.

Search for team in npm.

In the list of generators locate the team Generates an app with CI/CD in Team Foundation server or Team Services and hit enter to install.

Now you can run yo team and start working with package. In a next post let’s see what we can do with this package.

ASP.NET Core 1.1 is available with Visual Studio 2017 and it is based on .csproj to provide us with a consistent experience inside Visual Studio. .csproj will be the way forward with ASP.NET Core and Microsoft encourages everyone developing on ASP.NET Core to move to Visual Studio 2017. You can see the recommendation in https://blogs.msdn.microsoft.com/dotnet/2017/03/07/announcing-net-core-tools-1-0/ quoted below. Microsoft will not be updating VS 2015 based tools for .NET core anymore.

“Migrating project.json Projects to csproj

We’re now encouraging everyone to migrate to MSBuild and csproj from project.json. As I stated above, we will not be supporting any of the new .NET Core tools in Visual Studio 2015. We also won’t be updating the Visual Studio 2015 project.json-based tools.

There are two experiences for migrating project.json projects. You can migrate project.json files on the command-line, with the dotnet migrate command. The command will produce a .csproj project file that you can use with the latest .NET Core tools or open in Visual Studio 2017.

You can also open .xproj files in Visual Studio 2017. Visual Studio will migrate your .xproj files for you, producing a .csproj file that you can use going forward for use with both Visual Studio 2017 and with the latest .NET Core tools at the command-line.”

Let’s look at Team Services build definition that can build an ASP.NET Core Web Application developed with VS 2017. 

1. In your build definition make sure to select the Hosted 2017

2. Define variables for build configuration and build platform.

3. Add a command line task and add tool as dotnet and argument restore. Set the working folder to web project folder path.

4. Add a Visual Studio Build task and use build configuration and platform variables and version of Visual Studio as 2017.

5. Add command line task and use dotnet for the tool. Arguments should be publish -c $(BuildConfiguration) -o $(Build.ArtifactStagingDirectory). For the working folder provide the web project path.

6. Add an archive files task. Provide $(Build.ArtifactStagingDirectory) as the Root folder. Make sure to uncheck the “Prefix root folder name to archive paths”. Provide zip as Archive type and $(Build.ArtifactStagingDirectory)/$(Build.BuildId).zip as the “Archive file to create”.

7. Add Publish Artifacts task and provide $(Build.ArtifactStagingDirectory))/$(Build.BuildId).zipas”Path to Publish”.

Save and queue a build and you will be able to download the published ASP.NET web app zip file from the Build artifacts.

TFS/VSTS new build and release management is providing great flexibility in implementing CI,CD pipelines. To further enhance the flexibility a new feature “Conditional Tasks” is introduced to Tasks of build and release management. This was a user voice request that got implemented and available as preview in Team Services. This new conditional control option let’s you execute a task base on few predefined conditions and using custom conditions.

Predefined conditions

• Only when all previous tasks have succeeded
• Even if a previous task has failed, unless the build was canceled
• Even if a previous task has failed, even if the build was canceled
• Only when a previous task has failed

To enable this feature for your team services account follow the steps described below.

In the team services we portal, click on your profile picture and in the menu, click Preview features

Preview features popup default shows preview features for your logged in user. This new Conditional task feature does not allow you to enable it only for you. You have to do it for the team services account. To view the new feature select for this account

When for this account selected additional preview features will be shown and you can on/off “Task Conditions” feature.

Switching this on, prompts with confirmation saying this affects to all users in your account. Click on Turn on to enable.

Once switched on you can see additional drop down available in each task control options.

You can read through documentation here to get more in-depth understanding of how the Custom conditions can be specified.

VSTS allows great flexibility with it’s new web based build and release management features. You have several templates which can be used to create build and release definitions you need quickly. Lots of out of the box tasks allow you to further customize your definitions to support the steps that you need to perform during a build or a deployment. Visual Studio Marketplace is getting more and more components added to it, allowing you to find a task for almost any build deploy step you may require to perform. Taking the steps to the next level, you can now even generate your build/release pipeline with Visual Studio 2017, after adding the extension Continuous Delivery Tools for Visual Studio.

Let’s walkthrough the steps of generating a CD pipeline for an MVC Web Application, to allow it to be deployed to Azure App Service.

01. Create a Team Service, team project with repository selected as GIt or add a new Git repository to an existing team project.

02. In Visual Studio 2017 clone the repository.

03. Create a new Visual Studio solution.

04. Add a new MVC Web Application project to the solution.

05. Commit the changes to repository and push.

07. Download and install Continuous Delivery Tools for Visual Studio. This will add an option to generate CD pipeline targeting Azure, in Visual Studio.

08. In the popup window you can see the repository and branch selected to use the code base. If you care logged in with a Microsoft account having an Azure subscription it will be shown as target. You can add a different Microsoft account as well by clicking the drop down for User account field.

09. Click Edit on above screen will let you modify target App Service App Name, Service Plan, Location and Resource Group.

10. Select the preferences and click OK in  Configure Continuous Delivery window will create an Azure App Service App and configure a CD pipeline. Then will queue a build, once complete will trigger a release/deployment to the created Azure App Service App.

11. You can view the build definition created in the Team Services project and edit it.
12. You can see a build is already queued and completed and a deployment also completed.

13. A release definition available.

14. A deployment has triggered and deployed the application to Azure App Service.

15. Application is running in Azure APP Service.

16. To facilitate above build and deployment Azure Resource Manager service endpoint also generated.

C# developers often use string.Format in handling string. string.Format the { and } is used as a special character to identify the parameters.

For example:

scrollDepth = “10”

string.Format("DOWN {0}",scrollDepth)  generates a string DOWN 10.

But what if a { should be used as a value in the string. Is there a way to include { in the string?

To escape a { you can {{. So if you want to get the resultant string as “{DOWN 10}” the syntax to use is

string.Format("{{DOWN {0}}}",scrollDepth)

Deployment groups provide robust out-of-the-box multi-machine deployment with team services release management. It allows you to run deployments across multiple machines. You can install agent on each of your target servers directly and run rolling deployment to those servers, unlike agent based deployments where you install build/deployment agents on proxy servers in an agent pool. You can use all tasks in task catalog on your target machines.

Deployment group allows you to create target deployment machine groups, without requiring you to register machines in agent pools or queues. Machine in a deployment group will have an agent registered with the named deployment group, within the team project providing required isolation for target environment (such as DevInt, QA, UAT, Demo, Production etc.), for a given product or project.

Logical group of targets (machines) having an agent installed on each of them is a deployment group. It represents your physical environments. It can be single-box, multi-machine or a farm of machines. You can specify the security context for your physical environments by using the deployment groups.

Let’s look at how to create a Deployment Group in Team Services.

In a team services team project, click on Build & Release–> Deployment Groups. Then click New or Add deployment group button to create a new deployment group.

Provide a name for the deployment group and click Create button.

A new deployment group get created and you can register different machines to the deployment group. To do that for windows machine you can copy the PowerShell script available and execute in the required machine.

If you select “Use a personal access token in the script for authentication” it will generate a personal access token for the current user, scoped to Deployment group.

You can setup agents in Windows or Linux machines. By selecting relevant machine type you can copy the script for the given OS.

Execute the copied PowerShell script in a windows machine to register it with the Deployment group.

Agent.zip will be downloaded and extracted to a folder A1 in system drive by the script.

You can provide machine tags to identify/differentiate machine role within a deployment group. For example WebServer, DBServer can be such tags.

You can provide a local user in the machine or domain user if your machine is in a domain to execute the agent service or it will be executed with system user by default. Agent will be successfully registered with the Deployment group. You can add additional tags or remove the tags specified in the machines tab of the deployment group. A machine can be removed from the group if it is no longer required to be in the group.

Now in your release definition you can use this deployment group to do deployments. You have to add a deployment group phase to your release definition. 

You can use tags to filter for machines in a deployment group. This allows you to use multiple Deployment group phases in a release environment to perform different set of actions in different machines selected depending on the tags.

You can set parallel execution options within a Deployment group phase, when you have multiple machines in a deployment group.

Deployment groups are only available for VS Team Services and not available in on-premises TFS as of now. It will be available for on-premises TFS in future.

My friend Jaliya Udagedara has written nice post here, explaining how to deploy a Core web application into Azure App Service Application virtual directory. Below is comparison of few more settings you can use with Azure virtual directories.

Team Services is coming up with many improvements and one of it is the new process customization experience introduced recently. This allows you to have your own custom work item types, custom work item state flows and custom fields for work items etc. It is made easier to start customizing even directly from work item form. Let’s look at and understand process customization options available for you to optimize your work process.

You can navigate to Process tab from account home page to see the available processes in team services.

If you are in a team project view you can go to Account Settings page an then go to Process tab.

In the Process tab default available three process templates, Agile, Scrum and CMMI are shown.

You can click on each process template menu to create an inherited process from it for customization purpose.

In the pop up window you can provide a name for the inherited process and create it.

You can go to edit mode of the custom process by clicking on its name. Edit in menu will allow you to change the name of the inherited process. You can delete the process as long as it is not used by any of the team projects. Click on “Change team project <inheritedprocessname>” to use it in existing projects. New team project can be created with the inherited process by clicking New team project.

Click on name of the new inherited process.

Types of customizations

• Adding new work item types

Click on  New work item type and provide a name and select a color and click Create.

• Backlog level for new work item

Backlog level for new work item can be set by clicking on edit in a current backlog level of a existing work item. You cannot change the behavior of the Bug work item as it is controlled as a team preference to be available as Requirement backlog item or Iteration backlog item. You cannot select the Issue backlog item in Agile inherited process to any backlog level as it is there for the purpose of issue tracking.Same applies to Impediment work item in Scrum process.

In the pop up you are allowed to select the new work item type for the backlog level. You can even select it as default backlog level if you want. You can change the name and color of the backlog level to your preference.

• Editing existing (out of the box) or added custom work item type

You can edit the custom work item type name, description and color by clicking edit in menu. For existing work item types you are only allowed to disable them but you cannot edit name, description or color. To edit the existing/custom work item type field layout states, etc. click on its name.

New fields can be added to existing or current work item types. You can refine new group in the Layout to group your fields. Further you are allowed to add new pages to keep your fields and groups. Titles of groups other than Development and Related work can be edited. Any existing group can be hidden from the layout. Adding custom fields will be discussed in detain in a next post.

State flow of a work item can be changed in states tab. Currently you are not allowed to add states to Completed state category. States customizing with team services will be discussed in detail in a next post.

All fields in a team services account is shown in Fields tab of the Process admin page. You can delete any custom field added here but cannot delete existing out of the box fields.

In next few posts more details on customizations of team services process will be described.

Custom states for work items could be introduced and usage of new custom workflow for state transitions, is possible in team services from some time back. The post here describes how to customize work item states. With latest updates to Team Services a new process customization experience is introduced as described in “Team Services Process Customization”. Let’s  explore the state workflow customization of work items with the new process customization experience.

You can click on a work item name in the inherited custom process template or click on a given work item form menu, customize to open the work item customizing page.

If you click from work item form menu then you will be prompted to select existing inherited custom process template or create a new one.

In the inherited process you can click on work item to edit its layout or states (if you have clicked on Customize from a given work item form you will be directed to relevant work item edit page directly).

In the work item customize page go to States tab. You can hide or show (if already hidden) existing states. A state cannot be hidden only if it is the only state available in the given state category. For example if you try to hide New state without adding another state to Proposed category error message given below will be shown.

VS403089: Cannot hide state 'New' since it is the only one in its state category. Add another state in same state category before hiding this.

New state can be added to any category except Completed category as of now. If you try to add a new state to Completed category or try to hide existing state in the Completed category, below shown error message will appear.

VS403093: Team Services currently does not support changes to 'Completed' category. Choose a different category.

View state for existing state will show you the details of the state but those information cannot be edited. Only possible option is hiding the existing state after adding a new state(s) to the same category.

When adding a new state you can select the category (except Completed) and color for the state. Previously added custom states (even for different work item types) will be listed in drop down to minimize the chances of adding the same sate with different spellings by mistake.

You can select a state from existing list (coming from different work items or from other templates) or add a new state by typing new state name.

Custom states created can be edited or removed.

If a existing non custom state is hidden you can show it by clicking show in the menu of the state.

These state changes will be available for you in the work items and you can use Board Column customizations to make it  more effectively used by your teams.

Team Services now allows work item states to be customized and you can change the workflow to your preference. This is explained in the previous post “Custom States for Work Items in Team Services with New Process Customization Experience” in detail. As explained there you can hide available default states and use your custom sates instead of them. But as of now state change from a custom state to Completed category state does not update the Closed Date and Closed By fields in Bug and User Story/PBI work items. For Task work item in custom state , changing to Completed category state, updates Closed Date but not the Closed By field.

Let’s further understand this issue with an example.

User story is introduced with below highlighted custom states and default available states also kept without hiding them (refer “Custom States for Work Items in Team Services with New Process Customization Experience”  for more details).

State change from default available states New, Active, Resolved –> Closed will update the Closed Date and Closed by fields.

But history does not show anything about Closed Date field update, but has info on Closed By field update.

Moving back to a default available state will clear these two fields.

Again history only has information on Closed By field update not the Closed Date field.

But moving from custom state to Closed (Completed category) will not update Closed Date or Closed By fields.

History does not have information on Closed Date or Closed By fields update, which is understandable as they are not updated by this state change. But ideally it should have updated the Closed Date and Closed By with the correct values as happened in Default “In Progress” category state to “Completed” category state transition.

Behavior is same even if all the default states are hidden for the user story. A Bug work item has the same behavior. Task work item is little bit different from this, as it will always update Closed Date field with the correct value, regardless of whether the state change to Completed category state, is done from a default state or from a custom state.

When state is changed back to In Progress or other category state from Completed category state, Closed Date and Closed By fields get cleared, only if the target state is a default available state. If the target state is a custom state, then Closed Date and Closed By fields do not get cleared, for User Story,Bug and Task work items.

This is bit confusing situation and it could be accounted as a bug in Team Services or may be Closed Date and Closed By fields are deprecated, and the State Change Date is there as the alternative. But  in Scrum process template PBI (Product Backlog Item) does not have State Change Date field even though Bug work item has it. There is no Closed By field in work items of Scrum template.

How to resolve this?

As of now no way to resolve this issue, but this can be fixed with new feature “Define business rules for work item types” coming into Team Services, hopefully soon.

Visual Studio 2017 creates few files such as slnx.sqlite, .suo and these files often give trouble if you get it added to a branch in Git version control. Every time you open a solution in Visual Studio 2017, these files are indicated as pending changes and you are unable to do a pull, push etc. without undoing or committing these files. This is annoying since you actually do not want these to be added as changes to version control repository. You can try completely removing the files not needed from repository but if you are not willing to go through somewhat risky procedure, what options you have for solving this problem?

Let’s look at how to fix this issue.

.gitignore

Adding unwanted files to .gitignore works as long as you have not initially committed them to any branch. But in this case where it is already committed adding .gitignore entry such as /.vs/slnx.sqlite does not help.

Ignore changes to the files

You can run below command to ignore the changes to these files by assuming they are unchanged.

git update-index --assume-unchanged filename

To run the command open command prompt from team explorer window of Visual Studio by right clicking on the repository name of the connect page.

The command git update-index --assume-unchanged slnx.sqlite gives error “fatal: Unable to mark file slnx.sqlite” because it actually cannot find the file.

Providing correct path to file from the location you are running the command will make it execute without error message.

slnx.sqlite file no longer considered as changed.

You can undo the the assume-uchanged state by executing command below.

git update-index –-no-assume-unchanged filename

Backlog item sizing will help an Agile team to identify their velocity and plan for future iterations/sprints considering it. It is important the team members have discussed a backlog item and have a common understanding on what needs to be done before it is relatively estimated. Sizing for backlog items in Team Services work items such as User Story, Bug can be updated in Story Points or Effort field depending on the template you are using. Team Services extension, “Estimate” is available in Visual Studio Marketplace allow you to do effective estimating of backlog item, by enabling team to vote for each work item using on Team Services, while getting Story Points or Effort field update automatically with the size value, once team is committed to a size.

When you have installed Team Services extension Estimate  you will see new menu item “Estimate work item(s)” available in the work item popup menu.

You can go to Estamates sub tab available in Work tab as well. Then start a new session to estimate work items.

Start the session and other team members can join the session in the Estimates tab.

Team members can then vote for the work items by selecting a work item. Selecting work item can be only done by the session started member only and others can vote.

Voting value will be shown to you but not to others. Until someone session owner reveal it.

Once all votes given, average estimate can be viewed as an average of number of people voted.

Team can have discussions and agree on the average or go for a revote. Session owner (start initiator) can select a different work item and select the required work item to enable a revote. If team agrees on an average it can be committed to the work item. It is possible to alter the auto calculated average manually before committing to the value.

This value will be updated to the Story Points/Efforts field of the work item.

Release definition in Team Services helps you to define deployment pipelines across target environments. You can setup a release definition to deploy via agents, deployment groups or execute agent less activities. With the latest update to Team Services a new release definition editor is introduced. Let’s ex[lore the new editor.

To enable new release definition editor in Team Services click on Preview features.

In the preview feature list enable the New Release Definition Editor.

Other option to enable the preview feature is by clicking Try it! in the new feature notification that appears in the Release tab.

In the edit mode of the release definition you can visualize the release pipeline in a more effective and meaningful way.Sequentially running environments and parallel deploying environments will be shown properly in the new view.

Parallel deploying DevInt environment.

Continuous deployment trigger can be setup for each build artifact. It can be automated depending on the branch built.

Post deployment approvers can be changed with each environment by clicking the person icon in the release workflow.

Adding and cloning new environments is possible when you move your mouse just underneath an environment. You can also do it from the Environments Add button for adding new environment, or select an existing environment then clone it by selecting the option available in the drop don menu.

By clicking Phases and Task link in each environment you can view/edit the given environment tasks.

You can also select the each environment from Task menu to edit or view it.

Run on agent options cab be set by selecting the agent phase. Here you can set the demands agent queue etc,

You can now add tasks using task tabs, to agent/deployment group or agent less phase. This is same experience available in the build editor with facility to search for tasks, drag drop in a preferred position etc.

To add new agent/deployment group/agentless phase click on the menu (three dots) in the environment and select the required phase.

With the latest release to Team Services Kanban Card has been added with a new feature. Previously, if you want to edit a value in a field that is currently empty, in the Kanban Card You  had to keep it showing even if value is empty. With the new feature available now you can let Kanban Card to hide a field, if it is empty and expand the Card to show empty fields  so that you can edit them.

You can let the empty fields in your Kanban Card hidden.

This will hide a field if it has empty value, even if you have selected the field to show in Kanban Card.

When you hover your mouse over a Card you can now see a chevron  which allows you to expand the Card.

Once you expand you can now see the selected fields for the card even if they currently have empty values. You can edit the fields on the Card and you can collapse the card using the chevron, to hide the empty value fields.

Team Foundation Version Control (TFVC) is widely used with Team Foundation Server and in Team Services, as a source control system to manage source code repositories.Usage of TFVC can be found here. If you want to generate history report for TFVC including details of files changed and any work items associated with the changesets, you can use the script available at TechNet Gallery.

This script works with Team Foundation Server 2017 or later and with Team Services. In order to use the script you need to create Personal Access Token (PAT) for your profile. Instructions to create a PAT can be found here. This PAT should be scoped to as shown in below figure with Code(read), Work items (read) and Work items search (read) permissions.

You can execute script with the parameters specified below.

• token – generated PAT.
• fromDate – the date the change history report should be generated from.
• toDate – the date the change history report should be generated to.
• sourceControlPath  - Path of the source control to consider
• collectionUri – the URL of the collection

.\GetChangeHistory.ps1 -token "pat value" -fromDate "01-01-2017" -toDate "08-31-2017" -sourceControlPath "$/Project X" -collectionUri "https://yourteamservice account.visualstudio.com/defaultcollection"

When the script executed it will output a log showing each change history item being processed. An html report will be generated in the same location where the script is located.

Html report will have a link to the changeset and any work items associated to it, while listing all changed files. Changeset will include the changed person and the comments and date time information.

Await for similar script for Git version control in TFS and Team Services.

You might want to clone your TFS instance if you are doing a hardware move upgrade. There can be other situations such as you need to move one of your projects to VSTS (Team Services) using high fidelity database import, without migrating other projects in the same collection. If you prefer to keep your current TFS untouched while trying to create an isolated collection for a single project, you might want to clone and create an instance of your TFS. There can be several other experimental reasons you may have to clone a TFS instance.

Let’s look at backup options we have.

You can backup TFS after stopping all services and taking manual backups via SQL Management Studio. If you want to keep your TFS running while you take backup, you can use the TFS administration console backup scheduler and trigger a manual backup. First create scheduled backup with manual backup option selected. Then take a backup by manually triggering a full backup.

But if you are taking a backup without stopping TFS services, make sure you have no other backup plans running using SQL server backup devices etc. This is because your backups to be restored should be in time sync etc and it will be done using trn files added to backup set. If any other SQL trn (transaction log) backups happen during the long running TFS backup process you may encounter issues in restoring. make sure to add a report key encryption password and remember it for restoration, in different hardware. The learnings here are also worth having a consideration.

Backup set will not include the Tfs_Analysis backup. To take the analysis database backup connect to Analysis Services via SQL Management Studio and take the backup manually. This database should be rebuilt with the warehouse once the cloning of TFS completed. But this is required to be restored to allow running commands such as prepare clone, which will be explained in next article.

Provide path and name of the backup file with extension .abf and click OK.

To Restore

First setup your target machine with same SQL server version of your current TFS database server. Higher version of SQL also works fine. To find out the version and edition of your TFS database SQL server execute below commands in a new query.

SELECT @@VERSION

SELECT SERVERPROPERTY('edition')

Setup the TFS version (exactly current TFS version you have in your current TFS server) in the target clone server. You can find the Current TFS version in Admin console of your current TFS server AT.

Once the same version is installed, do not configure anything, close the wizard that appears.

Go to Scheduled Backups and click on Restore Databases. This process will only restore the databases in SQL server, but will not configure a TFS server clone.

In the restore wizard you have to set the backup path where your backup set is available.

In the next step select all databases. and provide the new Database server name (Current TFS database server name appears here, do make sure to change it to new one before proceeding).

In the next step provide the password you have used when creating backup of the reporting services key.

You can review the settings and then run the readiness checks.

You might get the above shown error if you have your new SQL server reporting services configured in native mode. Go to the SQL reporting services and change the database name to something like ReportServer1.

After configuring the report server with different database name remove the ReportServer and ReportServerTemp databases from SQL server.

With this your readiness checks should pass.

Click o Restore to restore the databases. This will take considerable amount of time depending on your TFS databases size.

Restore operation completed with warning on failure to restore the reporting services key.

Out of below issues we have to only worry about the reporting services key as we are cloning our TFS environment.

TF400980: Failed to restore the Reporting Services encryption key. You can try using RSKEYMGMT command to restore the encryption key
 
TF401010: The backup path changed since Scheduled Backups were configured.  This may cause future backups to fail.  Rerun the Scheduled Backups wizard to update the settings to the new path.
 
You may need to purge the version control file cache on all TFS ATs and all TFS proxy servers that service the TFS instance prior to putting the TPC back online. For more information, see this KB article http://support.microsoft.com/?kbid=2025763

To get the reporting services working with the restored report services DBs go to change databases in Reporting Services Configuration Manager, and change database. Select the option of use existing database and proceed.

Select the restored ReportServer database. Then proceed with the wizard to set the databases to restored ReportServer and ReportServerTemp.

To restore the encryption key go to Encryption Keys and click on Restore.

Provide the encryption key that is backed up earlier, and provide the password.

Encryption key should be restored successfully.

You can safely remove the temporary report server databases created earlier named ReportServer1 and ReportServer1Temp.

You should be able to see your report services now containing the TFS reporting server database information and details of each of the collections.

As the last step restore the analysis database. In analysis services of new server click restore in databases menu.

Select the backup taken and provide TFS_Analysis as the name of the database to restore. Make sure to copy backup to a local drive to avoid access denied errors when trying to restore.

In the next post we will look at how to prepare restored databases for cloning the TFS instance.

You have to make sure you are not corrupting your current TFS instance that is up and running, while you are cloning a  TFS instance. For this you need to prepare the restored databases of the TFS, in new hardware, before configuring the cloned Application Tier of TFS. In the “Cloning Your TFS Server Part 01 – Backing Up and Restoring Databases” how to back up and restore TFS database was discussed in detail. Let’s look at each of the preparation steps required in order to guarantee both current TS instance and cloned instance can coexist in the same network.

SharePoint

If you have SharePoint with your TFS then execute below commands, to redirect SharePoint products to  new content databases restored. You have to do this in the SharePoint foundation machine you have setup in new hardware. Change directory to Drive:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\15\bin and the execute the commands.

stsadm.exe –o addcontentdb –url http://SharePointFoundationServerName/sites -databasename WSS_Content -databaseserver SQLServerName

stsadm.exe -o addpermissionpolicy -url http://SharePointFoundationServerName -userlogin Domain\UserName -permissionlevel "full control"

Server IDs

This step is mandatory to prevent risk of corruption of your current TFS instance and Cloned instance if both are live together. Corruption could happen if they are pointing to same SharePoint or Report Server. Open a command prompt as an administrator and change the directory to Team Foundation server tools folder. in the new Application Tier (AT). It can be Drive:\%programfiles%\Microsoft Team Foundation Server 12.0\Tools if the TFS instance is TFS 2013. For TFS 2015 it is Drive:\%programfiles%\Microsoft Team Foundation Server 14.0\Tools.

Execute the command below to prepare for TFS clone. This will remove information about scheduled backups, SharePoint, and reporting resources from a Team Foundation Server (TFS) deployment. You must run this command before configuring AT of your cloned TFS. For more information visit here.

TFSConfig PrepareClone /SQLInstance:ServerName /DatabaseName:TFSConfigurationDatabaseName /notificationURL:ApplicationTierURL

When above command executed you might run into error below if you have not restored the TFS_Analysis database.

TF246083: The configuration of Team Foundation Server is not valid. You must remap the databases in order to fix the configuration. The following error was received from the server: TF400673: Unable to find any compatible SQL Analysis Services database within the specified instance.'2' hosts have been given updated connection strings.

With TFS_Analysis database restore in the new database server prepare clone command executes successfully.

If you have configure Lab management for current TFS instance you will see a warning as shown above. As instructed execute TfsConfig.exe lab /delete /collectionName:collectionName to clear all lab assets from the clone, once the configuration of Application Tier of the cloned FS instance is completed. This further will be discussed in the next article.

After prepare clone execute the ChangeServerID command to change the server GUIDs associated with the TFS databases.

TFSConfig ChangeServerID /SQLInstance:ServerName /DatabaseName:ConfigurationDatabaseName

Once the command executed it will prompt you to confirm Application Tier is not configured as this command should only be executed in a scenario where Application Tier of TFS is not configured and databases just restored.

All database IDs will be changed with the command.

Next execute RemapDBs command to redirect TFS to its databases in new hardware. This is not mandatory as you can see previous command already remapped the databases as shown in above screenshot. But you can execute the command to make sure it is properly mapped.

TFSConfig RemapDBs /DatabaseName:ServerName;ConfigurationDatabaseName /SQLInstances:ServerName1,ServerName2 [/AnalysisInstance:ServerName] [/AnalysisDatabaseName:DatabaseName] [/preview] [/continue] [/usesqlalwayson]

You should get the message that the current configuration is valid as shown above.

With the above steps the TFS databases in new hardware is prepared and ready for configuring as a cloned instance of current TFS. These two instances can coexist in the same network after the clone is configured. In the next article we will have a look at how to configure the cloned instance.

To clone an instance of a TFS server while the current live instance is running it is required to take backups as explained in “Cloning Your TFS Server Part 01 – Backing Up and Restoring Databases” and restore the DBs in new hardware. After that there should be preparation activities run as described in “Cloning Your TFS Server Part 02 – Prepare Restored Databases” to make sure the current and cloned TFS instances are not getting corrupted, when both running simultaneously in the same network. Let's go through the configuration steps to configure the cloned TFS instance.

Launch the TFS configuration  wizard from the TFS Admin Console.

Select Application Tier Only (since we are going to use existing databases) and start the wizard.

Make sure your new SQL instance having restored and prepared TFS databases, is specified and click List Available Databases.

You will see TFS_Configuration database details with the version of TFS. Click next to proceed.

Use the same account that is used in current TFS instance for the TFS service account of the clone and test the account. Using a new account for this purpose is also OK.

In the Application Tier step make sure to edit site settings and remove the URLs referring to your current live TFS instance.

Make sure to review that no references to your current live TFS is not set new cloned configurations.

Run the readiness checks.

Configure the TFS instance.

Check if SharePoint is connected to the live TFS server SharePoint instance. If so remove it immediately. Then you can configure SharePoint for new instance, with new SharePoint server.

Check the SSRS reporting is referring to the cloned server. In case if it is connected to live TFS server reporting instance make sure to remove it and connect to the cloned server reporting services.

You have to stop the jobs running for TFS reporting and rebuild the reporting warehouse to make the TFS reporting properly working with the cloned instance.

As the last step you should remove all lab management configurations from the cloned TFS collections. to do this you can run TfsConfig.exe lab /delete /collectionName:collectionName . It might give error below if SCVMM (System Centre Virtual Machine Manager) Administrator Console, is not available in AT.

TF255384: Team Foundation Server could not find a supported version of Virtual Machine Manager Administrator Console on a logical application tier server. Confirm that SCVMM Administrator Console is installed. Then try the operation again.

Download SCVMM 2008 R2 or any other version of SCVMM stated in the error message. SCVMM 2008 R2 available here. Then run the setup and install Admin Console.

After installation done run TfsConfig.exe lab /delete /collectionName:collectionName command for each of the collection in the cloned instance.

You should have your cloned TFS instance running simultaneously with your live TFS.

TFS 2018 RC1 is now available and you can download it from https://www.visualstudio.com/downloads/. Release note here explains the new features you can expect in TFS 2018. Below features are going to be removed from TFS with this version.

• SharePoint Extensions
• XAML Builds
• Team Rooms
• Lab Center and automated testing flows in Microsoft Test Manager support

Requirements for TFS 2018 can be found here.  Let’s look at the installation experience with TFS 2018 RC1 on Windows 2012 Server with SQL 2016 SP1.

Install SQL 2016 SP1 and reporting services should also be configured in native mode.

Download and install TFS 2018 RC1, setup will show below error on Windows Server 2012.

The .NET Framework 4.7 installation (required by this version of Team Foundation Server) cannot continue because of a missing update. Install the update from https://go.microsoft.com/fwlink/?LinkId=854151 (https://go.microsoft.com/fwlink/?LinkId=854151) and then try installing Team Foundation Server again.

To fix this required to install an update to windows. Go to the https://go.microsoft.com/fwlink/?LinkId=854151 and get the update by clicking on the link “The .NET Framework 4.7 installation is blocked on Windows 7, Windows Server 2008 R2 and Windows Server 2012 because of a missing d3dcompiler update” (https://support.microsoft.com/en-us/help/4020302/the-net-framework-4-7-installation-is-blocked-on-windows-7-windows-ser)

Then click download link (http://go.microsoft.com/fwlink/?LinkId=848160)

Install Update for Windows (KB4019990)

After install no restart needed to the machine you can now rerun TFS setup.

After setup completed restart the machine. Then let the TFS configuration wizard to run when prompted. Select Configure Team Foundation Server and click Start Wizard.

Proceed to next step.

Select new Team Foundation Server deployment and click Next.

Select start trial check box and click Next.

Go with New Deployment – Advance option.

Select the preferred language and proceed.

Specify the SQL Server instance and click Next.

Provide a service account or use system account NT AUTHORITY\NETWORK SERVICE and click Next.

You can edit the setting and add FQDN if required.

Select to install and configure search and provide a service account for search service or use system account NT AUTHORITY\NETWORK SERVICE.

Select check box to Configure Reporting services for TFS.

Populate reporting services URLs from the installed reporting services.

Verify analysis services are running.

Provide a service account for report reader account.

Specify a collection name or leave it with DefaultCollection (default collection name).

Review the settings and click on Verify for readiness checks.

Java Runtime Environment (JRE) is required for Search service, error will be shown. Select the check box to download and install it with the setup and click on Configure.

Java runtime downloads and installs for search service, but configuring fails at Search Service, if you have specified an account other than NT AUTHORITY\NETWORK SERVICE as the service account for the search service.

[Info   @07:14:13.319] Adding JAVA_HOME to the environment of child process, value: C:\Program Files\Microsoft Team Foundation Server 2018\Search\Java\jre1.8.0_144
[Info   @07:14:13.319] Process starting: fileName=cmd.exe arguments=service.bat start
[Info   @07:14:16.203] Process finished: fileName=cmd.exe arguments=service.bat start exitCode=0 in 2883 ms
[Info   @07:14:16.203] Failed starting 'elasticsearch-service-x64' service
[Info   @07:14:16.205] Waiting for Elasticsearch operation to complete...
[Warning@07:14:16.216]
Exception Message: Elasticsearch operation was timedout. (type ElasticsearchOperationTimedoutException)
Exception Stack Trace:    at Microsoft.TeamFoundation.Admin.Search.ElasticsearchInstaller.<>c__DisplayClass3_0.<Start>b__0()
    at Microsoft.TeamFoundation.Admin.Search.ElasticsearchInstaller.<>c__DisplayClass5_0.<InvokeServiceBatCommand>b__0()
    at Microsoft.TeamFoundation.Common.RetryManager.Invoke(Action action)

[Info   @07:17:16.206] Adding JAVA_HOME to the environment of child process, value: C:\Program Files\Microsoft Team Foundation Server 2018\Search\Java\jre1.8.0_144
[Info   @07:17:16.206] Process starting: fileName=cmd.exe arguments=service.bat start
[Info   @07:17:18.442] Process finished: fileName=cmd.exe arguments=service.bat start exitCode=0 in 2236 ms
[Info   @07:17:18.442] Failed starting 'elasticsearch-service-x64' service
[Info   @07:17:18.443] Waiting for Elasticsearch operation to complete...
[Warning@07:17:18.443]
Exception Message: Elasticsearch operation was timedout. (type ElasticsearchOperationTimedoutException)
Exception Stack Trace:    at Microsoft.TeamFoundation.Admin.Search.ElasticsearchInstaller.<>c__DisplayClass3_0.<Start>b__0()
    at Microsoft.TeamFoundation.Admin.Search.ElasticsearchInstaller.<>c__DisplayClass5_0.<InvokeServiceBatCommand>b__0()
    at Microsoft.TeamFoundation.Common.RetryManager.Invoke(Action action)

As confirmed by Microsoft support this is due to a bug in TFS 2018 RC1 and options to setup search for TFS are as below as per the instructions by Microsoft support.

“There is a bug in TFS 2018 RC1, which causes this failure when search service is configured to run under account other than NT AUTHORITY\NETWORK SERVICE. The issue will be fixed in TFS 2018 RC2. For now, you can either use NT AUTHORITY\NETWORK SERVICE or configure search after you configure TFS.”

With this information letting the search service configure with NT AUTHORITY\NETWORK SERVICE worked fine. Or first configuring TFS 2018 RC1 without search and then configuring search for TFS with other domain service account or NT AUTHORITY\NETWORK SERVICE works fine as well.

Without search service configuring TFS.

Then Search service can be configured by selecting Search tab in TFs admin console and clicking on configure installed features. Select Configure Search in the Configuration Center and Start Wizard.

You can select to download install JRE if not already installed in the server.

In the settings now you can specify NT AUTHORITY\NETWORK SERVICE or other domain account as the service account for Search service. Both works fine if you are configuring Search service after configuring the TFS.

Let’s explore new features and improvements in TFS 2018 in next posts.