Microsoft Whiteboard: Setup, Policies, and Admin Configuration Guide 2026
Why Microsoft Whiteboard Setup Goes Wrong
Picture this: you've just rolled out a new collaboration initiative across your company. You've told everyone about Microsoft Whiteboard , the infinite canvas built right into Microsoft 365, the one that works in Teams meetings, on Surface Hub, on Windows PCs and iOS. Your users are excited. And then they try to open it and get... nothing. A blank screen. A sign-in loop. A cryptic message saying the app isn't available for their account.
I've seen this exact scenario on dozens of tenant deployments. The frustration is real, especially when the product itself is free with most Microsoft 365 subscriptions and should, in theory, just work. The problem isn't the app. It's the way Microsoft 365 admin controls interact with Whiteboard's dependency on cloud infrastructure, OneDrive for Business, and Microsoft Entra ID.
Here's the core issue: Microsoft Whiteboard for collaborative sessions requires a cloud-based Microsoft Entra ID environment. It's not optional. If your organization is running hybrid configurations, has Conditional Access policies that block certain app registrations, or has Whiteboard itself disabled at the tenant level (which is easy to do accidentally during a broader security review), users will hit walls with no clear error message explaining why.
There are also networking requirements that catch admins off guard. The app needs specific domains , Whiteboard.ms, *.whiteboard.microsoft.com, and wbd.ms, on your allowed list, plus port 443 open for HTTPS. If your proxy or firewall is doing SSL inspection and those domains aren't explicitly allowed, the collaborative features silently fail. Users can still open the app locally, but they can't invite anyone, and nothing syncs to the cloud.
Government tenants, GCC and GCC High, have their own separate setup paths with different admin portals and different data residency requirements. Applying the standard commercial docs to a government tenant is one of the most common mistakes I see, and it always causes avoidable downtime.
Then there's deployment itself. Whiteboard isn't always pre-installed on managed Windows 10/11 devices. If you're using Microsoft Intune or Configuration Manager to control what gets pushed to endpoints, and Whiteboard isn't in your assigned app list, users simply won't have it, and the error they get rarely points to that as the cause.
The good news? Every one of these problems has a documented fix. This guide walks through all of them, step by step, so you're not guessing. Browse all Microsoft fix guides →
The Quick Fix, Try This First
If users in your organization can't access Microsoft Whiteboard at all, they see a "This app isn't available" message or get kicked back to the sign-in page repeatedly, the first thing to check is whether Whiteboard is actually enabled at the tenant level. This single toggle resolves the majority of Whiteboard access complaints I see in enterprise environments.
Here's what you do. Sign in to the Microsoft 365 admin center at admin.microsoft.com using a global admin or Teams service admin account. In the left-hand navigation, go to Settings > Org settings. Scroll through the Services list until you find Microsoft Whiteboard, it won't be the first entry, so you may need to scroll or use Ctrl+F in your browser. Click it. You'll see a panel slide out on the right with the primary toggle: Turn on Microsoft Whiteboard for your organization. If that toggle is off, that's your culprit.
Flip it on, save the change, and give it 15–30 minutes to propagate across the tenant. Microsoft 365 service configuration changes don't always take effect instantly, especially for large tenants. Ask your test user to sign out of all Microsoft 365 apps, including Teams, clear the Teams desktop client cache, and sign back in. Then try launching Whiteboard again from teams.microsoft.com in a browser, or directly from whiteboard.office.com.
If Whiteboard was already enabled and the problem persists, check the networking side next. Pull up your proxy or firewall's block log and search for requests to wbd.ms or whiteboard.microsoft.com. Even a single blocked request to these endpoints will break the collaboration handshake without showing the user anything meaningful.
Add these three entries to your allow list right now if they're not already there:
Whiteboard.ms*.whiteboard.microsoft.comwbd.ms
Make sure port 443 (HTTPS) is open for all three. That's the only port Whiteboard uses.
Before any Microsoft Whiteboard setup step, you need to confirm the service is enabled for your tenant, and optionally scope it to specific user groups if you're doing a phased rollout. This is the foundational step that every other configuration depends on.
Sign in to admin.microsoft.com as a Global Administrator or Teams Service Administrator. Navigate to Settings > Org settings > Services. Select Microsoft Whiteboard from the list.
The settings panel shows three key controls:
- Turn on Microsoft Whiteboard for your organization, the master switch. This must be on.
- Enable sharing of whiteboards for your organization, controls whether users can send invite links. Leave this on unless you have a specific data governance reason to disable it.
- Enable Diagnostic Data, optional telemetry toggle, unrelated to core functionality.
Once you enable Whiteboard, verify that your users have eligible Microsoft 365 licenses. Whiteboard collaboration requires a commercial Microsoft 365 environment backed by cloud-based Microsoft Entra ID. On-premises Active Directory alone is not sufficient, users must be synced to Entra ID (formerly Azure AD) and have valid cloud identities.
One thing that trips people up: Microsoft 365 Germany and Microsoft 365 operated by 21Vianet (the China-hosted version) do not support Whiteboard collaboration at all. If your tenant is in one of those environments, collaborative whiteboards simply won't work regardless of settings. You'll need to document this as a known limitation for your users.
After enabling, you should see Whiteboard appear at whiteboard.office.com for licensed users within about 30 minutes. If it still doesn't appear after an hour, check whether a Conditional Access policy is blocking the Whiteboard app registration in Entra ID.
This step is non-negotiable for any organization with a managed network, proxy server, or firewall with application-level inspection. Microsoft Whiteboard's real-time collaboration engine communicates over HTTPS exclusively, but it uses its own set of endpoints that aren't always included in generic "Microsoft 365" allowlists.
Add the following entries to your web proxy, firewall, or URL filtering solution as explicitly allowed:
Whiteboard.ms
*.whiteboard.microsoft.com
wbd.msPort requirement: HTTPS: 443. This should already be open on most networks since it's standard HTTPS, but some zero-trust configurations apply application-level controls that block specific domains even on 443. Check those policies first.
If you're running Zscaler, Palo Alto Prisma Access, or a similar cloud proxy, search for existing Microsoft 365 URL categories in your policy. Whiteboard endpoints may or may not be included depending on your vendor's category definitions and how recently they've been updated. The safest approach is to create a dedicated bypass rule for the three domains above rather than relying on a category.
For Surface Hub deployments specifically, and this catches a lot of admins, port 443 should be configured during the initial Surface Hub setup. If you're seeing Whiteboard work on PC but not on Surface Hub, a port or proxy mismatch on the Hub's network profile is almost always the reason. Check the Surface Hub admin settings under Settings > Surface Hub > Network & internet to verify proxy configuration matches your corporate proxy settings.
Once your allowlist is updated, test connectivity by navigating to https://wbd.ms from an affected device. You should get a redirect or a Whiteboard login page, not an error or blocked page. If the proxy still blocks it, look for SSL inspection policies that might be intercepting the certificate, Whiteboard's certificate chain needs to be trusted end-to-end.
On managed Windows 10 and Windows 11 devices, Whiteboard isn't guaranteed to be pre-installed, especially on corporate images that strip out default apps for security or compliance reasons. If your users are saying "I can't find the Whiteboard app," this is likely why. The fix is to push it through Microsoft Intune.
Sign into the Microsoft Intune admin center at intune.microsoft.com. Navigate to Apps > All apps, then click Add. In the app type selector, choose Microsoft Store app (new). Search for "Microsoft Whiteboard" in the store search box. Select it from the results and click through the setup wizard.
Key deployment settings to configure:
- Assignment type: Set to Required for groups where Whiteboard should be mandatory, or Available if you want users to self-install from Company Portal.
- Target groups: Assign to the Azure AD (Entra ID) user or device groups that need access. For a pilot rollout, create a dedicated group like "Whiteboard-Pilot-Users" and add test accounts first.
- Install behavior: Choose User context for user-based licensing or System context for device-wide deployment.
Important: Whiteboard is not supported on Windows Server. Don't assign the app to groups that include Windows Server machines, Intune may report an error on those devices, which can clutter your deployment compliance reports.
After the assignment is saved, affected devices will receive the app on their next Intune check-in cycle, which is typically within 8 hours. You can trigger an immediate check-in by going to the device in Intune admin center and selecting Sync. Or, on the device itself, open Settings > Accounts > Access work or school, select your org account, and click Info > Sync.
Confirm successful deployment by checking the app's Device install status in Intune. Green checkmarks mean the app installed correctly. Red errors typically mean either the device is running Windows Server, or the device doesn't have a valid Store connection, which in enterprise environments often requires the Microsoft Store for Business to be configured.
Getting the app installed is only half the battle for Microsoft Whiteboard setup in an enterprise. The sharing and collaboration model has its own set of controls, and getting them wrong means users can technically open Whiteboard but can't invite anyone or see shared boards from colleagues.
Back in the Microsoft 365 admin center under Settings > Org settings > Microsoft Whiteboard, confirm that sharing is enabled. But here's what most guides skip: collaboration between users in the same Teams meeting is handled differently from general sharing via link. When a user shares a Whiteboard link in a Teams meeting, the system generates a meeting-scoped share. This requires that the user's OneDrive for Business is provisioned and active.
If a user has never signed into OneDrive or their OneDrive provisioning failed during account creation, Whiteboard data for that user can't be stored properly. Boards get saved to OneDrive for Business as .whiteboard files. To check if a user's OneDrive is provisioned, go to the SharePoint admin center > Active sites and search for their name, each user's OneDrive appears as a personal site collection.
For collaboration to work across devices and users in a real-time session, all participants must belong to the same Microsoft 365 tenant. Cross-tenant guest collaboration for Whiteboard has specific limitations, external guests joining a Teams meeting can view a shared Whiteboard but may have limited editing rights depending on your organization's external sharing policies in SharePoint/OneDrive admin.
If you want to restrict who can share Whiteboards externally, you control this through your OneDrive and SharePoint external sharing settings rather than through the Whiteboard panel itself. Set external sharing to Existing guests only or Only people in your organization in the SharePoint admin center to tighten this down. Whiteboard inherits these policies because it stores content in OneDrive for Business.
Surface Hub has the Whiteboard app built in, but there are setup steps specific to Hub that a lot of IT teams miss, and then wonder why the Hub board doesn't show up in the gallery on users' PCs, or why collaboration sessions won't connect.
First, confirm all three Whiteboard domains are in your allowed sites list and port 443 is open, as covered in Step 2. On Surface Hub, this isn't just about the corporate firewall, it's also about the Hub device's own network profile. Open Hub settings as an admin, go to Settings > Network & internet, and verify the proxy settings match your corporate proxy exactly.
For a collaborative session to work from Surface Hub:
- Open the Whiteboard app on the Hub and tap Sign in.
- Sign in with your organization ID, a licensed Microsoft 365 account in your tenant.
- Once signed in, tap the Invite button next to your name at the top of the app.
- Type the names or email addresses of the people you want to collaborate with.
After being invited, remote participants on other devices will see the shared board appear in their Whiteboard board gallery. If they don't see it within a couple of minutes, the most common cause is that they're signed in with a different tenant account, or the collaboration session failed to establish because one of the Whiteboard endpoints was blocked.
One thing I always tell IT teams setting up Surface Hub: have a fallback ready. If users can't sign in to Whiteboard on the Hub for any reason, they can still collaborate by joining a Teams or Skype for Business meeting and sharing their screen. After the session, they can go to Settings > Export to email to save a copy, or export to SVG for a higher-resolution vector version that can be opened directly in any web browser. The SVG export is significantly better quality than PNG for any board with fine ink strokes or text.
For automatic saving: once signed in, boards save to the cloud automatically. There's no local folder, no file path to remember. The board gallery is the starting point every time. If a user can't find a previous board, have them check they're signed in with the same account, boards are tied to the account, not the device.
Advanced Troubleshooting for Microsoft Whiteboard Setup
If the basics above haven't resolved your Microsoft Whiteboard setup issues, you're likely dealing with a more complex environment, government cloud, heavily locked-down enterprise, domain-joined legacy devices, or policy conflicts. Here's how to work through those scenarios.
Government Cloud: GCC and GCC High
If your organization is in a US Government GCC or GCC High tenant, the admin paths and data storage configurations for Whiteboard are different from commercial. GCC environments use a separate portal at gcc.teams.microsoft.com for Teams-based collaboration, and Whiteboard data residency follows the GCC data boundary rules for Azure and OneDrive for Business. Make sure you're following the GCC-specific Whiteboard admin documentation, not the commercial docs, the settings panels look the same but behave differently and have different compliance certifications behind them.
GCC High has additional restrictions: not all Whiteboard clients are supported. Before deploying to GCC High users, check the official client support matrix for that environment to confirm which platforms are fully supported versus limited.
PowerShell Management
Microsoft Whiteboard exposes PowerShell cmdlets for bulk management, particularly useful if you need to audit Whiteboard content ownership, transfer boards when an employee leaves, or manage data subject requests under GDPR. To use Whiteboard PowerShell:
# Install the module if not already present
Install-Module -Name WhiteboardAdmin -Force
# Check Whiteboard ownership for a user
Get-Whiteboard -UserId "user@yourdomain.com"
# Transfer all whiteboards from a departing user
Invoke-TransferAllWhiteboards -OldOwnerId "leaver@yourdomain.com" -NewOwnerId "manager@yourdomain.com"These cmdlets are particularly important for GDPR data subject requests. If a user requests deletion of their personal data, you need to identify all Whiteboard content they own and process it accordingly.
Entra ID Conditional Access Conflicts
If users can sign into other Microsoft 365 apps but Whiteboard specifically fails, check your Conditional Access policies in the Entra admin center. Look for any policy that targets "All cloud apps" with a device compliance requirement or location restriction. Whiteboard's app registration may not match the compliance state expected by those policies, especially on BYOD devices that aren't Intune-enrolled. Add a specific exclusion for the Whiteboard app ID in the CA policy, or ensure the policy scope only applies to enrolled devices.
Event Viewer and Diagnostic Logs
On Windows 11 PC, Whiteboard app errors log to the Windows Event Log under Applications and Services Logs > Microsoft > Whiteboard. Open Event Viewer, navigate to that path, and look for Error or Warning events. Authentication failures show up as Event ID 1000 with "sign-in failed" in the description. Network connectivity failures show differently, look for events referencing wbd.ms or whiteboard.microsoft.com with timeout or connection refused messages. These give you a precise trail to follow rather than guessing.
Prevention & Best Practices for Microsoft Whiteboard Deployments
Fixing Whiteboard after it breaks is frustrating and time-consuming. Here's how to avoid getting into that position in the first place, based on what I've seen go wrong repeatedly in enterprise environments.
Document your Whiteboard configuration decisions. It sounds obvious, but in most environments, the Whiteboard enable/disable toggle gets changed during a broad security review with no note about why. Three months later, nobody knows who turned it off or what policy prompted it. Keep a simple change log in your IT wiki that records who changed what and why.
Test your allowlist before deploying to all users. After adding the three required domains, test from a standard user account on a standard network device, not from the admin's machine that has direct internet access bypassing the proxy. The goal is to simulate exactly what your users will experience.
For Surface Hub deployments, put the Hub through a full collaboration test cycle during setup: sign in, create a board, invite a remote user on a PC, verify the board appears on both devices, make a change and verify it syncs, then export to both PNG and SVG. Do this before the Hub goes into a conference room. It's much easier to troubleshoot in your IT lab than with a room full of executives waiting to start their meeting.
Keep an eye on OneDrive provisioning for new user accounts. When a new employee is created, OneDrive provisioning can take up to 24 hours to complete. If that user tries to start a collaborative Whiteboard session before OneDrive is ready, they'll get a confusing error. Adding a note to your new-hire onboarding checklist that "Whiteboard may not be available for the first 24 hours" prevents a lot of unnecessary support tickets.
- Add the three Whiteboard domains to your proxy allowlist as part of your standard Microsoft 365 URL list, not as a separate item that gets forgotten during policy reviews
- Create a dedicated Entra ID security group called "Whiteboard-Users" so you can scope Intune app deployment and quickly add or remove users during access reviews
- Run a monthly check in the Intune admin center on Whiteboard app deployment status, devices that fail silently won't generate tickets but will leave users without the app
- For GCC/GCC High tenants, bookmark the government-specific documentation pages separately from your commercial docs reference, the setup steps look similar but have critical differences
Frequently Asked Questions
Why can't my users find Microsoft Whiteboard in Teams meetings even though it's installed on their PCs?
This almost always comes down to Whiteboard not being enabled at the tenant level, or the specific Teams meeting policy not including the Whiteboard integration. Go to admin.microsoft.com > Settings > Org settings > Microsoft Whiteboard and make sure the toggle is on. Also check your Teams meeting policies in the Teams admin center, under Meeting policies, look for the "Whiteboard" setting and confirm it's set to Enabled. After any policy change, give it up to 30 minutes to propagate and have users sign out and back into Teams.
Where are Whiteboard files actually saved? I need to back them up or audit them.
Whiteboard boards are stored as .whiteboard files in each user's OneDrive for Business, not in a shared library or SharePoint site. You'll find them in the user's OneDrive under a dedicated Whiteboard folder. Because they're OneDrive files, they're covered by your existing OneDrive backup, retention, and eDiscovery policies. You can use the Whiteboard PowerShell cmdlets to enumerate boards across users, which is useful for GDPR data subject access requests or audits.
Microsoft Whiteboard works on my PC but won't load on the Surface Hub, what's different?
Surface Hub has its own network profile separate from your regular corporate network. The most common cause is that the Hub's proxy settings don't match your corporate proxy, so the Whiteboard collaboration endpoints are being blocked at the Hub level even though they work fine on a laptop. Open Hub admin settings and go to Settings > Network & internet to verify proxy configuration. Also confirm that port 443 is open specifically from the Hub's network segment. If the Hub is on a VLAN that has different firewall rules from your main office network, those rules need to allow the same Whiteboard domains that you've allowed for PCs.
Can people outside our company collaborate on a Whiteboard with us?
It depends on your external sharing settings. Whiteboard collaboration is built for users within the same Microsoft 365 tenant, that's the primary supported scenario. External guests who are in a Teams meeting can view shared Whiteboards, but full real-time co-editing by external users depends on your OneDrive and SharePoint external sharing policies. If external sharing is set to Only people in your organization in the SharePoint admin center, external guests will be blocked from editing. You can't configure external Whiteboard access separately from those OneDrive/SharePoint policies, Whiteboard inherits them directly.
What happens to a user's Whiteboards when they leave the company and their account is deleted?
Because Whiteboards are stored in the user's OneDrive for Business, the same data lifecycle policies that apply to OneDrive apply here. If you delete the user account without first transferring their data, the boards will sit in the OneDrive retention period (configurable in your SharePoint admin center) before permanent deletion. The right move is to use the Invoke-TransferAllWhiteboards PowerShell cmdlet before offboarding to move all boards to a manager or admin account. Build this into your offboarding checklist alongside OneDrive file transfer.
Is Microsoft Whiteboard available for US Government GCC and GCC High environments?
Yes, but with environment-specific setup requirements. GCC and GCC High each have their own Whiteboard admin documentation with distinct configuration steps, data residency information, and supported client lists. Not all Whiteboard clients and features available in commercial are supported in government environments, particularly GCC High has the most restricted client support list. Always use the government-specific documentation rather than the commercial docs when configuring Whiteboard in a GCC or GCC High tenant. Microsoft 365 Germany and 21Vianet-operated Microsoft 365 do not support Whiteboard collaboration at all.