Posted by lee jones on Apr 6, 2017 in Azure, Cloud
I recently hit a minor road-block when attempting to link a VSTS account to an Azure account to do automated deployment upon checkin to a given branch. For some reason Azure simply would not “see” my VSTS account and therefore projects from the portal. After a little bit of searching online I found and followed this article on the Kudo blog. Specifically it states that you need to be at least a project administrator, it must be GIT source controlled project and you need to check if you can create service hooks (to validate the given permissions). All of these were fine so I continued searching. I then stumbled upon this article which solved the problem for me. It seems you also need to be the project OWNER, which I was not. Thankfully, changing ownership is a doddle so I switched owners using the details in the post I just linked to and it still didn’t show up. Finally, I switched back to the old azure portal and tried linking my accounts there. Voila! It worked. Why the new Azure portal couldn’t see the VSTS account I don’t know, but as soon as they were linked in the old portal everything started working in the new one. It seems we may be stuck with two portals for a little while...
Read More »
Posted by lee jones on Nov 16, 2016 in Asp.net, Azure, Cloud
If you deploy a single project asp.net core application to azure everything is about as smooth as it could be. A typical workflow would be to simply create a new web app, set the deployment source (e.g. your git repository) and everything is up and running in a few seconds. If, however, your solution contains multiple projects, how do you specify which project is deployed? Previously this would be done using Azure deployment scripts, but this is a needless effort for such a small task. Just look at the wiki for details on why you may want to avoid this. The preferred way is to specify an Application Setting in the Azure portal. The advantage of this is that you have no deployment code checked in to your source code repository and you can more easily toggle active projects both without deployment and between deployment slots. To do this we need to go to your web app in the portal, click App Settings and create a new App settings key called PROJECT with the path to your project file: However, while this works well with full .net framework applications that use .vbproj and .csproj solutions, at the time of writing asp.net core applications still use the soon-to-be-obsolete .xproj system. If you point your app setting to an xproj, you’ll get an error message in the console. A workaround to this is to update the setting to point to the directory of the solution you want to deploy, relative from the root of your source code repository. In .net core land, this is likely to be along the lines of [Solution name]\src\[project name]\ 1 [Solution name]\src\[project name]\ And you can verify this using the very, very handy console (found under development tools in your web app service list). Open the console and cd ..\repository 1 cd ..\repository and from there traverse your way to your folder containing your xproj. Copy that path (from repository onwards) and use this as the app setting: Redeploy your solution, and you should be up and running with your chosen project. Another benefit… Another nice benefit of this approach is that if you use deployment slots, you can toggle projects per deployment slots, making it exceedingly quick to switch projects just by doing a slot-swap in the...
Read More »
Posted by lee jones on Dec 30, 2014 in Azure
This post is a quick instruction on how you can enable the RDP protocol in an Azure linux instance. Why would you want to do this? Well, although you’ll probably want to SSH into the box for the majority of times, there are instances where GUI access is handy. If, like me, you like to consolidate all your RDP session (I personally use the excellent mRemoteNG ) then having this enabled is useful. Thankfully, getting RDP working on an Azure Linux instance is trivial. In my case, I’ll be using Ubuntu 14.04: Update apt-get to make sure your sources are up to date. If you don’t do this then you’ll get 404 errors in the next step sudo apt-get update 1 sudo apt-get update Once your repository is fully up to date, you can install a desktop. I’ll stick with the default, Ubuntu Unity. I’m not a massive fan of Unity but given the little time I’ll spend in here, it will suffuce. sudo apt-get install Ubuntu-desktop 1 sudo apt-get install Ubuntu-desktop This will take several minutes, so go make a coffee. Once you have a desktop environment installed, you can enable RDP: sudo apt-get install xrdp 1 sudo apt-get install xrdp The last thing to do is to open the RDP port on the Azure firewall. By default it isn’t enabled, so log into the Azure portal, select your Linux VM, go to the endpoints tab and add RDP to the list of open endponts Virtual Machines > Your Linux Box > EndPoints > Add > Add standalone Endpoint > Remote Desktop 1 Virtual Machines > Your Linux Box > EndPoints > Add > Add standalone Endpoint > Remote Desktop Once that is done and the Azure configuration has been applied, you should be set to...
Read More »
Posted by lee jones on Jul 13, 2014 in Asp.net, Azure, Cloud
I recently had a problem whereby I couldn’t view failed request trace logs on an Azure hosted VM. The XML would open, but the XSLT wouldn’t be applied which made the page unreadable. My first thought was that freb.xsl file was missing or corrupt somehow, but after deleting the containing IIS log folder, which causes IIS to regenerate the file it was clear this wasn’t the fault. After a bit of digging I came to the conclusion that it must be permissions based and stumbled upon this post. Even though I wasn’t getting the content blocked error message, the default internet security settings on azure VM’s are set to high. Therefore, to resolve this you (rather bizarrely) need to add the about:internet page to the trusted sites list: Internet Options Security Tab Click Sites Enter about:internet in the ‘Add this website to the zone” text box and click the add button Close IE and re-open the trce log XML I’m not really sure why about:internet specifically fixes this, but it worked for...
Read More »
Posted by lee jones on Feb 5, 2014 in Azure, Other
I recently had the need to run some PowerShell scripts against a new VM created in Windows Azure using PowerShell Remoting. I thought this would be a simple enough job (and in truth, it is), but you need to know a couple of things. By default, PowerShell uses active directory to identify and authenticate users, but of course standalone Azure VM’s aren’t part of a domain. Therefore you’ll need to add the public IP address of the VM to the trusted hosts on your client. From the Azure portal, open port 5985 for PowerShell (the portal should open 5986 by default). To do this, go to: Virtual Machines > YOUR VM > Endpoints > ADD. Complete the resultant dialog: From the client machine, start PowerShell and type Set-Item -Path WSMan:\localhost\Client\TrustedHosts -Value '11.22.33.44' 1 Set-Item -Path WSMan:\localhost\Client\TrustedHosts -Value '11.22.33.44' Obviously substituting the IP address of the Azure VM you obtain from the Azure Portal If you already have trusted hosts, use –Concatenate to avoid overwriting the others. To be sure, Get-Item -Path WSMan:\localhost\Client\TrustedHosts 1 Get-Item -Path WSMan:\localhost\Client\TrustedHosts Should show you the entry you just created. Now, to connect to the Azure VM and start the PowerShell session: Enter-PSSession -ComputerName 11.22.33.44 -Credential 11.22.33.44\USERNAME 1 Enter-PSSession -ComputerName 11.22.33.44 -Credential 11.22.33.44\USERNAME Substitute in the username you created in the Azure portal when creating the VM (or any user you’ve since set up on the box with the relevant permissions) and you should be presented with a login box to confirm the password. Once that is done, your PowerShell session should be active. Happy...
Read More »
Posted by lee jones on Jan 21, 2014 in Azure
I recently ran into a problem creating a storage account using PowerShell. The rather obscure error I was getting was: New-AzureStorageAccount : Specified argument was out of the range of valid values. 1 New-AzureStorageAccount : Specified argument was out of the range of valid values. After lots of digging about coming up blank at the likes of Bing, Google and Stack Overflow I worked out the root cause – the name I was using for the storage account exceeded the 24 character length imposed by Azure! Simple error that I should have spotted, and attempting to create that environment in the portal surfaced the underlying cause immediately, but error messages like this really do not help. Nothing like a helpful error message is...
Read More »
I'm a gadget loving code-junkie who loves to program, create websites and try out new stuff. Married, with two young daughters I am also a keen marathon runner and fitness enthusiast.