Search Engine: Elastic

Article ID: 115165, created on Nov 20, 2012, last review on Jul 14, 2018

  • Applies to:
  • Operations Automation 6.0
  • Operations Automation 5.5
  • Operations Automation 5.4
  • Business Automation 5.5
  • Business Automation 5.4


Operations Automation (OA) background task to provision a new Office 365 subscription fails with this timeout: Method edit_customercalling failed. Reason:Timeout exception. Customer subscriptions are not ready yet, waiting for request completion.

The task also contains an XML request with a subscription ID that is not ready, as in the example below:

Task name               APS application 'Microsoft Office 365', id 101, instance 102 -> service 'customer', instance 103: executing configuration script, site ''
Output  Application configuration script reported errors: '
Method edit_customer calling failed. Reason:Timeout exception. Customer subscriptions are not ready yet, waiting for request completion. _**XML Payload**_: _Request_: <s:Envelope xmlns:a="" xmlns:s=""> <s:Header> <a:Action s:mustUnderstand="1"></a:Action> <a:MessageID>urn:uuid:12345678-42b8-abcd-9d3f-b7a0fce2bd78</a:MessageID> <a:ReplyTo> <a:Address></a:Address> </a:ReplyTo> </s:Header> <s:Body> <PlaceOrder xmlns=""> <request xmlns:d4p1="" xmlns:i=""> _**<d4p1:CustomerId>abcdef09-86ee-1234-8ba7-98765432b6b7</d4p1:CustomerId>**_ <d4p1:OfferId>1017D7F3-6D7F-4bfa-BDD8-79BC8F104E0C</d4p1:OfferId> <d4p1:PartnerId>0</d4p1:PartnerId> <d4p1:Quantity>50</d4p1:Quantity> <d4p1:RelatedSubscription i:nil="true" /> <d4p1:RequestId>98765432-48c9-dcba-866c-123456fdfe00</d4p1:RequestId> _**<d4p1:SubscriptionId>dcba0987-1ba6-1234-a681-567890b36004</d4p1:SubscriptionId>**_ </request> </PlaceOrder> </s:Body> </s:Envelope> _Response_: <s:Envelope xmlns:s="" xmlns:a="" xmlns:u=""> <s:Header> <a:Action s:mustUnderstand="1"></a:Action> <a:RelatesTo>urn:uuid:12345678-42b8-abcd-9d3f-b7a0fce2bd78</a:RelatesTo> <ActivityId CorrelationId="12345678-90e9-4b88-abcd-e28e277c32e1" xmlns="">00000000-0000-0000-0000-000000000000</ActivityId> <o:Security s:mustUnderstand="1" xmlns:o=""> <u:Timestamp u:Id="_0"> <u:Created>2012-11-16T17:25:52.693Z</u:Created> <u:Expires>2012-11-16T17:30:52.693Z</u:Expires> </u:Timestamp> </o:Security> </s:Header> <s:Body> <PlaceOrderResponse xmlns="" /> </s:Body> </s:Envelope>'


Odin Service Automation is waiting for the provisioning operations for the subscription in question to be completed or for the callback from Microsoft Online Portal.

There is a record in the waiting_subscriptions table in the [MOSI Gateway Database][1] for the problem subscription, indicating that a callback about the previous operation's completion was not received by the MOSI Gateway.

This can indicate a number of things:

  1. Provisioning has not been completed on the Office 365 side and Microsoft has not sent a callback to Parallels about completing the provisioning. Provisioning can take quite a while in certain cases.
  2. Provisioning has been completed on the Office 365 side, but OA has not received a callback because Microsoft did not send it or it was lost.

When a callback about subscription provisioning is received by the MOSI Gateway, this will remove the record about the problem subscription from the waiting_subscriptions table and the failed OA task will complete at the next execution.


