The default interval for Windows Azure Active Directory Sync (DirSync) synchronisations is 3 hours. If for instance, your Active Directory has lots of changes you probably want to consider shortening the sync interval.
The schedule can be modified by changing the “Microsoft.Online.DirSync.Scheduler.exe.Config” configuration file. Before proceeding to make any changes to the sync interval you should evaluate how long it takes to complete synchronisation. You can do this by reviewing the application event log for entries that indicate when sync has started and completed.
To modify the configuration file open “C:\Program Files\Windows Azure Active Directory Sync\Microsoft.Online.DirSync.Scheduler.exe.Config” in Notepad. You will then need to modify the value of the “Synctimeinterval” key – the notation of this is Hours:Minutes:Seconds.
Save the configuration file and restart the “Windows Azure Active Directory Sync Service” Windows Service (via PowerShell Restart-Service MSOnlineSyncScheduler) to apply this change.
When configuring Windows Azure Active Directory Sync (or DirSync as it was previously known) it’s useful to be able to run various synchronisation tests. The default synchronisation schedule is 3 hours so unless you want to wait you will need to force a full synchronisation using PowerShell.
To do this you need to load the Windows Azure Active Directory Sync PowerShell module and run a cmdlet. Start by navigating to “C:\Program Files\Windows Azure Active Directory Sync” in PowerShell and then run “.\DirSyncConfigShell.psc1” from this directory. This will launch a new PowerShell console with the Windows Azure Active Directory Sync PowerShell module loaded (Add-PSSnapin Coexistence-Configuration). Then to force a full synchronisation you need to run the Start-OnlineCoexistenceSync cmdlet.
You can verify that synchronisation has occurred by reviewing the application event log on the server running DirSync – there should be several items in the log such as “Directory Synchronization, Event ID – 114, Export cycle completed”. There is also a status of the Active Directory Synchronisation on the “Users and Groups” page in the Office 365 admin portal. There are also two other ways to see the status of synchronisation jobs which I will go into in more detail in a later post but these include using the Forefront Identity Manager (FIM) client and Fiddler web debugging proxy.
You can create a shortcut to “C:\Program Files\Windows Azure Active Directory Sync\DirSyncConfigShell.psc1” on the desktop for ease of administration. I, however, take this one step further and create a shortcut to perform a synchronisation as well. Create a shortcut with the following target below.
Since our Office 365 tenant was upgraded we’ve been experiencing difficulties with our users signing into Lync 2013. When these users tried to sign in, the Lync 2013 client returned an error saying it could not communicate with the server. The users received the following error.
“The server is temporarily unavailable.”
Firstly our IT guy raised this issue with Office 365 through a support ticket some months ago when we started experiencing this issue. There was some back and forth communication however no solution was ever found. As far as I know, the issue is still open.
A few months passed and I was getting more and more frustrated that I wasn’t able to communicate with my team using Lync so I decided to spend some time and see if I could find a solution myself.
Here is some other background information about our configuration…
Domain joined machines using Office 2010 were ok
Mobile clients were fine
All users are part of a Windows 2008 R2 Active Directory domain that is not connected to Office 365 through ADFS or DirSync
User accounts experiencing the issue have spaces in their account name (Joe Bloggs)
The Office 365 DNS records are set up correctly – even broke out fiddler and checked my Lync client was reaching it’s end-points correctly which they were
Our internal domain is using an unresolvable .local address
After reading countless forum posts I noticed many others were reporting similar issues and the issue seemed quite widespread.
So after some research, I read that Microsoft was aware of the bug and did not expect it to be resolved until September time. Others were saying that it worked with users whose machines were not joined to an Active Directory domain. This leads me to think about try using a local account and there it is folks – my solution!
This is less of a solution but more of a workaround whilst Microsoft fix this issue once and for all!
Kill the “lync.exe” process (use Task Manager to end the process)
Create a new local user account on the computer (lusrmgr.msc)
Add this account to the Administrators security group
Navigate to the Program Files directory for Lync 2013 (C:\Program Files\Microsoft Office 15\root\office15\)
Whilst holding the SHIFT key down, right click on the “lync.exe” application and select “Run as different user”
Enter the username and password of the account that was just created
Lync 2013 should open and launch the “New user configuration” window
Sign in to Lync 2013 with your Office 365 username and password
The Lync 2013 client should now happily work
I should highlight that some features such as creating a Lync meeting through Outlook might not work due to the processes running as different user accounts. Try it out for yourself and see.
Fingers crossed Microsoft fix this issue pretty soon!
Update: July 2015 Some readers have kindly brought to my attention that after reading this post, they were concerned as to data security. Having read this post back, some two years on, I can see how some misunderstanding can be made from this post, so I’ve updated the article to reflect this. Finally, the disclaimer on this site has always suggested you validate the information with secondary sources. Microsoft also publishes information around how they protect and secure data in Office 365 on their Office 365 Trust Center site – please use this for any concerns around data protection. Additional information: Partner admin centre
At the time of writing this post, I was working for a “Microsoft Cloud Accelerate” partner. As a result of this, certain user accounts within our own Office 365 tenant were able to provide support to our customers, they would need to explicitly agree to the partner providing ‘delegated administration’ to their Office 365 tenant.
Delegated administration allows selected users to perform ‘delegated administration’ functions to Office 365 tenants (those that have allowed this) using their own credentials. This could be creating support tickets, managing users accounts and resetting passwords to configuring their services – it is also possible to support customers with SharePoint Online.
All of this of course, from setting up ‘delegated administration’ through to supporting customers with this function should be always be agreed and authorised with the customer. A key point to make clear with your customers is that by establishing the ‘delegated administration’ trust, the partner has access to provide ‘delegated administration’ to Office 365 services, subscriptions and SharePoint Online for example in their Office 365 tenant.
Create a delegated administration offer for your customers
To create a delegated administration offer for your customers you must do the following:
Click on the link “Send delegated administration offers” link.
Copy the information that appears in the window and sends this offer on to your customer(s). The offer isn’t customer-specific so you can reuse this offer for multiple customers.
The customer must then click on the link they receive and proceed to authorise you the partner as a delegated administrator of their Office 365 tenant. You will then receive an email confirming they have configured delegated administration.
In order for users within the partner organisation to perform delegated administration, they must be given administrative access to companies you support.
To do assign users with the permission they need you must complete the following:
Navigate to the “Users and groups” page.
Find the user you wish to give this permission to and select “Edit”.
From the “Settings” page scroll down to the “Assign administrative access to companies you support” and select “Yes”. This will then give the user access to the “Partner overview” page.
Then choose the appropriate role, and then click “Save”. The full administration role has the same privileges as the global admin role for the companies you support. The limited administration role has the same privileges as the password admin role for the companies you support.
Performing delegated administration
To do administer a customers Office 365 tenant you must use the “User and domain lookup tool” that is available on the “Partners” tab. Here you can enter your customer’s information it will bring back information about the tenant such as the subscription type and contact information. This page also displays three links to “Administer on behalf of”, “Create service requests” and “Show all administrators”. The “Administer on behalf of” link will then takes you to the “Office 365 admin centre” where you can manage and administer their tenant.