Just before Christmas, I upgraded my Windows Server 2012 Essentials server at home to Windows Server 2012 Essentials R2. After re-deploying the server as R2, I re-configured my Windows Azure Backup and my Office 365 Integration. Since re-configuring the Windows Azure Backup, I’ve been having a problem with the integration with the Windows Server 2012 Essentials R2 Dashboard.
Just before Christmas, I upgraded my Windows Server 2012 Essentials server at home to Windows Server 2012 Essentials R2. After re-deploying the server as R2, I re-configured my Windows Azure Backup and my Office 365 Integration. Since re-configuring the Windows Azure Backup, I’ve been having a problem with the integration with the Windows Server 2012 Essentials R2 Dashboard.
The Windows Azure Backup Integration is dependant on two things: The Windows Azure Backup Agent (cbengine) and the Windows Azure Backup Integration Service (WSS_OnlineBackupProviderSvc). The Windows Azure Backup Integration Service is dependant on the Windows Azure Backup Agent.
With both services started, launching the Dashboard and accessing the Online Backup tab is empty reporting No Data.
When this occurred, I observed that the Windows Azure Backup Integration Service would stop after launching the Dashboard. Restarting the service and the Dashboard did nothing except cause the service to crash again. This crash could be observed in the Application Event Log as follows:
Error .NET Runtime Event ID 1026
Application: OnlineBackupProvider.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.NullReferenceException
Stack:
at Microsoft.WindowsServerSolutions.DataProtection.OnlineBackup.OnlineBackupJob.Equals(Microsoft.WindowsServerSolutions.DataProtection.OnlineBackup.OnlineBackupJob)
at Microsoft.WindowsServerSolutions.DataProtection.OnlineBackup.OnlineBackupProviderCore+<>c__DisplayClass46`1[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]].<GetOnlineBackupObjectUpdateList>b__44(System.__Canon)
at System.Linq.Enumerable.FirstOrDefault[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]](System.Collections.Generic.IEnumerable`1<System.__Canon>, System.Func`2<System.__Canon,Boolean>)
at Microsoft.WindowsServerSolutions.DataProtection.OnlineBackup.OnlineBackupProviderCore.GetOnlineBackupObjectUpdateList[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]](System.Collections.Generic.List`1<System.__Canon>, System.Collections.Generic.List`1<System.__Canon>)
at Microsoft.WindowsServerSolutions.DataProtection.OnlineBackup.OnlineBackupProviderCore.UpdateOnlineBackupData()
at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
at System.Threading.ThreadPoolWorkQueue.Dispatch()
Searching online for the issue turned up nothing, so I decided to report the issue on the TechNet community forum (http://social.technet.microsoft.com/Forums/en-US/eb718279-3da9-4544-9e0f-50b0ba440ef5/windows-azure-backup-integration-service-fails?forum=winserveressentials) and Pan Chen from Microsoft turned up with an unexpected answer.
The Windows Azure Backup Agent logs the status of backups and their success or failure to a separate event log in Applications and Services LogsCloudBackupOperational. Pan believed that an unexpected or corrupt event log entry was preventing the integration service from reading this event log properly.
I cleared the log file, restarted the Windows Azure Backup Integration Service and re-launched the Dashboard, and after some delay, presumably while the Dashboard pulled new data from the Azure Backup Agent, I am now able to see the status data in the Dashboard.
My personal feeling is that a bad event log entry shouldn’t cause this integration to fail, but suffice to say, it looks like it does.