|
|
|||||||
Hi all, I am having some trouble with the script below and need some help. Sometimes it works fine and sometimes it doesn't. It has something to do with the /f switch or with something in GPO. I don't use GPO for login scripts but what is happening is sometimes the INGROUP commands will not function when the user logs on. Locally on the PC I have ran the kix32.exe /f \\10.10.22.11\netlogon new.kix (syntax might be wrong) successfully and then boom, the drive mappings show up, then I go to another pc, login as the same user and get no mappings. I tried adding the /f to the login script but apparently it only works if ran locally. Any suggestions as to why the script works sometimes but not others.. Thanks guys, Greg This is my batch file... Code: : @echo off cls :START echo. echo Logging on to IMO.INT - echo ### Removing Existing Mappings ### net use g: /delete net use p: /delete net use r: /delete net use h: /delete echo ### Installing Printers ### rundll32 printui.dll,PrintUIEntry /in /q /n \\newfs01\bwcanon rundll32 printui.dll,PrintUIEntry /in /q /n \\newfs01\colorcanon If Not Exist %Windir%\Kix32.exe Goto InstallKix If Not Exist %Windir%\UpgradeKix.Chk Goto Onsite Attrib -R %Windir%\Kix32.exe Del "%Windir%\UpgradeKix.Chk" :InstallKix Echo. Echo Updating the logon script processor. Please wait.. copy %logonserver%\netlogon\kix\*.* %windir%\*.* >nul :Onsite %windir%\kix32.exe %logonserver%\netlogon\new.kix goto exit :EXIT Exit My Kix script Code: ;******************************************* ;Show welcome splash ;******************************************* CLS $section=1 ;Section 1 Color w+/n Box (9,29,15,46,single) Color w+/n AT (10,30) "Welcome to the," AT (12,30) @domain AT (12,39) "domain" AT (14,30) @fullname SLEEP 1 CLS Color g+/n ? "Today is " + @DAY + ", " + @MONTH + " " + @MDAYNO + ", " @YEAR + "." ? "Processing login, please wait..." :DRIVEMAP ;********** ;Begin Group-Based Mappings IF INGROUP("NEWGROUPS") USE P: /DELETE USE P: "\\NEWFS01\GROUPS" USE H: /DELETE USE H: "\\NEWFS01\USERS\%USERNAME%" ENDIF ;********** IF INGROUP("NEWBARRYROSS") USE R: /DELETE USE R: "\\NEWFS01\npd" ENDIF ;********** |
||||||||
|
|
|||||||
I don't see anything obvious (yet), but I suggest getting rid of most of the batch... and for the most part it's not necessary to copy kix32.exe to the local machine. In your batch just fire off kix and the script kix32.exe logon.kix and in your kix... |
||||||||
|
|
|||||||
A common user cannot and should not be able to copy something to %windir% during the legacy logon script. The NTFS security for %windir% for "Users" is per default set to "Read & Execute". Verify if the kix32.exe exists in %windir%. Just copy your kix32.exe and/or wkix32.exe to \\domain.ext\sysvol\domain.ext\scripts\ or \\domain.ext\netlogon\ and use it from there If you really want to copy kix32.exe or wkix32.exe to the %windir%, I think you should use a GPO Computer Startup Script. |
||||||||
|
|
|||||||
See also the "XP Fast Logon Optimization" FAQ at http://www.kixtart.org/forums/ubbthreads.php?ubb=showflat&Number=112428 |
||||||||
|
|
|||||||
I agree with Witto here, all logon stuff should be run from the netlogon share. If you really feel the need to run it from the local %windir% consider deploying the kix executables. Btw Witto: \\domain.ext\sysvol\domain.ext\scripts\ And \\domain.ext\netlogon\ are one and the same |
||||||||
|
|
|||||||
Originally Posted By: apronk Btw Witto: \\domain.ext\sysvol\domain.ext\scripts\ And \\domain.ext\netlogon\ are one and the same I know Thanks for telling anyway |
||||||||
|
|
|||||||
well, not really the same. both might point to same folder, but doesn't make them the same. |
||||||||
|
|
|||||||
same folder, same security = same |
||||||||
|
|
|||||||
different share still... |
||||||||
|
|
|||||||
subshare of the same share |
||||||||
|
|
|||||||
I agree with apronk - but yes, it is a different share, but pointing to the same source |
||||||||
|
|
|||||||
I am more interested to know if gaprofitt his problem was caused to the fact that a user has no rights to write to his %windir% |
||||||||
|
|
|||||||
Domain users per definition do not have local admin rights. This can be resolved by polies adding the Domain Users group to the local Power Users or Administrators group. |
||||||||
|
|
|||||||
Could be done, but shouldn't be done. The Share could have different permissions than the folder permissions so yes it's different. |
||||||||
|
|
|||||||
Originally Posted By: NTDOC Could be done, but shouldn't be done. The Share could have different permissions than the folder permissions so yes it's different. Should be done, domain users should be local admins. Further restrictions can be set. and If you have a proper RIS image who cares wether they crash the workstation :P |
||||||||
|
|
|||||||
Because as an Admin that gives them quite a leg up on escalating their privs on the Domain as well. It is a Best Practice with Microsoft and all Large Enterprise Networks to not have a user with any higher privs than needed any where on your system. That also makes it much easier for a remote hack into your network where they could easily gain the same rights as the user and as said above gives them a foot step into your network to work further. |
||||||||
|
|
|||||||
IMHO domain users should not be local admins. A user should have the possibility to do all he needs on his computer. But installing, registering and other of these tasks should be left to domain admins. It will keep computers longer usuable. As domain admin, it will give you an easier job because computers do not get messed up that fast. |
||||||||
|
|
|||||||
It's never fun when users can install whatever they want if you don't have cd-roms locked down or Internet content filtering blocking executables. Who knows what you'll get on your PCs. It's very unfortunate some software companies to not gear their applications toward this and you have to deal with users having elevated priviledges sometimes. |