LSASS.exe process near 100% usage

J

JA

i have a windows 2000 advanced server. it is a domain controller, as well as
a
fsmo roles holder and a dns server. i have 2 other domain controllers and a
secondary dns server.

at least once a week, this server's cpu usage (in task manager) goes near
100%
and the culprit thats taking up so much cpu usage is LSASS.exe. why is that?
when i reboot, its okay again.

i believe that process handles logons? not really sure. can anyone tell me
why
this process goes 100% on occassions and i need to reboot? thanks.
 
S

Super-G

That is totaly normal...

you should not reboot, The CPU will go back to normal
after a few minutes.

This is caused by various configurations. If you har
using MDMT, or if you have lots of account in the
adminitrative group, an exchange server in your
orginazation cal also cause this. etc ....


There are various articles in technet that describes the
issue.

Later
 
D

David Everett [MSFT]

What Service Pack is installed on the DCs?

Are you getting any errors in the Directory Services event logs of the DCs?
If so, what is the Event ID, Source and Description of these events?

If this DC is the only one that has the problem and others do not, try
Transferring the PDC role to a different DC and see if the CPU spike moves
with the role.

What OS do the client machines have installed?

Is SIMS or another third-party solution that works like SMS in the
environment?

Follow the steps outlined in 251343 on the problem DC and see if the "DS
Security Propagation Events" counter returns to baseline in perfmon or if it
stays spiked. If the process stays spiked you may need to examine
membership of Protected Groups.

251343 Manually Initializing the SD Propagator Thread to Evaluate Inherited
http://support.microsoft.com/?id=251343

811172 Lsass.exe Spikes at 100 Percent CPU Usage and Then Shows a Typical
Load
http://support.microsoft.com/?id=811172
 
J

JA

i have windows 2000 service pack 4 installed.

two out of three DC's have this problem where the lsass.exe process would
go to near 100% usage.

the client machines are either xp pro or windows 2000 pro.

no sims or sms installed.

i seem to be getting a lot of the following event log errors:
event id: 1000
source: userenv
desc: windows cannot determine the user or computer name. return value (14)

and
event id: 213
source: licenseservice
desc: replication of license information failed because the license logging
service on server servername.company.com could not be contacted

that server has been taken out of the domain and cannot be put back
into the domain. i guess it probably wasn't gracefully demoted? how would
one correct that and i'm not sure if that could be the cause of the
lsass.exe
to spike up like that.
 
J

JA

nope, not rebooting is not an option. if i don't reboot,
no one can access any shared drives. and it never
goes back to normal in a few minutes.

it will stay at close to 100% for quite some time. i don't
know how long because the longest i went was 1 day
and i was forced to reboot because no one could access
anything.
 
D

David Everett [MSFT]

The two DCs that have the problem, are they Global Catalog servers, and the
one that is trouble free is it not?

Try pulling the network cable from the back of the server when the spike
occurs and let me know if the spike remains or goes away when the cable is
removed.

Do the DCs ever reboot on their own?

Are the DCs getting any Errors or Warnings in the Directory Services event
log? If so, let me know the Event ID and Description information.

The DC that was not gracefully demoted, was it a FSMO Role holder? To find
out you can run "netdom query fsmo" on the good DC and verify that it show
all 5 FSMO roles on DCs that are still in the domain. If the DCs still
think that server holds a FSMO Role you will have to Seize the role to a
good DC if that server has gone away for good. Also, if the DC that was
removed from the domain was not gracefully demoted you should still see it
in the Domain Controllers OU. If it is still there then you should clean it
out of metadata by following the steps outlined in 216498.

216498 HOW TO: Remove Data in Active Directory After an Unsuccessful Domain
http://support.microsoft.com/?id=216498

You can disable License Logging Service on all DCs. This service is being
disabled by default in Windows Server 2003 and will be removed from the OS
following that.

824196 Description of the License Logging Service in Windows Server
Operating
http://support.microsoft.com/?id=824196
--
David Everett
Microsoft Corporation

This posting is provided "AS IS" with no warranties, and confers no rights.
 
D

David Everett [MSFT]

Does the spike happen at particular time intervals, like every 12 hours?

Were there any schema modifications recently or have you done any large
migrations recently?
--
David Everett
Microsoft Corporation

