Article ID: 115703, created on Mar 12, 2013, last review on Aug 12, 2014

  • Applies to:
  • Operations Automation


New Features in the Microsoft Office 365 4.0 APS package


Table of contents

Syncing Office 365 users and domains from Microsoft Online Portal (MOP) to POA
Automatic deployment and upgrade of the O365 Gateway Application
Improved User Seat Downgrade Report
New 'Administration' Screen
Support the new format of the MX records
Office 365 Wave 15 support
The POA hosting subscription ID is stored in the MOSI Gateway DB


Syncing Office 365 users and domains from Microsoft Online Portal (MOP) to POA


 The enterprise customers used to create and delete users and domain from within Microsoft Online Portal (MOP) directly (not via POA Control Panel), and therefore POA needs to sync the users and domains back.

The Microsoft Office 365 4.0 APS application provides the synchronization script 'import_csv.py' that allows Provider to synchronize the users and domains created directly in the Microsoft Online Portal to POA. The script is included in the Office 365 4.0 APS application package.

How the synchronization script works

POA requests the lists of users and domains for subscriptions with Office 365 services from the Microsoft Office 365 Cloud using cmdlets defined in the Windows Azure Active Directory Module for Windows PowerShell (previously known as Microsoft Online Services Module for Windows PowerShell). Then the users and domains obtained from the MOP are compared to those existing in POA. To match the users in MOP and POA the User Principal Name (UPN) is used if the user is synced for a first time. During the first synchronization session for each user the internal Microsoft Object ID is obtained and stored in the MOSI Gateway Database. During the future synchronization sessions stored ID is used to match the users in MOP and POA.

POA processes subscriptions by 3 pieces at a time. For each 3 subscription the MOSI Gateway method get_mop_accounts is being called. The input parameters and output of the method are logged into the sitelog log file at the MOSI Gateway. Since the PowerShell cmdlets are used no XML Payloads are logged in this case.

If some action cannot be performed automatically the notification message is added to the synchronization log file synclogYYYY-MM-DD.log. The log file is created in the current directory from which the script is executed.

Domains synchronization

Domain in MOP Office 365 Service
in MOP
Domain in POA Office 365 Service in POA Synchronization result
Domain exists Assigned Domain does not exist Not assigned The domain is added to POA subscription as 'Domain registered elsewhere'.

If the 'Auto host domains' activation parameter of the Office 365 Application Resource Type is set to 'On' the domain is automatically added to the Office 365 Application.
Domain exists Assigned Domain exists Not assigned The following notification is added to the synchronization log file only: 'Unable automatically add the existing domain ‘domain_name’ to the Office 365 application. You can add the domain manually in Customer's CP.'


Users synchronization

User in MOP Office 365 Service
in MOP
User in POA Office 365 Service in POA Synchronization result
User exists Not assigned User does not exist Not assigned POA ignores such user (no new user is being created in POA) and the following notification is being added to the synchronization log file: 'User has no offers assigned and cannot be processed. In order to involve the user into synchronization process please assign some license(s) to them in MOP or create the user in POA manually.'
User exists Not assigned User exists Not assigned POA synchronizes contact info only, the Office 365 Resource Type with NULL GUID (the value 00000000-0000-0000-0000-000000000000 should be set both for the settings Included Offers and Trial Offer ID) is being assigned to the POA user. Such special Resource Type with NULL GUID should be created and included to the Office 365 Service Tem0plate before the synchronization, otherwise the following notification is added to the synchronization log file: 'Resource type for offer set {EMPTY} cannot be found in subscription's Service Template.'
User exists Assigned User does not exist Not assigned POA creates the new service user and assigns Office 365 service with corresponding offers to it.
User exists Assigned User exists Not assigned POA assigns the Office 365 service with corresponding  offers to the existing user and updates user contact info in POA.
User exists Assigned User exists Assigned, offers in POA and MOP do not match to each other POA assigns Office 365 service with offers assigned to the user in MOP and updates user contact info in POA.
User does not exist Not assigned User exists Assigned POA removes the Office 365 service from the user.
User exists Assigned with Administrative privileges User exists Assigned without Administrative access POA assigns the 'Office 365 Administrative Access' service  to the user and updates contact info in POA.
User exists Assigned without Administrative privileges User exists Assigned with Administrative access POA removes the 'Office 365 Administrative Access' service  from the user and updates contact info in POA.


When it comes to contact info synchronization the following fields are being updated in POA:
  • First name
  • Last name
  • Display name
  • City
  • Country
  • Department
  • Office
  • Phone number
  • Mobile phone
  • Fax
  • Postal code
  • State
  • Street address
  • Title
  • Usage location


Processing cases when user UPN was changed in MOP

Only case alias or the domain part of UPN was changed. The user was never synced to POA yet (during the previous synchronization processes), it is the first time sync script is being run since the user was created.

E.g. POA user jdoe@customer.com was changed to JohnDoe@customer.com in MOP.
The matching POA user will be found and usual synchronization is performed, the user login in POA is changed.
Any kind of change was performed to user UPN in MOP. The user was already synced to POA during previous synchronization processes (i.e. synchronization script was ran at least one time since the user was created). The matching POA user will be found via Microsoft Object ID (this ID is being stored in Gateway Database during synchronization process) since user was already synced to POA and usual synchronization is performed, the user login in POA is changed
Any kind of change was performed to user UPN in MOP. The user was never synced to POA during previous synchronization processes (i.e. synchronization script was not yet ran since the user was created).

E.g. POA user jdoe@customer.com was changed to user@contoso.com in MOP.
This is new user for POA. POA removes the Office 365 service from the existing user (which is absent in the list of users in MOP), creates new service user and assigns Office 365 service to it.

