Find Unknown Wireless Password for Aruba Wireless SSID

If you don’t remember what password you or another Administrator set for a particular SSID on an Aruba Wireless Access Controller (or Instant Access Point), you can find this by connecting to any Access Point via SSH, Telnet or Console, and running the following commands:

show run no-encrypt

Scroll up until you get to the wlan ssid-profile section, and the password will be listed next to wpa-passphrase

If you had just ran a show run without the “no-encrypt“, you would have see a random hash like this:


How to collect EMC SP NAR Data/Logs

Collecting EMC NAR Data


Login to Unisphere

Select your system from the List

Hover over System and click Statistics


 Enable Performance and Data Logging

Select box to enable Periodic Archiving
Select Box to stop after 6 or 7 days
Click Start (and then Yes/OK to following prompts, and click X to close Windows after it starts)

After the 6-7 days of running, retrieve the NAR file by doing the following:

Go back to the Statistics Page where you started the data logging, and select Retrieve Archive


 You will need to get files from both SPs, so start with SP A.
Click the files that were created during the date range you ran the logging, browse to someone on your computer to save them, and select retrieve


Repeat those steps on SP B.


After you have the files saved, I will get you an FTP link to upload them to be analyzed.

While attempting to upgrade a ESXi host from to the latest 6.x build (6.0.0.update02-4192238) via CLI (see my post here about pathcing via CLI)

I got the following error:

VIB VMware_bootbank_esx-base_6.0.0-2.43.4192238 requires vsan >= 6.0.0-2.43, but the requirement cannot be satisfied within the ImageProfile.
VIB VMware_bootbank_esx-base_6.0.0-2.43.4192238 requires vsan << 6.0.0-2.44, but the requirement cannot be satisfied within the ImageProfile.
Please refer to the log file for more details.

The exact build on the error may be different on yours, but the issue is the same. I found this KB from VMware and decided to make a post that gets right to the point: VMware KB

This error occurs because the newest version of VSAN (which is built into ESXi) is looking for a specific base hypervisor build (esx-base). In order to run the update successfully, you’ll need to define the update profile for the VIB you are using. Its actually a lot easier than it may sound.

First, lets find the software profile the VIB you will be using contains. Run the following command, pointing the destination to the .zip VIB you uploaded to a datastore on the host.

esxcli software sources profile list -d <location_of_the_esxi_zip_bundle_on_the_datastore>

It will output something similiar to this:

That Name is the Profile you will need to add to your update command.
So in my case, the update command would look like this (highlighting added for emphasis):

esxcli software profile update -d /vmfs/volumes/datastore1/ -p Dell-ESXi-6.0U2-4192238-A04

It should update and finish with no errors:

The final step is to issue a reboot command, and you are done.

vSphere 6.5 – Transport (VMDB) error -45: Failed to connect to peer process

While upgrading some Cisco UCS B200 M3 Servers from vSphere 6.0 to 6.5, I ran into an error that I could not figure out. After upgrading the first Cisco Blade to 6.5, I could not vMotion any VMs from the older 6.0 host to the newly upgraded 6.5 host. I would get the following error:

Transport (VMDB) error -45: Failed to connect to peer process

I was able to vMotion a powered off VM to the new host, but when I attempted to power on the VM, I got the same error: Transport (VMDB) error -45: Failed to connect to peer process

After poking around for awhile, I decided to turn to the VMware community, where I most mostly seeing this error with people using Workstation and Fusion products, but there wasn’t much going on with ESXi environments. I made sure to use the ESXi 6.5 Cisco Media for the original installs and this upgrade, and I assumed there had to be a driver/component issue with all of this. I tried updating by booting into the ISO and running the upgrade from there. After attempting to manually upgrade drivers and firmware, the solution that worked for me was the following:

Reinstall the freaking host from scratch! 

There you have it. Such a simple solution 🙂
Honestly, I have no idea why the reinstall was necessary. I ran into the same issue again when trying to upgrade that second host, and I even tried upgrading it using the an alternative method (Using ESXCLI and Update Manager), but no luck.

I did not call VMware Support on this, but I did submit the bug report. I would love to hear from someone who figured out the root cause and workaround.

Create Bootable VMware ESXi Installer USB Drive

