Windows Server 2003 R2 Standard Edition SP2 Mapped Drive Access Problem

We have experienced a strange issue with access to mapped drives on
our Windows Server 2003 several times now. We have two "servers" on
our network: 1) Windows Server 2003 R2 Standard Edition SP2, the
domain controller and file & print server; 2) Windows XP Pro SP3,
email & FTP server. Three times now, weeks apart, users have been
able to login to the server in the morning but locally mapped drives
to Server #1 would not connect nor did they have access to the email
or FTP servers (on Server #2). Upon checking, it was found that
although Server #2 was powered up, it was in an unresponsive mode.
Simply powering Server#2 down allows user's mapped drives to connect
to Server #1 with no direct action taken on their part.

Since this has happened three times now, I know there is some sort of
issue with Server #2 and that issue is somehow compromising mapped
drive connectivity to Server #1. However, what I really find strange
is when this issue manifests itself, users can login to Server #1 (all
logins are done to the domain controller). There are no messages
presented to users to the effect that the domain controller is not
available and login will proceed to the local computer. But, after
login, file and print access to the domain controller (Server #1) is
not possible. Can anyone shed any light on what Server #2 could be
doing when in its funny mode that prevents mapped drive connectivity
to Server #1 but not prevent user login to Server #1 (domain
controller)?

With respect to Server #2, the first time this issue happened the
effect it had on Server #1 was not yet known (after this issue
happened the second time, the effect was realiized). Once it was
discovered non-responsive it was powered down and back on. It would
not boot. A message stating an OS could not be found was presented.
After two more attempts to reboot, it did boot up and ran for several
weeks without issue. Then, exactly the same thing happened. This
time, it would not reboot at all. I had to re-install the OS and
recover from a system state backup. At this time, larger drives were
installed. I should note that each time this issue has happened, it
happened after completion of the day's scheduled backup (NTBackup) to
a second drive in the computer. No entries were found in the Event
Log between end of the backup and restart of the computer.

The issue happened again last night. Exact same effect on Server #1.
Server #2 was on but unresponsive. Powering down corrected the mapped
drive issue to Server #1. Upon power up, the computer went into a
ChkDsk procedure (I failed to note on which drive) which completed
successfully. Server #2 then booted OK. Upon checking after boot, I
found no entries in the Event Log between completion of the backup and
the reboot. I did, though, find entries indicating an issue with the
second HDD, not the boot drive, which caused the ChkDsk on reboot.

Server #2 is a 1.6 GHz Pentium 4 with 1GB RAM. Both HDD are 320GB.
Can anyone shed any light on what could be happening in this machine
to cause the issues explained (it becoming non-responsive and its
effect on network user mapped drive connectivity to the domain
controller)?

Thanks in advance for your assistance.
--
System Administrator
Sprotte + Watson Architecture and Planning
Vista, CA

 

"System Administrator" <sysadmin.removethis@sprottewatson.com> wrote in
message news:4aa14b97.1113530187@msnews.microsoft.com...<!--coloro:blue--><span style="color:blue <!--/coloro-->
> We have experienced a strange issue with access to mapped drives on
> our Windows Server 2003 several times now. We have two "servers" on
> our network: 1) Windows Server 2003 R2 Standard Edition SP2, the
> domain controller and file & print server; 2) Windows XP Pro SP3,
> email & FTP server. Three times now, weeks apart, users have been
> able to login to the server in the morning but locally mapped drives
> to Server #1 would not connect nor did they have access to the email
> or FTP servers (on Server #2). Upon checking, it was found that
> although Server #2 was powered up, it was in an unresponsive mode.
> Simply powering Server#2 down allows user's mapped drives to connect
> to Server #1 with no direct action taken on their part.
>
> Since this has happened three times now, I know there is some sort of
> issue with Server #2 and that issue is somehow compromising mapped
> drive connectivity to Server #1. However, what I really find strange
> is when this issue manifests itself, users can login to Server #1 (all
> logins are done to the domain controller). There are no messages
> presented to users to the effect that the domain controller is not
> available and login will proceed to the local computer. But, after
> login, file and print access to the domain controller (Server #1) is
> not possible. Can anyone shed any light on what Server #2 could be
> doing when in its funny mode that prevents mapped drive connectivity
> to Server #1 but not prevent user login to Server #1 (domain
> controller)?
>
> With respect to Server #2, the first time this issue happened the
> effect it had on Server #1 was not yet known (after this issue
> happened the second time, the effect was realiized). Once it was
> discovered non-responsive it was powered down and back on. It would
> not boot. A message stating an OS could not be found was presented.
> After two more attempts to reboot, it did boot up and ran for several
> weeks without issue. Then, exactly the same thing happened. This
> time, it would not reboot at all. I had to re-install the OS and
> recover from a system state backup. At this time, larger drives were
> installed. I should note that each time this issue has happened, it
> happened after completion of the day's scheduled backup (NTBackup) to
> a second drive in the computer. No entries were found in the Event
> Log between end of the backup and restart of the computer.
>
> The issue happened again last night. Exact same effect on Server #1.
> Server #2 was on but unresponsive. Powering down corrected the mapped
> drive issue to Server #1. Upon power up, the computer went into a
> ChkDsk procedure (I failed to note on which drive) which completed
> successfully. Server #2 then booted OK. Upon checking after boot, I
> found no entries in the Event Log between completion of the backup and
> the reboot. I did, though, find entries indicating an issue with the
> second HDD, not the boot drive, which caused the ChkDsk on reboot.
>
> Server #2 is a 1.6 GHz Pentium 4 with 1GB RAM. Both HDD are 320GB.
> Can anyone shed any light on what could be happening in this machine
> to cause the issues explained (it becoming non-responsive and its
> effect on network user mapped drive connectivity to the domain
> controller)?
>
> Thanks in advance for your assistance.
> --
> System Administrator
> Sprotte + Watson Architecture and Planning
> Vista, CA
><!--colorc--><!--/colorc-->


This sounds like a classic DNS mis-config. To confirm and evaluate your
configuration or to at least eliminate this possibility, we'll need an
unedited ipconfig /all of both servers, your DC and a sample workstation.

Also, when you stated you powered down a workstation, did you shut it off
using the power button, or did you choose start/shutdown or restart? Power
button shutdowns, if done too many times, may result in chckdsk firing up.


--
Ace

This posting is provided "AS-IS" with no warranties or guarantees and
confers no rights.

Please reply back to the newsgroup or forum for collaboration benefit among
responding engineers, and to help others benefit from your resolution.

Ace Fekay, MCT, MCTS Exchange, MCSE, MCSA 2003 & 2000, MCSA Messaging
Microsoft Certified Trainer

For urgent issues, please contact Microsoft PSS directly. Please check
for regional support phone numbers.

 

Thanks for the quick response. Below you will find the ipconfig /all
for the two servers and a workstation. Please note that Server #1
(SRVR1) is the domain controller.

With respect to Server #2, by "unresponsive" I meant that, although
powered on, it was not putting out any signal to the attached monitor
and it did not respond to any keyboard or mouse input. It was powered
down by holding in the power button until shutdown occurred.

IPConfig /all:

--Server #1 (SRVR1, domain controller):

Windows IP Configuration
Host Name . . . . . . . . . . . . : srvr1
Primary Dns Suffix . . . . . . . : lan.sprottewatson.com
Node Type . . . . . . . . . . . . : Unknown
IP Routing Enabled. . . . . . . . : Yes
WINS Proxy Enabled. . . . . . . . : Yes
DNS Suffix Search List. . . . . . : lan.sprottewatson.com
sprottewatson.com
Ethernet adapter Local Area Connection 2:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Intel® PRO/1000 MT Network
Connection
Physical Address. . . . . . . . . : 00-0E-0C-A4-0A-75
DHCP Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : 192.168.0.202
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.0.1
DNS Servers . . . . . . . . . . . : 192.168.0.202

--Server #2 (SRVR2, email & FTP, WinXPPro)

Windows IP Configuration
Host Name . . . . . . . . . . . . : SRVR2
Primary Dns Suffix . . . . . . . : lan.sprottewatson.com
Node Type . . . . . . . . . . . . : Unknown
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : lan.sprottewatson.com
sprottewatson.com
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : Intel® PRO/100 VE
Network Connection
Physical Address. . . . . . . . . : 00-03-47-F2-B4-FB
Dhcp Enabled. . . . . . . . . . . : No
IP Address. . . . . . . . . . . . : 192.168.0.201
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.0.1
DNS Servers . . . . . . . . . . . : 192.168.0.202
192.168.0.1

--Workstation (John1, WinXPPro)

Windows IP Configuration
Host Name . . . . . . . . . . . . : JOHN1
Primary Dns Suffix . . . . . . . : lan.sprottewatson.com
Node Type . . . . . . . . . . . . : Hybrid
IP Routing Enabled. . . . . . . . : No
WINS Proxy Enabled. . . . . . . . : No
DNS Suffix Search List. . . . . . : lan.sprottewatson.com
lan.sprottewatson.com
sprottewatson.com
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . : lan.sprottewatson.com
Description . . . . . . . . . . . : Broadcom NetLink ™
Gigabit Ethernet
Physical Address. . . . . . . . . : 00-0F-EA-EC-40-76
Dhcp Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
IP Address. . . . . . . . . . . . : 192.168.0.15
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.0.1
DHCP Server . . . . . . . . . . . : 192.168.0.202
DNS Servers . . . . . . . . . . . : 192.168.0.202
Primary WINS Server . . . . . . . : 192.168.0.202
Lease Obtained. . . . . . . . . . : Friday, September 04, 2009
9:30:45 AM
Lease Expires . . . . . . . . . . : Sunday, October 04, 2009
9:30:45 AM

Thanks for your continued assistance.



On Fri, 4 Sep 2009 14:08:27 -0400, "Ace Fekay [MCT]"
<aceman@mvps.RemoveThisPart.org> wrote:
<!--coloro:blue--><span style="color:blue <!--/coloro-->
>"System Administrator" <sysadmin.removethis@sprottewatson.com> wrote in
>message news:4aa14b97.1113530187@msnews.microsoft.com...<!--coloro:green--><span style="color:green <!--/coloro-->
>> We have experienced a strange issue with access to mapped drives on
>> our Windows Server 2003 several times now. We have two "servers" on
>> our network: 1) Windows Server 2003 R2 Standard Edition SP2, the
>> domain controller and file & print server; 2) Windows XP Pro SP3,
>> email & FTP server. Three times now, weeks apart, users have been
>> able to login to the server in the morning but locally mapped drives
>> to Server #1 would not connect nor did they have access to the email
>> or FTP servers (on Server #2). Upon checking, it was found that
>> although Server #2 was powered up, it was in an unresponsive mode.
>> Simply powering Server#2 down allows user's mapped drives to connect
>> to Server #1 with no direct action taken on their part.
>>
>> Since this has happened three times now, I know there is some sort of
>> issue with Server #2 and that issue is somehow compromising mapped
>> drive connectivity to Server #1. However, what I really find strange
>> is when this issue manifests itself, users can login to Server #1 (all
>> logins are done to the domain controller). There are no messages
>> presented to users to the effect that the domain controller is not
>> available and login will proceed to the local computer. But, after
>> login, file and print access to the domain controller (Server #1) is
>> not possible. Can anyone shed any light on what Server #2 could be
>> doing when in its funny mode that prevents mapped drive connectivity
>> to Server #1 but not prevent user login to Server #1 (domain
>> controller)?
>>
>> With respect to Server #2, the first time this issue happened the
>> effect it had on Server #1 was not yet known (after this issue
>> happened the second time, the effect was realiized). Once it was
>> discovered non-responsive it was powered down and back on. It would
>> not boot. A message stating an OS could not be found was presented.
>> After two more attempts to reboot, it did boot up and ran for several
>> weeks without issue. Then, exactly the same thing happened. This
>> time, it would not reboot at all. I had to re-install the OS and
>> recover from a system state backup. At this time, larger drives were
>> installed. I should note that each time this issue has happened, it
>> happened after completion of the day's scheduled backup (NTBackup) to
>> a second drive in the computer. No entries were found in the Event
>> Log between end of the backup and restart of the computer.
>>
>> The issue happened again last night. Exact same effect on Server #1.
>> Server #2 was on but unresponsive. Powering down corrected the mapped
>> drive issue to Server #1. Upon power up, the computer went into a
>> ChkDsk procedure (I failed to note on which drive) which completed
>> successfully. Server #2 then booted OK. Upon checking after boot, I
>> found no entries in the Event Log between completion of the backup and
>> the reboot. I did, though, find entries indicating an issue with the
>> second HDD, not the boot drive, which caused the ChkDsk on reboot.
>>
>> Server #2 is a 1.6 GHz Pentium 4 with 1GB RAM. Both HDD are 320GB.
>> Can anyone shed any light on what could be happening in this machine
>> to cause the issues explained (it becoming non-responsive and its
>> effect on network user mapped drive connectivity to the domain
>> controller)?
>>
>> Thanks in advance for your assistance.
>> --
>> System Administrator
>> Sprotte + Watson Architecture and Planning
>> Vista, CA
>><!--colorc--><!--/colorc-->
>
>
>This sounds like a classic DNS mis-config. To confirm and evaluate your
>configuration or to at least eliminate this possibility, we'll need an
>unedited ipconfig /all of both servers, your DC and a sample workstation.
>
>Also, when you stated you powered down a workstation, did you shut it off
>using the power button, or did you choose start/shutdown or restart? Power
>button shutdowns, if done too many times, may result in chckdsk firing up.
>
>
>--
>Ace
>
>This posting is provided "AS-IS" with no warranties or guarantees and
>confers no rights.
>
>Please reply back to the newsgroup or forum for collaboration benefit among
>responding engineers, and to help others benefit from your resolution.
>
>Ace Fekay, MCT, MCTS Exchange, MCSE, MCSA 2003 & 2000, MCSA Messaging
>Microsoft Certified Trainer
>
>For urgent issues, please contact Microsoft PSS directly. Please check
> for regional support phone numbers.
>
><!--colorc--><!--/colorc-->

