I'm creating new users in on-prem Active Directory using PowerShell, and these users sync to Azure. I need to add these new users to existing Microsoft 365 groups. I can use the command `Add-EntraGroupMember -GroupId $group.Id -MemberId $user.Id` for this, but I'm looking for a way to do it before the sync because I can't retrieve the user ID until they are synced.
I thought about generating a CSV file of the new users during their initial creation and running a separate script a few hours later to add them to the O365 groups after the ADSync process. However, I'm wondering if there's a more efficient option available.
4 Answers
What about using group writeback and adding the users to the group during their initial creation in the on-prem environment?
Why not just perform the sync right after creating the users and then add them? That way, you'll have their IDs available immediately.
Any idea how long I need to wait after running `Start-ADSyncSyncCycle` before the user appears in Azure? I've read it can take anywhere from 2 to 30 minutes. Since these users come in groups of 20-30, syncing each user individually seems excessive, so I'd still need to batch them somehow.
You can't access the userID until after the sync since it only gets generated when the user object is created. It might be worth considering group writeback to keep your M365 groups in sync with the AD groups, if that's an option for you.
I recommend switching to Graph for this task, as it's generally more reliable than Entra. You can use the following commands:
`Connect-MgGraph -Scopes 'User.Read.All'`
`$mguser=Get-MgUser -userid "[username]"`
`new-mggroupmember -GroupId [YourGroupID] -DirectoryObjectId $mguser.id`
For multiple CSV imports, you'd use a foreach loop to add each user’s MG ID to the corresponding groups.
Glad to hear my idea isn't too out there! Is there a specific reason why the Graph calls work better than the Entra commands? I thought Entra was just a more user-friendly wrapper around Graph.
You might want to explore dynamic groups for this situation. They can simplify user management significantly.
I'd go that route too, but unfortunately, it requires a premium license that the business isn't willing to invest in.
Are you suggesting I create the users directly in Azure and then write back to on-prem? That could work, but it would disrupt my current script since it relies on having an on-prem user before proceeding. Plus, this approach requires a P1 license, which I don't currently have.