→ Basic Access
→ Custom (you can create a access catalog with selective capabilities that you want your users and/or admins to have, the URL usually will be https://<publicmdmserverFQDNorIPaddress>/mydevice e.g. https://mdm.domain.com/mydevice) Following can be a high-level implementation and administration tasks involved in a MDM deployment: Please note there can be additional tasks based on the specifics of your project such as Intranet Apps, Corporate Data Access/Share etc. Note: The terms and steps may vary depending on the MDM vendor. Before I start to pen down my thoughts, experiences, would like to share a very basic and high-level overview of the User to Device to App Relationship or Management. It may be vary depending on your organisational structure, architecture, design style. In an attempt to represent this with clarity, sharing you this diagram. Hope it helps you in understanding and deployment. Also, note that I may modify this if I think something is missing or needs correction. User Management º Create Organisation Group (Custom and/or Directory) º Add/Register Users, Device(s) in MDM Console in bulk or one at a time depending on the user-base and demand in your organisation º Create User Group (Custom and/or Directory) Smart Group is mainly used on the application side. It is used when a specific App is pushed via App Catalog to specific user groups. User Group is primarily used on the user level. Specific users are added to user group based on the profile, level of access, security and/or restrictions. And also used in line with the smart group. Users Group is added to specific Smart Group for grant access to specific apps. Device Management using MDM Profiles and Compliance Rules Create following Profiles based on the level of security to be applied on user or user group-level (For example: HIGH/MED/LOW). For Passcode and EAS, recommended is to have a single profile across of users/groups. º Passcode
º Exchange Active Sync
º Restrictions (mostly device related and telecom/data)
º Compliance Policies (Whitelist/Blacklist) Email Management º Enable Exchange Active Sync (EAS) in your environment (Enable EAS policy/service in Active Directory domain) for your users. º Restrict/Limit users to specific device(s) (MAC/IMEI/deviceID) and/or specific number of devices (1,2,…n) (This may be optional and is required when your EAS traffic routes from an already existing spam filter engine (e.g. barracuda) and you may want to restrict the new EAS traffic from MDM deployment route through SEG or SMG thus allowing users to enroll to only 1 or 2 devices. This may be experimental as I had some issues during my testing. So please test and ensure it works. Please refer Enable a Device for Exchange ActiveSync for more info on how to) º Email Domain Registration (similar to user addition or device registration in Airwatch portal/environment) º Integrate your email management with vendor provided applications such as the following: → Email Client – Configuring and accessing corporate emails using vendor email client. (By default, native device email client is used) → Browser – Opening links in vendor browser. (By default, native device web browser is used) → Secure Content Locker (SCL) – for opening attachments in encrypted mode within a container. (You may configure unencrypted and opening attachment directly without SCL) Application Management ° Add Internal, Public Applications in the MDM Console manager. Most of the applications are either available from App Store or Google Play or Windows Store. Additional specific apps can be imported as SDKs or App profiles. ° Either let users control Public Apps using Google Play, or restrict using App Catalog with whitelist/blacklist Apps list/compliance rules. Note/Checklist when Managing Android Devices NOTE 1 iOS Devices are easy to configure and manage compared to Android Devices. Having said that with the introduction of Samsung SAFE and KNOX, android devices are marching towards a sofiscated and secured device in the next months/years to come.Therefore, you may find several restrictions and configuration settings which either does not work or need to configure it with certain services turned on such as background data service, non-market app install allowed, several system services turned on. Google Play needs to be enabled to install public apps managed via MAM solution. Quick checklist you may want to consider while managing android devices: → Settings > Security > Unknown sources > Allow installation of apps from sources other than the Play Store is checked. (Else third party or non-market app install is blocked) → Settings > Security > Verify apps is unchecked NOTE 2 Public Apps when pushed via App Catalog fails to install if Google Play is disabled using policy. Currently, this does not work, therefore you must enable Google Play to install the public apps. In a real-time scenario, you may follow it using one of the following ways: º Enable Google Play in the ‘Restriction’ profile for all users/device platforms.
º Enable Google Play → Install the required Public Apps → Test → Disable Google Play by modifying the ‘Restriction’ profile. (This will be tedious if you need to do it every time an user requests for ‘n’ number of devices).
º Enable Google Play in ‘Restriction’ profile and then configure Whitelist/Blacklist Apps list/compliance policy.
º Create separate ‘Restriction’ profile for specific usergroups who require Google Play and require public apps. In my next part of the MDM series, will share a little more on the services that enables the MDM environment. And also FAQs and Issues/workarounds based on real-time scenarios. Apart from this, also would create a separate blog on AirWatch and XenMobile side-by-side on Architecture, Components, Editions, High-level comparison. Hope I keep the promise 🙂 Till then…have fun n spread peace n happiness…