28 December 2025

What’s your MAC?

You find yourself talking to your network administrator and they need to know what your Windows machine MAC address is. Your device might be blocked, or they are helping you troubleshoot some layer 1 issue… How do you quickly find, fetch, and retrieve your MAC address?

I’m sure some of you would dive into your device properties, find your network adapter, and start looking at it’s hardware properties. Some of you would run an “ipconfig /all” and then look through that text dump to grab your physical address. Others would go through ‘Windows Settings’ or the ‘Control Panel’ or use PowerShell or other similar methods to find it.

Yes, there are many ways to find it. But there is only one truly quick way to grab all of your Windows Device’s MAC addresses. You are just going to open your terminal, it doesn’t matter if your preference is Command Prompt or PowerShell, and run the “GetMac” command. This will pull up every MAC address on your device, Wi-Fi and Bluetooth. No sorting through a wall of text with information you don’t need. Just your MAC addresses as a list, table, or csv. Let take a look below. 

getmac /v

This will be the default command you use to get a verbose view of all of your MAC addresses. All at once with the connection name to make it easy to identify the desired NIC.

Variations of the command that you would use to return a list, table, or csv are:

getmac /v /FO list
getmac /v /FO table
getmac /v /FO csv

Believe it or not, this command has been around since Windows XP! Comment below if you knew that, if you have used it before, or if you are just learning about it today.

Category: Microsoft, Windows 10, Windows 11, Windows 2012/2012R2, Windows 2016, Windows 2019, Windows 2022 | LEAVE A COMMENT
24 December 2019

Office 365 – Winmail.dat

After changing over from on-prem Exchange to O365, I had one user where the recipients of their emails would receive any attachment that was sent as the “dreaded” winmail.dat file instead of the .pdf or whatever file the user was actually sending. It was intermittent however, in that some users would get the actual file and some (all external) would get the winmail.dat file.

First thing that I did was check that user was sending their mail as HTML, and not Rich-Text. After changing that value, I check back a week or so later and the user was still experiencing the issue, so it was time to dig a little deeper. After some searching online I was able to find that this was not an uncommon issue.

The issue happens because the receiver’s email client can not interpret the email message that was sent from Outlook in the Rich-Text format. When using Outlook to end an email using the Rich-Text format, a plain text copy of the email is also sent along with an attachment named winmail.dat. This ‘winmail.dat’ attachment is what contains all of the formatting, elements, and other data specific to Rich-Text email messages. This method of sending the email message is called “Transport Neutral Encapsulation Format” or “TNEF” for short.

Unfortunately, many non-Microsoft email programs can not properly open message that are received in TNEF. To fix this, we can use PowerShell to force Exchange Online to convert Rich-text messages to HTML before it sends it off. You can use the commands shown below to set the ‘RemoteDomain’ property “TNEFEnabled” to false on the Default policy.

1) Connect to Exchange Online via Powershell.

2) Get your Default RemoteDomain policy:
Get-RemoteDomain | fl *

3) Set the TNEFEnabled property:
Set-RemoteDomain Default -TNEFenabled $false
Re-run step 2 and you should see that “TNEFEnabled” is set to “False”.

Just in case… Here is how to change it back to a NULL value to undo your change in step 3, and let the Outlook client again decide how it wants to send the message.

4) Set the TNEFEnabled property back to NULL:
Set-RemoteDomain Default -TNEFenabled $nul

Category: Microsoft, Office | LEAVE A COMMENT