अनैटेंडेड एक्सेस तैनाती: सैकड़ों तक स्केल करना

किसी भी मशीन पर physically जाए बिना सैकड़ों मशीनों पर अनैटेंडेड एक्सेस रोलआउट करना लक्ष्य है — और योजना न बनाने पर यह सिरदर्द बन जाता है। यह मार्गदर्शिका एक पुनरुत्पादन योग्य, ऑडिट-योग्य रोलआउट बताती है: प्री-कॉन्फिगर इंस्टॉलर बनाएं, उन्हें GPO/MDM या ऑर्केस्ट्रेशन टूल्स से पुश करें, बड़े पैमाने पर सत्यापित करें, और सामान्य जालों से बचें। यदि आप पहले से ही अपनी वातावरण की सीमाएँ जानते हैं (एयर-गैप्ड, सख्त रेजिडेंसी, या कोई अनुपालन नियम जो थर्ड-पार्टी रिले को मना करता है), तो नीचे स्व-होस्ट सेक्शन पर सीधे जाएँ।

1. आर्किटेक्चर और अनिवार्यता तय करें

पैकेजिंग शुरू करने से पहले चुनें कि फ़्लेट Tenvo के managed relay का उपयोग करेगा या self-hosted relay। Tenvo's managed relay हमारी डिफ़ॉल्ट सिफारिश है: यह मल्टी-रीजन फ़ेलओवर, एक ब्राउज़र क्लाइंट (public beta), Windows/macOS/Linux के लिए नेटिव क्लाइंट्स, और प्राइसिंग टियर Free $0 / Lite $2.99/mo / Pro $7.99/mo प्रदान करता है। जब तक आपके पास अपना रिले चलाने की लिखित अनिवार्यता न हो (डेटा रेजिडेंसी, एक अलग नेटवर्क, या ऐसा कोई अनुपालन नियम जो थर्ड-पार्टी इन्फ्रास्ट्रक्चर को मना करे), तब तक Tenvo के रिले का उपयोग करें। Managed relays ऑन-काल भार कम करते हैं: आप TLS termination, certificate renewal, key custody, या single-region failover नहीं चलाते।

सुरक्षा नोट: Tenvo पर प्रति-डिवाइस प्रमाणपत्र के साथ आपसी प्रमाणीकृत TLS का उपयोग होता है। दो डिवाइसों के बीच डायरेक्ट पीयर-टू-पीयर कनेक्शन उन एंडपॉइंट्स के बीच end-to-end होता है; जब ट्रैफ़िक रिले पर fallback करता है, तो TLS रिले पर terminate होता है, इसलिए जो भी वह रिले ऑपरेट करता है वह सेशन ट्रैफ़िक तक पहुँच सकता है। अपने लॉगिंग और एक्सेस कंट्रोल्स के अनुसार योजना बनाएं।

2. प्री-कॉन्फिगर किए हुए इंस्टॉलर बनाएं

प्री-कॉन्फिगर इंस्टॉलर मानव त्रुटि को हटाते हैं। इंस्टॉलर को सेवा इंस्टॉल करनी चाहिए, कॉन्फ़िगरेशन फ़ाइल या टोकन सही पथ में गिराना चाहिए, और सेवा शुरू करनी चाहिए। सामान्य प्लेटफ़ॉर्म और उनके अनुशंसित फॉर्मैट:

• Windows: MSI या EXE with silent switches (msiexec /i mypkg.msi /qn).
• macOS: .pkg या एक साइन किया हुआ इंस्टॉलर जो installer CLI का उपयोग करे.
• Linux: .deb/.rpm पैकेज systemd सेवा एनेबलमेंट के साथ.

इंस्टॉलर को इस तरह डिज़ाइन करें कि एक एकल, पुनरुत्पादन योग्य आर्टिफैक्ट सैकड़ों मशीनों पर पुश किया जा सके और मशीन अपने आप आपके कंसोल में रजिस्टर हो जाए। कॉन्फ़िगरेशन में शामिल होना चाहिए: एक डिवाइस नेम टेम्पलेट, एक इंस्टॉल टोकन या प्रोविज़निंग की, और रनटाइम विकल्प (auto-start, user-session व्यवहार, logging level)। इंस्टॉलर में कभी भी लंबी अवधि के एडमिन पासवर्ड न-पकाएँ — प्रति-डिवाइस टोकन या शॉर्ट-लाइव्ड बूटस्ट्रैप टोकन का उपयोग करें जिन्हें मैनेजमेंट कंसोल रद्द कर सके।

