This version of the application reached its end of life. We recommend that you upgrade to the latest supported version of the application. To obtain the latest supported version, see this article.

Table of Contents

Release Notes

You can read the complete Office 365 18.3 Release Notes here. Also, you can download the office_365_integration_18.3_release_notes.pdf.

Dependencies and Pre-Requisites

The Office 365 application package requires:

  • Odin Automation 7.4.0 or a later 7.4.x version
  • Odin Automation 7.3.0 or a later 7.3.x version
  • Odin Automation 7.2.0 or a later 7.2.x version

Fixed Issues

  • APSA-19808 Provisioning fails with error "Can't update a subscription with deleted status" if MPN ID is changed.
  • APSA-20321 "Purchasing Office 365 License" notification message gets stuck in UX1 for Customers after failed order becomes archived.
  • APSA-20250 Tasks 'Provisioning "Subscription" for Office 365' fail with error 'Default Admin login of the customer is not set'.
  • APSA-20397 User removal in Partner Center leads to failed unprovisioning task.
  • APSA-19795 autoconf.py should set 'Destroy Service On Cancel' to 'No' in Office 365 service templates.
  • APSA-19957 It is impossible to use readCSPAccounts.py for large resellers since it can process only 499 customer accounts.
  • APSA-20011 Task 'Provisioning "Subscription" for APS application Office 365' fails with error 'Password of this length should contain more different characters'.
  • APSA-20175 UX1 for Customers: Error "Property passwordProfile.password is invalid" occurs.
  • APSA-19083 Unclear error message is shown when customer tries to verify domain.
  • APSA-20386 Resource dependencies must be used instead of offer compatibility checker for checking compatibility of offers.
  • APSA-19595 Offer configuration script autoconf.py adds resource to service template of one application instance even if resource belongs to another application instance.
  • APSA-19938 "UsageLocation" user property should be sent in uppercase to Microsoft cloud.
  • APSA-20158 Import script readCSPAccounts.py should be able to find customer tenant by any of its verified domains.
  • APSA-20473 Import script readCSPAccounts.py must skip suspended tenant subscriptions where list "suspensionReasons" does not include "CustomerCancellation".
  • APSA-19927 Reconciliation report creation process fails with error "An item with the same key has already been added" if the same Odin Automation subscription is fetched twice for "InstanceSubscriptions" dictionary.
  • APSA-20252 Master tenant role is not moved from inactivated tenant with this role when this tenant is removed.
  • APSA-19929 Import scripts readCSPAccounts.py and importSubsCSP.py do not take into account billing frequencies of tenant subscriptions and billing periods of service plans.
  • APSA-20069 Task 'Provisioning "AsyncOperation"' fails with error 'Unknown line item action for the line item 0' when incorrect possible parent license is specified in addon license.
  • APSA-20104 [UX1 for Customers] On "Users" screen, "OFFICE 365 LICENSES" column contains "Off" even if user actually has licenses assigned.
  • APSA-20535 Reading APS resources page by page, from the first page to the last page, does not guarantee receipt of full set of resource data from APS bus.
  • APSA-20510 Synchronization of 100k+ users never ends.
  • APSA-20514 Delta link must not be reset if users still have ambiguous licenses at the end of synchronization.
  • APSA-20563 [UX1 for Customers] Error 'Resource with UID ... not found' is displayed for deleted subscriptions.

Important: This section provides the list of fixed issues. To obtain the detailed description of a fixed issue, you must read the corresponding section of the complete release notes. You can read the complete Office 365 18.3 Release Notes here. Also, you can download the office_365_integration_18.3_release_notes.pdf.

New Features and Changes

UX1 for Customers: Synchronization of Changes from Office 365 Portal

Now, UX1 for Customers gives administrative users the ability to run the synchronization of changes made in the Office 365 Portal.

An administrative user willing to retrieve changes from the Office 365 Portal and apply them to his/her Office 365 organization in Odin Automation can now run synchronization by clicking the SYNC USERS link in the ADMINISTRATION tile. There are two types of synchronization that an administrative user can run:

  • A full synchronization, which synchronizes all changes occurred since the creation of the respective customer tenant in the Office 365 Portal.
  • A delta synchronization, which synchronizes only changes that occurred since the last synchronization.

