I´m testing WIN10 silent enrollment using different parameter combinations as described here :
Silent Enrollment Parameters and Values
I have tested some combinations that work as aspected to enroll my Win10 devices but there is one that I can´t get to work. Maybe I'm doing wrong or I'm not understanding it correctly.
The description of the parameter SECURITYTYPE=<B(asic)/D(Directory)> says :
"EOBO Workflow Only: Needed if user account is added to Workspace ONE UEM console during enrollment process".
So I'm assuming that I can stage the device with a proper staging user I've created in WS1 UEM for that purpose and after that create a new WS1 UEM user providing the credentials in the script and enroll the device with this user . Somethig like this
msiexec /i c:\Temp\AirwatchAgent.msi /q ENROLL=Y SERVER=xxxxx.awmdm.com LGName=OU-LAB USERNAME=Stageuser PASSWORD=******* STAGEUSERNAME=NewUser SECURITYTYPE=B STAGEPASSWORD=*******
This is only one of the combinations I've tested for this workflow and seems to make sense. but is not working. When I have a look at the logs I can see that the OU and staging user are validated correctly but the NewUser is not created in WS1. Instead of this I'm asked to provide an existing user
ValidateGroupIdentifier: STARTED Executing
ValidateGroupIdentifier: ENDED Executing
ValidateLoginCredentials: STARTED Executing
ValidateLoginCredentials: ENDED Executing
ValidateOnBehalfOfUsername: STARTED Executing
ERROR_CODE: , ERROR_MESSAGE: Server returned enrollment failed with Status Fail , Message Enrollment user is not found. Please provide an existing user., ValidateOnBehalfOfUsername: ENDED Executing
So, this parameter is not for creating the final user as explained in the parameter description?, Is my script wrong? Am I misunderstanding the purpose of this parameter?
Every comment will be welcomed and if someone can show me an example of how to do this I would be thankful
The command line that we use is:
msiexec /i AirwatchAgent.msi /qn IMAGE=N ENROLL=Y SERVER=XXXXX LGName=OGID USERNAME=Staging@OG.com PASSWORD=XXXX ASSIGNTOLOGGEDINUSER=Y DOWNLOADWSBUNDLE=True
That enrolls the device as the staging account and switches to the first user who logs in after that. It will also install the latest version of the WS1 self service catalog. The user that we use is the built in UPN which you can find by going to the OG you want to enroll to, Groups and Settings > All Settings > Devices & Users > Windows > Windows Desktop > Staging & Provisioning. The Username is the 'UPN' and the password is the 'Password' or 'Secret' depending on which version of WS1 you have installed.
Thanks for your reply Aaron!
I¨ve also make some tests with examples like yours but in these cases the user who logs in after enrolling with the staging user must already exist in WS1 UEM to get the device assigned (usually an active directory user). I suppose this is your case. Right?
What I'm trying to do is to create a new user in WS1 UEM from within the script , that means that user does not exist previously in WS1, and assign him the device . This is what I understand the option SECURITYTYPE is used for. As I said in my original post , maybe I'm misunderstanding the purpose ot this parameter or there are additional configs in WS1 UEM necessary to achieve this but I don´t find a word about this.
Ahh yes, we have all of our AD users synced in WorkSpace ONE already.
I haven't looked too much into it but there is an API command to create/sync a user, you could try adding something like that in your script to add the user before you do the enrollment. We do something similar with tagging of application installs.
This with the API sounds interesting. Will have a look at this...
Thank you Aaron
Hava nice weekend!
if you create you own local staging user in WSO UEM and enable the staging parameters in the Advanced Tab and run your script with this user instead of the build-in staging user for WIN10 your WIN10 device will be automatically assign to the AD user that is currently logged in. You don´t need to wait for a restart and a new login.
I´ve tested it and it works
Hope this helps you
Thanks for that. We had some issues when using that method before we upgraded (was 1903 now 2005), I can't remember what they were now but that was the solution that VMWare told us to get around the issue. It may no longer be an issue, we will need to do more testing.
Sorry, I just wanted to jump on here to ask un unrelated question. Where exactly do you pull those enrollment logs from? I'm trying to tweak my silent enroll settings and it would be super helpful to look at those logs you're referencing but I don't know where they are sitting.
Check out this troubleshoot cheat sheet for all the details https://via.vmw.com/W10CheatSheet
More details in this tutorial https://via.vmw.com/W10Troubleshooting
during enrollment process a small Hub Icon appears bottom right on the taskbar (maybe you must clic on "Show Hiden Icons" to see it). If I right clic on this icon y have the options "Enroll" and "Troubleshoot -> Collect logs" . Select "Collect Logs" and in the generated logs folder search in "Agents", then "Workspace ONe Intelligent Hub" and there you will find a txt file named "DeviceEnrollment".
There is where I got the information mentioned in my post
Hope this helps you
By the way,
thanks foy your great VMWorld session "Out with the Old, In with the New Cloud-Based GPOs", Josue. Very interesting for people who are dealing with this..
Thank you! Please let me know if you ever have any feedback. You can reach out directly via any of my profiles: Josué Negrón's posts on VMware Digital Workspace Tech Zone