|
|
|||||||
There have been quite a number of questions with regard to GPO and KiX and hopefully, this will help. Please provide any feedback, criticisms, etc. Here goes: You ** MUST ** be a Domain Administrator or better to do this task This assumes that you have Group Policy Management Console. (1) Find the user(s) you want to modify in the OU and remove under Profile, the Login Script, or you can remove this using an AD script: Code:
(2) In Active Directory Users and Computers, go into the OU that you want to modify and open Group Policy Management.. (3) In Group Policy Management, right-click on the OU and Select "Create and link a GPO Here" (4) In the New GPO, provide a Name: Login Script Click OK (5) In the Right Pane, right-click on the newly created GPO and choose edito Note: Scripts can be defined in GPO in one of two locations -
(6) Open the Logon by double-clicking on it. (7) Click the Add.. Button and add the needed files. We will just add in one batch file - NTLOGON.BAT and it contains the following: \\domain.tld\netlogon\WKiX32.exe \\domain.tld\netlogon\script.KiX Note: You can still keep your W/KIX32.EXE in the Netlogon folder.. If you choose to do: \\domain.tld\netlogon\WKiX32.exe \\domain.tld\netlogon\OU\script.KiX Then \\domain.tld\netlogon\OU needs to exist, for example: \\domain.tld\netlogon\Accounting \\domain.tld\netlogon\Marketing \\domain.tld\netlogon\Sales \\domain.tld\netlogon\HR etc. Or, better yet: \\domain.tld\netlogon\CompanyA \\domain.tld\netlogon\CompanyB \\domain.tld\netlogon\CompanyC \\domain.tld\netlogon\CompanyD etc. and this makes it pretty easy to maintain/manage. Also, Enterprise-wide, changes are not as high-profile. The other advantage to this model is that you can have Representatives from IT in each of these areas maintain their own scripts. (8)Click OK and close out of Group Policy and then close out of Group Policy Management Note: You may not see immediate results as replication between your DCs has to occur Thanks, Kent |
||||||||
|
|
|||||||
Quote:That is the single most interesting part, so it definetly should be added Note: a per-machine script (computer configuration - Startup/Shutdown) runs under SYSTEM context (meaning admin privs). Must admit that I've never even tried running KiX via GPO, don't know if it even works |
||||||||
|
|
|||||||
My apologies, I have made some changes Kent |
||||||||
|
|
|||||||
Quote: But not network access unlesss SYSTEM is specifically granted network access, so I remember. |
||||||||
|
|
|||||||
Good job, Kent. Not sure I follow what you are trying to say with the OU path example, {AAAAAAAA-BBBB-CCCC-DDDD-EEEEEEEEEEEE}. In my company, when we came up with an OU design, I designed the NetLogon folder structure to follow that same OU tree structure. We delegate rights to OU_Administrators to both their OU and matching folder in NetLogon and to make it simple, we setup a hidden share on their local DC to the NetLogon subfolder for admin access only. OU_Admins are free to choose whether to deploy legacy logon scripts and/or GPO scripts. I recall from past discussions, that Startup scripts do have limited network access to NetLogon without fiddling with any perms. |
||||||||
|
|
|||||||
Jens/Les - Changes implemented. Sorry, kind of threw this together at the end of the day. Thanks! Kent |
||||||||
|
|
|||||||
Made one minor change with regard to company. Kent |