Getting ESXi installed on a server today is more often done through the servers BMC (iLO, iDRAC, CMC, etc). But this guide might be helpful when installing vSphere on a standalone server. The tool of choice for any bootable USB is my friend Rufus.

There are three things you will need to do this:

  • Download Rufus Here
  • Download whatever .iSO image you want to be bootable (whether its WIndows, ESXi, or Linux).
  • Use a somewhat quality USB Flash Drive (1GB or larger). For some reason, I will run into some cheap-o thumb drives that do not boot anything. If your boot drive doesn’t work, try a different flash drive


Here are the easy steps:

  • Insert your blank (or soon to be formatted) flash drive into your PC
  • Open Rufus

  • Under Device, select the flash drive you wish to format and use
  • Select MBR partition Scheme for BIOS or UEFI
  • Filesystem = Fat32
  • Use default Cluster Size (4096 bytes)
  • Click the icon next to FreeDOS and select your ISO image
  • Rename the New Volume Label to whatever you wish to see when you insert the flash drive into a PC
  • Click Start

  • When prompted to replace menu.c32, select Yes

  • Finally, click Yes to the warning that this flash drive will be formatted (destroyed)


That’s it. It will take a couple of mins, but you should have a bootable flash drive.

System logs are stored on non-persistent storage

As customer start to deploy ESXi on smaller SD Cards or Boot from SAN, they encounter the following error after installing a new host:

“System logs are stored on non-persistent storage”

This error just indicates that you need to save your scratch logs to another location, (shared storage or local disk). The process is super easy. To change the location, use on of the following methods:

Verifying the Location of System Logs in vSphere Client

To verify the location:

  1. In vSphere Client, select the host in the inventory panel.
  2. Click the Configuration tab, then click Advanced Settings under Software.
  3. Ensure that points to a persistent location.The directory should be specified as [datastorename] path_to_file where the path is relative to the datastore. For example, [datastore1] /systemlogs.
  4. If the field is empty or explicitly points to a scratch partition, make sure that the field ScratchConfig.CurrentScratchLocation shows a location on persistent storage.

Verifying the Location of System Logs in vSphere Web Client

To verify the location:

  1. Browse to the host in the vSphere Web Client navigator.
  2. Click the Manage tab, then click Settings.
  3. Under System, click Advanced System Settings.
  4. Ensure that points to a persistent location.
  5. If the field is empty or points to a scratch partition, make sure that the field ScratchConfig.CurrentScratchLocation shows a location on persistent storage.

No image profile is found on the host or image profile is empty. An image profile is required to install or remove VIBs. To install an image profile, use the esxcli image profile install command

While upgrade an ESXi 6 host for a customer last night, I ran into the following error when trying to patch via Update Manager:
No image profile is found on the host or image profile is empty. An image profile is required to install or remove VIBs. To install an image profile, use the esxcli image profile install command.”

I tried various things such as rebooting the host, and manually patching via esxcli. (See my previous post on patching via CLI) but nothing seemed to work.

