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 you’ll 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 a synchronisation. You can do this by reviewing the application event log for entires that indicate when a 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 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 a 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 a 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.
I’ve been there at least once or twice and I’m sure others have as well – where we’re happily modifying the web.config on half-a-dozen or more servers and as Steve so elegantly describes it, we “fat finger some random part of a web.config change” causing complete devastation to the running of SharePoint and to your progress. Well not any more my sysadmin friends, not any more not with this tool. It allows you to edit the connection string, people picker wildcard, membership provider, role provider details within the web.config for a specific web application. It then creates a backup copy and updates the web.config across all the servers in your farm through a timer job which is a really neat trick.
Having done this now on several occasions I thought I was pretty confident flying through the steps necessary within an hour or so…the occasional error would sneak in and then I would spend as long again troubleshooting the configuration. Steve’s Forms Based Authentication Configuration Manager has now completely removed the chances of any errors sneaking in and will make me even quicker configuring FBA in SharePoint. Thank you Steve!
Ok, so this has bothered me for sometime – until now, there has been standalone OneDrive for Business SkyDrive Pro client. Users have had to install Office 2013 to experience the new way of synchronising files with SharePoint.
The reason it has bothered me is that it is such a limitation to require the client to be installed in this way. For most organisations it is just not feasible to install the latest and greatest software from day one due to budgets and wider IT constraints, resources and policies where software has to be tested, licensed and patched for example.
Let’s put that aside now as I’m really happy to see that Microsoft released a standalone installer for the OneDrive for Business SkyDrive Pro client earlier this week.
If you need to check what version of SharePoint server your Office 365 tenant is running especially during the Office 365 and SharePoint Online service upgrade (aside from checking through the Admin Portal via https://portal.microsoftonline.com) then you can add the following /_vti_pvt/service.cnf to the end of your SharePoint site – as shown below.
The page will output two lines of text from which we can determine the version of the SharePoint servers. If the second row starts with 14 then you are running SharePoint 2010, if it starts with 15 then you are running SharePoint 2013.