Computer Trouble Thing



Internet Connectivity issue with Windows 2003 network

The basic setup involved c. 12 client PC's using a 100BaseT switch connected to a LAN NIC on a dual-homed HP Proliant server running Advanced Server 2003. The WAN NIC of the server was connected to Broadband ADSL via a 4 port router.
Problem:  The PC clients lost connectivity with internet supposedly after the server was re-powered. It was thought that updates had recently been applied before the reset occurred.

The original settings -
ADSL/ISP Static IP: 217.74.XX.58
Router IP: 192.168.254.254
DHCP enabled

Server running Server 2003 EE as DC with Active Directory installed
NIC 1 - Static IP: 192.168.254.5 (external broadband route - using EN5861 BT router)
Mask: 255.255.255.0
Default Gateway (DGW): 192.168.254.254
DNS: 192.168.0.1
NIC 2 - Static IP: 192.168.0.1 (internal network - c. 12 XP Pro SP2 clients via 24 port switch)
Mask: 255.255.255.0
DGW: blank
DNS: 192.168.0.1
DHCP enabled (0.200 ~ 0.254)
Routing & Remote Access (RRAS) not configured
IP routing not enabled
Windows Firewall enabled
DNS Forwarder: 192.168.254.254
No static or persistent routes in place (Route Print)

Initial testing showed -
Client pings 192.168.0.1 OK
192.168.254.5 OK
192.168.254.254 Fail (Request Time Out)

Solution:

Initially tried to set IP routing with a registry hack but no good.

Check -
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\
DWORD IPEnableRouter set to 1 (This was later found to be reset to 0 and remained so even after RRAS was configured)

Not having dealt with Windows 2003 before and after much swotting I found -

1 - Internet Connection Sharing/Internet Connection Firewall (ICS/ICF) should not be used on Server 2003, RRAS with NAT/Basic FW is preferable
2 - The server should be used for DNS and any further queries can be routed by the Forwarder to the internet
3 - IP routing can be enabled without RRAS or ICS being enabled
4 - The default IP for the external NIC (WAN) when ICS is used happens to be 192.168.0.1
5 - NetBIOS over TCPIP and WINS is only required for legacy OS machines (9X, NT, etc)
6 - The external NIC should only have TCPIP enabled (not File and Print Sharing or Microsoft Client)
7 - Active Directory relies on DNS
8 - DNS needs to be setup well
9 - DNS Reverse lookup zones are required for utilities such as NSLookup

I tried to disable the ICS/ICF via the Services and Registry with mixed results. I was able to configure RRAS but when I later disabled RRAS for troubleshooting I found I couldn't re-configure it because ICS/ICF was in use.

I suspected that ICS/ICF functionality may have been implemented at some stage (especially since 192.168.0.1 had been used ) but there was no ICS tickbox available to disable the ICS, possibly it may have been hidden by an update prior to the reset.
So to the process that improved the situation -

Applied KB897616 - this is a hotfix to restore the ICS tickbox to the Advanced tab of the NIC properties which is removed after particular MS updates are applied, probably because ICS is not meant to be used on Server 2003

This indeed showed that ICS was enabled against the NIC and so was unchecked. This removed the TCP/IP settings of the internal network NIC (192.168.0.1)

Note: I suspect the server setup was a bit dodgy all along because the ICS should have at least been set against the external NIC and having 192.168.0.1 on the external NIC of a home PC would be quite normal but not necessarily so with a Server 2003 setup.

Both the server NIC's were checked and reconfigured as necessary.

The Services was checked to ensure the ICS and Windows Firewall services were off and disabled.

The RRAS could now be configured using NAT with Basic Firewall.

Note: When I checked this I found the NAT had been placed against the internal NIC - it was either a typo during the setup or the 192.168.0.1 IP was automatically detected for the NAT. I expect that with a correct fresh install these issues wouldn't occur but if I was designing the setup again I would avoid using 192.168.0.0 as the internal network.

The NAT settings in RRAS were readjusted to place NAT against the external NIC (192.168.254.5).

Check -
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RemoteAccess\
DWORD ConfigurationFlags set to 1 (Found that this key is set to 1 when the RRAS is configured)

