XenMobile

User Communities

每个组织由不同用户communities that operate in different functional roles. These user communities perform different tasks and office functions using various resources that you provide through user mobile devices. Users might work from home or in remote offices using mobile devices that you provide. Or, users might use personal mobile devices, which allows them to access tools that are subject to certain security compliance rules.

With more user communities using mobile devices, Enterprise Mobility Management (EMM) becomes critical to prevent data leak and to enforce organizational security restrictions. In order for efficient and more sophisticated mobile device management, you can categorize your user communities. Doing so simplifies the mapping of users to resources and ensures that the right security policies apply to the right users.

Categorizing user communities can include use of the following components:

  • Active Directory Organizational Units (OUs) and Groups

    Users added to specific Active Directory security groups can receive policies and resources such as apps. Removing users from the Active Directory security groups removes access to previously allowed XenMobile resources.

  • XenMobile local users and groups

    For users who don’t have an account in Active Directory, you can create the users as local XenMobile users. You can add local users to delivery groups and provision resources to them in the same manner as Active Directory users.

  • XenMobile delivery groups

    If multiple groups of users with different level of permissions are to consume a single app, you might need to create separate delivery groups. With separate delivery groups, you can deploy two separate versions of the same app.

  • Delivery group and user group mapping

    Delivery group to Active Directory group mappings can be either one-to-one, or one-to-many. Assign base policies and apps to a one-to-many delivery group mapping. Assign function-specific policies and apps to one-to-one delivery group mappings.

  • Delivery Group and Resource Mapping of Apps

    Assign specific apps to each delivery group.

  • Delivery Group and Resource Mapping of MDM Resources

    Assign apps and specific device management resources to each delivery group. For example, configure a delivery group with any mix of the following: Types of apps (public, HDX, and so on), specific apps per app type, and resources such as device policies and automated actions.

The following example illustrates how the user communities of a healthcare organization are classified for EMM.

Use Case

This example healthcare organization provides technology resources and access to multiple users, including network and affiliate employees and volunteers. The organization has chosen to roll out the EMM solution to non-executive users only.

You can divide user roles and functions for this organization into subgroups including: clinical, non-clinical, and contractors. A selected set of users receive corporate mobile devices, while others can access limited company resources from their personal devices (BYOD). To enforce the appropriate level of security restrictions and prevent data leak, the organization decided that corporate IT manages each enrolled device. Also, users can only enroll a single device.

The following sections provide an overview of the roles and functions of each subgroup.

Clinical

  • Nurses
  • Physicians (Doctors, Surgeons, and so on)
  • Specialists (Dieticians, phlebotomists, anesthesiologists, radiologists, cardiologists, oncologists, and so on)
  • Outside physicians (Non-employee physicians and office workers that work from remote offices)
  • Home Health Services (Office and mobile workers performing physician services for patient home visits)
  • Research Specialist (Knowledge Workers and Power Users at six Research Institutes performing clinical research to find answers to issues in medicine)
  • Education and Training (Nurses, physicians, and specialists in education and training)

Non-Clinical

  • Shared Services (Office workers performing various back-office functions including: HR, Payroll, Accounts Payable, Supply Chain Service, and so on)
  • Physician Services (Office workers performing various health care management, administrative services, and business process solutions to providers, including: Administrative Services, Analytics and Business Intelligence, Business Systems, Client Services, Finance, Managed Care Administration, Patient Access Solutions, Revenue Cycle Solutions, and so on)
  • Support Services (Office workers performing various non-clinical functions including: Benefits Administration, Clinical Integration, Communications, Compensation & Performance Management, Facility & Property Services, HR Technology Systems, Information Services, Internal Audit & Process Improvement, and so on.)
  • Philanthropic Programs (Office and mobile workers that perform various functions in support of philanthropic programs)

Contractors

  • Manufacturer and vendor partners (Onsite and remotely connected via site-to-site VPN providing various non-clinical support functions)

Based on the preceding information, the organization created the following entities. For more information about delivery groups in XenMobile, seeDeploy resourcesin the XenMobile product documentation.

Active Directory Organizational Units (OUs) and Groups

For OU =XenMobile Resources

  • OU = Clinical; Groups =
    • XM-Nurses
    • XM-Physicians
    • XM-Specialists
    • XM-Outside Physicians
    • XM-Home Health Services
    • XM-Research Specialist
    • XM-Education and Training
  • OU = Non-Clinical; Groups =
    • XM-Shared Services
    • XM-Physician服务公司ices
    • XM-Support Services
    • XM-Philanthropic Programs

XenMobile Local Users and Groups

