Dylan Babcock

A request I have heard from customers before is the ability to allow users, who are not full-administrators on a Windows endpoint, the ability to perform certain actions or open certain applications in an elevated context. Intune has this ability (called endpoint privilege management). For comparison, Dynamic Environment Manager (commonly associated with our Horizon offering) has had this ability for some time, though called Privilege Elevation. Through the integration with DEM and Workspace ONE, we can support privilege elevation on enrolled Windows devices. If you do not have a license for DEM, you can also accomplish a similar process (though this will result in the end user being added or removed from the Administrators group) through the scripts/sensors functionality in Workspace ONE. Both processes, whether through DEM integration or through sensors/scripts functionality, are outlined in my blog post here: https://www.seinanrv.com/articles/workspace-one-uem/privilege-elevation-for-windows.

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?

Understood. At this point, I think the proper path forward is to submit that as an idea at https://wsone.ideas.aha.io/?category=6787856840400996014. I appreciate you sharing the example.

@Thomas TERRIEN Curious, is there a specific ADMX_xxx policy you're looking to implement? Baselines are still a thing if you want to implement any GPO's that aren't available via Policy CSP yet, but just curious to see an example.

Agreed, this is the way it should be done. I think Policy Builder will not be updated in the future in favor of the Windows (Beta) platform type which has the same CSP's that Policy Builder does.

What platform(s) are you referencing? Last seen generally comes from a device's communication with the AWCM (AirWatch Cloud Messaging) channel that is specific to Workspace ONE. That is to say, you can still query a device and push commands/profiles/apps to a device despite it not having checked in. In this circumstance, we'd use APNS (iOS) or FCM (Android) to push the command to the device. Then it would check in with the AWCM channel and update the last seen time. Generally, devices should be checking in every ~4 hours or so on a rolling interval. That said, if you have a device that hasn't checked in, are you able to query it and have it check in?

Gotcha. I speculate the reason behind having hub open automatically is to get users to sign in so that it switches devices from the staging user to the actual end user / gives them a gentle reminder to sign in so that any user-based resources also land.

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?

Is this part of imaging a device, or is this being done manually through cmd / a batch script? Ideally I think you'd want to use a staging user to install Hub in an administrator account. Then, once installed, when the user signs in next, they'd be prompted to sign into hub (unless you're using AD and the ASSIGNTOLOGGEDINUSER flag). To answer your question directly, beyond the quiet flag, I am not sure we can specifically suppress hub popping up... but depending on the enrollment flow we'd want hub to appear for a user to sign in to assign the device to them in UEM.

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)?

How are you trying to stage those devices? Just installing hub via the MSI app, or using command line based enrollment command?