During synchronization, an administrative user is informed about the status of synchronization and its results with the help of the notification system of UX1 for Customers. Also, an administrative user can view notification messages related to synchronization in the action log of UX1 for Customers.

To learn more about the synchronization of changes made in the Office 365 Portal, refer to the Office 365 Integration Provider's Guide >> Cloud Solution Provider Scenario > Useful Information > Synchronizing Changes from Office 365 Portal.

Improved Logging of Offer Auto-configuration Script autoconf.py

Now, when you run the offer auto-configuration script autoconf.py, in addition to sending log output to the console, the script writes log output to its log file autoconf_YYYY-MM-DD.log. This makes analyzing the script's execution results and troubleshooting simpler.

Odin Automation Office 365 Integration Provider's Guide >> Cloud Solution Provider Scenario > Configuring Offers

Simplified Processing of Office 365 Subdomains

In the previous versions of the application, due to technical reasons, Office 365 subdomains, such as <customer>.onmicrosoft.com, <customer>.onmicrosoft.de, and <customer>.partner.onmschina.cn, were automatically created in Odin Automation after subscription provisioning or synchronization with the Office 365 Portal. Now, Office 365 subdomains are not created in Odin Automation.

On new installations of the application, Office 365 subdomains will not be created in Odin Automation.

On existing installations of the application, Office 365 subdomains will not be created in Odin Automation after you upgrade the application; already existing Office 365 subdomains can be removed from Odin Automation, if necessary.

Ability to Confirm Customer Acceptance of Microsoft Cloud Agreement

As of March 22, 2019, Microsoft will require partners to obtain their customers' acceptance of the Microsoft Cloud Agreement (MCA) before they can order Microsoft products and services for these customers. To better help partners meet compliance requirements, Microsoft will ask partners to confirm acceptance by providing the following details regarding the person who accepted the agreement: first name, last name, email address, phone number, and date of acceptance. To learn more, see https://docs.microsoft.com/en-us/partner-center/confirm-consent-faq.

To facilitate obtaining a customer's acceptance of the MCA, the Office 365 application enables a customer to accept the MCA and provide the contact details of the person who accepted the MCA.

The application supports the following scenarios of obtaining acceptance information:

  • In CCPv1, when a customer who has not yet provided acceptance information buys an Office 365 subscription by using the Buy More Services Wizard, the customer is asked to provide his/her acceptance information. Also, in this scenario, the vendor of the customer can act on behalf of the customer.

  • In UX1 for Customers, when a customer who has not yet provided acceptance information buys an Office 365 subscription by using the Buy New License Wizard, the customer is asked to provide his/her acceptance information. Also, in this scenario, the vendor of the customer can act on behalf of the customer.

  • In UX1 for Customers, when a customer who has not yet provided acceptance information buys an Office 365 subscription by using the Marketplace, the customer is asked to provide his/her acceptance information. Also, in this scenario, the vendor of the customer can act on behalf of the customer.

  • In CCP v1 and UX1 for Customers, when a customer who has not yet provided acceptance information buys an Office 365 subscription by using the online store, the customer receives notifications that he/she has to provide his/her acceptance information. Also, in this scenario, the vendor of the customer can act on behalf of the customer.

  • In the online store, when a customer buys an Office 365 subscription, he/she is asked to provide his/her acceptance information. Also, in this scenario, the vendor of the customer can act on behalf of the customer.

  • In PCP v1 / RCP v1, when a vendor buys an Office 365 subscription for a customer who has not yet provided acceptance information, the vendor is asked to provide the acceptance information of the customer.

For the Global Office 365 Cloud, the ability is enabled by default. For the German and Chinese Office 365 Clouds, the ability is disabled by default. You can make it enabled by following the instructions provided at https://kb.cloudblue.com/en/133266.

After upgrading to Office 365 18.3, customers who have not yet provided their acceptance information will receive notifications that they have to provide their acceptance information.

Changes in Import Scripts readCSPAccounts.py and importSubsCSP.py