--
System Administrator
Sprotte + Watson Architecture and Planning
Vista, CA

 

"System Administrator" <sysadmin.removethis@sprottewatson.com> wrote in
message news:4aa16024.1118790781@msnews.microsoft.com...<!--coloro:blue--><span style="color:blue <!--/coloro-->
> Thanks for the quick response. Below you will find the ipconfig /all
> for the two servers and a workstation. Please note that Server #1
> (SRVR1) is the domain controller.
>
> With respect to Server #2, by "unresponsive" I meant that, although
> powered on, it was not putting out any signal to the attached monitor
> and it did not respond to any keyboard or mouse input. It was powered
> down by holding in the power button until shutdown occurred.
>
> IPConfig /all:
>
> --Server #1 (SRVR1, domain controller):
>
> Windows IP Configuration
> Host Name . . . . . . . . . . . . : srvr1
> Primary Dns Suffix . . . . . . . : lan.sprottewatson.com
> Node Type . . . . . . . . . . . . : Unknown
> IP Routing Enabled. . . . . . . . : Yes
> WINS Proxy Enabled. . . . . . . . : Yes
> DNS Suffix Search List. . . . . . : lan.sprottewatson.com
> sprottewatson.com
> Ethernet adapter Local Area Connection 2:
> Connection-specific DNS Suffix . :
> Description . . . . . . . . . . . : Intel® PRO/1000 MT Network
> Connection
> Physical Address. . . . . . . . . : 00-0E-0C-A4-0A-75
> DHCP Enabled. . . . . . . . . . . : No
> IP Address. . . . . . . . . . . . : 192.168.0.202
> Subnet Mask . . . . . . . . . . . : 255.255.255.0
> Default Gateway . . . . . . . . . : 192.168.0.1
> DNS Servers . . . . . . . . . . . : 192.168.0.202
>
> --Server #2 (SRVR2, email & FTP, WinXPPro)
>
> Windows IP Configuration
> Host Name . . . . . . . . . . . . : SRVR2
> Primary Dns Suffix . . . . . . . : lan.sprottewatson.com
> Node Type . . . . . . . . . . . . : Unknown
> IP Routing Enabled. . . . . . . . : No
> WINS Proxy Enabled. . . . . . . . : No
> DNS Suffix Search List. . . . . . : lan.sprottewatson.com
> sprottewatson.com
> Ethernet adapter Local Area Connection:
> Connection-specific DNS Suffix . :
> Description . . . . . . . . . . . : Intel® PRO/100 VE
> Network Connection
> Physical Address. . . . . . . . . : 00-03-47-F2-B4-FB
> Dhcp Enabled. . . . . . . . . . . : No
> IP Address. . . . . . . . . . . . : 192.168.0.201
> Subnet Mask . . . . . . . . . . . : 255.255.255.0
> Default Gateway . . . . . . . . . : 192.168.0.1
> DNS Servers . . . . . . . . . . . : 192.168.0.202
> 192.168.0.1
>
> --Workstation (John1, WinXPPro)
>
> Windows IP Configuration
> Host Name . . . . . . . . . . . . : JOHN1
> Primary Dns Suffix . . . . . . . : lan.sprottewatson.com
> Node Type . . . . . . . . . . . . : Hybrid
> IP Routing Enabled. . . . . . . . : No
> WINS Proxy Enabled. . . . . . . . : No
> DNS Suffix Search List. . . . . . : lan.sprottewatson.com
> lan.sprottewatson.com
> sprottewatson.com
> Ethernet adapter Local Area Connection:
> Connection-specific DNS Suffix . : lan.sprottewatson.com
> Description . . . . . . . . . . . : Broadcom NetLink ™
> Gigabit Ethernet
> Physical Address. . . . . . . . . : 00-0F-EA-EC-40-76
> Dhcp Enabled. . . . . . . . . . . : Yes
> Autoconfiguration Enabled . . . . : Yes
> IP Address. . . . . . . . . . . . : 192.168.0.15
> Subnet Mask . . . . . . . . . . . : 255.255.255.0
> Default Gateway . . . . . . . . . : 192.168.0.1
> DHCP Server . . . . . . . . . . . : 192.168.0.202
> DNS Servers . . . . . . . . . . . : 192.168.0.202
> Primary WINS Server . . . . . . . : 192.168.0.202
> Lease Obtained. . . . . . . . . . : Friday, September 04, 2009
> 9:30:45 AM
> Lease Expires . . . . . . . . . . : Sunday, October 04, 2009
> 9:30:45 AM
>
> Thanks for your continued assistance.<!--colorc--><!--/colorc-->


You are welcome, so far.

From what I see, I suggest to make the following changes, please:

On Server1:
=======
1. IP routing is enabled. This can and will cause problems with AD, such as
with logons and authentication. I suggest disabling IP routing on it.
How to disable IP routing - You need to edit the following registry key
value to 0 (zero), which means disabled:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Value Name: IPEnableRouter
Value type: REG_DWORD
Value Data: 0

