Brett

Digging even deeper in taskscheuduler logs in C:\ProgramData\Airwatch\UnifiedAgent\Logs\TaskScheduler-#########... we see thsi failure. 2024-09-19T08:41:29.8722Z [ 4476: 53] [ERR] Generic Device Reassignment Exception - Device Reassignment Failed. { SourceContext: "VMware.Hub.Win32Agent.Reassignment.UserReassignment.UserReassignmentManager", ProcessName: "TaskScheduler", EnvironmentUserName: "WORKGROUP\SYSTEM" } VMware.Hub.Win32Agent.Common.Error.CustomException.UIErrorException at VMware.Hub.Win32Agent.ClientCommunication.PostEnrollmentUiHandler.<SendMessageAsync>d__11.MoveNext() --- 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 VMware.Hub.Win32Agent.ClientCommunication.PostEnrollmentUiHandler.<GetCheckoutUserResponseAsync>d__8.MoveNext() --- 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 VMware.Hub.Win32Agent.Reassignment.UserReassignment.ManualCheckoutHandler.<GetVidmReassignmentResponseAsync>d__15.MoveNext() --- 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 VMware.Hub.Win32Agent.Reassignment.UserReassignment.ManualCheckoutHandler.<CreateVidmReassignmentResponseAsync>d__13.MoveNext() --- 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 VMware.Hub.Win32Agent.Reassignment.UserReassignment.ManualCheckoutHandler.<PerformCheckoutAsync>d__8.MoveNext() --- 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 VMware.Hub.Win32Agent.Reassignment.UserReassignment.UserReassignmentManager.<CheckOutAsync>d__25.MoveNext() --- 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) at VMware.Hub.Win32Agent.Reassignment.UserReassignment.UserReassignmentManager.<ReassignDeviceToCurrentUserAsync>d__22.MoveNext()

Also, how can I find the commands for the AirWatchagent.msi? The images on this page seem to be broken https://techzone.omnissa.com/onboarding-windows-devices-using-command-line-enrollment-workspace-one-operational-tutorial#command-line-enrollment-scenarios

I have also taken another Windows device with a fresh image of Windows from Lenovo, created a local user during OOBE, downloaded the AirwatchAgent.msi, ran the enrollment/install command from the CMD, created a new user, logged in and got the same failure.

