«

OK, Here's a REAL case study for my fellow MCSE's and soon-to-be's. It's
long, so skip if you're not interested. I don't think you'll find this one
on any tests, but it's real and sure had me scratching my head for a good
hour. The names have been changed to protect the innocent.



I set up a single W2K3 DC in a one-domain new forest for a small medical
office. Pre-joined 4 XP clients and connected in a training room so their
software vendor could do training prior to the rollout. Created user
accounts, placed in an OU - "Staff". 2 GPOs linked to the OU, one runs a
logon script (nothing fancy, just maps drives and printers). The other
re-directs My Documents to the server for central backup. Server is
multi-homed, one connected to the LAN and the other to a wireless AP for 2
mobile tablet PCs. Their primary software vendor specified Terminal Services
for the wireless on a separate subnet, no routing, so all protocols except
TCP/IP are disabled on that interface. Everything fires up, workstations
join without problem, group policy is applied correctly, training goes off
without a hitch, mobile tablets connect with an RDP session - all is well,
life is good.



Then comes deployment in the office. I am asked to set it up so that users
can have the same application settings at any workstation (but not roaming
profiles). After a little research, I decided to use a GPO to redirect
"Application Settings" to the same directory as "My Documents" (Since it's
already being backed up). When I attempt to access the GPO cache for the OU,
I get the message:



Windows cannot access the file gpt.ini for GPO
CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=thisdomai
n,DC=local. The file must be present at the location
<\\thisdomain.local\sysvol\thisdomain.local\Polici es\{31B2F340-016D-11D2-945
F-00C04FB984F9}\gpt.ini>. (Configuration information could not be read from
the domain controller, either because the machine is unavailable, or access
has been denied. ). Group Policy processing aborted.



The event ID is 1058.



Just to get you started, there are no SMB signing conflicts and the
"everyone" group has read and execute permissions to the root.



Give it your best shot, I'll post hints as required and tell you when you're
getting warmer!

yada, yada, yada "Kurt" <> said...yada, yada, yada in
news::

> OK, Here's a REAL case study for my fellow MCSE's and soon-to-be's.

the answer is D...

--
Neil MCNGP #30
the "curious" hair on the soap of society

I dunno,

would it be related to this?

http://support.microsoft.com/default...3B314494&sd=ee

--
kpg A+ MCP MCNGP 0x22
We have enough youth, how about a fountain of smart?

No. In fact it passes the acid test in some other articles (connect to
\\server\sysvol).

"kpg" <> wrote in message
news:...
> I dunno,
>
> would it be related to this?
>
> http://support.microsoft.com/default...3B314494&sd=ee
>
> --
> kpg A+ MCP MCNGP 0x22
> We have enough youth, how about a fountain of smart?
>

The clue is in the error message, which refers to \\thisdomain.local\sysvol,
rather than \\server\sysvol. If you ping server, it resolves to the wired
network with a full suite of protocols, services, clients. However, for
whatever reason, when you ping (or nslookup) thisdomain, it resolves to the
other (wireless) network. Since group policy is read from a share, and since
everything but TCP/IP was disabled (like file and print sharing), the server
could not read from it's own share. After enabling file and print sharing on
the other interface, everything was hunky-dory. There was never a problem
reading the policies from a wired client because windows DNS always resolves
to the same subnet as the request came from. But the server itself would
resolve to either of it's IP addresses. There's probably a way to force
resolution to one interface. I'll have to research it.

....kurt

"Kurt" <> wrote in message
news:...
> OK, Here's a REAL case study for my fellow MCSE's and soon-to-be's. It's
> long, so skip if you're not interested. I don't think you'll find this one
> on any tests, but it's real and sure had me scratching my head for a good
> hour. The names have been changed to protect the innocent.
>
>
>
> I set up a single W2K3 DC in a one-domain new forest for a small medical
> office. Pre-joined 4 XP clients and connected in a training room so their
> software vendor could do training prior to the rollout. Created user
> accounts, placed in an OU - "Staff". 2 GPOs linked to the OU, one runs a
> logon script (nothing fancy, just maps drives and printers). The other
> re-directs My Documents to the server for central backup. Server is
> multi-homed, one connected to the LAN and the other to a wireless AP for 2
> mobile tablet PCs. Their primary software vendor specified Terminal
Services
> for the wireless on a separate subnet, no routing, so all protocols except
> TCP/IP are disabled on that interface. Everything fires up, workstations
> join without problem, group policy is applied correctly, training goes off
> without a hitch, mobile tablets connect with an RDP session - all is well,
> life is good.
>
>
>
> Then comes deployment in the office. I am asked to set it up so that users
> can have the same application settings at any workstation (but not roaming
> profiles). After a little research, I decided to use a GPO to redirect
> "Application Settings" to the same directory as "My Documents" (Since it's
> already being backed up). When I attempt to access the GPO cache for the
OU,
> I get the message:
>
>
>
> Windows cannot access the file gpt.ini for GPO
>
CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=thisdomai
> n,DC=local. The file must be present at the location
>
<\\thisdomain.local\sysvol\thisdomain.local\Polici es\{31B2F340-016D-11D2-945
> F-00C04FB984F9}\gpt.ini>. (Configuration information could not be read
from
> the domain controller, either because the machine is unavailable, or
access
> has been denied. ). Group Policy processing aborted.
>
>
>
> The event ID is 1058.
>
>
>
> Just to get you started, there are no SMB signing conflicts and the
> "everyone" group has read and execute permissions to the root.
>
>
>
> Give it your best shot, I'll post hints as required and tell you when
you're
> getting warmer!
>
>

