"Chris Martin" <ChrisMar***@discussions.microsoft.com> wrote in message
news:2AFDEDA1-52B6-437A-B7D3-4089B7E55C9F@microsoft.com...
> We have a situation where group policies are not applying on XP desktops
> and
> laptops at a remote site, which links back to the head office via a VPN
> tunnel (which is working fine). Authentication is working, so it's
> probably
> not an issue with the VPN. There are no ports blocked over the VPN.
>
> The site is defined in AD Sites and services and the IP range exists in
> ADS&S, too, and is set as the site range. Reverse DNS zones have been
> created
> in DNS (as AD replicated zones) and the DNS hives have been
> auto-generated.
> There is no reason I can see that machines shouldn't be able to determine
> what AD DCs service their site however the machines are all recording
> Event
> ID: 1054 and not applying GPOs.
>
> There are no connectivity issues, other than the latency involved, but
> there
> are only two users at the site, so that shouldn't be an issue.
>
> I read in the following article that there is slow link detection
> (http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/distrib/dsec_pol_chzb.mspx?mfr=true).
> To adjust this, do I have to change it on the domain controller or the
> desktop/laptop? If it must be set on the desktop/laptop, how can we fix it
> as
> it's set in a GPO (sort of a chicken in the egg thing: it can't be set
> before
> it's set, as GPOs are already not applying)? If the group policies aren't
> applying for this reason, is this the error we'd expect? I would have
> thought
> that a slow link would have generated a different error to this as this
> error
> suggests that the PC can't determine what site it is in, rather than than
> a
> slow link causing it to fail. If it is a slow link issue, maybe the error
> message should be amended to make it a little more useful for diagnostics.
>
> If it's not at all related to slow link detection then, what could it be?
> Given that authentication and DNS seem to beem working 100%, what could be
> causing this and what's my next step in diagnosing the issue?
>
> Thanks!
>
> --
> Chris Martin
> SysAdmin
> Medfin

"Anthony" wrote:

> Chris,
> Are the clients using only your internal DNS servers as their Preferred and
> Alternate DNS Server address?
> Anthony, http://www.airdesk.com
>
> "Chris Martin" <ChrisMar***@discussions.microsoft.com> wrote in message
> news:2AFDEDA1-52B6-437A-B7D3-4089B7E55C9F@microsoft.com...
> > We have a situation where group policies are not applying on XP desktops
> > and
> > laptops at a remote site, which links back to the head office via a VPN
> > tunnel (which is working fine). Authentication is working, so it's
> > probably
> > not an issue with the VPN. There are no ports blocked over the VPN.
> >
> > The site is defined in AD Sites and services and the IP range exists in
> > ADS&S, too, and is set as the site range. Reverse DNS zones have been
> > created
> > in DNS (as AD replicated zones) and the DNS hives have been
> > auto-generated.
> > There is no reason I can see that machines shouldn't be able to determine
> > what AD DCs service their site however the machines are all recording
> > Event
> > ID: 1054 and not applying GPOs.
> >
> > There are no connectivity issues, other than the latency involved, but
> > there
> > are only two users at the site, so that shouldn't be an issue.
> >
> > I read in the following article that there is slow link detection
> > (http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/distrib/dsec_pol_chzb.mspx?mfr=true).
> > To adjust this, do I have to change it on the domain controller or the
> > desktop/laptop? If it must be set on the desktop/laptop, how can we fix it
> > as
> > it's set in a GPO (sort of a chicken in the egg thing: it can't be set
> > before
> > it's set, as GPOs are already not applying)? If the group policies aren't
> > applying for this reason, is this the error we'd expect? I would have
> > thought
> > that a slow link would have generated a different error to this as this
> > error
> > suggests that the PC can't determine what site it is in, rather than than
> > a
> > slow link causing it to fail. If it is a slow link issue, maybe the error
> > message should be amended to make it a little more useful for diagnostics.
> >
> > If it's not at all related to slow link detection then, what could it be?
> > Given that authentication and DNS seem to beem working 100%, what could be
> > causing this and what's my next step in diagnosing the issue?
> >
> > Thanks!
> >
> > --
> > Chris Martin
> > SysAdmin
> > Medfin
>
>
>

