An Ignition 8.1.28 gateway on Windows 11 was upgraded in place to 8.3.0 with all installer defaults. The new gateway then asked for a login before it would restart the trial, and the admin password that worked on 8.1 was rejected. The same failure appeared in a second case: an 8.1.48 gateway backup from Windows Server 2022 was restored manually into an 8.3.0-beta 2 Docker container running under WSL on a Windows 11 VM. In both cases the gateway command-line utility (gwcmd) reset the system login and restored access. The restore case did not reproduce on 8.3.0-RC1.
Where does the trial-reset login request stop after an 8.1-to-8.3 upgrade?
Trace the request one hop at a time:
- Browser to gateway web server. The operator clicks the trial restart in the 8.3 gateway web UI. The HTTP request reaches the gateway, so the network path and the web port are working. The gateway answers with a login challenge.
- Gateway to System Identity Provider. Restarting the trial is a privileged gateway action. The gateway sends the login attempt to whichever identity provider is assigned as the system (gateway) login provider. In 8.1 this job belonged to the system user source in the gateway settings. In 8.3 the System Identity Provider does it.
-
Identity provider to user source. An Ignition-type identity provider passes the credentials to its backing user source. That can be the internal source, or an Active Directory source such as
adeasy. - Where it stops. The request fails at hop 2 or 3. Either the System Identity Provider is not bound to the user source that holds the old admin account, or the migration produced a provider that does not authenticate against that source. The browser shows a login failure. The request never reaches the trial-reset handler.
This is an authentication-layer failure, not a licensing or network fault. The trial itself is fine. What the gateway lacks is a credential path that grants the admin role. In the AD case, the adeasy user source came through the restore and appeared in the configuration, but gateway login still failed. The data carried over; the binding between the gateway login and that provider did not.
Was the 8.3 gateway upgraded, restored, or freshly installed?
How the gateway reached 8.3 tells you which credentials it should accept. The installer does not create a separate side-by-side install when it finds an existing gateway. Pointing the 8.3 installer at a machine running 8.1.28 is an in-place upgrade, and the 8.1 configuration, including the gateway login, is supposed to carry through.
| Path to 8.3 | Commissioning prompt for admin password? | Expected gateway login |
|---|---|---|
| Fresh install, no prior gateway | Yes. You set the admin credentials during commissioning. | Credentials entered at commissioning |
| Installer run over an existing 8.1 install (defaults accepted) | No | Same login as the 8.1 gateway |
Gateway backup (.gwbk) restored onto 8.3 |
No, because the backup supplies the configuration | Same login as the gateway that produced the backup |
If you never saw a commissioning screen asking for a password, the gateway did not start from a blank configuration. It either upgraded an existing install or restored a backup, which can be an old local install you have forgotten about. In either case the 8.1 credentials are the first thing to try. If they fail, the migration dropped the system login binding.
Which symptoms map to which cause?
| Symptom | Likely cause | Deciding check |
|---|---|---|
| No commissioning screen after install; 8.1 admin password rejected | In-place upgrade did not carry the System Identity Provider / user source binding | Confirm an 8.1 install existed on the host before running the 8.3 installer |
8.1 admin password rejected after manual .gwbk restore into 8.3 beta |
Pre-release migration defect in identity provider handling. Several AD user source issues were fixed after beta 2. | Repeat the restore on the latest 8.3 build and retest the login |
| AD user source visible in config, gateway login still fails | User source migrated; the gateway system login did not | Check which identity provider the gateway uses for its own login |
| Wrapper log shows nothing abnormal after restore | Authentication binding problem, which does not raise an error at startup | Log shows no clue; test the login directly |
| Backup filename field goes blank in the restore dialog | Known UI display defect. The component keeps the selected file. | Cosmetic only; continue the restore |
| Gateway fails to come back up after a restore on RC1 | Unrelated to the blank filename field | Restart the gateway with gwcmd and recheck |
Which recovery path fits: old credentials, gwcmd reset, or re-restore on a newer build?
Three approaches are available. They answer different needs.
| Approach | What it restores | Time to access | Keeps AD/identity config intact | When to use |
|---|---|---|---|---|
| A. Log in with the 8.1 credentials | Access only, if the binding survived | Immediate | Yes | Always try first |
B. Reset the system login with gwcmd
|
Gateway admin access | Minutes | Other providers and user sources stay in the config; the system login is replaced | Credentials rejected and you need the gateway now |
C. Restore the pre-upgrade .gwbk onto the latest 8.3 build |
Full migrated config, including the system login binding if the newer build fixes it | Longer; needs a clean target gateway | Yes, if the migration succeeds | Sandbox or migration testing where the migrated identity config itself has to be proven |
Recommendation: Use B to get into the gateway and restart the trial. Then use C on the current 8.3 release whenever the migrated identity configuration matters, which covers any AD-backed gateway you plan to promote beyond a sandbox. The gwcmd reset uses the same procedure as on 8.1, and it restored access in both the upgrade and the container-restore cases. In the container case, re-restoring the 8.1.48 backup onto 8.3.0-RC1 brought the gateway login through correctly, with no reset needed.
How do you reset the gateway system login with gwcmd?
The Gateway Command-line Utility ships with the gateway. Its commands can reset the main gateway password, change the gateway web port, and restart the gateway. The utility runs locally on the gateway host and talks to the installation directly, not through the web UI. That is why it still works when the authentication hop is broken.
- Open a shell on the gateway host with administrator rights. On Windows, open an elevated command prompt in the Ignition installation directory. For a Docker gateway, open a shell inside the running container with
docker execand change to the Ignition install directory in the container. - Run
gwcmdwith its help option to list the available flags. Identify the password-reset command for your installed version. Read it from the help output rather than from memory, because flag names can change between major versions. - Run the password-reset command.
- Restart the gateway, either with the
gwcmdrestart command or with the Windows service or container restart, so the reset takes effect. - Browse to the gateway web UI. Enter the new admin credentials when the gateway prompts for them.
- Log in with the new credentials and restart the trial from the gateway page that requested the login.
The reset replaces only the gateway system login. It does not touch device connections, tags, projects, or other user sources. Other identity providers, such as an AD-backed Ignition provider, stay in the configuration and remain available to projects.
What changes when the 8.1 backup is restored into an 8.3 container?
The container restore failed the same way, but the physical and host layers differed. The source gateway was 8.1.48 on Windows Server 2022. The target was the 8.3.0-beta 2 Docker image on WSL inside a Windows 11 VM. The restore was run manually through the gateway web UI, not through the compose file at container creation. The identity provider was Ignition-type, backed by the AD user source adeasy.
Watch for the following during a manual restore:
-
Blank filename after selection. After you pick the
.gwbk, the filename text disappears from the restore dialog. The component still holds the file, and the restore proceeds. Do not re-select the file in a loop. -
Gateway does not come back after restore. On RC1 one restore left the gateway stopped. A restart through
gwcmdbrought it up with the restored configuration. The same backup restored without this problem on beta 2, so the blank filename field did not cause the failure. - Wrapper logs. Collect the wrapper log from immediately after the restore. In the failing beta 2 case the log showed nothing unusual. A clean log therefore does not clear the identity migration, and you have to test the login itself.
- Build level. Beta 2 was followed by several releases before RC1, including fixes for AD user source issues. Test on the newest 8.3 build before you open a defect or rebuild identity configuration by hand.
If the login binding still drops on a current build, keep the exact .gwbk you restored and the post-restore wrapper log. Send both to Inductive Automation support. The vendor could not reproduce the upgrade case from an older backup and specifically needs the backup taken immediately before the upgrade.
How do you prepare an 8.1 gateway so the 8.3 upgrade is recoverable?
- Take a fresh gateway backup (
.gwbk) from the 8.1 gateway immediately before you run the 8.3 installer. An older backup can hide the configuration state that triggers the failure. - Record which user source or provider the 8.1 gateway uses for its own system login. Also record one admin account in that source that you can test with, whether internal or AD.
- Confirm you have local shell access to the host or container so you can run
gwcmdif the web login fails. - Use the latest 8.3 release as the upgrade or restore target, not an early pre-release build.
- For AD-backed gateways, run the migration on a sandbox gateway first by restoring the backup there. Upgrade production only after the sandbox login test passes.
How do you confirm the System Identity Provider migrated correctly?
- Log out of the gateway web UI. Log back in with the recorded 8.1 admin account, not the account created by the
gwcmdreset. If this succeeds on an upgraded or restored gateway, the system login binding migrated. - Open the gateway identity provider configuration. Confirm that the provider assigned to the gateway system login is the one you expect, and that its user source is the one the 8.1 gateway used, for example
adeasyfor the AD case. - For AD sources, log in with a domain account that holds the gateway admin role. This proves the full chain: gateway, then identity provider, then AD user source, then domain controller.
- Restart the trial and confirm the trial timer resets on the gateway status page.
- Restart the gateway service or container. Check the wrapper log for startup errors.
- Log in again with the migrated admin account to confirm the binding persists after a restart.
FAQ
Does upgrading Ignition 8.1 to 8.3 keep my gateway admin login?
It should. Running the 8.3 installer over an 8.1 install is an in-place upgrade, and the gateway login is expected to carry through. If the 8.1 admin password is rejected afterward, reset the system login with gwcmd, then verify which identity provider the gateway uses for its own login.
Can I restart the Ignition 8.3 trial without logging in to the gateway?
No. Restarting the trial is a privileged gateway action that requires an authenticated admin login. If you cannot log in, use gwcmd on the gateway host to reset the system login first, then restart the trial from the web UI.
Does the gwcmd password reset work the same in Ignition 8.3 as in 8.1?
Yes, the procedure is the same. Run gwcmd locally on the host or inside the container, check its help output for the password-reset command, restart the gateway, and set new admin credentials at the next browser login.
Can I run gwcmd inside an Ignition Docker container?
Yes. Open a shell in the running container with docker exec and run gwcmd from the Ignition install directory. After a restore on 8.3.0-RC1 left the gateway stopped, a gwcmd restart brought it back up.
Why does the backup filename disappear during an Ignition 8.3 restore?
It is a known UI display issue. The restore component still holds the selected .gwbk even though the filename text clears. Continue the restore, then confirm success by logging in with the migrated admin account after the gateway restarts.