0

راهنمای عملی Windows Autopilot در Endpoint Central برای Zero-Touch Provisioning لپ‌تاپ‌های سازمانی؛ از Hardware Hash و Entra ID تا Enrollment، Policy، App Deployment و Reassignment.

شرکت مدانت
شرکت مدانت
[ مجری تخصصی پیاده‌سازی چارچوب ITIL و تحول دیجیتال ]
Windows Autopilot در Endpoint Central؛ راه‌اندازی Zero-Touch لپ‌تاپ‌های سازمانی

سناریو آشناست: واحد منابع انسانی اعلام می‌کند ۴۰ نیروی جدید از دوشنبه شروع به کار می‌کنند. تیم IT باید ۴۰ لپ‌تاپ را از جعبه خارج کند، Windows را آماده کند، Agent نصب کند، Policyها را اعمال کند، نرم‌افزارهای سازمانی را نصب کند، دستگاه را به کاربر تحویل دهد و مطمئن شود همه چیز درست است. اگر هر لپ‌تاپ فقط ۳۰ تا ۴۵ دقیقه زمان بگیرد، تیم IT عملاً یک یا دو روز کامل درگیر آماده‌سازی دستی می‌شود.

Windows Autopilot در Endpoint Central این مدل را تغییر می‌دهد. ایده اصلی این است که دستگاه جدید بدون Image اختصاصی و بدون حضور طولانی کارشناس IT، مستقیماً به کاربر برسد؛ کاربر دستگاه را روشن کند، به شبکه متصل شود و پس از احراز هویت، Enrollment، Policy، Application و تنظیمات مدیریتی به‌صورت خودکار اعمال شوند.

این مقاله درباره خود صفحه محصول Endpoint Central نیست؛ آن صفحه باید Intent تجاری محصول را نگه دارد. اینجا روی یک Use Case مشخص تمرکز می‌کنیم: Zero-Touch Provisioning لپ‌تاپ‌های Windows با Windows Autopilot و ManageEngine Endpoint Central و اینکه چطور آن را طوری پیاده کنیم که Deployment سریع شود اما امنیت و کنترل IT از بین نرود.

Windows Autopilot چیست؟

Windows Autopilot مجموعه‌ای از فناوری‌های Microsoft برای آماده‌سازی و پیکربندی اولیه دستگاه‌های Windows است. به‌جای اینکه IT برای هر مدل لپ‌تاپ Image جداگانه بسازد، از Windows نصب‌شده توسط OEM استفاده می‌شود و دستگاه در اولین راه‌اندازی به وضعیت «Business-ready» منتقل می‌شود.

طبق مستند Microsoft، Autopilot می‌تواند برای این سناریوها استفاده شود:

  • User-driven deployment برای دستگاه شخصی هر کاربر؛
  • Self-deploying mode برای دستگاه‌های Shared، Kiosk یا Digital Signage؛
  • Autopilot Reset برای بازگرداندن دستگاه به وضعیت آماده سازمان؛
  • Repurpose یا انتقال دستگاه به کاربر دیگر؛
  • اعمال Policy و نصب Application بدون Re-imaging سنتی.

نکته مهم این است که Autopilot خودش ابزار کامل Endpoint Management نیست. Autopilot مرحله Provisioning و Enrollment را ساده می‌کند؛ بعد از Enrollment، ابزار UEM/MDM مانند Endpoint Central مسئول Policy، Software Deployment، Inventory، Patch، Configuration و سایر کنترل‌ها می‌شود.

Endpoint Central در سناریوی Autopilot چه نقشی دارد؟

ManageEngine در راهنمای رسمی Windows Autopilot توضیح می‌دهد که دستگاه‌های Windows 10 و بالاتر را می‌توان از طریق Autopilot به MDM Enrollment متصل کرد. در این فرآیند، Hardware ID دستگاه ثبت می‌شود، Profile در Microsoft Intune Admin Center/Entra environment تعریف می‌شود و در اولین راه‌اندازی، دستگاه به مسیر Enrollment سازمان هدایت می‌شود.

پس معماری ساده چنین است:

  1. Device Identity یا Hardware Hash ثبت می‌شود.
  2. Autopilot Deployment Profile به دستگاه Assign می‌شود.
  3. کاربر دستگاه را روشن می‌کند.
  4. Windows OOBE سازمانی نمایش داده می‌شود.
  5. کاربر احراز هویت می‌کند.
  6. دستگاه به MDM/Endpoint Central Enrollment هدایت می‌شود.
  7. Policy، App، Security Baseline و Configuration اعمال می‌شوند.

