Make Your Test Data Less Boring with M365Mutator

Mix Up Test Data with M365Mutator to Make Scenarios More Believable

If you’ve ever tried to demo a Microsoft 365 backup solution, test a compliance workflow, or develop an application against Graph, you’ve hit the same wall: stale data. A backup demo isn’t impressive when nothing has changed since the last run. A search app looks broken when no new files have landed in SharePoint. And if you’re working against a Microsoft Customer Immersion Experience (CDX) tenant, you already know that the moment the tenant is provisioned, the data is essentially frozen.

The usual workarounds are tedious — logging in as multiple users to send email, manually uploading files, tweaking calendar entries by hand. That’s time you could be spending on the actual work. I got tired of doing this so I fired up Claude Code and built M365Mutator, a small open-source tool designed to solve exactly this problem.

What Is M365Mutator?

M365Mutator is a locally-hosted web app that connects to a tenant via Microsoft Graph and systematically generates realistic activity across multiple workloads. In a single session you can randomize user attributes in Entra ID, generate mailbox activity, create calendar events, and perform file operations in OneDrive and SharePoint — all without touching the tenant manually.

It’s aimed squarely at developers, architects, and IT pros who need a tenant that looks alive: varied data, recent changes, active mailboxes. You can run it as often or as seldom as you like to provide updated-looking data on demand.

Important caveat: M365Mutator requires high-privilege write permissions on Microsoft Graph. It is designed to run locally and should never be exposed to the internet.

Three of Five Workloads

The admin console is organized around five tabs, each targeting a different area of Microsoft 365. Two of them aren’t implemented yet, though.

The Identities tab (Figure 1) connects to Entra ID and randomizes attributes across a set of user accounts. You supply a list of UPNs and M365Mutator picks an attribute at random and updates it. The possible attributes to be changed are streetAddress, city, state, postalCode, country, businessPhone, mobilePhone, jobTitle, companyName, department, employeeId, employeeType, employeeHireDate, and officeLocation. This feature is useful for testing directory sync, HR integrations, or anything that reacts to profile changes.

The Mail tab (Figure 2) generates mailbox activity: sends, replies, forwards, and deletes (more properly, moves to Deleted Items). A run-count stepper lets you repeat a pass multiple times, so you can simulate days of activity in minutes rather than hours. For example, if you set the stepper to 25 and then choose 10 mailboxes, each of those 10 mailboxes will have a mutation action run on it 25 times.

Calendar creates meeting requests and appointments for target users. When the MailboxSettings.Read permission is granted, events land inside each user’s configured working hours; otherwise the tool falls back to a sensible Mon–Fri 08:00–17:00 default.

OneDrive and SharePoint round out the picture with file CRUD operations — creating, updating, and deleting documents across personal drives and SharePoint sites. I’ll be adding them in the next couple of weeks (so if you have suggestions on how you’d like to see them work, leave a comment here!)

Choosing Your Targets: Explicit vs. Random Mode

I wanted to give users some control over the scope of changes, so each workload offers two modes.

In Explicit mode, you can specify exactly which objects are in scope. You can type, paste, or upload a set of UPNs, or load the entire set of objects from the tenant with the Load button. The Check button validates the list and tells you if any are invalid. Once you’re happy with the list, click Save targets, which enables the Do it now button. This flow is a little annoying but it reduces the chances you’ll accidentally modify an unwanted object.

Random mode (Figure 3) samples a percentage of the tenant’s live at run time. You set a percentage (say, 25%), and M365Mutator reads all objects of the selected type from the tenant, then randomly selects targets for you to hit that percentage. This is useful for generating broad activity across a larger test tenant without having to curate a list.

Setting It Up

Setup involves three main steps: registering an app in Entra ID, granting it Graph permissions, and wiring the credentials into M365Mutator’s environment file.

The Fast Path: PowerShell

If you have the Microsoft Graph PowerShell SDK installed, the included Create-MutatorAppReg.ps1 script handles the registration automatically. It signs you in interactively, creates the app, attaches the right permissions, generates a credential, and optionally grants admin consent — printing the values you need at the end.

# All workloads, grant consent manually afterward
./helpers/Create-MutatorAppReg.ps1

# Specific workloads, grant consent automatically (requires admin)
./helpers/Create-MutatorAppReg.ps1 -Workloads Identities,Mail -GrantConsent

# Use a certificate instead of a client secret
./helpers/Create-MutatorAppReg.ps1 -UseCertificate

The -UseCertificate flag is worth noting: CDX tenants and tenants with the baseline Entra security policy applied will block you from creating client secrets. In that case, the script generates a self-signed certificate, uploads the public key, and writes a PEM file for the tool to use. PowerShell 7+ is required for the certificate path.

Manual Registration

If you prefer the portal route, the process is straightforward:

1. Go to Entra admin center → Identity → Applications → App registrations → New registration and create a single-tenant app called M365Mutator (no redirect URI needed — this is app-only auth).
2. Under API permissions, add Application permissions for the workloads you plan to use:

Workload	Required Permissions
Identities	User.ReadWrite.All
Mail	Mail.ReadWrite, Mail.Send
Calendar	Calendars.ReadWrite, MailboxSettings.Read*
OneDrive	Files.ReadWrite.All
SharePoint	Sites.ReadWrite.All

*MailboxSettings.Read is optional but improves event scheduling.

3. Grant admin consent — without it, every Graph call will return Authorization_RequestDenied.
4. Add a credential: a client secret (simplest, but blocked in some tenants) or a certificate. Copy the values immediately — client secret values are only shown once.

Configuring the App

Copy .env.example to .env and fill in the three required values:

GRAPH_CLIENT_ID=<Application (client) ID>
GRAPH_TENANT_ID=<Directory (tenant) ID>
GRAPH_CLIENT_SECRET=<client secret value>

For certificate auth, use GRAPH_CERTIFICATE_PATH pointing to your PEM file instead of GRAPH_CLIENT_SECRET.

After all that’s done, you can build and run the app. Today M365Mutator is built as a web app that you have to run locally. You’ll need to install node.js, after which you can install dependencies and start the server:

npm install
npm run dev

The admin UI will then be available at http://localhost:3700/admin.

Putting AI to Work

If you click the gear icon in the nav bar, you’ll see a spot for you to plug in an OpenRouter API key. If you do, M365Mutator uses the key to generate realistic email subjects and body text. Without a key, it falls back to using GUIDs, an ugly, but functional, approach. The OpenRouter integration makes the generated content look like actual tenant activity, which matters when you’re demoing to a discerning audience.

Who Should Use This?

M365Mutator is a good fit if you’re:

• A Microsoft 365 developer who needs a realistic dataset to test Graph integrations without polluting a production tenant.
• An ISV or solution partner who demos backup, compliance, or governance tools and needs tenant activity to look fresh between runs.
• An IT pro or consultant using CDX tenants for training or demos and tired of manually seeding data by hand.
• A Microsoft MVP or technical writer who needs realistic screenshots and environments for articles and books. (ahem)

A Few Things to Keep in Mind

Because M365Mutator authenticates as an application — not as a user — it uses client credentials flow with tenant-wide permissions. User.ReadWrite.All means it can change any user in the tenant. These are powerful permissions, and the tool is explicit about this. Use it only against tenants you own or have explicit permission to modify, and never against a production environment.

The client secret or certificate you generate is effectively a root credential for those Graph scopes. Protect it accordingly — don’t commit it to source control, and rotate it on a regular schedule.

Getting Started

M365Mutator is available on GitHub at https://github.com/probichaux/m365mutator. The README has full setup instructions and covers the PowerShell helper script, manual registration steps, environment configuration, and the application structure in detail.

For most people, the fastest path is:

1. Clone the repo
2. Run Create-MutatorAppReg.ps1 -GrantConsent in a PowerShell session with admin rights
3. Paste the output values into .env
4. npm install && npm run dev

Within a few minutes you’ll have a test tenant generating the kind of realistic activity that makes development, testing, and demos feel much less contrived. Maybe M365Mutator might not achieve the same fame as other Microsoft 365 utilities like MFCMAPI or Maester, but it offers value to anyone who needs to test scenarios against Microsoft 365 data.

---

Have you used M365Mutator or a similar approach to keep test tenant data fresh? Let me know in the comments below.