Prev: SBS 2008 Migrate "a drive cannot be found"
Next: AllSBSUsers Group Policy - doesn't exist
From: kj [SBS MVP] on 24 Jan 2009 14:07
thejamie wrote:
> I connect to the domain via a wireless access point - one job is to
> develop databases and frequently I move a large backup file from a
> laptop to the domain. Unfortunately, the connection is not always
> what it should or could be and the SBS DC interprets the missing
> packets as a bad sector on the hard disk, shuts down the domain...
> wow, so annoying!

Crashes? Hmm. Are you sure you don't really have a bad sector on a disk?
User mode copy of a non system file shouldn't crash the system.

While a good wirelless should work fine, there are many variables in the
environment that can cause timeouts and failures. Use of a good restartable
copy utility (like robocopy) is essential. Interesting use of eseutil, but
the documentation advises;

"For the best speed and stability, you should run Eseutil /Y from a command
prompt on the copy destination server rather than from an intermediate
location."

I think I'd give robocpy a shot and scutinize those event logs looking for
other evidence of disk issues.


The simple solution is to never try to move a
> large file from the access point into the domain but that is not a
> practical solution for this infrastructure.
>
> Which is this. There is a WAP just over 50 feet away from my desk.
> It is authenticated through IAS and SBS sees it like a machine on the
> network. The IAS keeps just anyone from using it - anyone can login
> if they know the WAP password, but it won't get them authenticated.
> That part is fine.
>
> Since moving files conventionally seems to fail frequently I try to
> use the ESE.DLL in conjunction with the ESEUTIL.EXE that comes with
> Exchange and then pipe it:
> eseutil /y "G:\BIGFILE" /d "\\dcserver\Users\myspace\BIGFILE.bak"
>
> Neither this nor the file transfer method works. The minute the WAP
> gets fuzzy and some packets are lost, SBS says - aha, I lost the file
> - must be my hard disk so I am going to shut down and kaboom, down
> comes the domain.
>
> What can I do to fix the server so that it doesn't interpret the file
> transfers as a bad disk?
>
> Yep, I have been doing this for about a year - I go back, run the
> chkdsk for bad sectors on the mirror - nothing - the disks are fine.
> It is essentially something in the makeup of the way SBS is
> interpreting the file as it comes across from the WAP.
>
> If I didn't think it would raise hackles all over the place, I would
> call it a bug. Think of a disgruntled employee on a WAP and you'll
> get the picture.

--
/kj


From: Cliff Galiher on 24 Jan 2009 18:11
First, let me be *very* clear on this. SMB, as a protocol, knows when
things are getting dropped. A good RAID card with appropriate drivers (you
are running RAID on your server, right?) knows when there is a hard disk
error. If your system is in decent running order, SBS *WILL NOT* confuse
missing data from a copy as a bad hard drive.

If the event logs are actually showing you hard drive related errors then
you *have* hard drive related errors and should address them.

But for us to help you, we'd need to know a few things:

First and foremost, what do you mean SBS shuts down the domain!? That
simply doesn't make sense. If the SBS server is shutting down and it is the
only DC then sure, you have no domain access...but it is the SERVER that
shut down. "The Domain" is a nebulous things that doesn't just shut down.
If SBS is staying up, but Active Directory is somehow becoming unavailable
then you have *OTHER* problems. Again, as above, you need to find out why
and address them. But you need to be VERY CLEAR about what is happening.
"shutting down the domain" unfortunately is just not detailed enough, and I
don't want to guess what you meant by that.

Secondly, what event logs have you seen that make you think SBS is deciding
it is a hard drive issue. Post the actual errors and events you are seeing.
We will be able to better help you interpret those errors and events than we
can guess what is happening based on the interpretation you've already
decided to make. You very well may have interpreted the errors
correctly...I'm not second guessing that, just saying that the conclusion
you drew may be off. But I'd rather not guess...and see the evidence for
myself.

Good luck,

-Cliff


