Daniel Langley

One of the conveniences of the WS1 architecture is that the consoles are 'dummy' servers that require a DB. You can deploy a new VM with appropriate OS and simply install the WS1 UEM bits on it and connect into the existing DB and you're good to go.

Awesome find Troy. Thanks for sharing the changes you made that resolved the trouble.

Correct, it's an OG level setting, you can inherit or override it at lower OG's if you wanted to alter behavior accordingly.

Hi Troy, Have you considered using the SaaS ENSv2? What is the Email end point? Is it on-prem Exchange? Are you using SEG? Overall this might pretty difficult to resolve on a forum. Typically I'd want to review Boxer logs, ENS logs and Exchange logs to correlate the 401 Unauthorized errors. I do resonate with your confusion on why Inbox sync works, but not subscribing to the same end point using the same credentials, that's why I think you'll need log analysis to get a bit of traction here. If everything on the new ENSv2 is the same as the one that works (same subnet, same networking rules), then I can definitely resonate with your frustration. If there's any more info you can share, we can see if we can dig a little deeper.

Hi Ivan, I know I'm a little late to this thread, but in my experience, when I can't start Connector services, it's usually because the Connector can't reach outbound to the tenant to get the SSL cert from Access. Does your Connector have outbound connectivity on 443? Is there a proxy in between internal network and internet? Since there hasn't been much activity on this thread, I'm assuming you got this sorted out, if not, let us know, we can try and help further.

Hi Mike, I'm not particularly familiar with your current issue, not something I've seen before. However, this KB has info for reaching support via phone or online -> https://kb.omnissa.com/s/article/6000004

I can't remember if sent-mail is blocked when SEG is managing a non-compliant device (I think it does), so as long as the device isn't showing as non-compliant, then it's pretty safe to say the sent-mail issue isn't related to SEG most likely. Where SEG is pointed determines what should be throttled based on device compliance and enrollment (depending on the MEM controls you have enabled). I don't think directing SEG to the new Exchange will solve any Sent-Mail issues, it will just change governance from the old server to the new one in terms of syncing/connecting from a compliant device. Let us know if any new info, we'll see if we can help further, but I'd guess any sent mail issues are most likely tied to the Exchange server or account. Have you tried turning off the SEG service and testing just to remove SEG from the equation? Maybe try that and do a quick test to see if the issue subsides or continues, that should help remove SEG as point of contention if no change in behavior after disabling SEG service for testing.

Yeah so you have to 'X' out the AWCM service (this feature will not be available | which uninstalls it as you've seen), then run the installer again and reinstall AWCM back, and upload the cert during the install wizard. You should ONLY be uninstalling/reinstalling the AWCM component, not anything else (not the Device Services Not Device management, etc). It looks like possibly you're reinstalling the Console Node in the screen shot saying it can't connect to the signing service? Looks like the AWCM can't reach the SQL server or the SQL server URL is wrong that you were using in the first error.

OK got it, I thought we were troubleshooting ACC. Take a look at this -> https://docs.omnissa.com/bundle/AirWatchCloudMessaging/page/RenewSSLCertificateforAWCM.html

OK, Let's take a step back, are you trying to update the self-signed 443 server certificate on ACC (AirWatch Cloud Connector), or the AWCM (AirWatch Cloud Manager) certificate?

I don't think you need the Secure Channel Cert for the ACC, it's for servers that host the AWCM service. If the 443 cert expired on the ACC, I think you just need to update it in IIS for port 443. Which cert are you trying to update?

Hi Jking316, Are there any certs (443) possibly that have expired (on that ACC or any in UEM)? Sometimes when the ACC won't start, it's due to a certificate issue of some sort. Take a look at the ACC logs, like Akito recommended, should have some good info in there. Let us know how it goes.