راه‌اندازی Remote Desktop Services برای برنامه‌های شرکت

همهٔ سرورها در این مثال Windows Server 2025 Standard با Desktop Experience و رابط انگلیسی دارند و عضو دامین ad.example.com هستند. DC1 کنترلر دامین جداگانه است؛ RDS1 نقش‌های مدیریتی و RDSH1 اجرای نشست کاربران را بر عهده دارد. دو کلاینت Windows 11 Pro در شبکهٔ داخلی برای آزمون لازم است. نام‌ها نمونه‌اند؛ DNS، زمان، عضویت دامین، به‌روزرسانی‌ها و مدیریت از راه دور سرورها باید از قبل سالم باشند.

پیش از نصب، از سازندهٔ برنامه تأیید بگیرید که نسخهٔ برنامه روی Server 2025 و محیط چندکاربرهٔ RDS پشتیبانی می‌شود. مجوز هر کاربر یا دستگاه، دیتابیس، قفل سخت‌افزاری، چاپ و ذخیرهٔ فایل را روشن کنید. بازشدن برنامه با حساب مدیر اثبات سازگاری چندکاربره نیست؛ تعداد کاربر قابل پشتیبانی هم از نام Windows Server به دست نمی‌آید.

این طرح یک Session Host دارد و دسترس‌پذیری بالا نیست. حساب اجرای تغییرات باید مجوز لازم روی سرورها داشته باشد و از حساب عادی کاربران جدا باشد. در محیط موجود، پیش از نصب نقش‌ها یا راه‌اندازی مجدد، زمان تغییر، داده و نسخهٔ پشتیبان را مشخص کنید.

RD Web Access به‌تنهایی تونل امن RDP به داخل شبکه یا کلاینت HTML5 نیست. در این مثال، کاربر از صفحهٔ وب فایل اتصال را می‌گیرد و برنامهٔ Remote Desktop روی ویندوز اتصال را انجام می‌دهد. دسترسی بیرونی به طراحی جداگانهٔ VPN یا RD Gateway و کنترل احراز هویت نیاز دارد؛ پورت 3389 را مستقیماً روی اینترنت منتشر نکنید. مقایسهٔ روش‌های دورکاری به انتخاب مسیر کمک می‌کند.

برای سناریوی معمول کارکنان شرکت، مجوز سیستم‌عامل سرور، Windows Server CAL پایه و RDS CAL افزوده را جداگانه در نظر بگیرید؛ مجوز خود برنامه هم مستقل است. RDS CAL به‌طور معمول Per User یا Per Device انتخاب می‌شود، نه بر مبنای تعداد پنجره‌های باز یا صرفاً نشست‌های هم‌زمان. شروع‌شدن اتصال در دورهٔ مهلت اولیه، اثبات تکمیل مجوزها نیست.

در دامین، انتخاب Per User یا Per Device باید با خرید و نحوهٔ استفاده منطبق باشد. محدودنشدن فنی بعضی حالت‌های مصرف به معنای مجوز نامحدود نیست. شناسهٔ قرارداد، تعداد یا کلید نمونه از اینترنت را وارد نکنید؛ قبل از ادامه اطلاعات واقعی مجوزهای خود را آماده کنید. این مثال برای کارکنان داخلی شرکت است؛ شرایط ارائهٔ سرویس به اشخاص دیگر می‌تواند متفاوت باشد.

• روی RDS1، در Server Manager از Add Servers هر دو سرور RDS1 و RDSH1 را اضافه کنید. وضعیت Manageability و نام کامل آن‌ها را بررسی کنید؛ سروری با DNS یا مدیریت ناموفق را وارد مراحل بعد نکنید.
• در Add Roles and Features، گزینهٔ Remote Desktop Services installation را انتخاب کنید؛ سپس Standard deployment و Session-based desktop deployment را بزنید.
• برای RD Connection Broker و RD Web Access سرور RDS1 و برای RD Session Host سرور RDSH1 را انتخاب کنید. جمع‌بندی را کنترل کنید و نصب و راه‌اندازی مجدد لازم را فقط در زمان تعیین‌شده انجام دهید.
• پس از بازگشت سرورها، در Server Manager → Remote Desktop Services → Overview تکمیل استقرار و نقش‌ها را بررسی کنید. خطای نصب را با ساخت دستی اتصال مدیریتی دور نزنید.

