وبلاگ نت‌آرامآموزش، تجربه و راهکارهای زیرساخت

رفع خطای 0x1 در Task Scheduler ویندوز سرور، قدم‌به‌قدم

آموزش یافتن علت کد 0x1 با بررسی History، مسیر Start in، حساب اجرا، PowerShell و دسترسی شبکه در Windows Server.

انتشار:
توسط تیم فنی نت‌آرام
۸ دقیقه زمان مطالعه
۰ دیدگاه
محتوای تخصصی، ساده و کاربردی
هماهنگ با هویت حرفه‌ای نت‌آرام
بازگشت به لیست مقالات
تصویر شاخص مقاله رفع خطای 0x1 در Task Scheduler ویندوز سرور، قدم‌به‌قدم در وبلاگ نت‌آرام
محتوای آموزشی وبلاگ نت‌آرام
یک اسکریپت را دستی اجرا می‌کنید و درست کار می‌کند، اما همان کار در Task Scheduler با نتیجه 0x1 تمام می‌شود. تفاوت معمولاً در محیط اجراست: مسیر شروع متفاوت است، کار با حساب دیگری اجرا می‌شود یا برنامه به فایل و شبکه‌ای که در نشست شما در دسترس است دسترسی ندارد. البته 0x1 به‌تنهایی علت مشخصی را ثابت نمی‌کند؛ ممکن است خود برنامه هنگام اجرا کد ۱ را برگردانده باشد.
در این راهنما اول گزارش همان اجرا را می‌خوانیم، بعد مسیر، حساب و خروجی را جداگانه آزمایش می‌کنیم. مثال‌ها در Windows Server روی سرور مجازی ایران و سرور اختصاصی ایران قابل استفاده‌اند. نام کار ReportJob و پوشه C:\Jobs\Report نمونه هستند. اگر کار اصلی ارسال ایمیل، جابه‌جایی پول یا پاک‌کردن فایل انجام می‌دهد، برای عیب‌یابی آن را پشت سر هم اجرا نکنید؛ از یک کار آزمایشی بی‌خطر استفاده کنید.

۱. زمان اجرا و نتیجه را پیدا کنید

با Remote Desktop وارد سرور شوید، منوی Start را باز کنید و Task Scheduler را جست‌وجو کنید. از سمت چپ به Task Scheduler Library و پوشه کار مورد نظر بروید. در فهرست، Last Run Time و Last Run Result را با زمان مشکل مقایسه کنید. اگر کار اصلاً در آن زمان اجرا نشده، اول Trigger و شرایط اجرا را بررسی کنید؛ نتیجه اجرای قدیمی لزوماً مربوط به مشکل جدید نیست.
در PowerShell نیز می‌توانید اطلاعات همان کار را بخوانید. مسیر نمونه زیر برای کاری است که در پوشه MyTasks ساخته شده است؛ اگر کار در ریشه کتابخانه است، مسیر آن را \ بگذارید:
کد / دستورGet-ScheduledTaskInfo -TaskName 'ReportJob' -TaskPath '\MyTasks\' | Format-List LastRunTime,LastTaskResult,NextRunTime,NumberOfMissedRuns
PowerShell ممکن است نتیجه را به‌صورت عدد ده‌دهی 1 و پنل به‌شکل 0x1 نشان دهد. در زبانه History رویدادهای زمان اجرای مورد نظر و نتیجه هر Action را ببینید. اگر تاریخچه خاموش است، گزینه Enable All Tasks History را در بخش Actions فعال کنید و سپس یک آزمون بی‌خطر جدید انجام دهید؛ فعال‌کردن آن گزارش اجراهای گذشته را بازسازی نمی‌کند.
رویداد تکمیل یک Action به معنی درست‌بودن کار تجاری نیست. نام برنامه و کد بازگشتی را بخوانید و بعد خروجی واقعی را بررسی کنید. اگر رویداد می‌گوید برنامه اصلاً شروع نشده، اول مسیر فایل اجرایی یا دسترسی حساب را دنبال کنید؛ اگر برنامه شروع و با کد ۱ تمام شده، علت را در گزارش و مستندات همان برنامه جست‌وجو کنید.

۲. تنظیمات فعلی را ثبت کنید

