Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1535
  • Last Modified:

DSAMAIN.exe runs 50% of CPU

On NT 4 SP6 and EXchange 5.5 sp4 in an organization with 4 sites, my DSAMAIN.exe is running at 50% of my cpu all the time.  Mad.exe, store.exe are both running fine.   Everything works, Priv, pub & dir.edb are all consistent.  I have mcafee & groupshield running and have found no virus on the computer. Any advice would be great.  Thanks.
0
gmacmaster
Asked:
gmacmaster
  • 8
  • 6
1 Solution
 
kevalaCommented:
1. Have you ran:   Eseutil /g /ds /v/x >checkdir.txt
 
You can run this from any directory at a command prompt.
NOTE: the directory service must be stopped.

This will check the directory database (in verbose mode with details) for corruption, and dump the result to a text file called checkdir.txt.

Let me know what the results are from the corruption check in the dircheck text file.

If the directory database is corrupt, my suggestion would be to restore the Directory ONLY from backup, not much you can do with a corrupted directory, MS does not recommend repairing it since there is no logical fix for it.

2. Make 100% sure that you are not scanning the Exchsrvr folders with your Anti Virus...this will cause the symptom you are describing. IF you are running file/folder level antivirus on the Exchange server, try removing it completely and then restarting the server.

3. Will a reboot fix the problem? If so for how long? Will just stopping and restarting the directory service as opposed to restarting the whole server fix the issue? If it does, i would be pointing more towards AV -

Either way, it is probably corruption of the directory database, or anti virus.

P.S. - one other thing to try is seeing if the dsamain.exe spikes with a blank set of information store databases, this will eliminate the IS from the picture, but this one is a last resort, try the first two steps 1st.

Hope this helps!
0
 
gmacmasterAuthor Commented:
checking table "MSysDefrag1" (102)
          checking data
          checking index "TablesToDefrag" (103)
          rebuilding and comparing indexes
...................

Operation terminated with error -1206 (JET_errDatabaseCorrupted, non-db file or corrupted db) after 3.469 seconds.


Shutting down the service did not help.  When I reboot it 'fixes' itself for about 4 hours. Then it spikes again.   I have Mcafee 4.5 and Im not scanning any of the exchsrvr folders.
0
 
gmacmasterAuthor Commented:
btw, Thanks for your help,  you are the first person to give me any help, I've post in a couple different forms. Thanks.
0
Get your Conversational Ransomware Defense e‑book

This e-book gives you an insight into the ransomware threat and reviews the fundamentals of top-notch ransomware preparedness and recovery. To help you protect yourself and your organization. The initial infection may be inevitable, so the best protection is to be fully prepared.

 
vinnyd79Commented:
Do you have a good backup of dir.edb?
0
 
kevalaCommented:
hey gmacmaster, at this point, i would check for a good backup of the "directory service". Depending on what kind of software you use for backup, if it is third party, you must have the Exchange agent installed. Like, if you use Veritas, then Veritas will supply an Exchange agent to allow you to backup the Exchange databases with their software.

The reason for the reboot working is because the server is completely losing access to any reference of the corrupted page in the dir.edb - then it will take a few hours, but after a while the corrupted page will be accessed again causing the dsamain to spike.

The key thing to check for here is a backup of the "Directory Service" - not the actual file dir.edb -
Through your backup software, you should have an Exchange option, through the Exchange option you should be able to find two options for a restore (after catalog of course) - the Information store and Directory service. Be sure to ONLY restore the directory service. Of course you will want to restore from back before the issue occurred.

1. Stop the Directory service for Exchange
2. Rename all Dsadata folders to dsadataold (repeat this for all dsadata folders, you might have them on multiple drives if you ran performance optimizer to seperate the logs and the databases)
3. Create a new dsadata folder for each one renamed
4. Restore the directory service from a backup prior to this issue occurring.

The above way is Microsoft recommended so you are restoring to blank folders and you do not have any old files or logs getting in the way.

The good thing about restoring the directory from backup is that you do not lose emails, the directory is just the structure and info on mailboxes, connectors, DL's, etc...

If i am not being specific enough, just let me know and i will attempt to explain better.
But basically, it says right there,....-1206 - DB corrupted - it's time to restore from backup or rebuild the directory database.

If you don't have any kind of Exchange aware backup to restore the directory service from, just let me know and i will hook you up with the best way to rebuild the directory database.

Oh and your welcome for the help! Let me know if you need any more specifics...or if i missed something.
<-_->
0
 