Verify whether provisioning on the Microsoft side has been completed:

  1. Check the record in the waiting_subscriptions table in the MOSI Gateway Database to understand what the desired outcome is.

    In the example below, OA wants to provision a new subscription for 50 seats of the offer 1017D7F3-6D7F-4bfa-BDD8-79BC8F104E0C, also known as ENTERPRISEPACK, and Plan E3 (see the Knowledgebase article #114227 [Office 365] Configuring Offer Mappings on Office 365 Gateway Host for the list of Microsoft Office 365 offers):

    sqlite> SELECT * FROM waiting_subscriptions WHERE id = "dcba0987-1ba6-1234-a681-567890b36004"
        "_waiting_for_": "**_Create_**:
    <s:Envelope xmlns:a=\"\" xmlns:s=\"\">
        <a:Action s:mustUnderstand=\"1\"></a:Action>
        <PlaceOrder xmlns=\"\">
          <request xmlns:d4p1=\"\" xmlns:i=\"\">
            <d4p1:RelatedSubscription i:nil=\"true\" />
    <s:Envelope xmlns:s=\"\" xmlns:a=\"\" xmlns:u=\"\">
        <a:Action s:mustUnderstand=\"1\"></a:Action>
        <ActivityId CorrelationId=\"12345678-90e9-4b88-abcd-e28e277c32e1\" xmlns=\"\">00000000-0000-0000-0000-000000000000</ActivityId>
        <o:Security s:mustUnderstand=\"1\" xmlns:o=\"\">
          <u:Timestamp u:Id=\"_0\">
        <PlaceOrderResponse xmlns=\"\" />

    The Office 365 subscription ID dcba0987-1ba6-1234-a681-567890b36004 used in the SQL query above must be replaced with the actual ID, which can be taken from the XML Payload in the failed OA task provided in the Symptoms section:


    As you can see from the above output, the MOSI Gateway is waiting for completion of the PlaceOrder request - it is waiting for the subscription to be created on the Microsoft side.

  2. Check in the Microsoft Online Portal web interface or in PowerShell whether the problem subscription was created in Office 365 and its limits. The example below shows that the subscription already exists in Microsoft with the correct number of seats:

    PS> Get-MsolSubscription -TenantID (Get-MsolPartnerContract -Domain _****_).TenantID | select skupartnumber, status, totallicenses
    SkuPartNumber                                  Status             TotalLicenses
    -------------                                  ------             -------------
    ENTERPRISEPACK                                Enabled                        50

    The domain in the PowerShell cmdlet above must be replaced with the actual customer domain in Office 365. The domain can be found in the OA Customer Control Panel (CCP) in the login of the administrative user, which is created along with the customer account in Office 365. The login of the admin user is displayed in the CCP at Microsoft Office 365 > Configuration > Settings > Generated Values. See this screenshot:

    In fact, any domain the customer delegated to Microsoft can be used in the PowerShell cmdlet above.

Further actions depend on the result of checking if the subscription was properly created in the Office 365 cloud:

  1. If provisioning has not been completed, wait for it to complete on the Microsoft side. As soon as provisioning is completed in Office 365, Microsoft will send a callback to the MOSI Gateway and the failed OA task will complete at the next run.
  2. If provisioning has been completed in Office 365 and OA did not receive a callback:

    2.1. Contact Microsoft support to clarify if the callback was sent for this subscription. In some cases Microsoft would require the list of incoming/outgoing callbacks for the customer - they may be located inside MOSI GW folder in Callbacks folder.

    2.2. If Microsoft claims they sent the callback, contact Odin technical support and provide the above investigation results.


If the issue is urgent or you do not wish to contact Microsoft support, you can remove the record for the problem subscription from the waiting_subscriptions table in the MOSI Gateway Database manually, then resubmit the failed task in OA:

    sqlite> delete from waiting_subscriptions where id = "dcba0987-1ba6-1234-a681-567890b36004";

After that, run the failed task in OA.

caea8340e2d186a540518d08602aa065 5356b422f65bdad1c3e9edca5d74a1ae ac82ce33439a9c1feec4ff4f2f638899 2554725ed606193dd9bbce21365bed4e 5b048d9bddf8048a00aba7e0bdadef37 e12cea1d47a3125d335d68e6d4e15e07 198398b282069eaf2d94a6af87dcb3ff 210d017ddc3a076d22f0f865b1cf0730 92711db0799e8aefe8e51f12dace0496 801221f8cd76fba7300d1e6817c8e08b 956c448bddc7e1f3585373687602379f 6f1456866eed87488c0f02b298a741c0

Email subscription for changes to this article
Save as PDF