Hello my little mobile minions! It’s been a slow week or so, but I wanted to write something to help out my friends. I thought that sharing a few of my secrets to building an amazing WS1 environment is right on point!

Typically, you will have “someone” build your initial WS1 environment whether its Professional Services or someone like me. The unfortunate truth is people tend to meet a bare minimum to get you operational. Many of the nuances that build a compelling environment are lost on them. Without further adieu, let’s start my top 5!

Leveraging LDAP in Workspace ONE to Automate User Placement

One of the things that I see a bunch are people improperly using Smart Groups and User Groups. They can be very powerful if you are doing things right. LDAP as seen below, is basically a way of extended Active Directory to your WS1 UEM environment while leveraging synchronization to automate the creation of users and groups.

We can leverage this in a powerful way, with a few tasks: (1) creating user groups with custom LDAP queries and (2) mapping those groups to organizational groups in WS1. The basic rule of thumb today is that organizational groups should only be used for two things mainly: (1) role-based access and (2) geographical disbursement of products like VMware Tunnel. Anything beyond that is definitely overkill and sadly we see that all the time! Let’s cover creating groups with LDAP queries.

Creating LDAP Groups

We start by going into Accounts > User Groups > List View and creating a new user group. By using custom query, we can make some magic happen! As you will see in the screen below, we enter in some custom logic e.g. (physicalDeliveryOfficeName=Dedham) in layman terms means “give me anyone who works in the Dedham office.”

We can get even crazier than that! Say, you want to say “Give me anyone in the Dedham office OR with a certain title!”

Let’s see what happens when you just add it:

So that didn’t work did it?! We can use operators to build something fantastic! By adding in a “|” you can build a query that says give me people in this office and with this title!

This sort of pliability empowers you to create some compelling automation. These groups will sync once per day and let you build an amazing model of excellence. The last thing you should do before saving is changing the “User Group Settings” to custom and customize the behavior as seen below. I like to have my groups add members automatically. One HUGE value is making sure you only have a small amount of “maximum allowable changes” That feature has really saved me in the past when someone screwed up bad and removed a bunch of people from an AD group. This gives you a catch to protect yourself from “boo-boo’s”

Mapping User Groups to Organization Groups

One can argue that you can modify the mappings when creating these user groups, but I think its better to do them in the settings menu. Firstly, we use these mappings to put members of user groups in the right organization groups. This serves a number of great purposes.

We can use these mappings to move people to other tunnel environments, other SEG profiles, or content gateway configurations in the event of a DR scenario. I created groups that organized users based on their Exchange Mailbox attribute in AD. When a failover hit, it would move them to a different container after a sync and bring them up quickly.

We access Grouping in Settings > Devices & Users > General > Enrollment > Grouping. From there, we can simply click “Edit Group Assignment” to build something compelling.

We simply click edit, and select what organization group to map it to and click “Change”

Once done, don’t forget to click “Save” on the page to apply your changes. I’ve found this is a really special elevation to a mundane environment, but you want to be careful. In some of the older environments, I’ve seen that they are building profiles and assignments incorrectly which could cause disruption when you implement this. That will take us into my 2nd tip!

Leveraging Smart Groups for All Deployments

You might ask yourself: “Is this really worth mentioning?” The answer is 100% YES YES YES! Every environment that I have joined, this is done incorrectly. Simply, you should be using smart groups for EVERYTHING. The best way to know if things aren’t right is to look at one of your profiles. If it looks like this, you are in trouble:

That globe icon means you aren’t using smart groups. You’re using organization groups to deploy things. That will always lead to a bad time for everyone eventually. The concerns around that design besides it being so 5 years ago is that any device movement at all will remove profiles and potentially cripple your users.

VMware has made it very easy to build profiles now. You can see that there’s a “Create Smart Group” button inside of the profile itself:

I frequently leverage user groups and smart groups together for an entitlement model. My idea is that we don’t deploy apps or profiles to a “person” but to a “role” e.g. this application should go to everyone in the Dedham Office. Two of the things that I love to call out with profiles now are the evolution of enrollment categories which gives you laser sharp focus with your deployments and using the device preview tab to eliminate mistakes.

Unless you have a lot of experience with smart groups, I don’t suggest doing this yourselves. Mistakes are often made during a transition because of how confusing legacy setups can be. An extra set of eyes or working together with others is always strongly recommended.

You might ask why do we love smart groups? The answer is they are very flexible. You can deploy profiles or apps only to specific OS versions, management types, members of user groups, and much more. This helps us transition to my 3rd tip.

Carving out User Personas in Workspace ONE

This is a weird one to mention, but many of us aren’t experienced with this concept. The best way to design and deliver anything in IT is with precision. We achieve precision in WS1 by carving out specific “personas” to deploy things with. I am going to focus on a few concepts:

• Device-Based Personas
• Directory-Based Personas

Device-Based Personas

You can define a persona simply as a “type” or a “collection.” I’m sure Microsoft or whoever may define it a bit differently, but I like to look at it more simply. The idea is to come up with a concept of group devices which simplifies how you deploy. Some of the device-based personas I recommend are:

• Corporate Devices
• BYOD Devices
• Corporate iOS Devices
• BYOD iOS Devices
• Corporate Android Devices
• BYOD Android Devices
• Shared iPads

There’s many other options, but typically I look at the different scopes available in smart groups and concoct device-based personas that fit the environment. So you might ask “Why do this?”

We build these personas to simplify and standardize on profiles and app deployment. We can safely say that all corporate iOS devices are going to get X profiles and all BYOD iOS devices are going to get X profiles. By doing this, we eliminate about 60-70% of the guesswork.

Personas help us solve for the unknown. We create these baselines which cover the base apps and profiles that all devices of a certain scenario will get. Next, we will talk about directory-based personas.

Directory-Based Personas

The idea behind the first group of personas is to catch most of the stuff you need. We will occasionally need to deal with special use cases, such as special profiles and configurations for C-Level executives or an application that has limited licenses. This is where directory-based personas come in.

The question you should always ask yourself is: “Does someone need to be granted access to this?” If the answer is “Yes!”, then you should be building smart groups around that. My design focuses on using the same groups that are used to entitle users to the application on the application side to also deploy the application via WS1.

As you build your user groups, you should focus on a few ideas around this. Building user groups/smart groups based on an existing AD Group or creating custom user groups via queries. Some of the personas you may need are:

• IT Users
• Human Resources Users
• Executives
• WebEx Users
• Directors
• Sales Directors

There are infinite permutations for directory-based personas, but think of them as roles. All people within a certain department, office, or company that could also be coupled with a title within those. I tend to ask people to tell me in human words who needs access. It’s our jobs as engineers to translate that to a group.

The most essential part of this is never compromise. Don’t start creating smart groups and manually adding users to them. This is NOT sustainable. Your company owns Active Directory or something like it. We must use the tools that we have at our disposal if we want to build something special.

Managing Public iOS Apps on Workspace ONE Like a BOSS

Many of us for years have deployed iOS apps as “Public Apps” in AirWatch/Workspace ONE. There is a new way of doing things now that is much more effective. I won’t cover so much how to do it in depth, but you can read my recent article here covering the process. Simply, we do a few things:

1. Setup an Apple Business Manager Account.
2. Integrate VPP in the WS1 Console.
3. Buy apps and assign them like we always have.

We have a few reasons why you want free apps as part of the Apple Volume Purchasing Program:

1. Device-Based Assignment
2. Auto-Update of Applications

By leveraging device-based assignment, we no longer need Apple IDs on corporate devices which limits the attack surface. In theory, you can block and restrict corporate devices much more effectively by leveraging this. It’s easy to enable as you see below:

Auto-Update for applications is also very easy to do in the GUI. One of the big issues we have dealt with for a long-time is getting our users to update apps and keep them up-to-date. We all know this is so important for the VMware apps especially as they release monthly updates that often fix major issues.

Let Workspace ONE Protect You

I went back and forth quite a bit on what the 5th and final item should be. I decided that we need armor. We have enough going against ourselves as mobility engineers! Let’s cover a few items that help protect you from shenanigans.

Application Removal Protection

We never work changes at good times do we? Usually its really early or really late and we are freaking exhausted! The application removal protection feature will SAVE your life I promise you.

Imagine you are deploying a new version of an internal application, but you forget to add the right smart groups and you deploy. OH NO! YOU ARE SCREWED NOW! Oh wait, here comes application removal protection to save the day!

All you need to do is go to Settings > Apps > Workspace ONE > Application Removal Protection and tweak the “Devices Affected” section, which I recommend you set to 10. This feature will block the removal of the application from devices and send a notification with a link to approve the action. You’re welcome!

Managed Device Wipe Protection

Similar to our friend above, this feature is also a lifesaver. You access this one via Settings > Devices & Users > Advanced > Managed Device Wipe Protection and configure it in the same fashion. They let you specify wiped devices within a certain time period. You will see these notifications quite a bit when doing device cleanups. Deleted, Enterprise-wiped, or device-wiped devices are caught in this feature.

Privacy

Privacy is another area worth a look. I’ve seen some nonsense over the years where help desk people are cracking jokes about who has Tinder on their phone or just nosey nonsense. You will find privacy under Settings > Devices & Users > General > Privacy. It can be a huge benefit for you to properly restrict what people can see and what is collected.

We need to make sure we consider what is necessary. You will likely want to collect personal apps, but not display them for security/malware purposes.

One major suggestion is to enable the privacy app, which you can do here at the bottom. I promise it will be a huge time savings and people like it more than you think:

Restricted Actions

The last item that I suggest reviewed are restricted actions. People don’t usually change these, but they should. This is a list of the actions that will require the admin’s 4-digit PIN before proceeding. VMware fails to enable this for a ton of things it should, such as:

• Apps Deletion
• Profile Deletion
• Provisioning Product Deletion
• User Account Deletion and more!

You can find these settings in Settings > System > Security > Restricted Actions and it is 100% worth reviewing them. We need to make sure we protect ourselves as much as possible. It’s remarkably easy to screw things up in the Workspace ONE UEM console.

Let’s Tidy Things Up

Workspace ONE is a good product that for the most part delivers a great user experience. We should always be aware that some of the textual information on the administration side can be a bit confusing. We leverage some of the concepts that I mentioned today to leave less to the imagination and rely more on automation and controls to protect our organization.

Hubris will always lead to your demise in IT. You need to evolve and learn constantly. I try to read the WS1 release notes found here when they come out and ask myself “Is this useful?” Chances are you just might learn something.