System Center returns empty feed
Posted by Eric Hanig on 21 February 2014 12:57 PM



You could browse to the SPF endpoints, but any attempt to retrieve feeds for resources, such as Clouds, returned an empty feed. No error just an empty feed. This was the URL used in a browser to reproduce the error:


Curiously the SPF Admin endpoints worked fine. For example:


Overview of Troubleshooting Steps and Resolution


  • We checked the configuration of all the endpoints in VMM.

  • The endpoints were properly configured and were using the correct application pools - VMM and Admin respectively. Both app pools used the same service account: THECLOUDSERVICE\sccmospf_service         

  • We checked that this account was a member of VMM Admins: true

  • We checked that this account had dbo.owner role on the SPF database: true


At this point all this compared as identical to the set up in my working dev environment so we were still baffled as to the root cause. Fortunately I found an article on SPF tracing:


Following the instructions in this support article we enabled tracing:


  1. Log on to your SPF server and open an elevated command prompt or PowerShell window by right-clicking on the shortcut and choosing Run as Administrator.

  2. Type the following commands to create the trace definition:


    For Microsoft System Center 2012 Service Pack 1 (SP1) System Provider Foundation (SC 2012 SP1 SPF):

    logman create trace spfdebugtrace -p Microsoft-ServiceProviderFoundation-Core 0x8000000000000000 0x5

    logman update trace spfdebugtrace -p Microsoft-ServiceProviderFoundation-VMM 0x8000000000000000 0x5

    logman update spfdebugtrace -p Microsoft-Windows-PowerShell 0xf0010000000003ff 0x5


  3. Type logman start spfdebugtrace to start the trace.


We browsed to


  1. Stop the trace by typing logman stop spfdebugtrace
  2. Navigate to the trace location (C:\PerfLogs\Admin by default, see below), and convert the trace to a readable format by typing the command netsh trace convert spfdebugtrace_000001.etl.  Note that the exact file name of the ETL file may be different if you have taken multiple traces.  Type logman query spfdebugtrace and investigate the Outputlocation value to see the name of the latest ETL file.


Upon examination of the trace file we found the following error:


[0]17C0.0FBC::‎2014‎-‎02‎-‎21 18:08:34.531 [Microsoft-Windows-PowerShell]Error Message = The SQL Server service account does not have permission to access Active Directory Domain Services (AD DS). (Error ID: 2607)       Fully Qualified Error ID = 2607,Microsoft.SystemCenter.VirtualMachineManager.Cmdlets.ConnectServerCmdlet  Recommended Action =       Context:          Severity = Warning          Host Name = Default Host          Host Version = 3.0          Host ID = e1eb2633-7412-42a5-85c9-ccf4d7acb2e1          Engine Version = 3.0          Runspace ID = 9c1d8c84-6515-4fb5-9722-7bbc7fa95b2a          Pipeline ID = 7          Command Name = Get-SCVMMServer          Command Type = Cmdlet          Script Name =           Command Path =           Sequence Number = 100          User = THECLOUDSERVICE\sccmospf_service          Shell ID = Microsoft.PowerShell      User Data:    


The service account that the SQL service was running as could not read the CN=Servers container where the SCVMM server object resided. To rectify this we added the user to the Windows-based Hosting Service Accounts group which has read access to that container. After a restart of the SQL service were able to successfully browse the cloud resources using:

(0 vote(s))
Not helpful

Comments (0)