I’ve recently blogged about using DIRSYNC to connect your local Active Directory (AD) to Office 365. It is one of the most popular posts on this blog and you can find it here:
I have followed this up even more recently with a post about the updated DIRSYNC tool called Azure Active Directory Sync Services and you can find that here:
Finally, I have posted about the preview of the tool that is replace Azure AD Sync Services called Azure AD Connect and that you can find here:
You may think these are the only tools used or required to copy you local AD to Office 365 services. They aren’t. Hopefully, you know that Yammer is now included free with many Office 365 plans and Yammer also contains user information. In fact it is possible to copy some of this user information from your local AD.
The place to start is the:
but before you get too far into the weeds what benefits does Yammer DIRSYNC provide?
As the guide says, after you set up this integration product, users will be able to be automatically:
– removed from your Yammer network when you disable them in AD
– invited to your Yammer network when you add them to AD
– updated with new profile information when you update their attributes in AD
and that is basically it. My personal take on this is that Yammer DIRSYNC doesn’t really provide a lot of benefit for smaller organisations that don’t have thousands of AD users and who don’t have large amounts of turnover within their staff. If that is your business or your customer’s business then you can stop reading here and not have to worry about this any more.
However, I hope that you are at least somewhat curious as to how the whole configuration process of Yammer DIRSYNC is completed, and you might also be interested in some of the ‘challenges’ I faced getting this to work. That, at least, I hope makes you read through the volume of information I’ll detail here with the process I went through.
This attempt to configure Yammer DIRSYNC was completed in a test environment. I created a new clean Office 365 E3 tenant. I installed a new clean Windows Server 2012 R2 server in Azure. I created a new set of local AD users and used AD Connect (Preview) to get them copied to the Office 365 tenant. I then assigned them licences. All of this was prior to getting Yammer DIRSYNC operational.
So the plan was now to install Yammer DIRSYNC on the same server as Azure AD Connect (Preview), which as it turns out is the Domain Controller (DC). Of course best practice should always be to install any Office 365 user syncing tool (Office 365 DIRSYNC, Azure AD Services, Azure AD Connect, etc) onto a separate members server. The same would also go for Yammer DIRSYNC, however not all businesses have this luxury when it comes to rolling out addition on premises hardware do they? Also to my mind it doesn’t make sense to roll out more on premises hardware when the real desired aim to eventually move everything to the cloud. Thus, in this case, everything will reside on the Domain Controller.
When a user is invited to join a Yammer network they receive an email like shown above that provides them a link to get started with Yammer. When you enable Yammer in Office 365 using this process that I also recently detailed:
Users won’t automatically receive such email invitations, they just need to select the Yammer icon from their app launcher inside the Office 365 portal. Thus, if you are looking to drive Yammer adoption throughout your organisation, having an email automatically sent to new users telling them about Yammer can provide a benefit. This you can do when Yammer DIRSYNC is enabled.
The first step in enabling Yammer DIRSYNC is to create a service account to be used by the DIRSYNC process. Thus, I went into my local AD, created a new user called Yammer Service and allowed that to sync to Office 365 (as I have Office 365 DIRSYNC enabled).
An interesting question gets raised here. What securities does this Yammer service account require both on premises and in Office 365? From what I can determine, locally, the Yammer service account can be just a normal user in the local AD and in Office 365 it has to have at least a mailbox license. This means if you only have Office 365 Suite licenses (i.e. SharePoint, Exchange, Skype for Business, together) you will need to either dedicate a complete license for this service account or purchase a stand alone Exchange Online license and add this to your tenant (which you can do now as Office 365 plans allow you to mix and match plans in one tenant).
Once the Yammer service account has been created in local AD, synced to Office 365 and assigned a license you simply login as that account and then navigate to Yammer so the service account is now an activated Yammer user. All this is the normal way you create and activate any Yammer user.
The next step is to login as an existing Yammer verified admin (typically an Office 365 Global Administrator) and select the Yammer enterprise admin area. Once there you will find an Admins option as shown above. Here you promote the new Yammer service account to be a verified Yammer admin.
Doing so means that the Yammer service account will have full control over Yammer (i.e. a Yammer admin) without the need to be an Office 365 Global Administrator (which gives them full control over more that just Yammer in Office 365).
Once you have added the Yammer service account as a Yammer admin you will also need to select the Grant Verified Admin button above to give that account full rights in Yammer.
You should now see the Yammer service account (here called Yammer Service) appear as a Current Admin as shown above.
What I then tried to do was go back into the Office 365 licensing and remove the license for the Yammer service account as I wanted to conserve licenses given I was using an Office 365 suite. Problem is when you do that (i.e. assign no license) you also don’t appear to get a Yammer license. You also don’t get a mailbox license which it turns out you’ll need later.
So, any Yammer service account requires at least a mailbox license in Office 365 from what I can determine.
The next step in the process is to download the Yammer.Dirsync.Setup program to your local on premises server on which the sync is gong to take place. You can download this software from:
You kick off the installation and change the install directory if desired. if not then it will install into:
c:\program files (x86)\yammer\directory sync\
Select the Install button to continue.
You’ll then see the software being installed.
When that process is complete you’ll see the above screen. You need to insert the Yammer service account and password in the top part of the options to the right.
Now as you can see, when I did this I received the error Unexpected login failure even though I knew the password was correct. The solution lies here:
Which in essence this is telling you that you need to generate a unique ‘app’ password for this account to move forward.
To do that you’ll need to log back into Yammer as the service account and select the three dots in the top right and then Apps from the menu that appears.
In the All Apps area towards the bottom of the page select the Yammer tab.
Locate an app and select it by name. Here I located the Windows Phone app and select the hyperlink Windows Phone.
This will show you something like the above. The information you require is in the lower left of this window.
here you should see your Yammer service account email and a temporary password. You will need to use this back with the Yammer DIRSYNC program.
Note that the app password is only available for a short period of time, so copy it from here and then immediately head back to the Yammer DIRSYNC configuration.
Place this Yammer app password in the password field and select the Login button to continue.
I next received the above message which I have no idea what it meant so I simply selected OK to continue.
The next step is to put in the details for your local domain. Here I specified my domain controller and select the Login button.
Doing so then placed my domain controller in the window. Strangely, there is no continue button so I simply selected Validate from the options on the left to proceed.
Now select the Start Validation button.
The validation process will then commence.
At this point I received the error:
Invalid or missing attributes for required attribute(s): mail
After much trial and error I discovered that the apparent reason for this validation error is because the email attribute for the user is not set in the local AD. You can see the location of the attribute in the above screen shot of a users properties in AD.
In an environment with no local Exchange server you have to wonder how this field is going to get populated? Clearly, in my case it has to be done manually. That could be quite a pain if you have a lot of users!
Now, with all the users in the local AD having their email field populated I could successfully complete the validation step as shown above.
Again, no real next button here so select Sync from the options on the left to continue.
To continue you need to enter mail server and user details as shown above. This is the reason why you need to ensure that the Yammer service account has at least an Exchange Online license.
The server in this case will be Office 365 which for SMTP is:
and Enable SSL should be checked.
A number of articles I found said that you need to ensure the FromAddress field in the EmailNotificationSettings section in the file globalsettings.config.json should be manually changed from the default of email@example.com to being the same as in the Username field above, which should be the email address of the Yammer service account.
When I searched the directory that Yammer DIRSYNC was installed but I couldn’t find the globalsettings.config.json file. Turns out it is actually located in:
by default. You may, as I had to, change the default view in Windows Explorer to actually see and navigate to the directory.
Turns out there is now a Yammer DIRSYNC icon in the system tray that if you right mouse click on show a menu as seen above.
If you select About from the menu that is displayed you will see the above dialog appear.
If you then select the Advanced Configuration button a Windows Explorer window will be opened at the location of the globalsettings.config.json file which again is located at:
You can open the json configuration file with notepad and make the appropriate change from firstname.lastname@example.org to the email address of the Yammer service account you are using. Close and then save the json configuration file.
You then return to the Yammer DIRSYNC installation program and complete all the details.
You should also then be able to select the Send Test Email button to verify everything is working.
After which you should receive a green check mark as shown above.
To proceed, select the Apply button to the right which should now be available.
The Enable Sync button at the button of the window should now be available and The Status should read Not Running as shown above.
Select the Enable Sync button to proceed.
You should see the Status field runs through a few options such as Validating Settings as shown above.
If there are no issues the Status should say Running as shown above.
You can close the Yammer DIRSYNC program and it will continue to run in the background. You should find a Yammer DIRSYNC icon in the system tray which you can right mouse click on and select Open from the menu that appears to view the program again if needed.
Here is the Microsoft documentation on installing the Yammer DIRSYNC application:
Now according to this:
The Yammer Directory Sync utility now queries Active Directory every 60 minutes and adds, updates, and suspends users, as appropriate.
The log files:
service.log – contains sync errors
ui.log – contains UI errors
are located in the directory:
along with the json configuration file.
What should happen after a a period of time is that if you look in Yammer as an admin under the Directory Integration menu option you should see that it has been enabled as you can see above.
If you return to the on premises server you installed Yammer DIRSYNC on you will find a service called Yammer Directory Sync 3.0 as shown above.
Now, what I found was that Yammer DIRSYNC service was taking a very long time to actually sync. This was probably due to the fact that the first sync is quite large but my overall experience is that Yammer sync is quite slow and there is now way to force it like you can with Office 365 DIRSYNC. You simply have to wait.
When I look at the service.log file after this et I was seeing an error:
INFO [2015-06-11 23:18:28,807] – Scheduled interval set to 60 minutes
INFO [2015-06-11 23:18:28,807] – Starting with sync enabled: False
INFO [2015-06-11 23:18:44,224] – IPC Server running successfully
INFO [2015-06-11 23:19:51,595] – Registering callback for Yammer.DirSync.Core.IPC.Transport.NamedPipeServerBus+CallbackReference
INFO [2015-06-11 23:20:06,842] – Changing sync enabled to True
ERROR [2015-06-11 23:20:06,880] – Error saving enabled state
System.UnauthorizedAccessException: Access to the path ‘C:\ProgramData\Yammer\DirSync\globalsettings.config.json’ is denied.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy, Boolean useLongPath, Boolean checkHost)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share)
at Yammer.DirSync.Core.FileSystemRepositoryBase`1.Save(T settings)
at Yammer.DirSync.Core.FileSystemRepositoryBase`1.Save(Action`1 update)
at Yammer.DirSync.Service.ScheduledSyncService.SetEnabled(Boolean status, Boolean interrupt)
INFO [2015-06-11 23:20:07,014] – Starting sync because sync state changed.
After another long period of troubleshooting what I found the solution that removed this access issue from the log file was changing the Yammer Directory Sync service to run as a domain administrator rather than the Network Service.
The other issue I saw a lot of in the log was:
Waiting for previously running sync to complete.
So in the end I left the sync process running and went away to do other things.
Eventually after at least 4 hours I returned to find that syncing was now successful.
INFO [2015-06-12 00:09:39,647] – Sending remote job Suspend with 1 users
INFO [2015-06-12 00:09:40,674] – Data received for job syncie-2-e2007c89-007f-44c6-8bd8-8e66b4ab6e9e, processing has begun.
INFO [2015-06-12 00:09:41,589] – Waiting for previously running sync to complete.
INFO [2015-06-12 00:49:51,074] – Yammer Directory Synchronization has completed.
1 Users Added
1 Users Updated
0 Users Suspended
0 Pending Users Deleted
I find it interesting that it took at least 4 hours to initially sink a clean demo system with only a handful of users! Again, my experience has been that Yammer DIRSYNC is quite a slow process.
INFO [2015-06-12 00:49:51,157] – Sync attempt finished with status: Success
WARN [2015-06-12 01:50:03,650] – Some attributes do not exist in directory CIAOPS-DC2: title, physicalDeliveryOfficeName, telephoneNumber, mobile, department, proxyAddresses
INFO [2015-06-12 01:50:03,774] – Reading directory users
INFO [2015-06-12 01:50:09,522] – Completed reading directory users. 0 total users.
INFO [2015-06-12 01:50:09,897] – No changes for sync phase CreateOrUpdate
INFO [2015-06-12 01:50:10,278] – No changes for sync phase Suspend
INFO [2015-06-12 01:50:10,278] – Yammer Directory Synchronization has completed.
0 Users Added
0 Users Updated
0 Users Suspended
0 Pending Users Deleted
As you see from the subsequent sync log above I was still get warnings which I wasn’t really sure what they meant or how to fix them, so I ignored them.
However, now after I created a new user in the local AD, allowed it sync to Office 365 via Office 365 DIRSYNC, then assign an Office 365 license, waited some more for it to sync to Yammer, the new user did receive for Yammer via email as you can see above.
Phew, that is a lot of work just to get that one email!
I then also deleted a user from the local AD, saw it removed from Office 365 and also no longer be able to login to Yammer so I am confident that the deletions in Yammer DIRSYNC also work as expected.
At this point I started to get more errors occurring with the Yammer DIRSYNC program to the point where the Yammer sync process would stop. I did some initial research on what might be causing these issues but abandoned that after a short while as I couldn’t really see much ROI in Yammer DIRSYNC.
At this point I abandoned further work on Yammer DIRSYNC as I had gotten it working.
The smaller the organisation the less of a need for considering Yammer DIRSYNC. I don’t believe it provides much real value unless you are adding or removing lots of users from you AD on a regular basis.
I found a lot of issues getting Yammer DIRSYNC operational and keeping it running in a small test environment. Maybe I overlooked some things or did stuff wrong, but I really couldn’t find a lot out there to help. I have included some helpful sites below in the references section.
It seems to me that the Yammer single sign on experience will be driven in future from Office 365 and Azure rather than a local application on a server syncing local AD. Hopefully something Azure AD Connect will one day incorporate all the synchronization Yammer requires. I expect this to be the case as Yammer becomes more and more integrated with Office 365.
The synchronisation of information to Yammer is very slow and only happens once an hour at most. I found now way to be able to force this synchronisation.
If you do have issue with Yammer DIRSYNC don’t be afraid to raise an Office 365 support ticket. The Yammer support people were very obliging and knowledgeable.
How to audit users in Yammer – https://technet.microsoft.com/en-us/library/dn783348.aspx
Plan for Yammer DIRSYNC – https://technet.microsoft.com/en-us/library/dn799027.aspx