Problem with logon scripts... W2K SP4 Clients - Microsoft Please Help.

[Harry Bates]

We are holding back on deploying SP4 on any of our client W2K Pro
workstations because logon scripts do not run after install. Details below:

User Accounts domain is trusted by workstation\server resource domain. Lets
call them ACCT and RES for domain names. All domain controllers from both
domains are W2K Server with either SP2 or SP3. Workstations work fine with
SP3. The domains are native. As soon as they are upgraded to SP4 or if a
clean build is done with SP4 integrated, they do not get logon scripts. I
can go out to the SYSVOL share on the ACCT domain controller and run the
logon successfully on all SPs even SP4. This also falls true for all of our
Win 2003 Servers. BUT, when we log into the RES domain with a RES account,
the logon script that is set for that user in RES does run successfully. It
is just when we log into the ACCT domain that the scripts do not run. Like I
said, this also is the same for W2K3 Server both console and terminal
logons. To fill in a couple of other blanks, since we have a world wide
extremely large ACCT domain, our logon script paths include a sub folder.

It look like this in AD U&C:

MTN\USER.BAT

During my test to see if it was a trust problem, I did include a subfolder
within the path when I tested a RES to RES login, and it was successful. I
believe this is a trust type of problem with the new SP and W2K3 Server.
Jerry Schulman is working with me at the time and I would like to see if any
other people are experiencing the same problem or have any sound input. Like
I said, we cannot deploy W2K3 Server or W2KSP4 until this is resolved.

Thank you for any valid responses.

-Harry Bates
Lockheed-Martin

 

[Dmitry Korolyov]

Well, the event is quite self-explanatory.

I assume that the user account in one domain is logging on a computer which
is in different domain. I also assume that either of the domains (or both)
is NT4 domain.

Then my guess is the following: after SP4 installation, group policy
subsystem treats trusts with NT4 domain in the same way as cross-forest
trusts between Windows 2003 mode forests. In this case, you might want to
look at the group policy settings (at the machine with SP4 applied) related
to cross-forest profile and group policy processing, and enable them. This
may work.

 

[Harry Bates]

Got it!

After seeing the event:

Event Type: Information
Event Source: Userenv
Event Category: None
Event ID: 1000
Date: 6/30/2003
Time: 3:38:50 PM
User: NT AUTHORITY\SYSTEM
Computer: MTN-H2
Description:
The logged on user's forest is different from the machine's forest. Cross
Forest Group Policy processing is disabled and loopback processing has been
enforced in this forest for this user account.


I migrated around local group policy with GPedit.msc to:

Computer Configuration\Administrative Templates\System\Group Policy

and noticed a new entry:

"Allow Cross-Forest User Policy and Roaming Profiles"

Once I enabled this on the workstations they got the logon script. MS should
look into this one.

-Harry Bates

 

[Dmitry Korolyov]

OK, so my guess was correct, happy to get it working.

 

[Harry Bates]

Well, the event is quite self-explanatory.

No NT4 domains as stated earlier. All domain controllers are W2K SP3 or SP2
and running native AD. I stated the fix in the last post I wrote. It should
propagate soon. Thanks for your help. BTW, you were right about the GP on
the client side. MS should look into this.

-Harry Bates

 

[Dmitry Korolyov]

Then, the user's and computer's domains belong to different forests? If yes,
the behavior you were fighting might be an undocumented feature property. If
they belong to the same forest, then it is a definite BUG.

 

[Harry Bates]

Different forest, but they failed to mention an added layer of security. I
don't believe it is a bug, they just should document the change somewhere.
This setting does not exist on pre SP4 boxes at all.

-Harry Bates
Lockheed-Martin