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

DSA & AD LDS Replica

My QMM environment consists of 4 servers. I have 2 RUM/LDS servers and 2 DSA servers. The second LDS server is configured as a replica. I am going to have 2 domain pairs so i plan on dedicating a DSA for each domain pair. Each RUM server is also pointing to their local LDS instance. My question is, when configuring the DSA, is it best practice to have both DSA's pointing to the same AD LDS, or should i have one DSA pointing to one AD LDS, and the other pointing to the AD LDS replica, based on the domain pair workstations will be processed from that server?

Any help would be appreciated.

Thanks,

Mike

Parents
  • Let me ask a few questions before we head down this rabbit hole. These are all things we use to consider deployment. 

    1. How large if your migration?
      1. The number of objects in the source and target directory total
      2. How many domains are in the scope of the migration? I assume 3 with two domain pairs
      3. Inter-org or intra-org migration?
      4. How many workstations?
      5. How many servers? 
      6. How many data centers/sites (with DC/Servers) do you have?
      7. How many the engineers will be executing the migration process?
    2. Why do you think you need more then a single AD LDS Instance
    3. Why do you think you need more then a single DSA instance? 
    4. Why do you think you need more then a single RUM console?
    5. Are Exchange mailboxes going to be migrated using QMM EX?
  • Hi Jeff, 

    Thank you for your response. Here are the answers to your questions.  At the moment my scope is only to consolidate 2 AD domains into a new AD domain. But next year I will be migrating an additional 13 domains to this new environment.

    1a. About 8000 users in each of the 2 AD domains that i am migrating at the moment. The other 13 domains are very small. Only a few hundred users.

    1b. 3 domains are currently in scope. 2 source and 1 target. The scope will increase to another 13 source next year.

    1c. Inter-org

    1d. 10,000+ workstations

    1e. 500 servers

    1f. 50 sites

    1g. 2 engineers

    2. wanted a replica ad lds instance so that each RUM server could be pointed to a local instance.

    3. In my training was told it was best practice to have a DSA dedicated for domain pairs, and it also helps reviewing the logs for troubleshooting.

    4. Multiple engineers will be able to migrate simultaneously. 

    5. Exchange is not installed.

    Thanks,

    Mike

  • Two domain with 20K objects (users, groups, computers) in each I would user a DSA for each would be fine. I would also only use a Single AD LDS instance on a dedicated host. A Project for all domain pairs is also in order. QMM AD console can be installed on multi hosts and accessed simultaneously  Also the RUM Console can be installed separately as needed. 

    As for Multi engineers you said you only have two? Two console, two domain pairs, two engineers. The normal migration process is to migrated all in scope users and groups from source to target and allow the directory sync to maintain them during the migration. At times migration session may be needed to enable the source and disable the target object as is common, but really there is little reason to touch the console after the inital setup of the domain pair. The RUM console on the other had, that is the rinse, wash and repeat work house. That can e deployed separately as needed. It can even be delegated to others with lesser roles in the migration. 

Reply
  • Two domain with 20K objects (users, groups, computers) in each I would user a DSA for each would be fine. I would also only use a Single AD LDS instance on a dedicated host. A Project for all domain pairs is also in order. QMM AD console can be installed on multi hosts and accessed simultaneously  Also the RUM Console can be installed separately as needed. 

    As for Multi engineers you said you only have two? Two console, two domain pairs, two engineers. The normal migration process is to migrated all in scope users and groups from source to target and allow the directory sync to maintain them during the migration. At times migration session may be needed to enable the source and disable the target object as is common, but really there is little reason to touch the console after the inital setup of the domain pair. The RUM console on the other had, that is the rinse, wash and repeat work house. That can e deployed separately as needed. It can even be delegated to others with lesser roles in the migration. 

Children
No Data