Search Engine: Elastic

Article ID: 134045, created on May 22, 2019, last review on Oct 16, 2019

  • Applies to:
  • Operations Automation 8.0

Table of Contents

Release Notes

You can read the complete Office 365 19.2 Release Notes here. Also, you can download the PDF version.

Prerequisites

The Office 365 application package requires:

  • Odin Automation

    • 8.2.0_hf134510 or a later 8.2.x version
    • 8.0.0_hf134499 or a later 8.0.x version
  • UX1 Marketplace (optional)

    • 1.4

Note: For information about UX1 Marketplace, please refer to the guide at https://docs.cloudblue.com/oa/8.0/premium/content/UX1-Marketplace/Introduction.htm.

Fixed Issues

  • APSA-21291 A subscription cannot be upgraded because its source subscription state is not active.
  • APSA-21330 The OA Billing customization file cowi_script.js affects non-Office 365 subscriptions.
  • APSA-21328 A refresh token expires in 90 days.
  • APSA-17115 Navigation in UX1 for Customers slows down because the Office 365 application has too many navigation variables.
  • APSA-20872 Error: User user@example.com is duplicated in Gateway DB.
  • APSA-21153 The subdomain form of the marketplace of UX1 for Resellers passes '-' symbols.
  • APSA-21156 Resource category names are incorrectly aligned in the online store if the new_general skin is used.
  • APSA-21243 An incorrect action initiator name is displayed in notification messages.
  • APSA-21009 A customer is asked to accept the Microsoft Cloud Agreement even if the customer has already accepted it.
  • APSA-21335 Orders fail with the error 'Culture da-FO is not supported in country FO'.
  • APSA-21113 The conversion of subscriptions from trial to paid fails for customers that do not have an active Microsoft Cloud Agreement.
  • APSA-21015 Tasks fail with the error 'Invalid MPN ID' when Offer ID is invalid.
  • APSA-21245 An add-on license cannot be provisioned: the 'Sequence contains more than one matching element' error appears.
  • APSA-21162 Significant performance degradation happens when a refresh token is expired.
  • APSA-21154 An unclear error message is displayed if a refresh token is expired.
  • APSA-20795 Synchronization finishes with the error 'User ... is duplicated in Gateway DB' because a user with the same login name is not removed.
  • APSA-20509 Synchronization fails with the error 'Username (login) can contain any letters, digits, hyphens, at-sign (@), dots and underscores, length must be in range from 3 to 254'.
  • APSA-21209 Update billing customizations.
  • APSA-20656 Customer account cancellation fails if the relationship with its provider is cancelled on the Microsoft side.
  • APSA-19711 The "Generic error occured while communicating with Company management service." error appears when a new account is created in the Microsoft cloud.

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 19.2 Release Notes here. Also, you can download the PDF version.

New Features and Changes

UX1 for Customers: User Role Management is Supported

In UX1 for Customers, customer account administrators can now manage Microsoft user roles of their Office 365 users.

This ability is available in the Edit Office 365 Account window, which can be opened, for instance, in the following way: select the Office 365 menu item, in the list of Office 365 users, click on the name of a user, and then click Edit.

Note: The application supports the Company Administrator, Helpdesk Administrator, Service Support Administrator, User Account Administrator, and User roles, which are used in the Microsoft Partner Center. For more granular control over roles, the Office 365 Admin Center can be used.

Using One Microsoft Account for Several Odin Automation Customer Accounts

As of this version, the same Microsoft account can be used by several Odin Automation customer accounts within the same Odin Automation installation.

For a service provider, this allows Direct and Indirect CSP Providers represented as vendor accounts in Odin Automation to sell Office 365 services to the same customer represented as one Microsoft account in the Microsoft cloud and several customer accounts in Odin Automation. For customers, this allows them to buy and use different Office 365 services from different CSP Providers.

UX1 for Customers: Using Several Microsoft Accounts for One Odin Automation Customer Account

