Lanview Architecture
Lanview uses a Server, Studio, Client and Agent model for managing Windows devices on a local network.
The architecture is designed so that Lanview Server stores management state and coordinates administration. Lanview Studio provides the administration interface, while Lanview Client and Lanview Agent provide managed device functionality.
Architecture overview
| Component | Role |
|---|---|
| Lanview Server | Stores and manages security, settings, device state, audit records, task state, repositories and communication with Clients. |
| Lanview Studio | Provides the Windows administration interface for Lanview users. |
| Lanview Client | Runs as a Windows service on managed devices and communicates with Lanview Server. |
| Lanview Agent | Runs in the logged-in user session where user session features are required. |
| Lanview AdminConsole | Provides local Server administration and recovery capabilities. |
Lanview Server
Lanview Server is the control point for the Lanview installation.
It is responsible for:
- Device records and approval state.
- Groups and device organisation.
- Security users, roles and permissions.
- Authentication and two-factor authentication policy.
- Server settings and policy metadata.
- Inventory records.
- Package and deployment state.
- Command routing to connected Clients.
- Audit records.
- Monitoring state.
- Server-side repositories and runtime data.
Lanview Server validates administration requests before they are carried out. It also records audit events for supported actions.
Lanview Studio
Lanview Studio is the main administration application.
Administrators use Studio to connect to Lanview Server, sign in, view devices, manage settings, perform support actions and review audit information.
Studio displays features based on the signed-in user’s effective permissions. Lanview Server still validates each request when an action is submitted.
Studio should be treated as an administration client, not as the owner of Lanview Server data.
Lanview Client
Lanview Client is installed on each managed Windows device.
It runs as a service and connects back to Lanview Server. The Client is responsible for device-side work such as reporting information, receiving authorised instructions, handling local task execution and supporting managed device operations.
The Client does not decide which administrators are allowed to perform Server-owned actions. Those decisions are made by Lanview Server.
Lanview Agent
Lanview Agent supports features that need access to the logged-in user session.
Examples include user visible messages, consent prompts and Lanview-native Remote View support. The Agent is not a separate administration authority and does not replace Server-side policy or permission checks.
Communication model
Lanview Client connects outbound to Lanview Server. Server can then send authorised instructions to the Client over that established connection.
Lanview Studio connects to the Lanview Server administration endpoint. It does not normally communicate directly with Lanview Client for Lanview-native management actions.
Microsoft Remote Desktop Protocol (RDP) is a separate exception because Remote Desktop uses the Windows RDP service on the target device.
State ownership
Lanview Server stores the main state for the installation.
This includes security configuration, device records, groups, settings, inventory, task state, package state and audit history.
Lanview Studio should manage Server state only through supported Lanview Server interfaces. Direct editing of Server-managed data is not a supported administration method.
Ports and services
Typical Lanview deployments use separate Server endpoints for Client communication and Studio administration.
The default Client connection port is 45750.
The default Studio administration port is 45751.
Your final deployment requirements may also depend on local firewall rules, service configuration and network design.
Policy and permissions
Lanview Server applies policy and permissions when administrative actions are requested.
Examples include:
- Whether a user can sign in to Lanview Studio.
- Which Studio modules are visible.
- Whether a user can approve devices.
- Whether a user can manage roles and permissions.
- Whether Remote View or Remote Control is allowed.
- Whether a reason is required before a sensitive action.
This model keeps access control consistent across Studio, AdminConsole and Server-handled command paths.