"Chris Martin" <ChrisMar***@discussions.microsoft.com> wrote in message
news:815B7E62-DC93-4972-978A-6191C5AC4C54@microsoft.com...
> Yes, they are configured only with the address of our AD DNS servers.
>
> I have run netdiag and everything passes.
>
> i have checked DNS and it has all the SRV records in the right places.
> There
> are GCs available for use and which are accessable. There are no
> restrictions
> on the VPN, no port blocking or anything.
>
> Any further diagnostics anyone can think of?
>
> --
> Chris Martin
> SysAdmin
> Medfin
>
>
> "Anthony" wrote:
>
>> Chris,
>> Are the clients using only your internal DNS servers as their Preferred
>> and
>> Alternate DNS Server address?
>> Anthony, http://www.airdesk.com
>>
>> "Chris Martin" <ChrisMar***@discussions.microsoft.com> wrote in message
>> news:2AFDEDA1-52B6-437A-B7D3-4089B7E55C9F@microsoft.com...
>> > We have a situation where group policies are not applying on XP
>> > desktops
>> > and
>> > laptops at a remote site, which links back to the head office via a VPN
>> > tunnel (which is working fine). Authentication is working, so it's
>> > probably
>> > not an issue with the VPN. There are no ports blocked over the VPN.
>> >
>> > The site is defined in AD Sites and services and the IP range exists in
>> > ADS&S, too, and is set as the site range. Reverse DNS zones have been
>> > created
>> > in DNS (as AD replicated zones) and the DNS hives have been
>> > auto-generated.
>> > There is no reason I can see that machines shouldn't be able to
>> > determine
>> > what AD DCs service their site however the machines are all recording
>> > Event
>> > ID: 1054 and not applying GPOs.
>> >
>> > There are no connectivity issues, other than the latency involved, but
>> > there
>> > are only two users at the site, so that shouldn't be an issue.
>> >
>> > I read in the following article that there is slow link detection
>> > (http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/distrib/dsec_pol_chzb.mspx?mfr=true).
>> > To adjust this, do I have to change it on the domain controller or the
>> > desktop/laptop? If it must be set on the desktop/laptop, how can we fix
>> > it
>> > as
>> > it's set in a GPO (sort of a chicken in the egg thing: it can't be set
>> > before
>> > it's set, as GPOs are already not applying)? If the group policies
>> > aren't
>> > applying for this reason, is this the error we'd expect? I would have
>> > thought
>> > that a slow link would have generated a different error to this as this
>> > error
>> > suggests that the PC can't determine what site it is in, rather than
>> > than
>> > a
>> > slow link causing it to fail. If it is a slow link issue, maybe the
>> > error
>> > message should be amended to make it a little more useful for
>> > diagnostics.
>> >
>> > If it's not at all related to slow link detection then, what could it
>> > be?
>> > Given that authentication and DNS seem to beem working 100%, what could
>> > be
>> > causing this and what's my next step in diagnosing the issue?
>> >
>> > Thanks!
>> >
>> > --
>> > Chris Martin
>> > SysAdmin
>> > Medfin
>>
>>
>>

"Anthony" wrote:

> Chris,
> to answer your first question, you can set the registry key remotely:
> http://technet2.microsoft.com/windowsserver/en/library/92c46246-7cb7-441e-92d6-2b6671c2980e1033.mspx?mfr=true
> Anthony, http://www.airdesk.co.uk
>
> "Chris Martin" <ChrisMar***@discussions.microsoft.com> wrote in message
> news:815B7E62-DC93-4972-978A-6191C5AC4C54@microsoft.com...
> > Yes, they are configured only with the address of our AD DNS servers.
> >
> > I have run netdiag and everything passes.
> >
> > i have checked DNS and it has all the SRV records in the right places.
> > There
> > are GCs available for use and which are accessable. There are no
> > restrictions
> > on the VPN, no port blocking or anything.
> >
> > Any further diagnostics anyone can think of?
> >
> > --
> > Chris Martin
> > SysAdmin
> > Medfin
> >
> >
> > "Anthony" wrote:
> >
> >> Chris,
> >> Are the clients using only your internal DNS servers as their Preferred
> >> and
> >> Alternate DNS Server address?
> >> Anthony, http://www.airdesk.com
> >>
> >> "Chris Martin" <ChrisMar***@discussions.microsoft.com> wrote in message
> >> news:2AFDEDA1-52B6-437A-B7D3-4089B7E55C9F@microsoft.com...
> >> > We have a situation where group policies are not applying on XP
> >> > desktops
> >> > and
> >> > laptops at a remote site, which links back to the head office via a VPN
> >> > tunnel (which is working fine). Authentication is working, so it's
> >> > probably
> >> > not an issue with the VPN. There are no ports blocked over the VPN.
> >> >
> >> > The site is defined in AD Sites and services and the IP range exists in
> >> > ADS&S, too, and is set as the site range. Reverse DNS zones have been
> >> > created
> >> > in DNS (as AD replicated zones) and the DNS hives have been
> >> > auto-generated.
> >> > There is no reason I can see that machines shouldn't be able to
> >> > determine
> >> > what AD DCs service their site however the machines are all recording
> >> > Event
> >> > ID: 1054 and not applying GPOs.
> >> >
> >> > There are no connectivity issues, other than the latency involved, but
> >> > there
> >> > are only two users at the site, so that shouldn't be an issue.
> >> >
> >> > I read in the following article that there is slow link detection
> >> > (http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/distrib/dsec_pol_chzb.mspx?mfr=true).
> >> > To adjust this, do I have to change it on the domain controller or the
> >> > desktop/laptop? If it must be set on the desktop/laptop, how can we fix
> >> > it
> >> > as
> >> > it's set in a GPO (sort of a chicken in the egg thing: it can't be set
> >> > before
> >> > it's set, as GPOs are already not applying)? If the group policies
> >> > aren't
> >> > applying for this reason, is this the error we'd expect? I would have
> >> > thought
> >> > that a slow link would have generated a different error to this as this
> >> > error
> >> > suggests that the PC can't determine what site it is in, rather than
> >> > than
> >> > a
> >> > slow link causing it to fail. If it is a slow link issue, maybe the
> >> > error
> >> > message should be amended to make it a little more useful for
> >> > diagnostics.
> >> >
> >> > If it's not at all related to slow link detection then, what could it
> >> > be?
> >> > Given that authentication and DNS seem to beem working 100%, what could
> >> > be
> >> > causing this and what's my next step in diagnosing the issue?
> >> >
> >> > Thanks!
> >> >
> >> > --
> >> > Chris Martin
> >> > SysAdmin
> >> > Medfin
> >>
> >>
> >>
>
>
>

>
>> Chris,
>> to answer your first question, you can set the registry key remotely:
>> http://technet2.microsoft.com/windowsserver/en/library/92c46246-7cb7-441e-92d6-2b6671c2980e1033.mspx?mfr=true
>> Anthony, http://www.airdesk.co.uk
>>
>> "Chris Martin" <ChrisMar***@discussions.microsoft.com> wrote in
>> message news:815B7E62-DC93-4972-978A-6191C5AC4C54@microsoft.com...
>>> Yes, they are configured only with the address of our AD DNS
>>> servers.
>>>
>>> I have run netdiag and everything passes.
>>>
>>> i have checked DNS and it has all the SRV records in the right
>>> places. There
>>> are GCs available for use and which are accessable. There are no
>>> restrictions
>>> on the VPN, no port blocking or anything.
>>>
>>> Any further diagnostics anyone can think of?
>>>
>>> --
>>> Chris Martin
>>> SysAdmin
>>> Medfin
>>>
>>>
>>> "Anthony" wrote:
>>>
>>>> Chris,
>>>> Are the clients using only your internal DNS servers as their
>>>> Preferred and
>>>> Alternate DNS Server address?
>>>> Anthony, http://www.airdesk.com
>>>>
>>>> "Chris Martin" <ChrisMar***@discussions.microsoft.com> wrote in
>>>> message news:2AFDEDA1-52B6-437A-B7D3-4089B7E55C9F@microsoft.com...
>>>>> We have a situation where group policies are not applying on XP
>>>>> desktops
>>>>> and
>>>>> laptops at a remote site, which links back to the head office via
>>>>> a VPN tunnel (which is working fine). Authentication is working,
>>>>> so it's probably
>>>>> not an issue with the VPN. There are no ports blocked over the
>>>>> VPN.
>>>>>
>>>>> The site is defined in AD Sites and services and the IP range
>>>>> exists in ADS&S, too, and is set as the site range. Reverse DNS
>>>>> zones have been created
>>>>> in DNS (as AD replicated zones) and the DNS hives have been
>>>>> auto-generated.
>>>>> There is no reason I can see that machines shouldn't be able to
>>>>> determine
>>>>> what AD DCs service their site however the machines are all
>>>>> recording Event
>>>>> ID: 1054 and not applying GPOs.
>>>>>
>>>>> There are no connectivity issues, other than the latency
>>>>> involved, but there
>>>>> are only two users at the site, so that shouldn't be an issue.
>>>>>
>>>>> I read in the following article that there is slow link detection
>>>>> (http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/distrib/dsec_pol_chzb.mspx?mfr=true).
>>>>> To adjust this, do I have to change it on the domain controller
>>>>> or the desktop/laptop? If it must be set on the desktop/laptop,
>>>>> how can we fix it
>>>>> as
>>>>> it's set in a GPO (sort of a chicken in the egg thing: it can't
>>>>> be set before
>>>>> it's set, as GPOs are already not applying)? If the group policies
>>>>> aren't
>>>>> applying for this reason, is this the error we'd expect? I would
>>>>> have thought
>>>>> that a slow link would have generated a different error to this
>>>>> as this error
>>>>> suggests that the PC can't determine what site it is in, rather
>>>>> than than
>>>>> a
>>>>> slow link causing it to fail. If it is a slow link issue, maybe
>>>>> the error
>>>>> message should be amended to make it a little more useful for
>>>>> diagnostics.
>>>>>
>>>>> If it's not at all related to slow link detection then, what
>>>>> could it be?
>>>>> Given that authentication and DNS seem to beem working 100%, what
>>>>> could be
>>>>> causing this and what's my next step in diagnosing the issue?
>>>>>
>>>>> Thanks!
>>>>>
>>>>> --
>>>>> Chris Martin
>>>>> SysAdmin
>>>>> Medfin

"kj [SBS MVP]" wrote:

> Chris Martin wrote:
> > OK, but I'm not even sure if that's the cause. The error itself would
> > seem to indicate an issue with the computer establishing what site it
> > belongs to, and thus it wouldn't be fixed by this.
> >
> > I will try disabling link speed detection and see if it fixes the
> > issue.
> >
>
> Also check the Network Location Awareness Service status and make sure it is
> started.
>
> >
> >> Chris,
> >> to answer your first question, you can set the registry key remotely:
> >> http://technet2.microsoft.com/windowsserver/en/library/92c46246-7cb7-441e-92d6-2b6671c2980e1033.mspx?mfr=true
> >> Anthony, http://www.airdesk.co.uk
> >>
> >> "Chris Martin" <ChrisMar***@discussions.microsoft.com> wrote in
> >> message news:815B7E62-DC93-4972-978A-6191C5AC4C54@microsoft.com...
> >>> Yes, they are configured only with the address of our AD DNS
> >>> servers.
> >>>
> >>> I have run netdiag and everything passes.
> >>>
> >>> i have checked DNS and it has all the SRV records in the right
> >>> places. There
> >>> are GCs available for use and which are accessable. There are no
> >>> restrictions
> >>> on the VPN, no port blocking or anything.
> >>>
> >>> Any further diagnostics anyone can think of?
> >>>
> >>> --
> >>> Chris Martin
> >>> SysAdmin
> >>> Medfin
> >>>
> >>>
> >>> "Anthony" wrote:
> >>>
> >>>> Chris,
> >>>> Are the clients using only your internal DNS servers as their
> >>>> Preferred and
> >>>> Alternate DNS Server address?
> >>>> Anthony, http://www.airdesk.com
> >>>>
> >>>> "Chris Martin" <ChrisMar***@discussions.microsoft.com> wrote in
> >>>> message news:2AFDEDA1-52B6-437A-B7D3-4089B7E55C9F@microsoft.com...
> >>>>> We have a situation where group policies are not applying on XP
> >>>>> desktops
> >>>>> and
> >>>>> laptops at a remote site, which links back to the head office via
> >>>>> a VPN tunnel (which is working fine). Authentication is working,
> >>>>> so it's probably
> >>>>> not an issue with the VPN. There are no ports blocked over the
> >>>>> VPN.
> >>>>>
> >>>>> The site is defined in AD Sites and services and the IP range
> >>>>> exists in ADS&S, too, and is set as the site range. Reverse DNS
> >>>>> zones have been created
> >>>>> in DNS (as AD replicated zones) and the DNS hives have been
> >>>>> auto-generated.
> >>>>> There is no reason I can see that machines shouldn't be able to
> >>>>> determine
> >>>>> what AD DCs service their site however the machines are all
> >>>>> recording Event
> >>>>> ID: 1054 and not applying GPOs.
> >>>>>
> >>>>> There are no connectivity issues, other than the latency
> >>>>> involved, but there
> >>>>> are only two users at the site, so that shouldn't be an issue.
> >>>>>
> >>>>> I read in the following article that there is slow link detection
> >>>>> (http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/distrib/dsec_pol_chzb.mspx?mfr=true).
> >>>>> To adjust this, do I have to change it on the domain controller
> >>>>> or the desktop/laptop? If it must be set on the desktop/laptop,
> >>>>> how can we fix it
> >>>>> as
> >>>>> it's set in a GPO (sort of a chicken in the egg thing: it can't
> >>>>> be set before
> >>>>> it's set, as GPOs are already not applying)? If the group policies
> >>>>> aren't
> >>>>> applying for this reason, is this the error we'd expect? I would
> >>>>> have thought
> >>>>> that a slow link would have generated a different error to this
> >>>>> as this error
> >>>>> suggests that the PC can't determine what site it is in, rather
> >>>>> than than
> >>>>> a
> >>>>> slow link causing it to fail. If it is a slow link issue, maybe
> >>>>> the error
> >>>>> message should be amended to make it a little more useful for
> >>>>> diagnostics.
> >>>>>
> >>>>> If it's not at all related to slow link detection then, what
> >>>>> could it be?
> >>>>> Given that authentication and DNS seem to beem working 100%, what
> >>>>> could be
> >>>>> causing this and what's my next step in diagnosing the issue?
> >>>>>
> >>>>> Thanks!
> >>>>>
> >>>>> --
> >>>>> Chris Martin
> >>>>> SysAdmin
> >>>>> Medfin
>
> --
> /kj
>
>
>

"Chris Martin" <ChrisMar***@discussions.microsoft.com> wrote in message
news:95DEA948-1B43-45ED-93EA-0CACC7C899AA@microsoft.com...
> OK, but I'm not even sure if that's the cause. The error itself would seem
> to
> indicate an issue with the computer establishing what site it belongs to,
> and
> thus it wouldn't be fixed by this.
>
> I will try disabling link speed detection and see if it fixes the issue.
>
> --
> Chris Martin
> SysAdmin
> Medfin
>
>
> "Anthony" wrote:
>
>> Chris,
>> to answer your first question, you can set the registry key remotely:
>> http://technet2.microsoft.com/windowsserver/en/library/92c46246-7cb7-441e-92d6-2b6671c2980e1033.mspx?mfr=true
>> Anthony, http://www.airdesk.co.uk
>>
>> "Chris Martin" <ChrisMar***@discussions.microsoft.com> wrote in message
>> news:815B7E62-DC93-4972-978A-6191C5AC4C54@microsoft.com...
>> > Yes, they are configured only with the address of our AD DNS servers.
>> >
>> > I have run netdiag and everything passes.
>> >
>> > i have checked DNS and it has all the SRV records in the right places.
>> > There
>> > are GCs available for use and which are accessable. There are no
>> > restrictions
>> > on the VPN, no port blocking or anything.
>> >
>> > Any further diagnostics anyone can think of?
>> >
>> > --
>> > Chris Martin
>> > SysAdmin
>> > Medfin
>> >
>> >
>> > "Anthony" wrote:
>> >
>> >> Chris,
>> >> Are the clients using only your internal DNS servers as their
>> >> Preferred
>> >> and
>> >> Alternate DNS Server address?
>> >> Anthony, http://www.airdesk.com
>> >>
>> >> "Chris Martin" <ChrisMar***@discussions.microsoft.com> wrote in
>> >> message
>> >> news:2AFDEDA1-52B6-437A-B7D3-4089B7E55C9F@microsoft.com...
>> >> > We have a situation where group policies are not applying on XP
>> >> > desktops
>> >> > and
>> >> > laptops at a remote site, which links back to the head office via a
>> >> > VPN
>> >> > tunnel (which is working fine). Authentication is working, so it's
>> >> > probably
>> >> > not an issue with the VPN. There are no ports blocked over the VPN.
>> >> >
>> >> > The site is defined in AD Sites and services and the IP range exists
>> >> > in
>> >> > ADS&S, too, and is set as the site range. Reverse DNS zones have
>> >> > been
>> >> > created
>> >> > in DNS (as AD replicated zones) and the DNS hives have been
>> >> > auto-generated.
>> >> > There is no reason I can see that machines shouldn't be able to
>> >> > determine
>> >> > what AD DCs service their site however the machines are all
>> >> > recording
>> >> > Event
>> >> > ID: 1054 and not applying GPOs.
>> >> >
>> >> > There are no connectivity issues, other than the latency involved,
>> >> > but
>> >> > there
>> >> > are only two users at the site, so that shouldn't be an issue.
>> >> >
>> >> > I read in the following article that there is slow link detection
>> >> > (http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/distrib/dsec_pol_chzb.mspx?mfr=true).
>> >> > To adjust this, do I have to change it on the domain controller or
>> >> > the
>> >> > desktop/laptop? If it must be set on the desktop/laptop, how can we
>> >> > fix
>> >> > it
>> >> > as
>> >> > it's set in a GPO (sort of a chicken in the egg thing: it can't be
>> >> > set
>> >> > before
>> >> > it's set, as GPOs are already not applying)? If the group policies
>> >> > aren't
>> >> > applying for this reason, is this the error we'd expect? I would
>> >> > have
>> >> > thought
>> >> > that a slow link would have generated a different error to this as
>> >> > this
>> >> > error
>> >> > suggests that the PC can't determine what site it is in, rather than
>> >> > than
>> >> > a
>> >> > slow link causing it to fail. If it is a slow link issue, maybe the
>> >> > error
>> >> > message should be amended to make it a little more useful for
>> >> > diagnostics.
>> >> >
>> >> > If it's not at all related to slow link detection then, what could
>> >> > it
>> >> > be?
>> >> > Given that authentication and DNS seem to beem working 100%, what
>> >> > could
>> >> > be
>> >> > causing this and what's my next step in diagnosing the issue?
>> >> >
>> >> > Thanks!
>> >> >
>> >> > --
>> >> > Chris Martin
>> >> > SysAdmin
>> >> > Medfin
>> >>
>> >>
>> >>
>>
>>
>>