A customer that has several Microsoft accounts in the Microsoft cloud for the same customer account in Odin Automation can now manage these Microsoft accounts through the Odin Automation control panel. This enables customers that have only customer accounts in Odin Automation to act as small resellers and provide their own customers with Office 365 services.

Note: This configuration can be obtained only by using the import tools described in Office 365 Providers Guide >> The Cloud Solution Provider Scenario > Importing Tenant Subscriptions from the Microsoft Cloud into Odin Automation.

The Management of Licenses Obtained Outside Odin Automation

In the Microsoft cloud, Microsoft accounts of customers can have licenses that are obtained from different CSP Providers, including those that are not represented as vendor accounts in Odin Automation. In the previous versions of the application, such licenses were ignored, and customers were not able to manage them through their control panel. As of this version of the application, such licenses are taken into account, and customers can view, assign, and revoke them through their control panel.

The Registration of Existing Microsoft Accounts is More Secure

As of this version of the application, when a customer buys licenses using the Use Existing Microsoft Online Account option, the customer must confirm the ownership of this Microsoft account by creating a verification DNS record through the Office 365 Portal.

The Product Configuration Manager is Supported

The Product Configuration Manager (PCM) is a component of Odin Automation that enables service providers to configure and reconfigure offers of applications. As of this version, the Office 365 application supports the PCM.

To learn more about the PCM and its abilities, please refer to this documentation.

Important: The First Time Configuration mode of the PCM is not supported. For the initial offer configuration of an Office 365 application instance, you must use the instructions provided in the Office 365 Providers Guide >> The Cloud Solution Provider Scenario > Configuring Offers.

Windows Server 2016 is Supported

As of this version, service providers can deploy the Office 365 application endpoint on Windows Server 2016 Standard.

Known Issues and Limitations

  • For CCP v1, the following operations are no longer supported by the application:

    • Adding, viewing, modifying, and removing Office 365 users.
    • Assigning and revoking Office 365 licenses to and from Office 365 users.
    • Running the synchronization of changes from the Microsoft cloud.

      Note: The automatic synchronization periodically performed by the application will continue to work.

    The full range of operations is available in UX1 for Customers, which is the modern replacement for CCP v1. We recommend that you switch your customers to UX1 for Customers. To switch your customers, use the instructions at https://docs.cloudblue.com/oa/8.0/premium/content/UX1-for-Customers-Provider-Guide/About-UX1.htm.

  • Office 365 and Azure CSP resources cannot be sold in the same service template and service plan. You must use separate service templates and 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.
  • For OA Billing online stores, the ability to create Office 365 subscriptions for existing Microsoft accounts is no longer supported.

Obtaining the 'Office 365' Package

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

Installation Procedure

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. Prepare the necessary information for upgrading the Office 365 application endpoint (collect Office 365 gateway site parameters).
  2. Turn off Office 365 synchronization.
  3. Upgrade the Office 365 application endpoint.
  4. Upgrade the Office 365 application.
  5. Update Office 365 resources.
  6. Update the OA Billing control panel and online store customizations.
  7. Perform post-upgrade validation.
  8. Perform post-upgrade actions.
  9. Turn on Office 365 synchronization.

