Blog: Networking

There are power management settings that should be checked when running ESX on HP Proliant G6 and above or Dell PowerEdge 11th and 12th Generation servers.  See VMware article for details: https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1018206​ 

The Proliant G8 that I examined having performance issues was set in the BIOS to use "HP Dynamic Power Savings mode" instead of "HP Static High Performance mode".  This can have an impact on virtual machines ability to utilize the CPU of the host.   This setting can be changed through iLO without the need to get into the BIOS directly to make the change.  It does not require a reboot of the ESX host to change the setting this way, which is even better.

I’ve been migrating Exchange customers from Barracuda ESS over the past few months and recently ran into a small issue. I had logged into the BESS portal one morning and decided to go ahead and start cleaning up some of the domains that were registered so that Barracuda would stop routing email for these customers.

It was a simple enough process – Click the Domains tab, find the domain to remove, click Remove. Everything magically disappears.

I removed 23 domains and called it good for the morning and proceeded to work on other things. A few days later, we get a task from a customer who was unable to receive email from another customer of ours who was still using Barracuda ESS. After tracking down the logs in Customer #2’s BESS portal, I discovered that BESS was still routing email internally instead of respecting MX records.

A quick phone call to Barracuda Support and they immediately escalated the case to Tier 2/3 and Product Development. I heard back from them later that afternoon and was informed that I was removing the domains incorrectly.

I didn’t think I could screw up clicking a “Remove” button, but apparently I did.

After another minute or two of explanation, my support rep explained that the issue was really because the domains I had removed that included Aliases. There’s apparently an acknowledged bug with the portal that requires you to un-alias all domains before removing the parent domain from the portal. They checked all 23 domains I sent and verified we were good to go.

Beginning with ASA OS v9.7, the 5506-X has a new default configuration that allows the ports to be used as switchports, similar to how the 5505 models worked. The default configuration includes a Bridge Virtual Interface (BVI) that has ports G1/2 - G1/7 (6 ports) as members of the BVI. This will apply to models that ship with 9.7 code. However, if you upgrade a device to 9.7, you will have to manually create the BVI group (the upgrade itself does not do this).

Even though the BVI supports up to 6 ports in the BVI, if you try to configure this via ASDM, it only allows you to add 4 ports as members. This actually is a restriction when running the ASA in transparent mode (we rarely do this) instead of routed mode (typical install), but ASDM seems to ignore the mode and apply this restriction regardless. So for an ASA in routed mode, this seems to be an ASDM bug. To work around this, you must add the member ports via the CLI. In addition, the ports cannot have a name defined before you configure the bridge group. However, they must have the naming convention inside1, inside2, etc. to work as part of the BVI group named inside. The default is to assign the members of BVI1 (G1/2 - G1/8) the names inside1 - inside7. The BVI interface is named inside.

Also, the http and ssh commands don't allow you to assign the BVI named interface (inside). Instead, you must add the member name (ex. inside1, inside2, etc.). The snmp-server command actually does allow you to add the BVI interface name, but it doesn't work when you do (seemingly another bug). So again, you'll need to use the member port name instead.

After upgrading a customer to vCenter to 6.0, VMs that were being replicated with Veeam from one site to another started to issue an alarm for a "VM MAC Conflict". However, when I compared the MACs of the replicated VM and the original VM, they were unique. I had not upgraded the hosts at this point, only vCenter. Nothing had changed with Veeam, so this was a new issue as a result of the vCenter upgrade.

As it turns out, there is nothing wrong technically, this is simply a change in behavior in the alarm issued by vCenter. When Veeam replicates a VM, the replica VM initially has all the same settings (other than the name) of the source VM. vCenter sees the same MAC address on two VMs and alarms. vCenter then changes the MAC address of the replica (as had always been the behavior), but it never clears the alarm. You must clear it manually. Then when the next replication occurs, the alarm will trigger again.

I found several references to this issue online and most had suggested simply disabling the alarm to avoid vCenter showing the replicas with an alarm all the time, but that's not a great solution because no alarm would be generated in the event of an actual MAC conflict. Further research revealed a workaround. You can edit the alarm VM MAC Conflict in vCenter and add an argument to exclude VMs whose name ends in "_replica".

I was recently doing a maintenance window for a customer and had an issue with several of their servers giving me an Error Code 80243004 – Windows Update encountered an unknow error when I was trying to install updates.  After researching, I came across an article with a very simple and weird fix for the issue. 

1. Right click on the taskbar and select Properties.
2. Click the Customize… button on the Taskbar and Start Menu Properties window.
3. On the Notification Area Icons window, make sure Always show all icons and notifications on the taskbar is checked and click OK.

