A friend of mine was having issues connecting to a couple of VMs that he provisioned using an ARM template. The template worked perfectly until he added the JSON block to add an NSG.
Every time he started a deployment with the NSG block in the ARM template, he wouldn’t be able to connect to the VMs in any way. The fun fact was that even deleting the NSG didn’t solve the issue, so he had to recreate the whole environment from scratch and trust me that took a while 🙂
So what was the problem, you may ask?
He was using a source TAG Internet which for some reason (I still haven’t figured this one out), killed the connectivity on the VMs on both sides (Private and Public IPs) and funnily enough, the logs didn’t show anything.
If you encounter a problem like this one, double check your NSG blocks to not have sourceAddressPrefix: Internet but sourceAddressPrefix: *
"description": "Allow RDP Connections",
"description": "Allow RDP Connections",
So far I haven’t been able to reproduce it, and I’m still looking into what’s causing the issue for that particular ARM template but if you encounter something similar, give it a try and let me know your findings 🙂
Have a good one!
Happy New Year!
For me this is a great start of the year as I’ve just received an e-mail from Microsoft, announcing me that I’ve been awarded the Microsoft Most Valuable Professional award in the Microsoft Azure category!
With this occasion, I would like to thank my good friends and colleagues, Tudor Damian and Mihai Tataran for supporting me to achieve this goal.
Great start of a year, hope the next one comes with the same awesome news 😀
With that being said, happy new year again, and as always have a great one!
LE: Added pics!
I’ve been working on migrating customers on-premise e-mail solution to Office 365, so they could benefit from all the goodness that Office 365 offers, we encountered some issues that we couldn’t find in the official documentation. By reading the migration documentation – IMAP Migration Documentation – we thought that we planned every black scenario that could happen, but Murphy’s law happened and we faced some dreadful issues.
In this blog post, I will write about what I encountered during an IMAP migration of a Zimbra on-premise e-mail solution and what you guys should consider if you ever do an IMAP migration of a non-documented e-mail solution.
Virtual network peering is a new mechanism in Azure Resource Manager that allows two virtual networks from the same region to be connected through the Azure backbone network. From a connectivity standpoint, this mechanism allows virtual machines in separate virtual networks to communicate with each other using private IP addresses. In this post, I will talk about what Virtual Network Peering is and how we can use it.
In a previous post I was talking and demonstrating how to create Custom Role Based Access Controls which could be tailored comply with a company’s requirements. Another company requirement is compliance regarding data governance. Say you have one or multiple Azure Subscriptions and one of the company policies is that nobody should be able to create Azure resources outside a specific region. Some / all of the company’s contracts have a mandatory clause that all the data they produce and keep in the cloud should only reside in a specific geographical region. Microsoft has gone to great lengths to ensure that their cloud services (Azure or Office 365) comply with national, regional, and industry-specific requirements governing the collection and use of individual’s data.
I’ve received an e-mail two weeks ago from a frequent reader of this blog that he started a PowerShell User Group here in Bucharest and I’m pleased to announce that I will be attending this meeting and I will be presenting a session about building your datacenter with PowerShell DSC.
The event will take place on the 25th October 18:30 at Cegeka Academy (Location). So if you’re interested, you can join the meetup group PSUG Bucharest Romania and come join us for some PowerShell 🙂
Here are the details of the event:
This is going to be the first meeting of (what I hope) is going to be a great sequel of great meetings for all PowerShell enthusiasts.
We are going to debate on the agenda for our next meetings, based on the input of our members, but this will definitely include: DSC, JIT/JEA, Pester, PowerShell for GUIs, crazy PowerShell (creating all kinds of applications with our favorite tool).
We’ll also have the pleasure of welcoming in our midst a great presenter, Florin Loghiade (https://www.florinloghiade.ro/about), who will help us discover the world of DSC with his (introductory) talk “Building and Managing your Virtual Datacenter with PowerShell DSC”.
No cost to attend the meetings! Please join and have an amazing time!
Please look for us also in the calendar of the very popular powershell.org site: Events on powershell.org
See you there!
In a previous post I talked about Operations Management Suite aka Log Analytics and how it can help you achieve a better understanding of what’s happening on your on-premise and cloud resources. In this blog post I will show you how to enroll your Azure VMs in OMS.
A friend of mine recently started working with Azure and loved it once he got the hang of it. I encouraged him to start using PowerShell to automate various Azure operations but it didn’t quite stick with him on the first try. He started automating Azure operations using the Azure CLI and while it’s not a bad tool, it’s quite lacking in features compared to PowerShell and I’m pretty sure that it will not be maintained much longer since Microsoft open sourced PowerShell and gave the Linux / Mac community a taste. The funny part of this story is that he’s a Windows user, uses Windows 10 and yet he’s still using Azure CLI.
Where am I going with this? While giving him some tips on how to deploy some production / staging environments in Azure, I saw how he was automating resource creation in Azure using the CLI. He basically created a golden image in a storage account and with 35 lines of Azure CLI code, he was provisioning the environments. That made me cringe and motivated me to teach him how to do it using ARM templates and custom scripts.
These days I was doing some Azure work for a customer and I was asked if it was possible to create multiple custom RBAC roles for their Azure subscription because the existing ones don’t suit their needs. So I rubbed my hands together and said to client that’s a definite yes and to let me know the requirements so I can start working on the new roles 🙂
I’m writing this short post because of a small issue that can occur when you’re using hosted agents in your Visual Studio Team Services instance. The problem is that the Azure PS version on the agents is quite old; v.1.3.2 OLD. Which means that if you’re like me and update all your modules on a daily basis you will surely have Azure PS version 2.0.x which has a lot of breaking changes between versions.
One of those breaking changes is the way you can create a Storage Account.
The V2 command version looks like this:
New-AzureRmStorageAccount -ResourceGroupName $ResourceGroup -Name $StorageAccount -SkuName Premium_LRS -Location $Location
Looks pretty normal right? Here’s the V1 version of the cmdlet:
New-AzureRmStorageAccount -ResourceGroupName $ResourceGroup -Name $StorageAccount -Type Premium_LRS -Location $Location
See the difference? No? In version 1 if you wanted to provision a spindle based or SSD based storage account, you had to type in the parameter -Type, parameter that was later changed in V2 with -SkuName.
So why I’m writing this blog post? Because if you use develop scripts on your local workstation and you have the latest version of the Azure PS cmdlets and then use that script in an Azure PowerShell task in VSTS, you will get a very very nice error saying that the SkuName parameter was not filled. Now go look at the cmdlet and figure it out. In my ignorance I forgot that the Visual Studio Team Service team that manages the hosted agent images didn’t update the PowerShell version / Azure PS version on the machines and that wasted 30 minutes of my time.
Please be aware that if you’re writing PowerShell scripts that are to be later used in VSTS tasks, TEST your scripts in a PowerShell 4 constrained instance. The agents are not using the latest and greatest version of WMF5 nor the latest and greatest Azure PowerShell cmdlets.
Sometimes working with the latest and greatest isn’t always a good thing 🙂