For Group= Contractors, Users =

  • Vendor1
  • Vendor2
  • Vendor 3
  • … Vendor 10

XenMobile Delivery Groups

  • Clinical-Nurses
  • Clinical-Physicians
  • Clinical-Specialists
  • Clinical-Outside Physicians
  • Clinical-Home Health Services
  • Clinical-Research Specialist
  • Clinical-Education and Training
  • Non-Clinical-Shared Services
  • Non-Clinical-Physician Services
  • Non-Clinical-Support Services
  • Non-Clinical-Philanthropic Programs

Delivery Group and User Group mapping

Active Directory Groups XenMobile Delivery Groups
XM-Nurses Clinical-Nurses
XM-Physicians Clinical-Physicians
XM-Specialists Clinical-Specialists
XM-Outside Physicians Clinical-Outside Physicians
XM-Home Health Services Clinical-Home Health Services
XM-Research Specialist Clinical-Research Specialist
XM-Education and Training Clinical-Education and Training
XM-Shared Services Non-Clinical-Shared Services
XM-Physician服务公司ices Non-Clinical-Physician Services
XM-Support Services Non-Clinical-Support Services
XM-Philanthropic Programs Non-Clinical-Philanthropic Programs

Delivery Group and Resource Mapping of Apps

Secure Mail Secure Web ShareFile Receiver SalesForce1 RSA SecurID EpicCare Haiku Epic Hyperspace
Clinical-Nurses X X X
Clinical-Physicians
Clinical-Specialists
Clinical-Outside Physicians X X
Clinical-Home Health Services X X
Clinical-Research Specialist X X
Clinical-Education and Training X X
Non-Clinical-Shared Services X X
Non-Clinical-Physician Services X X
Non-Clinical-Support Services X X X X
Non-Clinical-Philanthropic Programs X X X X
Contractors X X X X X X

Delivery Group and Resource Mapping of MDM Resources

MDM: Passcode policy MDM: Device Restrictions MDM: Automated Actions MDM: WiFi policy
Clinical-Nurses X
Clinical-Physicians X
Clinical-Specialists
Clinical-Outside Physicians
Clinical-Home Health Services
Clinical-Research Specialist
Clinical-Education and Training
Non-Clinical-Shared Services
Non-Clinical-Physician Services
Non-Clinical-Support Services
Non-Clinical-Philanthropic Programs
Contractors X

Notes and considerations

  • XenMobile creates a default delivery group named All Users during the initial configuration. If you do not disable this Delivery Group, all Active Directory users have rights to enroll into XenMobile.
  • XenMobile synchronizes Active Directory users and groups on demand using a dynamic connection to the LDAP server.
  • If a user is part of a group that is not mapped in XenMobile, that user cannot enroll. Likewise, if a user is a member of multiple groups, XenMobile only categorizes the user as being in the groups mapped to XenMobile.
  • To make MDM enrollment mandatory, set theEnrollment Requiredoption toTrueinServer Propertiesin the XenMobile console. For details, seeServer Properties.
  • To delete a user group from a XenMobile delivery group, delete the entry in the SQL Server database, under dbo.userlistgrps.

    Caution:

    Before you perform this action, create a backup of XenMobile and the database.

About Device Ownership in XenMobile

You can group users according to the owner of a user device. Device ownership includes corporate-owned devices and user-owned devices, also known as bring your own device (BYOD). You can control how BYOD devices connect to your network in two places in the XenMobile console: in Deployment Rules and through XenMobile server properties on theSettingspage. For details about deployment rules, seeDeploy resourcesin the XenMobile documentation. For details about server properties, seeServer Propertiesin this handbook.

By setting server properties, you can require all BYOD users to accept corporate management of their devices before they can access apps. Or, you can give users access to corporate apps without also managing their devices.

When you set the server propertywsapi.mdm.required.flagtotrue, XenMobile manages all BYOD devices, and any user who declines enrollment is denied access to apps. Consider settingwsapi.mdm.required.flagtotruein environments in which enterprise IT teams need high security plus a positive user experience during enrolling.

If you leavewsapi.mdm.required.flagasfalse, which is the default setting, users can decline enrollment. However, they can access apps on their devices through the XenMobile Store. Consider settingwsapi.mdm.required.flagtofalsein environments in which privacy, legal, or regulatory constraints require no device management, only enterprise app management.

Users with devices that XenMobile doesn’t manage can install apps through the XenMobile Store. Instead of device-level controls, such as selective or full wipe, you control access to the apps through app policies. Some policy settings require the device to check the XenMobile server routinely to confirm that the apps are still allowed to run.

User Communities