The following changes were made in the scripts that are used for importing tenant subscriptions from the Microsoft cloud into Odin Automation:

readCSPAccounts.py

  • A new option named --verbose was added. If it is specified, more log information is shown in the console during execution.
  • A new option named --account-domain-list was added, where a comma-separated list of verified domains of tenants can be specified. If it is specified, the script collects the tenant data of the tenants identified by the domains. If it is not specified, the script collects the tenant data of all tenants. You can use this parameter to import the tenant subscriptions of the tenants that you need.
  • The option --account-default-domain was made deprecated. It will be dropped in the future. We recommend that you start using the option --account-domain-list as a replacement.
  • The format of the following output files of the script was changed:

    • In customers_PARTNER_SUBDOMAIN.csv / customers_PARTNER_TENANT_ID.csv, the column DefaultDomainName was renamed to InitialDomainName.
    • In importSubs_PARTNER_SUBDOMAIN.csv / importSubs_PARTNER_TENANT_ID.csv, a new column named InitialDomainName was added.

importSubsCSP.py

  • A new option named --verbose was added. If it is specified, more log information is shown in the console during execution.
  • A new option named --file was added. You need to use it to specify a CSV file that contains tenant subscriptions to be imported.

Odin Automation Office 365 Integration Provider's Guide >> Cloud Solution Provider Scenario > Importing Tenant Subscriptions from Microsoft Cloud into Odin Automation

Known Issues and Limitations

  • Office 365 and Azure CSP resources cannot be sold in the same service template/service plan. You must use separate service templates/service plans for selling Office 365 and Azure CSP resources.
  • Upgrading trial Office 365 subscriptions from trial service plans to paid service plans does not work in CCP v1. To work around this issue, you can switch customers with trial Office 365 subscriptions from CCP v1 to UX1 for Customers.
  • In UX1 for Customers of Odin Automation 7.2, adding trial Office 365 services to users does not work on the Users screen. To work around this issue, customers can use the Office 365 screen.

Obtaining

Contact your Ingram Micro Support account manager to obtain the new version of the Office 365 application package.

Installation

To install the Office 365 application, use the instructions provided in the Odin Automation Office 365 Integration Provider's Guide.

Upgrade Procedure

The upgrade procedure consists of the following steps:

  1. Preparing necessary information for upgrading the Office 365 application endpoint (collecting Office 365 gateway site parameters).
  2. Stopping provisioning Office 365 services.
  3. Upgrading the Office 365 application endpoint.
  4. Upgrading the Office 365 application.
  5. Updating the OA Billing control panel and online store customizations.
  6. Removing the offer compatibility checker.
  7. Configuring resource dependencies for incompatible offers.
  8. Performing post-upgrade validation.
  9. Starting provisioning Office 365 services.

Important:

  • The upgrade procedure is not reversible.
  • Upgrade steps 1-9 are mandatory.
  • Make sure the current version of the Office 365 application is 18.2/18.2.1. Upgrading from other versions is not supported.
  • Before upgrading the Office 365 application from one version to another one, make sure that you are going to follow the allowed upgrade paths. See KB article #130752 for details.
  • If a non-LocalDB edition of SQL Server is used by your Office 365 application endpoint, make sure all SQL Server logins of Office 365 gateway application databases have the sysadmin server role. See Odin Automation Office 365 Integration Provider's Guide >> Cloud Solution Provider Scenario > Deployment Architecture > Preparing SQL Server Databases for details.
  • The names of the Office 365 gateway sites must not be changed after the installation of the Office 365 application endpoint. If you have changed them, return the original names before upgrading the Office 365 application endpoint.

