Settings Overview

The Settings page (/settings) is a tile grid that routes to focused sub-pages. Each tile opens a dedicated area with its own URL-addressable sub-tabs, so settings can be linked directly and bookmarked.

Tile Layout (Core)#

*The Cloud Integrations tile is license-gated: it appears whenever a valid license or an active trial makes the Enterprise feature set available (see Licensing). There is no registry flag.

Old addresses still work: /settings/general/winver and /settings/general/winpe land on Version Lists, /settings/backup lands on Diagnostics > Backup & Restore, /settings/notifications/smtp lands on Notifications > Channels, and /settings/relays/upgrades lands on Relays > Registration & Upgrades. Each corrects the address bar so bookmarks converge on the surviving address.

Relay Mode#

When the server is running as a Relay, Settings collapses to a single tile:

• Relay Configuration (/settings/relay-config) - a short Core Connection summary (read-only, driven by relay.json) and the editable Sync Schedule. The full read-only inventory - database, data storage, resolved paths - lives on Diagnostics > System Info, which this page links to rather than repeating.

Core-only tiles are hidden.

URL-Addressable Sub-Tabs#

Every settings sub-page supports direct-link URLs of the form /settings/<area>/<tab>. For example:

• /settings/security/saml opens Security on the SAML/SSO tab
• /settings/autopilot/azure and /settings/connectedcache/certificates open those pages on the named tab - their internal tabs are addressable too

Switching tabs updates the URL via NavigationManager.NavigateTo(replace: true) so browser history stays clean.

Multicast WIM streaming#

Settings > Deployment > Agent & Multicast. When enabled, multiple agents requesting the same WIM image receive it via UDP multicast instead of individual HTTP streams.

Network requirements:

• Multicast requires IGMP snooping on managed switches.
• Agents that cannot receive multicast automatically fall back to standard HTTP streaming, so enabling it is safe even where support is uneven.
• Recommended for lab / deployment VLAN environments running 5 or more simultaneous deployments. Below that, individual HTTP streams are simpler and just as fast.
• Increase TTL if multicast has to cross routers between VLANs.
• Chunk size is the payload per UDP datagram (default 8192). Larger is faster but risks fragmentation.
• Send rate (default 50 MB/s) is the throttle, and it is the setting that stops a multicast session filling the link on its own. It is honoured as an average: the server paces against a deadline rather than pausing between datagrams, so the stream goes out in short bursts a few milliseconds apart and the rate you set is the rate you get. Set it below what the site's switching can absorb - a stream faster than the network can forward is dropped packets, and a dropped chunk cannot be asked for again, so every machine on that session falls back to HTTP.

Group address, base port, send rate and max concurrent sessions are all configurable on the same tab. When multicast is disabled, every agent uses an individual HTTP stream.

Relay sites#

The settings on this tab are fleet-wide and they reach every relay, through the same sync manifest that already carries the unattend settings and the organization details. A relay applies them to its own streaming service on the next sync - no restart, and nothing to configure at the branch.

That is the case multicast is actually for. A relay serves a branch office, and the link that hurts is the one into that office, so ten machines at a branch each pulling the same WIM is the problem worth solving. A Core-only multicast setting optimised the one site that was already fine.

Per-site overrides: Site detail > General > Multicast WIM streaming. These seven describe the network the stream crosses, and that is a property of the site - one branch has IGMP snooping with a querier, another floods the group to every port; one uplink is 10 GbE and another is a closet switch; 239.255.42.x may already be spoken for at one location. So each site can override any of the seven, and every box shows where the value in force came from:

Leave a box on Inherit to follow Core; clearing an override returns the site to the fleet value on its next sync. Overrides are authored here in Core, not at the relay, so this console can always answer what a given site is running. A relay has no multicast settings page of its own.

A change to a site's overrides changes that site's manifest, so its next heartbeat picks it up within 15 seconds rather than waiting out the normal interval.

What the agent does, and when it gives up#

The agent asks for a session as its imaging phase begins, joins the group on every network adapter that is up, and assembles the image from the numbered chunks it receives. There is no retransmit - UDP multicast has no way to ask for a packet again - so the agent's job is to notice that something is missing rather than to repair it. Any of the following ends the attempt and the machine downloads the image over HTTP instead:

• Nothing arrives within 30 seconds. The usual cause is a VLAN that is not forwarding the group. This is the common case on unmanaged or partially-configured networks, and it costs each machine half a minute, once.
• The stream goes quiet for 20 seconds part way through - the session was cancelled, or the path broke.
• Chunks are missing when the stream ends. Even one is enough.
• The session was already streaming when the agent asked to join. A machine that arrives late has missed the beginning and cannot catch up, so it goes straight to HTTP rather than waiting out a transfer it can never complete.

Every one of those is logged to the deployment console with the reason, and a partially received image is deleted rather than kept.

The SHA-256 check is the same either way. A multicast-assembled image is hashed against the server's record exactly as a downloaded one is. If it does not match, the deployment halts with MULTICAST_INTEGRITY_FAILED - it does not retry and it does not apply the image. That code means the network corrupted the transfer in a way the chunk accounting could not see, so the action is to turn multicast off here rather than to re-upload the WIM.

When a change takes effect#

No restart is needed for any of these. What differs is whether a change reaches a transfer that is already running, and none of them do - a stream in flight keeps the settings it started with, because the agents receiving it have already joined a group on a port and agreed a datagram layout. Re-pointing a live stream would desync every one of them and corrupt the image they are assembling.

On a relay the same table applies, one sync later: the relay writes the new rows, its applier carries them into the running config, and a stream already in flight there keeps the group, port, chunk size, rate and TTL it started with.

A session whose clients have all gone stops. Every agent that times out and falls back to HTTP tells the server it has left. When the last one does, the send ends instead of pushing the rest of the WIM at the configured rate to a group nobody is listening on - and the session slot is freed for a transfer that has someone waiting. The server log says so, and names the likely cause (a VLAN not forwarding the group).

Accepted values: the group address must be an IPv4 address in the multicast range 224.0.0.0 - 239.255.255.255 (239.x.x.x is the administratively-scoped range and the usual choice); base port 1024-65535; send rate 1-1000 MB/s; max sessions 1-16; chunk size 512-65000 bytes; TTL 1-255. A value outside those bounds is refused rather than quietly clamped, so the page never shows a number the server is not using.

Access Control#

• Admin - Full access to all tiles
• Operator - Tiles that touch security, licensing, users, notifications, or backup are hidden
• ReadOnly - All tiles visible, but every form is wrapped in <fieldset disabled>; action buttons are hidden and a "Read Only" banner is shown

What each role can do:

An Operator can author task steps, and task steps run as SYSTEM on every machine a recipe deploys - including after the answer file (with the domain-join and local Administrator passwords) is on the disk. Treat the Operator role as local administrator of the fleet. See Authentication.

Users signing in through SAML SSO are mapped onto these same roles: anyone matching the configured Admin Groups / Roles gets Admin, and everyone else gets the Default Role on the same tab - Read Only out of the box, and settable to Operator or Admin if that is what you want for every unmapped account. The mapping is re-applied at every sign-in, so the IdP decides the role. See Authentication.

Changes made by any role are recorded in the Audit Log.