A setting changes on a laptop, and nobody on the helpdesk can say whether SCCM or Intune did it. Intune co-management lets Configuration Manager and Intune manage the same Windows PCs at the same time. Each job, called a workload, belongs to exactly one of them.
What co-management is
You decide which workloads move to Intune, and Configuration Manager keeps everything else. Turning it on changes nothing for users. There is no reboot, no new agent, and no notification. Configuration Manager stays in charge of every workload until you move one.
There are two ways in. Existing Configuration Manager clients get hybrid joined and enrolled into Intune. New devices join Entra ID, enroll in Intune, and then Intune installs the Configuration Manager client.
What you need
Entra ID P1 or P2 and Intune licenses, for the users and for the admin setting it up.
A supported Configuration Manager current branch version.
Devices that are Entra hybrid joined or Entra joined. Entra registered devices do not count.
Windows automatic enrollment, with users in the MDM user scope under Entra ID > Mobility (MDM and MAM) > Microsoft Intune.
A cloud management gateway, but only for devices that live on the internet or come in through Autopilot.
Full Administrator in Configuration Manager, plus a Global Administrator to sign in during setup.
Turn it on
In the Configuration Manager console, go to Administration > Overview > Cloud Services > Cloud Attach.
Click Configure Cloud Attach on the ribbon.
Sign in, then choose Use default settings or Customize settings.
Set Automatic enrollment in Intune to Pilot, All, or None. Pilot uses a collection you pick.
The Cloud Attach Configuration Wizard in Configuration Manager. Source: Microsoft Learn.
Older guides call this the Configure co-management wizard. Microsoft renamed it Cloud Attach in version 2111. The default settings enroll every eligible device, keep all workloads on Configuration Manager, and upload devices to Intune. Enrollment is spread out on purpose, so a big environment can take a few days.
The workloads
To move workloads, open the co-management object, CoMgmtSettingsProd, click Properties, and go to the Workloads tab. Each workload has a slider with three spots: Configuration Manager, Pilot Intune, and Intune. Pilot Intune only moves the devices in the pilot collection set on the Staging tab.
The Workloads tab, with one slider per workload. Source: Microsoft Learn.
Compliance policies: Intune decides compliance. Most companies move this one first.
Windows Update policies: Update rings come from Intune. Turn off software updates in the Configuration Manager client settings yourself afterward. Windows Autopatch needs this one on Intune.
Device configuration: Intune profiles apply. Moving this slider also moves Endpoint Protection and the old Resource access workload.
Endpoint Protection: Defender, firewall, and BitLocker policies come from Intune. You can move this one on its own, before Device configuration. Old settings stay until Intune overwrites them.
Office Click-to-Run apps: Microsoft 365 Apps come from Intune.
Client apps: Intune apps show up in Company Portal, and Configuration Manager apps stay in Software Center. New Microsoft Store apps need this one on Intune.
After compliance, Microsoft says the most common moves are Office Click-to-Run apps, Client apps, and Windows Update policies. You can slide a workload back. Anything Windows or Office already updated stays updated, though.
On Pilot Intune, Intune deploys Endpoint Protection and Device configuration policies but does not remove them when you unassign them. Plan your pilot like those settings will stick around.
Autopilot devices
New Autopilot PCs can get the Configuration Manager client from Intune. In Intune, go to Devices > Enrollment, open the Windows tab, and find Co-management Settings. Create a profile, set Automatically install Configuration Manager agent to Yes, and paste the command line from the Enablement tab of the co-management properties.
The Intune co-management settings profile that installs the Configuration Manager client during Autopilot. Source: Microsoft Learn.
It only works for Entra joined, user-driven Autopilot. Hybrid join, pre-provisioning, and Autopilot device preparation are out. These devices also need a cloud management gateway to reach Configuration Manager. If the Enrollment Status Page times out with 0x800705b4, the client install ran past the 60-minute default.
Tenant attach
Tenant attach uploads Configuration Manager devices into the Intune admin center without full co-management. It is the Upload to Microsoft Endpoint Manager admin center checkbox on the Configure upload tab. From Intune, you can then sync machine policy, run scripts, use CMPivot, see a timeline, install apps, and read BitLocker keys. Showing a BitLocker key that way rotates it afterward.
What a tenant-attached device looks like in the Intune admin center. Source: Microsoft Learn.
Who manages this device
In Intune, the Managed by column shows Co-managed for both, ConfigMgr for tenant attach only, and Intune for Intune only.
In Configuration Manager, Monitoring > Cloud Attach shows enrollment status, workload changes, and enrollment errors.
On the PC, CoManagementHandler.log in %WinDir%\CCM\Logs shows the enrollment and which workloads are on.
Running dsregcmd /status should show AzureAdJoined : YES.
Common enrollment errors
0x8018002A: Per-user MFA set to Enforced blocked the enrollment, or the user canceled.
0x80180026: A Disable MDM Enrollment policy, or the old Intune PC agent, is in the way.
0x8000FFFF: Automatic enrollment is not set up.
0x80180018: A license problem.
0x8018002B: Entra settings have not landed yet. It usually clears on its own.
No errors and no enrollment: Check MDM user scope and automatic enrollment.
Duplicate Entra device objects, one registered and one hybrid joined: Clean them up first.
Moving forward with Intune co-management
Turn it on with the Cloud Attach wizard, then pilot one workload at a time, starting with compliance. Keep the pilot collection small. When nobody knows who owns a setting, check Managed by in Intune and CoManagementHandler.log on the PC.
What can we learn as a person
What I like about co-management is that nothing has to move all at once. Each workload gets its own slider. You pilot one, watch it, and move the next one when you are ready.
That is not how I change things. A new year comes, and I slide everything to the new system on the same Monday. New diet, new sleep schedule, new budget, new me. By Thursday half of it has failed, and I roll every slider back to the old way.
What is one workload in your life you could move to Pilot this week? And what would you need to see before sliding it all the way over?
I broke a client's staging site testing a plugin I was sure was harmless. Not the live site, thankfully, but close enough that my stomach dropped. The fix was not a better backup habit. The fix was never testing on anything shared again. That is what pushed me into running a development WordPress in Docker, where the worst thing I can break is a folder I can delete and rebuild in about forty seconds. Here is the setup I actually use, plus how to turn on the REST API so an outside editor can talk to it.
What a development WordPress in Docker looks like
Two containers. One runs WordPress with PHP and Apache. The other runs the database. They talk to each other on a private network that Docker creates for you, and only the WordPress container gets a port on your machine. Your theme and plugin folders live on your real disk, so your editor opens real files.
The reason this beats a local stack like XAMPP is version drift. If the client runs PHP 8.3, you run PHP 8.3 by changing one line. No installers, no PATH surgery, no leftover services running on your laptop six months later.
The client talks to the daemon, the daemon runs your containers. Source: Docker Docs.
The compose file
Make an empty folder. Inside it, create docker-compose.yml and paste this.
Those passwords are garbage on purpose. This never leaves your machine, and nothing is published to the internet. If you ever point this at something real, change every one of them.
That WP_ENVIRONMENT_TYPE line matters more than it looks. I will come back to it when we get to the API.
Bring it up
From that folder, run the following.
mkdir theme plugins
docker compose up -d
First run pulls the images, so give it a minute. After that it starts in a couple seconds. Open http://localhost:8080 and you get the WordPress install screen. Pick a language, name the site, create your admin user, and you are in.
Useful commands while you work:
docker compose logs -f wordpress to watch PHP errors as they happen.
docker compose exec wordpress bash to get a shell inside the container.
docker compose down to stop everything and keep your data.
docker compose down -v to stop and delete the database, which is your reset button.
That last one is the whole point. Breaking the site stops being scary when a clean rebuild costs you one command and a fresh install wizard.
Why your theme folder is mounted separately
There are two kinds of storage in that compose file, and mixing them up is the most common way people lose work. Named volumes like wp_data are managed by Docker and live somewhere you do not really browse. Bind mounts like ./theme point at a real folder on your disk.
WordPress core goes in the named volume because you do not edit core. Your theme and your plugin go in bind mounts because you edit those constantly. Save a file in VS Code, refresh the browser, see the change. No copying into the container, no rebuild.
Volumes and mounts are how data outlives the container. Source: Docker Docs.
One caveat on Windows and Mac. Bind mounts cross a filesystem boundary and they are slower than native disk. For a theme and a plugin you will never notice. If you ever bind mount all of wp-content including a few thousand uploads, you will.
Turning on the API for your editor
The REST API is already running. It ships with WordPress and you do not install anything. Hit http://localhost:8080/wp-json in a browser and you will see a wall of JSON describing every route. What you actually need is a way to authenticate, because reading public posts is free but creating and editing is not.
Application Passwords are built into WordPress and they are the right tool here. Go to Users > Profile in the admin, scroll to Application Passwords, type a name like editor, and select Add New Application Password. WordPress shows you a password with spaces in it exactly once. Copy it then, because it never shows it again.
Here is the part that sends people in circles. If that Application Passwords section is missing entirely, it is not broken. WordPress hides it when the site is not on HTTPS and the environment type is not local. Your container is plain HTTP on port 8080, so without that WP_ENVIRONMENT_TYPE line from earlier, the section simply never renders. That one define is what makes it appear.
Talking to it
Authentication is HTTP Basic. Username is your WordPress login, password is the application password, spaces included. Read your posts first to prove the credentials work.
Then create a draft, which is the call an editor integration actually cares about.
curl -X POST \
-u "dave:abcd EFGH ijkl MNOP qrst UVWX" \
-H "Content-Type: application/json" \
-d '{"title":"Written from my editor","content":"Hello from curl.","status":"draft"}' \
"http://localhost:8080/wp-json/wp/v2/posts"
You get the created post back as JSON, including its id. From there every other route follows the same shape. Media uploads go to /wp/v2/media, categories to /wp/v2/categories, pages to /wp/v2/pages. Add ?context=edit when you want the raw fields instead of the rendered ones.
The two things that will bite you
Permalinks come first. If Settings > Permalinks is set to Plain, the pretty /wp-json/ route can return a 404 and you will swear the API is off. Set permalinks to Post name and it starts working. If you are stuck, http://localhost:8080/?rest_route=/wp/v2/posts is the fallback form that works regardless.
Custom meta comes second. The REST API will not write a meta field it does not know about. Plugins like Yoast register their own fields, but anything custom of yours needs register_post_meta with show_in_rest set to true. Skip that and your write silently does nothing, which is a genuinely annoying way to lose an afternoon.
Wrapping up
A development WordPress in Docker is one compose file, one folder, and two commands. Named volumes hold the parts you do not touch, bind mounts hold the code you edit, and docker compose down -v gives you a clean slate whenever you want one. Set the environment type to local so Application Passwords show up, fix your permalinks, and the REST API will take instructions from whatever editor or script you point at it. Copy the folder, change the port, and you can run a second site next to the first without either one knowing.
What can we learn as a person
Something clicked for me about compose files that has nothing to do with Docker. A compose file does not list steps. It describes the end state you want, and then the tool figures out how to get there. Install this, then configure that, then start this service in this order is a plan. WordPress running with a database attached is a goal.
I am a plan person by default, and I have watched it hurt me. I build the whole staircase in my head, and then step four goes sideways because a person got sick or a meeting moved, and I do not gracefully adapt. I stall. The plan was the thing I was committed to, so when the plan broke, I treated it like the goal broke. Those are not the same, and I keep having to relearn it.
Goals bend. A goal like get healthier survives a missed workout. A plan like run four miles every morning at six dies the first morning you oversleep, and worse, it takes your motivation with it, because now you are someone who failed. Same destination, completely different failure behavior. The rigid version breaks on contact with an ordinary Tuesday.
I am not against planning. Steps are how anything gets done. But I am trying to hold the plan loosely and the goal tightly, instead of the other way around. So what is something you gave up on recently, and was it really the goal that failed, or just the route you picked to get there?
Office is the first thing anyone opens on a new laptop, which makes it the first thing they notice is missing. Getting Microsoft 365 Apps onto devices with Intune is mostly easy. Keeping every device on the same update channel and the same settings is where people get tripped up.
Two ways to install
Intune has a built-in Microsoft 365 Apps app type. It is the easiest path and covers most companies. The other option is the Office Deployment Tool, which Microsoft calls the ODT, wrapped up as a Win32 app. That gives you more control, and Microsoft recommends it when Office has to install during Autopilot. Both download Office straight from Microsoft's servers.
The built-in Microsoft 365 Apps app in Intune
Intune admin center > Apps > All Apps > Create
Under Microsoft 365 Apps, pick Windows 10 and later.
On App suite information, give it a name.
On Configure app suite, set Configuration settings format to Configuration designer and fill in the settings.
Assign it, then Review + create.
The Configuration designer for the built-in Microsoft 365 Apps app. Source: Microsoft Learn.
Select Office apps: Which apps to install. Project and Visio sit under Select other Office apps, because they need their own licenses.
Architecture: 64-bit unless you have an old add-in that only works in 32-bit.
Update channel: How often Office updates. More on that below.
Remove other versions: Yes removes old MSI-installed Office first. Leave it on.
Use shared computer activation: For machines lots of people sign in to, like shared PCs or Cloud PCs.
Accept the Microsoft Software License Terms on behalf of users: Yes, so nobody sees a license prompt.
Languages: Pick them, or leave it to match the operating system.
Things the built-in app will not do
A device only gets one Microsoft 365 Apps deployment. If you assign two, only one arrives.
Old MSI-based Office has to come off first, or the install fails.
If Office apps are open during install, it can fail, and unsaved work can be lost.
It does not work on Windows Home.
It does not go through the Intune Management Extension, so the Intune Management Extension logs will not help you.
The Office Deployment Tool
The ODT is a small program, setup.exe, that reads a configuration.xml file telling it what to install. You build that file at config.office.com with the Office Customization Tool, which gives you the same choices as the Configuration designer and more. Here is the sample from Microsoft's docs, switched to 64-bit to match the advice above:
Useful extras in the XML include RemoveMSI to clear out old Office and SharedComputerLicensing for shared machines. The channel values are Current, MonthlyEnterprise, and SemiAnnual. You can also paste the same XML into the built-in app by choosing Enter XML data instead of the Configuration designer.
The built-in app with Enter XML data selected, using an Office Deployment Tool configuration file. Source: Microsoft Learn.
Microsoft 365 Apps during Autopilot
If the Enrollment Status Page waits on Office, Microsoft recommends the Win32 route. The built-in app can start installing while a Win32 app is still running, and that collision fails the setup screen. Wrap setup.exe and your configuration.xml with IntuneWinAppUtil, use setup.exe /configure configuration.xml as the install command, and use a detection rule that only passes once Office is really there. I covered building those in Intune detection rules. Microsoft also says not to mix line-of-business and Win32 apps during setup, because both use the same Windows installer service.
Update channels
Current Channel: New features as soon as they are ready.
Monthly Enterprise Channel: One update on the second Tuesday of each month, with each version supported for three months.
Semi-Annual Enterprise Channel: Features twice a year, but that is changing.
Starting with Version 2606 in July 2026, Semi-Annual Enterprise devices get monthly updates and show up as Monthly Enterprise Channel under File > Account. Microsoft says the first update after the switch is about 1.6 GB, so plan for that on slow connections.
Set the channel in one place only. In Intune, use a settings catalog policy with Update Channel set to Enabled and Channel Name: (Device) set to the channel you want. The other option is Cloud Update in the Microsoft 365 Apps admin center at config.office.com. It has profiles for Current and Monthly Enterprise, you add groups under the profile's Device selection criteria, and the default deadline is 3 days. If both are set, Cloud Update wins. If the channel in the app and the channel in a policy disagree, devices flip back and forth.
The Microsoft 365 Apps admin center, home to Cloud Update and Cloud Policy. Source: Microsoft Learn.
Cloud Policy for Office settings
Cloud Policy sets Office settings for users, no matter what device they sign in on. It even works on personal machines that are not enrolled in Intune. Go to config.office.com, then Customization > Policy Management > Create. You can also reach it from Intune under Apps > Policy > Policies for Office apps.
Scope it to all users or specific groups. It only looks at users, so device objects in a group get ignored. Office checks in every 90 minutes for targeted users and every 24 hours for everyone else, and changes apply when the Office app restarts. If policies overlap, priority 0 wins, and Reorder priority changes the order.
If Cloud Policy is not applying, check that Office is activated, check the user's group membership and the policy priority, and look for an authenticated proxy in the way. To force a fresh check-in, delete HKCU\Software\Microsoft\Office\16.0\Common\CloudPolicy and restart Office.
Troubleshooting an install
To check what a device has, open any Office app and go to File > Account > About. If the install never seems to start, look in C:\Program Files for Microsoft Office and Microsoft Office 15 folders. Those show that Intune kicked it off. Then watch C:\Program Files\Microsoft Office\Updates\Download grow.
For detailed logs, turn on verbose logging, try the install again, and look in %temp% and C:\Windows\Temp for files named after the computer and a timestamp:
1603: Old MSI Office is still installed, or you tried to put 64-bit over 32-bit.
17002: The install was canceled, another install was running, or the disk is full.
17004: The product ID in the XML is wrong.
1460: The download timed out.
0-1011 or 30088-1015: A network problem or not enough disk space.
To make Office check for updates right now, open Task Scheduler, go to Microsoft > Office, and run Office Automatic Updates 2.0.
A simple plan for Microsoft 365 Apps and Intune
Use the built-in Microsoft 365 Apps app in Intune with Remove other versions on. If Office has to install during Autopilot, use the ODT as a Win32 app instead. Pick one place to set the update channel, either the settings catalog or Cloud Update, and put Office settings in Cloud Policy so they follow the user.
What can we learn as a person
Microsoft is moving Semi-Annual Enterprise devices to monthly updates. Twice a year sounded calm, but each of those updates was big, and big changes are where things break.
If I could, I would put my whole life on Semi-Annual. Save every change up, then do them all at once in one huge, exhausting weekend. New routine and new budget, all at the same time. Then I wonder why the install fails.
What small change could you ship this month instead of saving it for the big one? And what are you holding back for a semi-annual update that could go out today?
A new laptop boots up, the user signs in, and before they ever see a desktop Windows asks them to set up a PIN. Some of them think it is a scam. The rest type 1234 and get told no. That prompt is Windows Hello for Business, and Intune decides when it shows up and what the rules are.
What Windows Hello for Business is
Windows Hello lets people sign in with a PIN, their face, or a fingerprint instead of a password. Windows Hello for Business is the work version. It covers Entra ID and Active Directory accounts and adds the controls a company needs. The consumer version covers personal Microsoft accounts. Neither one works with local accounts.
People always ask why a short PIN is safer than a long password. The PIN only works on that one device. It never leaves the device and never gets stored on a server, so a stolen PIN is useless without the actual laptop. The TPM chip inside the laptop also locks things down after too many wrong guesses. Fingerprint and face data stay on the device too.
Every user needs a PIN, even if they only plan to use their face. The PIN is the fallback, and you cannot turn it off. Windows also rejects simple patterns like 1111, 1234, or 1357.
It is already on
Windows Hello for Business is turned on by default for Entra joined devices. That is why users get the PIN prompt even when nobody in IT configured anything.
The tenant-wide setting lives in Intune admin center > Devices > Device onboarding > Enrollment. Stay on the Windows tab and click Windows Hello for Business. Configure Windows Hello for Business has three options:
Enabled: Turns it on and shows the PIN and biometric settings.
Disabled: Users cannot set up Windows Hello for Business during enrollment.
Not configured: Intune leaves whatever is already on the device alone.
The tenant-wide Windows Hello for Business setting under Devices > Enrollment > Windows. Source: Microsoft Learn.
This setting only applies when a device enrolls, so changing it later does nothing to devices you already have. It also hits every device that enrolls, no matter what group the user is in. Microsoft's own guidance is to leave this one Disabled and turn Windows Hello for Business on with a policy aimed at a group.
Turn it on with a policy
Intune admin center > Endpoint security > Account protection
Click Create Policy.
Set Platform to Windows and Profile to Account protection, then click Create.
Name it, set the Windows Hello for Business settings, and assign it to a group.
You can also build it in the settings catalog under the Windows Hello For Business category. Either way, these are the settings to look at:
Use Windows Hello For Business: Set to true to turn it on.
Require Security Device: Set to true to require a TPM chip.
Minimum PIN length: 6 by default, anywhere from 4 to 127.
Lowercase letters, uppercase letters, and special characters in the PIN: Each one can be allowed, required, or not allowed.
Allow biometric authentication and Use enhanced anti-spoofing, when available: These control face and fingerprint.
Enable Pin Recovery: Lets users reset a forgotten PIN without losing their keys.
A policy updates devices on the normal check-in schedule, which the tenant-wide setting never does. If you want the policy in place before a new user reaches the desktop, use the Enrollment Status Page. I walked through it in how Intune Autopilot works.
When settings collide
If a regular device passcode policy and a Windows Hello for Business policy both set PIN rules, the Windows Hello for Business policy wins. Mixing Group Policy and Intune for these settings is worse. When both exist, Group Policy wins and Windows ignores the Intune settings. The usual setting that makes Intune beat Group Policy does not apply here.
Hybrid joined devices and cloud Kerberos trust
You will see words like key trust, certificate trust, and cloud Kerberos trust. These only matter when people use Windows Hello for Business to reach on-premises Active Directory resources, like file shares. Cloud-only setups can skip this section.
For hybrid setups, Microsoft recommends cloud Kerberos trust. It is the only hybrid option that needs no certificates. Key trust and certificate trust both need a PKI, and certificate trust also needs AD FS. In the settings catalog, turn on Use Cloud Trust For On Prem Auth. The first time someone signs in with their PIN on a hybrid joined device, the device needs to reach a domain controller.
What the user sees
Setup starts right after the user profile loads and before the desktop shows up. Windows offers face or fingerprint first, which the user can skip. Then it shows the screen below, asks for multifactor authentication, and has them create the PIN.
The screen users see when their organization requires Windows Hello for Business. Source: Microsoft Learn.
The multifactor step is required. If the user never registered for MFA, Windows walks them through that first, so give new hires a heads-up.
Resetting a forgotten PIN
Users can do it from the lock screen by clicking Sign-in options, choosing the PIN option, and clicking I forgot my PIN. If they are already signed in, it is Settings > Accounts > Sign-in options > PIN (Windows Hello) > I forgot my PIN.
By default this is a destructive reset. Windows deletes the old PIN and keys and makes new ones. It works without any setup, but on a hybrid joined device it needs to reach a domain controller. A gentler reset that keeps the keys needs the Microsoft PIN Reset Service and the Enable Pin Recovery setting.
Troubleshooting Windows Hello for Business
Is it set up at all?
Run dsregcmd /status as the user and look under User State. NgcSet : YES means the user has a Windows Hello for Business key. If it says NO, look for the Ngc Prerequisite Check section. It lists IsDeviceJoined, PolicyEnabled, DeviceEligible, and SessionIsNotRemote, and the last line tells you whether Windows will try to set it up.
The prompt never shows up
Open Event Viewer and go to Applications and Services Logs > Microsoft > Windows > User Device Registration > Admin. Event 358 means setup will launch. Event 362 means it will not, and the event lists every check with a Yes or No so you can see which one failed. Setup never launches over Remote Desktop, so test while sitting at the actual machine.
Something went wrong
When setup fails, the user gets this screen with an error code. Have them send you a photo of it before they click anything.
The PIN setup error screen. The error code is the part you need. Source: Microsoft Learn.
0x80090029: The TPM is not set up on this device.
0x80090035: The policy requires a TPM and the device does not have one.
0x801C03ED: Multifactor authentication was required but did not happen.
0x801C000E: The user hit the device registration limit.
For anything else, try again, sign out and back in, and restart before you dig deeper.
Face or fingerprint not working
Enhanced sign-in security blocks external cameras and fingerprint readers, so a USB webcam may not be allowed. Enhanced anti-spoofing turns off face sign-in on cameras that do not support it. After too many failed tries, Windows disables the biometric until the user signs in another way. A restart does not bring it back.
The practical version
Set the tenant-wide Windows Hello for Business setting on purpose instead of living with the default, then turn it on with an Account protection policy in Intune for the groups that should have it. Use cloud Kerberos trust for hybrid devices. When a user has trouble, dsregcmd /status and the User Device Registration log will tell you why.
What can we learn as a person
You cannot turn off the PIN in Windows Hello for Business. Face and fingerprint are nice, but when the camera fogs up or the fingerprint reader decides it has never met you, Windows falls back to the PIN.
I have fancy options for bad days. A long walk, or a plan to journal that I follow about twice a year. They work great when everything else is working. When they fail, I find out I never set up a PIN. There is no simple, boring fallback I can reach for when I am too tired for the good stuff.
So what is your PIN? When the face and fingerprint version of you stops working, what is the plain thing you fall back on?
I once inherited a network with exactly one piece of documentation. A sticky note on a monitor that said the wifi password and nothing else. No IP scheme, no server list, no idea which of the four firewalls was actually live. I spent my first two weeks doing archaeology instead of work. That is the fear that made me systematic about this, so here is how to document a new environment in OneNote without it turning into another sticky note you lose.
Why OneNote for this
OneNote is free, it is already in your Microsoft 365 tenant, and it nests the way an environment actually nests. A notebook holds sections, sections hold pages, and pages hold your notes. That maps cleanly onto an environment that has categories, systems, and details. It also syncs through OneDrive or SharePoint, so the notebook is not trapped on your laptop where it dies with your laptop.
The search is the part you will love at 2am during an outage. Full text search across every page, including text inside pasted screenshots. You will find the one config note you wrote eight months ago by typing half a word.
Start a SharePoint site so the notebook has a shared home, not a personal one. Source: Microsoft Learn.
Put the notebook somewhere the team can reach
Before you type a single note, decide where the notebook lives. Not your personal OneDrive. If you get hit by a bus, or just quit, the documentation should not leave with you. Put it on a SharePoint site the team owns.
Make the site first. Go to the SharePoint admin center, open Active sites, select Create, and pick Team site. Name it something obvious like IT Documentation. Then in OneNote, choose Add notebook, and when it asks where to save, point it at that SharePoint site instead of your personal account. Now the whole team opens the same notebook, and permissions are controlled by the site, not by you emailing a file around.
A team site gives your documentation shared ownership and real permissions. Source: Microsoft Learn.
The sections you need to document a new environment
Sections are your categories. If you stare at a blank notebook you will freeze, so steal this starting set. Make each one a section, and add or drop as the environment tells you to.
Overview. Company contacts, site addresses, ISP and circuit info, main points of contact, and who to call when it is on fire.
Network. IP scheme, VLANs, subnets, DNS, DHCP scopes, firewall makes and models, VPN setup.
Identity. Domain name, domain controllers, Entra tenant, sync setup, admin accounts and how they are structured.
Servers. One page per server or VM. Role, OS, IP, host, what breaks if it goes down.
Endpoints. Intune or your MDM, imaging process, standard build, patching.
Applications. Line of business apps, where they run, vendor support lines, how they are licensed.
Backup and recovery. What is backed up, where it goes, retention, and the last time you actually tested a restore.
Vendors and licensing. Contracts, renewal dates, account numbers, support portals.
Runbooks. Step by step for the recurring tasks. Onboarding, offboarding, the printer thing everyone forgets.
Change log. Dated entries for anything you change. Future you will want this.
Inside each section, one page per thing. One page per server, one page per app. That keeps pages short and makes them linkable, which matters in a minute.
Linking to the password manager, not storing the passwords
This is the rule people break first and regret most. Do not put passwords in OneNote. OneNote is not a secrets vault. It has no real audit trail, and every sync copies those notes to more devices. A password manager exists for exactly this job, so let it do the job.
Instead, link out. Most password managers can produce a link or reference that points at a specific entry. In 1Password it is a private link on the item. Bitwarden, Keeper, and others have their own version of a deep link or item URL. Copy that link, then in OneNote highlight the text like domain admin credentials, and paste the link on it with Ctrl+K. Anyone with rights to the vault clicks through and lands on the real entry. Anyone without rights hits a wall, which is the point.
So the server page says what the account is and links to where the secret lives. The secret itself never touches the notebook. You get the convenience of one click without turning your documentation into the biggest security hole in the building.
Linking pages to each other
The thing that turns notes into documentation is cross links. Your app page should link to the server page it runs on. Your runbook should link to the identity page it references. In the desktop app, right-click any page tab and choose Copy Link to Page, then paste it wherever it belongs.
Do this and the notebook stops being a pile of pages and becomes a map. You click from the broken thing to the thing it depends on without searching. During an incident that is the difference between five minutes and fifty.
Where SharePoint carries more than the notebook
OneNote is great for notes, and clumsy for files. That is where the SharePoint site earns its keep beyond just hosting the notebook. Use a document library on the same site for the artifacts that do not belong pasted into a page.
Network diagrams and Visio files.
Exported configs, firewall rules, switch backups.
License PDFs and signed contracts.
Vendor quotes and warranty docs.
SharePoint keeps version history on every file, so when someone overwrites the good diagram with a bad one, you roll it back. Then link from the OneNote page to the library file, and your notes and your files point at each other instead of drifting apart.
Wrapping up
Start the site, save the notebook to it, build the sections from the list above, and make one page per system. Link credentials out to the password manager and never paste a secret. Cross link the pages so the notebook reads like a map, and hang the heavy files in a SharePoint library with version history. Done this way, how to document a new environment stops being a dreaded project and becomes a habit. It is not a weekend project. It is fifteen minutes every time you touch something, and in six months you have the documentation you wish you had inherited.
What can we learn as a person
The reason that undocumented network scared me so much is that I could not ask it anything. There was nobody to ask and nothing written down, so every answer had to be dug up the hard way. Documentation is really just a way of answering questions someone has not asked yet.
I am bad at asking questions in real life. I will spend an hour circling a problem alone rather than send a two line message to someone who already knows the answer. Part of it is pride, part of it is not wanting to bother anyone, and part of it is a quiet fear that needing to ask means I should have already known. So I dig through my own head like it is an undocumented server, when there is a person right there who is the documentation.
The best environments I have worked in were not the ones with the smartest people. They were the ones where asking a question was normal and cheap, where nobody made you feel small for not knowing. I want to be that for other people, and I am still learning to let other people be that for me. So what is the question you have been sitting on for a week, and who could you ask if you let yourself?
We use cookies to ensure that we give you the best experience on our website. If you continue to use this site we will assume that you are happy with it.
