SPF Part 5 - Registering the Service Provider Foundation Endpoint

Overview

This is the final step in registering the System Center 2012 R2 Service Provider Framework endpoint with the Azure Pack management server. Compared to the previos steps, it's a much smaller piece of work so it should be over quickly.

Other posts in this series are

• Part 1 - Installing Windows Server 2012 R2 Preview
• Part 2 - Installing Windows Assessment and Deployment Toolkit 8.1 Preview
• Part 3 - Installing Virtual Machine Manager 2012 R2
• Part 4 - Installing Service Provider Foundation 2012 R2
• Part 5 - Registering Service Provider Foundation with Windows Azure Pack
• Part 6 - Installing System Management Automation
• Part 7 - Register Service Management Automation with Windows Azure Pack 

Configuring

Troubleshooting

Note: The username is potentially case-sensitive. We had a few problems here registering the endpoint, and we used the following troubleshooting steps as follows to try to identify the problem. However, once we used the correct case in the username (i.e."va\Administrator" instead of "va\administrator") the endpoint registered successfully. We're not sure if this was just a concidence, but since it resolved the issue we were unable to investigate further.

• First, enable Failed Request Tracing in IIS on the Service Provider Framework server (VASCM01 in this case). Configure a tracing rule for the SPF website in Internet Information Services Manager, for all content with status codes 200-999 and for all providers. Then, enable Failed Request Tracing from the Actions pane for the SPF website.

• Next, try to configure the endpoint again in the Azure Pack management server. If this still fails, check the failed request trace log folder on the SPF server ("%SystemDrive%\inetput\logs\FailedReLogFiles\W3SVC2" by default). This should contain some "fr######.xml" files. Open the highest-numberer file in Internet Explorer and check if you see the following error:

  
        MODULE_SET_RESPONSE_ERROR_STATUS
        ModuleName - ManagedPipelineHandler
        Notification - EXECUTE_REQUEST_HANDLER
        HttpStatus - 401
        HttpReason - Unauthorized
        HttpSubStatus - 0
        ErrorCode - The operation completed successfully. (0x0)
  

  
  
• Check the "Compact View" on the trace, and check the RequestURL in the first trace event is "https://vascm01.va.local:8090/SC2012R2/Admin/Microsoft.Management.Odata.svc/"
  
  
• Open Event Viewer and check the "Event Viewer -> Application and Services Logs -> Microsoft -> Windows -> ManagementOdataService -> Operational channel" log. We saw an error logged with the following details:

  
        - <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
          - <System>
              <Provider Name="Microsoft-Windows-ManagementOdataService" Guid="{60B4C807-9E58-40D0-A608-9A60DFFDD6B9}" />
              <EventID>4004</EventID>
              <Version>1 </Version>
              <Level>2</Level>
              <Task>2</Task>
              <Opcode>11</Opcode>
              <Keywords>0x8000000000000008&lt/;Keywords>
              <TimeCreated SystemTime="2013-07-29T20:39:07.612582900Z" />
              <EventRecordID>18</EventRecordID>
              <Correlation ActivityID="{7212F460-8C7E-0000-C85B-13727E8CCE01}" />
              <Execution ProcessID="2392" ThreadID="3568"/>
              <Channel>Microsoft-Windows-ManagementOdataService/Operational
              <Computer>VASCM01.va.local
              <Security UserID="S-1-5-20" />
            </System>
          - <EventData>
              <Data Name="userName">va\Administrator</Data>
              <Data Name="authenticationType">Basic</Data>
            </EventData>
          </Event>
  

  
  
• On the Azure Pack management server, open Internet Explorer and try to navigate to the url in the error (i.e. "https://vascm01.va.local:8090/SC2012R2/Admin/Microsoft.Management.Odata.svc/"). This should load an document containing an OData xml document as per the screenshot below.