Check -
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\
DWORD IPEnableRouter set to 0 (RRAS didn't set this at all)

Initially the setup still didn't work but the next day I found it to be working - I suspect that the DNS setup was not perfect and it took a scheduled auto update to occur to correct the situation.

Final working setup:

BT Broadband ADSL
Static IP: 217.74.XX.58
Router IP: 192.168.254.254
DHCP enabled

Server running Server 2003 EE as DC with Active Directory installed
NIC 1 - Static IP: 192.168.254.5 (external broadband route - using EN5861 BT router)
Mask: 255.255.255.0
DGW: 192.168.254.254
DNS: 192.168.0.1
NIC 2 - Static IP: 192.168.0.1 (internal network - c. 12 XP Pro SP2 clients via 24 port switch)
Mask: 255.255.255.0
DGW: blank
DNS: 192.168.0.1
DHCP enabled (0.200 ~ 0.254)
RRAS configured with NAT/Basic Firewall against NIC1
IP routing not enabled
ICS disabled Windows Firewall disabled
DNS Forwarder: 217.74.XX.58 (current static IP from ISP - should really be the ISP's DNS servers)
No static or persistent routes in place (Route Print)


Note: If DGW of NIC1 was set to 192.168.254.5 then clients could ping router but server couldn't.
If DNS Forwarder set to 192.168.254.254 then clients couldn't HTTP to internet (no DNS).

It took a while to find this one but easy in the end. Basically the old arrangement must have had ICS enabled with 192.168.0.1 conflicting and the updates applied themselves with the reset of the server so turning the internet connection into a cabbage.

As a side issue I was finding that Internet Explorer was getting Page not Found on some accounts - this appeared to be some settings in IE for Proxy Server rather than Auto-detect.





nVidia driver problem brings PC to knees

PC Details:
Win 2000 Professional SP2
Creative 3D Blaster Riva TNT video card
Driver installed: 4.1.8.0
J2RE 1.4.1_01 in Mozilla 1.3

Using Mozilla (as I usually do) I had a problem when I viewed the following URL - http://www.nstc.org.nz/gallery.html

On scrolling down the page the trouble started when the standard Lake applet entered the screen - the screen went black and screen then froze. ^ Alt Del was useless and the PC needed a front panel reset.
This problem to occur with any Java applet on any site and would happen EVERY time so I considered it quite a catastrophic bug. 

The Event Viewer showed -
Source: nv Event ID 13
GR SW Notify error on 0000 88001c00 00000042 00000304 10003D00 00000002

I re-installed the nVidia driver with standard Microsoft nVidia driver and applet views were then OK, no problems.

nv4.sys 5.00.2165.0327 30/9/1999
nv4.dll 5.00.2160.0327 30/9/1999


I then installed the nVidia 4.4.0.3 driver and applet views were still OK, no problem.

The problem appeared to be with the nVidia 4.1.8.0 driver and fortunately the latest driver (at the time) fixed the problem.




Properties in Right-click context menu for folders not working in Explorer

Platform: XP Pro with SP1

This has been happening as an intermittent problem and getting annoying. The problem was basically down to an interaction problem with IIS and Zonealarm. When I did a reset of the IIS (iisreset in the cmd window) suddenly all the properties windows I had been trying to get popped up.

Further details of this problems can be found at -
www.murraymoffatt.com/software-problem-0005.html

The DependOnService registry fix as outlined tends to indicate that the W3SVC needs to be started before the TrueVector service is started.





Using Intel PRO/Wireless 2200BG card with Ethereal and Air Snare utilities


Setup:

IBM Thinkpad R51 with Intel PRO/Wireless 2200BG card
XP with SP2
ZoneAlarm 5.5.062.004

2200BG driver - Intel v 9.0.2.25
Ethereal v 0.10.12 (network sniffer/analyzer tool)
WinPcap 3.1 beta 4 (low level device driver for network applications)
Airsnare (a wireless intrusion/monitoring utility)

Initially tried the latest Intel driver since the IBM drivers always lag behind quite a few months and the Intel driver works in the Thinkpad just fine - I use the Intel client to control the wireless rather than the Microsoft or IBM Access one.

However I still could not get Ethereal or AirSnare to collect packets via the wireless card. It seems that the consensus is that the 2200BG card will not support promiscuous mode and Ethereal/WinPcap/Intel/Microsoft all point the finger at each other.

A workround is however possible that will allow AirSnare to work and Ethereal to collect packets in non-promiscuous mode

This site here held the key to an answer -

http://www.micro-logix.com/WinPcap/CardReport.asp?ID=29

The DIVX video gives a quick run down on creating a network bridge that will allow the apps to work however with SP2 installed the procedure is slightly different to that outlined in the video.


1) Open Network Connections
2) Select both the Wireless connection and another (I chose the 1394 Firewire since I don't normally use it) and then right-click and Create Bridge (this will take a few moments)
3) When the bridge is created go into properties and allocate an IP (if using DHCP this will happen when a Disable/Enable is done)
4) I found the wireless connection fired back up again under Intel control and browsing was OK however in order for the bridge to appear as a device in AirSnare or Ethereal I needed to restart the XP