This posting is provided "AS IS" with no warranties, and confers no rights.
 
J

JA

hi david...

yes the two DCs that have the problem are global catalog servers. the third
one
that was trouble free, i just made it a global catalog server just the other
day because
i thought i read somewhere that i didn't have enough GC's thats why the
lsass.exe spike.
so now the third DC is also a GC.

i'll try and pull the network cable the next time i get a lsass.exe spike. i
did
have one late yesterday afternoon but i had to immediately reboot the server
because users needed to get to shared drives.

no the DC's do not reboot on their own however, it may have at one point
because
i noticed that a program that i have that tracks uptime always used to
reset.
but i don't think they reboot on their own now.

the DC that was not gracefull demoted was never a FSMO holder. i ran
netdom query fsmo and the role holder now is one of the DC's that is
currently in the domain. how do i look at the domain controller OU?
when i am in the management console, under active directory users and
computers and then domain controllers, that old server does not appear.
but i think remnants of that server is still in active directory as the
licensing
service is still referencing it.
 
J

JA

it seems to happen about once a week or so... every 7-10 days.

one of my DC's who was the FMSO role holder had a major problem with
2 of the 3 hard drives and because you can rebuild the drives with only
one good drive in a raid-5 configuration, i had to basically wipe that
server
out and restore from a backup. but before i scratched the drives i did
transfer the fsmo roles to another DC which is one of the one's that is
giving me the lsass.exe spike problems. not sure if that helps. maybe i
should
re-transfer the fsmo roles back to that original server?
 
D

David Everett [MSFT]

By any chance do your workstations have a prefix on the computer names that
match the domain name?

For example you domain is called Domain and your workstations are called
Domain-wks1, Domain-wks2.
--
David Everett
Microsoft Corporation

This posting is provided "AS IS" with no warranties, and confers no rights.
 
D

David Everett [MSFT]

If you open Eventvwr.exe on one of the DCs and you click on the Directory
Services log and then right-click the Directory Services log and choose View
Filter and enter the number 1168 in the Event ID: field.

Click OK and see if you have any of these events double-click on it, click
the Copy button just below the down Arrow and paste the event in a reply
post

Repeat this step and filter for Event ID 1173 and see if you have any of
these events copy this event into the reply post as well.

To turn off the filter of events just right-click Directory Services log and
choose View > All Records.

As for the DC that went way, see if it still has a Server object in Active
Directory Sites and Services under Sites > Default-First-Site-Name > Servers
--
David Everett
Microsoft Corporation

This posting is provided "AS IS" with no warranties, and confers no rights.
 
J

JA

okay i did that and there are no 1168's or 1173's. the only warning i have
is
1265 with description:
The attempt to establish a replication link with parameters


Partition: CN=Schema,CN=Configuration,DC=uhwo,DC=hawaii,DC=edu

Source DSA DN: CN=NTDS
Settings,CN=KOLEA,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configur
ation,DC=uhwo,DC=hawaii,DC=edu

Source DSA Address:
582c9280-9bda-48fe-913a-fa35766ad5a4._msdcs.uhwo.hawaii.edu

Inter-site Transport (if any):


failed with the following status:


The DSA operation is unable to proceed because of a DNS lookup failure.


The record data is the status code. This operation will be retried.

i then checked the active directory site and
services/sites/default-first-site-name/servers
and that server that wasn't demoted gracefully isn't listed. thats why i'm
not sure the
licensing service was still trying to contact that server.
 
D

David Everett [MSFT]

Can you download and run the DS version of MPSReports on one of these DCs?

When it finishes it will place a "servername_MPSReports.CAB file in the
%systemroot%\MPSReports\DirSvc\Logs\cab folder. If you like you can send
the CAB file to my temporary hotmail address (e-mail address removed).

The MPSReports utility can be downloaded from:
http://download.microsoft.com/download/b/b/1/bb139fcb-4aac-4fe5-a579-30b0bd915706/MPSRPT_DirSvc.EXE
--
David Everett
Microsoft Corporation

This posting is provided "AS IS" with no warranties, and confers no rights.
 
J

JA

okay i sent this output to your hotmail address. please let me know what you
find.

also, the other server's lsass.exe service is spiking. i pulled the network
connection
as you suggested in an earlier message but its still at 90-99%
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads


Top