How the Moodle and Microsoft 365 integration works
Moodle and Microsoft 365 are connected with Microsoft's open-source o365-moodle plugin set. It lets staff and students sign in to Moodle with their work accounts and reach Microsoft 365 Groups and their files from inside courses. Moodle core does not include this integration. It is added through plugins, and the work runs in infrastructure you control, so your Moodle servers and the connection to your Microsoft 365 tenant are both operated under your own governance, by your team or by an implementation partner you choose. The set is made up of several plugins, each with a separate job. auth_oidc provides single sign-on through OpenID Connect and works with configurable identity providers, including Azure Active Directory, which the plugin directory still uses as its name. local_o365 matches users between the directory and Moodle and creates Microsoft 365 Groups from Moodle courses. repository_office365 shows Microsoft 365 Group files in the Moodle file picker. block_microsoft and theme_boost_o365teams add Microsoft-facing interface elements, and the OneNote plugins are optional. Decide early which of these you need, because each one asks for permissions and configuration in both systems. The main plugins are maintained for the directory listings by the Enovation Dev Team. The auth_oidc and local_o365 listings state support for Moodle 3.9 to 5.2 and say that supported versions follow core Moodle version support. Before any Moodle upgrade, check the plugin version against the Moodle release you plan to run. If your target is newer than the range listed, ask the plugin maintainers or your implementation partner to confirm compatibility in writing before you upgrade, and test the upgrade on a copy of your site first. The design decisions that matter most sit between the two systems. Choose the attribute used to match a Moodle account to a directory account, and confirm how accounts that already exist in Moodle will be handled. Decide which roles may create Microsoft 365 Groups from courses and how those groups are named and archived. Confirm with your Microsoft administrators which app registration and permissions the plugins will request in your tenant. Finally, keep a local administrator account outside single sign-on so that a misconfigured identity provider cannot lock every administrator out of Moodle.
What you need before the Moodle and Microsoft 365 integration starts
The integration depends on six prerequisites owned by different teams: the Moodle server, the plugin versions, the Microsoft tenant, Microsoft 365 licensing, network paths and a test copy. Confirm each one before the build starts, because a gap in any of them usually appears as a failed sign-in or a missing Group during testing.
Moodle version and server stack
Moodle 5.1 requires 64-bit PHP 8.2 or later (8.3 and 8.4 are supported) and one of PostgreSQL 15, MySQL 8.4, MariaDB 10.11 or SQL Server 2017 or later. Moodle 5.3 requires PHP 8.3 or later, PostgreSQL 17, MariaDB 11.4 or SQL Server 2019 or later. Upgrades to 5.1 must start from Moodle 4.2.3 or later, and upgrades to 5.3 from Moodle 4.4 or later. From 5.1, point the web server document root at the /public directory, or the site may show directory listings or errors.
Plugin versions matched to Moodle
The Microsoft plugins local_o365 and auth_oidc list support for Moodle 3.9 to 5.2 and follow core Moodle version support. Choose the plugin release listed for your target Moodle version before installing anything. If you plan to move to 5.3, check the plugin directory again first, because the listed range currently stops at 5.2. Record the plugin versions in your change log so each Moodle upgrade starts with a compatibility check.
Entra ID tenant with application rights
The auth_oidc plugin signs users in through OpenID Connect with Microsoft Entra ID, so you need a tenant and an account with administrator rights to register an application there. Confirm who holds that role, whether the registration needs approval from your identity or security team, and which redirect addresses your Moodle domain will use. Decide early whether the tenant is the same one your staff already use to sign in.
Microsoft 365 licensing for Groups and OneNote
local_o365 creates Microsoft 365 Groups from Moodle courses, and repository_office365 shows Group files in the file picker, so every teacher and student who uses these features needs access to Groups. OneNote assignments depend on the optional OneNote plugins and on each user's OneNote access. Ask your Microsoft licensing contact to confirm which plans include Groups and OneNote for your staff and learners, and who pays for those licences.
Outbound HTTPS from the Moodle server
The Moodle web and cron hosts must make outbound HTTPS requests to Microsoft sign-in and Microsoft Graph endpoints for sign-in, user matching, Group creation and file access. Ask your network team to allow those destinations from both hosts, and check any proxy or traffic inspection device, because it can break the token exchange. Confirm the exact endpoint list in the plugin documentation for your release before opening firewall rules.
Non-production Moodle copy for testing
Build and test the integration on a copy of your Moodle site with its own database and moodledata directory, kept separate from production. Use a test Entra application and test Microsoft 365 Groups so that trial courses do not create Groups or accounts that staff and students can see. Plan the copy early, because a sync run against production data can create Groups that are difficult to remove cleanly.
Which plugin handles each Microsoft 365 feature
Each Microsoft 365 capability in a Moodle integration comes from a specific plugin, and knowing which one does what decides how you plan configuration, testing and upgrades. The Microsoft o365-moodle repository lists the core set. auth_oidc provides single sign-on with Azure Active Directory (now Entra ID) through OpenID Connect. local_o365 handles user matching between Entra ID and Moodle and creates Microsoft 365 Groups from Moodle courses. repository_office365 exposes the files in those groups inside the Moodle file picker. block_microsoft adds the Microsoft block, theme_boost_o365teams applies Teams-style theming, and the optional OneNote plugins support OneNote assignments.
Each feature can be enabled separately, so the rollout can be staged. A common approach is to start with sign-in alone, confirm that accounts match the right people, and only then enable course group creation or file access. Authentication is the highest-risk step because it governs who can log in, so it deserves its own test cycle before anything that writes to Microsoft 365. Group creation is also worth a controlled pilot, since groups created from courses are tied to tenant policies that your Microsoft 365 administrators own. Decide the order before installation, and record which plugins are on in each environment.
The plugin set is not the same as Microsoft Teams app integration. The plugins described here work inside Moodle and call Microsoft 365 services such as Entra ID and Groups. They do not by themselves install a Moodle app into Teams, publish Moodle content as a Teams tab or manage Teams meetings. If your plan includes Teams-hosted access, treat that as a separate piece of design with its own Microsoft 365 configuration and its own testing.
Each plugin has its own settings, and those settings change over time. Before you configure anything, read the current documentation for each plugin in the Moodle plugins directory and in the o365-moodle repository, and confirm the exact fields, permissions and redirect addresses for your Moodle version. The plugins directory lists support for Moodle 3.9 to 5.2 for local_o365 and auth_oidc and states that they follow core version support. Check that your target Moodle release is in that range, and confirm the same for any optional plugin you plan to use, since a version mismatch is one of the most common causes of a failed upgrade.
Ask your integration partner to map each feature to a plugin, a Microsoft 365 permission set and a named owner in both Moodle and the Microsoft tenant. That map becomes the basis for your test plan and your change records. It also makes it clear which plugins you can disable without affecting sign-in, which matters when a Moodle upgrade forces a plugin update.
Configuration sequence for the Moodle and Microsoft 365 integration
This sequence moves the Moodle and Microsoft 365 integration from a single test account to production in a fixed order, so each plugin is proven before the next one depends on it. Each step closes with a check you can record. Identity matching and group creation carry the most risk, so both are tested in a non-production course before anything reaches learners.
Confirm the Moodle and plugin version pair
Your Moodle administrator compares the Moodle release on your test site with the plugin listings for auth_oidc and local_o365. Both list support for Moodle 3.9 to 5.2 and state that their supported versions follow core Moodle version support, so confirm the current listing before you install anything. Also confirm the PHP and database versions required by your Moodle release, and on Moodle 5.1 or later confirm the web server points to the /public directory. Check: a written record of the Moodle version, PHP version, database version and the exact plugin release numbers that match them.
Register the application in Entra ID
A Microsoft 365 or identity administrator creates an app registration for the Moodle site in Entra ID. Confirm the permissions each plugin requests in its documentation before consent is granted, and store the client secret in your organization's secrets store rather than in a ticket or a configuration file. Record the tenant identifier and the client identifier in the change record. Check: the app registration exists, its tenant and client identifiers are recorded, and the consent status matches the permissions you confirmed.
Install auth_oidc and test one sign-in
Install the auth_oidc plugin on the test site through your normal deployment path, then configure Entra ID as an OpenID Connect identity provider using the tenant identifier, client identifier and the redirect URL that the plugin displays. Ask the identity administrator to confirm that the redirect URL matches the one registered in Entra ID. Sign in with one test account, then check which account Moodle created or matched and which profile fields arrived. Check: a successful sign-in and sign-out, with the account name, timestamp and received attribute values written down. Fix any mismatch before going further.
Install local_o365 and configure user matching
Install local_o365 on the test site, connect it to your Microsoft 365 tenant and configure how Entra ID accounts are matched to Moodle accounts. Run the matching against a small, known set of test users and keep the test course the only place where course-level features are enabled. Review each match with your Moodle administrator, because a wrong match can link a learner to another person's account. Check: the matched accounts equal the test user list, no unexpected accounts are matched, and every mismatch is documented with the decision taken.
Enable group creation for test courses only
Turn on the option that creates Microsoft 365 Groups from Moodle courses, and apply it only to one test course. Before you enable it, ask your Microsoft 365 administrator which tenant policies govern group creation, ownership and deletion, because those policies decide what a teacher can do with a group. Confirm that the group membership follows the course enrolments and that the group name follows your naming convention. Check: the test course has one matching Microsoft 365 Group with the expected owner and members, and the archive and deletion behavior has been confirmed in writing.
Install repository_office365 and confirm group files
Install repository_office365 on the test site, then open the file picker in an activity inside the test course that has a linked group. Confirm that the group's files appear in the picker and that a file chosen from the picker can be attached to the activity. Repeat the check with a student test account that is not a member of the group, because access should follow the Microsoft 365 Group membership. Check: the teacher account sees the group files, the non-member account does not, and both results are recorded in the test log.
Add the block, theme and OneNote plugins if needed
Add the optional components only where the course design requires them, and keep this order. Install block_microsoft and the Teams theme, boost_o365teams, if your design uses them, and check the theme on the test site with a student account and a teacher account. Install the OneNote plugins last, since they depend on the course structure and the group setup already being correct. Check: each optional component you installed loads without errors for both account types, and any component you skipped is recorded with the reason.
Move the configuration to production with a change record
Promote the tested configuration to production using the same deployment method used for the test site, and avoid manual edits in production. Write a change record that lists the Moodle and plugin versions, the identifiers recorded in earlier steps without secrets, the matching rules, the group policy and the test results from each step. Your change board approves the record before the switch, and the rollback steps are written down. Check: the signed change record exists and production sign-in, matching and file picker checks pass with a test account.
How Entra ID accounts match Moodle users and courses
This table maps each Entra ID attribute and Microsoft 365 Group setting to the Moodle field or course behavior it drives, with the decision your institution must make for each. Read the rows top to bottom, since the matching key and the account-linking rule determine everything after them. Settle these choices in writing before the first sign-in test, because changing the key later means re-matching existing accounts.
| Item | Moodle side | Entra ID or Microsoft 365 side | Decision for the institution |
|---|---|---|---|
| Matching key | Moodle user record, matched by the attribute the local_o365 rule uses | Object ID is stable for the life of the account; UPN and email can change | Choose the unique key. Confirm in your plugin version which attribute the rule uses and whether a stable value is available. |
| User principal name | Moodle username field, if the UPN is used as the sign-in name | Sign-in name, often the organization domain format | Decide whether the UPN is the Moodle username and how renamed or domain-changed users are handled. |
| Email address | Moodle email field, used for notifications and sometimes as a fallback match | Mail attribute, which may be empty for some accounts | Decide whether email is a matching fallback or contact data only, and how duplicate addresses are resolved. |
| Given and family names | Moodle firstname and lastname fields in the user profile | givenName and surname attributes | Decide whether Entra ID is the source of truth for names and whether Moodle updates them on each sign-in. |
| Existing Moodle accounts | Accounts created before the integration, which may hold grades and enrolments | Matching Entra ID user, located by the chosen key | Decide whether pre-existing accounts link automatically or after review, and who resolves unmatched or duplicate records. |
| Entra ID users with no Moodle account | Account created on first sign-in or by sync, depending on your configuration | Licensed or assigned Microsoft 365 users in the scope you set | Decide which users may sign in and whether to restrict creation to specific Entra ID groups. |
| Moodle accounts with no Entra ID match | Local, guest or service accounts that stay outside Microsoft sign-in | No matching object in the directory | Decide which accounts keep password or other login methods and who reviews them each term. |
| Moodle course to Microsoft 365 Group | Course, with teachers and students enrolled in Moodle | Microsoft 365 Group that holds membership, the shared calendar and group files | Decide whether every course gets a Group or only selected ones, and set the naming convention before creation. |
| Group owners and membership | Course teachers with editing roles, and enrolled students | Group owners and members, changed in Entra ID or through the integration | Decide who owns each Group, how ownership passes when a teacher leaves, and who may change membership by hand. |
Who owns the Microsoft 365 Group for each course
The decision to settle before enabling Group creation at scale is who owns each course's Microsoft 365 Group, what happens to it when the course changes state, and how long its data is kept. In the o365-moodle set, local_o365 is the plugin that creates a Microsoft 365 Group from a Moodle course. Once that Group exists, Moodle enrolments and Microsoft 365 membership are no longer the same record, so each change needs a defined owner. Confirm with your Microsoft 365 administrator which account, or which role, will be the Group owner of record for courses created by the plugin, and whether teachers are added as owners or only as members. Those two choices determine who can change Group settings, add people and delete the Group from Microsoft's side. The Moodle roles that matter are the ones that carry course-level rights. Confirm in your test tenant which Moodle roles the plugin maps to Group owners and which to members, and whether that mapping matches your institution's view of who is accountable for a course. Enrolment changes are where drift appears. Test adding a student, removing a teacher, and suspending an enrolment, then check whether Group membership changes in the same way. A suspended student who keeps Group membership can still reach Group files and the shared mailbox, so the sync behavior for suspension and unenrolment needs to be documented, not assumed. Archiving, copying and deleting a course each affect the Group differently. A copied course is a new Moodle course, so ask whether the plugin creates a second Group or reuses the first one, and who owns the copy. Deleting a course in Moodle does not automatically mean the Microsoft 365 Group is deleted, and an archived course may still be accessible through its Group. Test each path in a non-production environment and record the outcome. Those results feed directly into the retention rule. A Microsoft 365 Group carries its own mailbox, calendar and files. Access decisions made in Moodle therefore affect Microsoft 365 data as well as Moodle data. Removing someone from a course may not remove their access to the files they already downloaded or to the Group's conversation history. Before scaling, agree a written ownership and retention rule that names the owner of record, the trigger for removing access, the retention period for Group content after a course ends, and who approves deletion. The institution's records and privacy staff should review it, and the rule should be tested with a sample of real course types before Group creation is turned on for every course.
Security settings for the Moodle and Microsoft 365 integration
This integration gives Moodle a direct trust relationship with your Microsoft Entra ID tenant and Microsoft 365 Groups, so each setting below extends what your identity and collaboration systems can do. Decide these controls before the first connection test, then record who approved them and how they will be reviewed.
Least-privilege Entra ID permissions
The Moodle app registration needs only the Microsoft Graph application permissions that auth_oidc and local_o365 require for the features you enable. Remove optional features you do not use, such as OneNote or group creation, so their permissions are never requested. Have your security team review each permission and record the admin consent decision before anyone grants tenant-wide consent. Confirm the exact permission list against the plugin documentation for your release, because it changes as features change.
Client secret and certificate handling
Decide whether the Moodle app registration authenticates with a client secret or a certificate. Store the secret or certificate in your secrets manager, not in the Moodle configuration database or a shared configuration file. Set an expiry that matches your rotation policy, add a calendar reminder and a tested procedure for replacing the credential before it lapses. A lapsed credential stops sign-in for every user, so rehearse the rotation in a staging site first.
Redirect URL restrictions
The redirect URIs registered on the Entra ID application must match the exact callback addresses of your production and test Moodle sites, using HTTPS. Remove placeholder, localhost and retired hostnames from the registration. Confirm that the wwwroot value in Moodle matches the public hostname, because a mismatch causes failed sign-ins or an open redirect surface. Review the list whenever a domain, reverse proxy or site copy changes.
Conditional access and MFA for Moodle
Create a conditional access policy scoped to the Moodle application so that sign-in to Moodle follows the same MFA, device and location requirements as your other sensitive applications. Test the policy with a pilot group that includes teachers, students and administrators, since each group may reach Moodle from different networks. Confirm how Moodle sessions behave when Entra ID requires re-authentication, and document the expected user experience for support staff.
Limiting Moodle roles that create Groups
Course-to-group creation in local_o365 runs under Moodle roles, so the capability to create Microsoft 365 Groups should be granted only to the roles that need it. Review which roles in your Moodle instance hold that capability, including roles created by plugins or custom role definitions. Assign group creation to a small set of administrators or course managers, and document the approval step for new groups so that sprawl in your Microsoft 365 tenant is controlled.
Logging and review of sign-in and Group events
Decide which events must be retained: Moodle authentication and log store entries, Entra ID sign-in logs, and audit records for Microsoft 365 Group creation. Forward or export them to the log platform your security team already uses, and set a review cadence with named reviewers. Check that the timestamps and user identifiers in both systems can be matched during an investigation. Confirm retention periods against your own policy and any regulation that applies to your education or workforce records.
Keeping Moodle and PHP within vendor support
Moodle security support is published per release on the Moodle releases pages. Moodle 4.5 has security support until 4 October 2027, Moodle 5.1 until 19 April 2027, and Moodle 5.2 until 4 October 2027, and Moodle 5.3 has security support until 1 October 2029. Check that your target release and PHP version appear in the auth_oidc and local_o365 supported versions before you upgrade, because those plugins follow core support. Schedule the upgrade window and the plugin update tests together, not as separate projects.
Common failures in the Moodle and Microsoft 365 integration
This table lists the failures teams most often hit when they connect Moodle to Microsoft 365 with Microsoft's plugin set, with the usual cause and fix for each. Read each row as a check to run during the build and again after every Moodle upgrade. Most failures trace back to decisions made early: the redirect URL, the user matching attribute and the Moodle version the plugins support.
| Failure | Usual cause | Fix |
|---|---|---|
| Sign-in loops or redirect mismatch errors | The redirect URL registered in the Entra ID application does not exactly match the callback URL shown in the auth_oidc settings. | Copy the redirect URL from the Moodle plugin settings into the Entra ID app registration, then test sign-in in a non-production site. |
| Users cannot be matched to Entra ID accounts | The chosen unique attribute is missing for some users, or its value differs in case from the value stored in Entra ID. | Audit the attribute across all users before go-live, normalize case where needed and confirm the matching rule in a test run. |
| Duplicate Moodle accounts after changing the matching attribute | Switching the matching attribute creates new identity links, so existing accounts no longer match the same people. | Choose the matching attribute before users sign in, reconcile existing accounts first and test the switch on a copy of the database. |
| Plugin errors after a Moodle upgrade | The installed plugin release does not list the new Moodle version. The local_o365 and auth_oidc plugins list support up to Moodle 5.2. | Check the plugin directory listing before upgrading Moodle, and hold the upgrade or update the plugins to a release that supports the target version. |
| Group files missing from the file picker | The signed-in user lacks permission to the Microsoft 365 Group or its SharePoint site, so the repository has nothing to show. | Confirm the user is a member of the group and has site access in Microsoft 365, then check the repository_office365 settings. |
| Microsoft 365 Group creation fails | Missing licenses for the account or a tenant policy that restricts who can create groups blocks the request from Moodle. | Ask the Microsoft 365 administrator to confirm license assignment and group creation policy for the service account before testing course sync. |
| Moodle 5.1 document root errors | The web server still points to the main Moodle folder instead of the /public directory that Moodle 5.1 requires. | Change the document root to the /public directory, reload the web server, and confirm the site no longer shows directory listings or errors. |
| Theme changes lost after a plugin update | Edits made directly to theme_boost_o365teams files are overwritten when the plugin is updated. | Keep customizations in a child theme or documented settings, then reapply and test them in staging after each plugin update. |
How to test the integration before students and staff use it
Test the Moodle and Microsoft 365 integration on a copy of your production site before any student or staff member signs in through it. The test plan should cover four areas: sign-in, user matching, group membership and file access, plus restore and upgrade behavior. Each test needs a named owner, an expected result and a recorded outcome, so the plan can be reused for each change to the site or the tenant.
Start with sign-in. Use test accounts for each population that will use the site: staff, students, existing Moodle accounts that already have a password, and new accounts that do not exist in Moodle yet. Run the sign-in through auth_oidc against the Entra ID application registration you intend to use in production, and confirm the redirect URI matches the Moodle copy's address. Check what happens when a user is disabled in Entra ID, when a user's password is changed, and when a user signs in from a browser where another Microsoft account is already active. Confirm with your identity team which tenant and application settings the test must mirror, because a test that passes against a different configuration proves little.
Next test user matching, which is where local_o365 most often produces surprises. Include edge cases on purpose: a student whose surname changed after enrolment, two accounts with similar display names, a shared mailbox or service account that appears in the directory, an account whose email address differs from its username, and a user who has been renamed in Entra ID. For each case, record which Moodle account the integration links to and whether a duplicate is created. Ask the vendor and your own team to agree in writing which field is the matching key, because the answer decides how name changes are handled later.
Then test Microsoft 365 Group creation and membership across enrolment changes. Enrol a test student, move that student to another course, suspend the enrolment, and remove it, checking after each step whether the group membership in Microsoft 365 changes as expected. Repeat with a teacher role and a teaching assistant role. Test file access through repository_office365 with read-only and write-access users, and confirm that a user without group membership cannot see or edit group files. Record which permissions Microsoft Graph grants to the integration and confirm them with your tenant administrator before the pilot.
Finish with restore, upgrade and pilot. Restore a recent backup of the Moodle copy into a separate environment and confirm that the integration settings, tokens and matched accounts behave correctly after restore, since restored tokens or client secrets may not match the tenant. Apply the planned Moodle upgrade to the copy and check the plugin versions against the supported range listed in the plugin directory. Then run a pilot with a small set of courses and a limited group of users before wide rollout. Keep all test records, screenshots, logs and sign-off as part of change control, so that each later plugin update or tenant change can be checked against a documented baseline.
Questions buyers ask about the Moodle and Microsoft 365 integration
What drives the cost and effort of a Moodle and Microsoft 365 integration?
The main drivers are your Microsoft Entra ID tenant policy, how many integration features you enable, the user matching rules, the testing scope and your upgrade cadence. Tenant policy decides how much consent, app registration and conditional access work is needed before sign-in can be tested. Feature count matters because single sign-on, user matching, Microsoft 365 Group creation, group files in the file picker, Teams theming and OneNote assignments each add configuration and testing. Matching rules and testing scope determine how many account edge cases must be checked. Upgrade cadence affects recurring effort, because the plugins follow Moodle's version support. In-house skills also change the effort, since a team already fluent in both platforms will need less outside help. Ask any partner for a quote that lists each of these drivers separately.
Can our own team build the Moodle and Microsoft 365 integration without a partner?
Yes, a team with Moodle administration skills and Microsoft Entra ID administration skills can install and configure the plugins in-house. The plugins are Microsoft's open-source set, including auth_oidc for single sign-on through OpenID Connect and local_o365 for user matching and Group creation. The harder part is governance, not configuration. Decisions about how Moodle accounts match to Entra ID users, and who owns the Microsoft 365 Groups created from courses, affect privacy, access and course lifecycle. Those decisions need named owners from IT, academic administration and compliance before build starts. If your team lacks one of the two platform skill sets, or cannot staff those decision owners, a partner can cover the gap within a written scope.
How long does a Moodle and Microsoft 365 integration take?
The duration depends on the decisions made before build and on how quickly the Microsoft tenant and Moodle environment can be accessed. Matching rules, Group ownership and the feature list set the amount of configuration and test work, and unresolved decisions are the most common cause of delay. Tenant access is the second factor, because app registration and consent often require approvals outside the project team. DeployOpen does not quote a fixed duration for this integration. Instead, the timeline is scoped in writing after a discovery review of your tenant policy, feature list and testing needs, and it is agreed before work starts. Ask for the timeline to be tied to named milestones and client dependencies.
What do we need to provide before the Moodle and Microsoft 365 work starts?
You need four things in place before build. First, tenant access sufficient to register the application, grant consent and configure Microsoft 365 Group settings, or a named administrator who can do this during the project. Second, Moodle access with site administrator rights on a non-production copy and, where production changes are needed, a change window. Third, decision owners from IT, academic administration and privacy who can sign off matching rules and Group ownership. Fourth, test accounts covering students, teachers, managers and at least one account type that does not match cleanly. A non-production copy of your Moodle site, running the same version as production, is needed so that upgrades and plugin changes are tested before they reach learners.
What recurring work follows go-live for this integration?
Three recurring tasks follow go-live. The first is plugin updates tied to Moodle upgrades, because the plugins list support for specific Moodle versions and follow core version support, so each Moodle upgrade needs a compatibility check before the update is applied. The second is secret rotation for the client secret or certificate used by the Entra ID application registration, which must be rotated on a schedule your identity team sets. The third is access reviews of the accounts, Groups and administrator roles involved in sign-in and Group creation, so that leavers and changed roles do not keep access. Ask any partner to state which of these it performs under a retainer and which stay with your team.
Does the Moodle and Microsoft 365 integration stay inside our own infrastructure?
Partly, and the split is worth stating clearly to your privacy and security reviewers. The Moodle site itself stays on servers you control, whether that is your data center or your cloud accounts. Your Microsoft 365 data, including Microsoft 365 Group content and group files, stays in your Microsoft tenant, because that is where Microsoft hosts it under your existing agreement. The integration connects the two systems, so authentication and file access traffic flows between them. Your architecture review should document which data is stored in Moodle, which stays in Microsoft 365, and what is exchanged between them. Confirm data residency and processing terms for your Microsoft tenant with Microsoft and your legal team, since those terms are not set by the integration plugins.
Which Moodle versions does the Microsoft 365 integration support?
The plugin listings for local_o365 and auth_oidc show support for Moodle 3.9 through 5.2, and they state that supported versions follow core Moodle version support. This means the plugin set can lag a new Moodle release, so check the current compatibility listing before choosing a Moodle version or scheduling an upgrade. Moodle 5.1 requires 64-bit PHP 8.2 or later and a supported database, and Moodle 5.3 raises the PHP and database minimums and requires an existing site on Moodle 4.4 or later. Confirm each plugin version against your target Moodle release in a non-production copy before committing to an upgrade date.
How DeployOpen scopes and delivers the Moodle and Microsoft 365 integration
DeployOpen plans, builds and documents the Moodle and Microsoft 365 integration in infrastructure you control, starting from a written scope that names the Microsoft plugins, tenant settings and courses involved. The work is fixed-scope, with deliverables and timelines agreed before any build starts, and ongoing support is available as a retainer.
How we scope
- Confirm which Moodle version and release line you run, and which Microsoft 365 tenant and Entra ID settings the integration will use.
- Agree in writing which plugins are in scope, such as auth_oidc, local_o365, repository_office365 and theme_boost_o365teams, and which are excluded.
- Record how users will be matched between Entra ID and Moodle, and which course groups will be created as Microsoft 365 Groups.
How we build
- Install and configure the Microsoft plugin set on a staging copy of your Moodle site, with the Entra ID app registration and redirect settings documented.
- Test single sign-on, user matching and group creation with sample accounts before any production user is affected.
- Verify group file access in the file picker and Teams theming against the permissions your tenant policies allow.
How we hand over
- Deliver a configuration record covering tenant IDs, app registration settings, plugin versions and field mappings, with secrets kept out of documents.
- Provide a runbook for user matching problems, failed sign-ins, group sync errors and rotating the client secret or certificate.
- Walk your administrators through the test results and the upgrade checks needed when Moodle or the plugins change version.
How we support
- Re-test the integration after each Moodle upgrade, since plugin support follows core Moodle version support and must be confirmed per release.
- Review Entra ID and Microsoft 365 changes that could affect sign-in, group creation or file access, and plan the fix in writing.
- Offer ongoing support, upgrades and testing under a retainer if you prefer a partner to keep the integration current.
