Mitel Forums - The Unofficial Source
Mitel Forums => Mitel Software Applications => Topic started by: acejavelin on April 28, 2016, 12:09:11 PM
-
I have a MiCollab 7.0 server I am trying to deploy mobile clients/softphones but really struggling.
I have licences a test user, built the softphone, added it to MBG and enabled it, and sent the deployment email with the activation code. The iPhone client (MiCollab Mobile) asks for the authentication key, then attempts to sync and either comes back with "Cannot reach Configuration server" or "Deployment error: No data found on the Deployment Server, please contact your administrator"
I have never really deployed MiCollab mobile, so I am kind of guessing at some of this stuff.
Can the client be setup manually, I only have 5 users to deploy too with the mobile client? I can't find any menu or anything like that to input IP address, login credentials, etc...
-
So by removing the MiCollab for Mobile client and installing the older MiCollab Client Mobile for iPhone (even though it says it's for 6.0 or older) I was able to get it mostly working. Missed the TCP SIP support option in MBG settings and got the softphone to register after that, could this be why the deployment client didn't work??? Guess I will play with it more on Monday.
I can't call out to anything unless the softphone is in a Multi-device user group, but I can't call it directly when it is in the group...
Baby steps I guess
-
You need to install a web certificate on the MiCollab server for the new Mobile Client app to work
-
You need to install a web certificate on the MiCollab server for the new Mobile Client app to work
Like a real cert from a CA? Meaning MiCollab has to have a real FQDN?
Sorry, never done this before.
-
Yep, cert from a CA and FQDN
-
Yep, cert from a CA and FQDN
Great... Now I (or the PM) has to go back to the customer's IT manager and tell them. Guess having them working by monday is not going to happen, since I am off today taking my son to technical school for sign-up. Oh well.
-
Just another FYI gotcha....the server hostname needs to match the external FQDN, for now. I have a case with Mitel regarding this. We will not use our internal hostname on the internet, we have an internal naming convention so we use alias names outside. When I create users via import, the configuration server address is populated as the FQDN using the internal name and cannot be modified. Anyone else see this or have a workaround?
-
So does anyone have a recommendation for a CA for this?
I know nothing about this aspect of it other than what Google has shown me... As far as reliable CA's go, Network Solutions Xpress Domain Validation package (http://www.networksolutions.com/SSL-certificates/index.jsp) seems the most cost effective for multi-year service. The customer's regular web stuff is hosted in Germany and falls under a different domain.
Anyone have input on this?
-
We've used RapidSSL and been happy. Also GeoTrust.
-
We ended up getting a UC Cert to install on MiCollab, and the 2 MGB's. A UC Cert from Godaddy will cover 5 hostnames. Once we installed that cert on the MGB's everything worked fine. Only thing we changed in our deployment profile is defined a specific MGB for teleworker, as the MGB also acts as the proxy to MiCollab. Once I got all those certs installed, and settings verified it worked great.
One thing to look at is the Diagnostics tab within the client deployment. Run that before deploying a client, once I got this test to pass everything worked great.
-
We had lots of issues with the 7.0 version and deploying the MiCollab client. We spoke with Mitel support and they recommended upgrading to 7.1 as 7.0 is a little buggy for MiCollab client deployment and it has a few other bugs in it.
Better to go to 7.1 as soon as you can to get all the bug fixes too.
-
We had lots of issues with the 7.0 version and deploying the MiCollab client. We spoke with Mitel support and they recommended upgrading to 7.1 as 7.0 is a little buggy for MiCollab client deployment and it has a few other bugs in it.
Better to go to 7.1 as soon as you can to get all the bug fixes too.
I will consider it... it is a MiVoice Business Express installation, so there are some caveats to upgrading individual blades, but we are having real issues with it besides the MiCollab Client deployment.
-
I finally got the SSL certificate installed, the customer had a blanket SSL cert for their domain from DigiCert so they created one using that and I applied the SSL cert and intermediate cert... now when I click on the link in the Email, it seems to go through for a while, then fails with the following error:
Error Code: 33 - Connection to the MiCollab Client Service server denied. Cannot verify the security certificate. Please contact your administrator.
1. The client cannot verify the secure connection to the Redirect Server on the Internet.
2. Check the time and date of the phone (issue may be caused by erroneous detection of certificate expiry)
3. Make sure that there are no transparent SSL proxies (e.g. Wi-Fi login page) on the local network.
4. Try to deploy the client via the mobile data network
5. The certificate can be checked by using the command: openssl s_client -CAfile /etc/pki/tls/certs/ca-bundle.crt -connect mas.yourmashostname:36008 < /dev/null #(place the correct hostname)
6. Check that you are not running an outdated MBG version. Some phones (Android) do not longer support the RC4 cipher anymore (use the command above and look for Cipher : RC4-SHA)
Consult the document "TLS_w_MiCollab_Client_Deployment.pdf" for further troubleshooting of certificates
Several people have said to go to MiCollab Client Deployment -> Diagnostics to troubleshoot this, but I don't have that option when I go to MiCollab Client Deployment, just Users, Deployment Profiles, and Configuration, and there is no Diagnostics option under any of them.
I tried doing item #5 from above, but it ends with "Verify return code: 18 (self signed certificate)" which doesn't seem right after loading the DigiCert SSL certificate.
-
Are you still on version 7.0?
-
Are you still on version 7.0?
Yes, it is part of the MiVoice Business Express
-
I would test via a SSL testing site. You need the keyfile for this cert and it needs to be in RSA format
-
Are you still on version 7.0?
Yes, it is part of the MiVoice Business Express
Most of our customers are on MiVB Express too. Its quite easy to backup the entire config, deploy a new instance on 7.1 and restore the config. 7.1 is a lot more stable with less bugs.
-
Are you still on version 7.0?
Yes, it is part of the MiVoice Business Express
Most of our customers are on MiVB Express too. Its quite easy to backup the entire config, deploy a new instance on 7.1 and restore the config. 7.1 is a lot more stable with less bugs.
This is my first and only MiVB Express, never upgraded one before. I'll look into it this week.
Sent from my MotoG3 using Tapatalk
-
I would test via a SSL testing site. You need the keyfile for this cert and it needs to be in RSA format
I ran an SSL Server test from Qualys SSL Labs (https://dev.ssllabs.com/index.html (https://dev.ssllabs.com/index.html)) and DigiCert's SSL Certificate Checker (https://www.digicert.com/help/ (https://www.digicert.com/help/)) and although it got an F rating for a vulnerability (OpenSSL Padding Oracle vulnerability (CVE-2016-2107) , the certificate portion passed with no issues from both sites.
Is that what you mean?
-
Yes, never had and F mostly B. I am trying to remember what the fix was for a customer who had the same message.
-
Did you end up figuring this one out? Experiencing the same issue with the cert having been loaded, but still being returned an error of Error: DEPTH_ZERO_SELF_SIGNED_CERT when running the diagnostics.
-
Did you end up figuring this one out? Experiencing the same issue with the cert having been loaded, but still being returned an error of Error: DEPTH_ZERO_SELF_SIGNED_CERT when running the diagnostics.
No... we were dealing with other issues and they are scheduled for an upgrade to the new MiVBX release towards the end of the month, we tabled it until the upgrade was complete.
-
I figured my issue out as being that the intermediate cert did not also contain the root, which is why the deployment service was then failing. Through a bit of trial and error I figured this out, and then once I had combined the two and uploaded it as the intermediate along with the signed then everything kicked in to life.