از Overview نقش RD Licensing را به RDS1 اضافه کنید. سپس RD Licensing Manager را باز کنید، روی سرور Activate Server بزنید و فرایند فعال‌سازی را با اطلاعات واقعی سازمان انجام دهید. اگر اتصال خودکار مجاز نیست، روش Web Browser مستندشدهٔ مایکروسافت می‌تواند از رایانهٔ دیگری با اینترنت انجام شود؛ این مرحله با نصب CAL یکی نیست.

در RD Licensing Manager، روی سرور فعال‌شده Install Licenses را انتخاب کنید. برنامهٔ خرید، اطلاعات قرارداد یا کلید، نسخه، نوع و تعداد را مطابق مجوز واقعی وارد کنید. در پایان، بستهٔ نصب‌شده و وضعیت سرور را بازخوانی کنید؛ صرف فعال‌شدن License Server، CAL موردنیاز را اضافه نمی‌کند.

در Server Manager → Remote Desktop Services → Overview → Tasks → Edit Deployment Properties → RD Licensing، حالت Per Device را مطابق مجوزهای همین مثال انتخاب و RDS1.ad.example.com را به‌عنوان License Server معرفی کنید. اگر طرح واقعی شما Per User است، هر دو سمت باید با همان انتخاب سازگار باشند. اخطارهای Licensing Manager و ابزار RD Licensing Diagnoser روی Session Host را بررسی کنید؛ سیاست دامینِ مخالف تنظیم استقرار نیز باید پیدا شود.

حذف کلید رجیستری دورهٔ مهلت، تغییر ساعت یا ابزارهای دورزدن فعال‌سازی، بخشی از راه‌اندازی RDS نیست. تا وقتی خطای نوع، نسخه یا ارتباط با سرور مجوز مشخص نشده، نتیجه را آمادهٔ بهره‌برداری اعلام نکنید.

دو حساب عادی lab.rds1 و lab.rds2 و گروه امنیتی Global به نام GG-RDS-Users را با روش ساخت کاربران و گروه‌ها بسازید و فقط این دو حساب را عضو کنید. lab.control برای آزمون منع دسترسی بیرون این گروه می‌ماند. عضویت را با ورود تازهٔ کاربران اعمال و بررسی کنید.

• در Remote Desktop Services → Collections، گزینهٔ Tasks → Create Session Collection را بزنید. نام LAB-Apps را انتخاب و RDSH1 را به مجموعه اضافه کنید.
• در User Groups، دسترسی عمومی پیش‌فرض مانند Domain Users را برای این مثال با AD\GG-RDS-Users جایگزین کنید. فهرست نهایی باید مطابق کاربران هدف باشد.
• برای این آزمایش تک‌میزبانه، Enable user profile disks را غیرفعال کنید و Collection را بسازید. در این محیطِ فاقد سیاست پروفایل دیگر، پروفایل‌ها محلی خواهند بود؛ برای چند Session Host، طراحی نگهداری پروفایل و بازیابی آن باید جداگانه انجام شود.

اگر Collection تازه را با User Profile Disk ساخته‌اید و هنوز هیچ کاربر یا داده‌ای روی آن ندارید، فرمان زیر روی RDS1 آن ویژگی را برای همین مجموعه غیرفعال می‌کند. آن را روی مجموعهٔ کاری موجود برای جابه‌جایی پروفایل‌ها اجرا نکنید:

Set-RDSessionCollectionConfiguration -CollectionName "LAB-Apps" -DisableUserProfileDisk -ConnectionBroker "RDS1.ad.example.com"

در خواص مجموعه، تنظیمات امنیت و نیاز به Network Level Authentication را بررسی و فعال نگه دارید. انتقال کلیپ‌بورد، دیسک و چاپگر کلاینت را هم مطابق نیاز واقعی محدود کنید؛ روشن‌گذاشتن همهٔ انتقال‌ها پیش‌فرض کسب‌وکار شما نیست.

پیش از اتصال کاربران، گواهی معتبر با کاربرد Server Authentication برای نام سرویس و زنجیرهٔ مورداعتماد سرورها و کلاینت‌ها آماده کنید. در شبکهٔ داخلیِ مدیریت‌شده می‌توان از CA سازمان با توزیع درست اعتماد استفاده کرد. نام مورد استفادهٔ این مثال RDS1.ad.example.com است و باید با نام‌های مجاز گواهی سازگار باشد؛ نام‌های مستعار نیز باید در DNS و گواهی لحاظ شوند.

در Edit Deployment Properties → Certificates، برای نقش‌های RD Web Access و دو مورد Connection Broker، گواهی موجود مناسب را از فایل PFX دارای کلید خصوصی انتخاب و Apply کنید. دسترسی به PFX و رمز آن را محدود نگه دارید؛ فایل کلید خصوصی را برای کاربران نفرستید. اعتماد کلاینت به صادرکننده و زنجیرهٔ گواهی نیز باید جداگانه برقرار باشد.