2. Same with WINS proxy. No need for that. Disable it.
Disable WINS proxy - To disable wins proxy, go to
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netbt\Parameters,
change the value to 0.

Value Name: EnableProxy
Value Type: REG_DWORD
Values: Boolean (0 or 1)
Default: 0

3. You also MUST, yes, MUST set a static configuration on this machine. This
is a domain controller. It must be set wtih a static IP configuration.
Domain controllers do not work well with as a DHCP client, since they also
run other services, such as DNS, DHCP (if using it on there), and WINS. This
is a MUST.

4. In DNS properties, Forwarding tab, configure a forwarder to your ISP. You
can also use 4.2.2.2 and 4.2.2.3. They are reliable forwarders. This will
offload internet resolution requests from your client machines.


On server2:
========
1. Remove 192.068.0.1 as a DNS server. That IP is your router. That thing
has no clue of your AD infrastructure. Just leave .202 in as a DNS server.

2. Reboot it. Check the event log. Post any errors you see by posting the
EventID# and source name.

3. Let us know if it still locks up.


On the workstation:
=======

1. The workstation ipconfig looks fine. Just an FYI, all client machines
must only use 192.168.0.202 for DNS. If there are any static configured
workstations, make sure they only use .202 as DNS.



Ace

 

Thanks, again, for you quick response.

First, I would like to point out that the current configuration of the
domain controller, the email server, and workstations have been in
effect since day 1 of this domain controller installation, which is
several years now. There have been no issues regarding network
operation or performance until the email server began going into the
funky state reported, the first instance of such was about three
months ago. I do not see how the machine configurations have anything
to do with the reported issue. That said, here are the answers to
your "questions":

Server #1:

1. The HKLM key is already set to 0
2. The HKLM key is set to 2
3. A static IP is set. The DHCP server component is active for
network machines.
4. The only forwarding site configured is the local domain. I was
under the impression that if a lookup failed locally, the DNS server
would automatically use one or more of the "global master" DNS
servers. Our network has less than 20 machines connected at any given
time. As such, I do not feel DNS lookups have a significant impact on
machine performance.

Server #2:

1. 192.168.0.1 was added only to allow the machine to gain access to
a DNS server in the event the primary DNS (DC) was not available.
Since this setting is for the secondary DNS, it should never be used
unless the primary DNS is not available.

2. Upon rebooting earlier today, after it was found unresponsive, it
went to ChkDsk mode and then to a login screen. After login, the only
events shown were disk issues with HDD #2 (Drive E) and then the
normal, successful, boot up entries.

3. Locking up, as you put, has been random for about three months
now. I can't predict if/when it will happen again. As mentioned, the
unresponsiveness is manifested by no video signal being issued to the
monitor and no reaction to keyboard or mouse input. The power button
must be pressed until the machine shuts down. Upon reboot from this
mode, it has 1) taken two attempts the first time; 2) resulted in a
corrupted OS the second time; and 3) going into ChkDsk on the
secondary HDD (Drive E) this time.

Workstations:

All user workstations are using DHCP and only the DC is pointed to
for DNS.


I appreciate greatly your assistance in this matter. However, I
really do not see how the items you have asked me to look at and
modify have any relation to what is happening in Server #2.

One other piece of information I found out just recently is that when
users attempted to login this morning, the login process took a very
long period of time. Once logged in, though, their mapped drives to
the DC did not connect. It is my guess that the timeout period for
login is much longer than for mapped drive connections. Thus the
successful login but failed drive mappings. Based on this new
information, it is now my belief that when Server #2 goes into the
funky state it gets into, that it is putting out lots of garbage
traffic on its network interface, possibly even directly to the DC.
That traffic is greatly slowing down all other traffic on the network.
That traffic slowdown results in the long login times and failed
drive mappings. (I will have to look at the network switch lights
next time it happens to see what they have to say.) Further, as you
said, the powering down of Server #2 is probably causing the file
corruptions noted. That leads one to wonder what is actually
happening in Server #2 and how to fix it. Any ideas?

Thanks, again.



On Fri, 4 Sep 2009 15:36:56 -0400, "Ace Fekay [MCT]"
<aceman@mvps.RemoveThisPart.org> wrote:
<!--coloro:blue--><span style="color:blue <!--/coloro-->
>
>You are welcome, so far.
>
>From what I see, I suggest to make the following changes, please:
>
>On Server1:
>=======
>1. IP routing is enabled. This can and will cause problems with AD, such as
>with logons and authentication. I suggest disabling IP routing on it.
>How to disable IP routing - You need to edit the following registry key
>value to 0 (zero), which means disabled:
>
>HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters
>Value Name: IPEnableRouter
>Value type: REG_DWORD
>Value Data: 0
>
>2. Same with WINS proxy. No need for that. Disable it.
>Disable WINS proxy - To disable wins proxy, go to
>HKEY_LOCAL_MACHINESystemCurrentControlSetServicesNetbtParameters,
>change the value to 0.
>
> Value Name: EnableProxy
> Value Type: REG_DWORD
> Values: Boolean (0 or 1)
> Default: 0
>
>3. You also MUST, yes, MUST set a static configuration on this machine. This
>is a domain controller. It must be set wtih a static IP configuration.
>Domain controllers do not work well with as a DHCP client, since they also
>run other services, such as DNS, DHCP (if using it on there), and WINS. This
>is a MUST.
>
>4. In DNS properties, Forwarding tab, configure a forwarder to your ISP. You
>can also use 4.2.2.2 and 4.2.2.3. They are reliable forwarders. This will
>offload internet resolution requests from your client machines.
>
>
>On server2:
>========
>1. Remove 192.068.0.1 as a DNS server. That IP is your router. That thing
>has no clue of your AD infrastructure. Just leave .202 in as a DNS server.
>
>2. Reboot it. Check the event log. Post any errors you see by posting the
>EventID# and source name.
>
>3. Let us know if it still locks up.
>
>
>On the workstation:
>=======
>
>1. The workstation ipconfig looks fine. Just an FYI, all client machines
>must only use 192.168.0.202 for DNS. If there are any static configured
>workstations, make sure they only use .202 as DNS.
>
>
>
>Ace
>
>
>
><!--colorc--><!--/colorc-->

--
System Administrator
Sprotte + Watson Architecture and Planning
Vista, CA

 

