Product Documentation

User Communities

Feb 21, 2018

Every organization consists of diverse user 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 section provides 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, see Deploy resources in 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 Services
    • 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 Services

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

Secure Notes

ShareFile

Receiver

SalesForce1

RSA SecurID

EpicCare Haiku

Epic Hyperspace

Clinical-Nurses

X

X

X

X

Clinical-Physicians

Clinical-Specialists

Clinical-Outside Physicians

X

X

X

Clinical-Home Health Services

X

X

X

Clinical-Research Specialist

X

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

X

Non-Clinical-Philanthropic Programs

X

X

X

X

X

Contractors

X

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 the Enrollment Required option to True in Server Properties in the XenMobile console. For details, see Server 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 the Settings page. For details about deployment rules, see Deploy resources in the XenMobile documentation. For details about server properties, see Server Properties in 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 property wsapi.mdm.required.flag to true, XenMobile manages all BYOD devices, and any user who declines enrollment is denied access to apps. Consider setting wsapi.mdm.required.flag to true in environments in which enterprise IT teams need high security plus a positive user experience during enrolling.

If you leave wsapi.mdm.required.flag as false, which is the default setting, users can decline enrollment. However, they can access apps on their devices through the XenMobile Store. Consider setting wsapi.mdm.required.flag to false in 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.