"Anthony" wrote:

> The things I can think of to look at:
> - correct registration in DNS: try deleting the record and do /registerdns
> to renew it
> - machine account: try resetting it, or rejoining domain
> - try "wait for network" at startup
> - if the problem is just this site, there is also a potential problem with
> MTU's over VPN: can you connect to remote management over the VPN, e.g
> Computer Manager?
> Hope that helps,
> Anthony, http://www.airdesk.co.uk
>
>
> "Chris Martin" <ChrisMar***@discussions.microsoft.com> wrote in message
> news:95DEA948-1B43-45ED-93EA-0CACC7C899AA@microsoft.com...
> > OK, but I'm not even sure if that's the cause. The error itself would seem
> > to
> > indicate an issue with the computer establishing what site it belongs to,
> > and
> > thus it wouldn't be fixed by this.
> >
> > I will try disabling link speed detection and see if it fixes the issue.
> >
> > --
> > Chris Martin
> > SysAdmin
> > Medfin
> >
> >
> > "Anthony" wrote:
> >
> >> Chris,
> >> to answer your first question, you can set the registry key remotely:
> >> http://technet2.microsoft.com/windowsserver/en/library/92c46246-7cb7-441e-92d6-2b6671c2980e1033.mspx?mfr=true
> >> Anthony, http://www.airdesk.co.uk
> >>
> >> "Chris Martin" <ChrisMar***@discussions.microsoft.com> wrote in message
> >> news:815B7E62-DC93-4972-978A-6191C5AC4C54@microsoft.com...
> >> > Yes, they are configured only with the address of our AD DNS servers.
> >> >
> >> > I have run netdiag and everything passes.
> >> >
> >> > i have checked DNS and it has all the SRV records in the right places.
> >> > There
> >> > are GCs available for use and which are accessable. There are no
> >> > restrictions
> >> > on the VPN, no port blocking or anything.
> >> >
> >> > Any further diagnostics anyone can think of?
> >> >
> >> > --
> >> > Chris Martin
> >> > SysAdmin
> >> > Medfin
> >> >
> >> >
> >> > "Anthony" wrote:
> >> >
> >> >> Chris,
> >> >> Are the clients using only your internal DNS servers as their
> >> >> Preferred
> >> >> and
> >> >> Alternate DNS Server address?
> >> >> Anthony, http://www.airdesk.com
> >> >>
> >> >> "Chris Martin" <ChrisMar***@discussions.microsoft.com> wrote in
> >> >> message
> >> >> news:2AFDEDA1-52B6-437A-B7D3-4089B7E55C9F@microsoft.com...
> >> >> > We have a situation where group policies are not applying on XP
> >> >> > desktops
> >> >> > and
> >> >> > laptops at a remote site, which links back to the head office via a
> >> >> > VPN
> >> >> > tunnel (which is working fine). Authentication is working, so it's
> >> >> > probably
> >> >> > not an issue with the VPN. There are no ports blocked over the VPN.
> >> >> >
> >> >> > The site is defined in AD Sites and services and the IP range exists
> >> >> > in
> >> >> > ADS&S, too, and is set as the site range. Reverse DNS zones have
> >> >> > been
> >> >> > created
> >> >> > in DNS (as AD replicated zones) and the DNS hives have been
> >> >> > auto-generated.
> >> >> > There is no reason I can see that machines shouldn't be able to
> >> >> > determine
> >> >> > what AD DCs service their site however the machines are all
> >> >> > recording
> >> >> > Event
> >> >> > ID: 1054 and not applying GPOs.
> >> >> >
> >> >> > There are no connectivity issues, other than the latency involved,
> >> >> > but
> >> >> > there
> >> >> > are only two users at the site, so that shouldn't be an issue.
> >> >> >
> >> >> > I read in the following article that there is slow link detection
> >> >> > (http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/distrib/dsec_pol_chzb.mspx?mfr=true).
> >> >> > To adjust this, do I have to change it on the domain controller or
> >> >> > the
> >> >> > desktop/laptop? If it must be set on the desktop/laptop, how can we
> >> >> > fix
> >> >> > it
> >> >> > as
> >> >> > it's set in a GPO (sort of a chicken in the egg thing: it can't be
> >> >> > set
> >> >> > before
> >> >> > it's set, as GPOs are already not applying)? If the group policies
> >> >> > aren't
> >> >> > applying for this reason, is this the error we'd expect? I would
> >> >> > have
> >> >> > thought
> >> >> > that a slow link would have generated a different error to this as
> >> >> > this
> >> >> > error
> >> >> > suggests that the PC can't determine what site it is in, rather than
> >> >> > than
> >> >> > a
> >> >> > slow link causing it to fail. If it is a slow link issue, maybe the
> >> >> > error
> >> >> > message should be amended to make it a little more useful for
> >> >> > diagnostics.
> >> >> >
> >> >> > If it's not at all related to slow link detection then, what could
> >> >> > it
> >> >> > be?
> >> >> > Given that authentication and DNS seem to beem working 100%, what
> >> >> > could
> >> >> > be
> >> >> > causing this and what's my next step in diagnosing the issue?
> >> >> >
> >> >> > Thanks!
> >> >> >
> >> >> > --
> >> >> > Chris Martin
> >> >> > SysAdmin
> >> >> > Medfin
> >> >>
> >> >>
> >> >>
> >>
> >>
> >>
>
>
>

