**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.

Thanks for the detailed report.

The missing zone record is not what's breaking discovery. Object ID 4 is a built-in object: the server creates the Default zone in memory at every startup, and the code paths that use it (including active discovery) handle it correctly whether or not a row exists in zones / object_properties - the row only gets written once the zone is actually modified, e.g. when the first subnet is placed into it. So on a freshly initialized database the tables being empty is expected, and this is not specific to SQLite or to Windows.

The error message in the log is misleading, though, and the zone should be persisted at first startup instead of being re-created every time. I've opened https://github.com/netxms/netxms/issues/3410 for that.

For the discovery problem, which is a separate issue, please check the following:

1. Discovery type. In Server Configuration, check NetworkDiscovery.Type. If it is 0 (disabled), the "Scan" action will enqueue addresses but nothing will pick them up. For active scanning of configured ranges it must be 2 (active) or 3 (active and passive).

2. Enable discovery debug output. Either start the server with a higher debug level, or set it at runtime without a restart:

    nxadm -c "debug tag poll.discovery 6"

Then run the scan again and watch netxmsd.log. At level 6 you will see, per address, whether the host responded to the probe and - if it did - whether the potential node was rejected and why ("IP address already known at node ...", "rejected by discovery filter", etc.). Reset it afterwards with nxadm -c "debug tag poll.discovery off".

3. Probing method. By default active discovery only uses ICMP ping. If the target hosts do not answer ICMP, nothing will be found. Check NetworkDiscovery.ActiveDiscovery.EnableSNMPProbing and NetworkDiscovery.ActiveDiscovery.EnableTCPProbing, and make sure ICMP is not blocked between the server and the scanned range.

4. Discovery filter. If a filter script is configured, a responding host can still be dropped. The level 6 log above shows this explicitly.

5. Address ranges. Verify that the ranges under Network Discovery -> Active Discovery Targets are the ones you expect, and that they are IPv4 - IPv6 ranges are skipped by active discovery.

If you post the poll.discovery log from a scan run, I can tell you where it stops.