Hey Chan!

Many many thanks for your help troubleshooting my issue.

At the end I did an RDP with SOTi and after many tests and checks, they created a SHA1 cert and it worked!

I don't really understand why on Win7 and Win10 SHA256 would work and not on the server, but hey... I got the devices enrolled on the server and that's all matters for now

Again, thanks a lot for your help

Please provide more details:

- What is the version & build number of your MobiControl server?

- Are your device and server accessible on a public network or on a closed network?  

- Is there any FQDN associated with the address of Windows machine hosting your Mobicontrol server?  If so, what is it?

- What is the device agent URL address you used in your test?

- Have you tried successfully deploying any MDM profile/rules  to your test devices enrolled to your MobiControl on Win10 ? 

-  Have you tried enrolling any Android/Android+ device and deploying any Android profile/rule successfully?  If not, please try to do so because Android/Android+ platform is often the simplest and easiest to set up and is usually the first platform I use to debug server problem in a multi-platform implementation.  If done, please give the test results.

Is the system date on the device correct?

I've had some issues where devices would reset the system date/time after a cold boot and therefore the device certificate issued by the Deployment Server was not valid and the device wouldn't connect to the server.

Hey, 

Thanks for replying. Thse are my answers

- What is the version & build number of your MobiControl server? I have used the same installer on both OS (MobiControl1410Setup_1152_release), is there a newer one?

- Are your device and server accessible on a public network or on a closed network?  Both devices are on a closed network (office network), however the server has access to the internet via a proxy server, so we can register the licenses and SOTI can autogenerate the certificates

- Is there any FQDN associated with the address of Windows machine hosting your Mobicontrol server?  If so, what is it? Yes, both MobiControl servers use their FQDN name (same as DNS name) to connect to them. ServerSOTI01.Domain.com

I have also configured the IP address on all fields of the Soti management console just in case this was a DNS problem and no luck

- What is the device agent URL address you used in your test? https://ServerSOTI01.Domain.com/MC/files/Agents/9 

- Have you tried successfully deploying any MDM profile/rules  to your test devices enrolled to your MobiControl on Win10 ? Yes, as soon as I download and install the SOTI client on the device, the rules and packages start applying within seconds. Both servers Win10 and Win2012 are configured exactly the same (same rules, packages etc). 

-  Have you tried enrolling any Android/Android+ device and deploying any Android profile/rule successfully?  If not, please try to do so because Android/Android+ platform is often the simplest and easiest to set up and is usually the first platform I use to debug server problem in a multi-platform implementation.  If done, please give the test results.

No, we don't have any Android devices at the office, sorry :S

Hey Michael,

Yes! I double checked just in case, but all devices /servers have the same regional settings and time and date.

Thanks for the idea :)

I have installed many tens of implementations on Windows 2012 server and SSL has basically never  a problem.  Firewall or other settings configured with MCadmin are more likely the issues.   However, if you have checked them and the problem really stems from SSL,  you might check to confirm the default enabled TLS1.1/1.2 on your Windows Server 2012 has not been disabled in any way.

I haven't tested Windows 6.5 with  MobiControl v14.x on a "closed" network in the past.  Please check with Soti support if you can use an internal (i.e. non-public name only associated with internal IP address, and can only use self-signed SSL certificate)  domain name for this platform with v14.x.

Thanks for your answer :)

Apart from TLS1.1/1.2, do I need to enable FIPS local policy? As soon as I enabled it, my SOTI certificates went crazy and made everything to stopped working. I couldn't even start the SOTI console or login... and the certificates disappeared and had no valid dates...

As said in earlier post, TLS1.1/1.2 should be enabled by default in Windows 2012.  If your 2012 instance does not have it enabled, please do so, and you have to check what is the default settings for FIPS local policy and try to leave it as default. I never have to make any changes on the above for previous installation on  2012 Server.