برای سازمانی که Endpoint Central را به‌عنوان UEM اصلی استفاده می‌کند، نتیجه این است که فرآیند «خرید لپ‌تاپ تا تحویل دستگاه Managed» می‌تواند بسیار کمتر وابسته به کار دستی IT باشد.

Autopilot چه تفاوتی با Imaging سنتی دارد؟

موضوع Imaging سنتی Windows Autopilot
Image اختصاصی معمولاً نیاز دارد معمولاً از Windows OEM استفاده می‌کند
نیاز به Touch IT زیاد کمتر
Driver Management ممکن است پیچیده باشد وابستگی کمتر به Golden Image
ارسال مستقیم دستگاه به کاربر دشوارتر سناریوی اصلی
اعمال Policy پس از Imaging در Enrollment و بعد از آن
مناسب Remote Workforce محدودتر مناسب‌تر
تغییر مدل سخت‌افزار ممکن است Image جدید بخواهد ساده‌تر

این جدول به معنی پایان Imaging نیست. بعضی سازمان‌ها هنوز برای Lab، Factory، Offline Network یا سیستم‌های خاص به Deployment سنتی نیاز دارند. Autopilot زمانی بیشترین ارزش را دارد که دستگاه‌ها اینترنت دارند، Identity Cloud/Hybrid تعریف شده و سازمان به سمت Modern Management حرکت کرده است.

سناریوی صفر تا صد: لپ‌تاپ مستقیماً از فروشنده به کارمند

فرض کنید سازمان ۲۰۰ کارمند دورکار دارد و هر ماه ۱۰ تا ۲۰ لپ‌تاپ جدید تهیه می‌کند. در مدل سنتی، همه دستگاه‌ها ابتدا باید به دفتر IT برسند. در مدل Autopilot می‌توان فرآیند را این‌گونه طراحی کرد:

  1. فروشنده یا OEM اطلاعات Hardware ID دستگاه‌ها را تحویل می‌دهد.
  2. IT آن‌ها را در Autopilot ثبت می‌کند.
  3. Profile مناسب بر اساس Department یا Use Case Assign می‌شود.
  4. لپ‌تاپ مستقیماً برای کارمند ارسال می‌شود.
  5. کارمند دستگاه را روشن و به اینترنت متصل می‌کند.
  6. Login سازمانی انجام می‌شود.
  7. Device Enrollment و مدیریت توسط Endpoint Central آغاز می‌شود.
  8. Applicationهای پایه نصب می‌شوند.
  9. Security Configuration اعمال می‌شود.
  10. دستگاه وارد Inventory و Monitoring می‌شود.

در این مدل، IT به‌جای لمس فیزیکی هر لپ‌تاپ، Process را طراحی و Exceptionها را مدیریت می‌کند.

پیش‌نیازهای Windows Autopilot با Endpoint Central

طبق راهنمای فعلی ManageEngine، پیش‌نیازهای اصلی شامل Integration با Microsoft Entra ID، دسترسی مناسب به Entra/Intune environment و Windows 10 یا نسخه‌های بالاتر است. در محیط On-Premises نیز Domain مورد استفاده باید در Azure/Entra environment تأیید شده باشد.

در طراحی Production این موارد را قبل از Pilot بررسی کنید:

  • Microsoft Entra ID Integration؛
  • مجوزهای لازم Microsoft برای Autopilot/Intune enrollment؛
  • دسترسی اینترنت دستگاه در OOBE؛
  • DNS و Proxy/Firewall مناسب؛
  • ثبت Hardware Hash دستگاه‌ها؛
  • Autopilot Deployment Profile؛
  • MDM Enrollment Configuration؛
  • Scope و License مناسب Endpoint Central؛
  • Application و Policyهایی که بعد از Enrollment باید اعمال شوند.

Hardware Hash چیست و چرا مهم است؟

Autopilot باید تشخیص دهد دستگاهی که روشن شده متعلق به کدام سازمان و کدام Profile است. برای همین Device Identity از اطلاعات سخت‌افزاری ساخته و ثبت می‌شود.

ManageEngine دو مسیر رایج برای گرفتن Hardware ID معرفی می‌کند:

  • دریافت مستقیم از Vendor/OEM؛
  • استخراج با Script و تولید CSV شامل اطلاعاتی مانند Serial Number و Hardware Hash.

برای Scale بالا، مدل Vendor-to-Autopilot بهتر است؛ چون اگر IT مجبور باشد هر لپ‌تاپ را روشن کند تا Hardware Hash استخراج شود، بخش زیادی از مزیت Zero-Touch از بین می‌رود.

User-driven Mode چه زمانی مناسب است؟