To upgrade an existing installation of the Office 365 application, perform the following steps:

  1. Prepare necessary information for upgrading the Office 365 application endpoint. You must prepare the name of the Office 365 gateway site, the name of the Office 365 gateway application, the hostname of the Office 365 gateway site, and the IP address of the Office 365 gateway site. This can be done in the following way:

    1. Log in to Provider Control Panel.
    2. Go to Service > Applications and click the Office 365 application.
    3. Select the Instances tab and click the target application instance.
    4. Select the General tab.
    5. Obtain the value of the Application API end-point URI setting. This is a URL that is structured in the following way: https://<Hostname_of_Office_365_Gateway_Site>/<Name_of_Office_365_Gateway_Application>/aps/.
    6. Write down the name of the directory from the URL. This is the name of the Office 365 gateway application.
    7. Write down the hostname from the URL. This is the hostname of the Office 365 gateway site.
    8. Resolve the hostname from the URL into the IP address. This is the IP address of the Office 365 gateway site. Write down this IP address.
    9. Log on to the Office 365 Application Endpoint Host as Administrator via RDP.
    10. Open Internet Information Services (IIS) Manager.
    11. Go to the list of sites.
    12. From the list, select the site with the IP address obtained above.
    13. Write down the name of the site. This is the name of the Office 365 gateway site.
  2. Stop provisioning Office 365 services:

    1. In OA Operations, go to Operations > Tasks and make sure all Office 365 tasks are processed.
    2. Stop provisioning Office 365 services. For example, deactivate the Office 365 service template in OA Operations.
  3. Upgrade the Office 365 application endpoint:

    1. Upload the Office 365 application package to the Office 365 Application Endpoint Host.
    2. Unpack the application package.
    3. Unblock the content of the O365-Web.zip file. To do this, right-click the file in Windows Explorer, click Properties, click Unblock, click OK.
    4. Unpack the O365-Web.zip file.
    5. Start Windows PowerShell Console and go to the directory where the contents of the O365-Web.zip file is placed.
    6. Run the following command:

      .\setup.cmd -GatewaySiteName <The name of the Office 365 gateway site> -GatewayAppName <The name of the Office 365 gateway application> -GatewayIPAddress <The IP address of the Office 365 gateway site> -GatewaySiteCertSubject <The hostname of the Office 365 gateway site> -Force
      
    7. Run the iisreset command.
  4. Note: If you have several Office 365 gateway sites on the Office 365 Application Endpoint Host, use the procedure provided above to upgrade each Office 365 gateway site.

  5. Upgrade the Office 365 application:

    1. Import the Office 365 application package to Odin Automation. See Odin Automation Application Hosting Guide >> Application Hosting Configuration > Managing Applications > Importing Application for details.
    2. Upgrade existing Office 365 application instances. See Odin Automation Application Hosting Guide >> Application Hosting Configuration > Bulk Application Upgrades for details.
  6. Update the installed OA Billing control panel and online store customizations. Use KB article #130232 to find necessary customizations and update instructions.

    Important: After upgrading Odin Automation, make sure the installed OA Billing control panel and online store customizations belong to the current version of Odin Automation. If necessary, update them. Use KB article #130232 to find necessary customizations and update instructions.

  7. Remove the offer compatibility checker from your system:

    1. On your OA Billing Application Server (OABLINFE), perform the following:

      1. In the directory /usr/local/bm/customization, remove the file Plan_CDB_BuyNewPlanListHead.xml.
      2. In the directory /usr/local/bm/conf/html/o365, remove the file script2.js.
      3. Execute the command service pba restart.
      4. Execute the command service www restart.
    2. On your OA Operations Branding Servers, for every brand used for selling Office 365 services, perform the following:

      In the directory /var/www/brands/<brand_domain_name>/o365, remove the files check.php, .htaccess, and incompatibilitylist.json.

  8. Configure resource dependencies for all incompatible offers as described in the Office 365 Integration Provider's Guide >> Cloud Solution Provider Scenario > Configuring Resource Dependencies for Incompatible Offers. After you perform the steps of the instruction, synchronize all the service plans that you modified with subscriptions.

  9. Perform the following post-upgrade validation steps:

    1. In Task Manager, make sure that there are no unprocessed Office 365 tasks scheduled during the upgrade.
    2. For each Office 365 application instance, make sure that all settings are correctly specified and all necessary Microsoft APIs are accessible. To do this, select the application instance you need to check and click Test Connection.
  10. Start provisioning Office 365 services. For example, activate the Office 365 service template in OA Operations.

Help Resources

Internal content

Link on internal Article