Solutions · IT administrators
One console for the work
you do every day.
Office Unbound is being designed around ordinary administration — new starters, leavers, policies, full mailboxes, sync problems, updates and restores — handled from one place, for every service, with an audit trail and an API behind it.
Project status Administration tooling is planned for the core-services phase and extended in the MSP and enterprise phase. None of it is available yet.
The problem with five consoles
An administrator looking after a self-hosted stack built from separate open-source projects typically has a console for mail, another for files, another for chat, an identity provider with its own interface, and a set of scripts holding it together. Each has its own role model, its own logs and its own idea of what a user is. Offboarding one person means visiting all of them, and the audit question “who changed this?” has five partial answers.
Office Unbound uses established open-source projects for the services themselves, but the administration layer is its own work. The intention is that a user, a group, a policy and an audit record mean the same thing across mail, documents, files, chat and meetings, and that the administrator works in one place. The underlying component consoles remain there for deep troubleshooting; they should not be needed for routine work.
A week in the life
Typical tasks from an administrator’s week, and how the administration layer is intended to handle each. Every row describes planned behavior: Planned
| When | Task | How it is intended to work |
|---|---|---|
| Monday | Two new starters in sales | Create each account once; group membership assigns the sales shared mailbox, team folders and chat channels. The user receives an enrollment link to set a password and MFA. |
| Monday | A manager wants access to a shared calendar | Calendar delegation set from the user’s page in the console, recorded in the audit log. |
| Tuesday | “My mailbox is full” | Mailbox size and quota visible on the user page; raise the quota or apply an archive policy. |
| Tuesday | A message never arrived | Trace the message through the mail logs and quarantine from the console; release it if it was held as spam. |
| Wednesday | Someone deleted a project folder | Restore from the file service’s deleted-items retention, or from a backup if the retention period has passed. |
| Wednesday | A laptop shows sync conflicts | See the desktop client’s reported state for that device and which files conflicted. |
| Thursday | Security update released for a component | Read the advisory, apply it to staging, then schedule production in the next maintenance window — or use the emergency path if it is critical. |
| Thursday | Require MFA for a contractor group | Apply an authentication policy to the group; it takes effect at the next sign-in for every service. |
| Friday | A leaver at the end of the day | One offboarding action: block sign-in, end sessions, convert or delegate the mailbox, transfer file ownership, remove from groups. |
| Friday | Weekly check | Service health, backup results, storage growth, failed sign-ins and pending updates on one overview page. |
User lifecycle
Joiners, movers and leavers are where most administrative mistakes happen.
Each service in a typical stack handles accounts differently: mail creates a mailbox, files create a home folder, chat creates a profile, and none of them knows about the others. The planned approach is that the identity layer is the source of truth and every service follows it. Users can be created in the console, synchronized from an existing LDAP directory, or created through the management API from an HR or ticketing system.
Joiners
Account, groups, service assignment and enrollment in one step, driven by templates for each role or department.
Movers
Changing group membership moves access: new shared mailboxes and folders granted, old ones removed.
Leavers
Sign-in blocked and sessions revoked everywhere at once; mailbox and files retained, delegated or transferred according to policy.
Policies, monitoring and troubleshooting
- Central policies
- Authentication requirements, session lifetimes, external sharing, mailbox and storage quotas, retention — set once per organization or group and applied across services, with the effective policy for any user visible in one place. Planned
- Monitoring
- Health of each service and the infrastructure under it, queue depths, storage growth and certificate expiry, with alerts that can be sent to an existing monitoring system. Planned
- Troubleshooting
- Message tracing, sign-in history, sync status per device and per-user service state, without logging in to each component separately. Planned
- Audit logs
- Every administrative change, by whom, when and to what, searchable and exportable. Planned
Which signals each underlying component exposes, and how well, is part of the evaluation work. The console can only surface what the services report.
Updates on your schedule
A cloud platform changes when the vendor ships. Office Unbound is intended to put that decision with the administrator, through a defined process:
Notification
Release notes and security advisories for the platform and its components.
Staging
Apply to a staging environment and test the things your users depend on.
Approval and window
Approve the update and schedule it in a maintenance window.
Rollback plan
Know before you start how you would go back, including database and data changes that cannot simply be undone.
Control cuts both ways: delaying a critical security patch leaves known vulnerabilities open. An emergency patch path is planned for exactly that case.
Backups you have tested
Mail stores, file storage, databases, identity configuration and collaboration data each need backing up, and each restores differently. The administration layer is intended to show backup status for all of them together and to support the restores administrators actually perform: a single mailbox, a folder, a deleted user, a whole service.
On the initial Proxmox VE target, virtual-machine-level backups complement service-level ones; they are not a substitute, because restoring a whole VM to recover one mailbox is rarely what anyone wants.
Migration tooling and automation
For most administrators, the first project on Office Unbound will be getting data into it. The planned migration control center is meant to be run by the same administrators who will operate the platform afterwards: assess the source tenant, map users and destination accounts, run a pilot, transfer in stages, retry failed items, verify and report. Per-user and per-service status replace the spreadsheet most migrations are tracked in today.
Anything an administrator does in the console is intended to be possible through the management API too, so that repetitive work — bulk user changes, scheduled reports, onboarding triggered by an HR system — can be scripted and audited the same way as manual changes.
The migration process
The management API, for developers
A unified console over several open-source components will not expose every setting each component has; some advanced configuration will still be done in the component itself, and the documentation will say where. Administrators of a self-hosted platform also take on work a cloud vendor would otherwise do: operating-system patching, certificate management, capacity and incident response.
You would be the one running it?
Tell us what you administer today and which tasks take the most time. Administrator feedback decides what the console does first.