"System Administrator" <sysadmin.removethis@sprottewatson.com> wrote in
message news:4aa17c5f.1126019906@msnews.microsoft.com...<!--coloro:blue--><span style="color:blue <!--/coloro-->
> Thanks, again, for you quick response.
>
> First, I would like to point out that the current configuration of the
> domain controller, the email server, and workstations have been in
> effect since day 1 of this domain controller installation, which is
> several years now. There have been no issues regarding network
> operation or performance until the email server began going into the
> funky state reported, the first instance of such was about three
> months ago. I do not see how the machine configurations have anything
> to do with the reported issue. That said, here are the answers to
> your "questions":
>
> Server #1:
>
> 1. The HKLM key is already set to 0
> 2. The HKLM key is set to 2
> 3. A static IP is set. The DHCP server component is active for
> network machines.
> 4. The only forwarding site configured is the local domain. I was
> under the impression that if a lookup failed locally, the DNS server
> would automatically use one or more of the "global master" DNS
> servers. Our network has less than 20 machines connected at any given
> time. As such, I do not feel DNS lookups have a significant impact on
> machine performance.
>
> Server #2:
>
> 1. 192.168.0.1 was added only to allow the machine to gain access to
> a DNS server in the event the primary DNS (DC) was not available.
> Since this setting is for the secondary DNS, it should never be used
> unless the primary DNS is not available.
>
> 2. Upon rebooting earlier today, after it was found unresponsive, it
> went to ChkDsk mode and then to a login screen. After login, the only
> events shown were disk issues with HDD #2 (Drive E) and then the
> normal, successful, boot up entries.
>
> 3. Locking up, as you put, has been random for about three months
> now. I can't predict if/when it will happen again. As mentioned, the
> unresponsiveness is manifested by no video signal being issued to the
> monitor and no reaction to keyboard or mouse input. The power button
> must be pressed until the machine shuts down. Upon reboot from this
> mode, it has 1) taken two attempts the first time; 2) resulted in a
> corrupted OS the second time; and 3) going into ChkDsk on the
> secondary HDD (Drive E) this time.
>
> Workstations:
>
> All user workstations are using DHCP and only the DC is pointed to
> for DNS.
>
>
> I appreciate greatly your assistance in this matter. However, I
> really do not see how the items you have asked me to look at and
> modify have any relation to what is happening in Server #2.
>
> One other piece of information I found out just recently is that when
> users attempted to login this morning, the login process took a very
> long period of time. Once logged in, though, their mapped drives to
> the DC did not connect. It is my guess that the timeout period for
> login is much longer than for mapped drive connections. Thus the
> successful login but failed drive mappings. Based on this new
> information, it is now my belief that when Server #2 goes into the
> funky state it gets into, that it is putting out lots of garbage
> traffic on its network interface, possibly even directly to the DC.
> That traffic is greatly slowing down all other traffic on the network.
> That traffic slowdown results in the long login times and failed
> drive mappings. (I will have to look at the network switch lights
> next time it happens to see what they have to say.) Further, as you
> said, the powering down of Server #2 is probably causing the file
> corruptions noted. That leads one to wonder what is actually
> happening in Server #2 and how to fix it. Any ideas?
>
> Thanks, again.<!--colorc--><!--/colorc-->



You are right that it doesn't have anything to do with the lockup. I think
the lockup may be due to a bad drive or controller. Are there any event log
errors? What type of controller is in the machine? Is there a management app
that came with it? Eg. Dell, HP, etc, come with management apps that allow
you to look at the health of a system's components. Maybe running a chkdsk
on it with the /F and /R switches to evaluate the drives, may be the first
thing to start with. Run chkdsk /? to see what the switches do.

However, evaluating your DNS config, I thought to point out a corrected,
recommended configuration. I'm sorry to hear you don't trust my
recommendations. Maybe if some of the others responding may formulate their
own recommendations or reiterate my recommendations, it may be more
convincing. I was just trying to help and guide you in a proper
configuration.

I do apologize about the DHCP setting on the DC. I misread that. I must have
been looking at the workstation config while scrolling up and down through
the post and mistakenly thought that was the DC.

However, IP routing does show enabled in the DC's ipconfig. If not enabled
in the reg, is it possible that the RRAS service is started? IP routing is
known to cause issues with authentication and other AD functions.

Keep in mind, 192.168.0.1 is your router. It's not a DNS server. With all
due respect, whether it will hit that server during a query or not, the
recommendation is to only use the internal DNS, in your case, your DC. So
let's say the local DNS service has a problem, it doesn't respond, the first
entry times out during a query, and then goes to the second one, which is
your router. Will that help logons, authentication or AD functions?

Instead of taking my word on it, maybe the following Microsoft articles may
help to understand what I'm referring to regarding AD and DNS settings.

825036 - Best practices for DNS client settings in Windows 2000 Server and
in Windows Server 2003 (including how-to configure a forwarder):


323380 - HOW TO: Configure DNS for Internet Access in Windows Server 2003
(How to configure a forwarder):


291382 - Frequently asked questions about Windows 2000 DNS and Windows
Server 2003 DNS


I hope I was helpful with the drive issue, and you've found my AD/DNS
comments educational.

Ace

 

RE: Windows Server 2003 R2 Standard Edition SP2 Mapped Drive Access Pr


Have you checked this issue on servers and clients?



This problem can resurface even after the option has been previously turned
off, and its symptoms do vary, so it is important to check for it in the
event of any connectivity issues.

