# Keep agents up to date

You do not reinstall the Access agent to update it. Your server fetches new agent versions from IZT, and the agents update themselves.

## Where new versions come from

Your server checks with IZT for new agent versions every 10 minutes and keeps the newest build plus the one before it. You can see what it holds under **Instance** › **License** › **Agent builds**:

- The **Agent** table lists each build the server hands out, with its **Version**, the **Previous** version and whether it is **Licensed**.
- The pill shows **Updates on** or **Updates off**. When updates are off, the reason is shown under the heading.
- **Check now** asks IZT straight away instead of waiting for the next check. You need the instance permission **Settings** to open this tab.

On a server that cannot reach IZT, an instance owner brings new versions in with an offline bundle: enter the **Version**, download a **Bundle request**, upload it on the IZT license portal, then select **Import bundle** with the zip it returns.

:::note[Support tool]
The support tool is never installed, so it never needs updating: every download is the version your server holds at that moment.
:::

## How Access agents update

When an Access agent connects to your server and its version is older than the server's current build, the server sends it the update. The agent then:

1. Downloads the new version and checks it is signed by IZT, built for your server, and newer than the version it runs.
2. Checks that the new version starts and finds its settings.
3. Swaps it in and restarts the service.
4. Runs the new version on probation for 24 hours. If the new version keeps crashing or cannot reconnect, the agent rolls back to the previous version on its own.

If a remote terminal is open on the computer, the update waits until the terminals are closed, for at most two hours.

## Push an update now

1. Open **Access** in the console. Devices with a newer version available show an **update** pill next to their agent version.
2. Select the device.
3. Select **Update**. The console confirms that the update was pushed.

**Update** is available only while the device is online, is not revoked, and has an update available, and only if your role has the **Edit devices** permission for it.

## Update states

The device list and the device details (**Last update**) show how the latest update went:

| State | What it means |
|---|---|
| **Updating** | The update was sent; Blink is waiting for the result. |
| **Probation** | The new version is running. It rolls back on its own if it keeps crashing within 24 hours. |
| **Update failed** | This attempt failed, for example because the download failed. It is tried again later. |
| **Update rejected** | The agent refused the build, for example because its signature is not valid. The device will not try that build again. |
| **Rolled back** | The new version was removed and the previous one restored. Depending on the reason, it is tried again or not at all. |
| **Rollback failed** | The update failed and the previous version could not be restored. Check the device. |
| **Update skipped**, **Update waiting**, **Update not started** | The device did not start this update, for example because the build failed there before, it is waiting after failed attempts, or it was busy. |

Hover over the state to see the exact reason and when the update is tried again. A successful update shows no state: the new version simply appears as the device's agent version.

If an update keeps failing, check `C:\ProgramData\Blink\update.log` on the computer and see [Troubleshooting](/troubleshooting/).