Hi Sascha, Hub version 23.10 must have been the latest version when I created the Factory Provisioning PPKG file back in July when I created this post. The XML that is generated adds the below line and I assumed that this line would update the client, but I guess not. <CommandLine>powershell $timeout = new-timespan -Minutes 10; $sw = [diagnostics.stopwatch]::StartNew(); do { $Failed = $false; Try { if( (Invoke-WebRequest -Uri https://prod.esr.vmwservices.com/esr/services/api/platforms/windowspc/oems/any/apps/com.airwatch.workspaceoneunifiedagentbundle/latest?osVersion=10.0.10586 -Headers @{'"Accept"' = '"application/vnd.vmware.esr.get-latest-app-update-v1+json"'} -Method Head).StatusCode -ne '200') {$Failed = $true} } catch { $Failed = $true } finally {start-sleep -seconds 5} } while ($Failed -And $sw.elapsed -lt $timeout)</CommandLine> Anyways, I created a new package with the latest hub version and I still ran into the same errors... it is a bit worse now as the work around isn't working anymore. If I am checking in the correct place, the Workspace One UEM Console version is 24.2.0.13 I have attached a modified version of the video we created for our end users to do the work around. Unfortunately the gif is too large to attach here. Below are from the DeviceReassignment.log with my latest test using the newest hub. I was unable to get the enrollment screen to pop up again after clicking the "Device registration incomplete" notification. Every time I rebooted the same logs would appear 2024-09-18T14:51:05.7976Z [ 4652: 35] [DBG] Is system account True { SourceContext: "AW.Win32.Utilities.ProcessHelper", VMware.Hub.Logging.Log.Name: "DeviceReassignment", ProcessName: "TaskScheduler", EnvironmentUserName: "WORKGROUP\SYSTEM" } 2024-09-18T14:51:05.8465Z [ 4652: 35] [INF] DuplicateTokenExWrapper: S\b { SourceContext: "AW.Win32.Utilities.ProcessHelper", VMware.Hub.Logging.Log.Name: "DeviceReassignment", ProcessName: "TaskScheduler", EnvironmentUserName: "WORKGROUP\SYSTEM" } 2024-09-18T14:51:05.8465Z [ 4652: 35] [INF] Found SID S-1-5-21-125669919-3427927803-4135305715-1005 for account SYSADMI-DEVICENAME\MYUSER { SourceContext: "AW.Win32.Utilities.GenericHelper.Helper", VMware.Hub.Logging.Log.Name: "DeviceReassignment", ProcessName: "TaskScheduler", EnvironmentUserName: "WORKGROUP\SYSTEM" } 2024-09-18T14:51:05.8465Z [ 4652: 35] [DBG] Checking if reassignment is needed { SourceContext: "VMware.Hub.Win32Agent.Reassignment.DeviceReassignment.Implementation.EvaluateReassignment", VMware.Hub.Logging.Log.Name: "DeviceReassignment", ProcessName: "TaskScheduler", EnvironmentUserName: "WORKGROUP\SYSTEM" } 2024-09-18T14:51:07.2584Z [ 4652: 34] [INF] Device reassignment feature flags: ServerSideFFEnabled-False, ClientSideFFEnabled-True, IsMultiUserDevice- True, IsReassignmentCommandReceived- False, MultiUserFetureEnable- False { SourceContext: "AW.Win32.Utilities.DeviceReassignmentUtility", VMware.Hub.Logging.Log.Name: "DeviceReassignment", ProcessName: "TaskScheduler", EnvironmentUserName: "WORKGROUP\SYSTEM" } 2024-09-18T14:51:07.2584Z [ 4652: 34] [DBG] Multi user feature disabled { SourceContext: "VMware.Hub.Win32Agent.Reassignment.DeviceReassignment.Implementation.EvaluateReassignment", VMware.Hub.Logging.Log.Name: "DeviceReassignment", ProcessName: "TaskScheduler", EnvironmentUserName: "WORKGROUP\SYSTEM" } 2024-09-18T14:55:20.2453Z [ 4804: 12] [DBG] Is system account True { SourceContext: "AW.Win32.Utilities.ProcessHelper", VMware.Hub.Logging.Log.Name: "DeviceReassignment", ProcessName: "TaskScheduler", EnvironmentUserName: "WORKGROUP\SYSTEM" } 2024-09-18T14:55:20.2760Z [ 4804: 12] [INF] DuplicateTokenExWrapper: H\b { SourceContext: "AW.Win32.Utilities.ProcessHelper", VMware.Hub.Logging.Log.Name: "DeviceReassignment", ProcessName: "TaskScheduler", EnvironmentUserName: "WORKGROUP\SYSTEM" } 2024-09-18T14:55:20.2770Z [ 4804: 12] [INF] Found SID S-1-5-21-125669919-3427927803-4135305715-1005 for account DEVICENAME\MYUSER { SourceContext: "AW.Win32.Utilities.GenericHelper.Helper", VMware.Hub.Logging.Log.Name: "DeviceReassignment", ProcessName: "TaskScheduler", EnvironmentUserName: "WORKGROUP\SYSTEM" } 2024-09-18T14:55:20.2926Z [ 4804: 12] [DBG] Checking if reassignment is needed { SourceContext: "VMware.Hub.Win32Agent.Reassignment.DeviceReassignment.Implementation.EvaluateReassignment", VMware.Hub.Logging.Log.Name: "DeviceReassignment", ProcessName: "TaskScheduler", EnvironmentUserName: "WORKGROUP\SYSTEM" } 2024-09-18T14:55:23.0545Z [ 4804: 6] [INF] Device reassignment feature flags: ServerSideFFEnabled-False, ClientSideFFEnabled-True, IsMultiUserDevice- True, IsReassignmentCommandReceived- False, MultiUserFetureEnable- False { SourceContext: "AW.Win32.Utilities.DeviceReassignmentUtility", VMware.Hub.Logging.Log.Name: "DeviceReassignment", ProcessName: "TaskScheduler", EnvironmentUserName: "WORKGROUP\SYSTEM" } 2024-09-18T14:55:23.0545Z [ 4804: 6] [DBG] Multi user feature disabled { SourceContext: "VMware.Hub.Win32Agent.Reassignment.DeviceReassignment.Implementation.EvaluateReassignment", VMware.Hub.Logging.Log.Name: "DeviceReassignment", ProcessName: "TaskScheduler", EnvironmentUserName: "WORKGROUP\SYSTEM" } 2024-09-18T15:07:48.5494Z [ 4768: 10] [DBG] Is system account True { SourceContext: "AW.Win32.Utilities.ProcessHelper", VMware.Hub.Logging.Log.Name: "DeviceReassignment", ProcessName: "TaskScheduler", EnvironmentUserName: "WORKGROUP\SYSTEM" } 2024-09-18T15:07:48.5650Z [ 4768: 10] [INF] DuplicateTokenExWrapper: H\b { SourceContext: "AW.Win32.Utilities.ProcessHelper", VMware.Hub.Logging.Log.Name: "DeviceReassignment", ProcessName: "TaskScheduler", EnvironmentUserName: "WORKGROUP\SYSTEM" } 2024-09-18T15:07:48.5650Z [ 4768: 10] [INF] Found SID S-1-5-21-125669919-3427927803-4135305715-1005 for account DEVICENAME\MYUSER { SourceContext: "AW.Win32.Utilities.GenericHelper.Helper", VMware.Hub.Logging.Log.Name: "DeviceReassignment", ProcessName: "TaskScheduler", EnvironmentUserName: "WORKGROUP\SYSTEM" } 2024-09-18T15:07:48.5650Z [ 4768: 10] [DBG] Checking if reassignment is needed { SourceContext: "VMware.Hub.Win32Agent.Reassignment.DeviceReassignment.Implementation.EvaluateReassignment", VMware.Hub.Logging.Log.Name: "DeviceReassignment", ProcessName: "TaskScheduler", EnvironmentUserName: "WORKGROUP\SYSTEM" } 2024-09-18T15:07:50.5268Z [ 4768: 10] [INF] Device reassignment feature flags: ServerSideFFEnabled-False, ClientSideFFEnabled-True, IsMultiUserDevice- True, IsReassignmentCommandReceived- False, MultiUserFetureEnable- False { SourceContext: "AW.Win32.Utilities.DeviceReassignmentUtility", VMware.Hub.Logging.Log.Name: "DeviceReassignment", ProcessName: "TaskScheduler", EnvironmentUserName: "WORKGROUP\SYSTEM" } 2024-09-18T15:07:50.5268Z [ 4768: 10] [DBG] Multi user feature disabled { SourceContext: "VMware.Hub.Win32Agent.Reassignment.DeviceReassignment.Implementation.EvaluateReassignment", VMware.Hub.Logging.Log.Name: "DeviceReassignment", ProcessName: "TaskScheduler", EnvironmentUserName: "WORKGROUP\SYSTEM" } It looks like it is a Multi user issue? Since there are multiple accounts on the device? The initial local admin account to run the installation & enrollment command and then the account of the end user that will be using the device and doing the next enrollment steps. Earlier, I even tried enabling 'Multi User Devices' under Advanced > Staging for the Staging account, but I still got these errors. The setting has since been reverted back. 2024-09-18T15:07:50.5268Z [ 4768: 10] [INF] Device reassignment feature flags: ServerSideFFEnabled-False, ClientSideFFEnabled-True, IsMultiUserDevice- True, IsReassignmentCommandReceived- False, MultiUserFetureEnable- False { SourceContext: "AW.Win32.Utilities.DeviceReassignmentUtility", VMware.Hub.Logging.Log.Name: "DeviceReassignment", ProcessName: "TaskScheduler", EnvironmentUserName: "WORKGROUP\SYSTEM" } Could it have to do with "Feature" being misspelled in "MultiUserFetureEnable- False" in the above log line? I created another local user and logged in to find the enrollment login screen again, but it gave the same failure message and clicking the "Device regsitration failed to complete" did not work again. I looked in %programdata%\Airwatch\UnifiedAgent\Log again and no new logs were generated from the enrollment attempt, just the same repeated logs when signing into the windows user.

Hi Sascha, I have checked the Workspace One Access logs and Google SAML logs and I see the following... attached I then did the work around of clicking the Windows notification "Device Registration Incomplete" and waited at least one minute (several in this test scenario) before trying to login and enroll again and I see the exact same logs in both WS1 Access & Google WS

Confirmed. Unless I am checking the wrong place, I am seeing a Web App in the Workspace ONE Access console for 'Workspace ONE UEM Provisioning' using SAML 2.0

Hi Dylan, It looks like users are synced through WS1 Access, using JIT and SAML with Google. Attributes being passed: Primary email > email Primary email > ExternalID First name > firstName Last name > lastName Organization unit path > OrganizationPath Primary email > userName

Hi Dylan, No, the device enrolls as expected without error.

Hi Chris, Thank you for your response. The accounts do exist in Workspace ONE UEM and are able to enroll devices. We have found that waiting around a minute after the first failed attempt, the enrollment will work with the same user that tried to login the first time. However, it is difficult to get back to enrollment screen. One successful method we have found is clicking the "Device Registration Incomplete" Windows notification. However, if we miss this notification, we just get the staging account information shared in the previous post and have to resort to unenrolling the device with the "awprocesscommand.exe Unenroll" command, and reinstall the Workspace One agent, which kind of defeats the purpose of pre-enrolling the device with the staging account. Is there another command or method we can use to bring up the enrollment (Google login) screen again?

Okay, after some more testing, I find that the first user that I try to enroll the device with fails and that if I try with a second different user it works??? This is not ideal for end users who do not have two accounts for this "work around." Also if I check the logs in %programdata%\Airwatch\UnifiedAgent\Logs\DeviceEnrollment-xxxxxx.txt the time stamps are a couple hours off from the system time and I do not think I am seeing the user enrollment there, just the staging account, but I am not sure? Also attaching the previous errors

Hello, I am having a lot of trouble with enrolling a device as a user after the device has been pre-enrolled with our staging account. The device is not domain joined and local user accounts are used. WS1 is installed with the following command: msiexec /i c:\Recovery\OEM\AirwatchAgent.msi /qn ENROLL=Y SERVER=(server info here) LGNAME=(needed info here) USERNAME=(blah blah) PASSWORD=(password here) ASSIGNTOLOGGEDINUSER=n The device is enrolled successfully with the staging account. A local account is created for the end user and after logging in with the account, I get the pop up to enroll into WS1 as expected. After attempting to login with my Google Workspace credentials and performing the 2fa prompt, I get the following unknown error... Request Failed Please retry, then contact your IT Administrator if this problem persists. Unexpected Error occured. After clicking 'OK', the hub just shows the status as enrolled with the staging account. Logging out of the windows account and signing back in again brings back the enrollment screen, but I get the same error. I also tried to restart the device and now the Workspace ONE Intelligent Hub will not even open. I tried to send the repair command from the UEM console, but this did not help. I do see that the device still checks in. Trying to repair the hub via the control panel also does not help. Are there any local logs on the device that I can check to see why the initial 'Unexpected Error' occurs?