|
I've been tasked with trying to determine the reason for slow logins in our computer labs yet I'm currently up a creek in terms of tools to use. I've been googling up and down trying to find something that can give me relevant info on when and what is loading when a user logs in (in the hopes of finding something that is bogging everything down). Normally I'd just go and uninstall programs one by one to see where login time reduces dramatically but with multiple lab setups (hardware and software wise) I'd be doing that until the end of the year (and will be if I don't find something better). Currently a Novell/AD setup running Windows XP SP3 as our base with software varifying from Catia to CS4 to SPSS (I'm going to guess, all three of these are the heavy hitters). If there are any fancy tools (free, University has no $) that can take advantage of Novell (leaving that soon I hear, woo!) or a domain environment I'm all ears. Stand alone programs are also totally fine, I just need something I can use that keeps the info consistent.
|
| # ? Nov 02, 2009 23:48 |
|
Fatal
|
|
| # ? Nov 22, 2009 10:48 |
|
|
perfmon.exe will already get you quite far. My personal first suspect would be a network bottleneck though.
|
| # ? Nov 03, 2009 00:13 |
|
|
The Novell client will copy the "Default User" profile to the newly created local user directory. The longer this takes, the longer the login box stares at you. I ended up taking ownership of a 37 server, 14 site, 30,000+ object Novell network at a college and it was a nightmare to get it all fixed. Endless nights flowed into the next day(s) and I ran dsrepair more times than I can even remember. Check the size of the "Default User" directory, ex "C:\Documents and Settings\Default User". Try copying it, manually, somewhere else, like say your desktop. How long does this take, if it's about the time of a logon, then you've found your bottleneck. We worked hard to keep this profile directory as small as possible but that's hard when Visual Studio wants to put 1 GB of help files in it and AutoCad likes to put zillions of templates in there or Oracle dumps the entire repository of "Forms and Reports" in there. Otherwise, where are you slowing down? It's important. Does it take forever to find the context? (The little pulsing icon just goes back and forth when you tab/click to the password field). You've got network congestion or your partitions are not setup very good. How many servers are there to contest "who's in charge". This is hard to get right and is highly dependent on your network size and WAN (if applicable). Having no local server, or one that is not partitioned correctly, will screw you over here... and it gets worse as this "bleeds" into the next paragraph's symptoms. You may even need to re-structure how you've organized your tree layout and this is a bitch. Do the username/password fields grey out but stay on-screen for the "length" of the login? Check for disk activity, this is the profile being created (this has a finite amount of time, try making a new, local user manually and time how long this takes). Also, the profile copies at this point. ZenWorks makes this worse as it adds policies to the mix. Check those as well. If you get your background image and logon script box, and it takes it forever there, go back and re-check your tree partitions and verify your servers are able to respond in a timely manner. 7ms over a T1 seems nice but really becomes a problem when 20 workstations are all taking a few megabytes of traffic to login. Again, do you have a local server? Those are the 3 largest issues that I can really think of that will slow you down aside from your install of Netware is hosed or you have hardware failures that no one's checked on in months.
|
| # ? Nov 03, 2009 01:21 |
|
|
Turn on userenv and winlogon logging, both of which I believe will give you timestamps along with an understanding of what's going on. Granted, it's been years since I've been in a Novell environment so I'm not sure how much of that process will show up. Oh, and verbose logon status messages can give you a quick hint without having to dive into logfiles right away.
|
| # ? Nov 03, 2009 01:24 |
|
|
Microsoft used to make BootVis that would have been perfect for this. It looks like it has been discontinued but perhaps you can scrounge up a copy on the web. I used to have a copy on my flash drive but I cant seem to find it. It gave a nice readout of the load times (and possibly timeouts) of all the components of the boot process. EDIT: go reading comprehension, you are looking at login not boot. oops. SchoolBus fucked around with this message at Nov 03, 2009 around 01:40 |
| # ? Nov 03, 2009 01:37 |
|
|
SchoolBus posted:Microsoft used to make BootVis that would have been perfect for this. It looks like it has been discontinued but perhaps you can scrounge up a copy on the web. I used to have a copy on my flash drive but I cant seem to find it. It gave a nice readout of the load times (and possibly timeouts) of all the components of the boot process. Keep in mind BootVis is a rather useful tool, though.
|
| # ? Nov 03, 2009 03:28 |
|
|
Turn on verbose logons either in the registry or local policy and you can see some extra info on what is going on, especially if it is loading a DLL or something and it is hanging up.
|
| # ? Nov 03, 2009 03:56 |
|
|
Try process monitor? Turn on boot logging, restart the system and save the boot log to someplace, then you can use the filters in procmon to get rid of all the crud before the login process. I believe on a standard XP installation you'd look for something like the last instance of winlogon.exe reading hklm\software\microsoft\windows xp\currentversion\winlogon\forcefriendlyui registry key and filter out anything prior to that (Don't know if Novell will change this or not).
|
| # ? Nov 03, 2009 11:28 |
|
|
Chro posted:Check the size of the "Default User" directory, ex "C:\Documents and Settings\Default User". Try copying it, manually, somewhere else, like say your desktop. How long does this take, if it's about the time of a logon, then you've found your bottleneck. I'm pretty sure this is the root cause. Context lookups don't take any time (1-2seconds) and neither do drive mappings (unless one of the side colleges network drives goes down, in which case Novell takes *forever* to timeout). You'd think that Novell could do something neat with symlinks or something similar to solve copying problems (copy/save on change, not by default), but then again, it is Novell.
|
| # ? Nov 03, 2009 18:59 |
|
|
Fatal posted:
This could be part of it, eDirectory might be the cause too. If the login script has a lot of includes that refrence objects on different partitions that can cause issues, a lot can be done on the eDir side to fix a lot of log in issues. Also if you are in charge of the Novell side of the house, get the hell off of Netware, the Linux version of NSS and eDirectory(this more so) is much faster, and 64 bit. EDIT: teh SwimNurd fucked around with this message at Nov 03, 2009 around 20:58 |
| # ? Nov 03, 2009 20:55 |
|
|
SwimNurd posted:Also if you are in charge of the Novell side of the house, get the hell off of Netware, the Linux version of NSS and eDirectory(this more so) is much faster, and 64 bit.
|
| # ? Nov 04, 2009 04:28 |
|
|
Aunt Beth posted:I've only ever run NDS on Windows or Netware. Do you know how it performs on Windows vs Linux servers? Only in the lab, it is significantly faster on Linux. A few years ago at Brainshare I saw a graph for a 10m object tree for each version of eDirectory, Windows performed the worst of the bunch. Why people would run eDirectory on windows is beyond me, Novell doesn't even recommend it.
|
| # ? Nov 04, 2009 06:13 |
|
|
SwimNurd posted:poor windows performance
|
| # ? Nov 04, 2009 09:50 |
|
|
Chro posted:The saddest part of this is that there really is no reason for this. Novell just likes to make really terrible software. They have an awesome idea, but the execution is just atrocious. Not to flame but eDir still out performs AD.
|
| # ? Nov 04, 2009 14:02 |
|
|
SwimNurd posted:Not to flame but eDir still out performs AD. A better thing for me to say would be: unfortunately there's not much choice and the choices that are there aren't very good but get the job done... for the most part.
|
| # ? Nov 04, 2009 21:29 |
|
|
Is it time for a general Novell questions megathread?
|
| # ? Nov 04, 2009 21:44 |
|
Rate Thread:
