[Webinar] Streamline your web hosting managementRegister Today

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 269
  • Last Modified:

Default Logon Script

I have a user base of around 800 people.  We are trying to set a default logon script in Active Directory (logon.bat) to each user.  Is there a way to do this without setting it up in -each- user account?  Like is there a way to associate it with the 'Everyone' group?  Or is there a way to change multiple users info at one time?
0
DennisS
Asked:
DennisS
  • 4
  • 3
1 Solution
 
MSGeekCommented:
Yes under Group Policy, you may set a login script.  You may want to create a container to apply the policy to and put the users in it, as you may not want to implement this at the domain level for it will affect all users including the admins.
0
 
oBdACommented:
For the default script, there is no "association" possible.
In NT4, you could mark several users in the User Manager's GUI and set new properties, but unfortunately, they took that out in W2k. It's probably more a bug than a feature; as far as I know, MS is finally planning to reintroduce this.
Until that gets realized, you should have a look at ldifde.exe; you should find it on your server. With that, you can script changes to multiple users.
0
 
MSGeekCommented:
oBdA.. Why do that when he can just add it to the group policy?

It's right under User Configuration - Windows Settings - Logon Script.  You just specify you script with a UNC path to a share the users have read rights to and your done.
0
[Webinar] Kill tickets & tabs using PowerShell

Are you tired of cycling through the same browser tabs everyday to close the same repetitive tickets? In this webinar JumpCloud will show how you can leverage RESTful APIs to build your own PowerShell modules to kill tickets & tabs using the PowerShell command Invoke-RestMethod.

 
kosukiCommented:
Did you try to put the logon.bat file in the Netlogon Directory, so whenever the user logon to the server the batch file will be executed in the client computer.

Try it and see whether it help!
0
 
oBdACommented:
Hi MSGeek,
why use Group Policies when he can just write a few lines of script? ;)

I have two reasons for recommending ldifde.exe:

* If you specify logon scripts using Group Policies, you have your user configuration at two different places. In my opinion, this complicates matters unnecessarily, especially if someone else should need to manage the users; so using Group Policies to change the logon script may be the easiest way, but in the long run, you benefit from doing it properly ("properly" defined by "my humble opinion", of course).

* Until Microsoft indeed (re)releases the function I mentioned above, ldifde.exe is the only possibility to change the properties of a whole bunch of users at once - so why not start getting used to it with something that's comparitively easy?
0
 
MSGeekCommented:
oBdA.. I understand what you are saying and you make good sense.  Group Policies are container based.  You only need to change one setting to have it propogate to all objects within the container to which the policy applies.

MS has made a major shift by implementing polices in tis fashion and establishing an inheritance scheme for policies similar to NTFS rights.  Policies are designed to be assigned to group objects and organizational units.  Just like NTFS rights, you should never assign rights or policies to one individual, you assign them to a group.

I still use scripts quite a bit, but in this situation utilizing Group Policies IMHO is the way to go.  Sounds like you might want to play with them a bit, I would encourage it.  I laid out policies for a 3500 user school district with three primary groups, Technicians, Adults and Students.  Then of course we had a group called No Internet Access for those students who found it difficult to behave.  :)
0
 
oBdACommented:
Hi MSGeek,
I'm quite familiar with Group Policies, I've been playing around with them since they were called System Policies, and I surely appreciate them.
But as I see it, in most cases there is no real need to use GPs to apply logon scripts.
Either you have the same logon script for all of your users - then you can as well specify it in user properties instead of wasting a perfectly good GPO on it.
Or you have a set of different logon scripts - and that's all the more reason to specify them in user properties. It's just more concise than creating a whole number of GPOs and applying the according security rights. Especially, as I mentioned before, if someone unfamiliar with your setup just wants to find out which logon script a certain user is running.
As I said: In my opinion, the logon script is a (vital) part of the user properties, not something to be hidden in a GPO; but, hey, maybe I'm just old-fashioned.
0
 
MSGeekCommented:
I understand, I just conceptualize Group Policies the same way I did with NT 4 rights.  Users into local groups and local groups into global groups.  If I assign anything on a user by user basis it requires documentation.   The only thing I don't like about policies is figuring out inheritance walking into a network new to me.  Thanks for sharing your perspective.
0

Featured Post

Upgrade your Question Security!

Your question, your audience. Choose who sees your identity—and your question—with question security.

  • 4
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now