Identify which wireless access point you are connected to

Sometimes you want to know which wireless access point (AP) you are connected to. From a Windows laptop you can do this by running the following command

 netsh wlan show interfaces

In the output, look for the BSSID, which will be in the format of a MAC address. Then look for this ID either on the AP itself, if you are able to physically access it, or via whatever wireless controller software you use to manage your APs.

You Build It, You Run It

A key tenet of the agile, DevOps-focused project-to-product transformation mindset is the concept of "You build it, you run it". That is, if you and your team were responsible for creating the thing, typically a bit of code in the DevOps world, the same team needs to be responsible for running it on a day to day basis. This probably works in the case of software, due to the way most of the "running" can be automated and therefore also turned into code. "Running" the code then simply involves a continuous improvement of that code, to be self-reliant and resilient. It would make sense for the team who know the core code, i.e what was "built", to also be intimately acquainted with the peripheral code, i.e. the code around the outside that automates the "running" of the core code, making it more resilient and reliable.

However, how does this idea translate into less automated products? Traditionally, highly skilled teams will build a product and leave the running, along with some heavy documentation, to an often lower skilled team of individuals. The highly skilled teams are your "developers", whether or not it is software they are developing. The teams left to do the often relatively mundane running tasks are your "operators". DevOps seeks to bring these development and operations teams together, hence "You build it, you run it." Can we translate that model into more traditional products, or does the success of the "You build it, you run it" concept depend heavily on whether or not running the product can be automated?

Can we keep our highly skilled developers involved in the sometimes mundane running of their products, without risking boredom and frustration? Perhaps it is this very boredom and frustration that inspires them into continuous improvement of the products. This might be wishful thinking.

Even better, how do we up-skill our operators to a level where they can further develop the products they are responsible for operating? This feels like a more uplifting path.

Product Management - Making Everyone's Day Better

I've been in a product management role for the last nine months and it has been a paradigm-shifting experience. Due to an unrelated opportunity I'll be moving on from this role, but someone who was interested in potentially replacing me, asked me what I did. This is how I, as someone who is still figuring it out myself, described it to him. A seasoned Product Manager would probably tear it to pieces, but I can only describe what I've managed to gather in a short 9-month stint.

The Work

The analogy I like use is to take a 600ml bottle of Coke. It is by no means a perfect analogy, but it helps create an initial picture.

The Product Manager's job is to weave between the following activities in any order at any time:

• Work out if the client truly wants Coke

Assuming they do

• Work out if 600ml is the optimal size (for client satisfaction, frequency of purchase, profitablilty, etc. All sorts of factors could help define "optimal")

Assuming the above are both true

• Work with the marketing team to make sure the advertising material says "600ml Coke"
• Work with the delivery (manufacturing) team to make sure the label says "600ml Coke"
• Work with the delivery team to make sure the bottle is in-fact 600ml
• Work with the delivery team to make sure the bottle is in-fact filled with Coke (few people want 800ml of Fanta, if they're expecting 600ml of Coke) 

Then

• Work out if the client still wants Coke. If yes, rinse and repeat above. 😊

If client wants "Fanta" or even just "Vanilla Coke"

This is an area I didn't get too much into, but we'd then start looking at

• Work out whether we should run the products side-by-side
• If not, work out plans for sunsetting the old product and bringing new ones online 

I think there are so many more intricate pieces to each of these items, and probably some major items missing from this list, but these are the things I had the privilege to work on.

Purpose

The purpose of all of the work above is to optimise the client experience, that is just make it awesome for them. That leads to repeat business, referrals, improved relationships, increased profitability, and so on. Ultimately, our work tends to improve the experience of everyone involved, which is potent motivation.

• The finance team find things easier to bill, as everything is well set up within the billing system.
• The sales teams find things easier to sell, as they have collateral, they know what they're selling (and what they're not), and how we can address out-of-product queries quickly and easily. Their customers are happier and therefore like them more.
• The delivery teams find things easier to deliver, as they know what is expected, what tools are available, what's included, what is not, where and how to find additional support.
• The leadership team's job is easier as they have more engaged, more satisfied staff to manage.
• Execs and owners are happier as more efficiently delivered products are more profitable (assuming we have priced right!), and staff are happier and more productive.

So you are a highly appreciated team member, which is an intense buzz.

Approach

So this is going to sound super lazy, but I found the key to the product management role was to try to do as little of "the work" as possible. This maybe more of a goal than a reality.

Your role is to inspire, delegate, excite, support. You're managing people that you have no authority over, which is a thought-provoking challenge. However, people find what you're doing so helpful that they are almost clamouring to assist. You need to get teams to own their part of the bigger picture, as much as possible. For example, technical teams need to keep technical wikis and processes up to date, the marketing team has to create the collateral, and the sales team have to engage with what has been developed to keep up to speed with what the organisation can deliver. All the while, you tie it together using various tools such as Product wikis, presentations, communications, reinforcement of consistent language, and more.

You're a conductor. A coordinator. A consultant. A facilitator.

Summary

So make the customer's experience excellent, by inspiring teams of people to make their individual pieces the best they can be in service of that goal.  

Block port 53 (DNS) in an Azure Network Security Group

At times, you may want to block all outgoing traffic from a VNet in Azure. You configure a Network Security Group (NSG) with a Deny All outgoing policy. Upon testing (because you always test...right?), you find that DNS and the Windows Licensing Key Management Service are still able to traverse the NSG.

