Troubleshooting Distribution Group not syncing to office 365

Follow me Often when we have directory synchronization setup between the on premise AD and the Office 365 we find that at times some objects do not get replicated or synced no matter how many times we resync and we find them listed under filtered connectors. This article is about the troubleshooting such situations and especially focusing on distribution group or mail enabled groups unable to sync. Why do my Group not sync ? Your group may have a sync conflict caused by a duplicate or invalid attribute. To identify this problem use KB 2643629. The technical contact for the tenant will likely have received an email with details about the offending attribute A member of the group having one of the above conflicts could also cause the group to not sync correctly The group is being filtered by the Directory Synchronization tool Following is a screenshot from KB 2643629, about default sync scoping rules:       MailEnabledGroup Can be filtered if any of the following condition is true Group has over 15000 members Display name is empty in which case you can follow KB 2508722 to fix the issue The group has not SMTP or primary SMTP address defined Group is placed under a filtered OU, Yes you can specify OU’s whose objects will not be synced to 365, read here about filtered OU’s   If you already fixed the above four conditions and still your issue is not resolved (Highly Unlikely 🙂 ) than please keep reading. Filtered Disconnectors It is quite likely that filtered connectors are causing the issue.To diagnose the issue with filtered connector follow the below steps Open...

How to Connect to Office 365 via PowerShell

This article explains How to Connect to Office 365 via PowerShell. There are lot of things you can do from the Portal, however for most of the tasks, you’ll need PowerShell. Please be sure to use it carefully as its a powerful tool, and can do a lot more than you can imagine. To login to Office 365 via Azure PowerShell, it’s advised to install the latest version of PowerShell. Prerequisite for Azure PowerShell is Microsoft Online Sign-in Assistant. You can download it from here. You can install this on Windows 8, Windows 8.1, Windows 7 (SP1)*, Windows Server 2008 R2 (SP1)* * You’ll need to install Microsoft .NET 4.5 framework or above along with Windows Management Framework 3.0 or above. Please click to know how to install .NET Framework 4.0 and Windows Management Framework 4.0 You can download the Azure PowerShell from the links below: Windows Azure Active Directory Module for Windows PowerShell (32-bit version) Windows Azure Active Directory Module for Windows PowerShell (64-bit version) Install the Sign-in Assistant, and Azure Active Directory Module, and launch Windows Azure PowerShell as Administrator (ensure that you Run it as Administrator) Run the following commands to connect with your Office 365 account: Set-ExecutionPolicy = unrestricted $cred = Get-Credential -Credential $user Enter the credentials for your Office 365 Admin account and hit OK. Import-Module MSOnline Connect-MsolService -Credential $cred $msoExchangeURL = “https://ps.outlook.com/powershell/” $session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri $msoExchangeURL -Credential $cred -Authentication Basic -AllowRedirection Import-PSSession $session Now you are connected to Office 365 via PowerShell. Please do not forget to share your feedback, or ask us a question by clicking here. Follow...

Missing Start-OnlineCoexistenceSync when running DirSync via Powershell

Follow me issing Start-OnlineCoexistenceSync when running DirSync via Powershell: Recently working on an environment, I noticed that the Start-OnlineCoexistenceSync is missing when trying to re-sync the Active Directory with Office 365 via PowerShell. This was very helpful when we need to sync the changes manually to Office 365. You’ll also notice that DirSyncConfigShell.psc1 is no longer present in its default location of C:\Program Files\Windows Azure Active Directory Sync. This is due to the change version of the Directory Sync Tool currently running on your Computer. To know more about the Directory Sync tool revision history, click here. When you try to run command to sync the changes, you get the following error message: PS C:\> Start-OnlineCoexistenceSync The term ‘Start-OnlineCoexistenceSync’ is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again. At line:1 char:28 + start-onlinecoexistencesync <<<< + CategoryInfo          : ObjectNotFound: (start-onlinecoexistencesync:String) [], CommandNotFoundException + FullyQualifiedErrorId : CommandNotFoundException PS C:\> In order to manually sync the directory changes, follow the following steps: Open PowerShell Type: Set-ExecutionPolicy Unrestricted and hit return. Type: Import-Module DirSync and hit return. Type: Start-OnlineCoexistenceSync and hit return. Now that you have successfully forced the Directory Sync with Office 365 for changes. You may now want to check what’s synced and if it at all worked. Open the MIIS Client: “C:\Program Files\Windows Azure Active Directory Sync\SYNCBUS\Synchronization Service\UIShell\miisclient.exe” On the main screen that opens by default, you’ll see what all has been synced, and its detailed result. There are different section to this...

Dirsync in Multi Forest Multi domain environment

I recently got an opportunity to setup directory sync with password sync for a big organization.  During this setup I realised that alot changes when the scope increased from 200 users to 50000 users. I faced multiple challenges and learnt alot, to make it simple for other, I am publishing my learning here. hope it helps   Office 365 Directory Sync with password Sync: Are you considering password sync with directory sync for your big multi-domain environment, you may face following issues: Issues with configuring Directory Sync: The user name or password is incorrect Unknown error (0x80005000) Directory Sync tries to reach domain controllers of all the child domains in the environment to give permission to MSOl user, and if somehow DirSyn is not able to reach some domain controller or the domain controller it is reaching is not responding properly. You may face any of the above error, then you need to find out which domain controller is creating problem, net mon can help you with that. Start Netmon trace and then run DireSync, expend the configuration.exe section, the last entry in this section would tell, you DirSync could not proceed with which DC, if you expend it, you would get information about the reason.   The above example shows that the child Domain controller is  not able to authenticate the Enterprise admin ID that is being used for configuring Directory Sync, it seems that the DC is  not able to communicate with Root domain controller. In this way you can find out, which domain controller has got problem, you can fix it. If you have multiple domain...

Full Password Sync after installing dirsync with password sync

Problem We have enabled password sync with directory sync for some client, it was setup correctly but only was syncing password for users who reset their password and not for all the users. Solution We found following solution to force a full password sync Note: You must have Directory Sync tool version 6438.0003 or greater installed in order to perform the process below.   On your DirSync machine, run the following .psc1: C:\Program Files\Windows Azure Active Directory Sync\DirSyncConfigShell.psc1 In the Powershell console that loads, run the Set-FullPasswordSync cmdlet Load Services.msc Restart the Forefront Identity Manager Synchronization Service Service. Once this is complete, you should see a series of EventId=656 (Password Sync Requests) and EventId=657 (Password Sync Results) indicating that your full password sync has kicked off. Update: During a recent 365 migration we used the latest version of Dirsync tool 6.8.6.2 . We have discovered that the file DirSyncConfigShell.psc1 is no more present and as it looks it did sync up all the passwords automatically during the first sync, so we actually didn’t even need this script.  ...