Sync AD groups to O365

[Chuckster]

I want to sync an OU of security groups that I want to appear in Office 365 as mail enabled security groups.

 

I use the Azure AD Connect to do this and everything appears to be successful; however, the groups do not appear. Initially they did with all the users but now they don't.

 

I have deleted, for example, a single group and the Azure AD Connect will show it has removed the group. I then re-create the group with an alternative name and it will show it's successfully synced. But, the on-prem AD group does not appear in Office 365.

 

I created a new OU with new groups and, again, this will sync successfully but it does not appear in the Admin Portal.

 

I have added the e-mail address as SMTP:[email protected] to the proxyaddress attribute as well as the mail attribute.

The AD group scope is set to universal and the group type is security.

 

What am I doing wrong?

[chaplic]

How are you determining it's not appearing in O365? What happens when you look at groups via https://aad.portal.azure.com ?

[Chuckster]

I am looking in https://portal.office.com/AdminPortal/Home#/homepage under Teams & Groups --> Active teams & groups --> Mail-enabled security

 

AAD portal also throws up nothing.

[chaplic]

Have you looked at sync errors, either in the Synch Service Manager (miisclient.exe) or sync errors in Azure Active Directory Connect Health - Azure Active Directory admin center

[Chuckster]

@chaplic, I have looked at the sync errors and everything is currently showing up as 0.

[chaplic]

Even in miis client? Could it be there's no error but some sync rule is filtering the groups out? group_ in admindescription field would be an obvious one, but could a custom rule have been written?

 

 

Can you locate a group in miisclient metaverse search, double click on it and there should be two connectors listed, one relevant to your local AD and the other something like yordomain.onmicrosoft.com - AAD

 

Double click the connector to AAD then look at the lineage tab. There, there should be a rule that has a 'provision' decision

 

 

Then if you look at the Metaverse object properties box you'll see the group obect as the metaverse sees it, and cloudanchor and cloudsourceanchor should be populated from AAD connector

[Chuckster]

No custom rule has been written; it was a standard installation.

 

The groups do appear in the metaverse search

 

The screenshot attached appears to look fine

[chaplic]

This is AADC pulling the group into the metaverse, the screen before this should show two connectors in play

[Chuckster]

I only see my local AD in the connectors tab. The AAD connector isn't shown.

[chaplic]

Great, so it's pulling it into the metaverse but deciding not to project it to AAD. That's the fault.

 

But why....?

 

In the synchronisation rules editor, in outbound rules, what does 'out to ADD - Group Join' filter out, and can you check your groups against that critieria? (and the description pane looks right in terms of connected system, object type and link type of provision, and that it's enabled?

[chaplic]

 

Not Sure, OP this is what I think Mr Plumb is getting at, metaverse search by object type group, then seeing if we can see group and where attributes are coming from. I'm thinking you'll see groups but no CloudAnchor etc...

[HPlum78]

Sorry I reread the thread with my glasses on...so the objects are in the on prem connector space and synced to the metaverse from what I can tell from the OP

[Chuckster]

Great, so it's pulling it into the metaverse but deciding not to project it to AAD. That's the fault.

 

But why....?

 

In the synchronisation rules editor, in outbound rules, what does 'out to ADD - Group Join' filter out, and can you check your groups against that critieria? (and the description pane looks right in terms of connected system, object type and link type of provision, and that it's enabled?

 

 

I'm in the Rule Editor and can see the 'out to ADD - Group Join' rule.

 

Can you tell me what it is that I am exactly looking for?

 

I'm unsure what's meant by checking my groups against the criteria.

[Chuckster]

[ATTACH=CONFIG]63055[/ATTACH]

 

Not Sure, OP this is what I think Mr Plumb is getting at, metaverse search by object type group, then seeing if we can see group and where attributes are coming from. I'm thinking you'll see groups but no CloudAnchor etc...

 

You're right, I don't see CloudAncor but there is a sourceAnchor.

[HPlum78]

Just out of interest you have run the troubleshooting tool?

 

https://docs.microsoft.com/en-gb/azure/active-directory/hybrid/tshoot-connect-objectsync

[Chuckster]

I ran the troubleshooting tool and I couldn't see any errors.

[DarkenRahl]

Have you tried a full import and full sync on the local AD connection? I usually run a delta sync and that works for most things except if i am importing new OUs and things. Even if i select the correct containers and things they won't show unless a full import and sync on the AD connection are run. Do not run an export on AD unless you want issues though.

[Chuckster]

I usually perform a delta sync but have on occassions ran a full import to no avail.

 

The miisclient.exe shows that everything is successfully being synced despite no evidence of the groups showing up in the Admin portal as well as Azure AD Portal.

[chaplic]

You're right, I don't see CloudAncor but there is a sourceAnchor.

 

CloudAnchor unsurprisngly comes from the cloud so that all adds up.

 

In terms of checks, I assume your 'out to AAD - Group Join' is not set to disabled?

 

[Chuckster]

The 'out to AAD - Group Join' is not set to disabled.

 

Weirdly enough, the AD groups now appearing in the 'mail-enabled security' section in the Admin Portal.

 

I haven't made any changes or reconfigured anything.

 

Seems like there must've been an error on Microsoft's side of things.

[chaplic]

I think that's called 'fixed during testing'! Intersesting to know if you have the cloudAnchor value on those groups now?

[Chuckster]

You'll be interested to know that the cloudAnchor value is now available. Very weird.

 

I can only assume it must certainly been an MS issue. Appreciate your all your help and suggestions @chaplic