Install and configure a TFS Release Manager Deployer Agent in Azure VM

The Problem

 

You have a domain with TFS and -release management, there are no problems deploying agents on machines inside the domain, but you are not able to configure an agent for machines outside the domain.

Es: you have some Azure VMs you want to use for your release pipeline and you do not want to join them to the domain with VPN or other mechanism.

This scenario usually ends in being not able to configure Deployment Agents in those machines due to various authorization problems. The exact symptom range from getting 401 errors when you try to configure Agent on the VM. Another symptom is being able to configure the Deployment Agent, but whenever the service starts you do not see any heartbeat on the server and in the Event viewer of VM you got error like these ones

Timestamp: 6/10/2014 6:17:12 AM
Message: Error loading profile for current user: nabla-dep1\inreleasedeployer
Category: General
Priority: -1
EventId: 0
Severity: Error
Title:
Machine: NABLA-DEP1

The usual cause

 

The most common cause of the problem is a bad configuration of Shadow Accounts and authentication problem between the machine outside the domain and the machines inside the domain. I want to share with you the sequence of operation that finally made my Azure VM runs a Deployer Agent and connect to Release Management Server.

Here is my scenario

My domain is called CYBERPUNK and the user used to run deployment agents is called InReleaseDeployer.

The machine where TFS and RM Server is installed is called TFS2013PREVIEWO and Azure VM is called NABLA-DEP1.

I’ve already the user CYBERPUNK\InReleaseDeployer added as a Service user to Release Manager, and I already used to deploy an agent for a machine in the domain with no problem.

Now head for configuring everything for an Azure VM.

The solution

 

This is the solution:

You need THREE ACCOUNTS:

  1. CYBERPUNK\InReleaseDeployer: You already have this because is the standard domain account used for Domain Agent in machine joined to your domain.
  2. TFS2013PREVIEWO\InReleaseDeployer: this is the shadow account on RM serve machine. It is a local user that should be created in the machine running Release Management server.
  3. NABLA-DEP1\InReleaseDeployer: this is the shadow account on the Azure VM Machine, is a local user on the Azure VM Machine

Now be sure that these account satisfy these conditions:

  1. All three accounts must have same password
  2. NABLA-DEP1\InReleaseDeployer must be administrator of NABLA-DEP1 machine, it must also have the right o logon as a service.
  3. All three account should be added to Release Management Users with these permissions.

Domain user should have the standard Service User flagged

imageù

Then the shadow account in the RM machine should be also Release Manager and not only Service User, here is the setting.

image

Please note that the user is expressed in the form MACHINENAME\username, so it is TFS2013PREVIEWO\InReleaseDeployer, and it is a Release Manager and a Service User.

Finally you need to add the user of the Azure VM.

image

Even for this user you need to express it in the form MACHINENAME\UserName, so it is NABLA-DEP1\InReleaseDeployer. This completes the setup of the shadow account for your RM Server.

Now it is the turn of the Azure VM so connect in Remote Desktop on Azure VM, and login with credentials NABLA-DEP1\InReleaseDeployer user, do not use other users and finally configure the agent. Before configuring the agent, open credential manager and specify credentials to connect to the public address of RM Server. You need to add a Windows Credential specifying the Credentials that should be used upon connection to the Remote Release Management Server. Be sure to prefix the user with domain specification, as in the following picture (CYBERPUNK\InReleaseDeployer).

image

You should now see the credentials you just entered.

image

Actually adding Credentials in Windows Credentials is required only if you want to use RM Client to connect to the server, but I noticed that my user had problem connecting to the server if I miss this part, so I strongly suggest you to add RM Server to Windows Credentials to avoid problem.

Now the last step is configuring the agent. You must specify Nabla-dep1\InReleaseDeployer as the user used to run the service and the public address of your Release Management Server.

image

Press Apply settings and the configuration should complete with no error.

image

Once the Deployer Agent is configured you should be able to find the new agent from Release Management Client, in Configure Path –> Servers –> New –> Scan For New .

image

Everything is ok, my RM Server is able to see the deployer on the VM even if the VM is outside the network and not joined to corporate domain. Now you can select the new agent and Press Register to register with the list of valid Deployer Agents.

image

Gian Maria.

Deploying on Azure Web sites from on-premise TFS

Many people asked me during course if the ability to automatically deploy to Windows Azure Web Sites is restricted only to those people that are using TF Service (TFS on the cloud), or if they can deploy with an on-premise installation of TFS.

The answer is clearly YES, and I strongly suggest you to watch the Continuous Deployment with Microsoft Visual Studio session of Brian Randell to have a deep explanation of all the possibilities you have to achieve automatic deployment of your applications from Team Foundation Server.

Deploying from on-premise TFS to Azure Web Site is simple, because it is only a matter of configuring msbuild to use the right publish file. The difference from an automatic deploy with TF Service is: when you publish from TF Service, the web site has a nice “deployment” tab listing all the deployment done with TF Service and a connection with Build Details, while if you publish from on-premise you loose this data and the Web Site completely ignores who and when the site was deployed.

To deploy on Azure from on-premise TFS you just need to download the publish profile of the Web Site into a local folder.

image

Figure 1: Download the publish profile

