Autopilot device naming templates: the 15-character wall and the duplicate hostnames it silently creates

The device name template in a Windows Autopilot deployment profile is one line of text. You type a prefix, you add %SERIAL%, you move on. It is the least interesting field in the whole profile, which is exactly why it is the one that quietly breaks your estate eighteen months later.

The failure is not loud. Nothing errors. Two laptops finish the out-of-box experience (OOBE) perfectly, both enrol, both go compliant. They just happen to have the same hostname. Domain Name System (DNS) starts flapping between two addresses for one record, Remote Help lands on the wrong machine, and your asset report has a row you cannot explain. This post covers the character arithmetic that causes it, what Microsoft actually documents about truncation, and how to design a template that cannot collide.

The problem: two laptops that answer to one hostname

The ticket usually arrives from the service desk rather than from monitoring. A technician starts a remote support session, connects, and finds a different user's desktop. Or a software deployment reports success on a machine that never received it. Or DNS answers for the same hostname with two different addresses, depending on which record won the last dynamic update.

When you go looking, the picture is confusing. The two systems that ought to flag the problem both think everything is fine.

Intune shows two rows with an identical Device name. Microsoft Entra ID shows two device objects with an identical displayName. Neither platform complains. That is not a bug, it is by design. The Entra device object is keyed on deviceId, a unique identifier set by the Device Registration Service at registration time. The Intune record is keyed on its own id. The display name is just an attribute, and two objects with the same attribute value are perfectly legal.

So the damage shows up wherever the name is the primary key rather than an attribute:

• DNS. Both devices dynamically register the same host record. Whichever registered last wins, until the other one refreshes.
• NetBIOS and Server Message Block (SMB). Two machines registering the same NetBIOS name on one network produce a name conflict, and one of them loses its Workstation service registration.
• Configuration Manager, if you are co-managed. Two clients with the same name and different hardware identifiers create the classic duplicate-record churn in the site database.
• Every runbook you own. Any query filtered on deviceName now returns two objects, and most scripts silently take the first one.

None of this is caused by a broken Autopilot service. All of it traces back to one line of text in a deployment profile.

Why it happens: a 15-character budget and a serial cut from the front

Start with the ceiling. Microsoft's Active Directory naming reference is explicit about NetBIOS computer names. The minimum length is one character and the maximum name length is 15 characters, because the sixteenth character is reserved for identifying the functionality registered on the network device. The same article adds that Windows does not permit computer names longer than 15 characters, and that you cannot specify a DNS host name that differs from the NetBIOS host name. That is the wall. Everything else is arithmetic against it.

The Autopilot profile documentation restates the constraint in product terms. On the out-of-box experience page of the profile wizard, Apply device name template carries this rule: names must be 15 characters or less, they can have letters, numbers and hyphens, and they cannot be all numbers. The Microsoft Graph reference for the underlying deviceNameTemplate property says the same thing from the other direction. The total length of the text generated by the template can be no more than 15 characters.

The two variables Microsoft documents, and only two

There are exactly two. Anything else you have seen in a forum thread is not a documented Autopilot variable, and inventing one will simply produce a literal string in your hostname.

Two documented details matter more than the syntax. First, from the Accounts configuration service provider (CSP): using any of these macros will limit the new name to 15 characters. Second, from the DevDetail CSP node that supersedes it: the character restriction limit does not count the length of the macros themselves. The budget is spent by the output, not by the template text. So CONTOSO-%SERIAL% is a 16-character string that is a perfectly valid template, because only the literal CONTOSO- counts against the 15.

The arithmetic nobody does before clicking Create

Take 15, subtract every literal character in the template, and what remains is the number of serial characters that survive. That is the whole model.

Now apply the documented truncation direction. The serial is cut from the beginning, so what survives is the tail. Consider two devices from the same vendor purchase order, with serials that differ only in their leading block.

That is the entire mechanism. A generous prefix looks tidy in a spreadsheet and destroys the distinguishing part of the serial number. Vendors that encode plant or line codes at the front and a sequential counter at the back survive truncation fine. Vendors that do the opposite, with the unique block first and a common batch suffix last, collide the moment your prefix grows.

