Wonderware Archestra Client-Server: Resolving "Can't Find the Starting Page" Errors

Wonderware System Platform (Application Server and InTouch) provides distributed HMI/SCADA deployment across operator stations, engineering workstations, and supervisory servers. Two client deployment topologies are supported: Client With Project and Client Without Project. A common commissioning failure on the operator HMI is the runtime error "can't find the starting page" raised by WindowViewer at launch. This reference details the architecture, isolates the root causes, and provides a deterministic remediation sequence with verification steps.

Architecture Overview

Application Server Topology

Wonderware System Platform centralizes configuration in the Application Server (AppServer) and the Galaxy Repository. The Galaxy is the persistent configuration store; it contains the area hierarchy, attribute definitions, derived tags, scripts, alarm configurations, security assignments (including the numeric Access Level), and deployment targets. The Application Server engine reads the Galaxy and serves configuration to client nodes over the network.

The IDE (Integrated Development Environment, formerly Archestra IDE) is the engineering workstation tool used to author the Galaxy, configure areas, deploy to nodes, and export data packages. WindowMaker is the InTouch development surface for individual window (.wie) files, tags, and QuickScripts. WindowViewer is the InTouch runtime that loads the project (or a data package) and presents the operator interface.

Deployment Modes

The computer list on the Application Server enumerates which client nodes may establish a session. The decision of whether to register a client on that list is governed entirely by the deployment mode. Misalignment between the registered list and the actual mode is the single most frequent source of starting page failures.

Data Package

A data package is a snapshot of the server-side configuration exported from Application Server for consumption by a Client With Project. It contains window references, attribute bindings, derived tag definitions, alarm routing, and security descriptors relevant to the client. When the server-side Galaxy changes, the data package must be regenerated and re-imported on every client. Stale packages produce runtime resolution failures when the client attempts to find a window or attribute that has since been renamed, moved, or deleted on the server.

Problem Details

Reported Symptom

On client launch, WindowViewer returns the error "can't find the starting page". The error persists even when the operator selects a different page through WindowViewer command-line overrides or by editing the project shell. The failure is reproducible at every boot until the underlying deployment mismatch is corrected.

Affected Environment

• Wonderware System Platform with Application Server deployed on Windows Server 2003 SP1/SP2 (a supported host of the era)
• InTouch WindowViewer runtime used for operator HMI
• Mixed Client With Project deployments across multiple operator stations
• Domain environments where Group Policy applies restrictive default ACLs (Access Control Lists) to user profile folders

Variations of the Symptom

Root Cause Analysis

Cause 1: Topology Mismatch on the Computer List

The most common cause. The client is configured as Client With Project (it has its own WindowMaker project) but its computer name has also been added to the server's computer list. The server then attempts to push its own starting page to a client that has a different project root. The client's local project cannot resolve the page reference and WindowViewer reports the error.

Decision path: If the client maintains any local configuration, custom windows, or QuickScripts beyond what is contained in the imported data package, the deployment is Client With Project. In that case the client name must be removed from the server computer list. If the client runs strictly the exported deployment with no local authoring, the deployment is Client Without Project and the client name must remain on the list.

Cause 2: Stale Data Package

The server-side Galaxy was modified after the most recent data package was exported. The package contains a reference to a window that no longer exists under that name, or it references an area the client has not yet been granted access to. When WindowViewer attempts to load the configured starting page from the package metadata, the resolution fails.

Cause 3: Insufficient Access Level

The Wonderware security model assigns numeric Access Levels to user accounts in the Galaxy. Level 1000 is administrative (full configuration authority). Level 1001 is the standard operator level (runtime control only). Lower numeric levels are more restrictive; higher levels are less common. A user without either level assigned cannot authenticate against the Application Server, and the deployment fetch fails during page resolution. Levels are not inherited: a user with 1001 does not automatically gain 1000 privileges; both must be granted explicitly if administrative actions are required.

Cause 4: DCOM Misconfiguration

Application Server relies on DCOM (Distributed Component Object Model) for inter-node object invocation. DCOM misconfiguration blocks the client from fetching starting page metadata. Failure modes include:

• DCOM disabled at the host level
• Default access permissions deny the runtime service account
• Default launch and activation permissions deny the service account
• TCP/IP not at the top of the DCOM protocol stack
• Authentication level set to None or to a level weaker than Connect
• Impersonation level set to Anonymous, preventing identity propagation

Cause 5: Folder Permission Drift After Migration

