Productivity Web Server: Blank Login Is Normal, Not a Fault

Productivity Web Server access remains available while the Psuite GUI is connected. A login page with no configured user credentials is also normal: leave both credential fields empty and select Login. Do not start by disconnecting Psuite, creating an unnecessary account, or repeatedly changing browsers. First separate the expected blank-login workflow from browser session state and the web server's one-connection behavior.

Accept the blank login page

The usual wrong fix is to treat the login page as proof that authentication was configured. That leads to guessed passwords, unnecessary configuration changes, and more downtime. The CPU can display the login page even when no login is configured.

1. Open the CPU web server address.
2. Leave the username and password fields empty.
3. Select Login.
4. Wait for the home page before opening another browser or device.

Entering no credentials and selecting Login is the correct access sequence for this condition. If an empty submission does not immediately advance, close competing browser sessions and repeat the test once from a clean browser session. The check passes when the home page opens without a username or password.

Leave Psuite connected while testing

Do not disconnect the Psuite GUI as the first response. Psuite and the CPU web server can be accessed at the same time. The statement in help topic P248 that only one web connection may access the server does not mean that an active Psuite connection blocks browser access.

Keep Psuite connected, open one fresh browser session, submit the empty login, and confirm that the home page loads. That proves the engineering GUI connection is not the blocker.

Clear remembered browser state

The browser may remember a previous web login and open the home page directly. Logging out can make the login page appear on the next access, while clearing cached site state or using a private window can produce a different result. This explains why disconnecting Psuite can appear to fix the problem even when the real change was browser state.

1. Log out from the CPU web interface if the page offers that action.
2. Close all tabs addressing the same CPU.
3. Open a private or incognito window and browse to the CPU again.
4. If required, clear the browser's stored data for that address rather than clearing unrelated browser data.
5. Leave the fields empty and select Login.

Firefox, Chrome, and Edge were all used during diagnosis, so changing browser brands alone is not a dependable fix. A private window is useful because it isolates remembered session state; it does not prove that Psuite was consuming the web connection. The check passes when a repeatable clean-session test reaches the home page with Psuite still connected.

Test the one-connection rule correctly

A page remaining visible is not proof that its session is still active. In one test, a second browser connection displaced the first; the first browser showed the logout only after refresh. In another access path involving a VPN, several browsers and devices appeared to remain connected. Test active requests, not open tabs, because cached pages and network intermediaries can hide a session change.

1. Close every known browser session to the CPU.
2. Open browser A, complete the blank login, and confirm the home page responds.
3. Open browser B or a second device and complete the same login sequence.
4. Return to browser A and refresh a live page.
5. Record whether browser A remains on the home page or returns to the login page.

If browser A returns to login after browser B connects, operate the server as a single-active-browser interface. If both still respond, record whether the path is local or through a VPN and avoid treating the result as proof that unlimited sessions are supported. The check passes only after each browser has issued a fresh request following the second connection.

Restore access in a controlled order

Restore production with one browser, one known route, and no saved session. Adding devices while diagnosing creates competing state and makes a working server look intermittent.

1. Confirm that the CPU address is reachable through the intended local or VPN route.
2. Keep Psuite connected so the actual maintenance condition remains under test.
3. Close other web sessions to the CPU.
4. Start a private browser window.
5. Open the web server, leave both credential fields empty, and select Login.
6. Navigate to a second page and refresh it to prove the session is active.
7. Exit through the web interface's logout action when finished.

Do not repeatedly click Login with empty fields if the interface stops responding; restart the test from a clean session instead. The check passes when navigation and refresh work without disconnecting Psuite or supplying credentials.

Verify the complete maintenance path

Run the final test through the same network path and device the night shift will use. A local test does not validate a VPN route, and a page loaded from browser state does not validate a current CPU response.

1. Connect Psuite to the CPU and confirm normal GUI communication.
2. Open a clean browser session over the required network path.
3. Confirm that the login page may appear with no login configured.
4. Submit empty credentials and open the home page.
5. Navigate and refresh to prove live access.
6. Open a second browser only if session-limit behavior must be documented, then refresh the first browser.
7. Log out, reconnect, and repeat the empty-login sequence once.

Record whether a second browser displaces the first, whether the test used a VPN, and whether private browsing changed the result. The end-to-end check passes when Psuite and one active web session operate together and a clean reconnection follows the same blank-login workflow.

FAQ