Sign in
 
HomeLibraryWikiLearnGalleryDownloadsSupportForumsBlogs
Resources for IT Professionals >
> 
> 
> 
MIIS change failure recovery

Answered MIIS change failure recovery

  • Wednesday, October 17, 2012 8:32 AM
     
     
    Sign In to Vote
    0

    We use MIIS for Galsync. We will made MIIS setting change this weekend.

    We have two Forests(say, ForestA, ForestB) and ExchOrgs.

    We will uncheck an OU of sync source OU of Forest A and import and sync . About 8000 users objects in Metaverse will be deleted. and we will export each MAs(correspondent contacts will be deleted)

    Then we will check an OU of sync source OU of ForestB and import and sync .   About 8000 users objects in Metaverse will be created.and we will export each MAs(correspondent contacts will be created)

    In case of failure, I am thinking of taking backup of SQL database according to the below URL before this task.

    http://technet.microsoft.com/en-us/library/cc708637(v=ws.10).aspx

     

    If I have done all of above task and found some error, is it recoverable to restore SQL backup , and chage MA setting to original state, and import ,sync, export ? 

     

     

All Replies

  • Wednesday, October 17, 2012 7:45 PM
     
     
    Sign In to Vote
    0

    In my experience, you will have to run a full import after removing an OU in the AD MA configuration in order for the objects in that OU to be removed from the connector space.  You didn't specify that was your plan, so I just wanted to make that clear.

    Restoring the SQL back-end should put your MIIS/GalSync installation back to the state that it was.  Because the MA configuration is stored in the database (unless you have custom code that is calling out directly to a file or other source outside the sync engine), you shouldn't even have to change the MA settings back to the original state.  The SQL backup would take care of that.

    If you are using password synchronization, you will have to re-enable it after restoring from backup.  It gets disabled as a safeguard in case there were now-outdated passwords in the process of being synchronized when the backup was captured.  (To be honest, I've never seen a description of what to do to purge any pending passwords...at least in my environment they're in and out in a second.)

    Also remember that whenever you restore from backup, you must run full imports on each MA (at least for AD this is true).  Again, I wasn't sure if that was your plan, but it should be in the event of a restore.  If you have large forests, be prepared for the time this process takes in your planning.

    Chris

     
  • Thursday, October 18, 2012 2:48 AM
     
     
    Sign In to Vote
    0

    Thank you.

    "Also remember that whenever you restore from backup, you must run full imports on each MA (at least for AD this is true).  "

    I assume that AD data of two Forest will be wrong state due to this task and backuped SQL database metaverse infomation is right and restore AD data from metaverse.

    Is it OK to restore AD data from backuped SQL metaverse ? 

    And will it be OK to  take SQL database backup without stopping MIIS service and password sync service because we forgot to notice end-user so, we could not stop service without notice.


    • Edited by blackjack08 Friday, October 19, 2012 9:45 AM
    •  
     
  • Friday, October 19, 2012 4:23 PM
     
     Answered
    Sign In to Vote
    0

    There are problems with trying to restore AD using the metaverse backup.  First, the sync engine doesn't know that there are changes that need to be made until you run a full import/sync on the MA for that data source.  Once you do a full import/sync, the current state of your AD is now the "truth" on which the sync engine's decisions will be made.  Depending on your environment, the sync rules you are using, etc. this could produce a result other than a simple return to what was.  You'd have to run it through a representative test environment to be sure.

    In almost every case, the supported way to truly restore AD to a known good state is to restore from the system state backup of a domain controller.  Of course that has other implications, like the reversion of user passwords and other things that happen outside the sync engine's purview.  And if you restore AD from backup, the same is true about the need to run a full import before resuming delta imports.

    If you do not have an adequate test environment to simulate the kinds of changes you are attempting to make, then make use of the features of MIIS that will help you evaluate what is about to happen. 

    1. Make your backup, then the changes, and run full imports (no sync).  Then use the Preview feature on a representative sample of connector space objects so that you can see what will happen in the sync you are about to run (full or delta). 
    2. And rather than using your normal export run profile, create a new one that drops the exported changes to a file and stops.  That way you can look at the file and determine if the changes that you are about to write to AD are the correct ones.  Another run profile can be made to pick up the file that was dropped and actually write the changes to your connected data source.
    3. Finally, you can limit the number of objects processed in a given run profile.  Limit your full sync and/or your export to a tolerably small number and take a real close look at what is happening.  (Note that you cannot control which objects will be processed first before the limit is reached.) 

    Information about using the Preview feature can be found here:  http://social.technet.microsoft.com/wiki/contents/articles/2047.troubleshooting-generic-fim-synchronization-errors.aspx

    I always use Carol Wapshere's script and XSL file to reformat the XML that the sync engine generates to make it more readable in IE.

    In short, I believe it is critical to spend more time preparing, testing and evaluating to avoid the need for recovery.  It's still important to have a recovery plan in place, but if the reason you are restoring is you didn't understand and anticipate the problems you would have with your sync engine, then the sync engine should not be the tool you use to put things back the way they were in case there was something else about its operation that you missed.

    Chris

     
  • Friday, October 19, 2012 4:27 PM
     
     
    Sign In to Vote
    0

    For the question about running the backup, it is quite normal to run SQL Server backups of the sync engine's back-end while the service is running.  My personal preference is to run it at a time that no major sync operations are taking place and user activitiy (for password sync in your case) is at a low point.

    Chris