Hi folks,
I have covered configuring DAG and AutoReseed in my previous article. In this one I will share with you on how AutoReseed Actually works. You can read this and this articles on the work flow behind it. I will simply share with you on how I tested it experimentally.
In order to emulate scenario that would activate AutoReseed, I first have removed virtual disk from one of my lab servers.
As the result all the mailbox database copies on this disk get into the state of Failed and Suspended.
The following event log is used to monitor events related to AutoRessed; Applications and Services Logs->Microsoft->Exchange->HighAvailability->Seeding
AutoReseed will start attempts to automatically reseed database copies that were stored on the list volume. It will log series of events with the source of HighAvailability.
First event 1109 will be logged as process starts.
It will follow by the event 1124 where attempt for resuming DBs will take place
Afterwards event 1110 will be logged showing that process has completed successfully.
But don't be fooled by the "success" word. In 15 minutes the whole process will be repeated again.
Overall, this process will be repeated 3 times every 15 minutes as AutoReseed is trying to resurrect the lost disk. After 3 attempts have failed the similar work process will start. You will again see event 1109 you saw previous 3 times.
Event 1119 will be logged with the information about attempt to assign spare disk
After this event 1124 will be logged, however it will attempt to assign spare drive and log the AssignSpare event.
This will follow with the event 1149 which will list all the available volumes:
If Autoreseed successfully finds spare volume and assigns it. Event 1125 will be logged saying that the spare volume has been successfully assigned
The process will finish with the event 1110 about the successful finishing of the process, but is not yet the end.
In 15 minutes database copies reseed will be started. The new cycle will start with our beloved event 1109. This will be followed by event 1124 with the difference that InPlaceReseed process has started.
The events 825, 1127 1246 and 1238 will be logged for every database copy as witness of the reseeding process.
Should DB copies replicate successfully event 826 will be booked for each of them
After this you will see event 827 which give evidence that context index is being replicated.
Finally after all replication is over events 1109, 1183 and 1110 are logged as evidence that HealthyCopyCompletedSeed event has completed. It means that all the mailbox database copies that were affected by the loss of the disk have been successfully replicated.
To verify health of your mailbox databases you can execute Get-MailboxDatabaseCopy against databases that were affected by this process to confirm that their state is healthy. You should get something as the below:
And when you check volume mount points settings on your spare drive you will notice that the database volume mount points previously assigned to the lost volume are now assigned to the spare volume.
And now all you need to do is to replace a faulty disk and assign it to the volume mount point of the lost volume.
To be continued...
I have covered configuring DAG and AutoReseed in my previous article. In this one I will share with you on how AutoReseed Actually works. You can read this and this articles on the work flow behind it. I will simply share with you on how I tested it experimentally.
In order to emulate scenario that would activate AutoReseed, I first have removed virtual disk from one of my lab servers.
As the result all the mailbox database copies on this disk get into the state of Failed and Suspended.
The following event log is used to monitor events related to AutoRessed; Applications and Services Logs->Microsoft->Exchange->HighAvailability->Seeding
AutoReseed will start attempts to automatically reseed database copies that were stored on the list volume. It will log series of events with the source of HighAvailability.
First event 1109 will be logged as process starts.
It will follow by the event 1124 where attempt for resuming DBs will take place
Afterwards event 1110 will be logged showing that process has completed successfully.
But don't be fooled by the "success" word. In 15 minutes the whole process will be repeated again.
Overall, this process will be repeated 3 times every 15 minutes as AutoReseed is trying to resurrect the lost disk. After 3 attempts have failed the similar work process will start. You will again see event 1109 you saw previous 3 times.
Event 1119 will be logged with the information about attempt to assign spare disk
After this event 1124 will be logged, however it will attempt to assign spare drive and log the AssignSpare event.
This will follow with the event 1149 which will list all the available volumes:
If Autoreseed successfully finds spare volume and assigns it. Event 1125 will be logged saying that the spare volume has been successfully assigned
The process will finish with the event 1110 about the successful finishing of the process, but is not yet the end.
In 15 minutes database copies reseed will be started. The new cycle will start with our beloved event 1109. This will be followed by event 1124 with the difference that InPlaceReseed process has started.
The events 825, 1127 1246 and 1238 will be logged for every database copy as witness of the reseeding process.
Should DB copies replicate successfully event 826 will be booked for each of them
After this you will see event 827 which give evidence that context index is being replicated.
Finally after all replication is over events 1109, 1183 and 1110 are logged as evidence that HealthyCopyCompletedSeed event has completed. It means that all the mailbox database copies that were affected by the loss of the disk have been successfully replicated.
To verify health of your mailbox databases you can execute Get-MailboxDatabaseCopy against databases that were affected by this process to confirm that their state is healthy. You should get something as the below:
And when you check volume mount points settings on your spare drive you will notice that the database volume mount points previously assigned to the lost volume are now assigned to the spare volume.
And now all you need to do is to replace a faulty disk and assign it to the volume mount point of the lost volume.
To be continued...