"Kurt" <> wrote in
news::

> OK, Here's a REAL case study for my fellow MCSE's and
> soon-to-be's. It's long, so skip if you're not interested. I don't
> think you'll find this one on any tests, but it's real and sure
> had me scratching my head for a good hour. The names have been
> changed to protect the innocent.
>
>
>
> I set up a single W2K3 DC in a one-domain new forest for a small
> medical office. Pre-joined 4 XP clients and connected in a
> training room so their software vendor could do training prior to
> the rollout. Created user accounts, placed in an OU - "Staff". 2
> GPOs linked to the OU, one runs a logon script (nothing fancy,
> just maps drives and printers). The other re-directs My Documents
> to the server for central backup. Server is multi-homed, one
> connected to the LAN and the other to a wireless AP for 2 mobile
> tablet PCs. Their primary software vendor specified Terminal
> Services for the wireless on a separate subnet, no routing, so all
> protocols except TCP/IP are disabled on that interface. Everything
> fires up, workstations join without problem, group policy is
> applied correctly, training goes off without a hitch, mobile
> tablets connect with an RDP session - all is well, life is good.
>
>
>
> Then comes deployment in the office. I am asked to set it up so
> that users can have the same application settings at any
> workstation (but not roaming profiles). After a little research, I
> decided to use a GPO to redirect "Application Settings" to the
> same directory as "My Documents" (Since it's already being backed
> up). When I attempt to access the GPO cache for the OU, I get the
> message:
>
>
>
> Windows cannot access the file gpt.ini for GPO
> CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=
> thisdomai n,DC=local. The file must be present at the location
> <\\thisdomain.local\sysvol\thisdomain.local\Polici es\{31B2F340-016D
> -11D2-945 F-00C04FB984F9}\gpt.ini>. (Configuration information
> could not be read from the domain controller, either because the
> machine is unavailable, or access has been denied. ). Group Policy
> processing aborted.
>
>
>
> The event ID is 1058.
>
>
>
> Just to get you started, there are no SMB signing conflicts and
> the "everyone" group has read and execute permissions to the root.
>
>
>
> Give it your best shot, I'll post hints as required and tell you
> when you're getting warmer!

DFSUtil:

http://support.microsoft.com/default...;en-us;q830676

> No.

Well in that case I'll have to agree with Neil.

The answer is D.

Unless Laura disagrees, then I'll go with whatever she says.

--
kpg A+ MCP MCNGP 0x22
Dopeler effect: The tendency of stupid ideas to seem smarter when they come
at you rapidly.

incase you missed it "kpg" <> said in
news::

>> No.
>
> Well in that case I'll have to agree with Neil.
>
> The answer is D.
>
> Unless Laura disagrees, then I'll go with whatever she says.
>

I'll try this first
http://support.microsoft.com/default...;en-us;Q842804

--
Neil MCNGP #30
the "curious" hair on the soap of society

Neil wrote:
> incase you missed it "kpg" <> said in
> news::
>
>>> No.
>>
>> Well in that case I'll have to agree with Neil.
>>
>> The answer is D.
>>
>> Unless Laura disagrees, then I'll go with whatever she says.
>>
>
> I'll try this first
> http://support.microsoft.com/default...;en-us;Q842804

Congrats... (#6187)

I did all that, still wasn't the problem. Actually the answer is "Z".

"Frisbee®" <> wrote in message
news:%...
> Neil wrote:
> > incase you missed it "kpg" <> said in
> > news::
> >
> >>> No.
> >>
> >> Well in that case I'll have to agree with Neil.
> >>
> >> The answer is D.
> >>
> >> Unless Laura disagrees, then I'll go with whatever she says.
> >>
> >
> > I'll try this first
> > http://support.microsoft.com/default...;en-us;Q842804
>
> Congrats... (#6187)
>