User-driven Deployment مناسب لپ‌تاپ شخصی یک کارمند است. دستگاه به کاربر مشخص تحویل می‌شود و کاربر در OOBE با Identity سازمان وارد می‌شود.

این مدل برای این سناریوها مناسب است:

  • کارمند اداری؛
  • Remote Worker؛
  • Developer Laptop؛
  • مدیران سازمان؛
  • دستگاه‌های اختصاصی یک نفر.

در این حالت، Policy و Application می‌تواند براساس User، Group، Department یا Device Profile متفاوت باشد.

Self-deploying Mode چه زمانی بهتر است؟

Microsoft Autopilot Self-deploying Mode برای دستگاه‌هایی طراحی شده که لزوماً User شخصی ندارند. نمونه‌ها:

  • Kiosk؛
  • Reception PC؛
  • Digital Signage؛
  • Shared Device؛
  • Training Room؛
  • کارگاه یا خط تولید.

در چنین دستگاه‌هایی هدف این نیست که کاربر شخصی Owner باشد؛ هدف این است که دستگاه با حداقل دخالت انسانی به Configuration استاندارد سازمان برسد.

Autopilot Reset برای Offboarding و Reassignment

یکی از Use Caseهای ارزشمند Autopilot فقط Onboarding نیست. وقتی کارمند سازمان را ترک می‌کند، دستگاه باید از وضعیت شخصی کاربر خارج و برای نفر بعدی آماده شود.

Autopilot Reset می‌تواند دستگاه را به Business-ready State برگرداند و در سناریوهای Reassignment یا Break/Fix مفید باشد. در فرآیند成熟، این مرحله باید با Offboarding سازمان هماهنگ باشد:

  1. Account Disable/Offboarding آغاز می‌شود.
  2. داده سازمانی بررسی و در صورت نیاز Backup می‌شود.
  3. Device از User قبلی جدا می‌شود.
  4. Reset اجرا می‌شود.
  5. Profile جدید Assign می‌شود.
  6. دستگاه به کاربر بعدی تحویل می‌شود.

برای طراحی چرخه عمر کامل Endpoint، این ارتباط بین HR، ITSM و UEM اهمیت زیادی دارد.

بعد از Enrollment چه Policyهایی باید اعمال شوند؟

Zero-Touch فقط وقتی ارزش دارد که خروجی آن دستگاه «Managed و Secure» باشد، نه فقط دستگاهی که Agent دارد.

مرحله کنترل پیشنهادی
Identity Entra Join/Hybrid Join، Group Assignment
Endpoint Management Enrollment و Agent Health
Security Baseline Password، Firewall، Defender/AV Policy
Patch OS و Third-party Patch Policy
Software Office، Browser، VPN، Agentهای سازمانی
Configuration Registry، Certificate، Wi-Fi، Proxy
Inventory Hardware/Software Inventory
Compliance Encryption، Security Configuration، Device Health

Endpoint Central در همین نقطه ارزش تجاری اصلی را ایجاد می‌کند: بعد از Enrollment، مدیریت چرخه عمر Endpoint ادامه دارد.

نصب نرم‌افزار بعد از Autopilot

پس از Enrollment باید مشخص باشد چه Applicationهایی Mandatory و چه Applicationهایی Optional هستند. طبق مستند Endpoint Central، Software Deployment در Windows می‌تواند با Packageها و Templateهای نرم‌افزاری مدیریت شود.

پیشنهاد عملی این است که Softwareها را سه Tier کنید:

  • Tier 0: Agentهای امنیتی و مدیریت؛
  • Tier 1: Applicationهای ضروری برای شروع کار؛
  • Tier 2: نرم‌افزارهای Department-specific یا Optional.

اگر همه نرم‌افزارها در OOBE نصب شوند، زمان آماده‌سازی اولیه زیاد می‌شود. بهتر است فقط موارد حیاتی قبل از شروع کار کاربر نصب شوند و سایر Packageها بعداً Deploy شوند.

Autopilot و Patch Management

دستگاه جدید لزوماً دستگاه Patch شده نیست. حتی لپ‌تاپی که تازه از کارخانه رسیده ممکن است Build قدیمی Windows یا نسخه قدیمی Application داشته باشد.

بنابراین بعد از Enrollment باید Patch Baseline اجرا شود. برای سازمان‌هایی که Third-party Application زیادی دارند، راهنمای مدیریت Patch نرم‌افزارهای ثالث با Patch Manager Plus دید مکمل خوبی درباره Pilot، Approval و Deployment مرحله‌ای می‌دهد.

Autopilot و IT Asset Management