Then you can right-click your web project node from the Solution Explorer in Visual Studio and choose “publish”, from there you can “import” the file you just downloaded.

image

Figure 2: Import the publish profile

This file contains all the information needed to publish against that Web Site, you can modify as you need

image

Figure 3: Details of the publish definition.

From the list of definition (Figure 2) I usually rename the publish file to something more useful, as an example AzureDemoWebSite.

image

Figure 4: Rename your publish file

I usually modify the publication file to include publishing the database to the Azure Database, you do not need to specify the connection string of the database, it will be taken from the profile and the only piece of information that the script needs is the relative path of the .dacpac file to deploy.

image

Figure 5: Modification done to the publishing profile to deploy a database project

Now you should check-in everything and you are only one step away from publishing from azure. Just create a standard build, but instruct MSBUILD that you want to also deploy with a specific publication profile. This can be done in the Advanced section of the Build Process

image

Figure 6: Instruct MSBuild with custom Arguments to deploy the site.

The whole string is this one

/p:DeployOnBuild=true /p:PublishProfile=AzureDemoWebSite /p:AllowUntrustedCertificate=true

/p:UserName=$tailspinonpremise /p:Password=2Xocq…

The tricky part is specifying correct credentials. You can find username and password directly opening the original publication profile file you downloaded from azure. Publish file in Visual Studio or your standard Azure credential wont work. The username is usually in the form $websitename and the password is a long sequence of characters and numbers, you cannot miss it.

image

Figure 7: The original content of the publication profile, it contains the username and password that you need to publish to that web project

Now you can simply fire the build, wait for it to complete and your web site will be automatically deployed.

image

Figure 8: Build succeeded and site was deployed

image

Figure 9: Site was deployed

Publishing on on-premise IIS is quite the same, it is just a matter of creating the right publish file and use it to deploy during a build.

Gian Maria.

Continuous Deployment on Windows Azure with Database projects

I’ve already blogged about Deploying on Azure Web Site with Database Project in the past, but in that article I showed how to accomplish it with customization of the Build Template. That technique is useful because quite often you need to run custom scripts or tools to do additional deploy related procedures to the site, but if your need is simply deploying schema change to an Azure Database with a Database Project you can accomplish it even without the need to touch the Build Workflow.

First of all download the publishing profile from your azure site.

image

Figure 1: Download publishing profile from Azure Web Site

Once you have publishing profile, it can be imported in Visual Studio, just Right-Click on Project node inside Visual Studio and choose Publish. From there you can import publishing profile just downloaded and modify it for your need.

image

Figure 2: Importing publishing profile from Visual Studio

From the settings tab you have the option to specify a .dacpac file to update database schema.

image

Figure 3:  Use a .dacpac to deploy database schema changes

Unfortunately this configuration is good from direct publishing with Visual Studio, but to make it works during a TFS Build you need to do some manual modification. Once the modified publishing file is changed, you can find it inside Properties/PublishProfiles node of your project, and you can edit it with a simple XML Editor.

image

Figure 4: Modify the location of the dacpac to match the location this file will have during TFS build

The trick here is modifying the path of the .dacpac file to match its location in the build server during the build. Knowing the location is quite simple, usually I map an entire branch (trunk, main or some release branch) as root dir for the build

image

Figure 5: Workspace configuration of Deploy build

Now I need to examine the structure of project folders, suppose the trunk has a sub-folder called TailspinToys that contains my web site project I want to deploy (called Tailspin.WebUpgraded).

image

Figure 6: Folder structure of my project

When the build takes place, all build output (including all .dacpac files) are stored in a folder called bin that is one level above the folder you mapped in the build workspace. To locate the build file during publish, I need to go three folder up to locate the parent of the trunk (my project is in Trunk\TailspinToys\Tailspin.WebUpgraded) then adding bin and the name of the .dacpac file. So the location of dacpac file is ..\..\..\bin\xxxxx.dacpac as you can see in Figure 4. Do not worry if it seems complicated, it is just a matter of a couple of tentative to find the root folder ;).

Once the publish file was modified and checked-in you can use it in your build definition.

image

Figure 7: Choose your new publish file as a publishing profile for the build.

Now you can run the build and database linked to the Web Site will be automatically updated with the definition of your Database Project.

Gian Maria.

My blog moved to Windows Azure

Actually it is a few days I’ve moved my blog to Windows Azure using Web Sites, still in Preview, but really stable. The only problem with my WordPress Site, is that I’m not able to use the automatic update of plugins, due to some problem in writing on the virtual file system, but apart from this little problem (I updated my plugin with standard FTP) I’m really satisfied of azure.

Thank to the fact that I have a MSDN subscription I have a certain amount of resources available for free, because they are included in the base MSDN subscription, you can read details here.

Moving to azure was really simple, just activated a new Web Site in reserved or shared mode, upload all site content with FTP, then restore MySql database to a linked MySql database (you have 20MB of MySql actually available for Web Sites), and finally switched my dns, and the blog is now running on Azure.

image

Actually if you have a MSDN subscription, Azure is a really appealing hosting solution. PHP support is good, you can also use the WinCache as cache backend for your W3 Total Cache plugin and everything runs smooth.

image

Happy New Year to everyone :).

Gian Maria