Example: Windows installer workflow

REM Example: unattended install and provisioning (Windows PowerShell)
msiexec.exe /i TenvoAgent.msi /qn /norestart
# Copy config (JSON) to ProgramData before starting service
Copy-Item -Path .\tenvo-config.json -Destination 'C:\ProgramData\Tenvo\config.json' -Force
Start-Service -Name TenvoAgent

Example: what the JSON config might contain (keep secrets minimal):

{
  "provisioning_token": "PROV-TOKEN-PLACEHOLDER",
  "device_name": "{hostname}-{serial}",
  "auto_start": true,
  "log_level": "info",
  "relay_region": "auto"
}

macOS के लिए समान फ़्लो को pkgbuild/productbuild और installer CLI के साथ स्क्रिप्ट किया जा सकता है; Debian/Ubuntu के लिए postinst शामिल करें जो कॉन्फ़िग रखता है और systemd यूनिट को एनेबल करता है।

3. बड़े पैमाने पर पुश के तरीके: GPO, Intune, SCCM, और SSH

वह डिप्लॉयमेंट चैनल चुनें जिस पर आपका वातावरण पहले से भरोसा करता है। रोलआउट के दौरान एक नया वितरण तरीका मत बनाइए। यहाँ सामान्य दृष्टिकोण और व्यावहारिक सुझाव दिए गए हैं।

Windows: Group Policy (GPO) or Intune

• GPO (AD): डोमेन-जॉइन्ड मशीनों के लिए Group Policy Software Installation का उपयोग करें (MSI को assign करें)। Assign करें, publish नहीं, ताकि एजेंट बूट पर इंस्टॉल हो। पहले एक छोटे OU पर टेस्ट करें। यदि आपको कॉन्फ़िग फ़ाइल रखने की आवश्यकता है, तो इंस्टाल के बाद JSON को ProgramData में कॉपी करने के लिए Group Policy Preferences का उपयोग करें, फिर सेवा शुरू करने के लिए एक startup स्क्रिप्ट कॉन्फ़िगर करें।
• Intune: MSI को Win32 ऐप के रूप में रैप करें, कॉन्फ़िग को dependency या install स्क्रिप्ट के रूप में शामिल करें, और ऐप को required के रूप में मार्क करें। detection rules का उपयोग करें जो सेवा के मौजूद होने या C:\ProgramData\Tenvo\installed.tag पर फ़ाइल मौजूद होने की जांच करें।

SCCM / Endpoint Configuration Manager

एक application package का उपयोग करें जिसमें ऐसा detection method हो जो सर्विस स्टेट की जाँच करे। रिंग्स में डिप्लॉय करें: 1% canary, 10% pilot, फिर 50/90। compliance baselines का उपयोग करके सत्यापित करें कि कॉन्फ़िग फ़ाइल अपेक्षित सामग्री से मिलती है (token मौजूद है; device_name टेम्पलेट सही है)।

Linux & macOS: SSH, MDM, and management agents

• Linux: यदि आपके पास SSH एक्सेस है, तो पैकेज और कॉन्फ़िग को एक स्क्रिप्ट से पुश करें जो apt/apt-get या rpm/dnf चलाए। जिन फ़्लीट्स को configuration management (Ansible/Chef/Puppet) द्वारा प्रबंधित किया जाता है, उनमें एजेंट को एक managed resource बनाएं ताकि आपका CM टूल इसे एन्फोर्स करे। उदाहरण: एक Ansible टास्क जो कॉन्फ़िग कॉपी करता है और सेवा को रिस्टार्ट करता है।
• macOS: Apple MDM (Jamf, Intune macOS) का उपयोग करके एक signed .pkg और एक configuration profile डिप्लॉय करें। यदि MDM सीधे कॉन्फ़िग फ़ाइल नहीं लिख सकता, तो पैकेज के अंदर एक postinstall स्क्रिप्ट का उपयोग करें।

Device naming and inventory

डुप्लिकेट्स से बचने के लिए एक डिटरमिनिस्टिक device-name टेम्पलेट (facility-hostname-serial) तय करें। यदि एजेंट टैग्स या ग्रुप्स का समर्थन करता है, तो इंस्टाल के समय विभाग और लोकेशन शामिल करें — इससे समस्याग्रस्त बैच को फ़िल्टर और रोलबैक करना आसान होगा। डिप्लॉयमेंट से पहले डिवाइस पहचानकर्ताओं का CSV एक्सपोर्ट करें ताकि आप क्रॉस-चेक कर सकें कि कौन सी मशीनें रिपोर्ट हुईं।

