GP: Login Scripts, not working on all workstations

Archived from groups: microsoft.public.win2000.group_policy (More info?)

I have created a login script that runs some updates to some software on the
150 workstations on my LAN.

The problem I'm running into is that several of my workstations are not
running the logon script.

I placed the logon script in the

\\mydomain.com\sysvol\bpc-financial.com\Policies\{31B2F340-016D-11D2-945F-00
C04FB984F9}\USER\Scripts\Logon

I have added the logon script to scripts list under the Default Domain
Policy:
User Configuration | Windows Settings | Scripts | Logon list.

Most of my workstations are running the script with no problem.

I will say this, when we setup several of these workstations, we created a
master workstation and ghosted the hard drive image to the new systems.

The new systems were disjoined from the domain, renamed, and rejoined the
domain once they were deployed.

I haven't found any way to really test this or test to see if a script has
run on a workstation other than to go to the workstation and see what
version of the software is on the actual PC.

Does anyone have any suggestions?
2 answers Last reply
More about login scripts working workstations
  1. Archived from groups: microsoft.public.win2000.group_policy (More info?)

    Ok, I've found that if I remove the workstation from the domain and then
    rejoin it, it seems to help with this issue. I'm not sure what would cause
    this, but I've found a fast way to disjoin and rejoin the domain using the
    netdom utility:

    netdom join targetworkstationname /Domain:mydomain\domaincontroler
    /Userd:mydomain\administrator /Passwordd:* /UserO:administrator /PasswordO:*
    netdom remove targetworkstationname /Domain:mydomain\domaincontroler
    /Userd:mydomain\administrator /Passwordd:* /UserO:administrator /PasswordO:*

    My question now is:
    Does anyone have any idea how this could have happened?

    What can corrupt the workstation's relationship with the domain?

    And what exactly does this disjoing/rejoin reset, because I didn't delete
    the workstation account from the AD?


    "Casey Chambliss" <nospam@bpc-financial.com> wrote in message
    news:n%OUc.3108$k21.1071@news02.roc.ny...
    > I have created a login script that runs some updates to some software on
    the
    > 150 workstations on my LAN.
    >
    > The problem I'm running into is that several of my workstations are not
    > running the logon script.
    >
    > I placed the logon script in the
    >
    >
    \\mydomain.com\sysvol\bpc-financial.com\Policies\{31B2F340-016D-11D2-945F-00
    > C04FB984F9}\USER\Scripts\Logon
    >
    > I have added the logon script to scripts list under the Default Domain
    > Policy:
    > User Configuration | Windows Settings | Scripts | Logon list.
    >
    > Most of my workstations are running the script with no problem.
    >
    > I will say this, when we setup several of these workstations, we created a
    > master workstation and ghosted the hard drive image to the new systems.
    >
    > The new systems were disjoined from the domain, renamed, and rejoined the
    > domain once they were deployed.
    >
    > I haven't found any way to really test this or test to see if a script has
    > run on a workstation other than to go to the workstation and see what
    > version of the software is on the actual PC.
    >
    > Does anyone have any suggestions?
    >
    >
  2. Archived from groups: microsoft.public.win2000.group_policy (More info?)

    We have had a similar problem.
    I'm not sure if it may have been related to the machine's SID.

    We have now been using either sysprep or ghost walker (ghstwalk.exe) to not
    only rename the machine but change the SID.

    We also had issues with collisions in AD where there would be an additional
    machine name with a GUID appended.

    Bruce

    "Casey Chambliss" <nospam@bpc-financial.com> wrote in message
    news:1hoVc.3291$gj2.421@news02.roc.ny...
    > Ok, I've found that if I remove the workstation from the domain and then
    > rejoin it, it seems to help with this issue. I'm not sure what would cause
    > this, but I've found a fast way to disjoin and rejoin the domain using the
    > netdom utility:
    >
    > netdom join targetworkstationname /Domain:mydomain\domaincontroler
    > /Userd:mydomain\administrator /Passwordd:* /UserO:administrator
    /PasswordO:*
    > netdom remove targetworkstationname /Domain:mydomain\domaincontroler
    > /Userd:mydomain\administrator /Passwordd:* /UserO:administrator
    /PasswordO:*
    >
    > My question now is:
    > Does anyone have any idea how this could have happened?
    >
    > What can corrupt the workstation's relationship with the domain?
    >
    > And what exactly does this disjoing/rejoin reset, because I didn't delete
    > the workstation account from the AD?
    >
    >
    >
    > "Casey Chambliss" <nospam@bpc-financial.com> wrote in message
    > news:n%OUc.3108$k21.1071@news02.roc.ny...
    > > I have created a login script that runs some updates to some software on
    > the
    > > 150 workstations on my LAN.
    > >
    > > The problem I'm running into is that several of my workstations are not
    > > running the logon script.
    > >
    > > I placed the logon script in the
    > >
    > >
    >
    \\mydomain.com\sysvol\bpc-financial.com\Policies\{31B2F340-016D-11D2-945F-00
    > > C04FB984F9}\USER\Scripts\Logon
    > >
    > > I have added the logon script to scripts list under the Default Domain
    > > Policy:
    > > User Configuration | Windows Settings | Scripts | Logon list.
    > >
    > > Most of my workstations are running the script with no problem.
    > >
    > > I will say this, when we setup several of these workstations, we created
    a
    > > master workstation and ghosted the hard drive image to the new systems.
    > >
    > > The new systems were disjoined from the domain, renamed, and rejoined
    the
    > > domain once they were deployed.
    > >
    > > I haven't found any way to really test this or test to see if a script
    has
    > > run on a workstation other than to go to the workstation and see what
    > > version of the software is on the actual PC.
    > >
    > > Does anyone have any suggestions?
    > >
    > >
    >
    >
Ask a new question

Read More

Policy Login Workstations Windows