Damp earth ~ after a summer shower.
Freshly cut timber ~ Sawdust.
smell of vanilla and peaches
Jasmine flowers
coffee
Sauteing ginger garlic paste
Fresh cut grass
Wednesday, January 28, 2009
Tuesday, January 27, 2009
Remove the first exchange server from the organisation
- Replicate all public folders to another server
- Rehome the Offline Address Book folder
- Change the server that is responsible for generating the Offline Address List
- Rehome the Schedule+ Free Busy folder
- Rehome the Organization Forms folder
- Rehome the Recipient Update Service
- Designate another server to be the routing group master
- Create another Site Replication Service (SRS) instance
- Rehome connectors to another server
- Move mailboxes to another server
- Remove the first Exchange Server 2003 computer[using CD]
Thursday, January 22, 2009
Exchange Server 2003 and antivirus software
File-level scanners
File-level scanners are frequently used, and they may be the most problematic for use with Exchange 2003. File-level scanners may be either memory-resident or on-demand:
Memory-resident refers to a part of file-level antivirus software that is loaded in memory at all times. It checks all the files that are used on the hard disk and in computer memory.
On-demand refers to a part of file-level antivirus software that you can configure to scan files on the hard disk either manually or on a schedule. There are versions of antivirus software that start the on-demand scan automatically after virus signatures are updated to make sure that all files are scanned with the latest signatures.The following issues may occur when you use file-level scanners with Exchange 2003:
File-level scanners scan a file when the file is used or at a scheduled interval, and these scanners may lock or quarantine an Exchange log or a database file while Exchange 2003 tries to use the file. This behavior may cause a severe failure in Exchange 2003 and may also generate -1018 errors.
File-level scanners do not provide protection against e-mail viruses such as the Melissa virus.Note The Melissa virus is a Microsoft Word macro virus that can propagate itself through e-mail messages. The virus sends inappropriate e-mail messages to addresses that it finds in personal address books on Microsoft Outlook mail clients. Similar viruses can cause data destruction.Exclude the following folders from both on-demand file-level scanners and memory resident file-level scanners:
Exchange databases and log files across all storage groups. By default, these are located in the Exchsrvr\Mdbdata folder.
Exchange MTA files in the Exchsrvr\Mtadata folder.
Additional log files such as the Exchsrvr\server_name.log directory.
The Exchsrvr\Mailroot virtual server folder.
The working folder that is used to store streaming .tmp files that are used for message conversion. By default, this folder is Exchsrvr\Mdbdata, but the location is configurable. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
822936 (http://support.microsoft.com/kb/822936/ )
File-level scanners are frequently used, and they may be the most problematic for use with Exchange 2003. File-level scanners may be either memory-resident or on-demand:
Memory-resident refers to a part of file-level antivirus software that is loaded in memory at all times. It checks all the files that are used on the hard disk and in computer memory.
On-demand refers to a part of file-level antivirus software that you can configure to scan files on the hard disk either manually or on a schedule. There are versions of antivirus software that start the on-demand scan automatically after virus signatures are updated to make sure that all files are scanned with the latest signatures.The following issues may occur when you use file-level scanners with Exchange 2003:
File-level scanners scan a file when the file is used or at a scheduled interval, and these scanners may lock or quarantine an Exchange log or a database file while Exchange 2003 tries to use the file. This behavior may cause a severe failure in Exchange 2003 and may also generate -1018 errors.
File-level scanners do not provide protection against e-mail viruses such as the Melissa virus.Note The Melissa virus is a Microsoft Word macro virus that can propagate itself through e-mail messages. The virus sends inappropriate e-mail messages to addresses that it finds in personal address books on Microsoft Outlook mail clients. Similar viruses can cause data destruction.Exclude the following folders from both on-demand file-level scanners and memory resident file-level scanners:
Exchange databases and log files across all storage groups. By default, these are located in the Exchsrvr\Mdbdata folder.
Exchange MTA files in the Exchsrvr\Mtadata folder.
Additional log files such as the Exchsrvr\server_name.log directory.
The Exchsrvr\Mailroot virtual server folder.
The working folder that is used to store streaming .tmp files that are used for message conversion. By default, this folder is Exchsrvr\Mdbdata, but the location is configurable. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
822936 (http://support.microsoft.com/kb/822936/ )
Message flow to the local delivery queue is very slow
The temporary folder that is used in conjunction with offline maintenance utilities such as Eseutil.exe. By default, this folder is the location where the .exe file is run from, but you can configure where you run the file from when you run the utility.
Site Replication Service (SRS) files in the Exchsrvr\Srsdata folder.
Microsoft Internet Information Services (IIS) system files in the %SystemRoot%\System32\Inetsrv folder.
The temporary folder that is used in conjunction with offline maintenance utilities such as Eseutil.exe. By default, this folder is the location where the .exe file is run from, but you can configure where you run the file from when you run the utility.
Site Replication Service (SRS) files in the Exchsrvr\Srsdata folder.
Microsoft Internet Information Services (IIS) system files in the %SystemRoot%\System32\Inetsrv folder.
Note :
You may want to exclude the whole Exchsrvr folder from both on-demand file-level scanners and memory-resident file-level scanners.
The Internet Information Services (IIS) 6.0 compression folder that is used with Outlook Web Access 2003. By default, the compression folder in IIS 6.0 is located at %systemroot%\IIS Temporary Compressed Files. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
817442 (http://support.microsoft.com/kb/817442/ ) Antivirus scanning of IIS Compression directory may result in 0-byte file
For clusters, the Quorum disk and the %Winnt%\Cluster folder.
Any messaging antivirus program folders.
The Exchsrvr\Conndata folder.Exclude the folder that contains the checkpoint (.chk) file from memory resident file-level scanners and on-demand file-level scanners.
The Internet Information Services (IIS) 6.0 compression folder that is used with Outlook Web Access 2003. By default, the compression folder in IIS 6.0 is located at %systemroot%\IIS Temporary Compressed Files. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
817442 (http://support.microsoft.com/kb/817442/ ) Antivirus scanning of IIS Compression directory may result in 0-byte file
For clusters, the Quorum disk and the %Winnt%\Cluster folder.
Any messaging antivirus program folders.
The Exchsrvr\Conndata folder.Exclude the folder that contains the checkpoint (.chk) file from memory resident file-level scanners and on-demand file-level scanners.
Many file-level scanners now support scanning processes. This can also adversely affect Exchange. Therefore, you should exclude the following processes from file-level scanners:
Cdb.exe
Cidaemon.exe
Store.exe
Emsmta.exe
Mad.exe
Mssearch.exe
Inetinfo.exe
W3wp.exe
Cdb.exe
Cidaemon.exe
Store.exe
Emsmta.exe
Mad.exe
Mssearch.exe
Inetinfo.exe
W3wp.exe
The information store is dismounted, and an event ID 1159 message is logged in Exchange Server 2003 or in Exchange 2000 Server
In Microsoft Exchange Server 2003 , the information store is dismounted. Additionally, an event that is similar to the following event is logged in the Application log on a server that is running Exchange Server 2003
------------------------
Event Type: Error
Event Source: MSExchangeIS
Event Category: General
Event ID: 1159
Description: Database error 0xfffffd9a occurred in function JTAB_BASE::EcUpdate while accessing the database "". Note The error code 0xfffffd9a translates to JET_errCheckpointDepthTooDeep
Event Type: Error
Event Source: MSExchangeIS Mailbox
Event Category: Logons
Event ID: 1022
Description: Logon Failure on database Path_of_Database.
Error: -519
------------------------------------
Problem:
This issue occurs if the storage group that is related to the information store contains more than 1008 uncommitted Extensible Storage Engine (ESE) transaction log files. Each ESE storage group has a hard-coded limit of 1024 uncommitted ESE transaction log files. When the number of uncommitted ESE transaction log files in an ESE storage group reaches 1008, Exchange Server 2003 or Exchange 2000 Server starts to dismount all the information stores in the storage group. Additionally, the event ID 1159 message is logged in the Application log.
Cause:
This problem occurs because the Exchange Server has used all the transaction logs that are available to a storage group causing to dismount all the databases that are in the affected storage group there by affecting mail flow.
Users who have mailboxes in this storage group experienced logon failures as we notice the events 1022 in the application log.
The maximum number of transaction log files that can be generated in a single sequence is 1,048,560 (0xFFFF0).
This generally happens when a backup has been started that does not complete for an excessive amount of time.
The backup will put the database into a state where it cannot commit the log files, then since the backup hangs it will eventually reach that limit and dismount the store. When you remount the store, the backup will have failed as a result of the database dismount and the log files will be committed. We need to ensure that no backups run for more than a day, and if one has been running that long cancel it.
Resolution:
To do this, you must move all existing transaction logs to another location. After you do this, a new sequence of log files that starts with 0x00001 is generated.Important Before you move the transaction logs, you must verify that all databases in the storage group are in a Clean Shutdown state. To do this and to reset the log file sequence, follow these steps:
Mark all the databases in the affected storage group to not mount on startup. To do this, follow these steps:
Click Start, point to Programs, point to Microsoft Exchange, and then click System Manager.
Expand Organization, click Servers, click your server, click Information Store, and then click your storage group.
Right-click your database, and then click Properties.
Click the Database tab.
Click to select the Don't mount this store at start-up check box.
Kill the store to dismount the database that could not be dismounted.To download the latest version of the Debugging Tools for Windows package, visit the following Microsoft Web site:
http://www.microsoft.com/whdc/devtools/debugging/default.mspx (http://www.microsoft.com/whdc/devtools/debugging/default.mspx)
Restart the store so that other storage groups can be mounted.
Run eseutil /r on all the databases that are in the affected storage group.
Verify that the databases were in a Clean Shutdown state. To do this, follow these steps:
In Exchange System Manager, right-click the first store in the storage group that has run out of transaction log files, and then click Properties.
Click the Database tab, and then note the paths and the file names of the database files in the Exchange database box and in the Exchange streaming database box. Each Exchange database is composed of a paired set of files that have the .edb file name extension and the .stm file name extension. Repeat this step for each store in the storage group.
At a command prompt, move to the Exchange Server bin folder. For example, move to the C:\Program Files\Exchsrvr\bin.
Type Eseutil /mh Database_File_Name, and then press ENTER. Repeat this step for each database in the storage group. This command displays the database file header. The header contains one of the following lines:
State: Clean Shutdown
State: Dirty Shutdown
Move logs and checkpoint files to another location in case a recovery is required from an old database. The log files have the .log file name extension. The checkpoint files have the .chk file name extension.
Mount all the databases in the storage group.
Click to clear the Don't mount this store at start-up check box for all the databases in the affected storage group.
The storage group must be backed up when delivery settles down on this computer because you cannot recover log files past the new log file generation point
------------------------
Event Type: Error
Event Source: MSExchangeIS
Event Category: General
Event ID: 1159
Description: Database error 0xfffffd9a occurred in function JTAB_BASE::EcUpdate while accessing the database "
Event Type: Error
Event Source: MSExchangeIS Mailbox
Event Category: Logons
Event ID: 1022
Description: Logon Failure on database Path_of_Database.
Error: -519
------------------------------------
Problem:
This issue occurs if the storage group that is related to the information store contains more than 1008 uncommitted Extensible Storage Engine (ESE) transaction log files. Each ESE storage group has a hard-coded limit of 1024 uncommitted ESE transaction log files. When the number of uncommitted ESE transaction log files in an ESE storage group reaches 1008, Exchange Server 2003 or Exchange 2000 Server starts to dismount all the information stores in the storage group. Additionally, the event ID 1159 message is logged in the Application log.
Cause:
This problem occurs because the Exchange Server has used all the transaction logs that are available to a storage group causing to dismount all the databases that are in the affected storage group there by affecting mail flow.
Users who have mailboxes in this storage group experienced logon failures as we notice the events 1022 in the application log.
The maximum number of transaction log files that can be generated in a single sequence is 1,048,560 (0xFFFF0).
This generally happens when a backup has been started that does not complete for an excessive amount of time.
The backup will put the database into a state where it cannot commit the log files, then since the backup hangs it will eventually reach that limit and dismount the store. When you remount the store, the backup will have failed as a result of the database dismount and the log files will be committed. We need to ensure that no backups run for more than a day, and if one has been running that long cancel it.
Resolution:
To do this, you must move all existing transaction logs to another location. After you do this, a new sequence of log files that starts with 0x00001 is generated.Important Before you move the transaction logs, you must verify that all databases in the storage group are in a Clean Shutdown state. To do this and to reset the log file sequence, follow these steps:
Mark all the databases in the affected storage group to not mount on startup. To do this, follow these steps:
Click Start, point to Programs, point to Microsoft Exchange, and then click System Manager.
Expand Organization, click Servers, click your server, click Information Store, and then click your storage group.
Right-click your database, and then click Properties.
Click the Database tab.
Click to select the Don't mount this store at start-up check box.
Kill the store to dismount the database that could not be dismounted.To download the latest version of the Debugging Tools for Windows package, visit the following Microsoft Web site:
http://www.microsoft.com/whdc/devtools/debugging/default.mspx (http://www.microsoft.com/whdc/devtools/debugging/default.mspx)
Restart the store so that other storage groups can be mounted.
Run eseutil /r on all the databases that are in the affected storage group.
Verify that the databases were in a Clean Shutdown state. To do this, follow these steps:
In Exchange System Manager, right-click the first store in the storage group that has run out of transaction log files, and then click Properties.
Click the Database tab, and then note the paths and the file names of the database files in the Exchange database box and in the Exchange streaming database box. Each Exchange database is composed of a paired set of files that have the .edb file name extension and the .stm file name extension. Repeat this step for each store in the storage group.
At a command prompt, move to the Exchange Server bin folder. For example, move to the C:\Program Files\Exchsrvr\bin.
Type Eseutil /mh Database_File_Name, and then press ENTER. Repeat this step for each database in the storage group. This command displays the database file header. The header contains one of the following lines:
State: Clean Shutdown
State: Dirty Shutdown
Move logs and checkpoint files to another location in case a recovery is required from an old database. The log files have the .log file name extension. The checkpoint files have the .chk file name extension.
Mount all the databases in the storage group.
Click to clear the Don't mount this store at start-up check box for all the databases in the affected storage group.
The storage group must be backed up when delivery settles down on this computer because you cannot recover log files past the new log file generation point
Your Exchange Server 2003 computer may stop responding after a MAPI client opens more than the default value of certain server objects
Symptom:
Your Microsoft Exchange Server 2003 computer may stop responding to one or more clients. Additionally, an error message that is similar to the following may be logged in the application event log:
Event ID: 9646
Type: Error
Source: MSExchangeIS
Description:Closing Mapi session "/o=Organization/ou=Administrative Group/cn=Recipients/cn=user" because it exceeded the maximum of 250 objects of type "objMessage".
Solution
In Exchange Server 2003, the number of server-side objects that are allowed by clients is limited to prevent a single client from the exhausting resources on the Exchange server. When the event log error that is mentioned in the "Symptoms" section occurs, it indicates possible poor behavior on behalf of a client opening too many objects or leaving too many objects open on the server. If the event log error occurs, investigate any third-party applications or add-ins that are running on the client. Additionally, investigate the user behavior that is associated with the indicated logon. This will help you better understand why the default number of objects is insufficient. In rare circumstances, the number of resources is insufficient and may be adjusted. However, use caution before you adjust the maximum number of objects that are allowed. When you increase the maximum number of objects of a particular type, you also increase the amount of memory that may be consumed by client requests. Incorrectly configuring this value could lead to out-of-memory warnings or virtual memory fragmentation warnings.You can add a registry key that adjusts the maximum number of resources that a MAPI client can use at the same time. This adjustment overrides the default limit of each server object that is mentioned in the "Cause" section.Note You should only adjust the value for the object type that is referred to in the event log error that is mentioned in the "Symptoms" section. You should adjust these values with caution, and only increase the value in small increments. For example, only adjust the value by 100.
Steps :
To add a registry key that limits the maximum number of resources that a MAPI client can use at the same time, follow these steps:
Click Start, click run, type regedit, and then click OK.
Expand the following registry subkey:
\\HKEY_LOCAL_MACHINE \SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem
Right-click ParametersSystem, point to New, and then click Key.
Type MaxObjsPerMapiSession, and then press ENTER to name the new subkey.
Right-click MaxObjsPerMapiSession, click New, and then click DWORD Value.
Type Object_type, and then press ENTER to name the object.Note Object_type is the name of the object type in the error message that is mentioned in the "Symptoms" section. For example, type objtMessage, and then press ENTER.
Right-click Object_type, and then click Modify.
In the Value data box, type the number of objects that you want to limit this entry to, and then click OK. For example, type 350 to increase the value for the objtMessage object. The default value is 250.
Your Microsoft Exchange Server 2003 computer may stop responding to one or more clients. Additionally, an error message that is similar to the following may be logged in the application event log:
Event ID: 9646
Type: Error
Source: MSExchangeIS
Description:Closing Mapi session "/o=Organization/ou=Administrative Group/cn=Recipients/cn=user" because it exceeded the maximum of 250 objects of type "objMessage".
Solution
In Exchange Server 2003, the number of server-side objects that are allowed by clients is limited to prevent a single client from the exhausting resources on the Exchange server. When the event log error that is mentioned in the "Symptoms" section occurs, it indicates possible poor behavior on behalf of a client opening too many objects or leaving too many objects open on the server. If the event log error occurs, investigate any third-party applications or add-ins that are running on the client. Additionally, investigate the user behavior that is associated with the indicated logon. This will help you better understand why the default number of objects is insufficient. In rare circumstances, the number of resources is insufficient and may be adjusted. However, use caution before you adjust the maximum number of objects that are allowed. When you increase the maximum number of objects of a particular type, you also increase the amount of memory that may be consumed by client requests. Incorrectly configuring this value could lead to out-of-memory warnings or virtual memory fragmentation warnings.You can add a registry key that adjusts the maximum number of resources that a MAPI client can use at the same time. This adjustment overrides the default limit of each server object that is mentioned in the "Cause" section.Note You should only adjust the value for the object type that is referred to in the event log error that is mentioned in the "Symptoms" section. You should adjust these values with caution, and only increase the value in small increments. For example, only adjust the value by 100.
Steps :
To add a registry key that limits the maximum number of resources that a MAPI client can use at the same time, follow these steps:
Click Start, click run, type regedit, and then click OK.
Expand the following registry subkey:
\\HKEY_LOCAL_MACHINE \SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem
Right-click ParametersSystem, point to New, and then click Key.
Type MaxObjsPerMapiSession, and then press ENTER to name the new subkey.
Right-click MaxObjsPerMapiSession, click New, and then click DWORD Value.
Type Object_type, and then press ENTER to name the object.Note Object_type is the name of the object type in the error message that is mentioned in the "Symptoms" section. For example, type objtMessage, and then press ENTER.
Right-click Object_type, and then click Modify.
In the Value data box, type the number of objects that you want to limit this entry to, and then click OK. For example, type 350 to increase the value for the objtMessage object. The default value is 250.
Troubleshoot virtual memory fragmentation in Exchange Server 2003
Overview
Virtual memory fragmentation is a condition where virtual memory is available for a process, but none of the virtual memory blocks that are available are of a significant size. Memory fragmentation occurs over time because of the varying size of memory allocations and the varying lifetimes of each allocation. When you scale a server to handle more users and larger loads, the server may run low on virtual memory in the Microsoft Exchange Information Store process (Store.exe). When this issue occurs, event ID 9582 events are logged to the application event log. In some cases, event ID 9582 events do not indicate a problem with the virtual memory on the server, and the events can be ignored. However, in other situations, the lack of virtual memory may result in message-processing errors (indicated by event ID 12800 events) and decreased performance. If left unchecked, virtual memory fragmentation can result in severe performance degradation and unexpected behaviors. There is virtually no correlation between the amount of physical random access memory (RAM) that is installed in the computer and the amount of virtual memory. Because of this, you cannot resolve low virtual memory issues by adding more physical RAM. Additionally, virtual memory errors and virtual memory fragmentation issues are not limited to Active/Active server clusters. These issues also occur on Active/Passive server clusters and on stand-alone servers that are running Exchange 2003 or Exchange 2000.Note Virtual memory issues are more prevalent in a clustered Exchange 2003 configuration or a clustered Exchange 2000 configuration because these environments are typically used to scale Exchange to host multiple thousands of users together with multiple storage groups and multiple messaging databases.
Virtual memory fragmentation is a condition where virtual memory is available for a process, but none of the virtual memory blocks that are available are of a significant size. Memory fragmentation occurs over time because of the varying size of memory allocations and the varying lifetimes of each allocation. When you scale a server to handle more users and larger loads, the server may run low on virtual memory in the Microsoft Exchange Information Store process (Store.exe). When this issue occurs, event ID 9582 events are logged to the application event log. In some cases, event ID 9582 events do not indicate a problem with the virtual memory on the server, and the events can be ignored. However, in other situations, the lack of virtual memory may result in message-processing errors (indicated by event ID 12800 events) and decreased performance. If left unchecked, virtual memory fragmentation can result in severe performance degradation and unexpected behaviors. There is virtually no correlation between the amount of physical random access memory (RAM) that is installed in the computer and the amount of virtual memory. Because of this, you cannot resolve low virtual memory issues by adding more physical RAM. Additionally, virtual memory errors and virtual memory fragmentation issues are not limited to Active/Active server clusters. These issues also occur on Active/Passive server clusters and on stand-alone servers that are running Exchange 2003 or Exchange 2000.Note Virtual memory issues are more prevalent in a clustered Exchange 2003 configuration or a clustered Exchange 2000 configuration because these environments are typically used to scale Exchange to host multiple thousands of users together with multiple storage groups and multiple messaging databases.
Events:
Source: MSExchangeISCategory:
PerformanceID: 9582
Type: Warning
Description: The virtual memory necessary to run your Exchange server is fragmented in such a way that performance may be affected. It is highly recommended that you restart all Exchange services to correct this issue.
Action:
Prepare and perform the steps to shut down and then restart the server in the next 36 to 72 hours.
To determine the rate of decay, use the Performance Logs and Alerts tool to monitor the following counter for the MSExchangeIS performance object:
VM Total Large Free Block BytesUse this data to help you plan an appropriate time (in the next 36 to 72 hours) to shut down and then restart the server.
Prepare and perform the steps to shut down and then restart the server in the next 36 to 72 hours.
To determine the rate of decay, use the Performance Logs and Alerts tool to monitor the following counter for the MSExchangeIS performance object:
VM Total Large Free Block BytesUse this data to help you plan an appropriate time (in the next 36 to 72 hours) to shut down and then restart the server.
When an Exchange server has less than 16 MB of free contiguous virtual address space, the following error message is logged to the application event log:
Source: MSExchangeIS
Category: PerformanceID: 9582
Type: Error
Description: The virtual memory necessary to run your Exchange server is fragmented in such a way that performance may be affected. It is highly recommended that you restart all Exchange services to correct this issue.
At this level of virtual memory fragmentation, the Store.exe process cannot create additional heaps and cannot correctly mount and dismount storage groups. If the VM Largest Block Size counter is below 10 MB, the storage groups do not mount. When an event ID 9582 error message is logged, prepare to shut down and restart the server at the next opportunity. For example, shut down and then restart the server that evening or the next morning. By doing so, you may help prevent performance issues that may occur during peak usage times. When you shut down and then restart the server to clear virtual memory fragmentation, there are additional considerations when Exchange 2000 Server is configured in a clustered environment. When you move cluster resources from one node to another node, this process does not ensure a "clean" virtual memory address space. If cluster resources are owned by the destination cluster node, and the cluster resources are moved to the passive node (without first restarting the destination node), you may experience virtual memory fragmentation on the passive node. To avoid this situation, and to clear memory fragmentation in an Exchange 2000 Server clustered environment, follow these steps:
Restart the passive node before you move cluster resources to it. This step helps to make sure that the cluster resources are moved to a server that has a "clean" virtual memory address space.
Move the cluster resources to the passive node.
Restart the node that previously owned the cluster resources.Note Exchange Server 2003 restarts the Store.exe service automatically after the resource records have been moved to a different node in the cluster to reset the Store.exe address space on that node. Therefore, the next time that the Exchange virtual server is moved back to the passive node, the Store.exe is operating with a "clean" address space.
Restart the passive node before you move cluster resources to it. This step helps to make sure that the cluster resources are moved to a server that has a "clean" virtual memory address space.
Move the cluster resources to the passive node.
Restart the node that previously owned the cluster resources.Note Exchange Server 2003 restarts the Store.exe service automatically after the resource records have been moved to a different node in the cluster to reset the Store.exe address space on that node. Therefore, the next time that the Exchange virtual server is moved back to the passive node, the Store.exe is operating with a "clean" address space.
Subscribe to:
Posts (Atom)
