Brett Posted July 17 Share Posted July 17 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? Quote Link to comment Share on other sites More sharing options...
Brett Posted July 17 Author Share Posted July 17 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 Quote Link to comment Share on other sites More sharing options...
Employee Chris Halstead Posted July 23 Employee Share Posted July 23 You will need to login with an account that exists in UEM in order to switch the enrollment. I would follow this guide to setup SAML between Workspace ONE UEM and Google. https://darrylmiles.blog/2021/06/13/setting-up-single-sign-on-sso-to-workspace-one-uem-self-service-portal-ssp-and-admin-console/ Look in %programdata%\Airwatch\UnifiedAgent\Logs for the log details - the device enrollment log would be the most help. But you will need to get the account you want to switch the enrollment to into UEM. 1 Quote Link to comment Share on other sites More sharing options...
Brett Posted July 24 Author Share Posted July 24 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? Quote Link to comment Share on other sites More sharing options...
Employee Dylan Babcock Posted July 24 Employee Share Posted July 24 (edited) Not positive it is related, but what is the authentication flow like between WS1 UEM and Google Workspace? Do you have WS1 Access in the mix, or are users JIT provisioned directly from Google Workspace to WS1 UEM? Do you get the "request failed" error when you try to enroll by installing hub and enrolling through the GUI directly with Google Workspace User's credentials (not doing command line enrollment with staging user)? Edited July 24 by Dylan Babcock Quote Link to comment Share on other sites More sharing options...
Brett Posted July 25 Author Share Posted July 25 Hi Dylan, Quote Do you get the "request failed" error when you try to enroll by installing hub and enrolling through the GUI directly with Google Workspace User's credentials (not doing command line enrollment with staging user)? No, the device enrolls as expected without error. Quote Link to comment Share on other sites More sharing options...
Employee Dylan Babcock Posted July 25 Employee Share Posted July 25 What is the identity flow like right now? Strictly between Google Workspace and WS1 UEM? Or is WS1 Access involved? Are these users JIT provisioned with SAML, or is everything tied to AD in the background? What attributes are you passing from Google Workspace to WS1? Quote Link to comment Share on other sites More sharing options...
Brett Posted August 6 Author Share Posted August 6 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 Quote Link to comment Share on other sites More sharing options...
Employee Dylan Babcock Posted August 6 Employee Share Posted August 6 (edited) Gotcha. I wanted to make sure that ExternalId was making its way to WS1, as that can cause some issues with Windows Hub specifically. Worth noting, I don't think that having a special character (like @ from the email address) is officially supported, though in my own testing it never really caused an issue. Next, check a user in WS1 Access and make sure that you see that the user has an ExternalId listed. A follow up question - how are users being pushed to WS1 UEM? Using the AirWatch Provisioning Adapter? Or JIT provisioned using the AirWatch application? Edited August 6 by Dylan Babcock 1 Quote Link to comment Share on other sites More sharing options...
Brett Posted August 9 Author Share Posted August 9 Quote Next, check a user in WS1 Access and make sure that you see that the user has an ExternalId listed. Confirmed. Quote A follow up question - how are users being pushed to WS1 UEM? Using the AirWatch Provisioning Adapter? Or JIT provisioned using the AirWatch application? 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 Quote Link to comment Share on other sites More sharing options...
Michael Troelstrup Posted September 7 Share Posted September 7 does a hub based enrollment work with no script ? just a regular agent enrollment. I think Chris is on the right track, I think an ObjectGUID/Unique ID is needed to check the device out from the staging user in the script to a new user. I believe a fix for this will be in the next console update as seen in the screenshot below, I have a similar issue with a client and ping instead of Google and discussed it with an Omnissa PM Quote Link to comment Share on other sites More sharing options...
Employee Sascha Warno Posted September 9 Employee Share Posted September 9 The new setting is for silent checkout of the device to the logged in user. What version of UEM are you on? This seems to do be checkout in which the user needs to sign into Hub to check the device out. Possibly because the authentication times out it fails. So one reason could be a network issue during auth, are you sure the devices can reach UEM, Access and Google to go through the authentication flow? Any proxy or firewall that could block any of the required connections? Second could be timeout of the authentication session itself at either Google or Access and failed auth because of that. I would check the local Hub logs, the Access audit logs for the time and user(might not show as no succesful auth) and Google sign in logs. If there is a timeout in authentication there should be failed attempts in the Access audit logs, potentially in the backend logs if it couldn't correlate the authentication request send to Google and the late return of the authentication. Quote Link to comment Share on other sites More sharing options...
Brett Posted Tuesday at 11:51 AM Author Share Posted Tuesday at 11:51 AM 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 Quote Link to comment Share on other sites More sharing options...
Employee Sascha Warno Posted Tuesday at 12:27 PM Employee Share Posted Tuesday at 12:27 PM A recording of the behavior would be great as well, the authentication is prompted each time but fails the first time? I would right click the Hub icon and collect the device side logs. Most likely this also requires the server side DeviceManagement and DeviceServices and API logs to see what is happening here. The best way forward would be a support ticket. Some questions on the config in general, I assume the source of authentication in the UEM enrollment settings is Access?! Auth seems to happen and greenbox is getting it's oauth token and should register the device to the user. Your version of Hub is 23.10?! Did you try with a newer version and what version is the console? Quote Link to comment Share on other sites More sharing options...
Brett Posted yesterday at 04:19 PM Author Share Posted yesterday at 04:19 PM Hi Sascha, Quote Your version of Hub is 23.10?! Did you try with a newer version and what version is the console? 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 Quote A recording of the behavior would be great as well, the authentication is prompted each time but fails the first time? 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. Quote I would right click the Hub icon and collect the device side logs. 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. Quote Link to comment Share on other sites More sharing options...
Brett Posted yesterday at 04:23 PM Author Share Posted yesterday at 04:23 PM 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. Quote Link to comment Share on other sites More sharing options...
Brett Posted 13 hours ago Author Share Posted 13 hours ago 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 Quote Link to comment Share on other sites More sharing options...
Brett Posted 11 hours ago Author Share Posted 11 hours ago 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() Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.