This month Microsoft held their Inspire conference for Microsoft partners. It looked like it was going to be the location of a partner rebellion, but Microsoft relented and let something else shine bright.
The first story I want to talk about was the big Azure story of the year so far. I have worked in the Microsoft partner world for most of my career. In my previous job, I spent over 4 years encouraging Microsoft partners to develop Azure practices. Most of those partners work as managed services providers (MSPs), companies that are effectively the IT department for their customers. Because of the way that Azure was developed, those companies faced some logistical blockers for providing smooth managed services to their customers that were using Microsoft’s cloud service.
Azure was developed with the tenant as a hard boundary, unlike Office 365 where a form of delegated administration has been available for years. If you were not a part of a customer’s tenant then you could not see or manage it. The addition of guest users made it possible for a partner to add their users to customer tenants but it’s a messy process – each operator/engineer must be invited, accept the invitation, be added to a group, and the group granted permissions to the customer subscriptions. Changes to staffing would require each customer to be modified to reflect the changes.
Microsoft decided to change this based on lots of feedback – not to mention that Microsoft partners are responsible for most of Microsoft’s revenue. Azure Resource Manager (ARM) was modified to enable users/groups from an external tenant to have specified rights to a “customer” tenant. In other words, I could put all of my operators/engineers into a group and grant them access to a customer’s subscription via that group. And here’s the best bit – once I do that, they can see every customer in the Azure Portal and use tools like Azure Monitor or Security Center to manage all customers through a single pane of glass (drink a shot!).
This new feature is called Lighthouse. While all the blurb refers to MSPs the feature can also be used internally by customers who have deployed multiple tenants; IT in a central tenant can manage internal customers from a central point.
Lighthouse can be implemented in one of two ways:
I cannot overstate how important Lighthouse is, and how it will facilitate MSPs to do more for their customers.
Sometimes when you deploy a multi-tiered service you need to minimize the levels of latency at the expense of availability. For example, you might want to place virtual machines as close together as possible in a single data center (remember that a region is multiple data centers) instead of spreading the machines around different data centers in the same region.
Proximity placement groups (PPGs) allows you to group virtual machines, availability sets or virtual machine scale sets (VMSSs) close together in a single facility. Architecturally, each tier of the service is an availability set or a VMSS deployed in a single PPG. When combined with Accelerated Networking (for supported virtual machine sizes) you can use close placement and hardware acceleration to reduce network latency between the virtual machines and service tiers to the lowest possible levels.
Ping and tracert, two tools based on the ICMP protocol, might have lower values in a software-defined network such as Microsoft Azure, but you’d be amazed how many times I encounter server and network admins who want to use these tools instead of using Azure’s Network Watcher. And to be fair, when I have guest OS access to a customer’s machines, tracert can be a handy tool to help me start my troubleshooting.
Note that many “devices” in a software-defined network, such as the default gateway in an Azure subnet or an Azure load balancer, don’t actually exist and are just functions of the underlying fabric. Therefore, these “devices” cannot respond to a ping. And ICMP has been blocked by default for a long time in Windows Server, but many don’t realize that because they have legacy Active Directory group policies that disable the Windows Firewall!
The most basic form of network security we have in Azure is the Network Security Group (NSG). No matter what design of firewall you implement, it should always be supported by NSGs. However, NSGs, up until this week, only supported three protocols:
If you wanted to create a locked down subnet then you had to use the Any protocol to allow ICMP. But that has changed. A fourth option now exists: ICMP. Now you can explicitly allow (or deny) ICMP traffic in your NSGs.
Here are other Azure IaaS headlines from the past month:
In the Microsoft world, July is the month of partnership. In my opinion, a partnership is a 2-way deal where there should be give and take on both sides. A month ago, news broke that Microsoft was once again trying to squeeze down what they give in the relationship with their partners:
The feedback was almost universally bad – anyone who understood the impact of the above items on their businesses spoke out. And I heard from partners that had started to investigate switching to non-Microsoft services because of the above decisions. That damage is done.
Microsoft representatives danced verbally, the way that bad politicians do when faced with tough questions. A leak revealed a financial cost of providing IURs to Microsoft partners and it was a burden. Every business has a cost of sales – maybe this was Microsoft part of the 2-way relationship that allegedly generates over 90% of Microsoft’s revenue?
The tech media caught wind of the announcements and feedback … and then something happened. A video where Microsoft answered the questions disappeared from YouTube. Conversation stopped. Maybe this had something to do with the awful timing – changes like this are announced at Microsoft’s financial year-end (June) and a week later is Microsoft partner conference, Inspire, at the start of the next financial year. I guess that Microsoft executives did not want to be drowned out by boos during their “core note presentations” (what are normally called keynote presentations) because Microsoft reversed each of the above announcements.
The wording was interesting. It suggested that Microsoft would rework the announcements in the future, but for now, support calls, IURs, and CSP resellers statuses are safe.
One other change didn’t make the headlines because it’s too esoteric. One channel of CSP (called Direct and previously called Tier 1) will have a new annual requirement. When Microsoft launched CSP, they intended Direct to be a small number of large partners – they didn’t want to have direct relationships with a large number of partners (they manage this number by designating partners as managed partners). Instead, they wanted the other partners to go through the channel: distributors who were CSP Indirect partners. But someone forgot to restrict the application for CSP Direct reseller status and just about every registered partner could sign up. The result is that Microsoft has a higher cost to manage lots of smaller resellers who are doing small amounts of annual trade. Last year, Microsoft introduced process and support contract requirements for those Direct resellers, trying to move them to the Indirect channel where the distributor is responsible for the relationship, not Microsoft. This year, Microsoft is introducing a requirement for $30,000 of annual revenue to those partners; those that do not exceed this target will be forced to move to the Indirect channel. You can guarantee that this number will increase year-on-year until Microsoft has reduced the number of Direct partners to a level that they feel comfortable managing directly.