"System Administrator" wrote:
<!--coloro:blue--><span style="color:blue <!--/coloro-->
> We have experienced a strange issue with access to mapped drives on
> our Windows Server 2003 several times now. We have two "servers" on
> our network: 1) Windows Server 2003 R2 Standard Edition SP2, the
> domain controller and file & print server; 2) Windows XP Pro SP3,
> email & FTP server. Three times now, weeks apart, users have been
> able to login to the server in the morning but locally mapped drives
> to Server #1 would not connect nor did they have access to the email
> or FTP servers (on Server #2). Upon checking, it was found that
> although Server #2 was powered up, it was in an unresponsive mode.
> Simply powering Server#2 down allows user's mapped drives to connect
> to Server #1 with no direct action taken on their part.
>
> Since this has happened three times now, I know there is some sort of
> issue with Server #2 and that issue is somehow compromising mapped
> drive connectivity to Server #1. However, what I really find strange
> is when this issue manifests itself, users can login to Server #1 (all
> logins are done to the domain controller). There are no messages
> presented to users to the effect that the domain controller is not
> available and login will proceed to the local computer. But, after
> login, file and print access to the domain controller (Server #1) is
> not possible. Can anyone shed any light on what Server #2 could be
> doing when in its funny mode that prevents mapped drive connectivity
> to Server #1 but not prevent user login to Server #1 (domain
> controller)?
>
> With respect to Server #2, the first time this issue happened the
> effect it had on Server #1 was not yet known (after this issue
> happened the second time, the effect was realiized). Once it was
> discovered non-responsive it was powered down and back on. It would
> not boot. A message stating an OS could not be found was presented.
> After two more attempts to reboot, it did boot up and ran for several
> weeks without issue. Then, exactly the same thing happened. This
> time, it would not reboot at all. I had to re-install the OS and
> recover from a system state backup. At this time, larger drives were
> installed. I should note that each time this issue has happened, it
> happened after completion of the day's scheduled backup (NTBackup) to
> a second drive in the computer. No entries were found in the Event
> Log between end of the backup and restart of the computer.
>
> The issue happened again last night. Exact same effect on Server #1.
> Server #2 was on but unresponsive. Powering down corrected the mapped
> drive issue to Server #1. Upon power up, the computer went into a
> ChkDsk procedure (I failed to note on which drive) which completed
> successfully. Server #2 then booted OK. Upon checking after boot, I
> found no entries in the Event Log between completion of the backup and
> the reboot. I did, though, find entries indicating an issue with the
> second HDD, not the boot drive, which caused the ChkDsk on reboot.
>
> Server #2 is a 1.6 GHz Pentium 4 with 1GB RAM. Both HDD are 320GB.
> Can anyone shed any light on what could be happening in this machine
> to cause the issues explained (it becoming non-responsive and its
> effect on network user mapped drive connectivity to the domain
> controller)?
>
> Thanks in advance for your assistance.
> --
> System Administrator
> Sprotte + Watson Architecture and Planning
> Vista, CA
>
> <!--colorc--><!--/colorc-->

 

Thanks, again, for your response. Sorry mine is late - I'm only at
this client one day per week normally.

Email Server: No, the lockup does not generate any events in the
event log. No management apps installed. No-name computer using an
Intel motherboard and only using the on-board controllers. Chkdsk on
both primary and secondary drives returned no issues. As mentioned
previously, the secondary DNS entry pointing to the router was only to
provide DNS services for times when the DC was down (monthly services)
and Internet access from the email server was needed. I have now
removed this pointer. Thank you for pointing out the possible issues
for having a non-DC secondary DNS configured. As of this writing, the
email server has been stable since its last crash (one week and
counting).

DC: I have checked the DNS configuration of the machine. The
Forwarding tab in the DNS Properties window shows forwarders to our
ISP's DNS servers configured. Sorry, I had forgotten that I had done
so. RRAS is active on the machine for VPN access.

Thanks for your assistance.
--


On Fri, 4 Sep 2009 20:07:00 -0400, "Ace Fekay [MCT]"
<aceman@mvps.RemoveThisPart.org> wrote:<!--coloro:blue--><span style="color:blue <!--/coloro-->
>
>You are right that it doesn't have anything to do with the lockup. I think
>the lockup may be due to a bad drive or controller. Are there any event log
>errors? What type of controller is in the machine? Is there a management app
>that came with it? Eg. Dell, HP, etc, come with management apps that allow
>you to look at the health of a system's components. Maybe running a chkdsk
>on it with the /F and /R switches to evaluate the drives, may be the first
>thing to start with. Run chkdsk /? to see what the switches do.
>
>However, evaluating your DNS config, I thought to point out a corrected,
>recommended configuration. I'm sorry to hear you don't trust my
>recommendations. Maybe if some of the others responding may formulate their
>own recommendations or reiterate my recommendations, it may be more
>convincing. I was just trying to help and guide you in a proper
>configuration.
>
>I do apologize about the DHCP setting on the DC. I misread that. I must have
>been looking at the workstation config while scrolling up and down through
>the post and mistakenly thought that was the DC.
>
>However, IP routing does show enabled in the DC's ipconfig. If not enabled
>in the reg, is it possible that the RRAS service is started? IP routing is
>known to cause issues with authentication and other AD functions.
>
>Keep in mind, 192.168.0.1 is your router. It's not a DNS server. With all
>due respect, whether it will hit that server during a query or not, the
>recommendation is to only use the internal DNS, in your case, your DC. So
>let's say the local DNS service has a problem, it doesn't respond, the first
>entry times out during a query, and then goes to the second one, which is
>your router. Will that help logons, authentication or AD functions?
>
>Instead of taking my word on it, maybe the following Microsoft articles may
>help to understand what I'm referring to regarding AD and DNS settings.
>
>825036 - Best practices for DNS client settings in Windows 2000 Server and
>in Windows Server 2003 (including how-to configure a forwarder):
>
>
>323380 - HOW TO: Configure DNS for Internet Access in Windows Server 2003
>(How to configure a forwarder):
>
>
>291382 - Frequently asked questions about Windows 2000 DNS and Windows
>Server 2003 DNS
>
>
>I hope I was helpful with the drive issue, and you've found my AD/DNS
>comments educational.
>
>Ace
><!--colorc--><!--/colorc-->

--
System Administrator
Sprotte + Watson Architecture and Planning
Vista, CA

 

"System Administrator" <sysadmin.removethis@sprottewatson.com> wrote in
message news:4aa9828c.1651895453@msnews.microsoft.com...

You are welcome! I'm glad to hear it hasn't crashed or locked up yet, and
there are no errors with the drive. With no-name brand mobos, it's hard to
diagnose if it is a controller or otehr problem, possibly even RAM.
Difficult to say. I've seen where RAM's the cause, however running all of
those mem tests on a machine show no problems, but it continues to occur,
yet when you swap the RAM out, it stops happening.Go figure...

The DNS thing with AD is important. Glad I was able to provide technical
information on it and was helpful.

As for VPN on a DC, that's one of the other things not suggested, and I
would recommend to offload it to a member server, or a hardware appliance.
Once again, it's because of the additional VPN interfaces that get
registered into DNS that can mess with AD.

Post back if you have any other questions.

Ace

