درس ۵ مسیر استقرار ServiceDesk Plus ــ On-Premises | پیش‌نیاز: کاربران، تکنسین‌ها و نقش‌ها | فهرست درس‌ها

کاربر ایمیل می‌فرستد و تیکت ایجاد می‌شود. کارشناس پاسخ می‌دهد، اما چیزی به کاربر نمی‌رسد. تیم می‌گوید «ایمیل وصل است»؛ درحالی‌که فقط نیمی از مسیر کار می‌کند. در این درس، تنظیم ایمیل ServiceDesk Plus را به سه آزمون جدا تبدیل می‌کنیم: ورود پیام، خروج پاسخ و برگشت پاسخ کاربر به همان مکالمه.

سناریو برای صندوق آزمایشی Microsoft 365 در محیط تجاری عمومی و روش IMAPS به‌همراه SMTP با OAuth است. این تنظیمات را به Gmail، Exchange داخلی، محیط‌های ملی Microsoft یا روش Microsoft Graph تعمیم ندهید. پیش از اجرا، پشتیبانی Build و مجازبودن پروتکل‌ها در سیاست سازمان را کنترل کنید. این مقاله راهنمای غیرفعال‌کردن سیاست‌های امنیتی برای عبور از خطا نیست.

پیش از اتصال صندوق واقعی

یک صندوق اختصاصی آزمایش تهیه کنید که فقط پیام‌های تمرینی داشته باشد. مسئول صندوق، مدیر مجاز ثبت برنامه، نشانی نهایی ServiceDesk و مسئول نگهداری اعتبارنامه برنامه باید مشخص باشند. صندوقی با سال‌ها مکاتبه واقعی را بدون برنامه انتقال به نصب آزمایشی وصل نکنید.

در برگه اتصال، حساب ورود به صندوق را از نام نمایشی فرستنده جدا بنویسید. همچنین مشخص کنید دریافت پیام‌های فرستندگان ناشناس در پایلوت مجاز است یا نه. اولین موفقیت فنی نباید باعث شود سامانه آزمایشی ناخواسته به کانال عمومی درخواست سازمان تبدیل شود.

گام اول: ثبت برنامه برای OAuth

در Admin → Mail Server Settings نشانی Redirect برنامه را بردارید. مدیر مجاز در Microsoft Entra، از App registrations → New registration برنامه را ثبت می‌کند و Redirect URI از نوع Web را مطابق آن قرار می‌دهد. Application Client ID، نشانی‌های authorization و token و مقدار Value مربوط به Client Secret در تنظیمات ServiceDesk قرار می‌گیرند؛ Secret ID جای Value نیست. اعتبار زمانی Secret و مسئول تمدید را ثبت کنید. مجوزها و Consent باید متناسب با پروتکل و سیاست Tenant تأیید شوند. راهنمای رسمی ثبت برنامه و اتصال Azure.

برای انتخاب مجوزهای IMAP و SMTP و Scopeها، علاوه بر راهنمای محصول، مستند رسمی Microsoft درباره OAuth این پروتکل‌ها را تطبیق دهید. دسترسی Microsoft Graph، Scope مربوط به IMAP و تنظیم SMTP سه نام قابل جایگزینی نیستند. مجوز اضافی را صرفاً برای آزمون‌وخطا به برنامه ندهید.

گام دوم: ایمیل ورودی

با SDAdmin، بخش Incoming Mail Server Settings را باز کنید. برای این سناریو، روش IMAPS و احراز هویت OAuth را انتخاب کنید، نام صندوق و اطلاعات برنامه را وارد کنید و نشانی Redirect را با نشانی واقعی بازشده در مرورگر تطبیق دهید. پس از Save، ورود و Consent باید با حساب متناظر تنظیمات صندوق انجام شود. دوره دریافت پیام را مشخص کنید و از Fetch a sample mail برای آزمون اتصال استفاده کنید؛ این آزمون می‌تواند قدیمی‌ترین پیام صندوق را دریافت کند. منبع: Incoming Mail Settings.

طبق جدول رسمی تنظیمات ایمیل، مقادیر این سناریو عبارت‌اند از میزبان outlook.office365.com، پورت 993 و TLS فعال. Scope ورودی https://outlook.office365.com/IMAP.AccessAsUser.All,offline_access است. این مقادیر را با نوع محیط Microsoft 365 خود تطبیق دهید؛ پسوندهای محیط‌های ملی متفاوت‌اند.

گام سوم: ایمیل خروجی