4. Canary, validation, and rollbacks

सभी जगह एक साथ डिप्लॉय न करें। प्रत्येक चरण पर स्वचालित सत्यापन के साथ एक रोलिंग रणनीति उपयोग करें। उदाहरण रिंग साइज: Canary 1–5, Pilot 5–50, Production वेव्स 10–25% हर बार। 1,000 मशीनों के फ़्लीट के लिए, एक वाजिब रोलआउट हो सकता है: 5 canary, 45 pilot, फिर जोखिम सहिष्णुता के अनुसार 200/200/250/300 वेव्स।

प्रत्येक वेव के लिए सत्यापन चेकलिस्ट:

• एजेंट सेवा चल रही है (service status check या systemd यूनिट active)।
• डिवाइस प्रबंधन कंसोल में ऑनलाइन दिखाई दे रहा है।
• कंसोल में सही डिवाइस मेटाडेटा दिख रहा है (name, tags, OS)।
• एक canary डिवाइस पर टेस्ट सेशन करें ताकि स्क्रीन, इनपुट, और यदि उपयोग हो तो फ़ाइल ट्रांसफ़र सत्यापित हो सके।
• एप्लिकेशन लॉग्स में त्रुटियों की जाँच करें (उदा., TLS handshake failures, provisioning rejections)।

जहाँ संभव हो चेक्स को स्वचालित करें। एक सरल स्क्रिप्ट Tenvo API (या कंसोल) को क्वेरी कर सकती है डिवाइस स्टेटस के लिए और यदि >=95% सफलता हो तो वेव को ग्रीन मार्क करे, अन्यथा पॉज़ करके जाँच करे।

5. Monitoring, logs, and auditability

फ़्लीट स्तर पर आपको इंस्टॉल और रनटाइम हेल्थ के बारे में दृश्यता चाहिए। सुनिश्चित करें:

• इंस्टॉल लॉग्स सेंट्रल में कलेक्ट हों (Syslog, Windows Event Forwarding), और एंट्रीज़ में एक deployment ID शामिल हो ताकि आप एक इंस्टॉल बैच को रिज़ल्ट से मैप कर सकें।
• एजेंट लॉग्स रिसोर्स रोटेशन और रिटेंशन के साथ हों; अनुपालन के लिए रिकॉर्ड रखें कि किसने रिमोट सेशन शुरू किया और कब।
• रिपीट फ़ेलियर्स के लिए अलर्टिंग: उदाहरण के लिए, यदि किसी वेव का >2% provisioning error रिपोर्ट करता है, तो मानव समीक्षा ट्रिगर करें।

रोलआउट से पहले अपने ऑडिट ट्रेल को डिज़ाइन करें: डिप्लॉयमेंट्स, किसने provisioning tokens बनाए, और डिवाइस ओनरशिप रिकॉर्ड होनी चाहिए। यदि आपको SOC 2 या PCI जैसे मानकों को पूरा करना है, तो अपने रिमोट-ऐक्सेस लॉग्स को उन कंट्रोल आवश्यकताओं से पहले से मैप करें। देखें Remote Desktop Audit Logging में कि क्या कैप्चर करना चाहिए।

6. Certificate and token lifecycle

कुंजी रोटेशन मत भूलिए। Provisioning tokens को शॉर्ट-लाइव्ड या रोटेबल होना चाहिए, और आपके पास decommission किए गए डिवाइसेज़ के लिए टोकन revoke करने की योजना होनी चाहिए। रिले के लिए, certificate renewal की योजना बनाएं और expiry डेट्स पर निगरानी रखें: जब रिले का सर्टिफिकेट एक्सपायर होता है, तो जुड़ी डिवाइसेज़ TLS हैण्डशेक फेल कर सकती हैं जब तक वह रिफ्रेश न हो।

व्यवहारिक नीति: बड़े फ़्लीट्स के लिए provisioning tokens हर 90 दिनों में रोट करें, या प्रति-डिवाइस टोकन का उपयोग करें जिन्हें आप व्यक्तिगत रूप से revoke कर सकें। यदि आप रिले self-host कर रहे हैं, तो उन लोगों को सूचीबद्ध करें जो सर्टिफिकेट रिन्यू कर सकते हैं और ऑटोमेटेड रिन्यूअल के साथ एक दस्तावेजीकृत रनबुक रखें। यदि आप Tenvo's managed relay का उपयोग करते हैं, तो certificate renewal Tenvo द्वारा संभाला जाता है; आप अभी भी अपने device tokens के मालिक हैं और उन्हें कंसोल से revoke कर सकते हैं।

