Glyn Dobson

Not sure what going on there. The Add-Type was missing so added it to the code block below. When I run this, $CMSHeader is set correctly. This is pointing to my certificate, if it can't find the certificate it throws an "The recipient certificate is not specified" which would be expected. I couldn't paste and run your code in due to formatting issues but it looks the same as what I have. Only thing I can think is that there is some kind of certificate issue. Looks like the line its failing on is: $SignedCMS.ComputeSignature($CMSigner) After running my code below, $SignedCMS = and $CMSigner = Might be worth checking to see what these two values are set to prior to running ComputeSignature. Side note, I would also recommend editing your post above and removing your tenantAPIKey since you would want to keep this internal only. Add-Type -AssemblyName System.Security [uri]$Url = 'https://mdm.airfrance.fr/api/mdm/dep/profiles/search?PageSize=40000' $Certificate = Get-ChildItem -Path Cert:\CurrentUser\my | Where-Object Subject -eq 'CN=8091:APICBA' $bytes = [System.Text.Encoding]::UTF8.GetBytes(($Url.AbsolutePath)) $MemStream = New-Object -TypeName System.Security.Cryptography.Pkcs.ContentInfo -ArgumentList (,$bytes) -ErrorAction Stop $SignedCMS = New-Object -TypeName System.Security.Cryptography.Pkcs.SignedCms -ArgumentList $MemStream,$true -ErrorAction Stop $CMSigner = New-Object -TypeName System.Security.Cryptography.Pkcs.CmsSigner -ArgumentList $Certificate -Property @{IncludeOption = [System.Security.Cryptography.X509Certificates.X509IncludeOption]::EndCertOnly} -ErrorAction Stop $null = $CMSigner.SignedAttributes.Add((New-Object -TypeName System.Security.Cryptography.Pkcs.Pkcs9SigningTime)) $SignedCMS.ComputeSignature($CMSigner) $CMSHeader = '{0}{1}{2}' -f 'CMSURL','`1 ',$([System.Convert]::ToBase64String(($SignedCMS.Encode()))) Write-Output -InputObject $CMSHeader

Try running this and see if it gives anything extra. Update the URL with the full URL and also change the CN for the cert, left mine in as an example. [uri]$Url = 'https://as1784.awmdm.com/api/mdm/devices?searchBy=DeviceId&id=154335' $Certificate = Get-ChildItem -Path Cert:\CurrentUser\my | Where-Object Subject -eq 'CN=8091:APICBA' $bytes = [System.Text.Encoding]::UTF8.GetBytes(($Url.AbsolutePath)) $MemStream = New-Object -TypeName System.Security.Cryptography.Pkcs.ContentInfo -ArgumentList (,$bytes) -ErrorAction Stop $SignedCMS = New-Object -TypeName System.Security.Cryptography.Pkcs.SignedCms -ArgumentList $MemStream,$true -ErrorAction Stop $CMSigner = New-Object -TypeName System.Security.Cryptography.Pkcs.CmsSigner -ArgumentList $Certificate -Property @{IncludeOption = [System.Security.Cryptography.X509Certificates.X509IncludeOption]::EndCertOnly} -ErrorAction Stop $null = $CMSigner.SignedAttributes.Add((New-Object -TypeName System.Security.Cryptography.Pkcs.Pkcs9SigningTime)) $SignedCMS.ComputeSignature($CMSigner) $CMSHeader = '{0}{1}{2}' -f 'CMSURL','`1 ',$([System.Convert]::ToBase64String(($SignedCMS.Encode()))) Write-Output -InputObject $CMSHeader

The values you can use for TargetReleaseVersion are listed here: https://learn.microsoft.com/en-us/windows/release-health/supported-versions-windows-client As Thomas mentioned above, make sure to add ProductVersion too unless you want them to move to Windows 11.

Here is an example on how to do this in PowerShell. The example uses the search API to find the device with ID 154335 but is really just to illustrate an API being used. The certificate was exported to the personal cert store and has the subject as shown below, which would need to be updated with the approprate subject of the certificate to use. The API server name and API Tenant code would also need to be specified. Add-Type -AssemblyName System.Security function Get-CMSURLAuthorizationHeader { [CmdletBinding()] [OutputType([string])] Param ( [Parameter(Mandatory=$true, ValueFromPipelineByPropertyName=$true, Position=0)] [uri]$URL, [Parameter(Mandatory=$true, ValueFromPipeline)] [System.Security.Cryptography.X509Certificates.X509Certificate2] $Certificate ) Process { TRY { $bytes = [System.Text.Encoding]::UTF8.GetBytes(($Url.AbsolutePath)) $MemStream = New-Object -TypeName System.Security.Cryptography.Pkcs.ContentInfo -ArgumentList (,$bytes) -ErrorAction Stop $SignedCMS = New-Object -TypeName System.Security.Cryptography.Pkcs.SignedCms -ArgumentList $MemStream,$true -ErrorAction Stop $CMSigner = New-Object -TypeName System.Security.Cryptography.Pkcs.CmsSigner -ArgumentList $Certificate -Property @{IncludeOption = [System.Security.Cryptography.X509Certificates.X509IncludeOption]::EndCertOnly} -ErrorAction Stop $null = $CMSigner.SignedAttributes.Add((New-Object -TypeName System.Security.Cryptography.Pkcs.Pkcs9SigningTime)) $SignedCMS.ComputeSignature($CMSigner) $CMSHeader = '{0}{1}{2}' -f 'CMSURL','`1 ',$([System.Convert]::ToBase64String(($SignedCMS.Encode()))) Write-Output -InputObject $CMSHeader } Catch { Write-Error -Exception $_.exception -ErrorAction stop } } } $Certificate = Get-ChildItem -Path Cert:\CurrentUser\my | Where-Object Subject -eq 'CN=8091:APICBA' $headers = New-Object "System.Collections.Generic.Dictionary[[String],[String]]" $headers.Add("Authorization", "$(Get-CMSURLAuthorizationHeader -URL $Url -Certificate $Certificate)") $headers.Add("aw-tenant-code", "****** REST API TENANT CODE GOES HERE ******") $headers.Add("Content-Type", "application/json") $URI = 'https://{api server}.awmdm.com/api/mdm/devices?searchBy=DeviceId&id=154335' try { $response = Invoke-WebRequest -Method Get -Uri $URI -Headers $Headers -ErrorAction Stop $response.content | ConvertFrom-Json } catch { Write-Output $_.Exception.Message }

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.