locked
Mid-Migration Roll-back - Point of No Return RRS feed

  • Question

  • Attempted Task:  Migrate SCCM 1511 running on a Win2008R2 server to a new Win2012R2 server.

    Existing SCCM Hierarchy was a single Primary Server with 3 secondary servers. No CAS.  The new 2012R2 server was meant to be a Primary server in which the old primary would be migrated.
    About half-way through our Migration tasks, I found that SCCM 1511 had been installed (by my colleague) as a CAS on the new 2012R2 server.  This was apparent when I found that the DP and MP roles were not installed, and unable to be installed since it is a CAS.
    We were following a very well documented migration guide from systemcenterdudes.com.  The following are the tasks in which we completed:

    Setup Source Hierarchy (the old primary SCCM server)
    Gathered Data
    Ran several Migration jobs to Migrate objects, including - Saved Searches, Collections, Boundaries, Boundary Groups, Software Distribution Packages, Application Deployments, Applications, OS Deployment Boot images, and Software Metering Rules.... Basically all objects minus SUP objects.  (SUP Role is not installed on either of the 2 servers in question)

    It was at this point, we were going to begin package migration and follow up with DP reassignment.  As previously mentioned, this was a no-go as the new server was improperly installed.

    We attempted to reverse course by making the new SCCM server the Source and then attempted to migrate one minor thing - a Saved Search - back to the original server.  This migration job failed with error: "provider exception cannot create duplicate search folder"

    It is assumed that any future Migration tasks going back to where they came from will also fail. So, this is where I stopped before making things worse.

    With my untrained eye - it looks like all we have done is copy a bunch of information from the old server, but no actual data or packages.  Furthermore, no roles have been transerred.  The original Primary server still appears to be a fully functional MP/DP - I don't see anything different with it.
    When I view the Hierarchy on each server under Monitoring> Overview> Site Hierarchy - The Original server reports it is at the top with its 3 seconday servers.  The new server reports it is the only server in its hierarchy.

    So the question(s).  Are we at a point of no return in this migration?
    Can we simply disable Data Gathering for both SCCM servers?  Then Un-install SCCM from the new server and re-install it properly as a Primary server?  Then just re-start the migration operation...

    Or is there more to it than that?
    Thanks for reading!


    Wednesday, June 1, 2016 4:14 PM

Answers

  • Yeah, ouch.

    You can't migrate backwards.

    Yes, you should be able to just kill the migration and start over with a correctly built destination site and site server.


    Jason | http://blog.configmgrftw.com | @jasonsandys

    • Marked as answer by DBruceM2 Thursday, June 2, 2016 6:19 PM
    Wednesday, June 1, 2016 5:11 PM

All replies

  • Yeah, ouch.

    You can't migrate backwards.

    Yes, you should be able to just kill the migration and start over with a correctly built destination site and site server.


    Jason | http://blog.configmgrftw.com | @jasonsandys

    • Marked as answer by DBruceM2 Thursday, June 2, 2016 6:19 PM
    Wednesday, June 1, 2016 5:11 PM
  • Hi Jason,

    Thank you for your prompt reply.  I've used your blog for a lot of great info in the past, so I was pleased to see your response.  As you might expect, I have just a few follow-up questions just to make sure I make this as clean as possible - given the circumstances.

    At this point, we'll stop the Data Gathering for both.  That's easy.  

    Should I perform the 'Clean Up Migration Data' task on both of the servers?  From what I can tell, performing this will eliminate the migration history.  Will this also remove the Source Site listed under Administration > Migration > Source hierarchy?  Or is that there to stay, indefinitely?

    And lastly - Can the Site Code of the improperly configured (CAS) server be re-used?  Or should we give it a new/unique site code when we rebuild it properly?

    Again - thank you for helping set my mind a little more at ease. I've backed away from the ledge for now. 

    Wednesday, June 1, 2016 6:12 PM
  • "Should I perform the 'Clean Up Migration Data' task on both of the servers? "

    On the source yes. The destination makes no difference if you are just going flatten it.

    "Can the Site Code of the improperly configured (CAS) server be re-used? "

    Can: Yes. Should: No. I never re-use things like server names or site codes because it makes it difficult (if not impossible) to validate when troubleshooting whether or not it's the old name/code stuck somewhere or being incorrectly used or the new/name code.


    Jason | http://blog.configmgrftw.com | @jasonsandys

    Monday, June 6, 2016 9:17 PM
  • TBH you might want to look at killing migration completely, get your existing environment onto 1602 release and run in-place upgrades to server 2012 R2 if this is all you want to achieve with your original goal. 

    Cheers Paul | http://sccmentor.wordpress.com

    Monday, June 6, 2016 9:37 PM