• State Verified Answer
  • Locked Locked
  • Replies 5 replies
  • Subscribers 61 subscribers
  • Views 5389 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

Steve Confused (and amazed a little)

ssathue
over 7 years ago

In Production: ARS v6.9
In Testing: Active Roles v7.0

So last week I "captured" my production v6.9 database and copied it into a test Active Role 7.0 installation,using the Configuration Center (which is great stuff, BTW).

That process went smoothly and at the end of the process, my AR70 installation had production data, in particular Dynamic Groups and Managed Units (and their respective rules, of course).

Here's what confuses me....

Yesterday I created a new Dynamic Group in my Production ARS v6.9 system. I did nothing in my AR70 system (in fact, the admin service was stopped, as it often is for my testing).

After I started the admin service on AR70, I found my Dynamic Group, rules and all, visible and usable in AR70. I don't understand how AR70 would know anything about the rules of this group, which, again, I created yesterday and never "migrated" to AR70.

Does this confuse anyone else? How smart/connected is AR70 actually?
Thanks for any feedback.
 -Steve

  • 0 over 7 years ago

    This has to do with the way that the definition of the dynamic group is stored.

    A good part of it is stored in a native AD attribute called AccountNameHistory.  Two virtual attributes are also used.

    That would explain how your 7.x instance picked up the group.

  • 0 over 7 years ago

    I never saw similar in past migrations, e.g. from v6.8 to v6.9 - there was no Configuration Center but I had my own simulation methodology then, i.e. create a Subscriber to the production replication group and then break it off as a Standalone. At that point, it had all the production information (regarding dynamic groups for this example). And if/when I created a new dynamic group in v6.8, the standalone v6.9 didn't know anything about it.

    Are you saying the AccountNameHistory and/or the virtual attributes you alluded to are new? In v6.9? Since that's the production system on which the dynamic group was created.

    Thanks again.

  • 0 over 7 years ago

    that's correct. Dynamic Groups product design got dedicated nuances:

    (a) DG configuration is stored in on AD group object in some attribute (you may find it) in XML format

    (b) (not relevant to the question, but to mention) DG is based on ARS listening DC MSFT DirSync events

    Conclusion: it is dangerous for two independent ARS instances 6..x and 7.x(upgraded and inherited 6.x configuration) to hit the same AD scope in long run in general. One of examples is DG group overlap and intererance is unavoidable here. In general you must get error on one of servers: cannot add member to the group because he is in the group (already been added by another install) - it is a harmless error and during short period of time of upgrade.

  • 0 over 7 years ago

    The AccountNameHistory is nothing new - it is in fact something that Msft natively uses for dynamic groups in AD as well.

    I was just explaining the specific case that "Steve" saw where a dynamic group he created in one instance of ARS became visible in another.

  • 0 over 7 years ago

    Thanks Aidar (and Johnnyquest) for the enlightenment.

    And I agree with the "dangerous" comments, which is why the admin service is Stopped for most of the time on my test installations. I had/have always had concerns about multiple systems updating the same dynamic groups and MUs, etc.

    I think I'm less confused now.

    But hopefully just as careful.

    -Steve