I originally posted this in Winodws Vista administration; I'm posting here
to encourage a response.

I experience unresponsiveness (also could be seen as slowdown) after joining
my Vista machines to the active directory. I experience it particularly when
I take an
AD-joined laptop and carry it to another location, such as a friend's house
or coffee shop. When I do this, and the provider (e.g. Comcast or T-Mobile,
because I know the problems occur there) blocks port 445 outgoing, the
symptoms will arise. In particular, any function that requires interaction
with Explorer (.exe) will take 30-90 seconds to complete. This includes, for
example, saving a downloaded file using Firefox. Because Firefox integrates
with Explorer to save files (I think to render the icons), when I try to save
a file using firefox in this environment, the download will block for 30-90
seconds before proceeding.

It seems to be that Explorer is blocking to perform some sort of Active
Directory action which requires port 445 (microsoft-ds) on which to
communicate. Explorer resolves a name for the AD action but must wait for
the TCP timeout to occur before returning control to the calling application.

I don't use isolated DNS, so my Active Directory DNS is visible from any
host on the Internet. I can see in other deployments why this symptom would
not arise -- because if the DNS were isolated, the host would not have an AD
server to attempt a connection, and thus would not have to wait for the TCP
timeout.

I would not be feasible for me to put an AD server at every location,
because I have about 2 PCs per location, so it's also difficult for me to
isolate the DNS.

This problem occurs with or without roaming profiles. It occurs on brand
new Vista machines recently joined to the domain. This problem also
exhibited itself to a lesser degree in Windows XP.

One work-around that often works is to establish a VPN connection to one of
the domain controllers. In this way, microsoft-ds traffic can pass
unobstructed, and the problem goes away immediately. Unfortunately, it's
cumbersome to instruct other users to establish a VPN connection to keep
their machine from becoming non-responsive.

This to me is clearly a design flaw or design oversight, or possibly just an
unsupported configuration.

I've applied all Windows Updates as well as kb941649, but the behavior
remains the same.

I would very much appreciate any suggestions for alleviating this problem.
I'm also happy to provide additional details if a Microsoft rep takes
interest in reproducing the problem.

Sincerely,
Jason R. Coombs

Are you saying that your AD dns server is visible to the world? If so that
is a bad idea and I'm guessing your workstation is attempting to talk to
services inside the firewall which your client can't reach (At least I hope
you have that all firewalled off). I would try to get a dns server address
from whatever dhcp service provides your client with an ip address. I could
be wrong but that sounds like where your problem is stemming from.

--
Paul Bergson
MVP - Directory Services
MCT, MCSE, MCSA, Security+, BS CSci
2003, 2000 (Early Achiever), NT

http://www.pbbergs.com

Please no e-mails, any questions should be posted in the NewsGroup
This posting is provided "AS IS" with no warranties, and confers no rights.

"Jason R. Coombs" <(E-Mail Removed)> wrote in message
newsB5D9888-34C4-4829-9198-(E-Mail Removed)...
> I originally posted this in Winodws Vista administration; I'm posting here
> to encourage a response.
>
> I experience unresponsiveness (also could be seen as slowdown) after
> joining
> my Vista machines to the active directory. I experience it particularly
> when
> I take an
> AD-joined laptop and carry it to another location, such as a friend's
> house
> or coffee shop. When I do this, and the provider (e.g. Comcast or
> T-Mobile,
> because I know the problems occur there) blocks port 445 outgoing, the
> symptoms will arise. In particular, any function that requires interaction
> with Explorer (.exe) will take 30-90 seconds to complete. This includes,
> for
> example, saving a downloaded file using Firefox. Because Firefox
> integrates
> with Explorer to save files (I think to render the icons), when I try to
> save
> a file using firefox in this environment, the download will block for
> 30-90
> seconds before proceeding.
>
> It seems to be that Explorer is blocking to perform some sort of Active
> Directory action which requires port 445 (microsoft-ds) on which to
> communicate. Explorer resolves a name for the AD action but must wait for
> the TCP timeout to occur before returning control to the calling
> application.
>
> I don't use isolated DNS, so my Active Directory DNS is visible from any
> host on the Internet. I can see in other deployments why this symptom
> would
> not arise -- because if the DNS were isolated, the host would not have an
> AD
> server to attempt a connection, and thus would not have to wait for the
> TCP
> timeout.
>
> I would not be feasible for me to put an AD server at every location,
> because I have about 2 PCs per location, so it's also difficult for me to
> isolate the DNS.
>
> This problem occurs with or without roaming profiles. It occurs on brand
> new Vista machines recently joined to the domain. This problem also
> exhibited itself to a lesser degree in Windows XP.
>
> One work-around that often works is to establish a VPN connection to one
> of
> the domain controllers. In this way, microsoft-ds traffic can pass
> unobstructed, and the problem goes away immediately. Unfortunately, it's
> cumbersome to instruct other users to establish a VPN connection to keep
> their machine from becoming non-responsive.
>
> This to me is clearly a design flaw or design oversight, or possibly just
> an
> unsupported configuration.
>
> I've applied all Windows Updates as well as kb941649, but the behavior
> remains the same.
>
> I would very much appreciate any suggestions for alleviating this problem.
> I'm also happy to provide additional details if a Microsoft rep takes
> interest in reproducing the problem.
>
> Sincerely,
> Jason R. Coombs