The server was a Dell R620, and after some searching, I found that it had a corrupt profile image. This can be fixed by replacing the corrupt image file and replacing with a known good one from another host. (The hosts dont have to be the same server version, but I would try to keep to same CPU families (Intel vs AMD). Here is how to do it.

  1. On the working ESXi host, copy the following image file: imgdb.tgz
    cp /bootbank/imgdb.tgz /vmfs/volumes/<An Accessible LUN>

  2.  On the corrupt host, copy the file imgdb.tgz from the working host to /tmp:
    cp /vmfs/volumes/<An Accessible LUN>/imgdb.tgz /tmp

  3. Change Directories to /tmp
    cd /tmp

  4. Extract file you just copied
    tar -xzf imgdb.tgz

  5. Copy the working profile files to the profile directory
    cp /tmp/var/db/esximg/profiles/* /var/db/esximg/profiles/

  6. Copy the working VIBs to the VIB repository
    cp /tmp/var/db/esximg/vibs/* /var/db/esximg/vibs/

  7. Remove the corrupt imgdb.tgz from the bootbank
    rm /bootbank/imgdb.tgz

  8. Move the working copy of imgdb.tgz into the bootbank
    cp /tmp/imgdb.tgz /bootbank/

  9. Make Config Backup

  10. Reboot the host
  11. Update host using Update Manager again

Uninstall Annoying Windows 10 Stock Apps via Powershell

These apps come with Windows 10, and some you can Right-Click and Uninstall, while others you cannot. That that you are able to Right-Click and uninstall, seem to come back with every Windows Updates you install (because Right-Click Uninstall doesn’t uninstall them completely).
So the easiest way to do this is with our favorite enemy friend, Powershell!

  1. First thing is to open Powershell as Administrator

All stock apps are in the AppxPackage command set. So running something like Get-AppxPackage would show you currently installed stock apps.

2. Here is the list of package commands that can be used to remove all or specific components

Remove all stock apps from all user accounts
Get-AppxPackage -allusers | Remove-AppxPackage

Remove all modern apps from system account
Get-AppxProvisionedPackage -online | Remove-AppxProvisionedPackage -online


Skype: Get-AppxPackage *skype* | Remove-AppxPackage
Sway: Get-AppxPackage *sway* | Remove-AppxPackage
Phone: Get-AppxPackage *commsphone* | Remove-AppxPackage
Phone Companion: Get-AppxPackage *windowsphone* | Remove-AppxPackage
Phone and Phone Compantion Apps: Get-AppxPackage *phone* | Remove-AppxPackage
Calendar, Mail: Get-AppxPackage *communicationsapps* | Remove-AppxPackage
People: Get-AppxPackage *people* | Remove-AppxPackage
Groove Music: Get-AppxPackage *zunemusic* | Remove-AppxPackage
Movies and TV: Get-AppxPackage *zunevideo* | Remove-AppxPackage
Groove Music/Movies/TV: Get-AppxPackage *zune* | Remove-AppxPackage
Money: Get-AppxPackage *bingfinance* | Remove-AppxPackage
News: Get-AppxPackage *bingnews* | Remove-AppxPackage
Sports: Get-AppxPackage *bingsports* | Remove-AppxPackage
Weather: Get-AppxPackage *bingweather* | Remove-AppxPackage
Money, News, Sports, Weather: Get-AppxPackage *bing* | Remove-AppxPackage
OneNote: Get-AppxPackage *onenote* | Remove-AppxPackage
Alarms and Clock: Get-AppxPackage *alarms* | Remove-AppxPackage
Calculator: Get-AppxPackage *calculator* | Remove-AppxPackage
Camera: Get-AppxPackage *camera* | Remove-AppxPackage
Voice Recorder: Get-AppxPackage *soundrecorder | Remove-AppxPackage
Maps: Get-AppxPackage *maps* | Remove-AppxPackage
3D Builder: Get-AppxPackage *3dbuilder* | Remove-AppxPackage
Xbox: Get-AppxPackage *xbox* | Remove-AppxPackage
Solitaire: Get-AppxPackage *solitaire* | Remove-AppxPackage
Get Office: Get-AppxPackage *officehub* | Remove-AppxPackage
Get Skype: Get-AppxPackage *SkypeApp* | Remove-AppxPackage
Get Started: Get-AppxPackage *Getstarted* | Remove-AppxPackage
Windows Store: Get-AppxPackage *windowsstore* | Remove-AppxPackage

Tip to Increase Wifi Speeds on an 802.11ac Network

For the past couple of months, I have been benchmarking many Enterprise Access Points, and have tried to test every possible variable I can think of. During my testing, I found a “trick” that increased my Wifi speeds dramatically. First let me explain…

Most/All Enterprise Access Points (Aruba, Cisco, Meraki, Rukus, etc) use a feature called “Band Steering”, which steers 5Ghz compatible devices to use the 5Ghz channels. I always assumed that if I had a 5Ghz capable laptop, I would always be on a 5Ghz channel. (Conditions permitting). And while that is true, Ive noticed the access points handling my connection in some sort of “5Ghz Compatible” mode. (My made up term).
What I mean by 5Ghz compatible mode, is I am running on the 5Ghz spectrum, and my laptop has an 802.11ac chipset, yet my speeds increase dramatically when I force by laptop to only connect using 802.11a. I guess I assumed I would always connect via 802.11ac if both laptop and AP supported it.

So here it the trick (not really a trick).

  1. Open Network Connections and Right-ClickProperties on your Wifi Adapter

2. Click Configure on the window that appears


3. Click AdvancedWireless Mode – and change value to 802.11a

My average speed increased as follows (transferring 20 MB Files)
Average Upload Time: 13.7% Faster
Average Upload Mbps: 16% Increase
Average Download Time: 52% Faster
Average Download Mbps: 53% Increase

Just remember to switch this back in places that don’t have 802.11ac Wifi or else you may not have a wireless connection at all!

VMware Storage I/O Control (SIOC) – A Blessing and a Curse

I am taking this content straight from an email I just sent a customer, so the content isn’t well polished. But the email took me long enough to write that I decided to post it here for others.

Storage I/O Control (SIOC) is a mechanism to prevent one VM to hog all the I/O resources making the other VMs wait for their I/O request to be completed. By default, it gives every VM on a Datastore fair and Equal I/O Shares. It is able to gauge and determine fairness based off latency. So if you have two VMs (VM1 and VM2) and VM1’s latency hits a specified threshold (30ms is default), then it will actually SLOW VM2’s I/O access and give the scheduler resources back to VM1 until fair sharing is equalized again. This is different than QoS, but I’m sure you see some similarities.

So that sounds great, right? (Really, it is great). But this is not very effective and can be detrimental in certain circumstances. I’ll try to explain.

First let me preface this by explaining two concepts, which  you may already be aware of.

  1. Hypervisors work via scheduled process. Every VM waits its turn to receive the CPU Cycle or Memory Page it requested until it is his turn in the scheduler.
  2. Every Volume you create and map to a host is given a LUN ID (this volume is the LUN) and each LUN has access to schedulers. All the VMs in this Volume/LUN take their turn for I/O requests. This is why best practice dictates you put a maximum of 10-15 VMs per Volume, or much less if those are resource intensive VMs. The more VMs in the LUN, the longer each VM has to wait for its I/O requests. (Note- Setting resource shares doesn’t solve this, it just guarantees one VM will have priority over another)

There are certain scenarios where SIOC can possibly make things worse. The scenario you might be running into is the following:
You have a SAN capable of tiered storage, which is really amazing when you think about how that all works. What’s even more incredible is that you are able to have different RAID types be striped across the same physical disk. (Hot data lives on 15k drives in a RAID 10 stripe, and as I becomes warm, it moves into a RAID 5 stripe across those same physical 15k drives).

Lets take our VM1 and VM2, both reside on the same LUN. We have enabled SIOC on that LUN. VM1 is a high resource VM that is crucial to your business and VM2 is just a Test/Dev Server. Most of VM1’s blocks reside in your 15k disks RAID10, but a few of its less hot blocks have moved to RAID 5, but still on those 15k drives. Again, data on VM1 is almost always hot.
VM2 on the other hand, has some of its blocks on the 15k drive, and some reside on the 7k slower drives since that data is hardly ever accessed.

One day you log into VM2, and fires up an application who’s data is on those 7k drives. That data takes longer to retrieve, naturally, since its sitting on the slowest media, and the time it takes to queue up and process that I/O request (latency) is much greater than the time its taking VM1 to process its requests.

What happens is the SIOC’s mechanism kicks in and because the latency on retrieving data for VM2 is impeding on its “fair access” functionality. So it throttles down the I/O of VM1 (your production server) to try and decrease the latency VM2 is having. You have essentially killed the performance of the VM that needs it the most. Now imagine this happening for all your VMs, VMDKs, bits, blocks, whatever you want to include, it has become a traffic nightmare. It can throttle a VM down so much, waiting for the latency to decrease on the other VMs, that everything is timing out, whereas if you weren’t using SIOC, things would be humming along as usual, and VM2 will just take its sweet time processing data from the slow drives.

I am sure you were aware of most of these concepts, and what I have described is somewhat over-simplified, but hopefully that makes sense. Sharing workloads across the same physical drives can make SICO a nightmare. If you are careful in what workloads you place in what LUN, then SIOC can be great, even on tiered storage. If you take an old EMC or Netapp where you used to carve out specific disks for specific volumes, SIOC would also be great.

Dell Compellent’s Best Practice is to use this with caution, just as other have stated as well on this feature.