What's up with that!?

There's actually also a third service (the Azure Instance Metadata service) that can do the same, and according to Microsoft,

Basic infrastructure services like DHCP, DNS, IMDS, and health monitoring are provided through the virtualized host IP addresses 168.63.129.16 and 169.254.169.254. These IP addresses belong to Microsoft and are the only virtualized IP addresses used in all regions for this purpose. Effective security rules and effective routes will not include these platform rules.

However, the news is not all bad. The same article states that

To override this basic infrastructure communication, you can create a security rule to deny traffic by using the following service tags on your Network Security Group rules: AzurePlatformDNS, AzurePlatformIMDS, AzurePlatformLKM

So there you have it, now you can REALLY block all outgoing traffic from your VNet. Oh wait...there still isn't one for DHCP. 🤷‍♂️

A word of warning, these services are used to provide key support to your Azure workloads, so proceed with caution.

References

https://docs.microsoft.com/en-us/azure/virtual-network/service-tags-overview#available-service-tags

https://docs.microsoft.com/en-gb/azure/virtual-network/security-overview#azure-platform-considerations

https://docs.microsoft.com/en-us/azure/virtual-machines/windows/instance-metadata-service

Azure IP Address Type Confusion

Azure throws IP addressing terms and mechanisms into a bit of a spin, and it is worth looking closely at the terminology used.

Those of us from a traditional infrastructure background remember two types of IP address allocation in earlier days:

• Static
• Dynamic

Static addresses were assigned to a network interface manually, by a server administrator. Dynamic addresses were distributed automatically, using the Dynamic Host Configuration Protocol (DHCP). There was actually a third, middle ground, called reservations. Reservations effectively ensured DHCP issued the same address to the same network interface every time, making it a dynamically configured static address of sorts.

Azure throws this into a bit of a spin for some techs, and it is worth looking more closely at the terminology used, as it seems familiar, but can mean different things to what one might otherwise assume.

So how does it work then?

At the OS level, Microsoft recommends that, except under very special circumstances, all network interfaces be set to use DHCP, so from the get-go, everything is dynamic to some degree.

At the Azure level, the terms private and public are applied, along with the terms static and dynamic.

Private IPs fall within the standard range of addresses reserved for private use:

• 192.168.0.0 - 192.168.255.255 (65,536 IP addresses)
• 172.16.0.0 - 172.31.255.255 (1,048,576 IP addresses)
• 10.0.0.0 - 10.255.255.255 (16,777,216 IP addresses)

Public IPs are basically any address outside of those ranges. There are a few other reserved addresses, but we're not going to talk about those today.

In Azure, both private and public IPs can be either static or dynamic. However, the meanings for static and dynamic are not fully consistent between private and public addresses. 

Sum It Up

Here is the low down on how each configuration works within Azure:

Private IP

Static:

• You select exactly which IP in the range you want.
• Will it change? No. It will only be given back when the NIC it is assigned to is destroyed.
• In the OS, NIC IP address is set to DHCP

Dynamic:

• You let Azure select which IP in the range you get.
• Will it change? No. It will only be given back when the NIC it is assigned to is destroyed.
• In the OS, NIC IP address is set to DHCP

Public IP

Static:

• You get whatever Azure allocates to you.
• Will it change? No. It will only be given back when the Public IP Address resource it is part of is destroyed.
• In the OS, NIC never sees this address. NAT is used to send traffic to the NIC's private IP address instead.

Dynamic:

• You get whatever Azure allocates to you.
• Will it change? Yes, potentially, but I don't remember the scenarios. I need to find out and edit this article.
• In the OS, NIC never sees this address. NAT is used to send traffic to the NIC's private IP address instead.

Conclusion

So there you have it. Azure has four main types of IP address split between public and private, and dynamic and static. Understanding the difference is important, to ensure you get the result you want and don't waste time on tasks you don't need to. Now what happens if you want to assign multiple IP addresses to a single NIC? That's a question for another post.

User Powershell Script as Startup or Login Script and Bypass Execution Policy

Use the following settings in the Login/Startup Script section of your GPO

Script Name: %windir%\System32\WindowsPowerShell\v1.0\powershell.exe
Script Parameters: -Noninteractive -ExecutionPolicy Bypass –Noprofile -file MyPSScript.ps1 -psscriptparameter1 value -pssscriptparameter2

-Noninteractive Prevents an interactive window from trying to open at any time during the script execution

-ExecutionPolicy Bypass Enables this single script to run if more restrictive Powershell Execution policies are normally applied on the target computer

-Noprofile Ensures PowerShell does not execute profile scripts and instead launches the desired script immediately in an unaltered environment

References:

http://woshub.com/running-powershell-startup-scripts-using-gpo/

https://docs.microsoft.com/en-us/powershell/module/Microsoft.PowerShell.Core/About/about_PowerShell_exe?view=powershell-5.1#-file----filepath-args

Manage the Local Administrators Group on Azure AD Joined Devices

• If your tenant users are synchronized from on-premises Active Directory, use net localgroup administrators /add "Contoso\username".
• If your tenant users are created in Azure AD, use net localgroup administrators /add "AzureAD\UserUpn"

Reference:
https://docs.microsoft.com/en-us/azure/active-directory/devices/assign-local-admin