If you really have to make some changes as described in the previous paragraph, I believe you might need to re-install your Soti Mobicontrol (or at least regenerate the DSE [for SSL] and some other required certificates in MCadmin.exe), especially if you find lots of warning/errors on your existing implementation.   For some of the certificate changed,  you have to recall and re-enroll all your devices.  Also, re-installation means you have to re-activate the license reg-code.  You have to contact Soti support team to cancel your previous activation, so that you can use the same reg-code again for the new installation.

Hi all,

I think the problem might be that my RF device (Honeywell Dolphin 70E) doesn't support SHA256.

However, not sure why this got to work on my Win10 laptop...

But I have checked all the certificates installed by default on the Windows 6.5 device and they are all SHA1.

Does anybody know if the enrolment website can be force on SHA2?

I have verified TLS1.1 and 1.2 on the server and they are both enabled

The MobiControl version you installed use SHA2 root certificate by default.  I am not sure if you manually chose to use SHA1 root certificate during the installation when you installed it on Windows 10.   If your device can successfully get re-enrolled to Win 10 server, and the MobiControl root certificate used is SHA2, then your device can support SHA2 and the cause of problem is something else.

For now, let's  just assume that your device only supports SHA1 certificates.    TLS1.2 support for some Win 10 build numbers has been reported to be problematic.   What build number of Windows 10 are you using?     If you still have that Mobicontrol server up and running, can you check whether the Mobicontrol root certificate is SHA1 or SHA2?  You can export the root certificate  from MCadmin.exe or from web console (Global-Settings -> "Servers" tab -> "Cloud Liink Agents" on the top left corner -> "Download MobiControl Root Certificate" from the pop up menu)

If the MobiControl root certificate on your Windows 10 server is SHA1 (with key length 1024), that is probably why your device supporting only SHA1 can get enrolled.  To use your current Mobicontrol server version on Server 2012, you might need to go to MCadmin.exe and manually change the root certificate to use SHA1.  After that, you also have to re-generate all the other certificate entries in the certificate tab.  Please note that ALL devices previously enrolled to this server will need to be re-enrolled.  This is of course OK if your problematic device is the first device you try on this server.

Hey Chan,

Firstly many thanks for your support with this :) You are giving me some good ideas to check. 

Well I have now installed SOTI (with the default options, same as the other Win10 and Win2012R2) on a Win7 and it works perfectly well, same as the Win10.

I have checked all certificates, Win10, Win7 and Win2012 and they are all the same, SHA256. So it's defo something on the Win2012 that is blocking the SSL certificate. I haven't enabled SHA1 on any of the MobiControl

I have verified that the 443 is listening on the server:

  TCP    [::]:443               [::]:0                 LISTENING

I have been searching more on Google (as well as I logged a case with SOTI) and there are some articles about binding certificates on 2012 and having to install Centralized SSL Certificate Support (https://docs.microsoft.com/en-us/iis/get-started/whats-new-in-iis-8/iis-80-centralized-ssl-certificate-support-ssl-scalability-and-manageability#TOC301258515). However that's for IIS not for Apache/TomCat as SOTI runs, but maybe it's something related to that?

Did you have to install the Centralized SSL Certificate Support on your Win2012? Or it could be that the Win2012 doesn't allow anonymous connections? but it would be silly, right? The devices I'm enrolling are not on the domain.

The error message I get is "Cannot find 'https://xxxx.com/MC/files/Agents/1'. Make sure the path or Internet address is correct"

It's not the standard message saying it cannot connect, but it cannot find that path (due to the certificate window not popping up).So the connection to the server happens (same as via ping), but it cannot load the certificate for some reason.

Many thanks again

As far as I know, there is no need to explicitly do anything to install Centralized SSL Certificate support on Server 2012 for  all the platforms I had handled in the past.  However,  I haven't tried Windows CE/Mobile using Mobicontrol  v14.x on a closed network.

However, I strongly believe this is not the cause of your problem.  As I mentioned in previous post, enrolling an Android device is the simplest test to check basic server/network configurations because Android is the least demanding (or most tolerant) platform.  I reckon your problem is related to your MCadmin settings and SSL certifciate used on your closed network.

What are your current primary/secondary agent address, management console connection address and device management address settings?   Is your SSL certificate self-signed?  And bind to common name "xxx.com"?