GPO script running twice

[Guest]

I have a user logon script which records info to a database when users logon, this is set in a GPO on the parent OU. Howver I have noticed that since I have set loopback (in merge mode) in the GPO of a child OU it now logs the details twice (about 15-20 seconds apart) in the database for anyone logging on at the computers in the child OU, as if the script is now being run twice, about 15 seconds apart. The logoff script is doing exactly the same thing. It is only the computers in the child OU which has the GPO applied using loopback that are affected. Logging on at computers under a different child OU there is only 1 record created in the database (thus the logon script is only running once, as it should be!

When using loopback I have always heard mentioned that it 're-applys' GPO settings, but I didnt think this was taken literally and that the script is now 're-applied' a 2nd time (though it certainly looks like this is happening

I'm not sure how to stop this, as I only want it to run the script once at logon. Any ideas

JOhn

 

[Kerry Hoskin]

We had the same problem. We run a logon script at the OU that contains our
users, for mapping drives, printers, etc We have an open access room where
the PC are locked down tight, using Loopback. We used to define our logon
scripts for each user, as we had a number of down-level clients but when we
moved to all w2k clients we defined the logon script via a GPO (so we didn't
have to type logon.bat in every users property page) any user that logged on
to a open access PC (which uses loopback) had the logon script applied
twice. What is happening is that loopback applies the users settings of a
GPO to the computer itself, so the users settings run once for the users and
then gets applied again for the computer, so you get the script running
twice. The way we got around this was to create another OU outside of the
scope of the OU where the GPO defining the login script was, we then put all
of our open access PC's in this OU and every thing worked fine. If you have
any other GPOs that you need to be applied to your PC's you'll need to link
them to the new OU.

Default OU
¦ ¦
¦ OU (GPO with defining logon script held here)
¦ ¦
¦ ¦
¦ Users OU
¦ ¦
¦ ¦
¦ Computers OU
¦ ¦
¦ Open access PC's OU
¦
¦
NEW Open Access PC's OU Created Here

I have a user logon script which records info to a database when users

logon, this is set in a GPO on the parent OU. Howver I have noticed that
since I have set loopback (in merge mode) in the GPO of a child OU it now
logs the details twice (about 15-20 seconds apart) in the database for
anyone logging on at the computers in the child OU, as if the script is now
being run twice, about 15 seconds apart. The logoff script is doing exactly
the same thing. It is only the computers in the child OU which has the GPO
applied using loopback that are affected. Logging on at computers under a
different child OU there is only 1 record created in the database (thus the
logon script is only running once, as it should be!)

When using loopback I have always heard mentioned that it 're-applys' GPO

settings, but I didnt think this was taken literally and that the script is
now 're-applied' a 2nd time (though it certainly looks like this is
happening)

 

[Guest]

Thanks for replying. Been off for a while over xmas so not seen it until today. Its currently the only way I can see of doing it but it wont work for my situation as we are using loopback a lot in different areas, and it would make our AD structure much more complicated. I keep thinking there must be a way to get round this, Ill have to keep looking.

Thanks

John

 

[Kerry Hoskin]

its really annoying and I don't think there is a work around apart from
messing around with your OU structure. Luckily in my situation it wasn't
that much of a problem, just a bit of a hassle

Kerry

Thanks for replying. Been off for a while over xmas so not seen it until

today. Its currently the only way I can see of doing it but it wont work
for my situation as we are using loopback a lot in different areas, and it
would make our AD structure much more complicated. I keep thinking there
must be a way to get round this, Ill have to keep looking.