Hope all is well! When you have a second, can you send a screenshot of the values that you’re filling in for the time/date dialog box prior to submitting? I’d like to see if I can potentially recreate the behavior in our test environment.
Apologies for the slow response! Could you share RCT log files from your device from %APPDATA%\RecastRCT\Logs folder to our support: email@example.com? In the support email, could you also share us your operating system’s region format (short date & short time)?
Before sending the log files, could you try to schedule the restart with other “Scheduled Task Options” and “Restart Options” to see if changing those makes any difference?
My organization is experiencing this same behavior. We are largely using version 4.8.2110.5301, and suddenly starting to get multiple failures of scheduled restarts with the same error message. The Scheduler.log displays the following:
2023-01-12 08:02:07,215  ERROR Scheduler reportProgress()
System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.Exception: The scheduled task creation did not return a process ID. Return Value: Recast.RCT.Server.Plugins.Abstractions.CimInterfaces.RecastCimMethodParameter
at NowMicro.Recast.RCT.Server.Plugins.SystemInformation.SystemInformation2.ScheduleShutdown(String name, Boolean restart, Boolean skipIfUserLoggedIn, Boolean giveUserPromptToCancel, String taskName, DateTime startDate, ScheduleFrequency frequency, ScheduleModifier modifier, DateFormat dateFormat, ISettingProvider settingProvider, IRecastCimSessionProvider sessionProvider, Int32 delay, String userMessage, Nullable`1 endDate)
--- End of inner exception stack trace ---
at System.RuntimeMethodHandle.InvokeMethod(Object target, Object arguments, Signature sig, Boolean constructor)
at System.Reflection.RuntimeMethodInfo.UnsafeInvokeInternal(Object obj, Object parameters, Object arguments)
at System.Reflection.RuntimeMethodInfo.Invoke(Object obj, BindingFlags invokeAttr, Binder binder, Object parameters, CultureInfo culture)
--- End of stack trace from previous location where exception was thrown ---
at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
at System.Runtime.CompilerServices.TaskAwaiter.ValidateEnd(Task task)
We upgraded to 4.9.2210.3302, but receive the same behavior across multiple target endpoints, and SCCM technicians working from different stations. Executing mass restart via straight powershell (bypassing RCT) succeeds, and CANCELLING restarts with RCT (says that it) succeeds without error.
The proposed solution of ‘Use IP Address Instead of Computer Name’ did not resolve the issue in our case.