Offboarding the PortalTalk application

The moment the PortalTalk license contract is terminated, the so-called off-boarding protocol will be started. This consists of;

1. The connection between PortalTalk and the Microsoft 365 tenant will be lost,

2. The customer specific data will be deleted from the PortalTalk databases,

3. The specific settings or configurations made by PortalTalk are restored to their former state.

If these above 3 steps have been completed, there is a complete offboarding of the PortalTalk application

Offboarding steps in detail

For each offboarding step, it is described in detail below.

1.     Disconnect customer tenant consent with the PortalTalk application

The PortalTalk application has a so-called 'consent' to the customer tenant. In addition to authentication, permissions to the tenant are also defined in here. Definition has been made in the Microsoft Azure Portal, AAD Enterprise Apps. The app were these permissions are defined is called 'QS PortalTalk'. The administrator with Global Admin role should uninstall this application. This action completely disconnects the PortalTalk app.

2.     Deletion of customer-specific data in the PortalTalk databases

The data collected from the customer during the operational phase of the application will be deleted from the databases.  It consists of basic data of the users and the Azure Active Directory groups, and MS Teams and SharePoint sites created and managed by PortalTalk.

After deleting data, it can be restored for another 30 days. After this, the data will be permanently deleted. This is part of the standard backup procedure of the database platform used for PortalTalk.

3.     Restore specific settings or configurations on the customer tenant

PortalTalk has a number of specific functions where Microsoft default settings are modified or cannot be modified via the Microsoft user/administrator interface.

 This concerns the following settings in PortalTalk:

1. MS Teams configured categories with read role

2. Setting to invite External guests in a MS Teams team workspace

3. PortalTalk MS Teams app as organization app in the MS Teams app store

4. SharePoint Sites and Member web parts in the local Apps for SharePoint store

5. AAD groups created and managed by PortalTalk with 3 added extension attributes

6. System users and AAD groups created for various configurations and granting access via groups

 The above settings can be removed /undone by offboarding manually or with script. Below is a detailed description of how to make adjustments per item.

MS Teams configured categories with read role

If a team workspace in MS Teams category with Read role ON is created, the following specific configuration for this team and linked SharePoint site is performed;

• To get a Read-role function, a SharePoint and AAD group are created and nested to redirect the permission from ‘Edit’ to ‘Read’ access.  Access to the default SharePoint ‘Members’ group is set to ‘No Access’.

• To change this after offboarding, QS solutions provides a PowerShell script 'Remove PortalTalk Read-only configuration per team.ps1'. This script can be run by an administrator to reset the MS Teams team workspaces ‘Read’ permission to the Microsoft default. For users who only had ‘Read access’, after running the script they will have 'Edit' access again and therefore are Members of the team.
  Product Backlog Item 66045: [PT off-boarding] PowerShell script to remove PortalTalk Read-role function on MS Teams workspaces

Setting for invite External guests to MS Teams team workspaces

In PortalTalk it is possible to configure the invitation of external guests per 'Workspace type' of an MS Teams category.

• When PortalTalk is off-boarded, team workspaces that have been assigned external invite "off" through a PortalTalk "Workspace type," will remain at that setting.

• To adjust this after offboarding, QS solutions provides the Powershell script 'Set team workspace external invite property back to Allowed.ps1'. Script will reset the MS Teams team workspaces that have external invite 'Not Allowed' back to the default setting 'Allowed'. Script should be executed by a Global Admin.  
  Product Backlog Item 66046: [PT off-boarding] PowerShell script to set External Invite disabled on MS Teams workspaces back to original Enable function

• Pay attention if Microsoft Information Protection (MIP) label is used on team workspaces for your organization. It is recommended to not use this PortalTalk script.

PortalTalk MS Teams app as organization app in the MS Teams app store

To use PortalTalk within the MS Teams application, the PortalTalk MS Teams app is installed as an Organization app. It must be removed after offboarding PortalTalk in the MS Teams Admin Center.

SharePoint Sites and Member web parts in the local Apps for SharePoint store

If the PortalTalk Sites and/or Member web parts are used, they must be deleted in the SharePoint Admin center.  In the SharePoint Admin center, this is done in the Apps for SharePoint store. Also remove the SharePoint API access user impersonation for PortalTalk web parts.

 AAD groups managed by PortalTalk with 3 added extension attributes per group.

To distinguish which AAD security groups have been created by PortalTalk, groups are provided with extension attributes. This is a Microsoft-supported method of giving specific attributes to an AAD object. These have no further impact on the operation of the object. If the preference is to remove these attributes from the PortalTalk-managed AAD security groups after offboarding PortalTalk, QS solutions provides a PowerShell script to remove these attributes.
NOTE: Do not run this script on an active PortalTalk instance that is onboarded. This can irreparably damage the PortalTalk integration with the AAD.

Product Backlog Item 66735: [PT off-boarding] PowerShell script to remove PortalTalk AAD controlled security groups extension parameters

System users and AAD security groups created for various configuration purposes

PortalTalk uses for various functions system users and AAD security groups.
 
It concerns the following functions with associated AAD objects:

• Configuration settings - > Invite: Exchange Online Mailbox (delete mailbox)

• Configuration settings - > SharePoint: Account for creating Modern Team Sites

• Configuration settings - > SharePoint: Default owner for automated site registration

• Configuration settings - > MS Teams: Default owner of archived MS Teams

• Configuration settings -> categories -> Any category -> Create or request workspace: AAD group(s) for creation and requests

• Configuration settings - > SharePoint categories -> Category settings: OAG (Organisation Access Group) AAD public access group

4.     Insight into non-customizable settings and their consequences

PortalTalk has built one configuration, which should not be modified. This is for the permission assignments of SharePoint sites. To manage permissions in SharePoint sites, PortalTalk uses the Microsoft-supported features of AAD security groups nested in SharePoint groups. The SharePoint group is connected to a permission level within a site. This is the way PortalTalk distributed permissions. After offboarding, this structure remains in place and permissions can be manually distributed or removed to the connected AAD groups. Which AAD groups are used, can be seen in the SharePoint groups of the relevant SharePoint site. This mechanism has been applied to both team site (site collections) and team site (sub-sites) and is not used in the SharePoint sites linked to MS Teams.