7. When to self-host a relay (and what breaks)

Self-hosting तभी सही विकल्प है जब कोई लिखित आवश्यकता इसे बाध्य करे: ऐसा कोई अनुपालन दायित्व जो थर्ड-पार्टी इन्फ्रास्ट्रक्चर को मना करे, एक अलग नेटवर्क जिसमें कोई egress न हो, या कड़ा डेटा-रेज़िडेंसी नियम। अन्यथा, managed relay आमतौर पर कम लागत वाली होती है जब आप ऑन-काल समय, पैचिंग, key custody, certificate renewal, और मल्टी-रीजन फ़ेलओवर के अभाव को जोड़ते हैं।

यदि आपको self-host करना ही है, तो योजना बनाएं:

• HA across regions (या कम से कम multiple AZs) ताकि single-region फेलियर से बचा जा सके।
• मॉनिटरिंग और ऑटोमैटेड सर्ट रिन्यूअल (let's encrypt या आपकी CA) ट्रैकिंग और अलर्टिंग के साथ।
• कॉन्फ़िग और प्राइवेट कीज़ का बैकअप, सख्त एक्सेस कंट्रोल और क्रेडेंशियल रोटेशन।

स्व-होस्टिंग के ट्रेडऑफ़्स और निर्देशों की पूरी वॉकथ्रू के लिए देखें Self-hosted remote desktop: the honest 2026 guide. अगर आप deployable MSIs बनाने के लिए एक त्वरित how-to चाहते हैं, तो पढ़ें Remote desktop MSI deployment: Rollout via Group Policy.

8. Common failures and how to fix them

फेलियर्स आमतौर पर नेटवर्किंग, परमिशन्स, और provisioning के आसपास क्लस्टर करते हैं। निम्न प्राथमिकता सूची के साथ ट्रबलशूट करें:

1. Service not running: systemd/Windows service logs और permissions चेक करें। Windows पर, इंस्टॉल पैकेज कोड के लिए Event Viewer देखें। सुनिश्चित करें कि सर्विस अकाउंट के पास कॉन्फ़िग पथ के अधिकार हैं।
2. Agent can't reach relay: आउटबाउंड HTTPS (443) को रिले endpoints के लिए अनुमति है यह पुष्टि करें, और कि कंपनी प्रॉक्सी कॉन्फ़िगर हैं। कुछ कॉर्पोरेट प्रॉक्सीज़ NTLM/kerberos auth की मांग करते हैं और एजेंट प्रॉक्सी कॉन्फ़िगरेशन की आवश्यकता होती है।
3. Name या token mismatch: इंस्टॉल की गई कॉन्फ़िग में अपेक्षित provisioning token की पुष्टि करें। यदि आपका डिप्लॉयमेंट post-install स्क्रिप्ट के माध्यम से टोकन रखता है, तो फाइल कॉपी ऑर्डर जांचें (फाइल सेवा शुरू होने से पहले मौजूद होनी चाहिए)।
4. TLS handshakes failing: एजेंट लॉग्स में सर्टिफिकेट त्रुटियों के लिए देखें। यदि आप self-host कर रहे हैं, तो chain validity और intermediate certs मौजूद होने की जाँच करें। यदि आप Tenvo's managed relay का उपयोग कर रहे हैं, तो relay region सेटिंग्स की पुष्टि करें।
5. Devices appear offline in console: heartbeat intervals और फ़ायरवॉल के stateful नियम जाँचें जो लाँग-लिव्ड कनेक्शंस ड्रॉप कर सकते हैं। flaky नेटवर्क्स में agent keepalive बढ़ाना या relay region बदलना मदद कर सकता है।

यदि आपको व्यक्तिगत डिवाइसेज़ के लिए त्वरित सेटअप चेकलिस्ट या लोकल ट्रबलशूटिंग स्टेप्स चाहिए, तो हमारी कॉम्पैक्ट गाइड उपयोगी है: How to Set Up Remote Access in 60 Seconds.

9. Rollout checklist (one-page)

• managed relay बनाम self-host चुनें (कारण दस्तावेज़ करें)।
• provisioning tokens और tag नीति बनाएँ।
• प्रत्येक OS के लिए एक सिंगल प्री-कॉन्फिगर इंस्टॉलर बनाएं और silent install switches सत्यापित करें।
• तीन मशीन प्रकारों पर टेस्ट इंस्टॉल करें (canary farm)।
• स्वास्थ्य जांचों के साथ pilot वेव डिप्लॉय करें (स्वचालित)।
• लॉग और डिवाइस काउंट मॉनिटर करें; यदि विफलताओं की सीमा पार हो तो पॉज़ करें।
• वेव्स को प्रोग्रेस करें और रोलबैक दस्तावेज़ करें (uninstall स्क्रिप्ट या token रिवोकेशन)।

10. Example PowerShell bootstrap for Windows (practical)

# Bootstrap script for a silent Tenvo install on Windows
$msiPath = "\\fileserver\packages\TenvoAgent.msi"
$configPath = "\\fileserver\configs\tenvo-config.json"
Copy-Item $msiPath -Destination "C:\Temp\TenvoAgent.msi" -Force
msiexec.exe /i "C:\Temp\TenvoAgent.msi" /qn /norestart
New-Item -ItemType Directory -Force -Path 'C:\ProgramData\Tenvo'
Copy-Item $configPath -Destination 'C:\ProgramData\Tenvo\config.json' -Force
Start-Service -Name TenvoAgent
# Wait and verify
Start-Sleep -Seconds 10
if ((Get-Service -Name TenvoAgent).Status -ne 'Running') { Write-Error 'Tenvo service failed to start'; exit 1 }
Write-Output 'Install complete and agent running.'

इसे अपने डिप्लॉयमेंट पाइपलाइन (SCCM/Intune/PSExec) में एंबेड करें और सुनिश्चित करें कि fileserver पथ टार्गेट होस्ट द्वारा रिज़ॉल्वेबल हो। Intune के लिए स्क्रिप्ट को Win32 ऐप इंस्टॉल व्यवहार में रैप करें और detection rules का उपयोग करें जो सेवा के लिए देखते हों।

Final notes and truth-telling about cost

फ़्लीट स्केल पर, स्पष्ट मीट्रिक केवल प्रति-डिवाइस लाइसेंस नहीं है — यह कुल संचालन लागत है। Self-hosting से पूरा समय कार्य बढ़ जाता है: रिले पैचिंग, certificate rotation, incident response, और बैकअप। Tenvo's managed relay उस ऑपरेशनल भार को हटा देता है। हमारी managed relay मल्टी-रीजन है, macOS/Windows/Linux के नेटिव क्लाइंट्स का समर्थन करती है, ब्राउज़र क्लाइंट public beta में है, और Free $0 / Lite $2.99/mo / Pro $7.99/mo टियर्स में उपलब्ध है।

हम सीधे कहते हैं: यदि आपका संगठन थर्ड-पार्टी रिले स्वीकार कर सकता है और आप ops ओवरहेड कम करना चाहते हैं और मल्टी-रीजन विश्वसनीयता चाहते हैं, तो Tenvo's managed relay का उपयोग करें। यदि कोई विनियमन स्पष्ट रूप से बाहरी रिले मनाह कर देता है, तो self-host चेकलिस्ट का पालन करें और दीर्घकालिक रखरखाव लागत की योजना बनाएं।

अतिरिक्त पढ़ाई: यदि आप Windows एजेंट्स को डोमेन डिप्लॉयमेंट्स में पैकेज कर रहे हैं, तो हमारी स्टेप-बाय-स्टेप MSI deploy गाइड में Group Policy और detection rules का विस्तार है: Remote desktop MSI deployment: Rollout via Group Policy. यदि आपको रिमोट एक्सेस के लिए सुरक्षा प्राइमर चाहिए, तो देखें Remote Desktop Security: What You Need to Know.

कंट्रोल्ड रोलआउट ट्राई करने के लिए तैयार हैं? Windows, macOS, और Linux के लिए क्लाइंट डाउनलोड करें या नीचे दिए लिंक पर ब्राउज़र क्लाइंट बीटा आज़माएँ। यदि आपको अपने वातावरण के लिए रिंग साइज करने या डिप्लॉयमेंट स्क्रिप्ट बनाने में मदद चाहिए, तो 1–5 मशीन canary से शुरू करें और पहली प्रोडक्शन वेव को फोरेंसिक अभ्यास मानें।

Tenvo डाउनलोड करें