در Outgoing Mail Server Settings، روش SMTP و OAuth را انتخاب کنید. سرور، نام نمایشی، نشانی فرستنده، حساب صندوق، TLS و اطلاعات برنامه را تکمیل کنید. پس از ذخیره و تأیید مجوزها، با Send a sample mail به یک گیرنده آزمایشی پیام بفرستید. تنظیمات فرستنده باید با مجوز ارسال حساب هماهنگ باشد؛ نوشتن یک آدرس دیگر در فرم، مجوز استفاده از آن آدرس ایجاد نمی‌کند. منبع: راهنمای ایمیل خروجی.

در جدول رسمی یادشده، برای SMTP محیط عمومی Microsoft 365، میزبان smtp.office365.com، پورت 587 و TLS فعال آمده است؛ Scope مربوط https://outlook.office365.com/SMTP.Send,offline_access است. اگر سیاست صندوق یا Tenant این مسیر را مجاز نمی‌داند، ابتدا مدیر ایمیل باید روش مورد تأیید سازمان را تعیین کند؛ تغییر تصادفی پورت یا حذف TLS راه‌حل نیست.

آزمون پذیرش: یک مکالمه کامل

ورود: از حساب درخواست‌کننده آزمایشی، ایمیلی با عنوان یکتا و یک پیوست غیرحساس کوچک بفرستید. زمان ارسال، رسیدن به صندوق و ایجاد درخواست را ثبت کنید. نام درخواست‌کننده، متن فارسی و پیوست را در تیکت بررسی کنید. رسیدن پیام به صندوق، هنوز اثبات تبدیل درست آن به درخواست نیست.

خروج: کارشناس از داخل همان درخواست پاسخ بدهد. در صندوق درخواست‌کننده، فرستنده، متن، پیوست و موضوع را بررسی کنید. پیام ممکن است ارسال شده باشد ولی در پوشه دیگری قرار گرفته باشد؛ نتیجه را با مشاهده واقعی گیرنده ثبت کنید، نه صرفاً ناپدیدشدن پیام از صف ارسال.

برگشت: درخواست‌کننده به همان پیام پاسخ دهد، بدون اینکه شناسه‌ها و موضوع را عمداً تغییر دهد. بررسی کنید پاسخ به مکالمه همان تیکت اضافه شده و درخواست ناخواسته جدیدی ایجاد نشده است. رفتار واقعی باید با تنظیمات مکالمه و سیاست سازمان تطبیق داده شود.

چهار نقطه برای عیب‌یابی هدفمند

اگر OAuth به خطای Redirect می‌رسد، نشانی دقیق ثبت‌شده و نشانی مرورگر را مقایسه کنید. اگر Consent انجام نمی‌شود، حساب استفاده‌شده و سیاست تأیید مجوزها را بررسی کنید. اگر دریافت موفق و ارسال ناموفق است، تنظیمات خروجی را مستقل آزمون کنید. اگر اتصال موفق است ولی تیکت ساخته نمی‌شود، سیاست پذیرش فرستنده و پردازش پیام را بررسی کنید؛ همه خطاها مربوط به رمز نیستند.

هنگام تحویل گزارش، زمان، مرحله شکست و متن خطا کافی‌تر از چند تصویر نامرتب است. Client Secret، Access Token و Refresh Token را در تصویر، تیکت عمومی یا گزارش آموزشی قرار ندهید. داده حساس لاگ نیز پیش از اشتراک باید کنترل شود.

از اتصال ایمیل تا توزیع درخواست

پس از قبولی این سه آزمون، به سراغ مسیر‌دهی درخواست با Email-to-Ticket و گروه‌ها بروید. قواعد توزیع را قبل از تثبیت مسیر پایه ایمیل پیچیده نکنید. مالک پیگیری انقضای Secret و خطاهای دریافت را نیز در سند بهره‌برداری مشخص کنید؛ راه‌اندازی امروز بدون مسئول نگهداری، مسئله فرداست.

سخن پایانی

ایمیل زمانی وصل است که یک گفت‌وگوی واقعی بتواند سالم رفت‌وبرگشت کند. سه چراغ جدا برای دریافت، ارسال و ادامه مکالمه داشته باشید؛ روشن‌بودن یکی، تاریکی دو مسیر دیگر را جبران نمی‌کند.

این درس، آموزش تألیفی بر اساس منابع رسمی پیوندشده است، نه ترجمه کامل صفحات سازنده. مرحله بعد را در نقشه راه ServiceDesk Plus دنبال کنید. بازبینی منابع: ۱۸ سپتامبر ۲۰۲۶.