**Environment**
- NetXMS Server version: 6.2.1 (Build 6.2-514-g2e01d869eb)
- Platform: Windows (server installer: netxms-server-6.2.1-x64.exe)
- Database backend: SQLite
- Install type: fresh install, Compact install type, SQLite selected as database type during setup
**Summary**
On a completely fresh install with SQLite as the database backend, `nxdbmgr init` reports "Database initialized successfully" and generates an admin password as expected, but the mandatory Default zone object (ID 4) is never actually written to either the `zones` or `object_properties` tables. This causes the server to log the following error on every startup:
*E* [obj.init] NetObj::loadCommonProperties() failed for Zone object Default [4]
**Reproduction steps**
1. Run netxms-server-6.2.1-x64.exe on Windows, choose Compact install type
2. On the "Initialize Database" screen, select Database type: SQLite, provide a valid path to database file (e.g. C:\ProgramData\NetXMS\netxms.db). Note: an initial installer attempt with an invalid database path (folder only, no filename) failed as expected with a clear "unable to open database file" error — this is unrelated to the bug below, which was confirmed independently on a subsequent clean init using a fully valid file path.
3. Complete the installer
4. Run `nxdbmgr.exe init` manually (in my case this was a clean re-init after deleting the .db file; behavior is identical to the installer's own init)
5. Start the NetXMSCore service
6. Inspect C:\NetXMS\log\netxmsd.log — the zone load error appears on every single startup, including immediately after a fresh, successful init
**Verification**
Ran the following queries directly against the fresh SQLite database via `nxdbmgr -o batch`:
SELECT * FROM zones WHERE id=4;
SELECT * FROM object_properties WHERE object_id=4;
Both return zero rows. `nxdbmgr check` reports no errors ("Zone object properties [PASSED]"), suggesting the checker validates referential integrity of existing rows rather than confirming that mandatory well-known objects (like the Default zone) exist at all.
**Impact**
Because the Default zone object is malformed/missing, the Network Discovery "Scan" action (triggered from the Management Console, for both manually-scanned subnets and scheduled active discovery) silently fails — the client-side confirmation dialog fires normally, but nothing is logged server-side and no discovery activity occurs. No error is surfaced to the user in the console.
**What I've tried**
- Full clean reboot of the host — error persists identically
- Complete deletion and reinitialization of the SQLite database file — error persists identically on the fresh init
- `nxdbmgr check` — reports no errors
This looks like a genuine defect in how `nxdbmgr init` seeds the SQLite database on Windows, rather than an environmental or user-configuration issue, since it reproduces identically on a from-scratch database. Possibly related to NX-2867 ("Disable 'Create database and database user before initialization' if SQLite selected in Windows installer"), though I can't confirm that's the same root cause.
- NetXMS Server version: 6.2.1 (Build 6.2-514-g2e01d869eb)
- Platform: Windows (server installer: netxms-server-6.2.1-x64.exe)
- Database backend: SQLite
- Install type: fresh install, Compact install type, SQLite selected as database type during setup
**Summary**
On a completely fresh install with SQLite as the database backend, `nxdbmgr init` reports "Database initialized successfully" and generates an admin password as expected, but the mandatory Default zone object (ID 4) is never actually written to either the `zones` or `object_properties` tables. This causes the server to log the following error on every startup:
*E* [obj.init] NetObj::loadCommonProperties() failed for Zone object Default [4]
**Reproduction steps**
1. Run netxms-server-6.2.1-x64.exe on Windows, choose Compact install type
2. On the "Initialize Database" screen, select Database type: SQLite, provide a valid path to database file (e.g. C:\ProgramData\NetXMS\netxms.db). Note: an initial installer attempt with an invalid database path (folder only, no filename) failed as expected with a clear "unable to open database file" error — this is unrelated to the bug below, which was confirmed independently on a subsequent clean init using a fully valid file path.
3. Complete the installer
4. Run `nxdbmgr.exe init` manually (in my case this was a clean re-init after deleting the .db file; behavior is identical to the installer's own init)
5. Start the NetXMSCore service
6. Inspect C:\NetXMS\log\netxmsd.log — the zone load error appears on every single startup, including immediately after a fresh, successful init
**Verification**
Ran the following queries directly against the fresh SQLite database via `nxdbmgr -o batch`:
SELECT * FROM zones WHERE id=4;
SELECT * FROM object_properties WHERE object_id=4;
Both return zero rows. `nxdbmgr check` reports no errors ("Zone object properties [PASSED]"), suggesting the checker validates referential integrity of existing rows rather than confirming that mandatory well-known objects (like the Default zone) exist at all.
**Impact**
Because the Default zone object is malformed/missing, the Network Discovery "Scan" action (triggered from the Management Console, for both manually-scanned subnets and scheduled active discovery) silently fails — the client-side confirmation dialog fires normally, but nothing is logged server-side and no discovery activity occurs. No error is surfaced to the user in the console.
**What I've tried**
- Full clean reboot of the host — error persists identically
- Complete deletion and reinitialization of the SQLite database file — error persists identically on the fresh init
- `nxdbmgr check` — reports no errors
This looks like a genuine defect in how `nxdbmgr init` seeds the SQLite database on Windows, rather than an environmental or user-configuration issue, since it reproduces identically on a from-scratch database. Possibly related to NX-2867 ("Disable 'Create database and database user before initialization' if SQLite selected in Windows installer"), though I can't confirm that's the same root cause.