Blog: Networking

I had a customer IT Admin call in saying that they had been trying to login to a Windows 7 laptop that had not been in use for a while and the employee was no longer there.  They kept getting a message when trying to logon that said “the trust relationship between this workstation and primary domain failed”.   When trying to login as the local Administrator account, it said that the account was disabled.

By default, Windows 7 disables the local Administrator account.  The laptop was encrypted, so resetting any passwords by means of a third party password recovery disk could cause the data to be irretrievable.  The IT person had removed the PC from active directory without unjoining the domain, so I could not troubleshoot resetting the computer account.  [more]

After some research, I found that you can boot the system with the network cable unplugged and login with cached network credentials.  The admin was able to login, plug in the network cable, then unjoin and rejoin the domain.  After a reboot, the PC could login to the domain normally.

I was doing a physical to virtual conversion on a Windows 2003 Small Business Server. After the conversion, I shutdown the old physical server and booted the virtual server. I started the VMware tools installation and it got an error warning that it could not locate the path to My Documents to write temp files. Since no network interfaces (NICs) were available it did not load the SYSVOL and therefore could not find domain shares. I also could not change the My Documents redirection because it would not allow me to load the Domain Group Policy. The flexible NICs I initial tried to use did not work since VMware Tools could not install and the system did not have a driver available. The system did have a driver available for Intel E1000 NICs, I changed the NIC type to E1000 and rebooted. Windows installed the driver allowing the SYSVOL to load and allow me to install VMware Tools.

The traditional program switch to “fix” a hard disk drive may not fix everything. I have used chkdsk /f to fix disks for years, but it turns out that there is also a chkdsk /r . The /r switch does everything a /f  does and additionally checks for bad sectors on the disk.

When changing some settings in Internet Explorer recently, I stumbled across the “Use SSL 3.0” and “Use TLS 1.2” settings under the Advanced tab of Internet Options.  For a long time, I have been running without SSL 2.0, TLS 1.0, and TLS 1.1 enabled, but I wondered if SSL 3.0 is even necessary anymore (TLS superseded SSL 3.0 in 1999).  So I unchecked the “Use SSL 3.0” check box.  I did the same in my Firefox settings.  I ran that way for at least a couple of weeks without any noticeable issues.  Then last week I was onsite at a bank and tried to use the Cisco AnyConnect SSL VPN.  It did not connect, so I tried it that night from the hotel.  It still did not connect.  The Cisco IPSEC VPN client worked perfectly.  After a couple of days of the AnyConnect client not working, I was about to send an email to one of our network engineers asking if anything had changed when I remembered the “Use SSL 3.0” setting.  After re-enabling SSL 3.0 in both IE and Firefox, the AnyConnect client worked.  Aside from the SSL 3.0 setting breaking AnyConnect, the more general GOTCHA is that the AnyConnect client uses at least some of the web browser settings when establishing its connection, so I now know to include them when troubleshooting the VPN.

I ran into a very interesting 32/64-bit problem the other day that looks to me like Microsoft has goofed. The issue involved installing the x64 version of WSUS on Windows 2008. In Windows 2008, WSUS is now a feature and can be installed without a download.  During setup of one of our new customers, WSUS was installed on an x64 Windows 2008 server that was currently hosting some .NET web services in IIS. After the install of WSUS, the web services would return a 500 error for every request. The error page noted a problem with DynamicCompressionLibrary. After much digging, the problem was caused by installing the x64 version of WSUS alongside x86 web applications in IIS. [more]

When WSUS is installed, it installs a dynamic compression library called suscomp.dll globally in IIS. This compression library is used to compress updates before they are streamed down to clients via BITS. However, due the inherited nature of .NET configuration (web apps inherit global settings in IIS), these .NET web services were looking for the x86 version of the suscomp.dll (search path is by default at c:\windows\SYSWOW64\) which WSUS DOES NOT install. It installs the x64 version (default path at c:\windows\system32\). Without a matching suscomp.dll compression library, the inheritance chain is broken, and you will get 500 internal server errors. This could all be avoided if Microsoft would just include the x86 version of suscomp.dll in the install of x64 WSUS. The fix is to find an x86 version of suscomp.dll (from another install of WSUS) and copy it to c:\windows \SYSWOW64\ and do and iisreset. Thanks Microsoft!

During the recent move of a customer’s servers to our network, we had to change the IP address to match our addressing scheme. This ended up breaking many of the applications on the server (including OWA) that we needed to go fix. I opened up IIS and changed the connection address from their previous address to the current address of the network. After running iisreset, OWA still did not work. I couldn’t get the websites to even start up. It was as if the server still wasn’t listening on the correct address.

Well, sure enough, that was the case. The command “httpcfg query iplisten” will show you the IP addresses that the server is listening for. In my case, I saw something similar to the following:

 IP : 127.0.0.1
-------------------------------------
 IP : 192.168.1.10
-------------------------------------

Where 192.168.1.10 is the wrong address. For the sake of this example, our “correct” address will be defined as 10.1.1.10. [more]

Now, there are two ways you can resolve this, the first is running “httpcfg delete 192.168.1.10” followed by “httpcfg set 10.192.0.10” which should resolve the problem. In addition, I found a knowledge base article (http://support.microsoft.com/default.aspx?scid=kb;en-us;890015) that explained how to reconfigure the IP addresses from the registry. After running through the instructions, followed by another iisreset, I got the following from my “httpcfg query iplisten” command:

 IP : 127.0.0.1
-------------------------------------
 IP : 10.1.1.10
-------------------------------------

Problem solved.

When new user profiles are created on a server, it is worthy to note that the profile gets created from the “All Users” profile.  Since the “All Users” group is used as a template in creating the new user’s initial profile, it is important that any settings in the “Application Data” directory that users need also be copied to the “All Users\Application Data” directory also.  This should prevent any problems with new users having different settings than other users that may have had their settings adjusted.

Not too long ago I had a problem updating my virus definitions on a VMware virtual machine.  When I tried to update my Symantec virus definitions on my virtual machine, I kept getting an error message saying my machine could not access a long-named vmdk file.  It said if this file was on a remote computer, I should check my connection, and if it was not, I should check my hard drive (or something along those lines).  The message gave me the option to Retry, Abort, or Continue.  Retry and Continue both made the same error message pop up, and Abort shut my vm down (without deleting some lck files, preventing me from restarting my vm until I manually deleted those).  I tried running different versions of VMs (XP and two Windows 7 machines) and got the same error.   I also didn’t get the error when running Microsoft Updates…only Symantec LiveUpdate.  I had to reinstall VM Workstation to get it to work and I haven’t gotten that error since.

I set up an distribution group on our Exchange server for when we need to communicate with a new customer.  Email to the group from the inside worked fine, but any external mail sent to the address would bounce with a generic "Unknown recipient".  I asked a couple of our other network engineers to look at it, and one of them found the RequireSenderAuthenticationEnabled attribute was set to true, so he changed it with this command: [more]

"Set-DistributionGroup "groupname" -RequireSenderAuthenticationEnabled $false".