روی کار کلیک راست و Properties را انتخاب کنید. در زبانه‌های General، Triggers و Actions نام حساب، شیوه اجرا، زمان‌بندی، برنامه، آرگومان و مسیر شروع را یادداشت کنید. اگر اختیار دارید، با گزینه Export یک نسخه XML از تنظیم همان کار در پوشه‌ای خصوصی نگه دارید؛ فایل می‌تواند نام حساب و مسیرهای داخلی داشته باشد. این نسخه پشتیبان خود اسکریپت یا داده‌های آن نیست.
برای دیدن Actionها از PowerShell، با نام و مسیر واقعی کار:
کد / دستورGet-ScheduledTask -TaskName 'ReportJob' -TaskPath '\MyTasks\' | Select-Object -ExpandProperty Actions | Format-List Execute,Arguments,WorkingDirectory
خروجی ممکن است آرگومان حساس داشته باشد؛ پیش از فرستادن به شخص دیگر آن را بررسی کنید. در این مرحله چیزی را تغییر نداده‌ایم. یک کار ممکن است چند Action داشته باشد، بنابراین مطمئن شوید خطا مربوط به کدام مرحله است.

۳. مسیر برنامه و پوشه شروع را اصلاح کنید

روی Action مربوط در زبانه Actions دکمه Edit را بزنید. برای اجرای یک فایل PowerShell با Windows PowerShell، نمونه زیر سه فیلد جداگانه دارد:
  • Program/script: مسیر کامل فایل اجرایی، مانند C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe.
  • Add arguments: مقدار -NoProfile -File "C:\Jobs\Report\export.ps1" با مسیر واقعی اسکریپت.
  • Start in: پوشه C:\Jobs\Report بدون قراردادن نام فایل اسکریپت در این فیلد.
اگر مسیر اسکریپت فاصله دارد، قرارگرفتن آن داخل علامت نقل‌قول در آرگومان اهمیت دارد. فیلد Start in فقط پوشه کاری است؛ در آن از مسیر پوشه بدون نقل‌قول اضافی استفاده کنید. اگر برنامه از PowerShell 7 یا یک مفسر دیگر استفاده می‌کند، مسیر اجرایی و سازگاری همان نسخه را جایگزین کنید. مایکروسافت پوشه کاری را به‌عنوان بخشی از تنظیم Action معرفی می‌کند.
برای اطمینان از وجود فایل‌ها، در PowerShell حساب مدیر بخوانید:
کد / دستورTest-Path -LiteralPath 'C:\Jobs\Report\export.ps1' Test-Path -LiteralPath 'C:\Jobs\Report' -PathType Container
خروجی True یعنی مسیر در نشست فعلی دیده می‌شود؛ هنوز ثابت نمی‌کند حساب کار زمان‌بندی‌شده به آن دسترسی دارد. اگر False است، مسیر و نام واقعی را اصلاح کنید. داخل خود اسکریپت هم بهتر است فایل‌های همراه را بر اساس محل اسکریپت پیدا کنید، نه پوشه اتفاقی شروع. برای PowerShell نسخه ۳ به بعد می‌توان از این الگو استفاده کرد:
کد / دستور$configPath = Join-Path -Path $PSScriptRoot -ChildPath 'settings.json' Test-Path -LiteralPath $configPath
این قطعه فقط نمونه است؛ آن را به‌جای مسیر مرتبط در اسکریپت خود و پس از تهیه نسخه قبلی به کار ببرید. $PSScriptRoot در فایل اسکریپت، پوشه همان اسکریپت را نشان می‌دهد. قبل از تغییر مسیر خروجی، محل نوشتن داده و مجوز آن را هم مشخص کنید.

۴. حساب اجرای کار و مجوز آن را ببینید

در زبانه General نام حساب را با حسابی که کار را دستی آزمایش می‌کند مقایسه کنید. برای دیدن Principal از PowerShell:
کد / دستورGet-ScheduledTask -TaskName 'ReportJob' -TaskPath '\MyTasks\' | Select-Object -ExpandProperty Principal | Format-List UserId,LogonType,RunLevel
ممکن است حساب سرویس به پوشه، فایل تنظیم یا محل خروجی دسترسی نداشته باشد. اگر خود حساب قفل شده، ابتدا راهنمای رفع قفل حساب ویندوز سرور را ببینید و از تکرار ورود ناموفق جلوگیری کنید. مجوزهای NTFS همان مسیر را ببینید:
کد / دستورicacls 'C:\Jobs\Report'
این دستور مجوزها را گزارش می‌کند، اما عضویت گروه، مجوزهای ارث‌رسیده و دسترسی مؤثر را باید با هم تفسیر کرد. به حسابی که کار واقعاً با آن اجرا می‌شود فقط دسترسی لازم برای همان عملیات بدهید. گزینه Run with highest privileges تنها زمانی مفید است که آن کار واقعاً به دسترسی مدیریتی نیاز داشته باشد و حساب نیز مجاز باشد؛ فعال‌کردن آن برای همه کارها جای اصلاح مسیر یا مجوز فایل را نمی‌گیرد. حق Log on as a batch job و سیاست دامنه نیز ممکن است مانع شروع کار شوند؛ راهنمای مایکروسافت درباره Access denied را ببینید.
اگر اسکریپت به یک درایو شبکه مانند Z: وابسته است، توجه کنید نگاشت درایو معمولاً مربوط به همان نشست کاربر است و ممکن است در نشست غیرتعاملی کار وجود نداشته باشد. در صورت سازگاری برنامه از مسیر UNC مثل \\fileserver\reports استفاده کنید و مجوز share و NTFS را برای حساب اجرای کار بررسی کنید. نوع ورود نیز مهم است: برخی حالت‌های بدون ذخیره گذرواژه دسترسی شبکه ندارند. روش مجاز احراز هویت را با مدیر دامنه تعیین کنید و گذرواژه را در اسکریپت یا آرگومان خط فرمان قرار ندهید.

