Jump to content

Login Issue with Windows 2000


Recommended Posts

Hi All,

I work for a company that has close to 250 workstation users. Of late we have been having issues with our login process. This has been a progressively growing problem over the last 6 months but we have been getting closer to locating the issue. We are now at a point where we aren't certain how to progress. I'll give some background.

The site's workstations run on Windows 2000 Service Pack 4 and are kept current with Windows Update. Of course however should we find these updates to cause issue (as we have in the past with Outlook 2000) we remove them. Our servers are comprised of both Windows 2000 and 2003, also updated.

The domain is governed by Active Directory and we are using Kixtart (http://kixtart.org) as our login script utility. Here the script will build registry entries into the local user's registry, icons get copied over as shortcuts and the profile is built. It is probably worth mentioning the profile is roaming.

Basically we noticed some time ago that users were all having issue with the login command script stalling. Kixtart allows the administrator to verbosely relay information back to the end user about the login scripts progress. It was found after some time that the script appeared to be stalling on the icon copy process we have. The command is a simple:

copy "$vault\$Corp\*.*" "%userprofile%\Start Menu\1. Corporate\"

Please note $vault and $Corp are variables and are fine. The %userprofile% system variable is fine also and Kixtart has no issues reading these.

We found that when we accessed the $vault\$Corp\ directory - a hidden share on one of our domain controllers (not subject to replication) the icons were sluggish to load. After some time Explorer became responsive and the user's script continued fine. We observed that in Manage Computer for the domain controller hosting the share that all the icons were open (Read) by a single user, with other users locked on a same single file. I can only assume here that the user with all the files open has somewhat locked the files (although Manage Computer doesn't convey this) and subsequent users are being held up as a result.

Our team have located these problematic machines are found on all occassions they have completely locked up and required a hard reboot. Once the open files are dropped all other users continue to login fine. After the problem PC comes back online it is also fine. There doesn't appears to be anything in the Event Log and the PC logs in fine afterwoods for both client and server.

Please note also that the even taking Kixtart out of the equation and using a simple bat file with code below also locks up.

CLS

DEL "%userprofile%\Start Menu\1. Corporate\*.*" /Q

COPY "\\Server3\Vault$\Application Menus\Corporate\*.*" "%userprofile%\Start Menu\1. Corporate"

We have attempted to determine if the issue was with:

- Anti-virus software (McAfee) - remove C:\Documents & Settings\<user>\ local PC scanning, and Domain controller vault scanning

- Network Load - benchmarked network performance often and there's no unusual spikes

- Server Load - Server load varies and no consistency with occurance of event and non-event

- Time of Day - issue has occured various times of the day, even late at night when minimal staff on-site.

- Common workstations (model/make) - machine specifications varies allow all are HP

If anyone has any advice please let me know.

Link to comment
Share on other sites


One simple work around I can think of for the meantime would be to have your KiX script see if the shortcuts already exist, and don't attempt to copy them if they do.

If Exist("%USERPROFILE%\Start Menu\1. Corporate\shortcut1.lnk") = 0
Copy "$vault\$Corp\*.*" "%userprofile%\Start Menu\1. Corporate\shortcut1.lnk"
EndIf

If Exist("%USERPROFILE%\Start Menu\1. Corporate\shortcut2.lnk") = 0
Copy "$vault\$Corp\*.*" "%userprofile%\Start Menu\1. Corporate\shortcut2.lnk"
EndIf

It's a little more code but it shouldn't take but a few milliseconds longer to run (and should get rid of the pause if the shortcuts already exist thereby actually speeding up the logon process).

Have you noticed if it's one particular file or is it just that share in general? It's possible that your server may need to be defragged. Waaaay back in my early NT4 days we had a server (domain controller, email server, file server...wasn't my doing) that had a single 1GB SCSI drive in it. The drive was so fragmented that if you browsed it directly from a Win95 machine it would lockup the Win95 machine. This is when I found Diskeeper. A few days of running the (then) free version and things cleared up nicely. Back then it was a common misconception that NTFS didn't need to be defraged.

Edited by nmX.Memnoch
Link to comment
Share on other sites

Hey thanks for the advice. Unfortunately we will first delete all the icons and re-copy them over again. The reason for this is that we may remove a shortcut from the list.

With the fragmentation issue, nice thought. I admit we didn't think of this, however we also tried to move the share to another DC with the same result. However not to the same extent. It is possible both devices are in need of a defrag so I'll check this now.

If you have any other thoughts please let me know.

Thanks again

One simple work around I can think of for the meantime would be to have your KiX script see if the shortcuts already exist, and don't attempt to copy them if they do.

If Exist("%USERPROFILE%\Start Menu\1. Corporate\shortcut1.lnk") = 0
Copy "$vault\$Corp\*.*" "%userprofile%\Start Menu\1. Corporate\shortcut1.lnk"
EndIf

If Exist("%USERPROFILE%\Start Menu\1. Corporate\shortcut2.lnk") = 0
Copy "$vault\$Corp\*.*" "%userprofile%\Start Menu\1. Corporate\shortcut2.lnk"
EndIf

It's a little more code but it shouldn't take but a few milliseconds longer to run (and should get rid of the pause if the shortcuts already exist thereby actually speeding up the logon process).

Have you noticed if it's one particular file or is it just that share in general? It's possible that your server may need to be defragged. Waaaay back in my early NT4 days we had a server (domain controller, email server, file server...wasn't my doing) that had a single 1GB SCSI drive in it. The drive was so fragmented that if you browsed it directly from a Win95 machine it would lockup the Win95 machine. This is when I found Diskeeper. A few days of running the (then) free version and things cleared up nicely. Back then it was a common misconception that NTFS didn't need to be defraged.

Link to comment
Share on other sites

Indeed the original $Vault share's drive does need a good defragmentation, however the other server does not.

Admittedly over the last 5 days we've only had the issue occur 1-2 times. Prior to relocating the share it was happening 1-4 times daily.

Link to comment
Share on other sites

Hey thanks for the advice. Unfortunately we will first delete all the icons and re-copy them over again. The reason for this is that we may remove a shortcut from the list.

That's easy enough as well. :)

For instance, if you remove 'shortcut1' then simply comment out the code that copies it and then add a section to delete it if it exists on the target machine:

;;If Exist("%USERPROFILE%\Start Menu\1. Corporate\shortcut1.lnk") = 0
;; Copy "$vault\$Corp\*.*" "%userprofile%\Start Menu\1. Corporate\shortcut1.lnk"
;;EndIf

If Exist("%USERPROFILE%\Start Menu\1. Corporate\shortcut1.lnk") = 1
Del "%userprofile%\Start Menu\1. Corporate\shortcut1.lnk"
EndIf

If Exist("%USERPROFILE%\Start Menu\1. Corporate\shortcut2.lnk") = 0
Copy "$vault\$Corp\*.*" "%userprofile%\Start Menu\1. Corporate\shortcut2.lnk"
EndIf

;;If Exist("%USERPROFILE%\Start Menu\1. Corporate\shortcut2.lnk") = 1
;; Copy "$vault\$Corp\*.*" "%userprofile%\Start Menu\1. Corporate\shortcut2.lnk"
;;EndIf

You could even go ahead and put both lines in for a shortcut and comment out the line you don't need (note what I did with 'shortcut2' as an example). Once you get the slowdown issue figured you you can go even further and have the script check the date of the file in the share versus the date of the file on the workstation...that way shortcuts will only get copied if they're newer.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...