SOTI Pulse Logo

Documentation?

S
Scott
Union Pacific Railroad

The support page mentions the availability of "Knowledge Base Articles Access" with a description of "SOTI knowledge base articles to find answers to your SOTI MobiControl implementation. Get helpful advice in an easy to understand format written by our support engineers."
Great! Where do I find it??

I'm looking for information on disaster recovery configurations.  The deployment server config contains things like: "Secondary Agent Address and Port".  Seems like a recovery/failover mechanism of some kind.  Finding any detailed information about it though seems to be impossible.  The online (un)help contains the useful: "Displays the secondary address for device connectivity in IP or FQDN format as well as its associated port."
How about a description of WHEN or HOW it would/should be used!

Are there any "best practices" documents that explain how to prevent devices from becoming orphans if our data center blows up and we need to bring up the infrastructure in a different location?

deployment
7 years ago
SOTI MobiControl
ANSWERS
RC
Raymond Chan Diamond Contributor
7 years ago (edited 7 years ago)

It is not uncommon to misinterpret or overlook blind-spots/assumptions when looking into documentations on complex problem such as DR implementation.  Basically, no two DR/HA solutions are exactly the same. There are just too many dimensions to consider, including but not limited to

- General DR requirements/ customer expectations  -e.g.  max recovery time, reliability, ease of operation, costs, etc.

- Existing network infrastructure, server locations, and new hardware availability;

- Number of device models/firmwares and platforms deployed, and EMM features/policies deployed;

- Current use cases of domain(s), certificates, LDAP/IdP, etc;

- DS/MS/SQL Server versions and configurations, backup software or mechanisms;

- Ever-changing EMM related behaviors/limitations defined by platform vendors such as Google/Apple/Microsoft

etc.

That is probably why customers often need professional services offered by specialists.

It is often not possible to reveal above-mentioned details of a company's implementation deep enough for discussion in an OPEN forum.  However, if you are worried about devices being left orphaned in case your data-centre gets blown up, the simplest and cheapest you need to do in the general case will be:

1. Make regular backup of the MS-SQL databases used by MobiControl.

2. Make sure your MobiControl server use a FQDN your company owns, and trusted CA certificate(s) bind to such domain as bases to set up all other server settings, services (from Google/Apple/Microsoft/Soti, etc)  and MDM policies.

Then, in principle, your deployed devices will remain in full control as before once the redundant/new hardware+software get up running using the latest SQL databases restored.  Overlooking some implementation detail(s) may render some functionalities failing, or even some/all devices requiring recall and/or re-enrollment in the worst case.

S
Scott
7 years ago

Appreciate your answer and the time it took to create.  I understand there won't be a "this is how you do it" document that covers every possible scenario.  However, providing adequate documentation on the actual data fields of the product seems to me something that should come "out of the box".  Ex. the help description for the secondary agent address and port is: "Displays the secondary address for device connectivity in IP or FQDN format as well as its associated port".  How does that help?  I had to call in a support case to Soti to get the explanation that it is not related to failover or a secondary server but instead just a way to provide a secondary path to the same primary MC infrastructure.  Why could that not be included in the documentation??

Example 2:

You mention "and trusted CA certificate(s) bind to such domain as bases to set up all other server settings".  I agree, however, Soti documentation on that subject is also sorely lacking.  It appears that you can put a signed CA on the physical device and let the server create device certs from that or also have it send requests to an external CA to enroll devices.  The documentation around it though leaves out details.  I found a reference to "after you have installed web enrollment services", but no where that actually explains that web enrollment services are a requirement in order to accomplish proxying device cert requests.  It's just frustrating that things that seem to me to be basic product documentation are left out and require a support case to get a basic question answered or worse, a response that this is a "professional services" level request.  For a product that is two to three times the cost of its competition, I expect more, and the product documentation is part of it.

(rant off)

Scott

RC
Raymond Chan Diamond Contributor
7 years ago

Hi Scott,

