locked
Migrating SCOM Management servers and Databases to a New domain RRS feed

  • Question

  • Well, I've done some initial searches and the news doesn't appear good, but I need to find a definitive process for moving SCOM 2007 Sp1 management servers and databases from one forest to another.     We currenlty have a forest trust between the two forests and are currently monitoring resources in both forests without the use of gateway  management servers.    But the business wants to eliminate the source domain where the SCOM back-end components currently reside.   

    We've already started migrating agents by completely removing and re-adding the agent after a machine is migrated, but there doesn't appear to be a documented process for back-end SCOM components.  

    Is there any way to accomplish this, or are we pretty much talking about removing SCOM completely and re-installing it, and maybe retaining some settings by exporting and importing management packs?  

    Are there any options for possibly standing up a new management group in the new domain and migrating settings between management groups?   

    Any known features in SCOM 2010 that might simplify this process?   I.e. install SCOM 2010 in the new domain and migrate settings to it?   

    I've got to find some process, no matter how ugly.  
    Tuesday, February 2, 2010 6:25 PM

Answers

All replies

  • Hi,
    There is no SCOM 2010 product. My understanding is that you will have to do most of a re-install. As you wrote, mabe you could retain some settings by export/import managements.
    Anders Bengtsson | Microsoft MVP - Operations Manager | http://www.contoso.se
    Tuesday, February 2, 2010 7:12 PM
  • Thanks Anders.  I know that there is currently no SCOM 2010 product, but I also know SCE 2010 is in beta and the full system center product will likely follow that.   So I was really looking for a response from Microsoft as to wether or not there might be any enhancements in the upcoming version relating to portability, or possibly some migration tools that might simplify this process (like some of the migration tools that were made available for MOM 2005 to SCOM 2007 upgrades).  

    If anyone else has attempted a forest to forest move and documented any of the specific steps, limitations, or shortcuts,   I'd really appreciate any feedback you could provide. 

    Thanks,
    Scott...

    Tuesday, February 2, 2010 7:31 PM
  • Hi Scott

    What is the OS and SQL Version for the current domain?

    My guess is that the next version of OpsMgr (and this is a total guess) will only support windows 2008 \ SQL 2008 (x64) from a core component perspective. I have no knowledge on this ... and haven't seen anything to do with the next version of OpsMgr yet ... but having taken a look at servicemanager (and its requirements), I think that is a good guide for the requirements for the next version of OpsMgr, whenever it might come along. Given that it isn't available as a public beta yet, I think it is still some way off.

    So with that in mind, if you have windows 2003 \ sql 2005 at the moment, I'd almost suggest a new install into the new domain on Windows 2008 \ SQL 2008 and move the agents across - you might want to consider running the environments in parallel (with multi-homed agents) for as long as any reports need to be run against old data. For instance, if you need to run quarterly reports, make sure you have 3 months of data in the new data warehouse before uninstalling the agents from the old management group.

    As for migrating settings - I think you'll just need to document those and redo. I've found that trying to migrate something generally takes twice as long as redoing it ... I'm paranoid as well as cautious!

    Cheers

    Graham


     

    View OpsMgr tips and tricks at http://systemcentersolutions.wordpress.com/
    Tuesday, February 2, 2010 8:00 PM
  • All the current scom core components are win2k3 32bit with sql 2005.  So your points about win2k8 and sql2k8 x64 are certainly valid.   However,  with Microsoft's increasing aversion to direct upgrades, I think any new version of scom would likely require additional/parallel boxes anyway.        I'll still go with the 2k8 x64 versions of everything in the new forest though just to keep everything as current as possible.   By the way - Are all the scom 2007 R2 roles supported on both Win2k8 and SQL2k8 64bit?      

    Regarding multihoming and keeping legacy reporting data - all of our member servers will be migrating into this new forest also.   So what we are planning is building up the new SCOM environment, and then when a member server is migrated into the new forest, remove the old management group agent and add the new one.     Once the member server changes domain memberships,  it can no longer talk to the legacy scom environment anyway, unless we intend to also redeploy the agent from the legacy environment (i.e. two agent deployments after a member server domain migration).   So I don't think we'll do that, however, if I manually remove the legacy agent from add/remove programs, then the machine record should stay in the legacy scom databases for reporting purposes until we're ready to eliminate the entire legacy environment. 

    Wish there was an easier way, but on the positive side I've been pushing for an R2 upgrade, and this is one very roundabout way to get there. 

    Tuesday, February 2, 2010 8:32 PM
  • it is supported on X64 and X64 is nice as you could use more memory in your machines.
    Anders Bengtsson | Microsoft MVP - Operations Manager | http://www.contoso.se
    Wednesday, February 3, 2010 4:10 PM
  • Any known issues running the core components on Win2k8 R2?   
    Wednesday, February 3, 2010 8:41 PM
  • Monday, February 8, 2010 7:30 PM
  • No activity for 30 days, will mark this thread as answered now. Feel free to open it again.
    Best regards, Marnix Wolf

    (Thoughts on OpsMgr)
    Tuesday, March 9, 2010 12:39 PM
  • Hello,

    Can we open this thread again please?  We are also looking to migrate our SCOM server from one domain to another - mainly because it was not installed in the proper domain to start with and for security reasons we must remove this last inter-domain dependency between the two domains (SCOM server in one domain monitoring servers in another domain).  It was an ugly install and configuration to get it to work using domain trusts and certificates across the domains.  Now we need to remove all of this and put the SCOM server in the same domain as the resources that it's monitoring.  We went through a lot of configuration to get the alerts and monitoring set up properly and would like to retain at least those settings.

    Has anyone ever attempted such a move (sounds like not, but I thought I'd try again just in case anyone's out there who's done this before).


    Thank you,


    Aquelah Davis

    Monday, April 26, 2010 3:17 PM
  • We are actually moving across forests, not just domains.    But it's really not possible to move SCOM to either a new forest, or a new domain in the same forest.    There are just too many domain dependencies and references.  

    So you pretty much have to build out a new environment and recreate everything.   I'd recommend that you have both environments up in parallel so you can view settings in both at the same time.    

    Hopefully you used good naming practices when creating your own objects (overrides, rules, monitors, groups, etc.), like prefixing everything with company acronym.    This will allow you to at least search and locate the customizations you have made.   

    Scott...

    Tuesday, April 27, 2010 8:19 PM