Zero-Touch Provisioning فقط مسئله Deployment نیست؛ باید به Asset Lifecycle هم متصل شود. وقتی لپ‌تاپ خریداری می‌شود، بهتر است Asset Record قبل از تحویل به کاربر وجود داشته باشد و اطلاعات زیر ثبت شود:

  • Serial Number؛
  • Asset Tag؛
  • Vendor و Model؛
  • Purchase Date؛
  • Warranty؛
  • Assigned User؛
  • Department؛
  • Lifecycle Status.

در سازمان‌هایی که ServiceDesk Plus یا ITAM دارند، Autopilot باید بخشی از چرخه «Procurement → Enrollment → Assignment → Support → Reassignment → Retirement» دیده شود. برای نگاه ITAM می‌توانید راهنمای مدیریت دارایی فناوری اطلاعات را نیز ببینید.

چرا Enrollment را با Device Management اشتباه نگیریم؟

Enrollment فقط شروع رابطه مدیریتی دستگاه با UEM است. اگر Enrollment موفق باشد اما موارد زیر درست نباشند، پروژه هنوز کامل نیست:

  • Agent سالم نباشد؛
  • Patch Policy Assign نشده باشد؛
  • Application Deployment Fail شود؛
  • Certificate نصب نشود؛
  • Encryption فعال نباشد؛
  • Device در Inventory اشتباه Group شود؛
  • Compliance Alert تعریف نشده باشد.

بنابراین KPI پروژه باید «Enrollment Success» نباشد؛ KPI بهتر «Business-ready Device Success Rate» است.

چه KPIهایی برای Autopilot تعریف کنیم؟

KPI هدف
Enrollment Success Rate درصد دستگاه‌هایی که بدون Intervention ثبت می‌شوند
Time to Business-ready زمان از روشن شدن تا آماده کار شدن
Manual Touch Rate چند درصد دستگاه‌ها نیاز به دخالت IT دارند
App Deployment Success نرخ موفقیت نصب Applicationهای الزامی
Policy Compliance درصد دستگاه‌های مطابق Baseline
Reassignment Time زمان آماده‌سازی دستگاه برای کاربر بعدی

اگر فقط تعداد Enrollment را بسنجید، ممکن است ده‌ها دستگاه ثبت شده باشند اما کاربر هنوز نتواند VPN یا Application اصلی را اجرا کند.

سناریوی Pilot؛ از ۱۰ دستگاه شروع کنید

Rollout سراسری Autopilot بدون Pilot ریسک بالایی دارد. پیشنهاد عملی:

  1. ۵ تا ۱۰ دستگاه از دو یا سه مدل Hardware انتخاب کنید.
  2. یک Department کم‌ریسک را Pilot کنید.
  3. Hardware Hash Registration را تست کنید.
  4. Autopilot Profile را Assign کنید.
  5. Enrollment از اینترنت خارج سازمان را تست کنید.
  6. Application و Policy Deployment را Verify کنید.
  7. زمان Business-ready شدن را اندازه بگیرید.
  8. Failureهای OOBE و Enrollment را مستند کنید.
  9. Runbook Support بنویسید.
  10. بعد به ۵۰ و سپس ۲۰۰ دستگاه Scale کنید.

مشکلات رایج Autopilot در Production

  • Hardware Hash دستگاه ثبت نشده است.
  • Profile درست Assign نشده است.
  • Entra ID Integration ناقص است.
  • Proxy یا Firewall ارتباط OOBE را مسدود می‌کند.
  • User مجوز لازم ندارد.
  • Device در Group اشتباه قرار گرفته است.
  • Application Mandatory باعث Timeout می‌شود.
  • Certificate یا VPN Profile دیر Deploy می‌شود.
  • Enrollment انجام شده اما Endpoint Central Agent/Management کامل نشده است.

Runbook پشتیبانی باید این خطاها را قبل از Rollout گسترده پوشش دهد.

Autopilot برای شعب و Remote Workforce چه مزیتی دارد؟

بزرگ‌ترین ارزش Autopilot زمانی دیده می‌شود که کاربر در دفتر مرکزی نیست. اگر لپ‌تاپ باید به شهر یا کشور دیگری ارسال شود، مدل سنتی IT Staging هزینه حمل، زمان و عملیات اضافی ایجاد می‌کند.

با طراحی درست، Vendor می‌تواند دستگاه را مستقیم به کاربر بفرستد و IT از راه دور Enrollment و Management را کنترل کند. این مدل برای سازمان‌های چندشعبه‌ای، Remote Worker و شرکت‌هایی که رشد سریع دارند بسیار جذاب است.

Autopilot جایگزین Endpoint Central نیست

