Before the server arrives, the room it serves has to be ready. Diskless workspaces put every operation that used to happen inside a machine onto the network instead — boot, application load, every read and write. A network that was perfectly adequate for ordinary desktops can become the reason a Synzo deployment feels slow.
Power
Give the server its own UPS. The server is a single point of failure for every station in the building. An unplanned shutdown mid-session risks corrupting the images that all of those stations depend on. A UPS sized for the server alone, with enough runtime for a clean shutdown, is not optional equipment.
Use redundant power supplies, and split them. If the server has two PSUs, connect them to separate battery banks within the UPS, or to two separate UPS units. Two power supplies plugged into the same outlet protect against a failed PSU but not against anything upstream of it.
Physical network
The network is where diskless performance is won or lost. Every machine in the workspace pulls its operating system across this path.
Server to switch: 10 Gb minimum. This link carries the combined traffic of the entire workspace. For larger deployments, move to 25 Gb or 40 Gb — see the tier table in Hardware Preparation.
Switch to switch: 10 Gb minimum. If your workspace uses more than one switch, the link between them carries just as much aggregate traffic as the server link. A 1 Gb uplink between switches will bottleneck every machine behind the second switch, and it is an easy thing to overlook.
Machine to switch: 1 Gb minimum. Each station needs a full gigabit connection.
Use SFP+ or better on the server side. Avoid running the server on ordinary 1 Gb ports outside of testing. It will work, and boot times and application loads will be noticeably slower — often slow enough that people conclude the software is at fault.
Network configuration
Keep the server and the machines on the same network segment where possible. This is the simplest configuration and the fastest. Synzo supports operation across multiple subnets when your layout requires it, but same-segment is the default recommendation.
DHCP: choose one mode
Synzo Console can handle DHCP for the workspace itself, or work alongside a DHCP server you already run. Both are supported. Decide which before installation, because the switch and firewall preparation differs.
Synzo DHCP — recommended. Synzo Console acts as the DHCP server for the workspace, assigning addresses and delivering boot instructions in a single response. This is the configuration we recommend for most deployments:
Address assignment and network boot are handled by one system, so there is nothing to keep in sync and no second server to misconfigure.
Boot is faster and more predictable, because machines are not waiting on two separate services to answer.
Troubleshooting is simpler. When something fails to boot, there is one place to look.
Address reservations, ranges, and machine identity all live in the same console you already use to manage the workspace.
Proxy DHCP. Synzo Console responds only to boot requests and leaves address assignment to your existing DHCP server. Choose this when your network policy requires DHCP to stay under central IT control, or when the workspace shares a segment with other systems that depend on the existing DHCP server.
This mode works reliably, but it depends on the other server being configured correctly and staying that way. Most of the boot problems reported in proxy deployments trace back to a change made on the DHCP server by someone who did not know the workspace depended on it.
Run one or the other, never both. If you enable Synzo DHCP, disable any other DHCP server on the same segment. Two DHCP servers answering the same requests produce address conflicts and intermittent boot failures that are difficult to diagnose.
Settings to disable
These interfere with network boot and should be turned off on the switches serving the workspace:
Flow control
DHCP options 60 and 66–68
DHCP snooping
Spanning Tree Protocol (optional, but a common cause of boot timeouts)
If STP cannot be disabled, enable PortFast — or your switch vendor's equivalent — on every access port connected to a machine or to the server. Without it, ports sit in listening and learning states long enough that machines fail to get an IP address before the boot attempt times out. This is one of the most common causes of intermittent boot failures, and it looks like a Synzo problem when it isn't.
OS licensing
Synzo does not provide or manage Windows or any other operating system licensing. Every machine booting from Synzo Console must be properly licensed, and ensuring compliance is your responsibility.
Recommended, not required
DHCP reservations. Assign IP addresses by MAC address. This prevents pool exhaustion in workspaces where machines cycle frequently, and it makes troubleshooting far easier — a station keeps the same address every time you look for it.
Public IP addressing. In esports and gaming deployments, assign a 1:1 public address to each machine. Some game launchers and platforms restrict multiple logins from a single public address, and shared NAT will cause account lockouts that appear unrelated to the network.