After turning on the notifications for Windows Update, I was able to successfully install all Windows Updates.

I received several new Cisco 2960x switches to configure and one of them would not boot up stating that the image failed digital signature verification.  These switches have USB interfaces on the front and can be used for file transfer, however more modern USB flashdrives would not work for me.  I had a few older USB flashdrives that worked, so hold on to your flashdrives!

From a working switch, copy the boot image to the USB flashdrive.  
"copy flash:/c2960..../c2960...bin usbflash1:" (or usbflash0: depending on which port it was connected to).

I booted up the switch that wouldn't verify and tried to copy the image onto the switch from usbflash1:  but it told me the copy command was unknown.  Luckily, you can boot off the USB flashdrive image.

I typed "boot usbflash1:/c2960....bin" and it booted the switch where I was able to copy the working image to flash: "copy usbflash1:/c2960....bin flash:/c2960..../c2960....bin"  

​​After overwriting the corrupt image, I rebooted the switch and it passed the verification on the image.

Recently I was deploying Cylance for a customer. The first approach I took to deployment was to create a group policy that ran a batch script at logon. I set up the policy and then restarted one of the test PCs I was working with. The group policy was being applied, but the software was not installing.

My research suggested disabling  asynchronous processing of group policies. To do that, I went to Group Policy and navigated to:  Administrative Templates\System\Logon. There is a policy called Always wait for the network at computer startup and logon and when that is enabled, it turns off asynchronous processing. As soon as I enabled that, the install worked.

Not long after I applied that policy, the customer called and said their users were having issues with one of their applications not launching. After some investigating, it turned out that the program required that a network drive be mapped first, before the program could launch. Clearly the order of operations was broken when I disabled asynchronous processing. So, I turned it back on, but the trick about group policies is that you have to go in and manually fix anything that was modified in the registry. I fixed that and everything started working. Moral of the story is always remember the policy changes you make, just in case you need to go unmake them.

As we’ve been working through migrating email delivery from Barracuda ESS to Proofpoint, one of the issues that pop up would be in regards to SPF records. I figured I’d give a quick overview about how SPF records work and why this could be an important issue.

SPF records are TXT records in DNS. These records are intended so that you can publish which mail servers are authorized to send email on your domain’s behalf. The way it works is this:

1. jdoe@contoso.com sends email to jsmith@fabrikam.com.
2. Contoso.com email server looks up MX records for fabrikam.com to route the email to the appropriate receiving mail server or spam filter
3. Fabrikam.com spam filter accepts the connection and performs an SPF record lookup
   1. The fabrikam.com spam filter requests all TXT records for contoso.com
   2. The fabrikam.com spam filter analyzes the response for a TXT record that contains a line similar to “v=spf1 …”
   3. The fabrikam.com spam filter checks to see if the contoso.com email server IP address is listed in the TXT record response.
      1. If Yes, the email is accepted and processed as expected
      2. If No, the email is rejected with an NDR

SPF records are used to help mitigate phishing and spoofed messages. If you receive an email from amex.com saying you owe a huge bill (“Click here to log into your account and pay”), an amex.com SPF record could help prevent you from receiving that phishing attempt because the actual sender wouldn’t be authorized to send email as amex.com.

The downside is that this truly depends on the recipient checking SPF records. You as a sender can do absolutely nothing, other than creating the TXT record, to force SPF checking on anyone. But if you have the record available, then you can be better protected. It takes very little time and is a worthwhile thing to set up.

When creating an SPF record, there are many tools online to help you format it properly. The biggest thing is to make sure that the final mail server sending your email is listed in the record.

I had two customers that needed to exempt a couple of systems from a group policy that disables USB/CD-ROM access, but I ran into the same issue both times when trying to do so.

I added the user to the appropriate group to block the GPO, but when I logged into the user’s PC, the drives still said access denied. I figured the group policy had not applied, so I forced it to apply and then I had the user both log off and back on and also restart with no success on the policy applying.

I did some digging and discovered that there is a bug in Windows that affects the Portable Device Enumerator Service. I tried several things with that service (restarting, looking at other depenedent services, etc) but nothing worked. Microsoft had a Hotfix available, so I tried that and still got nothing. Finally, after some additional research, I ran across a KB article that recommended going into Disk Management, uninstalling the driver for the CD-Rom and then rescanning the disks to let it re-install. As soon as I did that, everything started working properly. 

Here is the KB article with the Hotfix, in case it happens to work for someone else down the road: https://support.microsoft.com/en-us/help/2738898/users-cannot-access-removable-devices-after-you-enable-and-then-disabl