Thursday, October 14, 2010

Enabling Promiscuous Mode on vSphere 4

We are in desperate need of a testing server. The testing server needs to be able to listen to the network, through port mirroring, to record VoIP calls. In the physical world this is no problem, but we don't have the budget for another physical box, especially for something as non-critical as testing a program upgrade (even though the program it self is very critical to our business).

A year ago the software vendor said that they don't support virtual environments and their product doesn't work in a virtual environment. During discussions this year however they told the truth that they simply don't know if it will work, and thus "don't support" it. I am calling it lazy. It doesn't take much these days to get a VM host going and configured for testing things out.

Well we have done the leg work for them. I have confirmed that vSphere does allow for promiscuous mode, even from the physical network. To be honest I was a little shocked to see this worked.

Here are the steps to enable promiscuous mode on your vSphere host and the guest VM.
  1. Enable promiscuous mode on the virtual adapter.
  2. Enable promiscuous mode on the vSwitch.
  3. Enable promiscuous mode for the guest.
  4. Enable port mirroring on the physical switch (not covered here).
  5. Test capturing network data.
Now that we have the general synopsis of the procedure we can begin.

We enable promiscuous mode on the virtual adapter by logging into the vSphere Client, going to the VM Host, clicking on the "Configuration" tab, then on "Networking" in the "Hardware" section on the left. Now click on "Properties..." for the Virtual Switch.

Now enabling promiscuous mode on the vSwitch is pretty simple. Click on the "vSwitch" on the "Ports" tab, as shown below and then click on the "Edit..." button.

Now that we are editing the vSwitch properties click on the "Security" tab. Change the option for Promiscuous mode to "Accept" if it isn't already and hit "OK".

To enable promiscuous mode for the guest we need to break down to the command line. I used putty to SSH into my vSphere host, which I had previously setup. Now you need to edit the .vmx file of the guest that will be listening to the network.

# vi /vmfs/volumes/datastore1/testServer/testServer.vmx

I did a search for ethernet, so the promiscuous mode configuration would be with the rest of the ethernet config. Add the following line to the configuration file:

ethernet0.noPromisc = "FALSE"

And save when you are done. I rebooted my testServer just as a precaution, but I'm not certain it is required.

At this point everything is configured on the VM side of things. Make sure you have port mirroring enabled on your physical switch and give it a test. In my environment I commonly use Wireshark. I did my testing by pinging a server on a mirrored port.

Using PSExec to Defragment your PCs

Way back in 2000 / 2001 I was an IT intern. My job was to do the really manual processes for a small department with in a much larger company. One of those was monthly defrags of all PCs and Laptops (if they where available). I had to go to each and every PC, log on, and start the defrag process manually. I believe this to be my first moment of "I should automate this". Problem was I didn't know how or really where to start. I knew script was the answer, but just couldn't get things to work. I believe I eventually created a scheduled task on each machine (by hand) to do this for us.

Fast forward 10 years and I am still in need of the same thing, as we don't have Vista or Windows 7 deployed. But now I have a much better understanding of what needs to happen and even better I know where to start!

PSExec, which is part of the System Internals PsTools suite is my answer these days. A simple script, run from my PC (still manually for the time being) is able to handle defragmenting all of our PCs.

psexec @C:\Updates\Comps\AppPCs.txt -n 10 -c -f -d JkDefragCMD.exe

I use the files with PC names to speed up re-deployment of everything. The -n 10 flag tells psexec t0 wait 10 seconds before it times out the PC, instead of 60 (I believe this is the default). -c copies the file (jkdefragcmd.exe) to the remote system. The flag -f forces copying, even if the file exists. The flag -d doesn't wait for the process to terminate, this is as asynchronously as I can do.

My next step is to hook this up to task scheduler and have it run the first Sunday or something.

Monday, October 04, 2010

Documentation, not always the How To Dos

Documentation for me is often just How to do something, but I have been forgetting the WHY part of the equation. For instance, my documentation says to do our weekly maintenance window after 21:30 and to only reboot one particular server after 21:45, but I didn't say why and had forgotten myself. So I started doing the maintenance earlier and at one point rebooted the one particular server at 21:30. This caused the last of our production cron jobs to not run, and thus a customer didn't get their batch for the day.

Now this could have been avoided a few different ways. Since that first time was a mistake any thing that happens after it is a failure on my part, and thus can't happen again.
  1. I could have followed our procedure to the T.
  2. Read my e-mail to see that the cron job hadn't run yet.
  3. Run the cron job by hand after the server restart.
  4. Did all of the precursor work and waited for the cron job to run.
  5. Did all of the precursor work and run the cron job by hand.
I have chosen to go with option 1, follow our procedure to the T. We started doing the weekly maintenance for a few reasons and it was to be done after 9:30, with that one particular server last to ensure this didn't happen. Now once again I have my WHY, and I have it written down so if I question it again I know why.

This is just one instance where the WHY is critical, but there are others. So please when you are writing documentation, and you should be please include the WHY you do something the way you do it. It also helps train the new guy, or your replacement.

Enabling the Administrator user in Windows 7

This is a very simple fix. The reasons to actually log on as the administrator are shrinking, but for my environment I need to log on as the Administrator user occasionally (for software patching).

  1. Open up a command prompt as Administrator (not the same thing we are trying to do)
  2. Run "net user /active:yes administrator"
  3. Now it is a great idea to set a password for the Administrator user so we can do that right now
  4. Run "net user administrator password" but replace password with something more complex similar to "Som3C0mpl3xP@$$w0rd"
  5. Exit out of the command prompt.
For my situation I need to run commands as the Administrator user on other machines and need the Administrator shell. I did a lot of testing to make sure that the "Run as Administrator" doesn't work as I need.

Enabling Ping responses in Windows 7

Out of the box if you Ping a Windows 7 host you will recieve "Request Timed Out". This is because the Windows 7 firewall is blocking ICMP echo requests. If this is causing you problems and you need to open up access to ping requests it is fairly simple.

  1. Go to the "Windows Firewall" in the Control Panel.
  2. On the left hand side click "Advanced Settings"
  3. Click on "Inbound Rules"
  4. Right click on "Inbound Rules" and choose "New Rule"
  5. Select "Custom (Custom Rule)" and press "Next"
  6. Select the (default) "All Programs" and press "Next"
  7. Change the Protocol type from "Any" to "ICMPv4"
  8. Unless you want to restrict the ping response choose the option "Any IP address". (This is for your adapter.)
  9. Unless you want to restrict which hosts can ping you choose "Any IP address".
  10. On the Action screen ensure it is an "Allowed" connection.
  11. Leave all three check boxes check on the Profile screen.
  12. On the final screen, Name, give it a meaningful name such as "Echo Ping Request"
  13. Finally click finish.