"thejamie" <thejamie(a)discussions.microsoft.com> wrote in message
news:841863AB-807A-48CF-A69E-4C2900AA7647(a)microsoft.com...
> I connect to the domain via a wireless access point - one job is to
> develop
> databases and frequently I move a large backup file from a laptop to the
> domain. Unfortunately, the connection is not always what it should or
> could
> be and the SBS DC interprets the missing packets as a bad sector on the
> hard
> disk, shuts down the domain... wow, so annoying! The simple solution is
> to
> never try to move a large file from the access point into the domain but
> that
> is not a practical solution for this infrastructure.
>
> Which is this. There is a WAP just over 50 feet away from my desk. It is
> authenticated through IAS and SBS sees it like a machine on the network.
> The
> IAS keeps just anyone from using it - anyone can login if they know the
> WAP
> password, but it won't get them authenticated. That part is fine.
>
> Since moving files conventionally seems to fail frequently I try to use
> the
> ESE.DLL in conjunction with the ESEUTIL.EXE that comes with Exchange and
> then
> pipe it:
> eseutil /y "G:\BIGFILE" /d "\\dcserver\Users\myspace\BIGFILE.bak"
>
> Neither this nor the file transfer method works. The minute the WAP gets
> fuzzy and some packets are lost, SBS says - aha, I lost the file - must be
> my
> hard disk so I am going to shut down and kaboom, down comes the domain.
>
> What can I do to fix the server so that it doesn't interpret the file
> transfers as a bad disk?
>
> Yep, I have been doing this for about a year - I go back, run the chkdsk
> for
> bad sectors on the mirror - nothing - the disks are fine. It is
> essentially
> something in the makeup of the way SBS is interpreting the file as it
> comes
> across from the WAP.
>
> If I didn't think it would raise hackles all over the place, I would call
> it
> a bug. Think of a disgruntled employee on a WAP and you'll get the
> picture.
> --
> Regards,
> Jamie

From: thejamie on 24 Jan 2009 19:46
The server restart log is at 7:16 for this particular crash:
The client says:
The system failed to register host (A) resource records (RRs) for network
adapter
with settings:

Adapter Name : {7790AD42-FFC6-43CD-AF09-5F4275B39533}
Host Name : solsticedev
Primary Domain Suffix : terraatlas.local
DNS server list :
192.168.16.2
Sent update to server : <?>
IP Address(es) :
192.168.1.2

The reason the system could not register these RRs was because either (a)
the DNS server does not support the DNS dynamic update protocol, or (b) the
authoritative zone for the specified DNS domain name does not accept dynamic
updates.

To register the DNS host (A) resource records using the specific DNS domain
name and IP addresses for this adapter, contact your DNS server or network
systems administrator.

For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.

The server code is a bit less revealing:
The reason supplied by user TERRAATLAS\Administrator for the last unexpected
shutdown of this computer is: System Failure: Stop error
Reason Code: 0x805000f
Bug ID:
Bugcheck String: 0x0000007a (0xc03dcdb8, 0xc000000e, 0xf736e5ef, 0x11ed1860)
Comment: 0x0000007a (0xc03dcdb8, 0xc000000e, 0xf736e5ef, 0x11ed1860)

For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.


THEN
The Network Connections service was successfully sent a start control.

For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.


AND

Error code 0000007a, parameter1 c03dcdb8, parameter2 c000000e, parameter3
f736e5ef, parameter4 11ed1860.

For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.

as it came BACK

Printer Generic / Text Only (from SOLSTICEDEV) in session 0 was purged.

For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.

(some more of these purges) PLUS many of what is below:
--
for this particular time, there was a cd in the dvd drive with a bad sector
- probably did not help...

The device, \Device\CdRom0, has a bad block.

For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.


--
Regards,
Jamie


"Les Connor [SBS MVP]" wrote:

> Event logs, client and server please?
>
> --
> -----------------------------------------------
> Les Connor [SBS MVP]
>
> "thejamie" <thejamie(a)discussions.microsoft.com> wrote in message
> news:841863AB-807A-48CF-A69E-4C2900AA7647(a)microsoft.com...
> > I connect to the domain via a wireless access point - one job is to
> > develop
> > databases and frequently I move a large backup file from a laptop to the
> > domain. Unfortunately, the connection is not always what it should or
> > could
> > be and the SBS DC interprets the missing packets as a bad sector on the
> > hard
> > disk, shuts down the domain... wow, so annoying! The simple solution is
> > to
> > never try to move a large file from the access point into the domain but
> > that
> > is not a practical solution for this infrastructure.
> >
> > Which is this. There is a WAP just over 50 feet away from my desk. It is
> > authenticated through IAS and SBS sees it like a machine on the network.
> > The
> > IAS keeps just anyone from using it - anyone can login if they know the
> > WAP
> > password, but it won't get them authenticated. That part is fine.
> >
> > Since moving files conventionally seems to fail frequently I try to use
> > the
> > ESE.DLL in conjunction with the ESEUTIL.EXE that comes with Exchange and
> > then
> > pipe it:
> > eseutil /y "G:\BIGFILE" /d "\\dcserver\Users\myspace\BIGFILE.bak"
> >
> > Neither this nor the file transfer method works. The minute the WAP gets
> > fuzzy and some packets are lost, SBS says - aha, I lost the file - must be
> > my
> > hard disk so I am going to shut down and kaboom, down comes the domain.
> >
> > What can I do to fix the server so that it doesn't interpret the file
> > transfers as a bad disk?
> >
> > Yep, I have been doing this for about a year - I go back, run the chkdsk
> > for
> > bad sectors on the mirror - nothing - the disks are fine. It is
> > essentially
> > something in the makeup of the way SBS is interpreting the file as it
> > comes
> > across from the WAP.
> >
> > If I didn't think it would raise hackles all over the place, I would call
> > it
> > a bug. Think of a disgruntled employee on a WAP and you'll get the
> > picture.
> > --
> > Regards,
> > Jamie
>
>
From: thejamie on 24 Jan 2009 19:53
The cdrom error aside (definitely a contributing factor), I'm wondering if
the information in the article on hooking in the wireless is correct:

http://technet.microsoft.com/en-us/library/cc719890.aspx#

Or, as complicated as this is, maybe I set some small part of it up wrong.
I hadnt noticed all the DNSAPI register errors. Still it reinforces what I
am seeing with the timeout problem through the access point:

" The reason that the system could not register these RRs was because the
update request that was sent to the specified DNS server timed out. This is
probably because the authoritative DNS server for the name being registered
is not running."


--
Regards,
Jamie


"Les Connor [SBS MVP]" wrote:

> Event logs, client and server please?
>
> --
> -----------------------------------------------
> Les Connor [SBS MVP]
>
> "thejamie" <thejamie(a)discussions.microsoft.com> wrote in message
> news:841863AB-807A-48CF-A69E-4C2900AA7647(a)microsoft.com...
> > I connect to the domain via a wireless access point - one job is to
> > develop
> > databases and frequently I move a large backup file from a laptop to the
> > domain. Unfortunately, the connection is not always what it should or
> > could
> > be and the SBS DC interprets the missing packets as a bad sector on the
> > hard
> > disk, shuts down the domain... wow, so annoying! The simple solution is
> > to
> > never try to move a large file from the access point into the domain but
> > that
> > is not a practical solution for this infrastructure.
> >
> > Which is this. There is a WAP just over 50 feet away from my desk. It is
> > authenticated through IAS and SBS sees it like a machine on the network.
> > The
> > IAS keeps just anyone from using it - anyone can login if they know the
> > WAP
> > password, but it won't get them authenticated. That part is fine.
> >
> > Since moving files conventionally seems to fail frequently I try to use
> > the
> > ESE.DLL in conjunction with the ESEUTIL.EXE that comes with Exchange and
> > then
> > pipe it:
> > eseutil /y "G:\BIGFILE" /d "\\dcserver\Users\myspace\BIGFILE.bak"
> >
> > Neither this nor the file transfer method works. The minute the WAP gets
> > fuzzy and some packets are lost, SBS says - aha, I lost the file - must be
> > my
> > hard disk so I am going to shut down and kaboom, down comes the domain.
> >
> > What can I do to fix the server so that it doesn't interpret the file
> > transfers as a bad disk?
> >
> > Yep, I have been doing this for about a year - I go back, run the chkdsk
> > for
> > bad sectors on the mirror - nothing - the disks are fine. It is
> > essentially
> > something in the makeup of the way SBS is interpreting the file as it
> > comes
> > across from the WAP.
> >
> > If I didn't think it would raise hackles all over the place, I would call
> > it
> > a bug. Think of a disgruntled employee on a WAP and you'll get the
> > picture.
> > --
> > Regards,
> > Jamie
>
>
From: thejamie on 24 Jan 2009 20:01
I keep looking for a bad sector. The same error comes up frequently enough
so that I can link it to the Access Point and to a large file transfer. And
I see the same at home with the wireless there. Occasionally if something
gets opened on the SAN (it is an Airport Extreme wireless with a 1/2
terrabyte san disk) and it is left open long enough for the connection to
shake a bit, the connection goes out between the machines and the access
point. Sometimes when it reconnects the machine cannot resolve all the loose
ends.