"Chris Martin" <ChrisMar***@discussions.microsoft.com> wrote in message
news:6AAD0E63-5D1A-455C-BBFB-13E1A96B581E@microsoft.com...
>I had already tried all those issues. I renewed the DNS information with
> "ipconfig /registerdns" and had done MTU testing using pings with various
> payloads.
>
> I, at last, tried turning slow link detection and that fixed it. The even
> log message was very missleading and resulted in me wasting a great deal
> of
> time solving an issue which wasn't even an issue, but, instead, a designed
> limit. The event message should be amended to give a more useful
> description
> of the event, e.g. "Group Policy processing has been prevented due to slow
> link detection" rather than the event 1054 that I got, which instead
> suggests
> an NLA issue.
>
> --
> Chris Martin
> SysAdmin
> Medfin
>
>
> "Anthony" wrote:
>
>> The things I can think of to look at:
>> - correct registration in DNS: try deleting the record and do
>> /registerdns
>> to renew it
>> - machine account: try resetting it, or rejoining domain
>> - try "wait for network" at startup
>> - if the problem is just this site, there is also a potential problem
>> with
>> MTU's over VPN: can you connect to remote management over the VPN, e.g
>> Computer Manager?
>> Hope that helps,
>> Anthony, http://www.airdesk.co.uk
>>
>>
>> "Chris Martin" <ChrisMar***@discussions.microsoft.com> wrote in message
>> news:95DEA948-1B43-45ED-93EA-0CACC7C899AA@microsoft.com...
>> > OK, but I'm not even sure if that's the cause. The error itself would
>> > seem
>> > to
>> > indicate an issue with the computer establishing what site it belongs
>> > to,
>> > and
>> > thus it wouldn't be fixed by this.
>> >
>> > I will try disabling link speed detection and see if it fixes the
>> > issue.
>> >
>> > --
>> > Chris Martin
>> > SysAdmin
>> > Medfin
>> >
>> >
>> > "Anthony" wrote:
>> >
>> >> Chris,
>> >> to answer your first question, you can set the registry key remotely:
>> >> http://technet2.microsoft.com/windowsserver/en/library/92c46246-7cb7-441e-92d6-2b6671c2980e1033.mspx?mfr=true
>> >> Anthony, http://www.airdesk.co.uk
>> >>
>> >> "Chris Martin" <ChrisMar***@discussions.microsoft.com> wrote in
>> >> message
>> >> news:815B7E62-DC93-4972-978A-6191C5AC4C54@microsoft.com...
>> >> > Yes, they are configured only with the address of our AD DNS
>> >> > servers.
>> >> >
>> >> > I have run netdiag and everything passes.
>> >> >
>> >> > i have checked DNS and it has all the SRV records in the right
>> >> > places.
>> >> > There
>> >> > are GCs available for use and which are accessable. There are no
>> >> > restrictions
>> >> > on the VPN, no port blocking or anything.
>> >> >
>> >> > Any further diagnostics anyone can think of?
>> >> >
>> >> > --
>> >> > Chris Martin
>> >> > SysAdmin
>> >> > Medfin
>> >> >
>> >> >
>> >> > "Anthony" wrote:
>> >> >
>> >> >> Chris,
>> >> >> Are the clients using only your internal DNS servers as their
>> >> >> Preferred
>> >> >> and
>> >> >> Alternate DNS Server address?
>> >> >> Anthony, http://www.airdesk.com
>> >> >>
>> >> >> "Chris Martin" <ChrisMar***@discussions.microsoft.com> wrote in
>> >> >> message
>> >> >> news:2AFDEDA1-52B6-437A-B7D3-4089B7E55C9F@microsoft.com...
>> >> >> > We have a situation where group policies are not applying on XP
>> >> >> > desktops
>> >> >> > and
>> >> >> > laptops at a remote site, which links back to the head office via
>> >> >> > a
>> >> >> > VPN
>> >> >> > tunnel (which is working fine). Authentication is working, so
>> >> >> > it's
>> >> >> > probably
>> >> >> > not an issue with the VPN. There are no ports blocked over the
>> >> >> > VPN.
>> >> >> >
>> >> >> > The site is defined in AD Sites and services and the IP range
>> >> >> > exists
>> >> >> > in
>> >> >> > ADS&S, too, and is set as the site range. Reverse DNS zones have
>> >> >> > been
>> >> >> > created
>> >> >> > in DNS (as AD replicated zones) and the DNS hives have been
>> >> >> > auto-generated.
>> >> >> > There is no reason I can see that machines shouldn't be able to
>> >> >> > determine
>> >> >> > what AD DCs service their site however the machines are all
>> >> >> > recording
>> >> >> > Event
>> >> >> > ID: 1054 and not applying GPOs.
>> >> >> >
>> >> >> > There are no connectivity issues, other than the latency
>> >> >> > involved,
>> >> >> > but
>> >> >> > there
>> >> >> > are only two users at the site, so that shouldn't be an issue.
>> >> >> >
>> >> >> > I read in the following article that there is slow link detection
>> >> >> > (http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/distrib/dsec_pol_chzb.mspx?mfr=true).
>> >> >> > To adjust this, do I have to change it on the domain controller
>> >> >> > or
>> >> >> > the
>> >> >> > desktop/laptop? If it must be set on the desktop/laptop, how can
>> >> >> > we
>> >> >> > fix
>> >> >> > it
>> >> >> > as
>> >> >> > it's set in a GPO (sort of a chicken in the egg thing: it can't
>> >> >> > be
>> >> >> > set
>> >> >> > before
>> >> >> > it's set, as GPOs are already not applying)? If the group
>> >> >> > policies
>> >> >> > aren't
>> >> >> > applying for this reason, is this the error we'd expect? I would
>> >> >> > have
>> >> >> > thought
>> >> >> > that a slow link would have generated a different error to this
>> >> >> > as
>> >> >> > this
>> >> >> > error
>> >> >> > suggests that the PC can't determine what site it is in, rather
>> >> >> > than
>> >> >> > than
>> >> >> > a
>> >> >> > slow link causing it to fail. If it is a slow link issue, maybe
>> >> >> > the
>> >> >> > error
>> >> >> > message should be amended to make it a little more useful for
>> >> >> > diagnostics.
>> >> >> >
>> >> >> > If it's not at all related to slow link detection then, what
>> >> >> > could
>> >> >> > it
>> >> >> > be?
>> >> >> > Given that authentication and DNS seem to beem working 100%, what
>> >> >> > could
>> >> >> > be
>> >> >> > causing this and what's my next step in diagnosing the issue?
>> >> >> >
>> >> >> > Thanks!
>> >> >> >
>> >> >> > --
>> >> >> > Chris Martin
>> >> >> > SysAdmin
>> >> >> > Medfin
>> >> >>
>> >> >>
>> >> >>
>> >>
>> >>
>> >>
>>
>>
>>

