Hey everyone! I’ll be kicking off the start of 2019 with some exciting news! I am now officially the newest member of the Pittsburgh VMUG Leadership Team! Though I’m technically the rookie of the group, I’ll be helping the other leaders plan meetings, find venues, coordinate food and drink, find presenters, find sponsors, and of course, set the meeting dates (among other things). I know I’ll need quite a bit of guidance at first, but I also know I have a great team that’s here to help!
So why did I want to become a VMUG Leader? Years ago, when I first started coming to these meetings, I was just as an attendee looking to learn what I could from others. Over time, I kept seeing familiar faces and began making friends. Then in October 2017, I was finally convinced to give a community presentation about how I learned PowerCLI. That changed everything! After that talk, I wanted to:
Get even more involved in the vCommunity
Share even more knowledge and experiences with others
Help others overcome fear presenting in front of others
Help others grow and excel in their careers
Attend other VMUGs outside of my region to learn more and meet others
This script is an idea that spun off of my previous post, PowerCLI: Find UEFI-Enabled VMs. If you’re preparing to enable Secure Boot in a VMware environment, it may be helpful to identify the VMs that cannot be upgraded. As you might recall, enabling secure boot requires the following:
With all the news regarding the Spectre and Meltdown CPU vulnerabilities over the past several months, there’s been a greater focus to get VMware virtual machines to virtual hardware version 9 or higher, as noted by Andrea Mauro’s post regarding these vulnerabilities. In addition to that, several companies and organizations may be looking to enable Secure Boot, a feature first introduced with vSphere 6.5. However, in order to enable secure boot, the virtual machine needs to be configured with both EFI boot firmware AND be on virtual hardware version 13 or higher.
If you’ve been following the news, there was a recent phishing scam going around that was involving a number of Google Docs users. (If you’re not familiar with this story, check out this post by US-CERT). Fortunately, I didn’t receive that phishing attempt message myself.
However, there now seems to be a similar phishing attempt going around, but this time it involves Dropbox. A number of sites have stories on the Google Docs scheme, but as of this writing, I haven’t seen very much involving this particular Dropbox scheme. In the email I received, there were a couple of giveaways that stood out to me:
I wasn’t expecting any sort of shared document from the sender. Even though she’s in my contact list and is someone I do communicate with, it wasn’t something we had previously discussed.
This one is probably the most obvious, but the From: and To: email addresses were the same. Even though I received the email, MY email address wasn’t listed in the To: field.
It was sent to the wrong email address. Although this email address was once associated with Dropbox at one time, it isn’t any more. If this was legit, it would’ve gone to another email address.
If I hovered over (not clicked) the “Secured Document” link, I could clearly see that it wasn’t going to a Dropbox URL.
At this point, it was pretty obvious to me that this was an attempted phishing email, but I even reached out to the “sender” of this email to see if she had sent it. Her response back made it clear that she hadn’t sent this out.
Here’s a screenshot of what the email looks like. Remember to stay vigilant and question emails like this, especially when it’s not something you were expecting to receive!