ریموت دسکتاپ مایکروسافت؛ از ترمینال تا راه‌اندازی RDP و RDS
مقدمه
وقتی کارمند از یک تین‌کلاینت وارد نرم‌افزار حسابداری روی سرور می‌شود، اجرای برنامه و ذخیرهٔ داده‌ها در مرکز انجام می‌شود و کاربر تصویر و کنترل برنامه را روی میز خودش دارد. این الگو از ترمینال‌های اشتراک زمانی شروع شد و امروز در Remote Desktop Services به مجموعه‌ای برای انتشار برنامه و دسکتاپ تبدیل شده است.
خلاصه
برای مدیریت یک رایانه، اتصال Remote Desktop کافی است. برای ارائهٔ دسکتاپ یا برنامه به گروهی از کاربران، طراحی RDS، تعیین ظرفیت، مجوز مناسب و مسیر امن اتصال لازم است. RDP پروتکل اتصال است، RDS مجموعهٔ سرویس‌هاست و RDSH محلی است که نشست‌های کاربران را اجرا می‌کند.
از ترمینال متنی تا Windows Server
ترمینال‌های اولیه صفحه‌کلید و نمایشگر یا چاپگر را به یک رایانهٔ مرکزی متصل می‌کردند. در CTSS دانشگاه MIT که نخستین نمایش عمومی آن در ۱۹۶۱ بود، سیستم مرکزی زمان پردازش را بین کاربران تقسیم می‌کرد. ترمینال متنی آن دوره فقط یکی از نمونه‌های تاریخی پردازش متمرکز است. در محیط گرافیکی امروز، در کنار متن، خروجی تصویری و رویدادهای ورودی بین میزبان و کلاینت جابه‌جا می‌شوند.
مایکروسافت و Citrix در ۱۹۹۷ توافق توسعه و مجوز متقابل امضا کردند. مایکروسافت در ژوئن ۱۹۹۸ عرضهٔ Windows NT Server 4.0 Terminal Server Edition را اعلام کرد. در نسل Windows 2000 و Windows Server 2003 نام Terminal Services رایج بود. در Windows Server 2008 R2 نام مجموعه به Remote Desktop Services تغییر کرد و انتشار برنامه از طریق RemoteApp و مدیریت نشست‌ها در معماری RDS ادامه یافت. در نسل‌های جدید Windows Server، همین خانواده برای انتشار نشست سازمانی در دسترس است.
نقش‌ها و مسیر یک اتصال
RDP اطلاعات گرافیکی را از میزبان به کلاینت می‌آورد و ورودی‌هایی مانند ماوس و صفحه‌کلید را برمی‌گرداند. انتقال صدا، چاپگر، کلیپ‌بورد و درایو به قابلیت کلاینت و سیاست سازمان بستگی دارد. RemoteApp به کاربر اجازه می‌دهد فقط پنجرهٔ برنامهٔ منتشرشده را باز کند. برنامه همچنان روی میزبان اجرا می‌شود.
RD Session Host برنامه‌ها و نشست‌های چندکاربره را اجرا می‌کند. RD Connection Broker کاربر را به میزبان مناسب می‌فرستد و می‌تواند او را به نشست قبلی برگرداند. RD Web Access منابع منتشرشده را در اختیار کاربر می‌گذارد. RD Gateway مسیر مجاز از شبکهٔ بیرونی را فراهم می‌کند و RD Licensing مدیریت مجوزهای دسترسی را انجام می‌دهد. در یک محیط نشست‌محور، کاربران یک سیستم‌عامل میزبان را به اشتراک می‌گذارند. در VDI مبتنی بر VM، دسکتاپ در ماشین مجازی مجموعه اجرا می‌شود و الگوی مدیریت و ظرفیت متفاوت است.
| اصطلاح | وظیفه | مثال |
|---|---|---|
| RDP | پروتکل ارتباطی | ارسال تصویر نشست و دریافت ورودی کاربر |
| RDSH | نقش میزبان نشست | اجرای حسابداری برای چند کاربر روی یک Windows Server |
| RemoteApp | شیوهٔ ارائهٔ برنامه | باز کردن فقط پنجرهٔ حسابداری |
| RDS CAL | مجوز دسترسی | مجوز متناسب با کاربر یا دستگاه و نسخهٔ میزبان |
راه‌اندازی آزمایشی و ورود به بهره‌برداری
۱. کاربران هم‌زمان، نوع برنامه‌ها، نیاز به USB و چاپ، چندمانیتوره‌بودن، زبان و نرم‌افزارهای وابسته را مشخص کنید. پشتیبانی نرم‌افزار از اجرای چندکاربره را از سازنده بررسی کنید. برای محیط عملیاتی نسخهٔ پشتیبانی‌شدهٔ Windows Server را انتخاب و یک محیط آزمایشی جدا با حساب‌های عادی بسازید.
۲. در سناریوی دامنه‌ای، DNS، همگام‌سازی ساعت و عضویت سرورها در دامنه را بررسی کنید. در Server Manager از Remote Desktop Services installation استفاده کنید، نقش‌های RDSH، Broker و Web Access را طبق راهنمای مایکروسافت تخصیص دهید و یک Session Collection با گروه کاربران مجاز بسازید. برای آغاز، یک برنامهٔ سبک و نسخهٔ آزمایشی برنامهٔ اصلی را منتشر کنید.
۳. سرور RD Licensing را فعال کنید، بستهٔ مجوز سازگار را نصب کنید و حالت Per User یا Per Device را با مجوز و طراحی هماهنگ کنید. برای شیفت‌هایی که دستگاه‌های مشترک دارند Per Device و برای کاربران نام‌داری که از چند دستگاه متصل می‌شوند Per User گزینهٔ قابل بررسی است. جدول سازگاری نسخه‌ها و حق استفاده از نرم‌افزارها را جداگانه بررسی کنید.
۴. اتصال سازمانی را با گواهی معتبر، NLA و محدودسازی گروه‌ها تحویل دهید. برای دسترسی برون‌سازمانی از مسیر کنترل‌شده مانند RD Gateway یا VPN سازمانی با MFA در لایهٔ مناسب استفاده کنید. پورت RDP را مستقیماً روی اینترنت منتشر نکنید. چاپگر، انتقال فایل و کلیپ‌بورد را بر اساس نیاز کاری محدود کنید.
۵. با کاربر عادی ورود، قطع اتصال و بازگشت به همان نشست، اجرای برنامه، چاپ و جداسازی داده‌ها را تست کنید. سپس گروه آزمایشی را با بار واقعی بسنجید. زمان ورود، مصرف CPU و RAM، تأخیر ذخیره‌سازی و کیفیت تجربه را در ساعت شلوغ ثبت کنید. برنامهٔ پشتیبان، پایش رویدادها و راه بازگشت را پیش از تحویل مشخص کنید.
عیب‌یابی از کلاینت تا سرور
اگر اتصال تشکیل نمی‌شود، از نام میزبان، DNS، مسیر شبکه و اعتبار گواهی شروع کنید. اگر ورود انجام می‌شود اما برنامه دیده نمی‌شود، گروه Collection و تنظیمات انتشار RemoteApp را بررسی کنید. در خطاهای مجوز، حالت مجوزدهی، دسترسی به RD Licensing و سازگاری نسخه‌ها را با RD Licensing Diagnoser بررسی کنید. در کندی فراگیر، ابتدا از بار میزبان و ذخیره‌سازی نمونه بگیرید و آن را با تأخیر شبکه و کیفیت تجربهٔ یک گروه کوچک مقایسه کنید.
برای آزمون ساده از ویندوز در شبکهٔ مجاز، مدیر می‌تواند از Remote Desktop Connection یا mstsc به مقصد مشخص‌شده توسط سازمان متصل شود. تفاوت خطای احراز هویت با خطای اتصال اهمیت دارد. پیام گواهی ناشناس را با بررسی نام و زنجیرهٔ اعتماد پیگیری کنید.
پرسش‌های متداول
هر RDP به RDS CAL نیاز دارد؟
بابت استفادهٔ کاربران نهایی از امکانات RDS در Windows Server، مجوز دسترسی RDS طبق شرایط محصول بررسی می‌شود. اتصال مدیریتی محدود و اتصال به یک رایانهٔ ویندوزی سناریوهای متفاوتی دارند و تنظیم Remote Desktop روی یک دستگاه، حق استفادهٔ چندکاربره ایجاد نمی‌کند.
می‌توان RDS CAL قدیمی را برای میزبان جدید به کار برد؟
نسخهٔ مجوز باید با نسخهٔ میزبان سازگار باشد. مجوز قدیمی‌تر میزبان جدیدتر را پوشش نمی‌دهد. سازگاری نسخهٔ RD Licensing را هم با جدول رسمی بررسی کنید.
چند کاربر روی یک سرور جواب می‌دهد؟
با برنامهٔ واقعی و کاربران نماینده اندازه‌گیری کنید. حسابداری سبک با تماس تصویری، پردازش گرافیکی یا گزارش‌گیری سنگین ظرفیت یکسانی ندارد.
منابع اصلی
- راهنمای تاریخی CTSS، دانشگاه MIT
- اعلام همکاری مایکروسافت و Citrix در ۱۹۹۷
- اعلام عرضهٔ Terminal Server Edition در ۱۹۹۸
- تغییر نام Terminal Services در مایکروسافت
- مشخصات فنی RDP
- نقش‌های RDS
- راهنمای رسمی استقرار
- سازگاری و مجوزهای RDS CAL
