|
|
|||||||
I recently implemented KiXtart 2010 into my environment to replace all my old .bat login scripts. I borrowed fairly heavily from the adminscripteditor.com script library Domain Login Script. Now, I am seeing sporadic cases where workstations don't get mapped drives, and other cases where the drives map but all disappear about 20 minutes later. I have not been able to determine yet if the two instances are related. On workstations where drives don't get mapped, manually running the KIX executable seems to work (I will be investigating the XP wait on network setting). The script is fairly basic, thus (I have abridged redundant sections and sanitized it a bit): Code:
I am seeing error files from some workstations, but in all cases the @ERROR code is 0. Any thoughts/input would be helpful. G and J drives seem to be the most problematical, but then nearly everyone in the domain gets them so they are almost certainly over-represented. |
||||||||
|
|
|||||||
Modified tour script a bit hope you don’t mind. I removed the GoSub stuff. GoSub (and GoTo) should not be used in best practice because they make spaghetti code that is almost impossible to read and the flow of the script gets hard to follow. Untested but the script below should work. It first deletes the drives before mapping them because users can delete a drive mapping and map some other drive. It uses the /persistent option to also delete the drive is it has been mapped persistent. If the mapping of a drive failed it writes a line to the log file with error codes and workstation name. Code:
|
||||||||
|
|
|||||||
I appreciate the input on Gosub. I actually originally had the script set as you do, to map the drives directly in each section, and was still seeing the problems with some workstations not getting their mapped drives (couldn't tell if they were running the script or not). I switched to this one to see if a change to the mapping procedure made any difference (and it had the error logging built in). I now get error log files from some machines, but not others. I was a little curious about your comment regarding spaghetti code. What is the difference between a Gosub and a function() call? Aren't they essentially the same as far as the flow of the code in the script? I forgot to mention in the original post: the desktop environment is all XP Pro (some sp1, mostly sp2), and the backend is all 2003 server. AD is running in native 2003 mode, and replication is working fine between all 3 domain controllers. |
||||||||
|
|
|||||||
I tested your script. The IF @ERROR sections seem to simply re-set the $rc variable to the new value you have (Writeline etc etc). All my error files were coming in empty. They'd get created, but there was no text in them. I rewrote the script again, using the direct mappings as you have them, but calling the original ERRLOG subroutine which I know works. |
||||||||
|
|
|||||||
GoSub and GoTo both jump backwards and forwards in the script so the flow of the script is difficult to follow just like a plate of spaghetti Functions are build-in in the executable or (when it is a UDF) is placed between Function and EndFunction so it gets read into memory before anything else in the script gets executed. I prefer putting any UDF’s into a separate file and call them at the beginning of the script that uses them. First I would disable XP fast logon optimization because it sucks. If this doe not solve the problem then I would take one machine that has problems and put it in a so called quarantine environment and run some tests to see where things get screwed up. Does it also happen when other users logon to the system that does not map properly is it just one user having trouble? What happens if you replace the kix32.exe and/or wkix32.exe with fresh copies? Are you sure you are running the latest released (not beta) version of kix? |
||||||||
|
|
|||||||
Quote: Nope the $rc gets set by WriteLine. It will be 0 if writeline works. Quote: An error file gets created by the 5 option when I open the file. 5 is the sum of 1 create if file does not exists) and 4 open for writing. There is a bug in my code because writeline will also set @error Sorry for that. If you put these lines just after each use command it should show something on the screen. Can you tell us what you see on the screen? All writeline lines can be removed. Code:
|
||||||||
|
|
|||||||
When I put those lines in, I see that all my operations complete (but then, I never had any problem). Is there an alternative to the WriteLine command that will not change the @ERROR so I can see why drives aren't mapping? |
||||||||
|
|
|||||||
RedirectOutput might be an option. |
||||||||
|
|
|||||||
I'll look at that. In the meantime, any thoughts on why drives might map successfully, but disappear (as in no longer visible in "My Computer") 10-20 minutes later? |
||||||||
|
|
|||||||
I have a test script setup now, and edited the script to deliberately fail on mapping a drive (wrong server name). I get a return error code of 0, even though there is no way the drive can map (and indeed the drive doesn't map). Any thoughts? |
||||||||
|
|
|||||||
There is a flaw in your logic. You use WriteLine() to write the error but WriteLine() will change @Error. You need to capture @Error to a var when it still holds the result from USE. |
||||||||
|
|
|||||||
Disappearing drives are the function of the server hosting the drive, not KiX. You need to address it at the server. |
||||||||
|
|
|||||||
I finally go the error report to work on a client workstation. The Error code was 0 and The Operation Completed Successfully, but the drive didn't map. |
||||||||
|
|
|||||||
In order to bypass the Writeline he mentioned, I went back to the Gosub. I get error files, but even though the drive doesn't map, the error code is 0 and it says the operation completed successfully. What would I look at on the server to diagnose this? |
||||||||
|
|
|||||||
Disregard my last. I see what you are talking about. |
||||||||
|
|
|||||||
Would this work to capture @ERROR ?: Code:
|
||||||||
|
|
|||||||
I've been looking at the server trying to determine what would cause it to "pull" someone's mapped drive. Online sources suggest that it might be a licensing issue, but the "server" in question is a NAS, and shows a per-server concurrent connection limit of 9999, which I am quite sure we are nowhere near hitting. Two other factors are that the disappearing drives seem to affect only a small percentage of my user base, and prior to switching to KiX, I never heard any reports of this issue. Since the only thing that has changed in my environment is the method of mapping drives, I have to assume that the two are connected somehow, whether XP or 2003 has some issue with how KiX passes the Use command through the network, or something in how my script is written, or some other more obscure issue. Since KiX has been around so long, the fundamental principle is no doubt sound. I just need to narrow down the possibilities. |
||||||||
|
|
|||||||
Well... the server side setting I was talking about is http://support.microsoft.com/default.aspx?scid=kb;EN-US;297684 If you were mapping drives with the DOS USE command, the persistent setting may have been on by default. KiX USE does not follow the current persistent setting. |
||||||||
|
|
|||||||
The problem I am having is not the "red X" issue. In my case, I have users reporting that the mapped drive literally disappears from their "My Computer" windows. |
||||||||
|
|
|||||||
Then my guess is that you were making them persistent before and that there is some sort of network or NAS reliability issue at play here. |
||||||||
|
|
|||||||
this is totally usual case (seen it many times) but the reason for it seems to be unknown for all. tweaked even the timeouts on server and client back then, when tried to figure it out. it only happened on some xp clients, so it was left unsolved. |
||||||||
|
|
|||||||
From what I can tell, it would seem to be tied to the user, not the workstation. I have roaming profiles in my environment, so I can move users at will. I had a couple of them log into different machines this morning, and they still didn't get their drives. Any thoughts on what in a user profile might prevent them from running the executable? I know it isn't running because I am not getting error logs from them, although I am getting logs from others. |
||||||||
|
|
|||||||
one word to your code : Quote: syntactically isn't correct as NOT isn't a conditional operator but a logical one and will cause the script to die on an unhealable "error in expression" in the case @error is anything else than 0 (At least that's I think it will do) This one would fit better: Code:
or even Code:
as this will evaluate a true condition if @error is anything else than 0 |
||||||||
|
|
|||||||
Quote: Make up your mind. What is it? They get drives that disappear or they don't get anything? Quote: Which problem are we chasing? |
||||||||
|
|
|||||||
How do you change the timeouts? I have one particular drive that I know is timing out for some clients (large drive with poor directory structure). If given enough time, the drive will come up, so I need a way to make the client wait for that drive to map. |
||||||||
|
|
|||||||
Lighten up, Francis... I am seeing both problems. On some clients, the script doesn't appear to be running at all (they may not even be calling the executable, I haven't been able to tell yet). I am also getting reports from a small number of clients where the drives disappear from their "My Computer" after login, although they do map initially. |
||||||||
|
|
|||||||
I just recently changed to @error<>0. I found that just @error was sometimes reporting error 0 (though that may have been my scripting). Thank you. |
||||||||
|
|
|||||||
Still having these two problems: Some users are not getting mapped drives when they log in. They don't seem to be running the script automatically. The errorlogging built into the script seems to be catching problems, so I know it works. These users aren't even generating logs, so I am assuming they aren't even getting to the executable for some reason. So that's problem One. Problem 2 is that some users get their mapped drives ok, but a short time later the drive disappears from the network drives section of their My Computer. They can't access the drive at all, so I know it isn't just that the drive is not visible, it is actually not mapped anymore. Anyone have any idea of what might cause either of these two? I have seen articles/posts elsewhere on the web similar to my problem One, though never any solutions. I have not seen anything like problem 2. |
||||||||
|
|
|||||||
the problem one sounds like their gpo logonscript setting is wrong. or where ever you set your logonscript. at least reading your text sounds like, the script never run on these dudes. the problem two is a real problem and it has been discussed before. don't remember any solution posted ever anywhere though. |
||||||||
|
|
|||||||
1. Did you explore the Fast Logon Optimization feature? 2. My guess is that you were making them persistent before and that there is some sort of network or NAS reliability issue at play here. Did you try making them persistent again? |
||||||||
|
|
|||||||
Well the problems you appear to be having will more than likely trace back to some sort of setup, or configuration issue with Active Directory otherwise most of us would be having a similar issue. Please use the information below to help you locate tools and articles to help assist you in tracking down possible network issues. If there is reliability issues with the network then the diagnostics should hopefully show that too unless it is very sporadic which doesn't seem to be the case since you report that users have the issue often. A possible quick check that might reveal something is to check the Event logs on the client for issues with logon and policies and hopefully that might show something obvious. If not then you need to start doing some basic network and AD diagnostics to see where the issue resides. See the bottom of the post for Tool Downloads that may be required for dianostics work. Domain and Forest Trust Tools and Settings http://technet2.microsoft.com/WindowsSer...3.mspx?mfr=true
Network Services Management Support Tools http://technet2.microsoft.com/WindowsSer...3.mspx?mfr=true Other possible areas to check out Replication Does Not Work After Upgrading to Windows 2000 http://support.microsoft.com/kb/249261/ How To Diagnose and Test TCP/IP or NetBIOS Network Connections in Windows Server 2003 http://support.microsoft.com/kb/323388 Group Policy Home Page http://www.microsoft.com/windowsserver2003/technologies/management/grouppolicy/default.mspx Group Policy Troubleshooting Updated: March 02, 2005 http://technet2.microsoft.com/WindowsSer...3.mspx?mfr=true Troubleshooting Group Policy application problems (2000) http://support.microsoft.com/default.aspx?scid=250842 Troubleshooting Group Policy in Microsoft® Windows® Server (document download) http://www.microsoft.com/downloads/detai...;displaylang=en Active Directory Operations Overview http://www.microsoft.com/technet/prodtec...de/default.mspx Active Directory Operations Overview - Troubleshooting Active Directory—Related DNS Problems http://www.microsoft.com/technet/prodtec...t1/adogd10.mspx Active Directory Operations Guide Appendix A - Tasks Reference This appendix lists all tasks, and pointers to their associated procedures, in alphabetical order. You can build tear sheets for your operations staff by cutting and pasting procedures into a separate document. These procedures can be part of an operations task assigned to an operator, or part of a task to troubleshoot an Active Directory component. http://www.microsoft.com/technet/prodtec...2/adogdapa.mspx Active Directory Operations Guide Appendix B - Procedures Reference This appendix lists all procedures in alphabetical order. You can build tear sheets for your operations staff by cutting and pasting the task and its procedures into a separate document. http://www.microsoft.com/technet/prodtec...2/adogdapb.mspx NBLookup is a command line diagnostic tool that uses the User Datagram Protocol (UDP) to send NetBIOS name queries to Microsoft Windows Internet Naming Service (WINS) servers http://support.microsoft.com/kb/830578/ Windows 2003 Tool DOWNLOADS Windows Server 2003 Resource Kit Tools 12MB (DNSDIAG, REGINI, ROBOCOPY [XP010], SHOWACLS, etc...) http://www.microsoft.com/downloads/detai...;displaylang=en Windows Server 2003 Resource Kit Tool Updates http://www.microsoft.com/windowsserver2003/techinfo/reskit/tools/default.mspx Windows Server 2003 Service Pack 1 32-bit Support Tools 5.3MB (DCDIAG, NETDIAG, NETDOM, NLTEST, XCACLS, etc...) http://www.microsoft.com/downloads/detai...;displaylang=en Windows Server 2003 Service Pack 1 Administration Tools Pack 4/28/2005 http://www.microsoft.com/downloads/detai...;displaylang=en Sonar.exe: File Replication Service (FRS) Status Viewer http://www.microsoft.com/downloads/detai...;DisplayLang=en Microsoft ® Windows Server ™ 2003 Performance Advisor http://www.microsoft.com/downloads/detai...;displaylang=en Group Policy Inventory (GPInventory.exe) http://www.microsoft.com/downloads/detai...;displaylang=en Group Policy Management Console with Service Pack 1 http://www.microsoft.com/downloads/detai...;DisplayLang=en |
||||||||
|
|
|||||||
I turned off Logon Optimization. We have roaming profiles, so it should be off in the domain anyway. I have also explicitly mapped the drives persistent. So far that hasn't solved the problem. I doubt that the NAS is the problem, as it is brand new. It could be network, but we have been revamping the network lately, so we have been paying particular attention to network performance. That's partly why this is so frustrating: the infrastructure is pretty close to optimum. Even AD seems to be working well. To have this kind of random glitch is inexplicable. |
||||||||
|
|
|||||||
Well run DCDIAG and NETDIAG and report back. They are quick easy commands to run. Maybe try isolating some test users WITHOUT the piece of junk roaming profiles. Your choice, but dang I dislike roaming profiles and glad I've not had to work anywhere with them. Doing some basic tests just has to reveal the issue. If you have to get rid of the roaming profile for testing a couple users, run just a batch file to do the mapping and see what you get. |
||||||||
|
|
|||||||
So, since I have seen posts concerning users who don't run the script, and you have seen the issue where drives map, but then drop out later, and neither of these problems seems to have a solution, I've got my work cut out for me. I checked those users, and all seem to have the logon script mapped appropriately. I know for a fact that the script and the executable all replicated to all domain controllers. I'm going to go digging through ADSIEDIT to see if I can see anything wonky about the logon script in their actual user objects. There may be a hint there. Unfortunately, I don't have much longer to futz around with KiXtart. The mapped drives these users aren't getting are necessary for an in-house application to function. If I can't get it working within the next day or so, we will have to look at another solution. |
||||||||
|
|
|||||||
Well you can look into ADSIEDIT but if you have that type of problem then someone has been screwing around where they should not have. basics, basics, basics. Why look for the exotic first? |
||||||||
|
|
|||||||
I ran DCDIAG and NETDIAG, and all tests were ok. Nothing seems to be broken. I will track down one or two clients and see what if anything their event logs say. |
||||||||
|
|
|||||||
Sorry,first off - never got the info how you call your script. Second - the timeouts that are occuring, check your settings for timeouts and increase 'em, that is what I think was A solution Jooel to that problem (have seen it in one of our own old domains, but wasn't part of setting it up or anything - nor fixing it ). Third - check dns/wins resolving, perhaps this can be one faulty factor. Forth - Good luck . |
||||||||
|
|
|||||||
The script is being called by entering the executable name directly in the logon script field in ADUC on the profile tab. Someone will have to educate me on where the timeout settings are. I am looking into the possibility, at least regarding the script never running, that there is a problem with the computer account. I am having the machines removed from the domain, their accounts deleted, and then re-added to the domain as new names. I will see if this resolves the not-mapping issue. Then all I have to do is figure out the "drives get mapped, then disappear" problem. |
||||||||
|
|
|||||||
If the computer accounts were a problem hopefully you'd have seen "something" in the event logs. If worse comes to worse you can also do a network trace on the system and see what's happening. |
||||||||
|
|
|||||||
I know batch files work to map the drives, since that is what we were using prior to KiXtart. We switched so we could have a more unified environment, with a central point from which to manage network resource usage. Therefore the difference has to be KiXtart, as I didn't change anything else at the time I implemented it. The old .bat files were just a bunch of net use statements, without even a /delete to clear out old mappings. Unfortunately, we have to have the roaming profiles, as a large percentage of our user base changes desks regularly (sales guys, who get moved to keep them from getting in a rut). Especially since we have a couple of buildings, it makes moving far easier when the PCs can stay plugged in and set up. Actually, the only issue we have had with them is that sometimes the users don't listen when we tell them not to keep craploads of files in their My Documents. As long as the profile stays under 20-30MB, it works pretty well. Having an all XP/2003 environment probably helps a lot. |
||||||||
|
|
|||||||
Any reason why you cannot now SHELL out to the NET USE cammand that worked so well for you? |
||||||||
|
|
|||||||
By SHELL out, do you mean use KiXtart to call a .bat file? |
||||||||
|
|
|||||||
No, I mean: Shell 'net use this that whatever' |
||||||||
|
|
|||||||
hmm... so, you have kixtart called directly from the user script field or do you have a batch file calling for the kixtart? also, what is the antivirus solution on those failing computers? |
||||||||
|
|
|||||||
btw, if you call open, it will reset the @error value (or at least it should). so, as example in your original post: Code:
this will always give you succesfull (error = 0) return, if the file opens ok. to get the real error to the output, use something like: Code:
|
||||||||
|
|
|||||||
Got it, thanks. I'll see if that helps. |
||||||||
|
|
|||||||
Kix is always called directly from the script field. We have Symantec on all workstations in the environment. |
||||||||
|
|
|||||||
I caught that as well, and put @error into a variable so I could capture it. |
||||||||
|
|
|||||||
let us know, if you can find anything... |