Exchange server generates event 1182 on Veritas Cluster (924199)


The information in this article applies to:

  • Microsoft Exchange Server 2003 Enterprise Edition
  • Microsoft Exchange Server 2003 Standard Edition
Source: Microsoft Support

RAPID PUBLISHING

RAPID PUBLISHING ARTICLES PROVIDE INFORMATION IN RESPONSE TO EMERGING OR UNIQUE TOPICS, AND MAY BE UPDATED AS NEW INFORMATION BECOMES AVAILABLE.

SYMPTOMS

Exchange 2003 cluster generates the following events every so often causing the node to fail over or stopping of Exchange resources on the virtual server:

	Event Type:   Warning 
	Event Source: MSExchangeIS 
	Event ID:     1233 
	Description: An error occurred. Function name or description of problem: 
                     ScHasServerExpired returned error Error: 0xbf69

	Event Type:     Error
	Event Source:   MSExchangeIS
	Category:       General
	Event ID:       1182
	Description:    Thank you for participating in the Microsoft Exchange Server beta 
program.
                        Your license to use this beta version of the Microsoft 
Exchange Server software has expired.
                        Contact Microsoft Corporation.


Unable to reinstall Exchange 2003 or the service pack.

Setup log returned:

ScGetCurrentFlavorOfSetupInstalled
Error code 0X80005000 (20480): An invalid ADSI pathname was passed


ENVIRONMENT: Exchange 2003 running on Veritas Cluster

CAUSE

When the Microsoft Exchange System Attendant (SA) starts up, it looks at items in the HLKM\System\CurrentControlset\Services\MSExchangeSA\Parameters registry hive to determine the version of Exchange. If it has problems during this process or does not find exactly what it is looking for, it defaults the version of Exchange to an expired Beta version. 60 minutes later, Exchange indicates the 'Beta has ended' and shuts down. This process is not the normal process for the Beta software, but is the default when entries in the above registry location become corrupted, missing, or are from another Exchange Virtual Server (EVS).

RESOLUTION

This is a known issue with Veritas Cluster.
The following steps are outlined in http://support.veritas.com/docs/276518

There are 3 possible methods to correct this issue. Following are the methods that should be used and in the order that they should be tried.

Method 1 - Restore the RegRep shared drive location from backup. This is typically the quickest method to resolve this issue.
  1. Confirm that a valid backup of the RegRep shared disk exists from a time before the corruption. If no backups exist, go to the next method of resolution
  2. Offline the problem EVS service group except for the VMDg and MountV resources used by RegRep
  3. Modify the RegRep resource RestoreLocally attribute to 'True' for this service group (now would be a good time to repeat this step for all other EVS service groups)
  4. Delete the .reg files that are on shared disks
    1. Do not delete the .crk file in the same location
    2. These .reg files can be deleted as they contain corrupted data anyway
  5. Restore the .reg files from backup
  6. Online the RegRep resource on this node
  7. Offline the EVS service group
  8. Online the EVS service group and monitor for the 'Beta has ended' message at the end of 65 minutes

Method 2 - Valid EVS registry entries on another node in the cluster.
  1. Export the following registry location from all nodes on which the problem EVS can run
    HKLM\System\CurrentControlSet\Service\MSExchangeSA\Parameters
  2. Check the registry export files for all nodes that can potentially have the correct registry entries for the problem EVS
    1. Ensure that there is a system with a binary value and a key that both have the same name of the EVS
    2. If there is not a system with both of these items, go to the next method of resolution
  3. Offline the problem EVS service group except for the VMDg and MountV resources used by RegRep
  4. Modify the RegRep resource RestoreLocally attribute to 'True' for this service group (now would be a good time to repeat this step for all other EVS service groups)
  5. Delete the .reg files that are on shared disk
    1. Do not delete the .crk file in the same location
    2. These .reg files can be deleted as they contain corrupted data anyway
  6. Offline the EVS service group
  7. Online the EVS service group on the node and monitor for 65 minutes for the "Beta has Ended" message

Method 3 - Reinstall of the EVS to recreate a valid EVS registry. This method requires the most work to implement.
  1. Offline the problem EVS service group except for the VMDg and MountV resources used by RegRep
  2. Modify the RegRep resource RestoreLocally attribute to 'True' for this service group (now would be a good time to repeat this step for all other EVS service groups)
  3. Delete the .reg files that are on shared disk
    1. Do not delete the .crk file in the same location
    2. These .reg files can be deleted as they contain corrupted data anyway
  4. Follow Microsoft article 260378 on how to manually remove Exchange from this node.
    1. For Exchange 2000 use Microsoft KB 260378 - http://support.microsoft.com/kb/260378/
    2. For Exchange 2003 use Microsoft KB 833396 - http://support.microsoft.com/default.aspx?scid=kb;en-us;833396
    3. Do not remove the Exchange object from Active Directory as directed in either article
  5. Delete the HKLM\Software\VERITAS\VCS\ExchConfig registry hive from this node
  6. Delete the entries for this node from the HKLM\Software\VERITAS\VCS\ExchConfig\EVS\<EVSname>\Systems registry of all nodes that could host this EVS
  7. Follow the Exchange Solutions Guide on how to add an additional Exchange node to a cluster
  8. Rerun the Any-to-Any configuration wizard for all EVSs in the cluster
  9. Rerun the Exchange Service group configuration wizard for all EVSs in the cluster. This will set the Restorelocally attribute of the RegRep resources to "True" as needed to prevent this issue from happening again
  10. Online the EVS service group and monitor for the 'Beta has ended' message at the end of 65 minutes

MORE INFORMATION

Here are some additional troubleshooting steps:
  1. Obtain MPS_Reports and EXBPA
  2. Check permissions on the registry keys and at the Organization and Administrative group levels
  3. Use Regmon and filemon during setup to see where it fails
  4. Apply hotfix 898126

DISCLAIMER

MICROSOFT AND/OR ITS RESPECTIVE SUPPLIERS MAKE NO REPRESENTATIONS ABOUT THE SUITABILITY OF THE INFORMATION CONTAINED IN THE DOCUMENTS AND RELATED GRAPHICS PUBLISHED ON THIS WEBSITE FOR ANY PURPOSE. THE DOCUMENTS AND RELATED GRAPHICS PUBLISHED ON THIS WEBSITE COULD INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICAL ERRORS. CHANGES ARE PERIODICALLY ADDED TO THE INFORMATION HEREIN. MICROSOFT AND/OR ITS RESPECTIVE SUPPLIERS MAY MAKE IMPROVEMENTS AND/OR CHANGES IN THE PRODUCT(S) AND/OR THE PROGRAM(S) DESCRIBED HEREIN AT ANY TIME.

For more information on the terms of use, click on the link below:
http://support.microsoft.com/tou/
Modification Type:MinorLast Reviewed:10/6/2006
Keywords:kbprb kbtshoot kbrapidpub KB924199 kbAudITPRO
©2004 Microsoft Corporation. All rights reserved.