XADM: Cluster Machine Keys Prevent the System Attendant from Starting After Drive C on a Node Fails (329033)



The information in this article applies to:

  • Microsoft Exchange 2000 Server

This article was previously published under Q329033

SYMPTOMS

After drive C fails on a node of a cluster that hosts Exchange 2000 and the drive is restored (even from an image), the Exchange 2000 system attendant may not start when you fail over the virtual server to that node.

The following warning and error messages are logged in the Application event log:
Event Type: Warning
Event Source: MSExchangeSA
Event Category: General
Event ID: 9021
Description:
Microsoft Exchange System Attendant has generated
new security keys for Exchange server -server_name- .
Any passwords required by this server must be re-entered
using the Exchange System Management snapin

Event Type: Error
Event Source: MSExchangeSA
Event Category: General
Event ID: 9022
Description:
Microsoft Exchange System Attendant
encountered an error while
processing the security data for Exchange
server -server_name-

Event Type: Error
Event Source: MSExchangeSA
Event Category: General
Event ID: 9149
Description:
Microsoft Exchange System Attendant
failed to start Exchange
server -server_name- Error code 0x8009000f.

Event Type: Error
Event Source: MSExchangeSA
Event Category: General
Event ID: 1005
Description:
Unexpected error Object already exists. ID no: 8009000f Microsoft Exchange System Attendant occurred.


Task Scheduler may also stop responding, and you may receive the following error message:
AT - system cannot find the drive specified
Task Scheduler - 0x8009000f

CAUSE

This problem may occur if the Exchange 2000 system attendant cannot read the encryption private keys in the Rsa\Machinekeys folder on the node. This can occur for any of the following reasons:
  • The public key in the directory is corrupted (either intentionally or accidentally).
  • The Crypto container that contains the private key is corrupted.
  • Mad.exe (the system attendant process) does not have access to (permission for) the Crypto container.

RESOLUTION

To resolve this problem:
  • Locate the following folder:

    drive:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\Machinekeys

    Take ownership of the key files and grant permission to the account that has Exchange Full Administrator permissions and to the Administrators group. -or-

  • Re-create the keys:
    1. Locate any keys with the following name and entry:

      07a4f4a06b8bf781dcc2ed16529b8a04_b7f437dd-1ae0-4382-a8cd-dec434287809
      EXPWMGMT-bba7bd6d100e40ed9a62b6c8f3129089 RSA1H

      Rename this key, and then fail over Exchange 2000 to the node. The system attendant should start without generating any errors and create a new key.
    2. For Task Scheduler, the key file is different. Locate the following key:

      Application Data\Microsoft\Crypto\RSA\S-1-5-18\d42cc0c3858a58db2db376582

      Rename this key, and then create a new task to re-create the key. After you do so, Task Scheduler works.

Modification Type:MinorLast Reviewed:4/28/2005
Keywords:kberrmsg kbprb KB329033