Moving User from OU=A to OU=B still runs OU=A logon script intermit.

  • Thread starter Thread starter Graham Prentice
  • Start date Start date
G

Graham Prentice

We have a program that will place the user into a OU upon logon depending
upon type of w/s.
We have a logon script that adds default printer based on the OU.

If the user gets placed into a different OU, sometimes (3rd of the time)
the old OU logon script gets run and the user will get the wrong printer.

Have even tried a logoff script - but the next logon script is sometimes the
wrong one.

Win2k3 TS, WinXPe clients running RDP.

Any ideas?
Graham
 
Troubleshot this problem and found out a few things.

We have two domain controllers.

When the problem happens, it was always supplying the GPO from our 2nd DC.
(according to gpresult)

I powered down the second DC, and the GPO problem disappeared.

There must be some sort of sync issue between the DC's.

Graham
 
We have a program that will place the user into a OU upon logon
depending upon type of w/s.
Click to expand...

Why would you do this? It makes far more sense to enable Group Policy
Loopback mode on the Group Policy Comp Config of the Computers OU and
then set the User Policies on the User Section of the Computer Group
Policy. The Loopback mode will make it apply to any user logging onto
that specific machine no matter what OU the user resides in.

The problem is replication is 5 minutes between DC’s for
"non-important" changes like moving users around in OU’s. Only
password and account changes are replicated instantly.

Also, you can set printers up via machine instead of user if you want.
I use a batch file as a startup script and it creates my printers per
machine.

rundll32 printui.dll,PrintUIEntry /in /q /n "\\server\Printer
Name"

Cheers,

Lara
 
Lara,

We do use loopback mode for the primary GPO. (This one provides the locked
down TS environment)

We have another GPO farther down the tree who's sole purpose is to add a
printer via a logon script - depending upon which OU the user happens to be
in. If the user travels to another location, the s/w will change the user's
OU and group membership depending on the NETBIOS name of the thin client.

The users are log into a cluster (NLB - Session Directory) of three terminal
servers from thin clients.

These three TS's have users spanning 6 remote locations.

The thin clients all use the same image (deployment image) to connect to the
TS's.
The only difference is their NETBIOS name.

The thin clients are also not part of the domain so there aren't any
computer objects for OUs.

We could install a network printer as the default prt on each thin client,
but that would require many different images when deploying new machines.

I think our answer is to remove the second DC because the network is small
and we do frequent backups.
The present config works perfectly with DC#2 turned off.

(3 terminal servers, DC, Data server - may be overkill for 2 DCs)

Thanks and regards,

Graham
 
Graham Prentice2 said:
Lara,

We do use loopback mode for the primary GPO. (This one
provides the locked
down TS environment)

We have another GPO farther down the tree who's sole purpose
is to add a
printer via a logon script - depending upon which OU the user
happens to be
in. If the user travels to another location, the s/w will
change the user's
OU and group membership depending on the NETBIOS name of the
thin client.

The users are log into a cluster (NLB - Session Directory) of
three terminal
servers from thin clients.

These three TS's have users spanning 6 remote locations.

The thin clients all use the same image (deployment image) to
connect to the
TS's.
The only difference is their NETBIOS name.

The thin clients are also not part of the domain so there
aren't any
computer objects for OUs.

We could install a network printer as the default prt on each
thin client,
but that would require many different images when deploying
new machines.

I think our answer is to remove the second DC because the
network is small
and we do frequent backups.
The present config works perfectly with DC#2 turned off.

(3 terminal servers, DC, Data server - may be overkill for 2
DCs)

Thanks and regards,

Graham

 > >We have a program that will place the user into a OU
upon logon
 >>depending upon type of w/s.
Click to expand...

Hi,

Sorry, I don’t use terminal services and have never used them except
for Remote Desktop management so I can’t be of more help.

Cheers,

Lara
 
Lara,

What is strange is that our gpresult mentions that the user is in the proper
OU at the time - however runs the wrong GPO - it runs the GPO from the
previous OU that the user was at before.

Sometimes more than 5 minutes has past since the user changed OUs. Perhaps
we still have a syncing problem with our DCs.
Is there a setting to adjust the syncing to a faster time than 5 mins?

There was a few errors in the logs about the size of groups we used.
Event ID:1955
Active Directory encountered a write conflict when applying replicated
changes to the following object.

A write conflict can be caused by simultaneous changes to the same object or
simultaneous changes to other objects that have attributes referencing this
object. This commonly occurs when the object represents a large group with
many members, and the functional level of the forest is set to Windows 2000.
This conflict triggered additional retries of the update. If the system
appears slow, it could be because replication of these changes is occurring.


User Action

Use smaller groups for this operation or raise the functional level to
Windows Server 2003.

Graham
 
Back
Top