<!--coloro:blue--><span style="color:blue <!--/coloro-->
> Thanks, again, for your response. Sorry mine is late - I'm only at
> this client one day per week normally.
>
> Email Server: No, the lockup does not generate any events in the
> event log. No management apps installed. No-name computer using an
> Intel motherboard and only using the on-board controllers. Chkdsk on
> both primary and secondary drives returned no issues. As mentioned
> previously, the secondary DNS entry pointing to the router was only to
> provide DNS services for times when the DC was down (monthly services)
> and Internet access from the email server was needed. I have now
> removed this pointer. Thank you for pointing out the possible issues
> for having a non-DC secondary DNS configured. As of this writing, the
> email server has been stable since its last crash (one week and
> counting).
>
> DC: I have checked the DNS configuration of the machine. The
> Forwarding tab in the DNS Properties window shows forwarders to our
> ISP's DNS servers configured. Sorry, I had forgotten that I had done
> so. RRAS is active on the machine for VPN access.
>
> Thanks for your assistance.
> --
>
>
> On Fri, 4 Sep 2009 20:07:00 -0400, "Ace Fekay [MCT]"
> <aceman@mvps.RemoveThisPart.org> wrote:<!--coloro:green--><span style="color:green <!--/coloro-->
>>
>>You are right that it doesn't have anything to do with the lockup. I think
>>the lockup may be due to a bad drive or controller. Are there any event
>>log
>>errors? What type of controller is in the machine? Is there a management
>>app
>>that came with it? Eg. Dell, HP, etc, come with management apps that allow
>>you to look at the health of a system's components. Maybe running a chkdsk
>>on it with the /F and /R switches to evaluate the drives, may be the first
>>thing to start with. Run chkdsk /? to see what the switches do.
>>
>>However, evaluating your DNS config, I thought to point out a corrected,
>>recommended configuration. I'm sorry to hear you don't trust my
>>recommendations. Maybe if some of the others responding may formulate
>>their
>>own recommendations or reiterate my recommendations, it may be more
>>convincing. I was just trying to help and guide you in a proper
>>configuration.
>>
>>I do apologize about the DHCP setting on the DC. I misread that. I must
>>have
>>been looking at the workstation config while scrolling up and down through
>>the post and mistakenly thought that was the DC.
>>
>>However, IP routing does show enabled in the DC's ipconfig. If not enabled
>>in the reg, is it possible that the RRAS service is started? IP routing is
>>known to cause issues with authentication and other AD functions.
>>
>>Keep in mind, 192.168.0.1 is your router. It's not a DNS server. With all
>>due respect, whether it will hit that server during a query or not, the
>>recommendation is to only use the internal DNS, in your case, your DC. So
>>let's say the local DNS service has a problem, it doesn't respond, the
>>first
>>entry times out during a query, and then goes to the second one, which is
>>your router. Will that help logons, authentication or AD functions?
>>
>>Instead of taking my word on it, maybe the following Microsoft articles
>>may
>>help to understand what I'm referring to regarding AD and DNS settings.
>>
>>825036 - Best practices for DNS client settings in Windows 2000 Server and
>>in Windows Server 2003 (including how-to configure a forwarder):
>>
>>
>>323380 - HOW TO: Configure DNS for Internet Access in Windows Server 2003
>>(How to configure a forwarder):
>>
>>
>>291382 - Frequently asked questions about Windows 2000 DNS and Windows
>>Server 2003 DNS
>>
>>
>>I hope I was helpful with the drive issue, and you've found my AD/DNS
>>comments educational.
>>
>>Ace
>><!--colorc--><!--/colorc-->
>
> --
> System Administrator
> Sprotte + Watson Architecture and Planning
> Vista, CA
><!--colorc--><!--/colorc-->

 

The email server continues to keep on ticking. Must be a Timex. Hi!
Hi!.

VPN is only configued for occasional access to the network by the
business owners. Hardly used at all. So far, its presence on the DC
has not caused any issues. There is nothing else to offload it onto
without obtaining additional hardware. Thanks for the heads up,
though.

Thanks, again, for your assistance.


