|
|
|||||||
Advice needed: We work with windows2000 servers on a small domain. When a user logs on, the kix32.exe starts which starts the kixtart.kix script. Normally…… Since a few days it doesn’t work anymore. You can see that the kix32.exe starts but there is no connection to the kixtart.kix script with all off our necessary mappings. If I make a mapping to the Netlogon directory and start the kix32.exe, it does start the kixtart.kix script. It does this on both our domain-controllers How can I make it work for my users again??? (MCA: complete description) [ 18 June 2002, 12:48: Message edited by: MCA ] |
||||||||
|
|
|||||||
Dear, Welcome to the board. First some questions: - which kixtart version running? - what kind of clients you are using? - where are the kixtart files (kix32.exe, kx16.dll, kx32.dll, kx95.dll) installed on your clients? - where are the kixtart scripts located? - how are you calling your scripts? by BATch file? YES, please put BATch file on board. Suggestions:
Possible call MessageBox("KiXtart @kix script starting","KiXtart information") greetings. |
||||||||
|
|
|||||||
Did you change your server configuration recently? This might be a replication problem. Replicate your scripts & kixtart DLLs to all PDC & BDC. |
||||||||
|
|
|||||||
Nenya: Please see the following posts for universal LOGIN.BAT scritps: Kixtart Deployment Kixtart Starter's Guide LOGON.BAT (the overkill version) |
||||||||
|
|
|||||||
My configuration has been changed. So I think there is cause off my problem But I can't find anything they might have changed. so I'm still looking. We run kix 3.63 on a win2000 domain. the users with an Win98 or Win95 PC have the problems. Our login procedure is very simple. We use kix32 ase a login script (set by the profile tab in the sctive directory) and that triggers the kixtart script: ****************************** ;* Definition of variables... * ;****************************** $OLPath = "H:\Mail" ;************************************ ;* Specific Windows 9.x settings... * ;************************************ IF @INWIN = 2 USE H: /DEL USE H: @HOMESHR Run \\Athene\Norman\NVC\BIN\NVC5W32.Exe ENDIF ;**************************** ;* MAPI Profile creation... * ;**************************** IF EXIST ("$OLPath\outlook.prf") = 1 AND @RAS = 0 MD "$OLPath" COPY "@LSERVER\NETLOGON\outlook.prf" "$OLPath\" WRITEPROFILESTRING ("$OLPath\outlook.prf","General","ProfileName","@userid") WRITEPROFILESTRING ("$OLPath\outlook.prf","SERVICE1","DefaultArchiveFile","$OLPath\archief.pst") WRITEPROFILESTRING ("$OLPath\outlook.prf","SERVICE2","MailboxName","@userid") WRITEPROFILESTRING ("$OLPath\outlook.prf","SERVICE4","PathToPersonalAddressBook","$OLPath\@userid.pab") WRITEPROFILESTRING ("$OLPath\outlook.prf","SERVICE5","PathToPersonalFolders","$OLPath\@userid.pst") RUN newprof.exe + " -p $OLPath\outlook.prf" ENDIF ;*********************** ;* Network mappings... * ;*********************** USE G: /DEL USE M: /DEL USE N: /DEL USE O: /DEL USE S: /DEL USE G: "\\ISIS\GroupDirs" USE M: "\\EOS\Adlib" USE N: "\\ISIS\APPS" USE O: "\\ISIS\GROUPDATA" USE S: "\\ISIS\EXACT" ;************************* ;Synchronize the time... * ;************************* SETTIME @LSERVER The dosbox opens and closes again. The usual zeroos do not appear. If I start the script trough the run command, it works. I found a similar problem in the archive but there the script hangs... (kix 95 call febr 2001) Does anyone know how to set my netlogon rights right again? |
||||||||
|
|
|||||||
Forget your script for a moment and go back to square one. Create a really simple login script (pure batch file) containing the following lines: code:Use this as the login script. You should now see the login script window during login and the message on the screen. You might need to implement W2k - Keep the Window visible on login? to see the window. Now, if this works, create a KiXtart file containing the following lines:ECHO The batch file is running code:Also, use a login.bat file like the ones posted here:? 'This is the KiXtart login script' Kixtart Starter's Guide So, do you see the KiXtart login script running? If you got this far, try your custom KiXtart scritp again and pepper the whole script with code:lines to see where exactly your script is failing.? 'Error status : '+@ERROR+' - '@SERROR Aftere you done allthese steps, you can report back on this board and we might be able to help you. Finally, make sure that you have the KXRPC service running on ALL domain controllers. [ 05 June 2002, 15:18: Message edited by: sealeopard ] |
||||||||
|
|
|||||||
The login.bat works, So far So good. But then…. I must say that I’m a complete Kixtart nono. This is what I do: I made a login,bat that has the following command: %\..\kix32 %\..\logon.kix and my logon.kix is a copy of your code. When I logon the the system I get an error. “C:\windows> \..\logon.kix Bad command or file name” Did I do something wrong or is it something else. I can’t find any KXRPC or KIXRPC service running. Can this be the problem? Thanks for your patience. Nenya |
||||||||
|
|
|||||||
Dear, You call should be something like %0\..\kix32 %0\..\logon.kix Also possible \\servername\netlogon\kix32 \\servername\netlogon\logon.kix greetings. |
||||||||
|
|
|||||||
The KXRPC service not running will not prevent you from starting a KiXtart script but you will not be able to use certain Kixtart functions. Therefore, it is recommended to run the KXRPC service on all domain controllers. Also, make sure the following files are in the NETLOGON folder of all domain controllers (maybe even enable directory replication): KIX32.EXE KX16.DLL KX32.DLL KX95.DLL LOGON.BAT LOGON.KIX Then try again. |
||||||||
|
|
|||||||
Found the problem. I got the script working on my Win2000 pc’s but not on the 98 clients. I am missing the KX95.DLL I think/know now that is the course but how can I get that part back on my servers? Nenya |
||||||||
|
|
|||||||
I was to quick with my reply. I just looked on a backup tape of a while ago when the script was still working and I didn’t have the KX95.DLL then either. So it must be something else. The script works when I type \\server\netlogon\kix32.exe \\server\netlogon\login.kix in a Run command (win 2000 and Win98). But when I run the script (with or without using a batch file) it doesn't work on the 98 machines. Are there any ideas left? Nenya |
||||||||
|
|
|||||||
According to the error you report to be returned when loggin in : “C:\windows> \..\logon.kix Bad command or file name” it seems like the OS did not found and interpret the beginning of the line presumably contained in your launching .Bat : " %\..\kix32 %\..\logon.kix" Is this part really in your .Bat ? |
||||||||
|
|
|||||||
I found the course of my problem. It must be something to do with rights on the netlogon directory. The script stopped working the day after patches where loaded by an external system handler. He says that my problem has nothing to do with his actions so he can’t help me. If I logon with all my rights, there is nothing wrong BUT when a normal user logs on, the script doesn’t work. (a dosbox opens but the script doesn’t load) I made a test user with all off my admin and user rights and this user can use the script. After taking away various admin rights, the script can’t be used anymore. Does anyone know which user-rights the sysvol and/or the script directory needs, to be accessible for all users. Nenya |
||||||||
|
|
|||||||
replicator needs full access of course. and finally, normally in the netlogon share is full control over files to everyone. this is offcourse not secure as users may change scripts but if replication is working they will be fixed immediately. cheers, |
||||||||
|
|
|||||||
NETLOGON share is READ-ONLY by default and should definitely be kept this way, both on the file permissions and the share permissions. The Directory Replicator accound requires full access and Domain Administrators should have full access at least to the export directory on the Primary Domain Controller. They do not require full access to NETLOGON since script updates are performed through the export directory. |
||||||||
|
|
|||||||
hey... thanks jens. stupid me. again. the rights on the files are the same as in the source directory. but the share is read-only and that disables the changing from even domain admins. my mistake, jens'es glory |
||||||||
|
|
|||||||
No, I'm just a split personality, one part being 'Extremely Paranoid Systems Administrator'. |
||||||||
|
|
|||||||
one of my win2k instructors made a HUGE effort in describing the 'recommended' method of shares/permissions, which was: for sake of convenience All SHARES should have "authenticated users" will full permissions, and then use NTFS permissions on the files/folder to secure. The ntfs perms will supersceed the shares, since most restrictive perms will apply. Then you only need to maintain one set of perms and will not have 'conficts' with your logic. Use that as a basic rule (don't foget to set perms on the shared folder, not just the contents of the folder) |
||||||||
|
|
|||||||
Dear, As additional information for setup your server/client environment: For an easy upgrade of your clients with f.e. kixtart 4.02 you can use our installation package kix402update.exe. Always the correct files will be installed on your clients. The kix32 call can reduce to f.e. kix32 \\server\netlogon\your_script.kix At the moment there are six releases:
files will be replaced and missing files will be added. Regardless of file attributes. To prevent running more times weare using a control files. You can easily upgrade it with our iexpress package. Questions: how? A way of installing/updating kixtart of your clients: with only one additional statement For the installation of kixtart at your local workstation we see many version of doing it. Most statements in your BATch file are using for this duty. But there is also a way of doing it with a single statement, which doesn't only copy the required files, but also compare file version information. After completion a logfile will be created at your local workstation. Another way of installing/updating kixtart on your clients: For installing or updating of your clients you can download our packages kix363update.exe, kix400update.exe or kix401update.exe from our site http:\\home.wanadoo.nl\scripting. Possible calls in your logon procedure can be: As first line of your logon procedure you can use one of following formats:
for network environments (= update package will transfer during each logging on) code:or for dial-up environments (= update package will transfer only once)@echo off code:or@echo off code:After using above programs there will be created a control@echo off file c:\kix363.ok, c:\kix400.ok, c:\kix401.ok, c:\kix401.ok or c:\kix402.ok. So it isn't necessary to run the installation process again, but we advise to update (or better: verify) kixtart files always. Also those control files will put in the %windir% directory. Reason: a security leak for running kixtart from clients. remarks: SECURITY LEAK for running kixtart from clients running kix32.exe from a local workstation can have also unwanted effects. An user can modify or replace your kix32.exe file. f.e. not to run your script but for reading your script. For RAS users it is interesting not to download each time the kixtart required files, but for other users we advise: always check the kixtart files and update them when necessary before running your KIX scripts. FIX for SECURITY LEAK: In our case the first statement of our default logon procedure for network users is always: %0\..\kix363update.exe /q and it will guarantee that kix32.exe file will always the correct one. remarks: performance
btw: related kixtart topic http://kixtart.org/board/Forum2/HTML/000583.html btw: be sure no other kix32.exe and DLLs are active on your clients. |
||||||||
|
|
|||||||
Thanks for all the help!!! It is working again.. Just before the script stopped working, there where some patches loaded. These caused my kix-files to be hidden (the became protected operating system files and where therefore not visible.) That is why my users couldn’t “see” the script. After setting the files to normal files again, the script could be approached and used again. Thanks again Nenya |
||||||||
|
|
|||||||
Dear, Normally it is not a problem when you are calling a hidden kixtart script. Possible that you are trying to run the statement kix32.exe without script specification, which required the capability to search through a directory which required that your script is hidden. Question: are you calling it as describe above? greetings. |