gmacmasterAuthor Commented:
I don't have a good backup of directory services.  Can you please tell me how to rebuild the directory service?  I am looking on ms's site, but am having a little trouble,  do you know more specifically the 1206 error is?  
Thanks again!
0
 
kevalaCommented:
One thing you might actually try first, is defragging the directory database. Maybe the corruption is in the white space within the database. This should only take a few seconds, or minutes since usually the directory database is not that large.

First, once you stop the directory service, make sure the database is consistent.
1. Stop the directory service again
2. Run the following command
eseutil /mh "path to dir.edb" |more

You will look for the word "state" about 8 or 9 lines down - right next to it, it will say consistent, or inconsistent. The database needs to be consistent for any corruption check or defrag to work.

If the database is consistent, then proceed with a defrag, the defrag should not take long at all since the dir.edb is probably very small.
If consistent, make a copy of dir.edb, then run:
eseutil /d /ds       <--that will defrag the dir

Once the defrag has completed, then run the corruption check again to see if the corruption is gone.
Eseutil /g /ds /v /x >checktwo.txt

If you check consistency, and the state says inconsistent, then try starting and stopping the directory service to play the logs in, then get a gracful shutdown of the service.

If the database remains inconsistent, you might as well stop there.

~~~~~~~~~~~~
To rebuild the directory database, please answer the following questions:
1. What is the directory name of the Exchange "organization" and the Exchange "site"?
2. How many servers are in your Exchange site?
3. How many sites are in your organization?

Once you have answered the above questions, considering the defrag did not help anything, i will then give you the proper steps for rebuilding the directory database, but first i have to know how many Exchange servers and sites are in the picture here.
0
 
gmacmasterAuthor Commented:
I will try the defrag.   Last time I checked priv, pub and dir.edb were all consistent.  I will check again, to make sure.

The Answer to your question: my organization is called METRONET, there are four sites, Metromail, 19th_jdc, CTC, and PD. Mine is 19th_jdc. I have one server in my site, 19jdcmail1.The other three sites all have one server a peice.

Thanks again.
0
 
kevalaCommented:
Let's try the defrag first...then we'll plan for the rebuild....
0
 
gmacmasterAuthor Commented:
Okay..  I checked consistence of dir.edb, and it was consistent (I also check priv & pub consistent on both).   I then ran the "eseutil /d /ds" and got the error:

error 530 (JET_errBadLogSignature, bad signature for a log file)  My exchange directory would not start getting a 2140 error.     I tried replacing the dir.edb that I copied before the defrag and it didnt work,  returning a checksum error.  I had an older copy, stuck that in there and all my service came up.  

Exchange is now up,  but I couldn't preform the defrag, any ideas why?
0
 
kevalaCommented:
Yes, the answer to your question is....
After performing the defrag of the dir.edb, remove all log files and check files out of all dsadata folders. So the only thing you have in any of the dsadata folders is the dir.edb

The reason for the above error is because after performing a defrag of the dir.edb, it changes the database signature of dir.edb. The old database signature is hardcoded in the*.log files.

So, let's try the defrag again - if it completes, empty all dsadata folders leaving only the dir.edb. Then try to start backup.

The reason i did not mention removing the log files the first time is because this error only occurs sometimes and it did not dawn on me that it would happen to you.

But trust me, after a defrag, the DB signature changes, the database saw the logs in the dsadata folder which had the old DB signature and freaked out.

Try the defrag again, remove all files except dir.edb and try to startup again.
I know for a fact that was the problem.

Did the defrag complete successfully?
0
 
kevalaCommented:
Or, if you stop the directory and the dir.edb is consistent, just go ahead and move the log files out before doing the defrag - then see if we get the error :)
0
 
kevalaCommented:
How are we doing gmacmaster? Did the defrag do the trick?  
0
 
gmacmasterAuthor Commented:
That did the job! Sorry for my delayed reply,  my wife gave birth to my first son, I was out of the office.

THanks again for your help.

0
 
kevalaCommented:
CONGRATS!!! (and i'm glad to hear the defrag did the trick, it must've been some wacky "white space" the dsamain was trying to access for some reason)
0

Featured Post

Problems using Powershell and Active Directory?

Managing Active Directory does not always have to be complicated.  If you are spending more time trying instead of doing, then it's time to look at something else. For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why

  • 8
  • 6
Tackle projects and never again get stuck behind a technical roadblock.
Join Now