In the provided example POA will remove Office 365 service from the user jdoe@customer.com, create the new user with login user@contoso.com and assign proper Office 365 service to it.
 


Synchronization script deployment

Refer to the PA Office 365 Integration Provider's Guide for details - http://download.pa.parallels.com/poa/Office365/doc/71781.htm, the Installing Synchronization Script section.


Automatic deployment and upgrade of the O365 Gateway Application

The deployment script setup.ps1 included in the Microsoft Office 365 application package allows to automate the Office 365 package deployment and upgrade.

Provider has to run the deployment script on the Office 365 Gateway host. The script performs the actions described below.

1. Operating system components configuration.

  1. The version of operating system is checked.
  2. Presence of required system hotfixes is checked.
  3. IIS with required components is installed.
  4. Handler mapping for .svc files is configured in IIS.

2. Site certificate and Microsoft client certificate installation.

  1. If the script parameters SiteCertPath (path to the certificate .pfx file) and SiteCertPassword (password for the certificate .pfx file) are provided, the site certificate is installed in the system in the LocalMachine/My certificate store. Regardless of whether the script parameter MOSIClientCertSubject was provided or not it is reassigned with a subject name of imported certificate.
  2. If the script parameter MSCertPath (path to the certificate .p7b file) is provided, the Microsoft client certificate is installed in the system in the LocalMachine/My certificate store.

3. Website creation and configuration.

  1. If the web site with a name specified in the mandatory script parameter SiteName does not exists, the new web site is being created.
  2. At this point the IP address to which the new site will be bound is required. If there are more than 1 IP address configured in the system, the correct IP should be provided as script input parameter IPAddress. If the IP address is not provided or is ambiguous, the script execution is interrupted.
  3. In order to create a binding for the new web site the parameter MOSIClientCertSubject should be either provided as script parameter or initialized by the script (see the item 2a above). If the parameter is not set the script execution is interrupted.
  4. The protocol HTTPS and port 443 are used for a binding.
  5. For existing web site the binding reconfiguration may be forced by providing both MOSIClientCertSubject and IPAddress script parameters.
  6. Currently the IPAddress script parameter is required even if the web site exists and the binding should not be re-configured.

4. Application Pool creation and configuration.

  1. The name specified in the mandatory script parameter SiteName is used as name of Application Pool.
  2. If the Application Pool with such name does not exists, it is created.
  3. The following parameters are configured in the Application Pool:
    • Enable 32-bit Applications=False
    • Load User Profile=True

5. Application creation and configuration.

  1. If the Application with a given name does not exists in IIS, it is created.
  2. The Application is bound to the Application Pool configured on the previous step.
  3. Custom settings are being read from the application configuration file settings.config. For the Gateway application the following settings are being read: MOSIClientCertSubject, MOSIBillingID, MOSIBaseURL. For the Callbacks-Dispatcher application the following settings are being read: MOSIClientCertSubject, URLsToDispatchCallbacks. Each of these settings can be specified as script input parameters and in such case they overwrite the settings which were read from the settings.config file. Important: all listed settings should be presented either in application’s configuration file or in script input, otherwise the update will fail.
  4. Application configuration files settings.config and web.config are backed up
  5. Application content except the App_Data folder is removed
  6. New files are copied
  7. The settings.config file is updated with settings gathered at the step 5c.
  8. Access rights are configured for the App_Data folder: 'Modify' access right is granted to the Application Pool Identity User and is revoked from the IIS_IUSRS group.

6. Access rights for the site certificate are adjusted: 'Read' access right is granted to the Application Pool Identity User and is revoked from the IIS_IUSRS group.


Refer to the PA Office 365 Integration Provider's Guide for instruction how to run the deployment script - http://download.pa.parallels.com/poa/Office365/doc/70393.htm.


Improved User Seat Downgrade Report

The downgrade report is generated according to Microsoft requirements. Refer to the Knowledgebase article https://kb.odin.com/en/112959 for details.


New 'Administration' Screen

Account Administrator credentials and link to Microsoft Online Portal are placed together in the new ‘Administration’ screen:




Note: after importing the Office 365 package and before upgrading the application instances Provider has to configure the Office 365 Application Resource Type in POA:

  • Go to Service Director > Provisioning Manager > Resource Types
  • Click on the Office 365 Resource Type based on the 'Application' Resource Class
  • Switch to the Activation Parameters > Services tab
  • Set the Autoprovisioning property of the Administration service to 'Yes'


Support the new format of MX records

The mail routing in Office 365 is changing. To make email routing more efficient, this change requires each custom domain to have a unique Mail Exchange (MX) record value.
The Office 365 Gateway Application has been updated in order to meet the new requirements.


Office 365 Wave 15 support

Microsoft released the next version of the Office 365 - Office 365 Wave 15.

The Office 365 package has been updated in order to support new services, Provider has to create resources based on Application Service Resource Class for new Microsoft Office 365 offers.

Note: the Lync add-ons 'Lync to Phone Add-on‘ and 'Lync Online (Plan 3) Add-on‘ are not supported yet in the Microsoft Office 365 4.0 package.


The POA hosting subscription ID is stored in the O365 Gateway DB

The new field hostingSubscriptionId has been added to the customer data structure in the MOSI Gateway database. It helps to make matching entities between POA and Gateway database more easy.

 

caea8340e2d186a540518d08602aa065 5356b422f65bdad1c3e9edca5d74a1ae e12cea1d47a3125d335d68e6d4e15e07

Email subscription for changes to this article
Save as PDF