Storage Foundation and High Availability Solutions 7.4 HA and DR Solutions Guide for Microsoft Exchange 2010 - Windows
- Section I. Introduction and Concepts
- Introducing Storage Foundation and High Availability Solutions for Microsoft Exchange Server
- How VCS monitors storage components
- Introducing the VCS agent for Exchange 2010
- Introducing Storage Foundation and High Availability Solutions for Microsoft Exchange Server
- Section II. Configuration Workflows
- Configuring high availability for Exchange Server with InfoScale Enterprise
- Reviewing the HA configuration
- Reviewing a standalone Exchange Server configuration
- Reviewing the Replicated Data Cluster configuration
- Reviewing the disaster recovery configuration
- Disaster recovery configuration
- Notes and recommendations for cluster and application configuration
- Configuring disk groups and volumes for Exchange Server
- About managing disk groups and volumes
- Configuring the cluster using the Cluster Configuration Wizard
- Using the Solutions Configuration Center
- Configuring high availability for Exchange Server with InfoScale Enterprise
- Section III. Deployment
- Installing Exchange Server 2010
- Configuring Exchange Server for failover
- Configuring the service group in a non-shared storage environment
- Configuring campus clusters for Exchange Server
- Configuring Replicated Data Clusters for Exchange Server
- Setting up the Replicated Data Sets (RDS)
- Configuring a RVG service group for replication
- Configuring the resources in the RVG service group for RDC replication
- Configuring the RVG Primary resources
- Adding the nodes from the secondary zone to the RDC
- Verifying the RDC configuration
- Deploying disaster recovery for Exchange Server
- Reviewing the disaster recovery configuration
- Setting up your replication environment
- Configuring replication and global clustering
- Configuring the global cluster option for wide-area failover
- Possible task after creating the DR environment: Adding a new failover node to a Volume Replicator environment
- Testing fault readiness by running a fire drill
- About the Fire Drill Wizard
- About post-fire drill scripts
- Prerequisites for a fire drill
- Preparing the fire drill configuration
- Running a fire drill
- Deleting the fire drill configuration
- Section IV. Reference
- Appendix A. Using Veritas AppProtect for vSphere
- Appendix B. Troubleshooting
- Appendix A. Using Veritas AppProtect for vSphere
VCS logging
VCS generates two error message logs: the engine logs and the agent logs. Log file names are appended by letters. Letter A indicates the first log file, B the second, C the third, and so on.
The agent log is located at %VCS_HOME%\log\agent_A.txt
. The format of agent log messages is:
Timestamp (Year/MM/DD) | Mnemonic | Severity | UMI | Agent Type | Resource Name | Entry Point | Message Text
Here,
Timestamp denotes the date and time when the message was logged.
Mnemonic denotes which Veritas product logs the message. For VCS application agent for Microsoft Exchange, mnemonic is 'VCS'.
Severity denotes the seriousness of the message. Severity of the VCS error messages is classified into the following types:
CRITICAL indicates a critical error within a VCS process. Contact Technical Support.
ERROR indicates failure of a cluster component, unanticipated state change, or termination or unsuccessful completion of a VCS action.
WARNING indicates a warning or error, but not an actual fault.
NOTE informs that VCS has initiated an action.
INFO informs about various state messages or comments.
Of these, CRITICAL, ERROR, and WARNING indicate actual errors. NOTE and INFO provide additional information.
UMI or Unique Message ID is a combination of Originator ID, Category ID, and Message ID. For example, the UMI for a message generated by the ExchService agent would resemble: V-16-20024-13
Originator ID for all VCS products is 'V-16.' Category ID for ExchService agent is 20024. Message ID is a unique number assigned to the message text.
Message text denotes the actual message string.
You can view these message logs using Notepad or any text editor. All messages are logged to the engine and the agent logs. Messages of type CRITICAL and ERROR are also written to the Windows event log.