Blog: Networking

I was working on moving a group of users to a new Windows Server 2008 domain. I had copied all the users profiles to the new server. Whenever I tried logging in with a roaming profile, on a Windows XP client, it would get an error and load a local default profile. I found that when using Windows XP clients on a  2008 domain, roaming profiles will not recognize the presents of a version 1 profile (Windows XP, 2000, 2003) without the presents of a version 2 (Windows Vista, 7, 2008) user profile. In order to resolve the issue I logged onto the domain controller  as one of the users which initiated the creation of a version 2 profile for that user. I then modified the permissions and use it as a default profile and copied it to all the other users profile folders. This meant that all user then had a “NTProfile” and “NTProfile.V2” folder in the profile path. I then logged into a Windows XP client and it loaded the version 1 profile without  any problems.

During troubleshooting of some VPN connection issues, I was running a traffic dump session on the Ecessa PowerLink.  I noticed some unusual SSH traffic going to the internal VPN router.  When I entered in “show users” at the command line of the router, it showed myself and someone using “root” connected.  The IP address of the “root” user was an external IP address.  I performed a “whois” on the IP address.  It appeared to be originating from St. Louis Missouri. [more]

I talked to another engineer about this and after some investigation and testing, it turns out that when a person is trying to connect to a Cisco device, the show users output will show whatever username is being utilized.  I verified this by connecting to the same router and typing it “admin” at the username prompt.  The show users output showed the name admin.

One of our bank customers has a vendor that monitors the status of one of their servers remotely through a VPN connection.  In the past few days, something has happened to where they call saying that they are detecting the server is down or unreachable.  The bank had not noticed any problems in their ability to provide service to their customers as they usually get calls when something isn’t working right.

The vendor began troubleshooting network connectivity and determined later that there didn’t seem to be a network problem, but their network monitoring software was still indicating the server was down.  They later said that the problem had been traced to an “application” problem.  Rebooting the server brought the connectivity back up with their monitoring software.  The application running on the bank server had stopped responding and blocked incoming requests from the vendor’s monitoring software. This is an example of network monitoring software only being as good as the application on the other end.

The newer versions of the Cisco IOS allow you to add a compression algorithm to the transform set that defines how traffic is encrypted.  After adding new crypto map entries at a client using this compression, other VPNs (using the original transform set that does not include compression) started getting odd errors.  The VPN would stay up, but only small ping packets would get through.  And different endpoints had different sized pings that would make it through.  Eventually, I tried removing the crypto map entries using compression and the other problems disappeared.  The lesson I learned from this was to not use a crypto map that mixes transform sets with compression and transform sets without compression.

64 bit Gotcha:   If you are creating a DSN on a 64bit machine for a 32 bit database, then you will need to create a 32bit DSN. This cannot be done from the Control Panel  ODBC Data Source Administrator , because this program creates a 64bit DSN. In order to create the 32bit DSN, you must run the program odbcad32.exe from the Windows\syswow64 directory.  The KB article here talks about this issue. In particular, I ran into this problem when moving a VMware Virtual Center from one machine (32 bit, Windows 2003) to a new machine (64 bit, Windows 2008 R2). [more]

http://support.microsoft.com/kb/942976

I had been troubleshooting a DL380 server and replaced bad memory.  I had the server powered off and connected to it using iLO.  I used iLO to send power signal to the server so that I could watch it boot up.  For some reason right after I powered on the server, I lost connectivity to iLO and the blue UID light on the server remained on.

Once Windows came up, I checked the HP System Management software, and it did not list an iLO management processor like the other servers did.  I figured that iLO was hung, so I shutdown the server.  Still no response from iLO, so I checked BIOS with a physical monitor and keyboard.  Upon boot, it did not show the message to press a function key to configure iLO.[more]

In order to reset iLO, I had to completely unplug both power supplies from the back of the server.  After powering the system on again, I then saw the option to configure iLO.  I saw that it had an IP address but I still could not connect.  The blue UID light was off though.  After the system came back up, I had to reset the iLO interface through the HP System Management software before it would work again correctly.

When logging into the Symanted Endpoint Protection Management Console (SEPMC) console, keep in mind that the username is case-sensitive.  This is true whether the account you're using is set for 'Symantec Management Server Authentication' or MS 'Directory Authentication'.  You have to match the case of the username as it is listed within the console. The case as set in the console does not have to match case of the username as shown in MS-ADUC when using Directory Authentication.

I had an issue come up with using GUID partition table disks in Windows 2008 VMs. The issue involves doing a file-level restore from image-based backups made using 3rd party VMware backup utilities such as Veeam Backup, Vizioncore vRanger, or esXpress. In Windows 2008, the disk containing the system partition is always MBR, but disks with non-system partitions I had been using GPT. I found specifically with Veeam, file level restore functionality does not work because when the vmdk is mounted to the recovery host during the process, the partition table cannot be read. The partitions on the system disk show up fine, but all partitions on GPT disks are not available. A VERY close look at the Veeam documentation shows that GPT disks are not supported, only MBR disks. So, if one of these products will be used for backup, it would be best just to go with the MBR disks.

I installed Intel Turbo Memory driver update - but it also updated the Intel Matrix Storage Manager & Turbo Memory driver.  After the installation there were two entries in Programs and Features - one just for the Turbo Memory driver and one for the Matrix Storage Manager & Turbo Memory.

After this installation, my PGP single sign-on stopped working.  I would enter a pass phrase at boot and then credentials again when Windows started.  I changed my password to get things synched back up and it still didn't work. [more]

I uninstalled the Turbo Memory driver, after which there is only one related Intel entry in Programs and Features and now it doesn't mention Turbo Memory.  Then I rebooted and still had to use the old Windows password in the PGP boot loader and the new one when Windows started up.  However, this time, when booting into Windows, it gave me a password error before asking for the correct one (i.e., PGP had passed the old one through this time - I could have saved a password change).  After I entered the correct password things worked correct at the next boot.