Thanks Paul for the comments.

To clarify, yes, the AD dns server is visible to the world. I don't see
this as being a particularly bad idea. I don't have AD traffic firewalled
off, because I want to have Directory Services (single sign-on, etc)
available to the client machines regardless of where they're located. In
other words, the Internet is my intranet.

I'm using ISP-assigned DNS servers; my AD domain is also my Internet domain,
so when my machines want to authenticate to the domain, they query the
Internet domain servers, which forward the requests to the domain controllers.

This is the most straightforward and direct implementation of an AD domain
over a WAN. Again, I don't see a way to have an AD domain with unified
authentication and single-sign-on without
(a) having one domain controller that's globally accessible,
(b) having domain controllers at every site, or
(c) using VPN connections to tunnel.

(b) is impractical due to licensing costs of Windows Server and the fact
that I have 1-2 PCs per site. One laptop is primarily on the Internet
through Verizon wireless broadband (i.e. it's never on a private network).
(c) doesn't work in all cases, particularly if VPN traffic is blocked. I
believe I understand the security implications of choosing (a), but please
let me know if there's something inherently insecure about having domain
services exposed to untrusted hosts.

The problem is that my domain spans infrastructure over which I don't have
control, and in particular, Windows clients and Explorer don't degrade
gracefully when the AD DNS is available but port 445 traffic is disallowed.
Because port 445 is blocked arbitrarily, I don't have a good way to block AD
DNS requests from those networks.

I believe this is a limitation of Windows/Explorer and probably something
that could be addressed.

Nevertheless, I'm still open to suggestions that don't involve buying more
equipment.

"Paul Bergson [MVP-DS]" wrote:

> Are you saying that your AD dns server is visible to the world? If so that
> is a bad idea and I'm guessing your workstation is attempting to talk to
> services inside the firewall which your client can't reach (At least I hope
> you have that all firewalled off). I would try to get a dns server address
> from whatever dhcp service provides your client with an ip address. I could
> be wrong but that sounds like where your problem is stemming from.
>
> --
> Paul Bergson
> MVP - Directory Services
> MCT, MCSE, MCSA, Security+, BS CSci
> 2003, 2000 (Early Achiever), NT
>
> http://www.pbbergs.com
>
> Please no e-mails, any questions should be posted in the NewsGroup
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
> "Jason R. Coombs" <(E-Mail Removed)> wrote in message
> newsB5D9888-34C4-4829-9198-(E-Mail Removed)...
> > I originally posted this in Winodws Vista administration; I'm posting here
> > to encourage a response.
> >
> > I experience unresponsiveness (also could be seen as slowdown) after
> > joining
> > my Vista machines to the active directory. I experience it particularly
> > when
> > I take an
> > AD-joined laptop and carry it to another location, such as a friend's
> > house
> > or coffee shop. When I do this, and the provider (e.g. Comcast or
> > T-Mobile,
> > because I know the problems occur there) blocks port 445 outgoing, the
> > symptoms will arise. In particular, any function that requires interaction
> > with Explorer (.exe) will take 30-90 seconds to complete. This includes,
> > for
> > example, saving a downloaded file using Firefox. Because Firefox
> > integrates
> > with Explorer to save files (I think to render the icons), when I try to
> > save
> > a file using firefox in this environment, the download will block for
> > 30-90
> > seconds before proceeding.
> >
> > It seems to be that Explorer is blocking to perform some sort of Active
> > Directory action which requires port 445 (microsoft-ds) on which to
> > communicate. Explorer resolves a name for the AD action but must wait for
> > the TCP timeout to occur before returning control to the calling
> > application.
> >
> > I don't use isolated DNS, so my Active Directory DNS is visible from any
> > host on the Internet. I can see in other deployments why this symptom
> > would
> > not arise -- because if the DNS were isolated, the host would not have an
> > AD
> > server to attempt a connection, and thus would not have to wait for the
> > TCP
> > timeout.
> >
> > I would not be feasible for me to put an AD server at every location,
> > because I have about 2 PCs per location, so it's also difficult for me to
> > isolate the DNS.
> >
> > This problem occurs with or without roaming profiles. It occurs on brand
> > new Vista machines recently joined to the domain. This problem also
> > exhibited itself to a lesser degree in Windows XP.
> >
> > One work-around that often works is to establish a VPN connection to one
> > of
> > the domain controllers. In this way, microsoft-ds traffic can pass
> > unobstructed, and the problem goes away immediately. Unfortunately, it's
> > cumbersome to instruct other users to establish a VPN connection to keep
> > their machine from becoming non-responsive.
> >
> > This to me is clearly a design flaw or design oversight, or possibly just
> > an
> > unsupported configuration.
> >
> > I've applied all Windows Updates as well as kb941649, but the behavior
> > remains the same.
> >
> > I would very much appreciate any suggestions for alleviating this problem.
> > I'm also happy to provide additional details if a Microsoft rep takes
> > interest in reproducing the problem.
> >
> > Sincerely,
> > Jason R. Coombs
>
>
>