I agreed with you that the documentation should be improved.  Actually, the v14.x documentation is already much more informative compared to v9/10, the versions I first used Mobicontrol some years ago.  Back then, I was probably more frustrated than you are now.  

I am not from Soti, and what I post in this forum is UNOFFICIAL information I wouldn't mind to share.  I've tried my best to give information as accurate as I know, though experts from Soti might not agree to what I said here.  Your comments for your example 2 indicated some misunderstandings you had with respect to what I said in my point 2. Here are some clarifications:

a) Step 2 refers to the GENERAL case of a MobiControl server supporting ALL MAJOR device platforms on an open network.   If a server and devices remains in a closed system, or do not need some of the services provided by  Google/Apple/Microsoft/Soti, servers, then some requirements mentioned in step 2 might be relaxed.

b) The trusted CA certificate mentioned mainly refers to the Deployment Server, DS Extension and SSL certs for the company owned FQDN used in the Device Management Address set with MCadmin.exe, and not to any device certificates that you mentioned. 

c)  What I suggest is, in my personal view, the ideal scenario in which a MobiControl expert can get a totally brand-new hardware server located at a new IP address to regain full control of all deployed devices using the latest MobiControl databases restored.   In reality,  many of my customers did not follow it due to different technical or non-technical reasons.  Also, such recovery is possible only if the hardware/software were originally properly configured and EACH recovery step is done properly in the right sequence.

If you have a really big and mission-critical deployment,  please contact Soti support/professional service team for official answers related to your scenario and specific requirements.  As far as I know, you need to do the same for other vendors like Airwatch,  MobileIron, etc. because of the complexity of the problem. 

S
Scott
7 years ago

Thanks again for your reply.  I'm sorry if it appeared my response regarding incomplete doc was directed at you.  It was more at Soti, I just happened to be replying to your post.

SS
Support Staff Account
7 years ago

Hi Scott, 

Thank you for your inquiry in the Soti Central Forum discussion.  I like your idea of best practices documentation for MobiControl.   

The introduction to "Soti Knowledge base Articles" has been added now with the release of Soti Central 2.0 and we expect this to continue to grow as we receive more content. 

Navigate to the Soti Central Forum->Select the Articles Tab->Scroll though the Articles we have uploaded to the site and select the articles that appeal to you.

Unfortunately, I do not believe we have a topic on recovery/fail-over configurations, at the moment, in the articles section.  Nonetheless, the Secondary Agent Address and port is intended to be a used as a fail-over in case the agent cannot connect trough the primary address and port.  

I can inquire with regards to best practices documention for things like disaster recovery.  Usually a Technician can provide you with this information based on your environment or VIA a generic response without taking your installation details into consideration, if you prefer. 

Hopefully you find the other articles helpful.

Regards,

S
Scott
7 years ago

I appreciate the effort.  Unfortunately you posted this the same day that I received a response on another issue I had open with a Soti Support Case that essentially said, "After wasting two weeks of your time we now think you need to engage Professional Services, but hey, at least the quote is free".

This issue was about how the MCA utility manages certificates.  It allows you to import your own root certificate and some, but not all, of the certificates used for different services.  The documentation on the Soti site is worthless or nonexistent.  I spent a couple of days trying different things but eventually gave up and opened a case with Soti support.  Over the next two weeks I went back and forth with the support "specialist" and it became clear to me that they had no idea how their own product worked.  I ended up sending them a certificate I generated for them to test.  The response was, "You're right, it's not working.  We'll get back with you."  After a couple more days I received the response: "I had a meeting with my team and was told since currently you are in a running state and you would like to implement a self signed cert for all the bindings in MobiControl for your interest this will need to be handled our Professional Service team.  Please note this is a billable service however there is a free quote this job."

If anyone is interested in the entire contents of the case, I can provided it.  It is just another example of Soti pushing you to "Professional Services" rather than just DOCUMENTING THE PRODUCT.  Don't provide a button to perform a function if you can't use it without engaging Professional Services.  Or at least include a warning like "Danger! Clicking this button requires a credit card"

Similar Discussions