"Anthony" wrote:

> Well. I'm glad that fixed it,
> Anthony, http://www.airdesk.co.uk
>
>
> "Chris Martin" <ChrisMar***@discussions.microsoft.com> wrote in message
> news:6AAD0E63-5D1A-455C-BBFB-13E1A96B581E@microsoft.com...
> >I had already tried all those issues. I renewed the DNS information with
> > "ipconfig /registerdns" and had done MTU testing using pings with various
> > payloads.
> >
> > I, at last, tried turning slow link detection and that fixed it. The even
> > log message was very missleading and resulted in me wasting a great deal
> > of
> > time solving an issue which wasn't even an issue, but, instead, a designed
> > limit. The event message should be amended to give a more useful
> > description
> > of the event, e.g. "Group Policy processing has been prevented due to slow
> > link detection" rather than the event 1054 that I got, which instead
> > suggests
> > an NLA issue.
> >
> > --
> > Chris Martin
> > SysAdmin
> > Medfin
> >
> >
> > "Anthony" wrote:
> >
> >> The things I can think of to look at:
> >> - correct registration in DNS: try deleting the record and do
> >> /registerdns
> >> to renew it
> >> - machine account: try resetting it, or rejoining domain
> >> - try "wait for network" at startup
> >> - if the problem is just this site, there is also a potential problem
> >> with
> >> MTU's over VPN: can you connect to remote management over the VPN, e.g
> >> Computer Manager?
> >> Hope that helps,
> >> Anthony, http://www.airdesk.co.uk
> >>
> >>
> >> "Chris Martin" <ChrisMar***@discussions.microsoft.com> wrote in message
> >> news:95DEA948-1B43-45ED-93EA-0CACC7C899AA@microsoft.com...
> >> > OK, but I'm not even sure if that's the cause. The error itself would
> >> > seem
> >> > to
> >> > indicate an issue with the computer establishing what site it belongs
> >> > to,
> >> > and
> >> > thus it wouldn't be fixed by this.
> >> >
> >> > I will try disabling link speed detection and see if it fixes the
> >> > issue.
> >> >
> >> > --
> >> > Chris Martin
> >> > SysAdmin
> >> > Medfin
> >> >
> >> >
> >> > "Anthony" wrote:
> >> >
> >> >> Chris,
> >> >> to answer your first question, you can set the registry key remotely:
> >> >> http://technet2.microsoft.com/windowsserver/en/library/92c46246-7cb7-441e-92d6-2b6671c2980e1033.mspx?mfr=true
> >> >> Anthony, http://www.airdesk.co.uk
> >> >>
> >> >> "Chris Martin" <ChrisMar***@discussions.microsoft.com> wrote in
> >> >> message
> >> >> news:815B7E62-DC93-4972-978A-6191C5AC4C54@microsoft.com...
> >> >> > Yes, they are configured only with the address of our AD DNS
> >> >> > servers.
> >> >> >
> >> >> > I have run netdiag and everything passes.
> >> >> >
> >> >> > i have checked DNS and it has all the SRV records in the right
> >> >> > places.
> >> >> > There
> >> >> > are GCs available for use and which are accessable. There are no
> >> >> > restrictions
> >> >> > on the VPN, no port blocking or anything.
> >> >> >
> >> >> > Any further diagnostics anyone can think of?
> >> >> >
> >> >> > --
> >> >> > Chris Martin
> >> >> > SysAdmin
> >> >> > Medfin
> >> >> >
> >> >> >
> >> >> > "Anthony" wrote:
> >> >> >
> >> >> >> Chris,
> >> >> >> Are the clients using only your internal DNS servers as their
> >> >> >> Preferred
> >> >> >> and
> >> >> >> Alternate DNS Server address?
> >> >> >> Anthony, http://www.airdesk.com
> >> >> >>
> >> >> >> "Chris Martin" <ChrisMar***@discussions.microsoft.com> wrote in
> >> >> >> message
> >> >> >> news:2AFDEDA1-52B6-437A-B7D3-4089B7E55C9F@microsoft.com...
> >> >> >> > We have a situation where group policies are not applying on XP
> >> >> >> > desktops
> >> >> >> > and
> >> >> >> > laptops at a remote site, which links back to the head office via
> >> >> >> > a
> >> >> >> > VPN
> >> >> >> > tunnel (which is working fine). Authentication is working, so
> >> >> >> > it's
> >> >> >> > probably
> >> >> >> > not an issue with the VPN. There are no ports blocked over the
> >> >> >> > VPN.
> >> >> >> >
> >> >> >> > The site is defined in AD Sites and services and the IP range
> >> >> >> > exists
> >> >> >> > in
> >> >> >> > ADS&S, too, and is set as the site range. Reverse DNS zones have
> >> >> >> > been
> >> >> >> > created
> >> >> >> > in DNS (as AD replicated zones) and the DNS hives have been
> >> >> >> > auto-generated.
> >> >> >> > There is no reason I can see that machines shouldn't be able to
> >> >> >> > determine
> >> >> >> > what AD DCs service their site however the machines are all
> >> >> >> > recording
> >> >> >> > Event
> >> >> >> > ID: 1054 and not applying GPOs.
> >> >> >> >
> >> >> >> > There are no connectivity issues, other than the latency
> >> >> >> > involved,
> >> >> >> > but
> >> >> >> > there
> >> >> >> > are only two users at the site, so that shouldn't be an issue.
> >> >> >> >
> >> >> >> > I read in the following article that there is slow link detection
> >> >> >> > (http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/distrib/dsec_pol_chzb.mspx?mfr=true).
> >> >> >> > To adjust this, do I have to change it on the domain controller
> >> >> >> > or
> >> >> >> > the
> >> >> >> > desktop/laptop? If it must be set on the desktop/laptop, how can
> >> >> >> > we
> >> >> >> > fix
> >> >> >> > it
> >> >> >> > as
> >> >> >> > it's set in a GPO (sort of a chicken in the egg thing: it can't
> >> >> >> > be
> >> >> >> > set
> >> >> >> > before
> >> >> >> > it's set, as GPOs are already not applying)? If the group
> >> >> >> > policies
> >> >> >> > aren't
> >> >> >> > applying for this reason, is this the error we'd expect? I would
> >> >> >> > have
> >> >> >> > thought
> >> >> >> > that a slow link would have generated a different error to this
> >> >> >> > as
> >> >> >> > this
> >> >> >> > error
> >> >> >> > suggests that the PC can't determine what site it is in, rather
> >> >> >> > than
> >> >> >> > than
> >> >> >> > a
> >> >> >> > slow link causing it to fail. If it is a slow link issue, maybe
> >> >> >> > the
> >> >> >> > error
> >> >> >> > message should be amended to make it a little more useful for
> >> >> >> > diagnostics.
> >> >> >> >
> >> >> >> > If it's not at all related to slow link detection then, what
> >> >> >> > could
> >> >> >> > it
> >> >> >> > be?
> >> >> >> > Given that authentication and DNS seem to beem working 100%, what
> >> >> >> > could
> >> >> >> > be
> >> >> >> > causing this and what's my next step in diagnosing the issue?
> >> >> >> >
> >> >> >> > Thanks!
> >> >> >> >
> >> >> >> > --
> >> >> >> > Chris Martin
> >> >> >> > SysAdmin
> >> >> >> > Medfin
> >> >> >>
> >> >> >>
> >> >> >>
> >> >>
> >> >>
> >> >>
> >>
> >>
> >>
>
>
>