Glyn Dobson

Glad you managed to get it resolved. SaaS definitely has many benefits over hosting your own deployment and you'll be able to take advantage of the newer features that have not made their way into On-Prem.

You shouldn't need AWCM on both servers, only one instance is needed. The AWCM instance used by the system is shown under site URL's in the console (example below is from a cloud UEM tenant but the screen is the same). If cases where AWCM is not on its own sever, it is typically installed on DS:

Unfortunately, you will need to re-install. There is no way to re-encrypt the password outside of the installer. See this KB for the steps: https://kb.omnissa.com/s/article/2960970

AWCM is a java application and uses its own keystore for its certificates. You should be able to use the keytool command to update the certificate. The keystore is called awcm.keystore and is located in C:\AirWatch\AirWatch [version]\AWCM\config To update the certificate Make a backup of the keystore (awcm.keystore file) List the keystore contents. If using the self signed cert, the password is password: keytool -list -keystore acm. keystore Delete the current awcmcert certificate: keytool -delete -alias "awemcert" -keystore awcm.keystore Import the pfx file containing the full chain and private key. The source keystore password is the password set when creating/exporting the pfx: keytool -importkeystore -srckeystore myserver.pfx -destkeystore acm. keystore -deststoretype jks Change the alias to match the original certificate alias: keytool -changealias -alias "559811f1-4b62-42d5-995b-ec4eea8542fb" -destalias awcmcert -keystore acm.keystore List the certificates again for visual confirmation of the updated certificate: keytool -list -keystore awcm. keystore Restart the AirWatch Cloud Messaging Service from Windows Services Note: The password for the keystore is stored in an encrypted format in the file awcm.properties. This is the password that the system will use to open the keystore. If the password is changed, AWCM will fail to start. New certificate is now being used and matches the cert in the screenshot above:

Yes, that said I believe the script execution result and the logs are collected separately. Try doing a Workflow sync from the console and see if that causes the logs to be populated. You can also check the troubleshooting tab to see if there were any errors during the execution (timeout etc).

Do you have any kind of Android VPN setup, either for VPN or Mobile SSO? If so, try turning that off and see if it helps. Can you browse to the Access URL from chrome on the device? Try both from work profile and personal profile.

Scenario: One of your end users just won the lottery and has resigned. His laptop was returned to IT and now IT has to reprovision the device for a new user, or the more likely scenario One of your users has a damaged Windows install and needs to be re-imaged Normal reprovisioning steps would be: IT takes possession of the device Use PXE/USB to reimage it, possibly after downloading latest ISO from MS Joins it to the domain logs in and runs command line enrollment script to enroll as the staging user Shuts down the device and provides it to the end user The better option, use DSP Online. This process is used to register the devices serial number with the DSP service to enroll the device in the correct UEM tenant as well as join the device to the domain. Combine this with some scripting, and you have a virtually hands-off automated way to re-image and enroll the device in one step. To find out about DSP Online with self-registration, take a look at the docs here: https://docs.omnissa.com/bundle/workspace_one_drop_ship_provisioningV2306/page/DSPOnlineInfo.html If you want to take a look at the automated process, the scripts and docs can be found here: https://github.com/GlynDobson/WorkspaceONE/tree/main/DSP/imaging

Short version, yes. Longer version: To use Okta to auth into UEM you would need to configure SAML under Directory Services to use Okta. If you want to use Okta to auth into the Access portal, you would need to configure Okta as the IDP inside Access and set the appropriate rules in the Default Access Policy to send the auth request over to Okta. For Mobile SSO to work, Access must be the IDP so you would need to set Access as an IDP inside Okta and then set the appropriate routing rules to send the authentication request over to Access. On the Access side, make sure your Default Access Policy is set so that the rules for Android and iOS are the first ones in the list (for that device type) to be evaluated and set them to use Mobile SSO as the authentication method. I'd suggest adding Device Compliance in there too

I use the UEM API's with pretty much every customer I have worked with. I prefer to use PowerShell though since my Python scripting is limited. Here are some examples that I have created API scripts for: Adding devices to a Smart Group Updating Smart Group criteria Adding Tags to Devices Uploading Internal applications to the console Checking in/out devices Bulk Deleting devices Bulk deleting accounts Removing duplicate devices (device has unenrolled and re-enrolled resulting in new device record) Getting device lists Forcing a sensor sync in bulk (useful when waiting for sensor execution to occur) And if anyone wants it, there are a couple of PowerShell API templates here to get you started: https://github.com/GlynDobson/WorkspaceONE/tree/main/API/UEM API documentation can be found here: https://{console URL}/api/help/ If you're SaaS, take a look here on how to create an oAuth client for use with the API's: https://docs.omnissa.com/bundle/WorkspaceONE-UEM-Console-BasicsVSaaS/page/UsingUEMFunctionalityWithRESTAPI.html#create_an_oauth_client_to_use_for_api_commands_saas

The link that you reference is for the Okta classic engine; you should check that this is what you are using. If you are using the Okta Identity Engine, device trust is implemented using Okta Verify: https://help.okta.com/oie/en-us/content/topics/identity-engine-upgrade/dt-upgrade-considerations.htm The flow in the link you referenced is using Workspace ONE Access as the IDP. This is the recommended approach to setting up Mobile SSO for Android/iOS or Certificate Based authentication for Windows/macOS. You would need to add Workspace ONE Access as an Identity Provider in Okta in order to this.

There is also a good selection of sensors available from the Workspace ONE Intelligence Marketplace. In Intelligence, go to Marketplace > Sensors. If your UEM instance is tied to the Cloud Services Platform you can deploy directly from here, otherwise you can download them an deploy them manually.

The script log should contain your write-output. The example output below is from this example script that uninstalls java $apps = Get-WmiObject -Class Win32_Product | Where-Object {($_.Name -match "Java") -and ($_.vendor -match "oracle")} $result = "" if ($apps) { foreach($app in $apps) { $appName = $app.Name $appVendor = $app.vendor $result = $result + "Uninstalling $appName by $appVendor |" $app.uninstall() | Out-Null } } else { $result = "Oracle Java not found" } Write-Output $result

The Windows Update for Business process has evolved considerably over the past couple of years. The supported approach is now a ring-based deployment using deferrals instead of approvals. You will want to setup a few profiles with differing deferral values starting at no deferral for your UAT/Pilot with the next ring being 0+n days based on how long it will take you to validate the update. You would then progress through the next rings until your device fleet is updated. If there are any issues, you can use the pause and rollback functionality. Note that Quality updates (your "Patch Tuesday" updated) can be deferred for a maximum of 30 days with Feature updates being deferred for up to 365 days (although you would use the Target Release Version setting for this rather than deferral). If you need to pause an update, you can only do this for up to 35 days. Here is a good TechZone article on Windows Updates with the most current and up to date details. https://techzone.omnissa.com/managing-updates-windows-devices-workspace-one-operational-tutorial This is a link to the Microsoft technical documentation on the settings that are used to control Windows Update: https://learn.microsoft.com/en-us/windows/client-management/mdm/policy-csp-update