The gotcha that eats your serial entirely

A common instinct on discovering truncation is to bolt a random suffix on the end, something like CTS-%SERIAL%-%RAND:3%, so that colliding serials get separated. Microsoft documents that this does not work the way you expect.

What %RAND:x% actually buys you

%RAND:x% is genuinely collision-resistant, but only if you spend enough characters on it. Microsoft's guidance is directional rather than numeric. The Accounts CSP says to use the random macro with a large number to reduce the likelihood of a duplicated device name. The DevDetail CSP recommends either macro with a high character limit to reduce the chance of a name collision.

Microsoft does not publish a collision probability table, so here is the ordinary birthday arithmetic instead. For n devices drawn from N possible names, the expected number of colliding pairs is roughly n squared divided by 2N. The figures below are that formula applied to a 5,000-device estate. They are my arithmetic, not a documented Microsoft value.

The lesson is uncomfortable but simple. Six random digits, the value most templates use, is not enough for a mid-sized estate. Eleven digits is, and with a three-character prefix plus a hyphen you can afford exactly eleven.

Hybrid join takes a different path entirely

Everything above applies to Microsoft Entra joined devices. The profile field itself is gated, because Apply device name template requires the Microsoft Entra join type. For Microsoft Entra hybrid joined devices the naming happens in a separate Domain Join configuration profile, and Microsoft is blunt about its capability. The naming capability for Windows Autopilot for Microsoft Entra hybrid join does not support variables such as %SERIAL%, and it only supports prefixes for the computer name. The Autopilot profile page says the same thing more briefly: only a prefix can be provided for hybrid devices in a Domain Join profile.

So on the hybrid path you supply a Computer name prefix and the remainder of the 15 characters is generated for you. Two consequences follow. Your prefix is a direct tax on randomness, because a longer prefix means fewer generated characters and a higher collision rate, with no serial number available to compensate. And renaming afterwards is not an escape route. Microsoft documents that renaming Microsoft Entra hybrid joined devices from Intune is not supported, and that you must use domain-based methods outside Intune instead.

How to verify: read the template, do the arithmetic, hunt the collisions

Verification has three layers. What the profile says, what the device ended up with, and whether the estate already contains duplicates.

1. Read the Entra-join template in the portal

1. Sign in to the Microsoft Intune admin center.
2. Select Devices in the left hand pane, then select Windows under By platform.
3. Under Device onboarding, select Enrollment.
4. Under Windows Autopilot, select Deployment Profiles.
5. Open the profile, then select Settings.
6. Find Apply device name template. Read the template string and count its literal characters.
7. Subtract that count from 15. That number is how many serial characters your devices actually keep.

2. Read the hybrid prefix in the Domain Join profile

1. Select Devices, then Manage devices | Configuration, then Policies.
2. Open the profile built from the Domain Join template for platform Windows 10 and later.
3. Read the Computer name prefix. Every character here is a character not available for uniqueness.
4. Note the Domain name and the optional Organizational unit in distinguished name format, so you know which Active Directory container the duplicates would land in.

3. Confirm what the device actually got

The registry is where a pending rename hides. Microsoft documents the two locations in its Workstation service troubleshooting article. The non-volatile ComputerName subkey holds the name that will apply, and the volatile ActiveComputerName subkey holds the name currently in force. If they disagree, the device is mid-rename and a restart will change its identity.

All three values below sit under one parent key:

4. Audit the whole estate for duplicates

Because there is no service-side check and no event to watch, detection has to be a query. The companion script for this post reads Intune managed devices and Entra device objects, groups them on name, and reports three things. Exact duplicates, names sitting at or within one character of the 15-character ceiling, and names whose shape suggests a truncated serial. It performs GET requests only and uses read-only scopes.

The fix: a template that cannot collide

The design goal is a template where collision is arithmetically impossible or vanishingly unlikely. Not one that merely looks organised. Four rules get you there.

