Editing Category:NFC (section)

==Training on NFC Project KT PART 2. Dated 16 Nov 2024 - Tetra Support Staff - Raviraj==

{{#ev:youtube|Sf4Kg1HejQw|640}}

'''Video summary:''' "RAVIRAJ NFC KT 2" -- continues the NFC KT series with a support/operations-focused walkthrough. Covers the two Zimbra webmail clients NFC users may be on (Classic and Modern) and why it matters to ask which one a caller is using before troubleshooting; per-site public-circular distribution lists (Hyderabad, Kota, JTC); a two-tier attachment policy enforced via mail transport groups -- "Group One Transport" permits attachments, "Group Two Transport" (assigned by officer designation) does not -- plus separate sender restrictions that limit some users to internal-only mail. Describes the KVM-virtualized server layout per site (each physical/base machine hosts a paired mailbox/MTA/LDAP/proxy set) and the failover model: connectivity or load issues trigger automatic cluster failover to the secondary node, but a mailbox-specific problem requires a manual cluster shift; console access via the KVM host's URL is the fallback when SSH/PuTTY access fails, and if even the console doesn't respond the VM must be power-cycled. Notes an important operating constraint: NFC (a central government client) does not permit any remote login access to their environment -- support is done by walking NFC staff through fixes verbally on calls rather than connecting directly. Covers day-to-day troubleshooting patterns: slow mail delivery caused by a full mailbox quota; users' archive mount getting incorrectly pointed at another site's archive server (checked/fixed via `zmmailbox` commands to unmount and remount correctly); the full outside-to-inside mail path (KSMG -> IMSVA -> Postfix -> MTA -> mailbox) and where to check first when external mail isn't arriving, including manually releasing genuine mail that IMSVA quarantines as unscanned/spam (safe to release, and released mail doesn't get re-quarantined); and daily DRBD replication-status checks required only at Kota and JTC (which use active-passive DRBD replication), since Hyderabad's mailbox setup is active-active and doesn't need this check.