After this procedure it was possible to monitor with the 2200BG card but I needed to disable the promiscuous mode in the options. It is only possible to monitor traffic for the particular PC and broadcast traffic. Other traffic would require the promiscuous mode to be working correctly.


UPDATE:


Using -

2200BG driver - Intel v 9.0.4.8 (IBM issue)
Ethereal v 0.10.14 (network sniffer/analyzer tool)
WinPcap 3.1 (low level device driver for network applications)


Found Ethereal monitored the 2200BG card OK without a bridge being required but still no promiscuous mode.


A bridge was created and the 2200BG card still worked OK with Ethereal. The following (MS KB 302348) was tried to enable promiscuous mode on the card but didn't work -


In the XP CMD window


>netsh bridge show adapter


     should give ID and status of adaptor


>netsh bridge set adapter x forcecompatmode=enable   (where x is ID)
 

     sets the promiscuous mode


Not surprising really since Intel still don't support promiscuous mode on the Centrino adapters but it is always worth a try - at least Ethereal and WinPcap seem to be doing the right thing now.




Persistent CHKDSK issue with XP on boot up

Not a usual occurrence but I had a situation where a faulty appliance (an iron actually) managed to kill the PC's, etc.

Naturally as XP booted up again it went into the ol' "check disks for inconsistencies" routine. A number of partitions required checking and all went OK but the I: drive had a problem where the three normal checks (Files,Indexes & Security Descriptors) completed OK but then the system would just hang.


The Event Viewer showed an entry -

Type: Error Event ID: 55 Source: ntfs Category: Disk

Description: The file system structure on the disk is corrupt and unusable. Please run chkdsk utility on volume I:

Symbolic Name: IO_FILE_SYSTEM_CORRUPT_WITH_NAME


Checking the Disk Management applet showed the partition to be healthy.

Since chkdsk on boot up wasn't working I thought I'd use Partition Magic 8.0 to test the partition - a few errors were found and fixed.

Tried to boot XP and still faulty.

I reformatted the I: partition with PM (luckily this was a spare partition).

Tried to boot XP and still faulty.

Back to chkdsk from command line - from RUN>CMD I did chkntfs I: and got "Disk is dirty" so then used chkdsk /x and then /R to no avail.

Tried SeaTools diagnostics and the partition wasn't a recognised type so couldn't test it.

My final shot was to try the format from the XP Disk Management applet and remarkably it did the trick.

The PC booted without a hitch.


Unfortunately this just confirms my fear that there are two ways of formatting an XP NTFS partition - Microsoft's and everybody elses's




Printer Sharing on XP Pro SP1

Whether it is a real problem or just a quirk of my particular install of XP there is a problem with applying a share to a printer.

I check the "Share this printer" radio button and the Share name text box populates with a suggested name of 8 chrs in length. Changing this usually gets mixed results but if I accept the suggestion and APPLY or OK the applet goes into a "Not Responding" state. I need to close the window and after a few flash of the desktop graphics the system recovers. On viewing the printer in the Printers and Faxes part of the Control Panel the printer appears shared however if I go the the Sharing tab I see an erroneous name such as EpsonSty.2 and viewing the registry confirms that the share hasn't been fully applied.

Particular registry entries I check are -

HKLM/SYSTEM/CurrentControlSet/Control/Print/Printers/Epson Stylus 
COLOR 740 ESC/P 2

Share Name REG_SZ EpsonSty

HKLM/SYSTEM/CurrentControlSet/Control/Print/Printers/Epson Stylus 
COLOR 740 ESC/P 2/DsSpooler

printShareName REG_SZ EpsonSty (this is missing usually)


If the sharing is disabled and re-enabled then the same happens but the suggested name just increments - eg:

EpsonSty becomes EpsonSty.2 then EpsonSty.3, etc

It seems a bit hit and miss but to resolve the issue I did the following which appears to work.


Unplug USB printer

Disable the share

Delete the printer

Use Regedit -

Clear out entries such as EpsonSty, EpsonSty.2, etc from various keys as below.

HKCU/Software/Microsoft/Windows/CurrentVersion/Explorer/
WorkgroupCrawler/Printers/

HKLM/SYSTEM/ControlSet001/Services/lanmanserver/Shares/

Close Regedit and restart PC. The only stuff left should be the old driver installs which are OK.

Plug in USB printer and XP should soon pick it up and then acknowledge it has been installed because the drivers are still in place.