Autopilot و Endpoint Central دو لایه متفاوت هستند:

  • Autopilot: Provisioning و شروع Lifecycle؛
  • Endpoint Central: مدیریت روزمره Endpoint بعد از Enrollment.

برای همین اگر هدف فقط «راه‌اندازی اولیه» باشد، بخشی از ارزش UEM از دست می‌رود. سازمان باید Endpoint Lifecycle را یکپارچه ببیند: Provision، Configure، Patch، Secure، Inventory، Support و Retire.

Autopilot چه اثری روی هزینه عملیاتی IT دارد؟

بدون اندازه‌گیری داخلی نباید عدد عمومی برای صرفه‌جویی ساخت. اما می‌توانید TCO را با داده سازمان خود محاسبه کنید.

مثلاً اگر IT ماهانه ۵۰ دستگاه آماده کند و متوسط زمان Touch برای هر دستگاه ۴۰ دقیقه باشد، بیش از ۳۳ ساعت کار مستقیم صرف Staging می‌شود. اگر Autopilot این Touch را به Exception Handling محدود کند، بخشی از این زمان آزاد می‌شود.

فرمول ساده:

Monthly Staging Hours = Devices × Average Manual Minutes ÷ 60

بعد از Pilot همین KPI را قبل و بعد از Autopilot مقایسه کنید.

لایسنس Endpoint Central در پروژه Autopilot

Autopilot خودش جای License Endpoint Management را نمی‌گیرد. دستگاه‌هایی که قرار است بعد از Enrollment با Endpoint Central مدیریت شوند باید در Scope مناسب محصول و Edition قرار بگیرند.

برای محاسبه تعداد Endpoint، Edition و مدل Cloud/On-Premises، مقاله لایسنس Endpoint Central؛ محاسبه Endpoint و Edition را ببینید. این مقاله عمداً روی Licensing تمرکز دارد و مقاله حاضر روی Deployment Architecture؛ بنابراین دو Intent مکمل یکدیگرند.

صفحه اصلی Endpoint Central را کجا ببینیم؟

اگر هدف شما بررسی Capabilityهای کامل UEM شامل Inventory، Patch Management، Software Deployment، Configuration، Remote Management و Mobile Device Management است، صفحه Endpoint Central مدانت مرجع اصلی محصول است.

برای استعلام لایسنس نیز می‌توانید از فروشگاه و استعلام لایسنس ManageEngine مدانت استفاده کنید.

Checklist طراحی Zero-Touch Provisioning

  • Device Procurement Process با Autopilot هماهنگ شده است.
  • Vendor امکان ارائه Hardware Hash دارد.
  • Entra ID Integration آماده است.
  • Autopilot Profile طراحی شده است.
  • MDM Enrollment تست شده است.
  • Endpoint Central Scope و License مشخص است.
  • Mandatory Appها مشخص هستند.
  • Security Baseline تعریف شده است.
  • Patch Policy آماده است.
  • Certificate/Wi-Fi/VPN Configuration تست شده است.
  • Remote Internet Enrollment تست شده است.
  • Failure Runbook نوشته شده است.
  • Asset Assignment به User متصل شده است.
  • Offboarding/Reassignment Process تعریف شده است.
  • KPIهای Time-to-ready و Manual Touch اندازه‌گیری می‌شوند.

منابع

سخن پایانی

Windows Autopilot زمانی ارزش واقعی ایجاد می‌کند که از یک «روش Enrollment» به بخشی از Endpoint Lifecycle تبدیل شود. هدف نهایی فقط این نیست که لپ‌تاپ بدون حضور IT روشن شود؛ هدف این است که دستگاه از اولین Boot تا روز Retirement تحت کنترل، Patch، Inventory و Policy سازمان باقی بماند.

ترکیب Autopilot با Endpoint Central می‌تواند برای سازمان‌های چندشعبه‌ای، Remote Workforce و شرکت‌هایی که تعداد زیادی Device جدید Provision می‌کنند، فرآیند استقرار را استاندارد و قابل اندازه‌گیری کند.

مدانت می‌تواند در استعلام و خرید لایسنس Endpoint Central، طراحی معماری Cloud/On-Premises، راه‌اندازی Windows Autopilot، اتصال Entra ID، طراحی Policy، Software Deployment، Patch Management و پشتیبانی همراه سازمان باشد. برای بررسی Scope پروژه از تماس با مدانت یا درخواست جلسه فنی و دمو استفاده کنید.

مطالب مرتبط جهت افزایش سطح دانش شما:

33

دیدگاه شما

دیدگاه مرتبط و محترمانه بنویسید.