I know there's lots of info missing, but i'm looking for a prod in the right
direction at the moment, rather than a specific fix!

New network, just three boxes for now, DC, Domain-joined ISA box (dual NIC,
external connection to ADSL router), member server (for VM). Servers are bog
standard HP DL, fully up to date with firmware, and WIndows 2003 SP2 server
installed via HP tools (so correct drivers loaded)
* DHCP and DNS setup and running (more later though)
* ISA Server configured for discovery and working
* NSLOOKUP working fine.
* Internet browsing through ISA all OK (using ISA client on machines)
* DHCP allocation to client all OK and the ISA WPAD entry is clearly working.

Not working:
* login times (except on DC) taking ages
* remote authentication requests (for share permissions say) timing out
(errors in log - [sorry away from site so no eventid right now] which report
unable to authenticate, kerberos
* DNS updates to the forward lookup zone (unless I allow non-secure updates
when the HOST records are then entered).

It feels (and I stress feels!) like a firewall is in the way on the DC. But
there nothing there to do that. Done plenty of googling, and nothing obvious
comes to light.

My one concern is that the HP teamed NIC might be doing something, so will
break the team next time I'm there, disable a NIC, and use a single NIC with
the same IP settings.

It's the sort of setup that works every time <g> and you can do in your
sleep <bg> but this time is not, and there's nothing I've done that various
from the normal.

So if you have any suggestions please shout out!

Thanks, Peter

> Not working:
> * login times (except on DC) taking ages


This is a clear indication that DNS is not set up correctly.

Basic AD DNS setup is install a DNS server for the AD domain (suggest the DC
so you can use AD integrated DNS).
Point the AD DNS server to itself in the properties of TCP/IP for DNS. Use
the actual IP address not 127.0.0.1.

Point all AD clients to the DNS server setup for the AD domain ONLY.\

For Internet access setup your AD DNS server to forward requests and list
your ISP's DNS servers as the forwarders (or use root hints).
This is the only place on an AD domain your ISP's DNS servers should be
listed.



hth
DDS

"P J Bryant" <PJBryant@discussions.microsoft.com> wrote in message
news:A672F96B-1A71-44F1-8924-F3E5DE574A15@microsoft.com...
>I know there's lots of info missing, but i'm looking for a prod in the
>right
> direction at the moment, rather than a specific fix!
>
> New network, just three boxes for now, DC, Domain-joined ISA box (dual
> NIC,
> external connection to ADSL router), member server (for VM). Servers are
> bog
> standard HP DL, fully up to date with firmware, and WIndows 2003 SP2
> server
> installed via HP tools (so correct drivers loaded)
> * DHCP and DNS setup and running (more later though)
> * ISA Server configured for discovery and working
> * NSLOOKUP working fine.
> * Internet browsing through ISA all OK (using ISA client on machines)
> * DHCP allocation to client all OK and the ISA WPAD entry is clearly
> working.
>
> Not working:
> * login times (except on DC) taking ages
> * remote authentication requests (for share permissions say) timing out
> (errors in log - [sorry away from site so no eventid right now] which
> report
> unable to authenticate, kerberos
> * DNS updates to the forward lookup zone (unless I allow non-secure
> updates
> when the HOST records are then entered).
>
> It feels (and I stress feels!) like a firewall is in the way on the DC.
> But
> there nothing there to do that. Done plenty of googling, and nothing
> obvious
> comes to light.
>
> My one concern is that the HP teamed NIC might be doing something, so will
> break the team next time I'm there, disable a NIC, and use a single NIC
> with
> the same IP settings.
>
> It's the sort of setup that works every time <g> and you can do in your
> sleep <bg> but this time is not, and there's nothing I've done that
> various
> from the normal.
>
> So if you have any suggestions please shout out!
>
> Thanks, Peter

"Danny Sanders" <DSanders@NOSPAMciber.com> wrote in message
news:O$5kEwSqHHA.4100@TK2MSFTNGP06.phx.gbl...
>> Not working:
>> * login times (except on DC) taking ages
>
>
> This is a clear indication that DNS is not set up correctly.
>
> Basic AD DNS setup is install a DNS server for the AD domain (suggest the
> DC so you can use AD integrated DNS).
> Point the AD DNS server to itself in the properties of TCP/IP for DNS. Use
> the actual IP address not 127.0.0.1.

I know there was some (minor) reason for this but cannot recall it --
would you please remind me why the IP is better (in some cases)
than the Loopback 127.etc address....

Thanks

--
Herb Martin, MCSE, MVP
http://www.LearnQuick.Com
(phone on web site)

> Point all AD clients to the DNS server setup for the AD domain ONLY.\
>
> For Internet access setup your AD DNS server to forward requests and list
> your ISP's DNS servers as the forwarders (or use root hints).
> This is the only place on an AD domain your ISP's DNS servers should be
> listed.
>
>
>
> hth
> DDS
>
> "P J Bryant" <PJBryant@discussions.microsoft.com> wrote in message
> news:A672F96B-1A71-44F1-8924-F3E5DE574A15@microsoft.com...
>>I know there's lots of info missing, but i'm looking for a prod in the
>>right
>> direction at the moment, rather than a specific fix!
>>
>> New network, just three boxes for now, DC, Domain-joined ISA box (dual
>> NIC,
>> external connection to ADSL router), member server (for VM). Servers are
>> bog
>> standard HP DL, fully up to date with firmware, and WIndows 2003 SP2
>> server
>> installed via HP tools (so correct drivers loaded)
>> * DHCP and DNS setup and running (more later though)
>> * ISA Server configured for discovery and working
>> * NSLOOKUP working fine.
>> * Internet browsing through ISA all OK (using ISA client on machines)
>> * DHCP allocation to client all OK and the ISA WPAD entry is clearly
>> working.
>>
>> Not working:
>> * login times (except on DC) taking ages
>> * remote authentication requests (for share permissions say) timing out
>> (errors in log - [sorry away from site so no eventid right now] which
>> report
>> unable to authenticate, kerberos
>> * DNS updates to the forward lookup zone (unless I allow non-secure
>> updates
>> when the HOST records are then entered).
>>
>> It feels (and I stress feels!) like a firewall is in the way on the DC.
>> But
>> there nothing there to do that. Done plenty of googling, and nothing
>> obvious
>> comes to light.
>>
>> My one concern is that the HP teamed NIC might be doing something, so
>> will
>> break the team next time I'm there, disable a NIC, and use a single NIC
>> with
>> the same IP settings.
>>
>> It's the sort of setup that works every time <g> and you can do in your
>> sleep <bg> but this time is not, and there's nothing I've done that
>> various
>> from the normal.
>>
>> So if you have any suggestions please shout out!
>>
>> Thanks, Peter
>
>

In news:eTz%23jiUqHHA.4548@TK2MSFTNGP03.phx.gbl,
Herb Martin <news@learnquick.com> typed:
> I know there was some (minor) reason for this but cannot recall it --
> would you please remind me why the IP is better (in some cases)
> than the Loopback 127.etc address....
>
> Thanks

Herb,

Here's an old post from a few years ago concerning the loopback and minor
reasons why not to use it. Let's call it best practice:

=======================
----- Original Message -----
From: Ace Fekay [MVP]
Newsgroups: microsoft.public.win2000.dns
Sent: Sunday, March 07, 2004 4:46 PM
Subject: Re: DNS I think?


>>> Workstations without the DNS service don't point to themselves for
>>> DNS
> server do they? (The request doesn't actually happen does it?)
> No.... they don't. No it doesn't That was why I said:
>>> if a Windows DNS server points to NOTHING
> By that I meant a computer that is actually running the DNS service.
>
>>> Is that a dependable feature?
> It's actually a good one. Windows sets the blank to loopback address
> and it's thence a local resolution, and all is fine. This is what
> you'd want to do to avoid confusion in a multi-home DNS Server
> config. Instead of trying to figure out (or, in our case, explain)
> which NIC should point to which DNS, simply saying leave them blank
> s a lot. And it s Windows, too.
>
>
> Dèjì Akómöláfé, MCSE MCSA MCP+I
> www.akomolafe.com
> www.iyaburo.com

Deji, just to touch base on the loopback, it's actually advised not to use
it. Matter of fact, realizing that leaving it blank puts it in, but did you
ever try to type it in? It won't take it. Also it will cause other issues,
one such minor one is when nslookup gets invoked, you'll get that familiar
"can't find..." msg.

Q172060 - NSLOOKUP Can't Find Server Name for Address 127.0.0.1 -
(another good reason not to use the loopback):
http://support.microsoft.com/default...EN-US;Q172060&

Q254715 - RAS Clients Receive 127.0.0.1 for DNS Server Address:
http://support.microsoft.com/default...EN-US;Q254715&

And here's a post from Thomas Lee from awhile back about it:
============================
----- Original Message -----
From: "Thomas Lee [MVP]" <thomas@mvps.org>
Newsgroups: microsoft.public.win2000.dns
Sent: Saturday, October 12, 2002 11:13 AM
Subject: Re: DNS configeration


> In article <084201c271db$d74c6600$35ef2ecf@TKMSFTNGXA11>, dave
> <quick@firenet.uk.com> writes
>> i am setting up DNS on our server and was just wondering
>> ont he reverse look up should the IP number be
>> 192.168.0.x or 127.0.0.x? the rest of the computer of the
>> network are 192.168.0.x but the servers DNS IP number is
>> 127.0.0.x? which Ip number should i use?
>
> Ipconfig /displaydns should show you that a reverse lookup for 127.0.0.1
> is already in place. Set your reverse lookup to the actual IP address of
> your server.
>
> 127.0.0.0 is not a valid IP address for a host. This range is always a
> local loopback address.
>
> Thomas
> --
> --
>
Thomas Lee
===========================


--
Regards,
Ace

Please direct all replies to the newsgroup so all can benefit.
This posting is provided "AS IS" with no warranties.

Ace Fekay, MCSE 2000, MCSE+I, MCSA, MCT, MVP
Microsoft Windows MVP - Active Directory
--
=================================



Ace

Yup - but my trouble is tracking it down! However the symptons are slightly
worse than long log on times, if a member server creates a share, it cannot
access AD to resolve AD names to give permissions.

DNS is on the AD, and workign fine locally. NSLOOKUP from clients works OK.
I have used the actual address locally on the AD box, and not 127.0.0.1

All AD clients point exclusively to this DNS server for DNS, and the ISP's
DNS server is only used as a forwarder on the DNS service.

I mistakenly kicked off 2 threads here, so this is the summaryy of the notes
from the other one (which I'll ignore from now on).

-----------------------------

The only location the ISP's DNS servers are referenced is as a forwarder on
the DNS server. And that's how it was setup from scratch.

NSLOOKUP from client machines works fine for internal and external names.
The one symptom I've not yet understood (and hope may be a good clue) is the
fact that clients can only register with DNS when security is weakened from
secure only to non-secure and secure.

The one thing i've not checked so far (and will on Tuesday when i go back on
site) is that there is not a typo somewhere in the system. The internal
range is 192.168.74.x and the ISP range start 194. It's possible somewhere
there's a 194 instead of 192, but on the first pass yesterday it all looked
good. I'm considering a change to 172.16 just to make things clearer <g>

"Danny Sanders" wrote:

> > Not working:
> > * login times (except on DC) taking ages
>
>
> This is a clear indication that DNS is not set up correctly.
>
> Basic AD DNS setup is install a DNS server for the AD domain (suggest the DC
> so you can use AD integrated DNS).
> Point the AD DNS server to itself in the properties of TCP/IP for DNS. Use
> the actual IP address not 127.0.0.1.
>
> Point all AD clients to the DNS server setup for the AD domain ONLY.\
>
> For Internet access setup your AD DNS server to forward requests and list
> your ISP's DNS servers as the forwarders (or use root hints).
> This is the only place on an AD domain your ISP's DNS servers should be
> listed.
>
>
>
> hth
> DDS
>
> "P J Bryant" <PJBryant@discussions.microsoft.com> wrote in message
> news:A672F96B-1A71-44F1-8924-F3E5DE574A15@microsoft.com...
> >I know there's lots of info missing, but i'm looking for a prod in the
> >right
> > direction at the moment, rather than a specific fix!
> >
> > New network, just three boxes for now, DC, Domain-joined ISA box (dual
> > NIC,
> > external connection to ADSL router), member server (for VM). Servers are
> > bog
> > standard HP DL, fully up to date with firmware, and WIndows 2003 SP2
> > server
> > installed via HP tools (so correct drivers loaded)
> > * DHCP and DNS setup and running (more later though)
> > * ISA Server configured for discovery and working
> > * NSLOOKUP working fine.
> > * Internet browsing through ISA all OK (using ISA client on machines)
> > * DHCP allocation to client all OK and the ISA WPAD entry is clearly
> > working.
> >
> > Not working:
> > * login times (except on DC) taking ages
> > * remote authentication requests (for share permissions say) timing out
> > (errors in log - [sorry away from site so no eventid right now] which
> > report
> > unable to authenticate, kerberos
> > * DNS updates to the forward lookup zone (unless I allow non-secure
> > updates
> > when the HOST records are then entered).
> >
> > It feels (and I stress feels!) like a firewall is in the way on the DC.
> > But
> > there nothing there to do that. Done plenty of googling, and nothing
> > obvious
> > comes to light.
> >
> > My one concern is that the HP teamed NIC might be doing something, so will
> > break the team next time I'm there, disable a NIC, and use a single NIC
> > with
> > the same IP settings.
> >
> > It's the sort of setup that works every time <g> and you can do in your
> > sleep <bg> but this time is not, and there's nothing I've done that
> > various
> > from the normal.
> >
> > So if you have any suggestions please shout out!
> >
> > Thanks, Peter
>
>
>

"Ace Fekay [MVP]" <PleaseAskMe@SomeDomain.com> wrote in message
news:OyXADgXqHHA.5092@TK2MSFTNGP04.phx.gbl...
> In news:eTz%23jiUqHHA.4548@TK2MSFTNGP03.phx.gbl,
> Herb Martin <news@learnquick.com> typed:
>> I know there was some (minor) reason for this but cannot recall it --
>> would you please remind me why the IP is better (in some cases)
>> than the Loopback 127.etc address....


Maybe it is the "cannot find" (reverse) from nslookup but I thought
there was something material but minor -- I used to GIVE this
advice, but cannot remember for certain why I said that.

In news:1BE44039-8F1B-4E43-BBE2-2D592EB7C895@microsoft.com,
P J Bryant <PJBryant@discussions.microsoft.com> typed:
> Yup - but my trouble is tracking it down! However the symptons are
> slightly worse than long log on times, if a member server creates a
> share, it cannot access AD to resolve AD names to give permissions.
>
> DNS is on the AD, and workign fine locally. NSLOOKUP from clients
> works OK. I have used the actual address locally on the AD box, and
> not 127.0.0.1
>
> All AD clients point exclusively to this DNS server for DNS, and the
> ISP's DNS server is only used as a forwarder on the DNS service.
>
> I mistakenly kicked off 2 threads here, so this is the summaryy of
> the notes from the other one (which I'll ignore from now on).
>
> -----------------------------
>
> The only location the ISP's DNS servers are referenced is as a
> forwarder on the DNS server. And that's how it was setup from
> scratch.
>
> NSLOOKUP from client machines works fine for internal and external
> names. The one symptom I've not yet understood (and hope may be a
> good clue) is the fact that clients can only register with DNS when
> security is weakened from secure only to non-secure and secure.
>
> The one thing i've not checked so far (and will on Tuesday when i go
> back on site) is that there is not a typo somewhere in the system.
> The internal range is 192.168.74.x and the ISP range start 194. It's
> possible somewhere there's a 194 instead of 192, but on the first
> pass yesterday it all looked good. I'm considering a change to
> 172.16 just to make things clearer <g>

Read the following information closely. Please post the any information
(without editing it please) it is asking so we can ALL be clear on your
configuration. This info will us determine where the problem may lie.

--------
Here are some possible causes:
1. Single label name.
2. SRV records missing.
3. Disjointed namespace.- AD domain name doesn't match the Primary DNS
Suffix and/or the zone name.
4. Using an ISP's DNS in IP properties of the DC and clients.
5. DHCP Client service disabled.
6. DC is multihomed
7. 3rd party firewalls
8. etc....


If you like to get specific to diagnose this issue, and to elimiante
guesswork on our part, for starters, please post the following information:
1. Unedited ipconfig /all from two of your DCs, and one of your clients..
2. The exact zone name spellng in DNS and whether updates are allowed on the
zone.
3. The AD DNS domain name as it shows up in ADUC.
4. If the SRV records exist under your zone.
5. Any errors in the Event logs on the DC under System, Replication Service
and Directory Services (post the Event ID# and source please)
6. Dcdiag /v /fix > c:\dcdiag.txt (post the dcdiag.txt as an attachment)
7. Netdiag /v /fix > c:\netdiag.txt (post the dcdiag.txt as an attachment)
8. More than one subnet?
9. Forwarder(s) configured?
-----


Ace

Hi

If as you say, all the DNS config is fine, those event ids may .

There is a basic requirement of kerberos to have the correct time,from what I
have read (and experienced on my test network).Have all these machines got
the same time?I believe the threshold is 5 mins difference by default before
things fail. I know its very basic but sometimes you do overlook these things:
-)

Like Ace says the more info the better, hope you get it fixed.

Regards

S

Ace Fekay [MVP] wrote:
>> Yup - but my trouble is tracking it down! However the symptons are
>> slightly worse than long log on times, if a member server creates a
>[quoted text clipped - 27 lines]
>> pass yesterday it all looked good. I'm considering a change to
>> 172.16 just to make things clearer <g>
>
>Read the following information closely. Please post the any information
>(without editing it please) it is asking so we can ALL be clear on your
>configuration. This info will us determine where the problem may lie.
>
>--------
>Here are some possible causes:
>1. Single label name.
>2. SRV records missing.
>3. Disjointed namespace.- AD domain name doesn't match the Primary DNS
>Suffix and/or the zone name.
>4. Using an ISP's DNS in IP properties of the DC and clients.
>5. DHCP Client service disabled.
>6. DC is multihomed
>7. 3rd party firewalls
>8. etc....
>
>If you like to get specific to diagnose this issue, and to elimiante
>guesswork on our part, for starters, please post the following information:
>1. Unedited ipconfig /all from two of your DCs, and one of your clients..
>2. The exact zone name spellng in DNS and whether updates are allowed on the
>zone.
>3. The AD DNS domain name as it shows up in ADUC.
>4. If the SRV records exist under your zone.
>5. Any errors in the Event logs on the DC under System, Replication Service
>and Directory Services (post the Event ID# and source please)
>6. Dcdiag /v /fix > c:\dcdiag.txt (post the dcdiag.txt as an attachment)
>7. Netdiag /v /fix > c:\netdiag.txt (post the dcdiag.txt as an attachment)
>8. More than one subnet?
>9. Forwarder(s) configured?
>-----
>
>Ace

--
Message posted via WinServerKB.com
http://www.winserverkb.com/Uwe/Forum...r-dns/200706/1

Thanks for the suggestions everyone.

We decided we were concerned with SP2 for Windows Server 2003 (this is the
first build i'd used SP2 before creating AD etc). So we flattened the boxes
and rebuilt them to SP1 + patches and then created the forest/domain/DNS in
exactly the same way and all was OK.

So we'll be taking the network to SP2 soon, and examining behaviour then.
But for now I'd exercise circumspection with and new forest build on SP2 with
HP SmartStart setup with teamed NIC's

I've seen MS updates (a bad device driver patch) damage HP teamed NIC's
before in a Citrix setup, so was leaning towards that area, before the
rebuild. But everything looked so good with the setup (except that it was
failing!) that we decided we'd go to a known good world of SP1.

Thanks again, Peter

"Ace Fekay [MVP]" wrote:

> In news:1BE44039-8F1B-4E43-BBE2-2D592EB7C895@microsoft.com,
> P J Bryant <PJBryant@discussions.microsoft.com> typed:
> > Yup - but my trouble is tracking it down! However the symptons are
> > slightly worse than long log on times, if a member server creates a
> > share, it cannot access AD to resolve AD names to give permissions.
> >
> > DNS is on the AD, and workign fine locally. NSLOOKUP from clients
> > works OK. I have used the actual address locally on the AD box, and
> > not 127.0.0.1
> >
> > All AD clients point exclusively to this DNS server for DNS, and the
> > ISP's DNS server is only used as a forwarder on the DNS service.
> >
> > I mistakenly kicked off 2 threads here, so this is the summaryy of
> > the notes from the other one (which I'll ignore from now on).
> >
> > -----------------------------
> >
> > The only location the ISP's DNS servers are referenced is as a
> > forwarder on the DNS server. And that's how it was setup from
> > scratch.
> >
> > NSLOOKUP from client machines works fine for internal and external
> > names. The one symptom I've not yet understood (and hope may be a
> > good clue) is the fact that clients can only register with DNS when
> > security is weakened from secure only to non-secure and secure.
> >
> > The one thing i've not checked so far (and will on Tuesday when i go
> > back on site) is that there is not a typo somewhere in the system.
> > The internal range is 192.168.74.x and the ISP range start 194. It's
> > possible somewhere there's a 194 instead of 192, but on the first
> > pass yesterday it all looked good. I'm considering a change to
> > 172.16 just to make things clearer <g>
>
> Read the following information closely. Please post the any information
> (without editing it please) it is asking so we can ALL be clear on your
> configuration. This info will us determine where the problem may lie.
>
> --------
> Here are some possible causes:
> 1. Single label name.
> 2. SRV records missing.
> 3. Disjointed namespace.- AD domain name doesn't match the Primary DNS
> Suffix and/or the zone name.
> 4. Using an ISP's DNS in IP properties of the DC and clients.
> 5. DHCP Client service disabled.
> 6. DC is multihomed
> 7. 3rd party firewalls
> 8. etc....
>
>
> If you like to get specific to diagnose this issue, and to elimiante
> guesswork on our part, for starters, please post the following information:
> 1. Unedited ipconfig /all from two of your DCs, and one of your clients..
> 2. The exact zone name spellng in DNS and whether updates are allowed on the
> zone.
> 3. The AD DNS domain name as it shows up in ADUC.
> 4. If the SRV records exist under your zone.
> 5. Any errors in the Event logs on the DC under System, Replication Service
> and Directory Services (post the Event ID# and source please)
> 6. Dcdiag /v /fix > c:\dcdiag.txt (post the dcdiag.txt as an attachment)
> 7. Netdiag /v /fix > c:\netdiag.txt (post the dcdiag.txt as an attachment)
> 8. More than one subnet?
> 9. Forwarder(s) configured?
> -----
>
>
> Ace
>
>
>
>
>
>

In news:95C42B0C-82F1-4256-A6C6-A9EC57EFF264@microsoft.com,
P J Bryant <PJBryant@discussions.microsoft.com> typed:
> Thanks for the suggestions everyone.
>
> We decided we were concerned with SP2 for Windows Server 2003 (this
> is the first build i'd used SP2 before creating AD etc). So we
> flattened the boxes and rebuilt them to SP1 + patches and then
> created the forest/domain/DNS in exactly the same way and all was OK.
>
> So we'll be taking the network to SP2 soon, and examining behaviour
> then. But for now I'd exercise circumspection with and new forest
> build on SP2 with HP SmartStart setup with teamed NIC's
>
> I've seen MS updates (a bad device driver patch) damage HP teamed
> NIC's before in a Citrix setup, so was leaning towards that area,
> before the rebuild. But everything looked so good with the setup
> (except that it was failing!) that we decided we'd go to a known good
> world of SP1.
>
> Thanks again, Peter

Unfortunate you had to go this route. I/we were hoping it could have been
resolved otherwise. I have not seen any issues with SP2 as of yet other than
in SBS. Is this an SBS machine? If so, there's a simple fix for it.

Ace

'fraid this is not SBS Ace - i'd seen there was an issue there, but not paid
much attention to it.

I have retained the event logs (but not gone through them yet) to see if
there are any clues. But we were so convinced that SP2 was involved that we
went for the 'lets get it done quickly' SP1 route. Thankfully that worked;
we felt we needed to prove that.

More later (hopefully)

Peter

"Ace Fekay [MVP]" wrote:

> In news:95C42B0C-82F1-4256-A6C6-A9EC57EFF264@microsoft.com,
> P J Bryant <PJBryant@discussions.microsoft.com> typed:
> > Thanks for the suggestions everyone.
> >
> > We decided we were concerned with SP2 for Windows Server 2003 (this
> > is the first build i'd used SP2 before creating AD etc). So we
> > flattened the boxes and rebuilt them to SP1 + patches and then
> > created the forest/domain/DNS in exactly the same way and all was OK.
> >
> > So we'll be taking the network to SP2 soon, and examining behaviour
> > then. But for now I'd exercise circumspection with and new forest
> > build on SP2 with HP SmartStart setup with teamed NIC's
> >
> > I've seen MS updates (a bad device driver patch) damage HP teamed
> > NIC's before in a Citrix setup, so was leaning towards that area,
> > before the rebuild. But everything looked so good with the setup
> > (except that it was failing!) that we decided we'd go to a known good
> > world of SP1.
> >
> > Thanks again, Peter
>
> Unfortunate you had to go this route. I/we were hoping it could have been
> resolved otherwise. I have not seen any issues with SP2 as of yet other than
> in SBS. Is this an SBS machine? If so, there's a simple fix for it.
>
> Ace
>
>
>

In news:3EA9A98E-E60A-44F3-ADA9-A31DD17B9B90@microsoft.com,
P J Bryant <PJBryant@discussions.microsoft.com> typed:
> 'fraid this is not SBS Ace - i'd seen there was an issue there, but
> not paid much attention to it.
>
> I have retained the event logs (but not gone through them yet) to see
> if there are any clues. But we were so convinced that SP2 was
> involved that we went for the 'lets get it done quickly' SP1 route.
> Thankfully that worked; we felt we needed to prove that.
>
> More later (hopefully)
>
> Peter

I see.

FWIW, here is the info on SBS' RSS issue with SP2 and all of my notes on it:

================================================== ========

Windows 2003 service pack 2 known issues on Small Business Server 2003
http://support.microsoft.com/kb/555912/en-us

Susan Bradley: Vista slow after SP2 installed?
http://msmvps.com/blogs/bradley/arch...installed.aspx

Perform the following before un-joining it from the domain:

netsh interface tcp set global rss=disabled
netsh interface tcp set global autotuninglevel=disabled

Reboot the machine. Then re-join. Reboot.

More info:
You cannot host TCP connections when Receive Side Scaling is enabled in
Windows Server 2003 with Service Pack 2
http://support.microsoft.com/?id=927695

You experience intermittent communication failure between computers that are
running Windows XP or Windows Server 2003
http://support.microsoft.com/?id=904946


certutil -setreg SetupStatus -SETUP_DCOM_SECURITY_UPDATED_FLAG
net stop certsvc
net start certsvc



================================================== ========
or this...

I was able to find a very good site to fix my problem:
http://blogs.technet.com/sbs/archive...p2-on-sbs.aspx

I found that 2 changes to the registry fixed the problem for me:

Disable RSS in the Registry
Use the steps in KB 927695 to disable Receive Side Scaling (RSS) by adding a
DWORD registry key value for
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\Tcpip\Parameters\EnableRSS
and setting it to 0. A reboot is required to make the value go in to
effect.
Set DisableTaskOffload in the Registry
Use the steps in KB 904946 to create a DWORD value for
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\Tcpip\Parameters\DisableTaskOffload
and set it to 1. A reboot is required to make this value go in to effect.
Not one error yet
***
================================================== ========


Ace

Thanks Ace, interesting reading :-)

"Ace Fekay [MVP]" wrote:

> In news:3EA9A98E-E60A-44F3-ADA9-A31DD17B9B90@microsoft.com,
> P J Bryant <PJBryant@discussions.microsoft.com> typed:
> > 'fraid this is not SBS Ace - i'd seen there was an issue there, but
> > not paid much attention to it.
> >
> > I have retained the event logs (but not gone through them yet) to see
> > if there are any clues. But we were so convinced that SP2 was
> > involved that we went for the 'lets get it done quickly' SP1 route.
> > Thankfully that worked; we felt we needed to prove that.
> >
> > More later (hopefully)
> >
> > Peter
>
> I see.
>
> FWIW, here is the info on SBS' RSS issue with SP2 and all of my notes on it:
>
> ================================================== ========
>
> Windows 2003 service pack 2 known issues on Small Business Server 2003
> http://support.microsoft.com/kb/555912/en-us
>
> Susan Bradley: Vista slow after SP2 installed?
> http://msmvps.com/blogs/bradley/arch...installed.aspx
>
> Perform the following before un-joining it from the domain:
>
> netsh interface tcp set global rss=disabled
> netsh interface tcp set global autotuninglevel=disabled
>
> Reboot the machine. Then re-join. Reboot.
>
> More info:
> You cannot host TCP connections when Receive Side Scaling is enabled in
> Windows Server 2003 with Service Pack 2
> http://support.microsoft.com/?id=927695
>
> You experience intermittent communication failure between computers that are
> running Windows XP or Windows Server 2003
> http://support.microsoft.com/?id=904946
>
>
> certutil -setreg SetupStatus -SETUP_DCOM_SECURITY_UPDATED_FLAG
> net stop certsvc
> net start certsvc
>
>
>
> ================================================== ========
> or this...
>
> I was able to find a very good site to fix my problem:
> http://blogs.technet.com/sbs/archive...p2-on-sbs.aspx
>
> I found that 2 changes to the registry fixed the problem for me:
>
> Disable RSS in the Registry
> Use the steps in KB 927695 to disable Receive Side Scaling (RSS) by adding a
> DWORD registry key value for
> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\Tcpip\Parameters\EnableRSS
> and setting it to 0. A reboot is required to make the value go in to
> effect.
> Set DisableTaskOffload in the Registry
> Use the steps in KB 904946 to create a DWORD value for
> HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\Tcpip\Parameters\DisableTaskOffload
> and set it to 1. A reboot is required to make this value go in to effect.
> Not one error yet
> ***
> ================================================== ========
>
>
> Ace
>
>
>

In news:25BB328B-D7A0-4E2F-AE30-5BF90ECD1BFB@microsoft.com,
P J Bryant <PJBryant@discussions.microsoft.com> typed:
> Thanks Ace, interesting reading :-)
>

I agree. I thought the same thing when I first saw it.

Ace