• State Suggested Answer
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 18 subscribers
  • Views 3572 views
  • Users 0 members are here
Options
Related
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

QMMAD already deployed to sync passwords, need to perform QMMAD/EX migrations

eric_bergstrom
over 6 years ago

Hello all-

I’m starting a new migration project and am currently in the assessment phase. I have more questions than answers right now but wanted to run this scenario to the forum.

  • 3 AD forests into one target AD forest
  • Exchange 2010 and 2013 in the source, Exchange 2016 will be deployed in the target
  • Exchange 2013 is a RESOURCE forest to one of the source AD forests
  • QMM 8.13 is deployed already and is used to copy source accounts and sync passwords. This has been in place for quite some time and appears to work (although I understand the tool was not designed to do this long term.) Source/Target users have been copied/matched with their target objects

This is what I’m thinking:

  • Stand up 2 new QMM consoles with a shared ADLDS instance. This will allow myself and another consultant to work both the RUM and DSA concurrently. Matching will be done with available attributes and will obviously be different than what the other DSA instance uses
  • Match source/target AD objects but exclude the password copy. Let the other QMM instance continue to perform this function

Does this make sense? Am I missing anything? I would rather not disturb the first QMM install as it keeps critical applications from breaking. 

I’ll need to dig in deeper on a Resource Forest Exchange migration but any feedback is appreciated.

Thanks in advance,

Eric

  • 0 over 6 years ago

    Here's my thoughts:

    So your intention is to basically setup a whole new QMM Project to support this new effort (complete with its own service attributes)?

    I think that's prudent so you don't step on the existing QMM instance that's doing the password copy.  

    Since you are going to be doing an advanced install of QMM (rather than the Express), I would make sure that when you setup the new AD LDS ahead of time that you make sure that is has its own instance name - e.g. QMM2019 or some such so there's no risk of confusion.

    On the matching front, I would re-purpose the matches already made by copying the stamped GUIDs on the target objects from the existing matching attribute to your new one using PoSh.

    Also, make sure you document all of this VERY well so that in case you get hit by a bus, the next resource coming on site (who doesn't know QMM as well as you do), can figure this out.

    My $,02

    • 0 over 6 years ago in reply to JohnnyQuest

      Thanks for the quick response, Johnny!

      Can you elaborate a bit more on "I would re-purpose the matches already made by copying the stamped GUIDs on the target objects from the existing matching attribute to your new one using PoSh" I don't entirely follow. Copy the GUIDs from the first instance?

      Any good white papers on Exchange Resource forest migration? I have not dug into that one yet.

      • 0 over 6 years ago in reply to eric_bergstrom

        So right now, the first QMM deployment is using, let's say EA14 and EA15 on the target objects to store its data right?

        EA15 contains the corresponding source object GUID.

        In your new QMM deployment, you are going to use EA12 and EA13 for your service attributes - EA13 being the matching attribute.

        What I am proposing is that you use PoSh to copy the contents of EA15 to EA13 so when you run your migration sessions and/or dirsynch, QMM will immediately find the corresponding object in the target for each source object.  In fact, with this in place, you can turn off all of your existing matching rules in your new deployment.

        Does that make sense?

        • 0 over 6 years ago in reply to JohnnyQuest

          Yes it does. Thanks for the clarification!