Wasting Time – Ale, music and enjoying life.
A current annoying quirk it seems. Adding a task through the marketplace and installing to the correct organisation. Going into the pipeline and then attempting to add this task shows the task as “installed” but little else – I’m unable to add the task.
A few months back my OneDrive app suddenly refused to sync files and after about 5 seconds of launching would error with 0x8004def4.
Add yourself a User account for the FTP user. Go through Server Manager > Tools > Computer Management > Users and Roles and add yourself a User. Ensure this user has read write permissions on the folder you’re intending to use for your FTP.
Connect to your VM go through the usual Server Manager > Add Roles and Features > IIS enable FTP services here.
Under IIS click on the FTP site > FTP Firewall support add a IT range in here. I went with 9000-9999. Go with your public IP of your VM (top of your RDP session or back into Azure portal to grab it) for the External IP Address of Firewall.
Stay in IIS navigate up to your root/global server settings click on FTP Firewall Support at this global level and enter the same port range as above. Leave the External IP Address of Firewall blank.
Into the Azure portal. Click on the VM in question and into Networking. Add an Inbound Port Rule. Lets call it FTP and for Source port range enter *. Give it 21 for destination. TCP as the protocol.
Add another Inbound Port name it FTPData giving it 9000-9999 for it’s destination port and * as Source. TCP again.
Fire up Filezilla or similar and connect to the IP with the username and p/wd as configured earlier for the FTP user select Passive as the transfer mode.
Obviously, you might want to secure the FTP connection. I’m leaving this open for now as I’ll be addressing the security concern in another post which I will talk about Vnet to Vnet Peering. Stay tuned!
Typically you might get a user permissions issue when attempting to upload to the FTP site. Most likely the user won’t have the correct folder permissions. Hop back onto the VM, right click on the FTP folder > Security and add the ftp user to have read write permissions.
Ensure FTP is sound locally on the VM by firing up a command prompt on the VM itself and ftp to localhost via “ftp 127.0.0.1”.
Also bear in mind that if you’re making changes to the FTP settings under IIS you will probably need to restart the “Microsoft FTP server” service.
Here I simply span up an Azure VM and installed Visual Studio Build Tools. It makes life a little easier if you install the dev tools you need first before installing the agent as the agent service will need restarting each time a new set of tools are installed. You can check installs under the Capabilities section of the agent.
Head over to your Azure DevOps and select Pipelines > Deployment Groups > Pools then create a new Agent Pool. Once you’ve created your Agent Pool click on the “Download Agent” button. Connect back to your VM. Create yourself a agent folder “C:\Agent” unzip the contents of the downloaded agent to this folder. This is now effectively your build agent folder. Run the config command and run through the prompts – pretty much default for everything. Ensure you run the agent as a service. Once complete you’ll now have an agent configured along with the subfolder “_work” etc for the build files and process.
Now that the Build server is up and running you may wish to specify certain builds to use that server. The easiest option is specifying the Agent Pool on the build. You can also fine tune specific agents under the “Demands” section under the Build options.
Agent.Name equals MyNewAgent
or
Agent.ComputerName equals MyNewBuildServer
If your build gets stuck at “Waiting for the request to be queued” it’s very likely that you don’t have the capabilities set on the build server.
Sqlcmd –S <server>\<instance> -v <variablename>=<variablevalue> -i <sql script to run>.sql
So…
Sqlcmd –S localhost\myinstance -v databasename=mydatabase -i myscript.sql