As far as the bad sectors go though, I'll sit with the machine on a reboot
when the chkdsk runs - it never finds any errors on the mirror. You'd think
if there were any disk problems, it would show up on a chkdsk. Especially
when it is mirrored.

Robocopy ... hmmm, sounds like a useful tool.

So the ESEUTIL will pull better than push? I loaded both the exe and dll
on the laptop and ran the batch only because it fails so often with a simple
copy. Probably my imagination but it seems like it works better that way.
File size is about 3 gig - not huge. Should not be much of an issue to copy
that - people probably move copies of DVD's around alot and their nearly 5
gig. ...All relative but 3 seems pretty lightweight for a SQL BAK file.
--
Regards,
Jamie


"kj [SBS MVP]" wrote:

> thejamie wrote:
> > I connect to the domain via a wireless access point - one job is to
> > develop databases and frequently I move a large backup file from a
> > laptop to the domain. Unfortunately, the connection is not always
> > what it should or could be and the SBS DC interprets the missing
> > packets as a bad sector on the hard disk, shuts down the domain...
> > wow, so annoying!
>
> Crashes? Hmm. Are you sure you don't really have a bad sector on a disk?
> User mode copy of a non system file shouldn't crash the system.
>
> While a good wirelless should work fine, there are many variables in the
> environment that can cause timeouts and failures. Use of a good restartable
> copy utility (like robocopy) is essential. Interesting use of eseutil, but
> the documentation advises;
>
> "For the best speed and stability, you should run Eseutil /Y from a command
> prompt on the copy destination server rather than from an intermediate
> location."
>
> I think I'd give robocpy a shot and scutinize those event logs looking for
> other evidence of disk issues.
>
>
> The simple solution is to never try to move a
> > large file from the access point into the domain but that is not a
> > practical solution for this infrastructure.
> >
> > Which is this. There is a WAP just over 50 feet away from my desk.
> > It is authenticated through IAS and SBS sees it like a machine on the
> > network. The IAS keeps just anyone from using it - anyone can login
> > if they know the WAP password, but it won't get them authenticated.
> > That part is fine.
> >
> > Since moving files conventionally seems to fail frequently I try to
> > use the ESE.DLL in conjunction with the ESEUTIL.EXE that comes with
> > Exchange and then pipe it:
> > eseutil /y "G:\BIGFILE" /d "\\dcserver\Users\myspace\BIGFILE.bak"
> >
> > Neither this nor the file transfer method works. The minute the WAP
> > gets fuzzy and some packets are lost, SBS says - aha, I lost the file
> > - must be my hard disk so I am going to shut down and kaboom, down
> > comes the domain.
> >
> > What can I do to fix the server so that it doesn't interpret the file
> > transfers as a bad disk?
> >
> > Yep, I have been doing this for about a year - I go back, run the
> > chkdsk for bad sectors on the mirror - nothing - the disks are fine.
> > It is essentially something in the makeup of the way SBS is
> > interpreting the file as it comes across from the WAP.
> >
> > If I didn't think it would raise hackles all over the place, I would
> > call it a bug. Think of a disgruntled employee on a WAP and you'll
> > get the picture.
>
> --
> /kj
>
>
>
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: SBS 2008 Migrate "a drive cannot be found"
Next: AllSBSUsers Group Policy - doesn't exist