Univention Bugzilla – Bug 43064
Only one service plan configurable
Last modified: 2016-12-15 14:29:24 CET
The customer got two Office 365 licences for his members. 1. For Teachers (Office 365 ProPlus für Lehrpersonal) 2. For Students (Office 365 ProPlus für Schüler/Studenten) With the command "Get-MsolAccountSku" from Powershell (see https://msdn.microsoft.com/en-us/library/dn568014.aspx) we found out that the corresponding service plan names are: 1. For Teachers (Office 365 ProPlus für Lehrpersonal) = schulenXY:OFFICESUBSCRIPTION_FACULTY 2. For Students (Office 365 ProPlus für Schüler/Studenten) = schulenXY:OFFICESUBSCRIPTION_STUDENT Thanks to the UCR-Variable "office365/subscriptions/service_plan_names" we managed to set up test accounts with the value OFFICESUBSCRIPTION: office365/subscriptions/service_plan_names: "OFFICESUBSCRIPTION" This users got the first license (For Teachers - Office 365 ProPlus für Lehrpersonal) assigned. What doesn't work were: office365/subscriptions/service_plan_names: "OFFICESUBSCRIPTION_STUDENT" office365/subscriptions/service_plan_names: "schulenXY:OFFICESUBSCRIPTION_STUDENT" We faced two main problems. First we do not managed to assign the second licence "For Students (Office 365 ProPlus für Schüler/Studenten)" via the Office 365 Connector. Following ressources indicate that it must be somehow possible to set up OFFICESUBSCRIPTION_FACULTY and OFFICESUBSCRIPTION_STUDENT as service plans: https://blogs.technet.microsoft.com/treycarlee/2014/12/09/powershell-licensing-skus-in-office-365/ https://blogs.technet.microsoft.com/educloud/2014/02/05/what-are-my-sku-names-for-office-365-education-and-how-can-i-automate-the-licensing/ Secondly on UCS side it is not possible to assign different service plans to different types of users (e.g. group xy = OFFICESUBSCRIPTION_FACULTY / teachers = OFFICESUBSCRIPTION_FACULTY / students = OFFICESUBSCRIPTION_STUDENT).
I was asked to specify here the use cases which the customer has. The customer has two uses cases. BTW: Other school customers already asked for the same use cases. 1. Use case - Automatically import students 1.1 An Import is triggered by a school. The XML-Data only contains students. 1.2 Created students get a mailPrimaryAddress automatically (username@maildomain.de). 1.3 On all new created students the Attribut "Benutzer für Nutzung von Office 365 aktivieren" will be set (I will refer to it later on!) and the students were synchronized to the AzureAD. 1.4 All synchronized students in the AzureAD get the "Office 365 ProPlus für Schüler/Stundenten" service plan and all "subservices" (see Bug #43065) except "Office 365 ProPlus" will be deselected. This must be somehow configurable (I will refer to it later on!) 2. Use case - Create teachers 2.1 A school administrator created a new teacher in the Modul "Users (Schools)". Including a mailPrimaryAddress 2.2 On this new created teacher the Attribut "Benutzer für Nutzung von Office 365 aktivieren" will be set (I will refer to it later on!) and the students were synchronized to the AzureAD. 2.3. All synchronized teachers in the AzureAD get the "Office 365 ProPlus für Lehrpersonal" service plan and all "subservices" (see Bug #43065) except "Office 365 ProPlus", "Office Online für Bildungseinrichtungen", "OneDrive for Business (Plan 1)" will be deselected. This must be somehow configurable (I will refer to it later on!) So, for this use cases we have three feature requirements. A. Set the Attribut "Benutzer für Nutzung von Office 365 aktivieren" (Use cases: 1.2 & 2.2) automatically. It is not possible to set it in the Modul "Users (Schools)" and the Import-Tool currently can't set it either. At present we think about a hook which we will implement in the project. BUT if you think about a possibility to address this issue I prefer a possibility to set it at a group (e.g. schueler-ouXY, lehrer-ouXY). This has the advantage to set it very granular for schools. B. Assign the right service plan. Currently it is possible to set up "OFFICESUBSCRIPTION". Than the AzureAD-API give a list of Officesubscriptions back (here "OFFICESUBSCRIPTION_STUDENT" & OFFICESUBSCRIPTION_FACULTY). Currently the connector take the first one. This list must be selectable per group (e.g. schueler-ouXY, lehrer-ouXY). Nice (no must) would be a multi-value field to select multiple service plans if one service plan is "full" and the school ordered a further service plan. C. Deselect a list of "subservices". On Bug #43065 you will find a list of subservices which are currently are selectable in the Office 365 Interface. This "subservices" must be deselectable per group (e.g. schueler-ouXY, lehrer-ouXY). At least globally. Unfortunately the amount of subservices can be change over time. So, I would prefer a UCR-Variable which will have a list of "available" subservices and from this list the Administrator can disable per group the services. Hope this helps.
> A. Set the Attribut "Benutzer für Nutzung von Office 365 aktivieren" (Use > cases: 1.2 & 2.2) automatically. It is not possible to set it in the Modul > "Users (Schools)" and the Import-Tool currently can't set it either. At > present we think about a hook which we will implement in the project. BUT if > you think about a possibility to address this issue I prefer a possibility > to set it at a group (e.g. schueler-ouXY, lehrer-ouXY). This has the > advantage to set it very granular for schools. It is possible to add arbitrary fields (incl. extended attributes) to the CSV file and mapping-configuration of the import: Bug #41707. > C. Deselect a list of "subservices". On Bug #43065 you will find a list of > subservices which are currently are selectable in the Office 365 Interface. > This "subservices" must be deselectable per group (e.g. schueler-ouXY, > lehrer-ouXY). At least globally. Unfortunately the amount of subservices can > be change over time. So, I would prefer a UCR-Variable which will have a > list of "available" subservices and from this list the Administrator can > disable per group the services. I suggest to use both a whitelist and a blacklist per subscription. This way it will be possible to configure all variations.
(In reply to Daniel Tröder from comment #2) > > A. Set the Attribut "Benutzer für Nutzung von Office 365 aktivieren" (Use > > cases: 1.2 & 2.2) automatically. It is not possible to set it in the Modul > > "Users (Schools)" and the Import-Tool currently can't set it either. At > > present we think about a hook which we will implement in the project. BUT if > > you think about a possibility to address this issue I prefer a possibility > > to set it at a group (e.g. schueler-ouXY, lehrer-ouXY). This has the > > advantage to set it very granular for schools. > It is possible to add arbitrary fields (incl. extended attributes) to the > CSV file and mapping-configuration of the import: Bug #41707. Yes, I know but the customer has a project specific "Import-Tool" and the XMLs/CSVs are not changeable (encrypted). A modification in the project specific "Import-Tool" wouldn't be a big issue but because the teachers can't be included either we decided to implement a hook for all users.
The concept is now the following: * Groups will receive an additional extended attribute, which will store the name of a profile. * Profiles will be stored either as UDM objects (settings/...) or in ini-files on disk - both are easy for users to edit. * A profile has - a name (identifier used in ext. attribute of groups) - a list of subscriptions - a list of whitelisted plans (all other plans will be deactivated) - a list of blacklisted plans (those plans will be deactivated) The white and black lists are applied to all subscriptions of a profile. A UDM syntax will be created, that will allow to choose in the groups UMC page between known profiles. The listener module will collect all subscription-profiles from all groups a user is in. It will then select the first subscription that has a free seat. When assigning that subscription to the user, the restrictions on the plans (from the profile the subscription was found in) will be honored.
A short cmdline script will help users (admins) identify their subscription names and associated plans.
r74989: * add OFFICESUBSCRIPTION to list of plans used to identify office subscritions * add cmdline script to help users identify their subscription names and associated plans * modify user/group printing script to display plans in use by each user
Update path and ease of use for customers with only one subscription: If a user is enabled for office365 and non of its groups have a profile configured, the previous behavior is used: one of all possible subscriptions with all plans activated is used.
A note will be added to the last page (or one of the last pages... explaining that a checkbox has to be activated on the user to sync) "if you have more than 1 subscription in use, follow this like" → to an article in the wiki/sdb that explains this whole thing with groups and profile.
r75032: added support for subscription profiles
r75052: * list which license is used by each user * list licences even if all plans were deactivated * fix Consumed<->Remaining transposition
I added profile configuration and import into the listener, see bug #43134 However, when adding a user, the listener seems to not correctly detect available licenses, please recheck this: 08.12.16 16:59:11.322 LISTENER ( ERROR ) : o365(I): listener.assign_subscription:495 SubscriptionProfiles found for 'univention5': [SubscriptionProfile(MyEnterpriseProfile-NoPowerApps: [])] 08.12.16 16:59:11.323 LISTENER ( ERROR ) : o365(D): listener.assign_subscription:506 seats={u'ENTERPRISEPACK': (5, 3, u'6fd2c87f-b296-42f0-b197-1e91e994b900')} 08.12.16 16:59:11.323 LISTENER ( ERROR ) : o365(E): office365-user.handler:273 User univention5/d0ab384f-9378-4f67-a300-881bc8474524 created in Azure AD, but no allocatable subscriptions found.
Regarding comment6: I think we should ship these scripts and install them on UCS
(In reply to Erik Damrose from comment #12) > Regarding comment6: I think we should ship these scripts and install them on > UCS Already done in r75032: they are installed in /usr/share/univention-office365/scripts/.
*** Bug 43065 has been marked as a duplicate of this bug. ***
A SubscriptionProfile does not have a list of subscriptions anymore, but only one subscription. ---------------------------------------------------------------------- r75259: * Bug #43064: adapt code to subscription being a single value UDM property * cleanup SubscriptionProfile * fix whitelist / backlist calculation * refactor udm_helper to reduce duplicate code * restart umc-server to make it aware of new syntax * add test that checks license assignment and plan restrictions (92_office365/06_udm_group_members) Package: univention-office365 Version: 0.2.13-1.50.201612132139 Branch: ucs_4.1-0 Scope: office365
OK: Code changes OK: functionality: * Add profile with deactivated POWERAPPS * Add profile to a group * Create 2 users, one in group with profile * One user has POWERAPPS activated, the other deactivated -> Verified
Fixed in App version 1.2, bug #43181