Multiple Office 365 tenancies from single on premise Active Directory RRS feed

  • Question

  • Hi,

    I have a question around multiple Office 365 tenancies hanging off a single on premise Active Directory forest (single domain).

    As background we have the following scenario:

    We have a single Active Directory Forest (single domain)

    We currently have a single Office 365 tenancy configured with DirSync and ADFS supporting 160 schools.

    40 of these schools wish to utilise their own Office 365 tenancy.  There are a number of reasons for this, including (but not limited to); being able to associate their own EES agreement to the tenancy to allow access to the Office 365 desktop applications, have control over certain globally controllable settings and the limit of 250 Address Book Policies is becoming a hindrance in a single tenancy environment.

    Initially I was going to propose a MIM solution with the AAD Connector however have read a forum posting by Peter Stapf alluding to the AAD Connector becoming depreciated and receiving no further feature updates.

    Obviously the customer would like some clarification on this as the other option requires a virtual machine creating for each Office 365 tenancy to run their instance of Azure Active Directory Connect.

    Can anyone offer any suggestion as to where I might find a statement substantiating the statement that the AAD Connector for MIM will be depreciated, and can anyone see any major pitfalls in the proposal of implementing 40+ instances of AAD Connect?

    As a side to this, I am content with all my tenancies that will be introduced using the same ADFS environment to support authentication and understand I will have to utilise a third part application to pull mailboxes from the existing Office 365 tenancy to the new upon migration of the users and MX records.  Further, the customer is happy there will be down time associated with moving each school from one tenancy to another.

    Happy to provide any further information or detail if I have been too vague!

    Many thanks in advance.

    Wednesday, December 2, 2015 11:49 AM

All replies

  • Andreas Kjellman is the Microsoft AAD Connect product owner and you will find his blog here.  Your particular use case is interesting because most of the time organisations are looking to consolidate to a single tenant, not the other way around, but I note the limitations you speak of and can understand the thinking.  All the same, with O365 being in such a constant state of flux, you always need to be careful that the limitations you are working around are not suddenly miraculously lifted on a whim and you find yourself having wasted a lot of time and effort.

    That said, I too heard exactly what Peter Stapf has advised regarding the WAAD connector being retired (probably on the same call), and while this is not going to happen in the near future, I also know that all bets are now on AAD Connect in solving 99.9% of hybrid challenges.  I guess while there is a risk that 0.1% will still need to use FIM/MIM, there will always be that option too - but password hash syncs and the like will not be supported (ADFS model only for SSO if you go the FIM/MIM route).

    I am not aware of any statement of intent regarding the WAAD connector's future, but I can only confirm that what Peter has said is correct.  I am personally aware of at least one project coming up for me shortly to replace FIM2010 R2 with AAD Connect, and this will be just the start.  The best I could find was this comparison on Andreas' blog - written before MIM2016 came out.

    In the same way as there is no limit to the number of O365 tenants you could conceivably hang off a single on-premise AD forest, AAD Connect should also have no limit - but you should consider some edge cases. Is on-premise password authoritative across all schools, and if so will they all have the same password policy?  Is there any write-back to the on-premise AD forest that will create ambiguity (e.g. what if you were to synchronise the "domain users" group to all tenants and then AAD Connect wanted to write some attribute back)?  What if there are on-premise groups with members from multiple schools - presumably you would want to have contacts provisioned to the other tenants for each school (GAL Sync) to maintain group membership integrity and route-ability?

    I guess you just need to be sure that by solving one problem you're not creating another.  I could also imagine Andreas announcing at some point in the future that enough people have asked for multi-tenant support for a single AAD Connect instance to warrant support for this configuration OOTB.  Still, without asking the man directly I couldn't tell you if this was on the radar.

    My main reluctance for going down this path is simply the maintenance overhead - but if I was faced with the same challenge I think that right now I would be forced down this path too.  I would just be seeking my guidance directly from Microsoft on this, because the cost of getting it wrong is going to be high (simply in terms of wasted effort if nothing else).  Make 100% sure that the cure is not worse than the disease.

    Bob Bradley (FIMBob @ ... now using FIM Event Broker for just-in-time delivery of FIM 2010 policy via the sync engine, and continuous compliance for FIM

    • Edited by UNIFYBobMVP Monday, January 11, 2016 1:51 PM added comparison link
    • Proposed as answer by -Jeff Ingalls- Wednesday, January 13, 2016 3:37 PM
    Monday, January 11, 2016 1:49 PM