Tool: Microsoft Remote Connectivity

While onsite with a customer yesterday, I was introduced to a new free tool provided by Microsoft called the “Remote Connectivity Analyzer”.

So what does this do? How can it be of use to me?

I’m glad you asked. Our scenario was that the company used Office365 for their emails. I’ve watched companies make the move to cloud provided email for years now. But where this gets to be problemsome, is when you need to configure applications to send/receive email. Our specific scenario involved configuring vRA to use Office365. Now, I already know that if Office365 is set up to use EWS (Exchange Web Services) this won’t work. So boys and girls, if the customer uses Office365 and they are setting up vRA – ask them if O365 is using EWS. If so, stop. Save yourself a headache.

But back to the problem. So when we go to configure the email server (inbound or outbound), we only have the ability to plug in the configuration and click a little “Test Connection” button. If it fails, you get a generic error message and then you have to scour logs to try and decrypt what went wrong. Do you not have enough ports open? Are they blocking subnets? Is the email account enabled? Now you have to try and troubleshoot the problem with multiple teams.

Our first foray was to try and check if we could ping outlook.office365. We SSH’d into the vRA Cafe and pinged. We were good. We attempted telnet by running the command: curl -v telnet:// We were good. We had the network team verify that traffic was making it to and from. Again, good.

MS Remote Connectivity Analyzer
MS Remote Connectivity Analyzer
The next step was to validate the email configuration. The email team checked over our settings — which surprise, we’re good. Then they introduced us to the Remote Connectivity Analyzer. Using this tool, they were able to see test the connection between the admin’s workstation and outlook.office365. What we found was that the email account was set up as a shared email mailbox, and not an individual user box.

But what was fascinating was that the analyzer ran tests to check EVERYTHING. So the next time you run into issues with trying to configure email, give this a shot.

FINE PRINT: The test machine will need to have internet access to give this a whirl.

PernixData – First Impressions

PernixData Dashboard
PernixData Dashboard
As you’ve probably guessed, I got a new toy in the lab at work. I’m talking PernixData v1.0. For my initial review, I will say that the install, setup, and configuration was very simple — just a few steps actually. This was probably the easiest installation that I’ve done in the last year.
Continue reading “PernixData — First Impressions”

Thinking About Upgrading To vSphere 5.1?

If you haven’t made the jump to vSphere 5.1, then you may want to try this new fling out (vCenter 5.1 Pre-Install Check Script) from Alan Renouf before upgrading.

(*description borrowed from the Fling’s website)
This fling is a PowerShell script that when run will help customers validate their environment and assess if it is ready for a 5.1.x upgrade. The script checks against known misconfigurations and issues raised with VMware Support. This script checks the Windows Server and Active Directory configuration and provides an on screen report of known issues or configuration issues, the script also provides a text report which can help with further trouble shooting.

For more information, read New Fling: vCenter 5.1 Pre-Install Check Script.

As a reminder, all checks are read-only and no changes are made to the system.

I use many of Alan’s scripts during my customer engagements and this is one more that I have thrown into my bag for future health checks and upgrade validations.

Script: Detailed NIC Information Report

Over the last few days, my coworker and I have been working on a script that will go out and collect detailed network information for each NIC on our ESX hosts. Not wanting to reinvent the wheel, I strolled over to Alan Reneuf’s website ( I had remembered seeing a script (“More Network Info”) he created that I knew could collect the info we wanted. Thank you, Alan.

I copied Alan’s script into Notepad++ and started to work with it. One of the things we needed to know was duplex information. Since that wasn’t in the original script, I added it. I didn’t need to know the number of active virtual switch ports, so I removed that portion.

Here are the end results of this modified script.


The above script may not actually display properly within this blog entry. If this is the case, you can download the script here.

NetApp nSANity

I was asked a few days ago to run a tool against one of my ESX hosts. The tool is called nSANity and was supplied by my NetApp vendor. This application is designed to collect details of all SAN and fibre connectivity for end-to-end diagnosis. It takes this data and makes an XML report out of it. The reason I was requested to run this tool was so that data could be collected about a remote site and how it is currently connected to one of our NetApp SANs in preparation of a SAN data move to be performed by NetApp Professional Services.

Fig 1

The link for the software was supplied and I went to go retrieve this tool. I’m providing the link to the tool, but you will have to be a NetApp NOW member to download it. I get to the URL and start reading. I notice this right off the bat (see Fig 1). Hmm…. NetApp wants me to run this tool that they provide, yet they can not support you if you’re having trouble. Which I read as, “if this poops your machine, you’re on your own.”

Further reading gave me no indication of what kind of data was to be collected. In addition, the documentation mentions that you have to run this via SSH to the ESX Host as root. My company’s environment does not allow root access over SSH. It falls under the “No Fly Zone.” It’s forbidden, taboo, etc. Unfortunately, nSANity cannot be run locally on the ESX host. So I had to get an approval from Congress to allow root over SSH. (Ok, that’s an exaggeradtion, but that’s what it feels like.) Once I had the green light, I break out the fire extinguishers and prepare for the rapture of this ESX guinea pig.

The windows version of the tool runs very well on Windows 7. To fill in the blanks on how I ran this, I opened a command prompt (Run as Administrator) and then used the following command:

c:\> nsanity -d c:\temp vmware://root:*

The app runs for approximately ten minutes and collects configuration data on firewall rules, virtual switches, virtual nics, drives, cpu, processes, lspci, hbas, etc. Once the data was collected, root access via SSH had to be replugged. It seems harmless to the environment and the data collected doesn’t seem to fall under any security risks.

If you are having to run nSANity and aren’t familiar with the tool, I hope my experience with it provides some insight on how it works.