When a Wonderware project is copied between machines (backup restore, hardware refresh, virtualization migration), the destination's NTFS (New Technology File System, the Windows access-control file system) security template replaces inherited ACLs. The runtime service account that owned the source folder may not exist on the destination or may lack the equivalent rights. The project files become unreadable, and WindowViewer cannot resolve the starting page even when the package is valid.

Cause 6: Firewall and RPC Port Blockage (Windows Server 2003)

Windows Server 2003 ships with Windows Firewall enabled. Application Server requires DCOM and RPC traffic to traverse the host firewall. Blocking the endpoint mapper (TCP 135) or the dynamic RPC range (TCP 1024-65535 by default) prevents the client from establishing the DCOM session that is prerequisite to fetching the starting page.

Solution Procedure

Prerequisites

• Domain administrator or local administrator credentials on the server and client nodes
• Application Server IDE installed on the engineering workstation
• Galaxy Database access to verify user assignments
• Network connectivity between server and client on TCP 135 and the configured dynamic RPC range
• The original .apb (Application Server package) export or the ability to regenerate it

Step 1: Confirm Deployment Mode and Clean the Computer List

On the Application Server IDE, navigate to the deployment node for each client station and verify the Mode property.

1. Open the IDE and connect to the Application Server Galaxy.
2. Expand Deployment > [Site Name] > [Area Name].
3. Select the target client node and inspect its Mode attribute.
4. If the mode is Client With Project, remove the client computer name from the server's computer list.
5. If the mode is Client Without Project, confirm the client name is present on the list. Absence on the list will block the session outright.

Step 2: Verify and Assign Access Levels

Open the Galaxy Database through the System Management Console or the IDE and locate the operating user account.

1. Grant the runtime account at least level 1001 for operator HMI use.
2. Grant level 1000 if the account performs configuration or scripting changes.
3. Save the Galaxy and allow the change to propagate to the Application Server.

Step 3: Regenerate and Re-import the Data Package

1. On the engineering workstation, open the IDE.
2. Navigate to Deployment > [Site Name] > [Area Name].
3. Right-click the client node and select Export Data Package.
4. Save the .apb file to a network share accessible to the client.
5. On the client node, open WindowMaker against the local project.
6. Select Tools > Import > Wonderware Application Server Data Package and point to the exported .apb.
7. Confirm the imported starting page matches the server configuration.
8. Save the local project and exit WindowMaker.

Step 4: Reset Folder Permissions on Project Directories

For projects migrated between machines, perform an explicit ACL reset on both the server-side Galaxy directory and the client-side InTouch project directory.

1. Right-click the project root folder > Properties > Security tab.
2. Click Advanced > clear Allow inheritable permissions from the parent to propagate.
3. When prompted, choose Copy rather than Remove to retain existing explicit entries.
4. Add the runtime service account and grant Read & Execute, List Folder Contents, and Read.
5. Apply to This folder, subfolders, and files.
6. Repeat on every subdirectory that holds .wie, .wv, or Galaxy database files.

Step 5: Configure DCOM on Windows Server 2003

1. Open a command prompt and run dcomcnfg to launch Component Services.
2. Expand Component Services > Computers > My Computer.
3. Right-click My Computer > Properties.
4. On the Default Properties tab:
   • Set Enable Distributed COM on this computer = enabled.
   • Set Default Authentication Level = Connect.
   • Set Default Impersonation Level = Identify.
5. On the Default Protocols tab, ensure TCP/IP is at the top of the ordered list.
6. On the COM Security tab:
   • Access Permissions: Edit and grant the runtime service account Allow Local Access and Allow Remote Access.
   • Launch and Activation Permissions: Edit and grant the same account Allow Local Launch, Allow Remote Launch, Allow Local Activation, and Allow Remote Activation.
7. Navigate to DCOM Config, locate the Wonderware Application Server application, right-click > Properties > Security tab, and apply identical permissions in the Launch and Activation Permissions and Access Permissions sections, selecting Customize rather than Use Default.
8. Close Component Services and restart the Application Server service and the InTouch WindowViewer service.

Step 6: Open Firewall Exceptions for DCOM/RPC

On Windows Server 2003 hosts behind Windows Firewall, add exceptions for Application Server traffic:

• TCP 135 (DCOM endpoint mapper)
• TCP 1024-65535 (default dynamic RPC range; restrict where feasible via registry HKLM\SOFTWARE\Microsoft\Rpc\Internet ports)
• Any Application Server-specific port assignments from your deployment documentation

Verification

After the remediation sequence is complete, validate the deployment from both ends.

Server-Side Verification

1. From the IDE, confirm the target client node reports Connected status in the deployment view.
2. Confirm the Galaxy audit log shows successful authentication for the runtime account.
3. Confirm the data package export timestamp is later than the last server-side change to the affected area.

Client-Side Verification

1. Launch WindowViewer against the local project.
2. Confirm the configured starting page loads without error.
3. Confirm tag references show live values rather than #### placeholders.
4. Acknowledge an alarm to confirm bidirectional communication.
5. From the System Management Console, verify the client node has an active session against the Application Server.

Diagnostic Logging

For residual failures, capture a WindowViewer debug log:

The log records the missing page name, the data package timestamp, and the authentication result. Trace the page name back to the server-side window definition to confirm whether the resolution failure is in the package, the security model, or the project shell.

Troubleshooting Matrix

Edge Cases and Field Notes

Mixed Deployment Modes in a Single Plant

It is common to operate hybrid deployments: engineering stations as Client With Project (for local authoring and script development), and operator HMI stations as Client Without Project (for centralized change control). When commissioning a new operator station, register it on the server computer list before its first boot. Conversely, when commissioning an engineering station, confirm it is not on the server computer list.

Windows Server 2003 Specific Considerations

Windows Server 2003 SP1 and SP2 ship with Windows Firewall enabled by default. Application Server components require DCOM/RPC traffic to traverse the firewall. The default dynamic RPC range (TCP 1024-65535) is wide; restrict it through the RPC Endpoint Mapper configuration where security policy requires it. Service Pack 1 also tightened default DCOM authentication to Packet Privacy on some configurations, which can break Application Server if the client is not also patched to the same level. Verify SP parity across the server and client nodes.

Service Account Configuration

The Application Server engine and the InTouch WindowViewer service should run under a dedicated domain service account, not under the Local System account. Local System lacks network identity for DCOM authentication and cannot resolve remote Galaxy references. The service account must be a member of the local administrators group on every node where it runs, and it must possess explicit Log on as a service rights via Group Policy.

Project Migration Checklist

1. Document the source folder ACLs before copy.
2. Copy the project to the destination.
3. Reset inheritance and re-apply the documented ACLs.
4. Verify the service account can cd into the project directory from an interactive session.
5. Run WindowViewer in debug mode and confirm no file resolution errors.
6. Validate tag and alarm resolution against a live server.

Domain Trust and Authentication

In multi-domain environments, the Application Server host and the client node must reside in domains with a transitive trust relationship. Kerberos delegation must be configured if the service account needs to forward credentials to a back-end database server. NTLM-only fallback will work for Application Server internal authentication but may fail when the client attempts to reach a remote Galaxy on an untrusted domain.

Galaxy Database Storage Mode

The Galaxy may be stored either in the legacy Microsoft Access .mdb format or in a SQL Server database. The .mdb format is limited to a single writer and is sensitive to file-locking failures across the network. For deployments with more than a handful of client nodes, SQL Server hosting is recommended. Path resolution of the Galaxy on a remote SQL Server requires that the service account on the Application Server host has read/write rights on the SQL database, not just on the file system.

Diagnostic Commands

Related Configuration Touchpoints

Galaxy Security Configuration

Access levels are configured in the Galaxy under the security descriptor for each user. Group-based assignment is supported: a security group may be granted level 1000, and all members inherit the assignment through group membership rather than individual grants. This simplifies administration in large deployments but requires that the Application Server host can enumerate group membership against the domain controller.

Deployment Refresh Cycle

A disciplined deployment cycle prevents the stale-package failure mode. After every Galaxy change in the IDE, the engineering workstation exports a new data package and the package is propagated to all Client With Project nodes. A versioned package repository on a network share, with timestamps in the filename, provides an audit trail and supports rollback if a new package introduces regressions.

Backup and Restore Considerations

The Galaxy database must be backed up on a schedule consistent with the change rate of the configuration. For SQL Server-hosted Galaxies, native SQL backup with point-in-time recovery is recommended. For .mdb Galaxies, file-copy backup is acceptable only when the Application Server service is stopped; copying an open .mdb produces a corrupt snapshot. The backup procedure must capture both the Galaxy and the InTouch project directories; restoring one without the other produces starting page resolution errors at client launch.