Important:

  • The upgrade procedure is not reversible.
  • Upgrade steps 1-9 are mandatory.
  • Make sure the current version of the Office 365 application is 19.1/19.1.1/19.1.2. Upgrading from other versions is not supported.
  • Before upgrading the Office 365 application from one version to another, 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, reinstate the original names before upgrading the Office 365 application endpoint.
  • Before upgrading the application, we recommend that you check that there are no unprocessed Office 365 tasks in Task Manager. Unprocessed Office 365 tasks may cause issues during and after upgrade.

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

  1. Prepare the 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 the Provider Control Panel.
    2. Go to Services > Applications, select the APS Connectors tab, 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 and write down the hostname from the URL into the IP address. This is the IP address of the Office 365 gateway site.
    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. Turn off Office 365 synchronization by canceling all periodic tasks Office 365 * Synchronization with Office 365 Portal in Task Manager.

  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 contents of the O365-Web.zip file. To do this, right-click the file in Windows Explorer, click Properties, click Unblock, and 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 are located.
    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.

    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.

  4. Upgrade the Office 365 application:

    1. Import the Office 365 application package to Odin Automation. See APS Application Hosting Guide >> Application Hosting Configuration > Managing Applications > Importing Application for details.
    2. Upgrade existing Office 365 application instances. See APS Application Hosting Guide >> Application Hosting Configuration > Bulk Application Upgrades for details.
  5. Update Office 365 resources:

    Note: If you have several Office 365 application instances on your installation, make sure that the names of resource types, service templates, and service plans that belong to those application instances conform with one of the following naming schemes: (1) The names of resource types, service templates, and service plans of one application instance have no prefix. The names of resource types, service templates, and service plans of the other application instances have unique prefixes that end with a colon (:). For example: No prefix is used for the first application instance; O365INST2: and O365INST3: are used for the second and the third. (2) The names of resource types, service templates, and service plans of each application instance have unique prefixes that end with a colon (:). For example: O365INST1: is used for the first application instance; O365INST2: is used for the second application instance.

    For every instance of the Office 365 application, execute the autoconf.py script. See Office 365 Providers Guide >> The Cloud Solution Provider Scenario > Configuring Offers for details.

  6. Update the installed OA Billing control panel and online store customizations. Use KB article #130232 to find the necessary customizations and update instructions.

  7. 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.
  8. Perform post-upgrade actions by running the autoconf.py script in the following way:

    python autoconf.py upgrade19_2
    

    Note: The execution of this command may take a significant amount of time, depending on the number of Office 365 users registered in the application. For example, on an installation with 80,000 Office 365 users, the execution of this command takes 6.5 hours.

  9. Turn on Office 365 synchronization by running all the periodic tasks Office 365 * Synchronization with Office 365 Portal that you canceled previously.

The End of Life Policy

The Office 365 application follows the end of life (EOL) policy described below.

There are two types of application version:

  • Major versions. These have two-part version numbers (19.2, 19.3, 20.1, and so on).
  • Minor versions. These have three-part version numbers (19.2.1, 19.2.2, 19.2.3, and so on).

A major version is supported for 12 months from the date it is released, or for 6 months after the next major version is released. Depending on the release date of the next major version, the support period of the previous major version can be extended, but not shrunk.

For example:

  1. 19.2 is released on 15 July 2019. In this case, the EOL date of 19.2 is 15 July 2020.
  2. 19.3 (or 20.1) is released on 15 August 2019. In this case, the EOL date of 19.2, 15 July 2020, does not change.

    OR

    19.3 (or 20.1) is released on 20 February 2020. In this case, the EOL date of 19.2 changes from 15 July 2020 to 20 August 2020.

The very first minor version replaces its major version and inherits its EOL date from the major version. The major version, in turn, reaches its EOL date in a month after the release of the very first minor version.

The next minor version replaces the previous minor version and inherits its EOL date from the previous minor version. The previous minor version, in turn, reaches its EOL date in a month after the release of the next minor version.

For example:

  1. 19.2 is released on 15 July 2019. In this case, the EOL date of 19.2 is 15 July 2020.
  2. 19.2.1 is released on 15 August 2019. In this case, 19.2.1 inherits the EOL date of 19.2, 15 July 2020, and the EOL date of 19.2 changes from 15 July 2020 to 15 September 2019.
  3. 19.2.2 is released on 19 February 2020. In this case, 19.2.2 inherits the EOL date of 19.2.1, 15 July 2020, and the EOL date of 19.2.1 changes from 15 July 2020 to 20 March 2020.
  4. 19.3 (or 20.1) is released on 20 February 2020. In this case, the EOL date of 19.2.2 changes from 15 July 2020 to 20 August 2020.

Helpful Resources

adc6deaa66054d8a194d131ba07f2785 8fc71f07abe5b233fea1ae0377cd5e3d 5356b422f65bdad1c3e9edca5d74a1ae aab95f5cf9bcfa920cc1dda8487f084a

Email subscription for changes to this article
Save as PDF