|
|
|||||||
I am trying to deploy my logon.bat that calls my kixtart.kix script through a group policy. The servers are windows 2000 server and the client is windows NT 4.0 Workstation. I have tried putting several things in the logon key in the group policy screen and nothing works when the user logs on. I don't get any errors or anything but it doesn't run the script either. Please help! |
||||||||
|
|
|||||||
DJ, Why don't you show us your logon.bat & your kix script? |
||||||||
|
|
|||||||
Logon.bat code:Kixtart.kixECHO OFF code:;**** Created with KiXscripts Editor | http://KiXscripts.com **** |
||||||||
|
|
|||||||
If I deploy the logon.bat or the kixtart.kix script to the user individually it works perfectly without any problems. In the Group Policy Logon key I tried adding it there and it just doesn't work. |
||||||||
|
|
|||||||
Hi there, Group policies cannot be applied to NT4 clients unfortunately You'll have to work with good ol' poledit Only 2k and newer clients work with 2000/2003 GPO's |
||||||||
|
|
|||||||
Oh yeah ... and you commented at least one line false : quote: |
||||||||
|
|
|||||||
Well you can't do that if the servers are 2K can you? I don't have a NT 4 Domain Controller to handle NT 4 policies. I do know you can deploy policies to an NT4 box within a 2000 domain. And the comment is a non-issue. But Thanks! |
||||||||
|
|
|||||||
Forget about NT4 policies... forget about GPO logon scripts for legacy clients... It just will not work. FDISK the clients or specify the logon script in User Manager. |
||||||||
|
|
|||||||
Plain old batch file call in the User Manager. Never fails |
||||||||
|
|
|||||||
yeah but I gotta go to each nt 4 workstation and set that right? Damn that is a lot of work. |
||||||||
|
|
|||||||
yeah. especially when you can do that on by one click on dc. |
||||||||
|
|
|||||||
Huh!?!?!?! The second part of your post was kinda confusing. Could you please elaborate? |
||||||||
|
|
|||||||
Assuming you have a domain controller, you assign the login script in the 'User Manager for Domains' or whatever that thingy is called on the domain controller. So, why do you need to go to every workstation to implement a logon script? |
||||||||
|
|
|||||||
You do not have to go to every computer. You can do it from "Active Directory Users and Computers". There have also been scripts posted that will do it for you. |
||||||||
|
|
|||||||
In our organization we have many departments that use different mapped drives and printers based on their departments. My logon script checks for the ingroup and does it accordingly. We have a mixture of 9x, NT4, 2000 Pro and XP Pro clients. All 2000 Server Domain Controllers running AD. |
||||||||
|
|
|||||||
eh? AD that hard that you need to script such a task? bad... |
||||||||
|
|
|||||||
Ask NTDOC, he was the guy that wanted to script it. |
||||||||
|
|
|||||||
AD isn't hard, what are you getting at? You got a better idea? |
||||||||
|
|
|||||||
Well where is NTDOC? Is he watching this post? |
||||||||
|
|
|||||||
Yes: Back to square one and assign the logon.bat to each user in your AD domain. Is that too much? |
||||||||
|
|
|||||||
dj, get a moment and read what you are said. from les' post a piece: quote:like you have been told, use logonscripts normally. they are not wksta-related but domain based and can be done per-user... or as I did, selected the entire domain from user management and set their logonscript. |
||||||||
|
|
|||||||
DJ, Don't go Ballistic... it was in reference to my post "There have also been scripts posted that will do it for you". |
||||||||
|
|
|||||||
Assign the logon.bat to each user in my domain are you serious? Hell yes that's too much considering there are about 1000 users. If I can assign it to an OU then that is fine. But I tried assigning a logon.bat but for some reason it doesn't run. Maybe I am calling the script incorrectly in the logon.bat What should it look like? Considering my many various client OS's. |
||||||||
|
|
|||||||
Assigning a proper logonscript to an account (1 or ALL) is a trivial matter in both NT4 and W2K. But have you seen this thread: Assign script in Group Policy NT4 policies suck. I would FDISK computers that had them. [ 25. February 2003, 21:37: Message edited by: Howard Bullock ] |
||||||||
|
|
|||||||
eh? didn't someone just say that it's no goodie to try with policies? now you AD dudes got me lost as well. |
||||||||
|
|
|||||||
Piece of CAKE BREAK ON ; Example of LDAP call. GetObject("LDAP://ou=Users,ou=YourBusinessUnit,dc=YourCompany,dc=com") ; You need to know your LDAP connection. You can maybe find it by checking the propery details on the OU for your users. $target = GetObject("LDAP://your LDAP details") $loginscript="yourlogon.bat" for each $user in $target if $user.loginscript <> "$loginscript" ? "Current Script for " +$user.name " is: " +$user.loginscript+ " Should be: " +$loginscript ; $user.loginscript=$loginscript ; Remove the semi-colon at the front of this line to enable actually resetting the logon bat. ; $user.SetInfo ; Remove the semi-colon at the front of this line to enable actually resetting the logon bat. endif next |
||||||||
|
|
|||||||
A low tech way to do it is to use this JSI tip to generate a list of users: http://www.jsifaq.com/SUBB/tip0700/rh0748.htm Then create a command file that reads a user at time & then uses the net command to set the logon script. Then write a calling script that loops through the file with the FOR command. But personally, I think it might be worth your while to follow through with what NTDOC is offering. I suspect you will get results faster & you move into current technology. |
||||||||
|
|
|||||||
The script above can scan and modify 1,000s of users within a few seconds. A read through, shell to NET, LOOP, etc.. would have to be performed on the PDC/BDC and would take quite a bit longer to do. |
||||||||
|
|
|||||||
Dear, We have verify your code with kixstrip tool and we are missing one ENDIF statement. We couldn't verify at the moment KiXscripts Editor accept this code. code:we think that;**** Created with KiXscripts Editor | http://KiXscripts.com **** code:should beIF $rc=0 code:greetings.IF $rc=0 |
||||||||
|
|
|||||||
code:This code I am not sure how to use.BREAK ON Is there anyway I could give you information to fill in, the structure is what I am concerned with. To get it right. |
||||||||
|
|
|||||||
What exactly is the problem with this? The script is pretty self-explanatory. |
||||||||
|
|
|||||||
Jens, I am not sure but I get the impression DJ thinks COM is greek. DJ, The latest versions of kixtart allows one to use COM scripting. You need to install DCOM on Win9x/NT clients to use it (on Win2K/XP/ME I think it comes pre-installed). We have 2 FAQs on the topic:COM Primer & A FAQ with some COM info links plus the COM forum is full of tips. [ 03. March 2003, 22:38: Message edited by: Jack Lothian ] |
||||||||
|
|
|||||||
The problem with the script is that I am not sure how to figure out the LDAP part. I looked in AD and don't see anything. The other thing is...is there an easy way to automatically deploy the dcom if the client doesn't already have it? |
||||||||
|
|
|||||||
The script is a server script, thus ypour client do not need ADS. You would run your script on one of the Ad servers. What do you mean by you don't know your AD setup? The script explains the required parameters explicitly quote:This cannot be that hard, can it? Somebody must have set up AD, right? And the OUs and DCs shoudl be listed in the AD Manager. |
||||||||
|
|
|||||||
I am trying too many things at once. Is the problem. I have passed my deadline on making this work and I am in trouble so to speak. Essentially what I need to have happen is this. I need to deploy a logon script by Active Directory Group Policy. I need it to work on 98, NT 4 WS, 2000 Pro and XP Pro clients. That's it. Right now I am only trying to make it work on NT4 WS and it isn't working. I know it is possible because I have heard of people doing it. I have been searching the forums for many different posts and don't really get what I am looking for. A lot of reading and not much resource. Such as Do this, this, and this. The reply is I did this, this, and this. Nobody is saying whether it worked or not just more code to try. That is where my frustration is coming from. I am extremely greatful for the help I have received so far. Basically I have the kixtart.kix logon script working fine it is just the deployment part now. I do know if I put it assigned to the user's account in AD it works fine. But there are too many users for me to do that with. So that is why I need to deploy it by OU in AD either by the script or a batch file. Can anyone help me with knowing all of this? [ 04. March 2003, 16:01: Message edited by: DJ Ballistic ] |
||||||||
|
|
|||||||
The code that has been posted in this thread would solve to problem you are having. Run this code on one of your AD servers. Insert the correct OU and DC, which should be documented in the AD Manager of your AD domain. I'm sorry if we can't tell you what exactly to put into the GetObject but we didn't set up yoru AD domain. That is something you should have documented somewhere. I also should only take a minute or two to find this in the AD Manager. Then it's just a matter of putting it into the script and running it. It shouldn't take you mre than five mintes to do all this. |
||||||||
|
|
|||||||
Well right now here is what I have code:I don't know if I changed it to be correct or not. The user is located in the Test OU and the domain is sussexcounty.netBreak ON |
||||||||
|
|
|||||||
See I don't want to apply this to the entire domain as of yet because I need to work out all the bugs with the different OS's. So I am logging in with a test user that is in that Test OU and is a member of the necessary groups I am testing for. I just have to login with this test user on each of these different OS's to make sure it works on every one before changing it to work on the entire domain heirarchy. And I am still confused as to where that code should go. In my kixtart.kix script? And is there anything special my logon.bat should contain? [ 04. March 2003, 16:18: Message edited by: DJ Ballistic ] |
||||||||
|
|
|||||||
Just be sure the first script is started. Insert a net send to your computer, like "Net Send %ComputerName% This is a Test !", (this is only for the test). If logon.bat starts kix will also start. But not in your Logon.bat. You've typed \\sussex1\\NETLOGON, but it should be \\sussex1\NETLOGON. Just be shure that's correct. Otherwise the Kix32 won't be copied and also the script won't be found. Hope this might help you out! |
||||||||
|
|
|||||||
See what is happening with the NT 4 is that it acts like it isn't even running the script. It just logs in without any errors or prompts relating to my script. So how can I make sure it is running? I assume in AD it isn't setup right. |
||||||||
|
|
|||||||
Why are you talking about login? You should run the script on one fo the DCs formt he command line. This script has nothign to do with login script. It's a one-time-only script. It will set the login script for all users in OU=Test. Thus set the login script to soemthign and check after running the script whether it has changed. |
||||||||
|
|
|||||||
Oh Oh now I get it. Geez I feel dumb, now I get it. Okay I will run that on the Sussex1 DC. Do you think from what you can tell that I have that syntax right or is there anything missing on that code? |
||||||||
|
|
|||||||
In general, it does look okay to me. Also, it's always good to first test a script before letting it out into the wild. You must run it under an account that has aD amdin privileges. Also, change the code to: code:to provide mote insight into what's happening.Break ON |
||||||||
|
|
|||||||
code:Do I need the Users and Test OU's listed?Break ON |
||||||||
|
|
|||||||
Yes, you must define the OU that the script applies to. Give it a try, check the error messages and report back. |
||||||||
|
|
|||||||
I run it from my workstation i get "there is no such object on the server". Plus do I call this from a batch file because the DC isn't going to know what to do with a kix file. |
||||||||
|
|
|||||||
Then it seems that you don't have the correct OUs specified. |
||||||||
|
|
|||||||
But they are the names of the OU's. I am looking at it in AD Here is the heirarchy structure: sussexcounty.net ->AdminBldg ->Information Systems -> Test |
||||||||
|
|
|||||||
You can use the TranslateName() UDF and a @ldomain\@userid to return the distinguished name. From that you simply remove the CN=userid, and have the DN for the OU. |
||||||||
|
|
|||||||
I added the UDF to my script to run first but I am not sure what needs to be changed to conform to my domain. So the syntax is correct. |
||||||||
|
|
|||||||
Use TranslateName() and post the string you get. I'm sure we can then tell you what parts you need to write where. Take a look at the FAQ Forum if you want to know 'How To Use UDFs'. |
||||||||
|
|
|||||||
The use of the TranslateName UDF would be just to get the DN of one of your users since it appears that based on a previous post you could not find the user's OU. Use this example: code:$DN = TranslateName (3, "", 3, "@LDomain\@userid", 1) |
||||||||
|
|
|||||||
Here is what I get when I run it. L : 0 = -2147016656 - There is no such object on the server. -- Extended Error: C:\Documents and Settings\mmontgomery\Desktop\Kixstart 2001 4.20> |
||||||||
|
|
|||||||
I also added that example and I get this now. L : 0 = -2147016656 - There is no such object on the server. -- Extended Error: ssexcounty,DC=net. Montgomery,OU=Users,OU=Information Systems,OU=AdminBldg,DC=su Error = 0 ErrorText = The operation completed successfully. C:\Documents and Settings\mmontgomery\Desktop\Kixstart 2001 4.20> |
||||||||
|
|
|||||||
What is the OS of your computer where you are running the script? What was the script use executed? Have you tried the WinNT:// provider? |
||||||||
|
|
|||||||
I am running the script on XP Pro The script name is ldap.kix NT4 not sure what you mean. I am new at this. |
||||||||
|
|
|||||||
Please only run the example posted. What is the result? Please post your test script as well. [ 04. March 2003, 17:27: Message edited by: Howard Bullock ] |
||||||||
|
|
|||||||
If I use only that example posted I get this: ERROR : expected expression! Script: \\Sussex1\NETLOGON\LDAP.kix Line : 0 |
||||||||
|
|
|||||||
I am running this script from the Kixscript Editor. Should I be running this from a batch file? If so what needs to go in it. I have tried creating a ldap.bat that has Kix32.exe ldap.kix and it doesn't run, it says unable to find/open script. Man this is confusing. I thought this was easier. |
||||||||
|
|
|||||||
It would be easy if you would read the manual and the FAQ Forum. You also seem to have only minimal administrative experience which also doesn't help. Create a folder and put the KiXtart executable and the script into it. Edit the script in Notepad. open a command prompt and switch into the directory that contains your script and the Kixtart executable. Run the script by typing 'kix32 ldap.kix' at the command prompt. Also, please post the script you're using (in between [CODE] tags). |
||||||||
|
|
|||||||
Sorry to sound like I am beating on an old drum here is my login script: Kixtart.kix code:This all works if the script actually runs. Here is the logon.bat I created to try to call the script: code:It seems to work okay too I am not sure.@ECHO off I haven't changed it to try to work with 9x clients yet so the "myscript.scr" is still in there. I created this ldap.kix script code:Doesn't work when I run it alone.;**** Created with KiXscripts Editor | http://KiXscripts.com **** I tried creating a batch file to call it as well code:It doesn't work at all. I need a stiff drink. |
||||||||
|
|
|||||||
Actually my administrative experience is quite extensive. I am an MCDBA and an MCSA. I however am completely new to the kixtart scripting and have never done it before so in communicating with you guys that are more experienced it is hard for me to understand what you mean. The manual isn't helping me, I have read it and read it. It seems that I have a more complex environment that the manual covers. |
||||||||
|
|
|||||||
Why do you keep talking about login scripts? Forget the login script Do what I just posted. We're just working with the ldap.kix right now. I don't even care about your login script. It's not part of the problem Sorry, but it's getting a little bit tiresome. Make sure you have administrative privileges for the AD domain before running the ldap script. |
||||||||
|
|
|||||||
However, the manual does explain how to call a script. It also explains how to debug scripts. And an AD domain is not complicated per se. Did you read this as I referenced above: How to use UDFs [ 04. March 2003, 17:40: Message edited by: sealeopard ] |
||||||||
|
|
|||||||
ok I have domain admin rights on the domain. I can run the script. I need to run this on the domain controller right? If so how do I call it? That is my problem right now. I just can't run the .kix file it doesn't know what to do with it. And I can't just run kix32 because it will default to the kixtart.kix file which isn't the issue. I tried making a batch file to run the ldap.kix script and it isn't working. That is what I am trying to say. |
||||||||
|
|
|||||||
OK there appears to be a typo in the sample ldap.kix script. Two lines are concatenated There should be the function call and then three lines that begin with a question mark. Include the UDF TranslateName() under these fours lines. Execute the script using the command line "kix32.exe ldap.kix" You should get three lines of output. DN = ... Error = ... ErrorText = ... |
||||||||
|
|
|||||||
Command prompt (adjust for correct directories): code:LDAP.KIX:d:\temp\ldap\kix32.exe d:\temp\ldap\ldap.kix code:$DN=TranslateName(3, "", 3, "@LDomain\@userid", 1) [ 04. March 2003, 17:46: Message edited by: sealeopard ] |
||||||||
|
|
|||||||
You can execute this on your workstation, but you will have to make sure that KiXtart is in the current directory, in the %PATH%, or use fully qualified paths to both KiX32 and your script. |
||||||||
|
|
|||||||
Ok it ran successfully here is what I get: ssexcounty,DC=net. Montgomery,OU=Users,OU=Information Systems,OU=AdminBldg,DC=su Error = 0 ErrorText = The operation completed successfully. Why does it cut off the su on the first line? Is the first part of it on like 3 before the Error = 0 where it says DC=su? But anyway that is what I get |
||||||||
|
|
|||||||
Howard & Jens, You guys are doing a great job. If there was an all-star kixtart team you would be on it. |
||||||||
|
|
|||||||
Jack: Bring on the stars by voting for us ;-) DJ: Put code:into the first line of your script to force output wrapping.$rc=SETOPTION('WrapAtEOL','ON') [ 04. March 2003, 17:56: Message edited by: sealeopard ] |
||||||||
|
|
|||||||
This does does not look correct. It appears that you have wrapping text. I would also increase the size your your DOS window so your do not have the wrap issue and it will display on one line. [ 04. March 2003, 17:59: Message edited by: Howard Bullock ] |
||||||||
|
|
|||||||
Ok now we are getting somewhere Yipee!!!!! Here it is with that added DN = CN=Matthew T. Montgomery,OU=Users,OU=Information Systems,OU=AdminBldg,DC=su ssexcounty,DC=net Error = 0 ErrorText = The operation completed successfully. |
||||||||
|
|
|||||||
Your GetObject string should be: code:"LDAP://OU=Users,OU=Information Systems,OU=AdminBldg,DC=sussexcounty,DC=net" |
||||||||
|
|
|||||||
Now what's next? |
||||||||
|
|
|||||||
OK that now works it says what my current logon script is and what it should be. It doesn't change anything because I haven't uncommented those lines to actually have it reset it. That code on the top of page 2. That is what I ran and the results are stated above. What do I do with it? |
||||||||
|
|
|||||||
If it displayed all of the accounts you wish alter and you agree with the accounts listed, then remove the semi-colon in front of the two line that actually set the property. See below. code:BREAK ON |
||||||||
|
|
|||||||
Well the user is named kixtest and is in the Test OU not the Users OU under Information Systems. I changed it accordingly below and I run the script but I don't get any errors, but I don't get any information like before either. It just says The task completed successfully. Like this: "LDAP://OU=Test,OU=Information Systems,OU=AdminBldg,DC=sussexcounty,DC=net" |
||||||||
|
|
|||||||
Ahh I see this code does. It checks to see if a login script is assigned to the user's profile itself. Well in that case I don't see how this will help me. I need to assign the logon scripts to the OU, I know you said I cannot do that with NT 4 but I am a little lost as to how this code is to help me. |
||||||||
|
|
|||||||
This code will give each user in the specified OU a logon script called logon.bat. This is what you have to do in order to have people run a login script when logging into Windows 9x/NT/2000/XP. |
||||||||
|
|
|||||||
Are you running the DSClient on ALL of your downlevel clients? If you are you might be able to use the methodology I employ for my corporate logonscript. It calls subscripts based on the clients location in the OU hierarchy. All of your clients will execute the same base script called from a batch file. The core script then looks at the clients DN and then makes directory paths from the DN. You can place any scripts you want to execute in a directory structure that mimics the OU hierchy and have different scripts execute for different users. See http://mywebpages.comcast.net/habullock/logon_script_architecture.htm See my UDF MakePathsFromADlocation() [ 04. March 2003, 19:11: Message edited by: Howard Bullock ] |
||||||||
|
|
|||||||
Ok as a test I removed the comments for that script to run. code:I have it going to the Test OU in which there are 2 users, currently that have no logon script setup. If I run this with the comments removed are you saying it will automatically assign the logon.bat to those 2 user's profile?Break ON |
||||||||
|
|
|||||||
Yes, this is what is supposed to happen. |
||||||||
|
|
|||||||
It doesn't work. I run the script and says error = 0 but i go to that user's properties and there is no script name in there under their profile. If I can get this to work I think I will be set to go. |
||||||||
|
|
|||||||
What does the 'current script' and 'changed ' text output lines state? They should reflect the changes made. |
||||||||
|
|
|||||||
Do you have more than one DC in the domain? The DC chosen by the script to update the user account may not be the same DC to which your GUI is connected. |
||||||||
|
|
|||||||
Error = 0 - The operation completed successfully. C:\WINDOWS> That's all it says. This is the code I am running. code:Break ON |
||||||||
|
|
|||||||
We do have more than 1 DC in our domain. The DC I am connected to is the one where my GUI is connected. |
||||||||
|
|
|||||||
You might want to learn how to modify your script so that it prints more info. Try this: code:Break ON [ 04. March 2003, 20:35: Message edited by: sealeopard ] |
||||||||
|
|
|||||||
Okay I ran that and it did bring back the 2 users in that OU. It didn't assign the logon script in their profiles though. |
||||||||
|
|
|||||||
Could you please copy the complete output from your script to this board? |
||||||||
|
|
|||||||
'\\Sussex1\NETLOGON' CMD.EXE was started with the above path as the current directory. UNC paths are not supported. Defaulting to Windows directory. Error = 0 - The operation completed successfully. checking user: CN=Kix Test checking user: CN=Test User If no user was displayed, then no user was retrieved from the OU C:\WINDOWS> |
||||||||
|
|
|||||||
Please run the latest version of the script we posted so that the original assigned login script will get printed, too. |
||||||||
|
|
|||||||
I am using the latest posted script See: code:Break ON |
||||||||
|
|
|||||||
Then something seems wrong as it should also display the line 'Assigned login script' for ech user, which it doesn't. |
||||||||
|
|
|||||||
Well right now those 2 users don't have login scripts assigned. Isn't it supposed to assign it? |
||||||||
|
|
|||||||
Even if they don't have a login script assigned, the text 'Assigned Login Script:' should still be printed to the screen. |
||||||||
|
|
|||||||
It does for me... |
||||||||
|
|
|||||||
It does not for me so I don't know what is wrong. |
||||||||
|
|
|||||||
NTDOC which code are you using and what OS? I can't get it to display any thing relating to the current login script unless I manually assign it then it picks it up. |
||||||||
|
|
|||||||
Add: $script = $user.loginscript ? "Logon script error: @error @serror" after the line "checking user" |
||||||||
|
|
|||||||
Aww geez now I get this: '\\Sussex1\NETLOGON' CMD.EXE was started with the above path as the current directory. UNC paths are not supported. Defaulting to Windows directory. Error = 0 - The operation completed successfully. checking user: CN=Kix Test ory - The directory property cannot be found in the cache.script" (Active Direct ) [-2147352567/80020009] checking user: CN=Test User ory - The directory property cannot be found in the cache.script" (Active Direct ) [-2147352567/80020009] If no user was displayed, then no user was retrieved from the OU C:\WINDOWS> |
||||||||
|
|
|||||||
I have seen some ADSI COM calls fail and the text line used inconjuction with a "+$user.loginscript" will cause a failure is the property is not defined. So to get around that issue assign it to a variable first and check @error to see if you got it or not. I have updated the script to use this method. See below. code:Break ON |
||||||||
|
|
|||||||
However the script is sort of working. If I manually assign kix32 in the user's logon script box. And if I then run this script it changes it to logon.bat, but if there is currently nothing in there it gives me what I posted previously. |
||||||||
|
|
|||||||
You need to trap the fact (error) that the logon script has never been assigned. Something like this should help the situation. code:{edit} added quote on line 17Break ON [ 04. March 2003, 21:23: Message edited by: Howard Bullock ] |
||||||||
|
|
|||||||
With the newly changed script I get this now: '\\Sussex1\NETLOGON' CMD.EXE was started with the above path as the current directory. UNC paths are not supported. Defaulting to Windows directory. Error = 0 - The operation completed successfully. checking user: CN=Kix Test ERROR : unknown command [Logon]! Script: \\Sussex1\NETLOGON\LDAP Call.kix Line : 17 C:\WINDOWS> |
||||||||
|
|
|||||||
hold on don't post more yet. I am going to try that last code that was posted and report the results. |
||||||||
|
|
|||||||
Ok last result here is what I got: '\\Sussex1\NETLOGON' CMD.EXE was started with the above path as the current directory. UNC paths are not supported. Defaulting to Windows directory. Error = 0 - The operation completed successfully. checking user: CN=Kix Test Logon script error: 0 - The operation completed successfully. assigned login script: logon.bat checking user: CN=Test User Logon script error: 0 - The operation completed successfully. assigned login script: logon.bat If no user was displayed, then no user was retrieved from the OU C:\WINDOWS> |
||||||||
|
|
|||||||
Forgot a quote: ? "Logon script error: @error - @serror" |
||||||||
|
|
|||||||
Ballistic. From a Windows 2000 workstation or XP workstation. Copy KIX32.EXE and your script to a folder locally on that box. Then from a command line type as an example in the TEMP folder if you copied the file there. C:\TEMP\KIX32.EXE LDAP.KIX (or what ever the name of your script is) it should work. Break ON ; uncomment the next line to step through the code ; Debug ON $target = GetObject("LDAP://OU=Test,OU=Information Systems,OU=AdminBldg,DC=sussexcounty,DC=net") ? 'Error = '+@ERROR+' - '+@SERROR $loginscript="logon.bat" For Each $user in $target ? 'checking user: '+$user.name $script = $user.loginscript ? 'Logon script error: @error - @serror' ? 'assigned login script: '+$script If $Script <> $loginscript ? "Current Script for " +$user.name " is: " +$script+ " Should be: " +$loginscript $user.loginscript=$loginscript ? 'Error = '+@ERROR+' - '+@SERROR $user.SetInfo ? 'Error = '+@ERROR+' - '+@SERROR ? "Changed current Script for " +$user.name " to: " +$user.loginscript EndIf Next ? 'If no user was displayed, then no user was retrieved from the OU' |
||||||||
|
|
|||||||
Ok for Howard's post. I fixed the quotes and it works. It automatically added the logon.bat in each user's profile in that OU. With what NTDOC is posting will that interfere with that you are already showing me Howard or is that in addition? |
||||||||
|
|
|||||||
It's actually all the same, just different colors. alos, we've already talked about how to call KiXtart scripts, so there shouldn't be any open questions left (I hope ). |
||||||||
|
|
|||||||
Same code, only all the error logging removed. Should run exactly the same. I posted this code using PostPrep which allows you to copy it directly from here and paste into your text editor and maintain the formatting of the code is all. Break ON $target = GetObject("LDAP://OU=Test,OU=Information Systems,OU=AdminBldg,DC=sussexcounty,DC=net") $loginscript="logon.bat" For Each $user in $target $script = $user.loginscript If $Script <> $loginscript ? "Current Script for " +$user.name " is: " +$script+ " Should be: " +$loginscript $user.loginscript=$loginscript $user.SetInfo EndIf Next |
||||||||
|
|
|||||||
I meant this part Ballistic. From a Windows 2000 workstation or XP workstation. Copy KIX32.EXE and your script to a folder locally on that box. Then from a command line type as an example in the TEMP folder if you copied the file there. C:\TEMP\KIX32.EXE LDAP.KIX (or what ever the name of your script is) it should work. Why should I do or not do this? |
||||||||
|
|
|||||||
Ok I tested it on XP Pro, Check 2000 Pro, Check 98SE, No good. Says bad command or filename. Is there something that needs to be changed in my logon.bat or my kixscript that maybe 98SE initially cannot read. That is the last thing and I am finished. |
||||||||
|
|
|||||||
Why are you testing this script on all those operating systems? Only you will run this one time from your work station. Or are you now testing the logon script on these computer? Please try to include enough info for us to follow exactly what is happening. |
||||||||
|
|
|||||||
I prefer to provide full paths whenever calling scripts, especially if it has to work cross-platform. |
||||||||
|
|
|||||||
I am just testing it on a 98 box. Full paths like C:\yadda\yadda, etc like that not UNC's. Hmm not sure how to do that for the 98 boxes Because the netlogon folder on sussex1 which is the domain controller I am not mapping to any of the clients. It is just shared and that's it. |
||||||||
|
|
|||||||
Windows 9x DOES NOT run KiXtart without the supporting .DLL files. You also need to install ADSI on the NT/9x systems to run this type of script. As I say though. It should only be run from your 2000/XP workstation or another Admins workstation. It is not for a normal user to run. |
||||||||
|
|
|||||||
Ok I ended up using the overkill batch file in thread http://www.kixtart.org/cgi-bin/ultimatebb.cgi?ubb=get_topic;f=1;t=006464 At any rate, it automatically copied kix32 and the supporting dll's to the 98 client. I login with the 98 client and the script runs. However one funny qwerky thing that is happening is that it only maps some of the drives and not all of them that are mapped using the same user logging into a 2000, NT, or XP box. Any thoughts? I can see the light at the end of the tunnel I am almost finished with this whole thing. |
||||||||
|
|
|||||||
OK, you ask a question but did not supply the info about which drives did not map and what code (IF statement) governs when/if they get mapped. |
||||||||
|
|
|||||||
Ok sorry, code:This code works fine with the XP, 2000, and NT clients. Also the printer mappings aren't working at all on the 98 client. Here is that code as well.;******************************************* code:Thanks!!;************************************ |
||||||||
|
|
|||||||
As for the printers not mapping on Win9x computers, see the text taken from the manual below: quote:The drive not mapping seems to indicate that INGROUP may not be behaving as expected. Take that piece of code and make a test script to test just the INGROUP functionality use if ... else... endif format so that you can see if the ingroup is actually true or false. |
||||||||
|
|
|||||||
Ok I guess the printer issue with 9x is not a big deal really. The drive mappings are though. I created a test script for the drive mappings only and added the error checking by each line to make sure what is going on. Here are the results: '\\Sussex1\NETLOGON' CMD.EXE was started with the above path as the current directory. UNC paths are not supported. Defaulting to Windows directory. I: (\\Sussex-FS-1\General) Error = 0 - The operation completed successfully. P: (\\Sussex1\Users\mmontgomery) Error = 0 - The operation completed successfully. S: (\\Sussex1\Shared) Error = 0 - The operation completed successfully. W: (\\Sussex-FS-2\Information Systems) Error = 0 - The operation completed successfully. G: (\\Sussex-FS\Global) Error = 0 - The operation completed successfully. R: (\\Sussex-FS\ReAddressing) Error = 0 - The operation completed successfully. V: (\\Sussex1\View) Error = 0 - The operation completed successfully. Z: (\\Sussex-fs-1\Aerial_Photos) Error = 0 - The operation completed successfully. C:\WINDOWS> |
||||||||
|
|
|||||||
This was run on an XP box though not the 98 one. Do you need for me to run it on the 98 box? I was just checking to verify the network paths were valid and they are. By the ingoup usage. |
||||||||
|
|
|||||||
You should always run the scripts under the compuer/OS that is producing the errors. Also, with all the asssitance we've been providing so far I believe you should be able to do some basic debugging without asking us for every step. Put a DEBUG ON into the first line of your script code, and step through the code while running it under one of the affected computers/users. Then put more error checks into the code and test more. We are willing to help you, but you will have to do some of the work yourself. [ 05. March 2003, 15:43: Message edited by: sealeopard ] |
||||||||
|
|
|||||||
Not to be too blunt, but if the faillure is on the Win9x box do you think you need to be testing on the Win9x box so that you know what exactly is working and not working so that you can eventually fix the problem? |
||||||||
|
|
|||||||
Ok from what I found out by running it on the 98 box. It starts to map drives and when it gets to this line: If InGroup('Information Systems') ? 'W: (\\Sussex-FS-2\Information Systems)' Use W: '\\Sussex-FS-2\Information Systems' ? 'Error = '+@ERROR+' - '+@SERROR EndIf It says path cannot be found, which is actually true. That is a share that only IS people can get to. That is why it worked when I did it on my XP box because my login name has that permission. So it looks like the script fails after that line. Is there a way to make it keep running the script even after an error occurs? |
||||||||
|
|
|||||||
That should not cause the script to terminate. Logon as you on the Win98 box. Does the mapping complete? Are there limits to the length of a share that Win9x can address? [ 05. March 2003, 16:12: Message edited by: Howard Bullock ] |
||||||||
|
|
|||||||
I just logged in as me on the 98 box and same thing happened. It stops at that one share failure. I commented out that 1 to see if it would continue on to the Mapping & Addressing drives and it doesn't. I hope there is no limited to only 3 mapped drives on 98. That would really suck. Someone has to be doing this successfully. |
||||||||
|
|
|||||||
I am not saying you are limit to 3 mapping. I am questioning the length on the share name. Are the other shares that you map have long share names as well? Sorry, I should know any limitation of Win9x, but haven't platyed with Win9x in some years. Take you map statement and use 'Net use' to map the drive in a DOS window. Is that successful? Try mapping in explorer is that successful. If so, then there appears to be a problem in the script. If not then you have some network/client issue to resolve. What is the code following the failed mapping? [ 05. March 2003, 16:25: Message edited by: Howard Bullock ] |
||||||||
|
|
|||||||
However, there are limits to the length of share names. This is well documented, e.g. in the FAQ Forum. I also think I already asked you a couple of times to RTDFF (Read The D*** FAQ Forum). The post is appropriately named Limits in NetBIOS, computer/printer names, share names/comments . |
||||||||
|
|
|||||||
Ok every drive mapping mapped manually from the command prompt on the 98 box using net use commands. Except for the one ? 'R: (\\Sussex-FS\ReAddressing)' Use R: '\\Sussex-FS\ReAddressing' Which prompted me for a password, I am not sure why. I can get to it on my XP box just fine but not on the 98 box logged in as me. So I don't see the lengths being an issue here. Most of the shared are much shorter that the ones I am using below. code:;******************************************* |
||||||||
|
|
|||||||
Did you try creating a test script that just execute the "If InGroup('Mapping And Addressing')" test to see if the client is find the group membership? Group names greater than 20 characters are not supported on Win9x. Try looking there. |
||||||||
|
|
|||||||
I tried commenting all of the other drive mappings out except for that section and it didn't map anything. But if it was a limitation in 98 why would it work manually, I don't understand. |
||||||||
|
|
|||||||
My last post was not a comment about mapping drives. It was about the ingroup test on a group name greater than 20 characters. Please isolate your testing to one thing at a time so that you can determine exactly what does and what does not work. |
||||||||
|
|
|||||||
And read the post I referenced to double-check whether you hit any of the limitations mentioned in it. |
||||||||
|
|
|||||||
just run this If InGroup('Mapping & Addressing') by itself? |
||||||||
|
|
|||||||
You have to create a valid piece of script. Save this as a test.kix and execute it on the your XP box to see the success and then execute it on the Win98 box to see if you get a different result. code:? "The value of InGroup(Mapping And Addressing) is : " + InGroup('Mapping And Addressing') |
||||||||
|
|
|||||||
Try this: code:by itself.$group=InGroup('Mapping & Addressing') |
||||||||
|
|
|||||||
Ok yes the 98 client is falling into that limitation. I don't know if it is worth trying to map it with the shorter share name that gets cutoff like with long filenames in dos. If I decide to not worry about 98 clients altogether how is that going to affect everyone else. The problem is I don't know how many 98 clients there are, probably only a small few. But if I run that utility that was created for me to run one time to set the logon script to users in an OU, the chances are that it may end up being a 98 client and I don't want them to be screwed up. It would be nice if there was a way for the script to detect a 98 client and just not run at all regardless if they had a logon.bat assigned to their user account. |
||||||||
|
|
|||||||
The easiest and best solution is for you to correct the long share and group names. Shares can be easily changed and the groups can be renamed via script. [ 05. March 2003, 17:57: Message edited by: Howard Bullock ] |
||||||||
|
|
|||||||
I have to agree with Howard on this one. Oh, man, why not take a look at the KiXtart Manual? You could for example take a look at the macros section. Alternatively, take a look at e.g. my signature, which will laso give you a lot of resources. Or take a look at the OSID() UDF in the UDF forum. So, why not sit down for an hour and go through all the resources we've provided to you? [ 05. March 2003, 17:58: Message edited by: sealeopard ] |
||||||||
|
|
|||||||
Actually when I ran only that piece of code you posted I get this: 0 - The operation completed successfully. InGroup() = 0 |
||||||||
|
|
|||||||
If it was possible to actually pay someone to write the damn script for me I would but I can't. I am basically finished and my boss is saying not to worry about the 98 clients but I don't want to hose them up if it just isn't going to work. What about that code result I posted? That was run on the 98 box. |
||||||||
|
|
|||||||
Which would indicate that the user is NOT a member of the group. Is that what you expected? Is the group name correct? The two different test scripts show different group names. [ 05. March 2003, 18:02: Message edited by: Howard Bullock ] |
||||||||
|
|
|||||||
I am so so greatful for the help I have received up to this point. Everything I have done is basically due to the help of you guys and that is fantastic thank you. |
||||||||
|
|
|||||||
Read the Manual! code:IF @INWIN=1 |
||||||||
|
|
|||||||
Actually, a '0' would also be returned if you're outside the goup name length limts, I believe. Thus, the INGROUP() is actually working as expected. However the group names are way too long and should be shortened. Just excluding Windows 9x clients is a workaround and shouldn't really be done. Fix the underlying problem, don't cure the symptoms. This way, you end up with a well-documented and correctly setup network. |
||||||||
|
|
|||||||
Well we are not going to be able to change the share names because there are people currently using them the way they are and we are not ready to go live with this script domain wide yet. My boss/network administration says he really doesn't care about the script running on the 98 clients. I ran that code ? "The value of InGroup(Mapping And Addressing) is : " + InGroup('Mapping And Addressing') and i got a result of = 1 I change the And to & and got a result of = 0 I believe the actual group name in AD is Mapping & Addressing. |
||||||||
|
|
|||||||
A value of one (1) indicates the user is a member of the group. I think you need to get a better grip on what the group names actually are so that your script works as expected. The "AND" was copied from one of your posts. [ 05. March 2003, 18:14: Message edited by: Howard Bullock ] |
||||||||
|
|
|||||||
I still have no clue if you were successful or not with this test on the Win98 computer. You mentioned that you were affected by the limitation then you post your last item saying that my script returned a (1) meaning it worked. Where did it work? Where did it fail if at all. We are getting nowhere fast. [ 05. March 2003, 18:17: Message edited by: Howard Bullock ] |
||||||||
|
|
|||||||
The '#', '$', and '&' are special characters and should not be used under Windows 9x in computer names and/or group names. |
||||||||
|
|
|||||||
It is not just shares that is being talked about here it is the group names. I believe your long group names will not work on all DOS/Win9x/ME/NT clients. NT Servers do not like long group names either. Your organization shouldn't have created such long group names. I agree with jens & Howard you should rectify the underlying problem. [ 05. March 2003, 18:23: Message edited by: Jack Lothian ] |
||||||||
|
|
|||||||
I'm actually surprised that this is not part of the MCDBA/MCSA exams. |
||||||||
|
|
|||||||
Ok to recap this. I the group name in AD IS in fact Mapping & Addressing, it returns a result of 0 on my XP box and my 98 box. |
||||||||
|
|
|||||||
And on the NT4 box everything works fine now so I guess whatever. You guys have been patient up to this point but now you are getting to be rude. As for the MCDBA/MCSA exam remark, Kixtart isn't even mentioned. |
||||||||
|
|
|||||||
Replace the '&' ampersand with the 'And' and try to avoid special characters in shares/groupnames/usernames/computernames/DNS. However, I meant e.g. group limitations, not KiXtart. Also, be aware that if you assing a user to a group without refreshing the Kixtart token cache (Windows Nt/2000/XP only), that KiXtart might not detect the new group assignment. Please see the KiXtart Manual for ways to refresh the token cache. |
||||||||
|
|
|||||||
Ok someone at my location is messing with me. Geez, ok the group name is Mapping And Addressing not the Ampersand. Grief as if I am not stressed enough already. |
||||||||
|
|
|||||||
DJ, Howard & Jens have been very patient & as volunteers they have given you a lot of their free time. I don't see anything rude in their posts. They have shown a little annoyance occasional maybe but never rude. Your question style is rather abrupt & you tend to assume we know more about your circumstances than we do which tends to make responding difficult. I think frustration arises because of this difficulty. Try to be patient & give details. Make each post more detailed instead of feeding the info a little piece at a time in different posts. |
||||||||
|
|
|||||||
What happens if you shorten that particular group name to less than 20 characters? |
||||||||
|
|
|||||||
I'm sorry I don't mean to sound abrupt. I am not able to shorten that group name on the account of network admin doesn't want it done. Shorten a test group name and it seems that the group limitation is 13. It will run correctly at everything 13 and below for a group name. I guess I am going to have to search for a IF @INWIN or something to have the script stop if it detects a 98 client. That is what my network admin wants. |
||||||||
|
|
|||||||
You still have similar limitation on NT4. Are you going to just ignore NT4 workstation as well? |
||||||||
|
|
|||||||
How many of computers of each operating system do you have on your network? What is the planned scheduled replacement of all of the computers with less then Windows 2000 running on it? If the network and servers were setup without consideration for the client operating systems that need to be supported, you can tell your Admin from me that he was negligent in his professional responsibilities. [ 05. March 2003, 19:55: Message edited by: Howard Bullock ] |
||||||||
|
|
|||||||
Good grief I didn't realize that NT WS 4.0 would have a problem too. I don't know what to do. I cannot change group names to make them short, end of story, that is not an option. I guess this login script thing is a crazy idea for our situation now. I don't know what to do. I hooked up the NT 4 box again to try this and it maps all the drives even in "Information Systems" group so the limitation isn't that small for NT 4. I should tell you the Mapping And Addressing & Information Systems are the longest group names we have. Plus I found that there is also a group name called Assessment that Mapping & Addressing users are also in and it seems to work as well in the kixscript for NT 4.0 The 98 box doesn't seem to recognize the "Assessment" group. I guess I have to refresh that token cache. |
||||||||
|
|
|||||||
As for the number of OS's for the PC's on our network. There are very small 98 maybe like 10 if that. NT 4 quite a few and no soon plans for replacement. Many 2000 and XP boxes and everything new coming in is XP. |
||||||||
|
|
|||||||
Could you please explain to me what is so critical about the special group names that they cannot be shortened? Alos, why weren't OS limitations considered when the network was originally designed? |
||||||||
|
|
|||||||
NT4 has a group name limit of 20 characters. Apparently you found that Win9x has a groupname limit of less than that. The logon script is a great managment tool, but one has to properly setup the domain environment for ALL clients. |
||||||||
|
|
|||||||
Well other than the Network Admin doesn't want them changed no. As for the pre-planning stages of the network the first Network Admin is no longer here and that is just going with the time, budget money, etc. NT4 was more expensive then. But that is all shoulda, woulda, coulda. That isn't my fault I am just trying to come up with something workable in our current environment. |
||||||||
|
|
|||||||
Okay good so NT4 boxes aren't going to cause me a problem then. Just the 98 boxes. Since there are so few of them maybe that is why my Admin is telling me to have the script not run on them if 98 is detected. When the systems are replaced they will be XP and still good to go. |
||||||||
|
|
|||||||
You have been presented with the solution: Shorten the group names to an generally acceptable range. If the 'Network Admin' refuses, send him to the Microsoft KB so he can read up on it, otherwise I would suggest that the 'Network Admin' might have to look for another job soon. I don't consider the 'Network Admins' reaction professional. One has to wonder what else he doesn't want to do correctly. [ 05. March 2003, 20:04: Message edited by: sealeopard ] |
||||||||
|
|
|||||||
I totally agree with you. But since the group names aren't going to affect the NT 4 clients and will only affect the 9x boxes I think the best, and easier thing to do is have the script not to run at all when 98 OS is detected. That sounds good to me. I guess I'll read up on that and try to figure it out. |
||||||||
|
|
|||||||
Did you run the ingroup test script on an NT4 computer using the group name 'Mapping And Addressing'? Did it success or fail? If it fails, I would expect that. If you say is succeeded then There is some new aspect of the NT4 to AD as compared with NT4 to NT4 DC. Remember that if Ingroup > 0 then the user is a member. when it equals zero the user is not a member or so thinks the client. [ 05. March 2003, 20:09: Message edited by: Howard Bullock ] |
||||||||
|
|
|||||||
The Mapping And Addressing works successfully on the NT 4 box that is what I was saying. We won't have a problem then. |
||||||||
|
|
|||||||
The only problem is going to be 9x which I am ready to friggin through all of them out, which I can't do . But I think if I just have it not run then I will be fine and I can disappear from these forums |
||||||||
|
|
|||||||
I find that the ingroup working (returning the correct value) on a group greater than 20 on an NT4 client extraordinary and I will have to perform further testing here to understand why. We have seen in the past where a group name longer than 20 character will cause the ingroup command not to recognize that the user is a member of the group when in fact he was. Please confirm that you did test logging on as an account that is a member of 'Mapping And Addressing' and the Ingroup function returned a value of 1. |
||||||||
|
|
|||||||
It is possible that if you have e.g. two group names with more than 20 character but which have the same first 20 characters that the INGROUP might fail as it cannot correctly resolve the group name. |
||||||||
|
|
|||||||
i don't have the issue where the 2 group names have the same first 20 characters. That will never happen in our organization. As for the verifying that the Ingroup produced a value of 1 with the Mapping And Addressing group. That is affirmative. It returns a value of 1 |
||||||||
|
|
|||||||
i don't have the issue where the 2 group names have the same first 20 characters. That will never happen in our organization. As for the verifying that the Ingroup produced a value of 1 with the Mapping And Addressing group. That is affirmative. It returns a value of 1 |
||||||||
|
|
|||||||
I guess that is a good thing. Will have to to do more testing here to gain a better understanding of the issue and why I saw failures in the past. [ 05. March 2003, 21:20: Message edited by: Howard Bullock ] |