The Server Room is where SysDesks keeps the infrastructure that sits behind the endpoints you support. It is not a diagram or a status page you read — it is a management console, organised as a tree in the same style as the rest of the workstation, and the devices in it have real state that endpoint tickets depend on. When a user's connectivity problem turns out not to be their machine, this is where the cause lives.
What is in the rack
- Switches — Ciscora Catalyx access switches, including the Catalyx 2960-X and the Catalyx 9200L, filed under Infrastructure then Switches.
- Routers — branch routers and SonicShield security gateways such as the TZ 370, TZ 470 and NSa 2700. Policies, interfaces, routing, VPN and QoS are managed in the firewall GUI.
- Devices — other network-attached hardware, including desk hardware such as the IP Phone 8841.
- Printers — the network printers on the estate, which open into their own console rather than a desktop.
Selecting any device shows its record: hostname, model, platform, serial, location, management IP and network IP, plus live health. Health is not decorative. A device reports a status such as Healthy or Ready alongside its temperature and uptime, and when something is wrong the console says so rather than leaving you to infer it from a failing endpoint three floors away. An unreachable device answers a management attempt the way real hardware does, with a request that simply times out.
Each class of device offers the management path you would actually use against it. A switch opens a console session over SSH. A router or firewall opens its HTTPS management GUI. Other devices open their own device GUI. You are choosing the access method a technician really has for that platform, not clicking a single generic Manage button that behaves the same everywhere.
Management sessions are authorised, and this is the part worth understanding before you get stuck. Opening a device to look at it is always allowed. Changing its configuration is not, unless the incident linked to that device is assigned to you. If it is not, the controls are disabled and the console tells you to assign the linked incident first, and an attempt to manage a device with no route to it returns a management session unavailable dialog instead of pretending to connect. The Server Room also links straight to the open incident for a device, so the assignment is one click away rather than a hunt through the queue.
The switch console is a genuine command line, not a menu with a terminal skin. It runs an IOS style session with privilege and configuration modes, so you enable, enter configure terminal, drop into an interface, VLAN, access list or line context, and exit back out again. Interfaces are named the way the platform names them, including GigabitEthernet and FastEthernet ports, and show commands return the output the hardware would return, down to the configuration size in bytes when you display the running configuration.
What the switch console accepts
- show — running configuration, interfaces, VLANs, access lists and the default route.
- interface, or int, to enter an interface context, then speed and duplex to change how a port negotiates.
- shutdown and no shutdown to administratively disable or re-enable a port.
- vlan to work with VLAN configuration, including the guest VLAN.
- write to save the running configuration, and enable, exit and end to move between modes.
Because these are the same simulated objects the rest of SysDesks reads, changes you make here are visible from the other direction. A port you administratively shut down is genuinely down for the workstation attached to it, and the user on that machine sees the symptom that follows. That is the reason the Server Room exists as a first class console rather than a page of read only facts: an incident can begin at an endpoint, be diagnosed from the endpoint, and be resolved here, which is exactly the shape of a real escalation.
There is also a Network Lab alongside the Server Room. It is a smaller, more direct tool: it lists the nodes in the topology with their type, address and status, and it lets you inject a fault such as a DHCP service outage and then clear it again. It is there so you can watch a specific infrastructure failure appear at a workstation and understand the connection, rather than waiting for a ticket that happens to contain that fault.