1. Spend at most four characters on literals. A three-character prefix plus a hyphen leaves eleven characters. That is enough for most full serial numbers, and enough for %RAND:11%.
2. Do not encode site, department or role in the hostname. Those attributes change without the hardware changing, and every character they consume is stolen from uniqueness. Put them in Entra device categories, group membership or extension attributes, where they can be edited without a rebuild.
3. Pick one variable. Because the random macro takes priority and the serial is ignored when both appear, a mixed template silently becomes a random-only template.
4. Measure your vendors' serials before choosing. Run the audit script against your existing estate and look at serial length, and at how many serials share a tail. If the last few characters are not unique across your fleet, use %RAND:11% rather than %SERIAL%.

Changing the template on an existing profile

1. Go to Devices, then Windows, then Enrollment, then Deployment Profiles.
2. Select the profile and choose Settings.
3. Set Apply device name template to Yes and enter the new template.
4. Review the generated length against the 15-character budget one more time, then save.

Remediating names that already collided

For Microsoft Entra joined devices the Intune rename action is the supported path, and its rules are looser than the template's. The rename action permits a name of up to 63 characters, allows letters, numbers and hyphens, forbids spaces, forbids names that contain only numbers, and publishes an explicit disallowed-character list. Bulk rename additionally requires a variable in the name, and note that the syntax differs from the Autopilot template. It is {{serialnumber}} and {{rand:x}} with double braces, not percent signs.

1. Select Devices, then All devices, then Bulk Device Actions.
2. On the Basics page, set OS to Windows and set Device action to Rename.
3. Enter a name that includes {{serialnumber}} or {{rand:x}}.
4. Select the affected devices, then complete the configuration wizard. Choose whether to restart after rename.

Proof it worked: unique names and a quiet DNS zone

The proof here is negative evidence, which makes it easy to skip. Do not skip it. Re-run the audit after the template change and after the renames, and confirm three things. Zero duplicate groups, headroom below 15 characters where you expect it, and no fixed-prefix cluster sitting on the ceiling by accident.

Then confirm the downstream symptoms have cleared. In DNS, each hostname should resolve to one address consistently across repeated lookups. In Entra ID, a search on the previously duplicated name should return a single object. On a rebuilt device, the persisted and active computer name registry values should match, meaning no rename is left staged. And if you are co-managed, the Configuration Manager console should stop generating fresh duplicate records for the affected names.

One last habit is worth adopting. Put the audit on a schedule rather than running it after an incident. Because there is no event log signal and no service-side uniqueness check, a monthly report is the only thing standing between a careless template edit and a hostname collision you discover through a mis-routed support session.

References

• Configure Windows Autopilot profiles - the Apply device name template setting, the 15-character rule, the allowed characters, and the hybrid prefix-only note.
• Accounts CSP - the documented macro table, the truncation-from-the-beginning rule, and the explicit statement that uniqueness is not guaranteed.
• DevDetail CSP - the Ext/Microsoft/DNSComputerName node, the 63-character DNS maximum, the rule that macro text does not count toward the limit, and the random-beats-serial precedence.
• Enrollment for Microsoft Entra hybrid joined devices - the Domain Join profile, its Computer name prefix, and the statement that variables such as %SERIAL% are not supported there.
• Device Action: Rename Device - the rename rules, the disallowed character list, the bulk rename variables, and the note that hybrid joined devices cannot be renamed from Intune.
• Name computers, domains, sites, and OUs - the NetBIOS 15-character maximum, the disallowed characters, and the all-numeric restriction.
• windowsAutopilotDeploymentProfile resource type - the deviceNameTemplate property and its documented 15-character generated length.
• Error 2250 when the LanmanWorkstation service fails to start - the documented ComputerName and ActiveComputerName registry locations.
• device resource type (Microsoft Graph) - displayName, deviceId, trustType and enrollmentProfileName, all used by the companion audit script.
• List managedDevices - the endpoint and the least-privilege delegated scope the script requests.

Community deep-dives that cover the same ground from a practitioner angle. Both were fetched and confirmed on topic before being listed here.

The companion read-only audit script for this post is Get-DeviceNameCollisionReport.ps1 in the Windows Autopilot scripts collection. It performs GET requests only, prompts before installing any module, and exits non-zero when it finds a collision so you can wire it into a scheduled job.