merill/mc: A Public, Searchable Archive of Microsoft 365 Message Center Posts

What Problem This Archive Solves

The Microsoft 365 Message Center lives behind the admin center login. If you write a newsletter or run a community site, linking to a specific post forces your readers to authenticate first, which is friction. merill/mc removes that friction by publishing a public, searchable archive at mc.merill.net. The creator built it so his Entra.News newsletter could point to a post without the login wall. The target audience is anyone who needs to cite or share Message Center content widely: newsletter authors, IT communicators, and support teams that want a quick reference. The archive also includes the Microsoft 365 Roadmap, which is normally public but benefits from the same unified search. The project is not a replacement for the admin center; it is a convenience layer for reading and linking.

How the Archive Is Built and Refreshed

The data flow is straightforward but has a few deliberate choices. The README states that Message Center data is refreshed hourly and the site is rebuilt every four hours. The refresh runs as a GitHub Actions workflow, pulling posts from every tenant listed in @build/config-m365.json. Each tenant contributes posts that other tenants cannot see, because Message Center posts are tenant-specific. When the same message ID appears from multiple tenants, the merge logic picks the copy with the newest LastModifiedDateTime. If there is a tie, the copy with the most body content wins. That tie-breaker is a practical way to get the most complete text, though it is not a guarantee of accuracy. The rebuild step then generates a static site, which explains why the archive is fast and cheap to host.

Getting It Running: Commands and Configuration

You can run the project locally or use the hosted site. The README gives one direct command for the agent skill: npx skills add merill/mc. That installs a skills.sh-compatible skill that teaches an agent to use https://mc.merill.net/llms.txt, search https://mc.merill.net/messages-index.json, and cite canonical message pages. For the data refresh itself, the key script is Update-Site.ps1, which accepts a parameter called -NewPostMaxAgeDays. The default behavior is that only posts published within the last 14 days are announced, which prevents a new source tenant from flooding the Discord channel with old posts. To test the tenant configuration and merge logic locally, run npm run test:tenants. That command needs no network access or credentials, so it is a safe first step.

Multi-Tenant Collection and Federated Identity

The archive pulls from multiple source tenants, and the configuration file @build/config-m365.json defines each one. Each tenant entry has a name, tenantId, clientId, and an auth type. The auth type can be clientSecret (the default) or federatedIdentity. For clientSecret tenants, you set secretEnv to point to an environment variable holding the secret. For federated identity, there is no secret to store or rotate. The README walks through adding a federated tenant: create an app registration, grant ServiceMessage.Read.All, then add a GitHub Actions federated credential with the correct issuer and audience. The repository variables GRAPH_FEDERATED_TENANT_ID and GRAPH_FEDERATED_CLIENT_ID hold the tenant and app IDs. If those variables are unset, the refresh runs on the primary tenant only. This design keeps secrets out of the repo and allows the workflow to authenticate via OIDC.

Discord Notifications for Entra Posts

The project includes a Discord notification workflow that watches for new Message Center posts. It triggers when either the service/product label or the title contains the standalone word Entra, case-insensitively. That is a narrow filter, which is intentional: the creator runs Entra.News, so he only cares about Entra-related announcements. The workflow publishes one rich Discord embed per new post and links to the canonical mc.merill.net page. To set it up, you create an incoming webhook named Entra Scout in Discord, save its URL as the Actions secret DISCORD_ENTRA_SCOUT_WEBHOOK_URL, and optionally set DISCORD_ENTRA_SCOUT_AVATAR_URL for a custom avatar. The same webhook URL and secret name are used in the EntraDiff repository, so both publishers share one Discord identity. That is a clever way to avoid multiple bot accounts.

State Persistence and Retry Behavior

The workflow persists delivery IDs and pending retries in @data/discord-state.json. That file prevents duplicate posts when a workflow reruns, because the system tracks which Message Center IDs have already been announced. If a delivery fails, the pending retry is stored, so a later run can attempt it again. You can disable delivery entirely by setting DISCORD_ENABLED=false, or run in dry-run mode with DISCORD_DRY_RUN=true to queue without sending. The legacy variable DISCORD_ENTRA_MC_WEBHOOK_URL remains as a temporary compatibility fallback for local runs. This is a practical approach for a small project: it avoids the complexity of a database and uses a simple JSON file. The trade-off is that concurrent workflow runs could race on that file, but for an hourly schedule that risk is low.

Limitations and Wrong Use Cases

The biggest limitation is accuracy. The README includes a caution that the archive is built from a small number of source tenants, for example a Microsoft 365 E5 tenant. Not all posts are visible to all tenants, so your tenant may have different features and updates. If you use this archive to make decisions about your own tenant, you may miss posts that are specific to your licensing or region. The project is also not a complete historical record: the refresh only pulls recent posts, and the 14-day announcement window means older posts are not announced even if a new tenant makes them visible. Another limitation is the single-author maintenance model. There are no recent releases listed, and the last push date is unknown, so you cannot assume active development. For a production dependency, that is a risk.

Alternatives and How They Differ

The obvious alternative is the official Microsoft 365 admin center Message Center. That gives you tenant-accurate data, but it requires authentication and does not offer a public API for anonymous access. Another alternative is Microsoft's own Microsoft 365 Roadmap website, which is public but does not include Message Center posts. There are also third-party services that aggregate Message Center data, but they often require a subscription or an API key. The key difference with merill/mc is that it is open source and self-hostable, so you can run your own archive with your own source tenants. That gives you control over the data source and the notification logic. The trade-off is that you must maintain the tenant credentials and the workflow yourself.

Licence and Maintenance Cost

The project is licensed under MIT, which means you can fork, modify, and redistribute it freely, even for commercial use. There is no copyleft requirement, so you can integrate it into a proprietary system without releasing your changes. The maintenance cost is moderate: you need to keep the GitHub Actions workflow updated, monitor the tenant credentials, and watch for changes in the Microsoft Graph API. The federated identity approach reduces secret rotation overhead, but you still need to manage the app registration and permissions. The agent skill and Discord integration are optional, so you can start with just the archive and add features later. Given the single-author nature and the lack of recent release tags, you should plan to maintain your own fork if you depend on it.

Editorial conclusion

Adopt merill/mc if you run a newsletter, a community site, or an internal dashboard that needs to link to Message Center posts without forcing readers into the admin center. Do not adopt it if you need tenant-accurate, complete Message Center data for your own organization, because the archive is built from a small number of source tenants and may miss posts. Before relying on it, verify the freshness of the data by checking the rebuild schedule and the source tenant list in @build/config-m365.json, and confirm that the posts you care about are actually visible in your tenant. The project is MIT-licensed and maintained by a single author, so plan for your own fork if you need long-term guarantees.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository