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
;**********
Edited by Allen (2007-07-2307:25 AM) Edit Reason: added code tags
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
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.
Edited by Witto (2007-07-2312:45 PM) Edit Reason: Added reason why user cannot copy to %windir%
Registered: 2005-01-17
Posts: 1894
Loc: Hilversum, The Netherlands
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
Registered: 2005-01-17
Posts: 1894
Loc: Hilversum, The Netherlands
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.
Registered: 2005-01-17
Posts: 1894
Loc: Hilversum, The Netherlands
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.
Registered: 2007-01-26
Posts: 72
Loc: Green Bay, WI
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.