On Thu, 10 Sep 2009 20:45:40 -0400, "Ace Fekay [MCT]"
<aceman@mvps.RemoveThisPart.org> wrote:
<!--coloro:blue--><span style="color:blue <!--/coloro-->
>"System Administrator" <sysadmin.removethis@sprottewatson.com> wrote in
>message news:4aa9828c.1651895453@msnews.microsoft.com...
>
>You are welcome! I'm glad to hear it hasn't crashed or locked up yet, and
>there are no errors with the drive. With no-name brand mobos, it's hard to
>diagnose if it is a controller or otehr problem, possibly even RAM.
>Difficult to say. I've seen where RAM's the cause, however running all of
>those mem tests on a machine show no problems, but it continues to occur,
>yet when you swap the RAM out, it stops happening.Go figure...
>
>The DNS thing with AD is important. Glad I was able to provide technical
>information on it and was helpful.
>
>As for VPN on a DC, that's one of the other things not suggested, and I
>would recommend to offload it to a member server, or a hardware appliance.
>Once again, it's because of the additional VPN interfaces that get
>registered into DNS that can mess with AD.
>
>Post back if you have any other questions.
>
>Ace
>
><!--coloro:green--><span style="color:green <!--/coloro-->
>> Thanks, again, for your response. Sorry mine is late - I'm only at
>> this client one day per week normally.
>>
>> Email Server: No, the lockup does not generate any events in the
>> event log. No management apps installed. No-name computer using an
>> Intel motherboard and only using the on-board controllers. Chkdsk on
>> both primary and secondary drives returned no issues. As mentioned
>> previously, the secondary DNS entry pointing to the router was only to
>> provide DNS services for times when the DC was down (monthly services)
>> and Internet access from the email server was needed. I have now
>> removed this pointer. Thank you for pointing out the possible issues
>> for having a non-DC secondary DNS configured. As of this writing, the
>> email server has been stable since its last crash (one week and
>> counting).
>>
>> DC: I have checked the DNS configuration of the machine. The
>> Forwarding tab in the DNS Properties window shows forwarders to our
>> ISP's DNS servers configured. Sorry, I had forgotten that I had done
>> so. RRAS is active on the machine for VPN access.
>>
>> Thanks for your assistance.
>> --
>>
>>
>> On Fri, 4 Sep 2009 20:07:00 -0400, "Ace Fekay [MCT]"
>> <aceman@mvps.RemoveThisPart.org> wrote:<!--coloro:darkred--><span style="color:darkred <!--/coloro-->
>>>
>>>You are right that it doesn't have anything to do with the lockup. I think
>>>the lockup may be due to a bad drive or controller. Are there any event
>>>log
>>>errors? What type of controller is in the machine? Is there a management
>>>app
>>>that came with it? Eg. Dell, HP, etc, come with management apps that allow
>>>you to look at the health of a system's components. Maybe running a chkdsk
>>>on it with the /F and /R switches to evaluate the drives, may be the first
>>>thing to start with. Run chkdsk /? to see what the switches do.
>>>
>>>However, evaluating your DNS config, I thought to point out a corrected,
>>>recommended configuration. I'm sorry to hear you don't trust my
>>>recommendations. Maybe if some of the others responding may formulate
>>>their
>>>own recommendations or reiterate my recommendations, it may be more
>>>convincing. I was just trying to help and guide you in a proper
>>>configuration.
>>>
>>>I do apologize about the DHCP setting on the DC. I misread that. I must
>>>have
>>>been looking at the workstation config while scrolling up and down through
>>>the post and mistakenly thought that was the DC.
>>>
>>>However, IP routing does show enabled in the DC's ipconfig. If not enabled
>>>in the reg, is it possible that the RRAS service is started? IP routing is
>>>known to cause issues with authentication and other AD functions.
>>>
>>>Keep in mind, 192.168.0.1 is your router. It's not a DNS server. With all
>>>due respect, whether it will hit that server during a query or not, the
>>>recommendation is to only use the internal DNS, in your case, your DC. So
>>>let's say the local DNS service has a problem, it doesn't respond, the
>>>first
>>>entry times out during a query, and then goes to the second one, which is
>>>your router. Will that help logons, authentication or AD functions?
>>>
>>>Instead of taking my word on it, maybe the following Microsoft articles
>>>may
>>>help to understand what I'm referring to regarding AD and DNS settings.
>>>
>>>825036 - Best practices for DNS client settings in Windows 2000 Server and
>>>in Windows Server 2003 (including how-to configure a forwarder):
>>>
>>>
>>>323380 - HOW TO: Configure DNS for Internet Access in Windows Server 2003
>>>(How to configure a forwarder):
>>>
>>>
>>>291382 - Frequently asked questions about Windows 2000 DNS and Windows
>>>Server 2003 DNS
>>>
>>>
>>>I hope I was helpful with the drive issue, and you've found my AD/DNS
>>>comments educational.
>>>
>>>Ace
>>><!--colorc--><!--/colorc-->
>>
>> --
>> System Administrator
>> Sprotte + Watson Architecture and Planning
>> Vista, CA
>><!--colorc--><!--/colorc-->
>
><!--colorc--><!--/colorc-->

--
System Administrator
Sprotte + Watson Architecture and Planning
Vista, CA

 

"System Administrator" <sysadmin.removethis@sprottewatson.com> wrote in
message news:4ab28ea3.2244822828@msnews.microsoft.com...<!--coloro:blue--><span style="color:blue <!--/coloro-->
> The email server continues to keep on ticking. Must be a Timex. Hi!
> Hi!.
>
> VPN is only configued for occasional access to the network by the
> business owners. Hardly used at all. So far, its presence on the DC
> has not caused any issues. There is nothing else to offload it onto
> without obtaining additional hardware. Thanks for the heads up,
> though.
>
> Thanks, again, for your assistance.
><!--colorc--><!--/colorc-->

It must certaintly be a Timex!

You are welcome.

Cheers!

Ace

 

The email server continues to work OK. However, the 2nd (scanner
station) of two identical machines purchased at the same time has now
developed the identical issue. It is a machine that is not used
often. Upon powering it up today, it went into a mode that was 1)
doing something to the network interface that caused all network
traffic to the domain controller to slow to a crawl, if it was moving
at all; and 2) accepted no input from either keyboard or mouse. (It
did, though, get to the point of presenting the logon screen.) This
is the same exact mode that the email server has entered twice.
Disconnecting the scanner computer from the network allowed the
network to return to normal operation. Upon forcing a power down of
the scanner computer and re-booting, it could not find its OS,
possibly caused by sector corruption by the forced power down. I
would guess there is a generic problem on the M/B of both machines,
which I'm surprised to see since they are Intel M/B.


On Thu, 17 Sep 2009 15:39:30 -0400, "Ace Fekay [MCT]"
<aceman@mvps.RemoveThisPart.org> wrote:
<!--coloro:blue--><span style="color:blue <!--/coloro-->
>"System Administrator" <sysadmin.removethis@sprottewatson.com> wrote in
>message news:4ab28ea3.2244822828@msnews.microsoft.com...<!--coloro:green--><span style="color:green <!--/coloro-->
>> The email server continues to keep on ticking. Must be a Timex. Hi!
>> Hi!.
>>
>> VPN is only configued for occasional access to the network by the
>> business owners. Hardly used at all. So far, its presence on the DC
>> has not caused any issues. There is nothing else to offload it onto
>> without obtaining additional hardware. Thanks for the heads up,
>> though.
>>
>> Thanks, again, for your assistance.
>><!--colorc--><!--/colorc-->
>
>It must certaintly be a Timex!
>
>You are welcome.
>
>Cheers!
>
>Ace
>
>
><!--colorc--><!--/colorc-->

--
System Administrator
Sprotte + Watson Architecture and Planning
Vista, CA

 

"System Administrator" <sysadmin.removethis@sprottewatson.com> wrote in
message news:4abe73ee.3024429234@msnews.microsoft.com...<!--coloro:blue--><span style="color:blue <!--/coloro-->
> The email server continues to work OK. However, the 2nd (scanner
> station) of two identical machines purchased at the same time has now
> developed the identical issue. It is a machine that is not used
> often. Upon powering it up today, it went into a mode that was 1)
> doing something to the network interface that caused all network
> traffic to the domain controller to slow to a crawl, if it was moving
> at all; and 2) accepted no input from either keyboard or mouse. (It
> did, though, get to the point of presenting the logon screen.) This
> is the same exact mode that the email server has entered twice.
> Disconnecting the scanner computer from the network allowed the
> network to return to normal operation. Upon forcing a power down of
> the scanner computer and re-booting, it could not find its OS,
> possibly caused by sector corruption by the forced power down. I
> would guess there is a generic problem on the M/B of both machines,
> which I'm surprised to see since they are Intel M/B.<!--colorc--><!--/colorc-->

Have you ran a chkdsk lately? Anything in the HP tools regarding drive
issues?

Ace