Windows Thread, kix script not running all the time in Technical; Hi everyone,
I have been working on a problem with Microsoft since about October of 2007 and I've pretty much ...
-
27th February 2008, 11:12 PM #1 kix script not running all the time
Hi everyone,
I have been working on a problem with Microsoft since about October of 2007 and I've pretty much given up that I will get it solved so I'm turning to you all for suggestions.
Here's the problem. Our students (10,000+) logon and some students find out that they are missing their mapped drives and/or printers and/or homepage setting. This happens to about 5 - 10 students per site (21 sites) per day. If you do the math, this isn't happening to that many students percentage-wise but it is very annoying and frustrating for students and staff. As a part of the logon process, we setup a Group Policy that calls out a bat file that runs the kix script that assigns mappings, printer and homepages based on group memberships. There aren't any problems with the kix script or it wouldn't work for anyone.
All of our students use mandatory profiles. We have 4 domain controllers running W2K3SP2. The kix executable, kix config file and bat files resides in the netlogon share that is replicated amonst all 4 domain controllers. The mandatory profile also resides in the netlogon share. The last bit of information is that the workstations are XPSP2 and the workstation are all Dell Optiplex 260-755 models.
Again, I've been working with Microsoft on this issue since last October. If anyone has any ideas, I would be very grateful. Thanks in advance for any ideas.
-
-
IDG Tech News
-
27th February 2008, 11:38 PM #2
- Rep Power
- 12
Windows implementing a slow logon? Whats the network infrastructure like? Could it be overloading?
Try a solution like a super mandotary profile that will log the user off if the profile cannot be properly loaded.
Craig
-
-
28th February 2008, 12:11 AM #3 Welcome kubasa
Big question!
Have you any evidence like errors produced on the bad logons?
A break in communication can cause some GPOs to not apply is all I can think. 5 sites per server - what's the geographical spread/ network quality like?
Don't suppose you can list the blind alleys you've already found?
-
-
28th February 2008, 10:00 AM #4 How many DC's are we talking about?
How many DNS servers?
Definately look at network traffic for bottlenecks. I presume this happens at the busiest times?
Seem to recall there is a "wait for network" registry fix that we applied here to solve a similar problem.
-
-
28th February 2008, 10:43 AM #5
- Rep Power
- 11
Whats that fix called? Ive been told about that fix in the past, but could never find it?
-
-
28th February 2008, 11:04 AM #6 Erm.... rummaging through notes....
Pretty sure it was this.....
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\Tcpip\Parameters]
"TcpTimedWaitDelay"=dword:00000300
Save as "whatever.reg"
-
-
28th February 2008, 11:08 AM #7 Is the logon script running in a visible window? A problem we used to have when we used a logon script similar to yours was that people would think logon was slow, not know what the command window was for and just close it - leading to random drives not being mapped.
The other thing you could do is add some debugging logic to the script so it writes a log of the steps it's following - if you then have a failure you can try and find out if the script is not running at all or failing at a particular point. One of the things which I *think* we sometimes have is that if a server is busy, it won't respond to the mapping request quickly enough and so it fails.
Another thing you could try is:
Code:
attempts=1
do
Map drive
attempts=attempts + 1
loop until drive mapped or attempts > 3
- choose a number to suit. It obviously slows down even a "good" logon a bit (but it wouldn't be horrendous) and might help to fix the odd problems
-
-
28th February 2008, 11:52 AM #8
- Rep Power
- 14
Is there anything at all in the event log on the clients that this is happening with?
-
-
28th February 2008, 11:53 AM #9 
Originally Posted by
srochford
Is the logon script running in a visible window? A problem we used to have when we used a logon script similar to yours was that people would think logon was slow, not know what the command window was for and just close it - leading to random drives not being mapped.
If it's Kixtart, you can add "Break On" to stop them closing the script window.
-
-
28th February 2008, 12:14 PM #10
- Rep Power
- 11

Originally Posted by
GlennT
Erm.... rummaging through notes....
Pretty sure it was this.....
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\Tcpip\Parameters]
"TcpTimedWaitDelay"=dword:00000300
Save as "whatever.reg"
Thanks.
I'll have a play with that when i get the time.
.
-
-
28th February 2008, 08:07 PM #11 I would be tempted to make the batch and kix files both do some basic logging in the short term to see if either or both are running at all. I suspect that if they sometimes get some, but not all, settings set then the kix script is running for everyone.
In kix, you can run an action and assign the return code to a variable. I think the syntax is:
Code:
$ErrCodeDefPrint=SetDefaultPrinter($strPrinter)
You can also write events to the Windows event log, so you could follow each line as above with something like:
Code:
$ErrCodeDefPrint = "Default printer mapping result: " + $ErrCodeDefPrint
$RC = LogEvent(4,1004,$ErrCodeDefPrint,'KiXtart')
You can use this dll to make the events a bit easier to read, but it should work ok without.
Then you just need to examine the event viewer for an affected session to see what failed and how.
-
-
4th March 2008, 11:29 PM #12 Hello and thanks for all the replies. I was out of town and unable to check what suggestions had been made. In any case, the problem has been resolved. The problem was with one of our 5 domain controllers. When students would login and authenticate against this particular domain controller, it wouldn't run the kixscript for whatever reason. Everything appears fine and there were no errors on the DC but when we shut it off and then just let the other 4 take over, we didn't have any errors. It seems pretty obvious now (after the fact....). Again, thanks for all of the suggestions.
-
SHARE:
Similar Threads
-
By Mike-j in forum Scripts
Replies: 3
Last Post: 28th February 2008, 07:22 PM
-
By mullet_man in forum General Chat
Replies: 45
Last Post: 1st September 2007, 01:57 AM
-
By richard in forum Scripts
Replies: 11
Last Post: 29th May 2007, 07:39 PM
-
By Samson in forum Scripts
Replies: 5
Last Post: 10th May 2007, 03:29 PM
-
By NetworkGeezer in forum Windows
Replies: 7
Last Post: 1st June 2006, 05:13 PM
Thread Information
Users Browsing this Thread
There are currently 1 users browsing this thread. (0 members and 1 guests)
Tags for this Thread
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules