In April of this year, Nine41 Consulting is launching as an Ivanti Expert Solution Provider, specializing in Apple device management for UEM. As part of that effort, Nine41 Consulting will be hosting a 4-day training course, May 5th – May 8th, just prior to Ivanti Interchange 17. If you’re interested, register at http://www.nine41consulting.com/training-calendar/
Zero-touch configuration for IT, the holy grail of device management! This is the promise of a DEP enabled device. Just buy it and turn it on, it’ll pull down your designated management profile once the device has an established Internet connection and all of the associated settings and applications assigned will be deployed to the device.
Easy, right? For the most part, yes it is. All you need to do is make sure your DEP enabled devices, purchased from Apple or from an authorized DEP reseller, are associated with an Apple MDM server. In turn, that Apple MDM server needs to be configured with your MDM management service. To configure LANDESK as your preferred MDM server, see my previous blog post.
Today’s discussion will simply focus on getting those Apple devices enrolled with Apple’s MDM server. While the process only takes a few minutes, it is a required step for that zero-touch configuration; so don’t skip it.
And that’s it. Now when you unbox your shiny new Apple device, whether it be an iOS or macOS device, once it has an Internet connection (the touch part in the zero-touch process 🙂 ), it’ll pull down the assigned profile from your MDM server. Then, anytime the device is reset, the process will re-enage, ensuring that device always has your MDM profile assigned.
Here are the slides used in today’s webinar; including the embedded videos.
whats-new-for-apple-in-ldms-2016-3
LANDESK Management and Security Suite 2016.3 has MDM management built into its core functionality. Once a device is enrolled, you’ll have access to apply a number of different “Agent Settings” commonly known as Configuration Profiles in the Apple world.
LDMS 2016.3 has 4 out-of-the-box editable agent settings that can be built and assigned to a Mac or iOS device; Mobile Compliance, Mobile Connectivity, Mobile Exchange/Office 365 and Mobile Security. You’ll find all of these profile in the Agent Settings tool within the Configuration toolbar of the Management Suite console.
Mobile Compliance can be used to ensure the device’s integrity. For example, you can enable a compliance rule to detect if the device has been jailbroken and if it has, choose to selectively wipe it removing access to everything you’ve deployed to the device. 
Mobile Connectivity is where you would upload certificates to be used to bind to WiFi as well as the appropriate settings for the device to access your corporate WiFi. 
Mobile Exchange/Office 365 should be self-explanatory. Within this setting you’ll configure how your MDM devices will be configured to access your corporate email. 
Mobile Security has the real meat and potatoes for the agent settings. You can set a password policy, restrict the device functionality such as access to FaceTime, block access to the iTunes store, set the accessible ranges for content and ratings, control the behavior of iCloud and even block TouchID from unlocking the device. 
Mix and match the agent settings as desired, when deploying them out you do not need to employ a “one-size-fits-all approach.” When you create your Agent Settings task, you can select one of each to deploy at, giving you a ton of available combinations of configurations.
Once you have all of your Agent Settings created as desired, just create a Change Agent Settings task and target your MDM devices.
Once a device is added to a task and the task is started, every time the device “syncs” with the LANDESK Management Suite server, it will compare itself against the current scheduled tasks on the core with what it currently has applied and will add/remove profiles accordingly. So don’t delete your task once you’ve successfully applied an agent setting, so doing would in effect tell LANDESK to remove the agent setting from the device the next time it syncs.
Creating and deploying a VPP software package to either a macOS or iOS device is a very simple process within LANDESK Management Suite 2016.3. See the instructions below or watch the short video vignettes to be off and racing down the VPP software distribution track.
The iOS package creation is nearly identical, so I won’t include screenshots in these steps.
As mentioned in my previous post, LANDESK announced their 2016.3 release for Management Suite and with it comes the ability to completely manage macOS and iOS via via an MDM profile. If you’re lucky enough to have all of your macOS and iOS devices participating in Apple’s DEP, getting the devices enrolled into the LANDESK Management Suite server will be pretty straight forward. In a later blog post, I’ll cover how to configure DEP within LANDESK
If you’re asking how you place your devices into Apple’s DEP, it may be too late. As discussed in Apple’s DEP FAQ, in order for a device to be enrolled into the DEP program, it’ll need to be purchased directly from Apple or from an authorized DEP reseller. Which means it’s likely that ship has already sailed for you.
Alas, all is not lost. You can manually enroll any device into LANDESK, whether or not it’s participating in Apple’s DEP program.
Before you get started, make sure you have all of the architecture pieces in place as outlined here. Also, if your Macs already have a LANDESK agent installed, at this time, do not place an additional MDM profile on it as well.
LANDESK announced their 2016.3 Management Suite release this week and with it comes a number of enhancements to mobility management, including a number of enhancements to the iOS/macOS platforms for MDM management. Included in the 2016.3 release is the ability to integrate with Apple’s Device Enrollment Program (DEP) and Apple’s Volume Purchase Program (VPP); including supporting multiple VPP tokens.
Luckily, LANDESK has the documentation already available for this configuration. For ease, I’m going to aggregate all of the needed information to get up and running with LANDESK MDM in one spot.
The LANDESK Mobility Device Management does require a LANDESK Cloud Service Appliance. This can be either a physical appliance you host in your DMZ or a virtual appliance. If you do not have a CSA, contact your sales representative. They’re inexpensive and give you the ability to manage devices off your network.
LANDESK’s Workspaces application for iOS has the capability to integrate with LANDESK Management Suite; enabling users to see software catalog objects and Launchpad links published from Avalanche on Demand. In addition, based on a user’s role, he/she can see other devices and users information, such as the asset information related to a device, remote control options, tasks applied to a device and even install software to a managed node, all from within the Workspaces app for iOS.
While the Workspaces app for iOS is powerful, it requires a few unique configuration steps in order to properly take advantage of all of the features. This white paper will discuss the steps required to obtain full integration with LANDESK Management Suite and LANDESK Mobility Manager.
LANDESK Workspaces is driven by an HTML 5 backend service that is hosted on LANDESK Service Desk or LANDESK Management Suite. You need to ensure you have the proper settings applied within the Configuration Center for the respective platform you’re using to host the Web Services. If you own both LANDESK Management Suite and LANDESK Service Desk, you should host the service on LANDESK Management Suite so that it can properly integrate with the user/device based search. For more details on the different types of configurations, seehttps://community.landesk.com/support/docs/DOC-34966
To properly apply the appropriate settings for LDMO integration, launch Configuration Center by going to http://servername/ConfigurationCenter. The default username is ‘sa’ and the default password is ‘administrator.’ Now you are also going to need to know your customer ID, generate a workspace public key then apply it and sync managed devices from AOD. To do this, you’re also going to need to launch http://aod.wavelink.com or your own hosted instance and follow these steps:
| Configuration Parameter | Value |
| Name | Whatever this is already set to (My.BridgeIT) |
| Application Pool | Whatever this is already set to (My AppPool1) |
| Logon Policy | Token Only |
| LDSD Web API URL | http://servicedeskservername/tokenonlyinstancename |
| LDMS Web API URL | https://ldmsservername/ldapi/api |
| STS Issue Token URL | https://ldmsservername/STS/issueToken (This may be set to the SD token server LDMS is not in the environment. If LDMS is present, use it) |
| Avalanche Enterprise Server URL | https://aod.wavelink.com (This server will be different if you’re hosting AOD in your own environment. Refer to your ‘My Account’ page in AOD). |
| Avalanche Smart Device Server URL | https://sds.aod.wavelink.com (This server will be different if you’re hosting AOD in your own environment. Refer to your ‘My Account’ page in AOD). |
| Avalanche Company ID | Paste your value from step 2 (aa1a1111a-aaa1-1111-11aa-1a1111a1111a) |
| Enable LDMS Agent Integration | True (If using LDMS) |
| Core Fully-qualified server name |
|
| LDMS Service account | Domain\username |
| LDMS Password | serviceaccountpassword |
| LDAP Server Address |
|
| LDAP Username | Domain\username |
| LDAP Password | serviceaccountpassword |
| Cloud Services Appliance Public Address | https://cloudserviceappliancename.domain.extension |
For proper integration with LDMO and LDMS, LANDESK Workspaces must be deployed from AOD itself. Therefore, before any additional steps can be taken, you need to make sure your iOS devices are under management. For more information on how to enroll an iOS device into AOD, see:
A payload is essentially a package with instructions for the mobile device. Payloads can consist of specific settings such as restriction settings, app package information, certificates or links to files or services. We are going to create a software payload that distributes LANDESK Workspaces to all managed nodes.
One of the primary purposes for the Workspaces application is to allow end-users the flexibility to install optional software titles, view documents published and to access links to external services. Use this step to configure some optional objects so that when the user accesses Workspaces, content will be available to them.
A profile consists of one or more payloads that can be assigned to the mobile devices via group based targeting. We now need to create a Profile that contains, at the minimum, the LANDESK Workspaces payload. However, if you desire, you may also include other payload types, such as a passcode settings payload, wifi settings, certificates, links, documents as well as other optional or required applications.
Profiles are targeted to a user, Active Directory group or mobile device group. Mobile device groups allow you to group devices together based on selection criteria you configure. You can create dynamic or static groups. In both group types, new devices can be added to the group based on changes to the selection criteria. For additional information on creating mobile device groups, click here.
On the iOS device, the end user should be prompted to install the ‘LANDESK’ app. Proceed with the install on a device by device basis. If this is the first time a device is receiving an application, additional prompts for VPP or other configuration settings may also prompt. Once the application is installed, we also need to force the devices to check in and sync their information two separate times in order to finalize the Workspaces app enrollment.
You should be all set at this point and capable to login to Workspaces for iOS on your device.
The Launchpad feature inside of Workspaces for iOS can handle much more than just URL links, however, this process has not been documented and is a bit rough around the edges when it comes to the usability. Nevertheless, by adding the deep link path or URI information into the launch path of an app, once installed on the mobile device, Launchpad will display a tile for the app and if you’re lucky (dependent on the app vendor) an icon associated to the app.
In the screenshot of Workspaces below, I have created a deep link to the app Evernote, Hootsuite, LetMobile, iOS Mail, Salesforce1 and Twitter. I also have standard links to the LANDESK Community and one other site. If I were to click on Salesforce1, it would initially prompt me to allow (this only takes place the first time), and then open up into Salesforce1. However, because it was launched from Workspaces, you’ll see at the top left of Salesforce1 there is a link back to LANDESK.
As such, using this method, one could theoretically create a whitelist of approved apps and links, put an iOS device in supervised mode and only allow Workspaces to run. So doing would allow the admin complete control over the device and what is allowable to execute.
Mobile deep linking consists of using a hyperlink that links to a specific piece of content within an app or to just the app itself. For example, the deep link for Twitter is twitter://. Putting twitter:// into the launch path will open the app Twitter to it’s default home page. However, if you add twitter://timeline it will open up the app to the timeline feature. This deep link needs to be added to the Launch path section of the iOS software payload. For more in deep linking, see: Mobile deep linking – Wikipedia, the free encyclopedia
Setting up a software package to be deep linked is quite simple. All you need to do is put the deep link into the Launch path on the software payload for the app. See the screenshot below for Hootsuite. However, if the app you’re trying to deep link is included within iOS, such as iOS Mail, you’ll need to use a Link Payload inside of AOD under the iOS and Android section.
Figuring out what the deep link is for a given app is going to require some patience as they’re not always published and not exactly obvious. You’ll need to employ a “try and see” approach or maybe even contact the vendor. In my limited testing, I was not able to discover Cisco AnyConnect or Cisco WebEx. As a tip, I would attempt to find the URI by searching for the name of the app combined with iOS to pull up the itunes web link. That web link will contain the app’s full name as well as the ID. I would take that full name and attempt to combine words to discover what the URI might be. This helped me figure out that 1Password’s URI is onepassword:// and not 1password://.
The deep links I’m aware of are:
Apple in the Enterprise Moved 
Recent Comments