Once I have better understood what you are attempting to do, I don't know a
way around other than vpn and I haven't worked with a system like what you
have setup. 2008 will provide rodc's which is being presented (From what I
understand) to be more of what you are attempting to accomplish.

--
Paul Bergson
MVP - Directory Services
MCT, MCSE, MCSA, Security+, BS CSci
2003, 2000 (Early Achiever), NT

http://www.pbbergs.com

Please no e-mails, any questions should be posted in the NewsGroup
This posting is provided "AS IS" with no warranties, and confers no rights.

"Jason R. Coombs" <(E-Mail Removed)> wrote in message
news:9B5A59EC-035B-4D68-A36A-(E-Mail Removed)...
> Thanks Paul for the comments.
>
> To clarify, yes, the AD dns server is visible to the world. I don't see
> this as being a particularly bad idea. I don't have AD traffic firewalled
> off, because I want to have Directory Services (single sign-on, etc)
> available to the client machines regardless of where they're located. In
> other words, the Internet is my intranet.
>
> I'm using ISP-assigned DNS servers; my AD domain is also my Internet
> domain,
> so when my machines want to authenticate to the domain, they query the
> Internet domain servers, which forward the requests to the domain
> controllers.
>
> This is the most straightforward and direct implementation of an AD domain
> over a WAN. Again, I don't see a way to have an AD domain with unified
> authentication and single-sign-on without
> (a) having one domain controller that's globally accessible,
> (b) having domain controllers at every site, or
> (c) using VPN connections to tunnel.
>
> (b) is impractical due to licensing costs of Windows Server and the fact
> that I have 1-2 PCs per site. One laptop is primarily on the Internet
> through Verizon wireless broadband (i.e. it's never on a private network).
> (c) doesn't work in all cases, particularly if VPN traffic is blocked. I
> believe I understand the security implications of choosing (a), but please
> let me know if there's something inherently insecure about having domain
> services exposed to untrusted hosts.
>
> The problem is that my domain spans infrastructure over which I don't have
> control, and in particular, Windows clients and Explorer don't degrade
> gracefully when the AD DNS is available but port 445 traffic is
> disallowed.
> Because port 445 is blocked arbitrarily, I don't have a good way to block
> AD
> DNS requests from those networks.
>
> I believe this is a limitation of Windows/Explorer and probably something
> that could be addressed.
>
> Nevertheless, I'm still open to suggestions that don't involve buying more
> equipment.
>
> "Paul Bergson [MVP-DS]" wrote:
>
>> Are you saying that your AD dns server is visible to the world? If so
>> that
>> is a bad idea and I'm guessing your workstation is attempting to talk to
>> services inside the firewall which your client can't reach (At least I
>> hope
>> you have that all firewalled off). I would try to get a dns server
>> address
>> from whatever dhcp service provides your client with an ip address. I
>> could
>> be wrong but that sounds like where your problem is stemming from.
>>
>> --
>> Paul Bergson
>> MVP - Directory Services
>> MCT, MCSE, MCSA, Security+, BS CSci
>> 2003, 2000 (Early Achiever), NT
>>
>> http://www.pbbergs.com
>>
>> Please no e-mails, any questions should be posted in the NewsGroup
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>>
>> "Jason R. Coombs" <(E-Mail Removed)> wrote in
>> message
>> newsB5D9888-34C4-4829-9198-(E-Mail Removed)...
>> > I originally posted this in Winodws Vista administration; I'm posting
>> > here
>> > to encourage a response.
>> >
>> > I experience unresponsiveness (also could be seen as slowdown) after
>> > joining
>> > my Vista machines to the active directory. I experience it particularly
>> > when
>> > I take an
>> > AD-joined laptop and carry it to another location, such as a friend's
>> > house
>> > or coffee shop. When I do this, and the provider (e.g. Comcast or
>> > T-Mobile,
>> > because I know the problems occur there) blocks port 445 outgoing, the
>> > symptoms will arise. In particular, any function that requires
>> > interaction
>> > with Explorer (.exe) will take 30-90 seconds to complete. This
>> > includes,
>> > for
>> > example, saving a downloaded file using Firefox. Because Firefox
>> > integrates
>> > with Explorer to save files (I think to render the icons), when I try
>> > to
>> > save
>> > a file using firefox in this environment, the download will block for
>> > 30-90
>> > seconds before proceeding.
>> >
>> > It seems to be that Explorer is blocking to perform some sort of Active
>> > Directory action which requires port 445 (microsoft-ds) on which to
>> > communicate. Explorer resolves a name for the AD action but must wait
>> > for
>> > the TCP timeout to occur before returning control to the calling
>> > application.
>> >
>> > I don't use isolated DNS, so my Active Directory DNS is visible from
>> > any
>> > host on the Internet. I can see in other deployments why this symptom
>> > would
>> > not arise -- because if the DNS were isolated, the host would not have
>> > an
>> > AD
>> > server to attempt a connection, and thus would not have to wait for the
>> > TCP
>> > timeout.
>> >
>> > I would not be feasible for me to put an AD server at every location,
>> > because I have about 2 PCs per location, so it's also difficult for me
>> > to
>> > isolate the DNS.
>> >
>> > This problem occurs with or without roaming profiles. It occurs on
>> > brand
>> > new Vista machines recently joined to the domain. This problem also
>> > exhibited itself to a lesser degree in Windows XP.
>> >
>> > One work-around that often works is to establish a VPN connection to
>> > one
>> > of
>> > the domain controllers. In this way, microsoft-ds traffic can pass
>> > unobstructed, and the problem goes away immediately. Unfortunately,
>> > it's
>> > cumbersome to instruct other users to establish a VPN connection to
>> > keep
>> > their machine from becoming non-responsive.
>> >
>> > This to me is clearly a design flaw or design oversight, or possibly
>> > just
>> > an
>> > unsupported configuration.
>> >
>> > I've applied all Windows Updates as well as kb941649, but the behavior
>> > remains the same.
>> >
>> > I would very much appreciate any suggestions for alleviating this
>> > problem.
>> > I'm also happy to provide additional details if a Microsoft rep takes
>> > interest in reproducing the problem.
>> >
>> > Sincerely,
>> > Jason R. Coombs
>>
>>
>>