# App, Branch, Cloud Connector — enroll it, then prove it Source: https://ai.techclick.in/blog_zscaler_b11_10_zpa_connectors Markdown: https://ai.techclick.in/blog_zscaler_b11_10_zpa_connectors.md Publisher: Techclick Infosec Pvt Ltd Gold ZPA connector lesson: pick App vs Branch vs Cloud Connector, provision and enroll with a real key, design N+1 HA, and prove health — including what “no healthy connector” actually means. Quick answer (say this out loud) An App Connector is the only ZPA component that talks to the private app. It never listens inbound. You create an App Connector Group at one site (same latitude/longitude), mint a provisioning key bound to that group, write the key to /opt/zscaler/var/provision_key , and start zpa-connector . Zscaler recommends N+1 connectors in that group. No healthy connector is operator slang for session status NO_CONNECTOR_AVAILABLE — no eligible connector in the bound group. A green VM that cannot reach the server is a different code: APP_NOT_REACHABLE . Branch Connector and Cloud Connector are traffic-forwarding VMs (ZIA + ZPA), not a second name for the App Connector. ## 1. Why the connector is the product Lesson 9 taught the broker: Client Connector and App Connector both dial outbound to a Public or Private Service Edge. The edge stitches one microtunnel. The user never receives a subnet. This lesson is the box that makes that broker real. Policy, Application Segments, and Client Connector can all be perfect. If no App Connector in the assigned group is enrolled, enabled, and able to reach the server, the user still fails. Operators summarise that as “no healthy connector.” Hero · who talks to whom Notice: the App Connector sits next to the private app and dials the broker outbound. The app has no inbound VIP from the internet. Three different VMs share the word “connector.” Mixing them is the first production miss. #### App Connector ZPA-only. Sits next to the private server. Inside-out interface to the ZPA cloud. This is the box Jira needs. #### Branch Connector Branch or DC VM that forwards site traffic to ZIA and ZPA. Direct-to-cloud, full proxy. Not a second App Connector name. #### Cloud Connector Same idea as Branch Connector, but for public-cloud workloads (VPC / VNet). Registers with an API key + provisioning template. #### Combined image On VMware / Hyper-V / KVM, Zscaler ships a Branch Connector & App Connector image when a site must both forward and broker private apps. Interview line If someone says “we deployed a Cloud Connector so ZPA should work,” ask: is there an App Connector (or a combined Branch + App image) that can reach the application server? Cloud Connector forwards. App Connector brokers the private app. ## 2. Mental model — three VMs, one job each Memorise three objects before you open the Admin Console. Every “which appliance do I order?” conversation maps back to these. Flow 1 · three connectors, three jobs App Connector brokers private apps; Branch and Cloud Connectors forward site or cloud traffic - Pick the VM from the traffic, not from the word “connector” App Connector Sits next to Jira / RDP / DB ZPA only · outbound TLS Group + provisioning key N+1 at one lat/long Admin: Infrastructure → Private Access → Component Branch Connector Branch or DC site VM Forwards to ZIA + ZPA API key + template URL Can pair with App image Cloud & Branch Connector + ZPA Branch Connector Groups Cloud Connector AWS / Azure / GCP VPC Workload → ZIA + ZPA Provisioning template VM Size Small / Med / Large Infrastructure → Connectors → Cloud → Provisioning User Jira ticket → App Connector in the Server Group’s App Connector Group Site internet / SaaS ticket → Branch Connector (or GRE/IPSec + ZCC) Workload in a VPC with no user on the box → Cloud Connector Read left → right. App Connector is the ZPA broker next to the app. Branch and Cloud Connector are forwarding VMs. A site can run a combined Branch + App image. ### Hard words, before the runbook Term What it actually is App Connector Group The HA and path-selection unit. Every App Connector belongs to one group. Zscaler requires the same geographic location (latitude and longitude) for members of a group. Provisioning key A text string that enrolls an App Connector. It is a credential, and it is bound to one App Connector Group. The cloud uses it to place the VM in that group. OAuth 2.0 enrollment token The preferred enrollment method in current Help. Provisioning keys remain the classic path this lesson walks. Enrollment The VM presents the key (or token), receives a certificate signed by the Signing Certificate (enrollment CA), and appears on App Connectors . Health reporting The App Connector probes the application and reports Up or Down . Connector-to-cloud green + app Down is not “healthy for Jira.” NO_CONNECTOR_AVAILABLE Official Private Access session status. The Central Authority cannot resolve an App Connector for the user. App Connector ID shows as zero in diagnostics. APP_NOT_REACHABLE Different status. App Connectors exist for the application, but none of them can reach the server. Say this out loud The group is the unit of HA and of path selection. The key belongs to the group, not to the VM. Health has two layers: the connector can reach ZPA, and the connector can reach the app. ## 3. Decision flow — which connector, then enroll Flowchart first. Do not start by downloading an image. Flow 2 · choose, then enroll Decision flow from traffic type to connector type and enrollment What traffic must this VM handle? User → one private app? Jira, RDP, DB, SMB yes no — site or VPC App Connector next to the server Public cloud VPC? or branch / DC? branch / DC VPC Branch Connector + App image if site apps Cloud Connector template + API key Then enroll: Group → key or token → VM file → service start → Admin Status A powered-on VM with no key is not a connector. It is a Linux box. Diamond = decision. App Connector if the job is brokering a private app. Branch or Cloud Connector if the job is forwarding a site or a VPC. Path · provision → enroll → health Notice the order: VM ready is step 1, not the finish. Health green is after the key is consumed and mTLS enrollment succeeds. ## 4. How to choose Use the table in the design review. Do not order three SKUs “just in case.” App Connector Branch Connector Cloud Connector Job Broker one private app (ZPA) Forward branch/DC traffic to ZIA + ZPA Forward public-cloud workload traffic to ZIA + ZPA Where it lives Same L3 reachability as the server Branch or data-centre edge VPC / VNet (AWS, Azure, GCP) Enrollment Provisioning key or OAuth 2.0 token, bound to an App Connector Group API key + Branch Connector provisioning URL / template API key + Cloud Connector provisioning template Admin (current console) Infrastructure → Private Access → Component → App Connector Groups / Keys / App Connectors Infrastructure → Private Access → Component → Branch Connector Groups, plus Cloud & Branch Connector help Infrastructure → Connectors → Cloud → Provisioning HA unit N+1 App Connectors in one group, same lat/long HA pair / failover on the forwarding VM (see Cloud & Branch Connector HA) Template VM Size + Auto Scaling; pair with ZPA Cloud Connector Groups Pick this when Users (or Browser Access) must reach an internal FQDN/port The site should go direct-to-cloud instead of GRE/IPSec + local stack Workloads in a VPC need ZIA/ZPA without a user Client Connector on the server Do not pick this when You only need internet/SaaS forwarding You only need to broker one app and already have ZCC + GRE/IPSec You think “cloud” means “our App Connector in AWS” — that is still an App Connector Common miss An App Connector deployed in AWS is still an App Connector . It uses the App Connector image, group, and provisioning key. A Cloud Connector is a different product with a provisioning template and an API key from Administration → API Configuration → Legacy API → Cloud & Branch Connector API . ## 5. Runbook — Side A VM, Side B provision, Side C proof Primary source for Side A: App Connector Deployment Prerequisites plus the platform guide for your hypervisor or cloud. Primary source for Side B: Configuring App Connector Groups and Configuring App Connector Provisioning Keys . Primary source for Side C: Managing Deployed Software Components and Understanding Private Access Session Status Codes . Older ZPA-only portals still show Configuration & Control → Private Infrastructure → App Connector Management . Teach the current unified path below; if your tenant still has the legacy labels, the object names (App Connector Groups, App Connector Keys, App Connectors) are the same. ### Side A — VM and network prereqs Do this on the compute and firewall tickets before anyone pastes a key. #### Place the VM where the app lives The App Connector must reach the application on the ports in the Application Segment (TCP/UDP as configured). It must also egress to Zscaler Service Edges on TCP 443 . Official firewall language: allow egress on TCP, UDP, and ICMP. The App Connector does not need an inbound VIP from the internet. - #### Size from the current prerequisites page Platform deployment guides list a base of 4 GB RAM and 2 CPU cores (Xeon E5 class). For ZDX, Zscaler recommends 8 GB RAM (more if probe count is high). Confirm the live App Connector Deployment Prerequisites page for your image before you order hardware — do not freeze a 2022 blog as capacity planning. - #### Deploy the official image Use the App Connector image for that platform (VMware, AWS, Azure, GCP, Linux, Hyper-V, Nutanix, OpenShift). After first boot, Help notes it can take up to 15 minutes before the instance is ready to enroll. - #### Console login and time Default system-console account (Managing Deployed Software Components): username admin , password zscaler . Change it. NTP must be correct — if the App Connector clock disagrees with ZPA, certificate enrollment is delayed because the cert is not yet valid. - #### Prove two reaches from the VM, before the key From the App Connector: DNS + TCP to the application FQDN/port, and outbound 443 toward ZPA (no SSL inspection middlebox re-signing the Zscaler cert). A later “Active but Jira down” ticket is almost always this hop, not the key. HA on Side A Zscaler recommends deploying App Connectors in groups for high availability and horizontal scaling, and sizing groups for N+1 . Members of one group must share the same geographic location (latitude and longitude) so path selection works. Two data centres = two App Connector Groups. Do not “HA” Mumbai and Singapore in one group. ### Side B — ZPA Admin: group, then key, then enroll Order is fixed: group first , because the provisioning key must select a Group. admin.zscaler.com · Infrastructure → Private Access → Component → App Connector Groups Training mock · not live Infrastructure / Private Access / Component / App Connector Groups / Add ### Add App Connector Group Name DC1-MUM-AppConnectors Status Enabled Description Mumbai DC · Jira + fileserver · N+1 Location Mumbai, IN Location Coordinates · Latitude 19.0760 Location Coordinates · Longitude 72.8777 Persist Local Version Profile Disabled Update Settings · Version Profile Default Cancel Save Click next: Save the group, then open App Connector Keys → Add . Source: Configuring App Connector Groups — Status Enabled, Location used for path selection, Persist Local Version Profile and version profile on Update Settings. - #### Add the App Connector Group Infrastructure → Private Access → Component → App Connector Groups → Add . Set Status to Enabled . Fill Name , Description , Location , and Location Coordinates . Leave version-profile overrides alone unless you have a written upgrade window. Every group should later have at least one OAuth 2.0 enrollment token or provisioning key. - #### Add the provisioning key Infrastructure → Private Access → Component → App Connector Keys → Add (Help title: Add App Connector Provisioning Keys ). Current Help also supports OAuth 2.0 enrollment tokens as the preferred method — same idea, different credential. If you use a key, fill the documented fields below and copy the string once. admin.zscaler.com · Infrastructure → Private Access → Component → App Connector Keys Training mock · not live Infrastructure / Private Access / Component / App Connector Keys / Add ### Add App Connector Provisioning Key Name DC1-MUM-key-2026 Group DC1-MUM-AppConnectors Maximum Reuse of Provisioning Key 4 Signing Certificate Enrollment (CA) certificate View or Export Provisioning Key After Creation Enabled (default) Provisioning Key 1|enrollment.example.invalid|•••••••••••••••• · treat as a secret Cancel Save Click next: copy the key, then put it on the VM. Source: Configuring App Connector Provisioning Keys — Name (periods, hyphens, underscores only), Group, Maximum Reuse of Provisioning Key, Signing Certificate. The table later shows Maximum # of App Connectors and Provisioning Key Utilization Count. - #### Inject the key and start the service Official re-enroll / first-enroll sequence from Troubleshooting App Connectors (Linux systemd image): App Connector console · enroll sudo systemctl stop zpa-connector sudo rm /opt/zscaler/var/* sudo touch /opt/zscaler/var/provision_key sudo chmod 644 /opt/zscaler/var/provision_key # paste the key from Admin into that file, then: sudo systemctl start zpa-connector sudo systemctl status zpa-connector The service reads the key, enrolls under the App Connector Group bound to that key, and the VM should appear on App Connectors . Help: App Connectors you added but have not deployed are not listed — so an empty table usually means the key never landed, not that “Add App Connector” was skipped. - #### Bind the group to the app path The Server Group for the Application Segment must use this App Connector Group. A healthy connector in a different group does not serve Jira. That is the usual “green VM, users still fail” story after someone cloned a key from DC2. - #### Branch / Cloud Connector, if that is the ticket Cloud Connector: retrieve the API key from Administration → API Configuration → Legacy API → Cloud & Branch Connector API (API Key Management; Add Cloud Service API Key if none exists). Then Infrastructure → Connectors → Cloud → Provisioning → Add Cloud Connector Provisioning Template . Documented fields include Cloud Connector Group Creation (Automatic), VM Size (Small / Medium / Large), and Auto Scaling . Branch Connector: same API-key idea plus a Branch Connector provisioning URL / template on the VM. Combined Branch + App images exist on VMware, Hyper-V, and KVM when the site must both forward and broker. ### Side C — prove health (close the ticket) Green in one place is not proof. Collect three stamps. admin.zscaler.com · Infrastructure → Private Access → Component → App Connectors Training mock · not live Infrastructure / Private Access / Component / App Connectors ### App Connectors Name App Connector Group Status Last software update Connections mum-ac-01 DC1-MUM-AppConnectors Enabled Success Public Service Edge · up mum-ac-02 DC1-MUM-AppConnectors Enabled Success Public Service Edge · up mum-ac-03 DC1-MUM-AppConnectors Disconnected — filter: Connection Status Code = Disconnected Click next: open the connector, confirm the group, then Logs → Insights → Diagnostics → Log Type: App Connector Status . Source: About App Connectors (Status enabled/disabled, last software update, connection/health) and Accessing App Connector Status Diagnostics. - #### Admin: the connector exists and is Enabled Infrastructure → Private Access → Component → App Connectors . Confirm Status is Enabled, the row is in the intended App Connector Group , and connections/health are up. Optional dashboard: Analytics → Switch to Existing Reports → Private Applications → App Connectors . - #### On-box: the service is running A healthy systemd App Connector answers sudo systemctl status zpa-connector as active. If you must re-enroll after an accidental delete in Admin, use the wipe + new key sequence from Side B — Help notes this class of failure often follows deleting the object while the VM is still up. - #### App health, not just connector health Health reporting is Up or Down from the App Connector’s view of the application. Connector-to-cloud up + application Down is APP_NOT_REACHABLE territory, not “ZPA is down.” - #### User session must not be NO_CONNECTOR_AVAILABLE Pilot the entitled user. In diagnostics, a NO_CONNECTOR_AVAILABLE (or operator “no healthy connector”) session shows App Connector ID as zero. That means the CA could not pick an eligible connector — wrong group, all members disconnected, group disabled, or connectors paused for upgrade. Fix the group membership and health, then re-test. A success session names a real App Connector, not zero. Green success = these fields - App Connectors page: two rows (N+1), same group, Status = Enabled , connections up. - sudo systemctl status zpa-connector active on both VMs. - Application health reporting Up for jira.lab.example:443. - Pilot user activity: session status is not NO_CONNECTOR_AVAILABLE or APP_NOT_REACHABLE ; App Connector ID is not zero. ## 6. Runtime path after go-live After enrollment, the VM is not “done.” This is the path a Monday ticket walks. Flow 3 · runtime, then the two failure codes Runtime path from user to app and the two connector failure codes User + ZCC outbound TLS - Service Edge policy + stitch App Connector Group pick a healthy member App Connector → server health Up / Down Eligible connector in the bound group? no yes NO_CONNECTOR_AVAILABLE ID = 0 · “no healthy connector” Connector selected now: can it reach the app? if not → APP_NOT_REACHABLE connectors exist; server is dark Read left → right, then down. “No healthy connector” is the left box. A green connector that cannot open Jira is the amber box. ### Application-level HA (optional second layer) Inside one site, N+1 members of one App Connector Group is the default HA. Across sites, Help documents Configuring Application Load Balancing and High Availability : mark Server Groups Passive so traffic uses App Connectors in the passive group only when the active side is unhealthy. Switch-back language in that article is a health-percentage check on the two groups (passive below half healthy and active above half healthy). Do not invent your own “primary/secondary” toggle on the VM. ## 7. Traps + proof Proof · close the ticket with a named field Notice: proof is a named field on a timestamp, not a screenshot of a spinning tab. What you see What it usually is What you do “No healthy connector” / NO_CONNECTOR_AVAILABLE / App Connector ID = 0 No eligible App Connector in the bound group (disconnected, disabled, wrong group, paused for upgrade, key never enrolled). App Connectors page + Diagnostics Log Type App Connector Status , filter Connection: Status Code Equals Disconnected . Fix membership, then re-pilot. Connector Enabled / last seen seconds ago, users still time out APP_NOT_REACHABLE — none of the configured App Connectors can reach the server (route, security group, DNS, wrong port). From the VM, connect to the app FQDN:port. Health reporting Down confirms this. Do not mint a new key yet. VM running, empty App Connectors table Key never consumed, wrong file path/permissions, or clock skew delaying the enrollment cert. Confirm /opt/zscaler/var/provision_key is mode 644, NTP is sane, restart zpa-connector . Help: undeployed connectors are not listed. Green connector in DC2, users of DC1 Jira fail Provisioning key (and therefore the VM) is bound to the wrong App Connector Group. The Group field on a key cannot be treated as a later edit for placement. Re-enroll with the DC1 key. Wipe /opt/zscaler/var/* first. All users fail during a software window App Connectors paused for upgrade ( AC / paused-state codes). Single-member group = outage. N+1 in the group. Stagger Upgrade Day / version-profile windows. Persist Local Version Profile only with a written exception. Cloud Connector “up,” private app still dark Wrong product. Cloud Connector forwarded the VPC; no App Connector can reach the server. Deploy or reuse an App Connector (or combined image) that can open the app port. Enrollment loops after an Admin delete Object deleted in the console; the VM still thinks it is enrolled. Official recover: stop service, wipe /opt/zscaler/var/* , write a new key, start service. Unsafe “fix” Opening inbound 443 to the App Connector, publishing the app on a public VIP, or dumping 10.0.0.0/8 into one Application Segment so “something is healthy.” The connector is outbound-only. Health is not restored by making the app a VPN again. Pilot checklist before you leave the change window Two App Connectors, one group, same Location Coordinates, both Enabled. - Provisioning Key Utilization Count increased; Maximum Reuse still has headroom. - On each VM: systemctl status zpa-connector active; VM can open the app port. - Application health reporting Up. - Pilot allow: session names this group’s connector (ID ≠ 0). - Negative test: stop one VM — second connector takes the session (N+1). Stop both — NO_CONNECTOR_AVAILABLE (proves the error string). - A user not in Access Policy is still denied (Enabled ≠ allow). ## Knowledge check Six judgment items. Map each miss to the section in the reason, then retry. Q1 Finance must reach jira.lab.example:443 in the Mumbai DC. Which VM actually opens that TCP port? Cloud Connector in the landing VPC — “cloud” means ZPA. An App Connector that has L3 reachability to the Jira server, enrolled in the App Connector Group bound to that Server Group. Any Branch Connector in the company, because Branch Connector includes ZPA. The Public Service Edge — it NATs inbound to Jira. Correct: b . Re-read Mental model and How to choose . App Connector is the only ZPA component that talks to the private server. Branch/Cloud Connector forward. The Service Edge never receives an inbound VIP on Jira. Q2 Users report “no healthy connector.” What is the official session status you look for, and what does it mean? APP_NOT_AVAILABLE — the Application Segment toggle is Enabled, so ZPA should work. APP_NOT_REACHABLE — always. The VM must be down. NO_CONNECTOR_AVAILABLE — the Central Authority could not resolve an eligible App Connector (ID = 0). A green VM in a different group does not count. There is no session status. Open inbound 443 on the connector so ZPA can health-check it. Correct: c . Re-read Runtime path and Traps . Operator slang “no healthy connector” maps to NO_CONNECTOR_AVAILABLE . APP_NOT_REACHABLE is the next diamond: connectors exist but cannot reach the server. Q3 How should you HA two App Connectors for one Mumbai application? Put both in one App Connector Group at the same latitude/longitude, and size the group N+1. Path selection assumes one location per group. Put one in Mumbai and one in Singapore in the same group so “geo HA” is automatic. Give each VM its own App Connector Group with the same provisioning key. Enable inbound VRRP on the App Connector management NIC. Correct: a . Re-read Side A HA . Leading Practices: connectors in a group share lat/long; groups are the HA and scale unit; size N+1. Two sites = two groups (and, if you need site failover, official active/passive Server Groups). Q4 Both App Connectors show Enabled and last seen 20 seconds ago. Health reporting for Jira is Down. Users time out. What is the most likely code and cause? NO_CONNECTOR_AVAILABLE — regenerate the provisioning key. Access Policy default-deny — Enabled on the connector is not an allow. ZPA Public Service Edges are globally down. APP_NOT_REACHABLE — the connectors can reach ZPA, but none of them can reach the Jira server (route, security group, DNS, or port). Correct: d . Re-read Side C and Traps . Enabled + last seen proves enrollment to the cloud. Health reporting Down / APP_NOT_REACHABLE is the local hop. Test from the VM before you touch keys or policy. Q5 You create a provisioning key in the Admin Console. What is the key bound to, and why does that matter on Friday night? The individual VM hostname. You can move the VM to any group later by renaming it. One App Connector Group (the Group field). The cloud places every enrollment that uses that key into that group. A DC2 key will not serve a DC1 Server Group. The Signing Certificate only. Group is cosmetic. The Maximum Reuse count. After that number the key changes groups automatically. Correct: b . Re-read Side B . Official: each key is associated with a specific App Connector Group so the cloud knows where to deploy the connector. Maximum Reuse only caps how many times the key can enroll. Q6 What set of evidence closes “the connector is healthy” for a change window? App Connectors page: Status Enabled in the right group; systemctl status zpa-connector active; application health Up; pilot session is not NO_CONNECTOR_AVAILABLE and App Connector ID is not zero. vSphere shows the VM powered on and ping answers on the management NIC. You pasted a key an hour ago, so enrollment must have worked. Zscaler Client Connector on your laptop is green for ZIA. Correct: a . Re-read Side C . Powered-on, ping, and “I pasted the key” are not enrollment. ZIA Client Connector health is a different product. Collect Admin + on-box + app health + a user session. Check answers Reset ## Sources - Zscaler Help — About App Connectors (Infrastructure → Private Access → Component → App Connectors; Status; health/connections; undeployed connectors are not listed) - Zscaler Help — Configuring App Connectors (Add; select an existing App Connector Group; OAuth enrollment vs provisioning key) - Zscaler Help — About App Connector Groups (groups for HA and scale; Location / Location Coordinates; Status; every connector belongs to one group) - Zscaler Help — Configuring App Connector Groups (Add path; Status Enabled; Persist Local Version Profile; Update Settings / version profile) - Zscaler Help — About App Connector Provisioning Keys (key is a credential bound to a group; Maximum # of App Connectors; Provisioning Key Utilization Count) - Zscaler Help — Configuring App Connector Provisioning Keys (App Connector Keys → Add; Name; Group; Maximum Reuse of Provisioning Key; Signing Certificate; View or Export…; OAuth 2.0 tokens preferred) - Zscaler Help — App Connector Deployment Prerequisites (sizing; ZDX 8 GB RAM; egress 443; TCP/UDP/ICMP; app ports) - Zscaler Help — App Connector Deployment Guide for Linux (console login; /opt/zscaler/var/provision_key ; systemd service) - Zscaler Help — Troubleshooting App Connectors (wipe var, chmod 644, re-enroll; Diagnostics filters; clock skew; NO_CONNECTOR_AVAILABLE with ID = 0) - Zscaler Help — Managing Deployed Software Components ( sudo systemctl status zpa-connector ; default admin / zscaler; App Connectors page check) - Zscaler Help — Understanding Private Access Session Status Codes ( NO_CONNECTOR_AVAILABLE , APP_NOT_REACHABLE , paused-for-upgrade) - Zscaler Help — Understanding Health Reporting (application Up / Down from the App Connector) - Zscaler Help — Accessing App Connector Status Diagnostics (Logs → Insights → Diagnostics → Log Type: App Connector Status) - Zscaler Help — ZPA Leading Practices Guide (same lat/long per group; N+1) - Zscaler Help — Configuring Application Load Balancing and High Availability (active / Passive Server Groups) - Zscaler Help — About Branch Connectors (VM that forwards to ZIA and ZPA) - Zscaler Help — What Is Zscaler Branch Connector? - Zscaler Help — What Is Zscaler Cloud Connector? - Zscaler Help — Deploying Zscaler Cloud Connector with AWS (Infrastructure → Connectors → Cloud → Provisioning; API Key Management path; VM Size; Auto Scaling) - Zscaler Help — Deploying Branch Connector & App Connector on VMware (combined image; API key registration) Related: Lesson 9 · ZPA architecture · Lesson 11 · ZPA policies · App Connector deploy (deep) · App Connector troubleshooting · ZPA troubleshooting · Zscaler authentication --- Cite this Techclick lesson with the source URL. Do not invent fees, batch dates, or job guarantees. Browse all lessons: https://ai.techclick.in/blogs AI index: https://ai.techclick.in/llms.txt