بازشدن RDWeb با HTTPS تمام مسیر RDP را تأیید نمی‌کند. اگر هنگام اتصال، هشدار هویت Session Host، نام نامنطبق یا صادرکنندهٔ نامعتبر دیده می‌شود، گواهی سرویس مقصد و Listener مربوط را بررسی و اصلاح کنید. پذیرفتن دائمی هشدار یا غیرفعال‌کردن NLA راه تکمیل این مرحله نیست. این راهنما راه‌اندازی CA یا RD Gateway اینترنتی را پوشش نمی‌دهد.

برنامهٔ مورد تأیید را روی RDSH1 و طبق دستور نصب چندکاربرهٔ سازنده نصب کنید؛ نصب آن روی RDS1 باعث انتشار خودکار روی Session Host نمی‌شود. حساب عادی باید به محل داده، دیتابیس و مسیرهای لازم دسترسی محدود و صحیح داشته باشد. دادن دسترسی مدیر به همهٔ کاربران برای رفع اولین خطای برنامه، آزمون را بی‌معنا می‌کند.

در LAB-Apps، از RemoteApp Programs → Tasks → Publish RemoteApp Programs، برنامهٔ نصب‌شده را انتخاب کنید و مشخصات انتشار را بازخوانی کنید. اگر برنامه در فهرست نیست، مسیر اجرایی و روش پشتیبانی‌شدهٔ انتشار را با مستندات همان برنامه بررسی کنید؛ مسیر تصادفی یا فایل ناشناس اضافه نکنید. محدودیت کاربران برنامه نیز باید با گروه Collection هماهنگ باشد.

https://RDS1.ad.example.com/RDWeb

روی کلاینت با حساب عادی مجاز وارد صفحه شوید و RemoteApp را انتخاب کنید. فایل اتصال را با Remote Desktop Connection باز کنید و نام مقصد، ناشر و گواهی را بررسی کنید. برنامه روی RDSH1 اجرا می‌شود؛ نمایش پنجرهٔ آن روی کلاینت، نصب محلی برنامه یا اجرای آن داخل مرورگر نیست.

ورود موفق به صفحهٔ RDWeb به‌تنهایی به معنای مجازبودن اجرای هر برنامه نیست. برای آزمون حساب غیرمجاز، اتصال همان منبع منتشرشده را با اعتبارنامهٔ lab.control نیز بررسی کنید؛ از حساب مدیر به‌جای او استفاده نکنید. بستن پنجره ممکن است فقط Disconnect باشد و نشست را باز بگذارد؛ پایان کار را با Log off و پس از ذخیره‌سازی بسنجید. موفقیت دو کاربر، برآورد ظرفیت تولید برای ده‌ها کاربر نیست؛ بار واقعی برنامه، منابع و رشد باید جداگانه اندازه‌گیری شوند.

اگر آیکون دیده نمی‌شود، انتشار برنامه و گروه‌های مجاز را بررسی کنید. اگر آیکون هست ولی اتصال خطا می‌دهد، نام مقصد، گواهی، دسترسی شبکه و Licensing را جدا کنید. خطای ذخیرهٔ داده داخل برنامه می‌تواند از مجوز فایل یا خود برنامه باشد؛ برای سهم اشتراکی از آزمون Share و NTFS استفاده کنید.

نسخه‌ها، نقش هر سرور، نام Collection، کاربران مجاز، نسخه و نوع CAL، گواهی‌ها و نتیجهٔ آزمون برنامه را ثبت کنید؛ تاریخ انقضای گواهی و مسئول رسیدگی هم مشخص باشد. کلید مجوز، رمز و PFX را در مستند عمومی نگذارید. برای استفادهٔ بیرون شرکت، طراحی مسیر دسترسی و احراز هویت باید پیش از انتشار سرویس تکمیل شود.

اگر فقط آزمایش را جمع می‌کنید، پس از ذخیرهٔ کار و Log off کاربران، انتشار برنامه و Collection آزمایشی را از مدیریت RDS بردارید. ابتدا داده و پروفایل‌های لازم را حفظ کنید؛ حذف نقش‌ها یا پوشه‌های پروفایل روی سرور موجود را راه بازگشت عمومی ندانید. تغییرات تولید باید بر اساس طرح و نسخهٔ پشتیبان همان محیط برگردانده شود.