۵. یک آزمون بی‌خطر با همان شرایط بسازید

برای تشخیص مسیر و حساب، یک فایل آزمایشی جدید به نام probe.ps1 در پوشه‌ای که حساب کار اجازه نوشتن دارد بسازید. این نمونه فقط یک خط در فایل گزارش اضافه می‌کند:
کد / دستورtry { $line = '{0} | user={1} | directory={2}' -f (Get-Date -Format 's'), $env:USERNAME, (Get-Location).Path Add-Content -LiteralPath 'C:\Jobs\Report\probe.log' -Value $line -ErrorAction Stop exit 0 } catch { exit 1 }
پوشه گزارش را با مسیر آزمایشی مجاز خود جایگزین کنید. یک کار آزمایشی جدا با همان حساب، همان نوع ورود و تنظیمات مسیر بسازید و Action آن را به probe.ps1 بدهید. پس از یک اجرای دستی آن کار آزمایشی، گزارش را بخوانید:
کد / دستورGet-Content -LiteralPath 'C:\Jobs\Report\probe.log' -Tail 5
اگر فایل ساخته شد، نام حساب و پوشه شروع را با انتظار خود مقایسه کنید. اگر ساخته نشد، مسیر، مجوز نوشتن و History کار آزمایشی را بررسی کنید؛ نبود فایل به‌تنهایی دقیقاً نمی‌گوید کدام مرحله شکست خورده است. پس از پایان، کار و فایل‌های آزمایشی خود را با روال معمول و پس از شناسایی دقیق کنار بگذارید. هرگز کار اصلی را با این آزمون جایگزین نکنید.

۶. خطای خود اسکریپت را پیدا و نتیجه را تأیید کنید

اگر آزمون مسیر و حساب موفق بود اما کار اصلی هنوز کد ۱ می‌دهد، در اسکریپت اصلی به دنبال گزارش خطا، فایل ورودی گمشده و خروجی دستورهای خارجی باشید. بعضی برنامه‌ها خطا را در خروجی ثبت می‌کنند و با کد غیرصفر خارج می‌شوند. همچنین PowerShell و برنامه خارجی شیوه گزارش خطای یکسانی ندارند؛ کد بازگشتی و لاگ همان برنامه را بخوانید، نه اینکه برای مخفی‌کردن خطا exit 0 را به انتهای اسکریپت اضافه کنید.
اگر اجرای فایل به‌دلیل سیاست PowerShell متوقف شده، وضعیت سیاست‌ها و امضای فایل را بررسی کنید:
کد / دستورGet-ExecutionPolicy -List Get-AuthenticodeSignature -FilePath 'C:\Jobs\Report\export.ps1'
سیاست سازمان و اعتبار ناشر را با مدیر مربوط تطبیق دهید؛ خاموش‌کردن سراسری سیاست امنیتی راه‌حل عمومی نیست. پس از اصلاح، در زمان مناسب یک اجرای کنترل‌شده از کار واقعی انجام دهید و هم History و هم حاصل واقعی را بررسی کنید: مثلاً فایل گزارش تازه، تعداد رکوردها یا مقصد انتقال. سپس وقوع اجرای زمان‌بندی‌شده بعدی را نیز تأیید کنید. نتیجه 0x0 نشانه بازگشت کد صفر است، اما به‌تنهایی صحت محتوای خروجی را تضمین نمی‌کند.
اشتراک‌گذاری:
لینکدینتلگرامایکس
مقاله قبلی
مقاله قبلی وجود ندارد.

دیدگاه‌ها (۰)

دیدگاه‌های تاییدشده و پاسخ‌های تیم نت‌آرام