A question that I get every now and then from people are how to health check or validate their environment. I get this question for a few reasons. (1) Their PSO engagement was a few years back and they struggled to keep up with the evolution of Workspace ONE and (2) sometimes you just get a bad PSO engagement. It can happen at any company. Some people are really good at health checks and others not so much. I felt this week as we move into the last month of the year to discuss a bit of spring cleaning.

Health Check Document Structure

At the end of the section, you will be able to download my template, which will help with some of the structure of things for you.

Main Overview and Infrastructure Overview

Typically, in my Health Check document I will start with a short overview that covers the version of the existing environment and talks about the focus of the health check. Make sure you leverage proper headings so you can build a table of contents, which helps with readability. You can see what my overview looks like below:

Next, I will typically use some sort of infrastructure overview to set the stage along with a user count by platform. Its entirely up to you if you want to use screenshots or create a pie graph. For the purpose of my template I used screenshots, but I suggest a pie graph which I think relays a better feel:

Groups & Settings

At this point, I will move onto bouncing through every part of Groups & Settings and providing some good best practices like you can see below. I think this is better than just mentioning everything they’re doing. Succinctness is key here:

Profiles, Smart Groups, and On-Premises Infrastructure

Now, I will build out profile and application evaluations to show them what they’re currently using:

Profile Name	Platform	Config Type	Payload	Assigned Groups	Excluded Groups	Installed Status
iOS Passcode	iOS	Device	Passcode	All Devices		6/0/6
Android Passcode	Android	Device	Passcode	All Devices		6/0/6
Boston Email	iOS	Device	Exchange ActiveSync	All Devices	Boxer Users	10/0/10
London Email	iOS	Device	Exchange ActiveSync	All Devices	Boxer Users	55/2/57
iOS Restrictions	iOS	Device	Restrictions	All Devices		576/11/587

That will then follow what I would recommend like this:

I follow this with some smart group recommendations especially when I find people aren’t really using smart groups properly e.g.:

Profile Name	Platform	Config Type	Payload	Proposed Smart Group	Assigned Groups	Excluded Groups
iOS Passcode	Apple iOS	Device	Passcode	All iOS Devices	Synterex Users
Android Passcode	Apple iOS	Device	Passcode	All Android Devices	Synterex Users
iOS Restrictions	Android	Device	Restrictions	All iOS Devices	Synterex Users

Sometimes I will do an app breakdown, but I don’t typically so I’ll leave that alone for now. I will usually finish it off with recommendations on their on-premises infrastructure:

As promised my template is below:

My Methodology on Reviewing Groups & Settings in Workspace ONE

When reviewing groups & settings, I try to figure out what looks good and what doesn’t. The sniff test is not an exact science by any means.

As I cover in my video below, I show and talk about how I basically run section by section and look for stuff that just doesn’t quite make sense to me. That’s the name of the game. You will find, some stuff will be pretty obvious like SSL whereas other things will require checking out the System Settings Reference Manual to find out exactly what some of them mean. The tool tips can be pretty useful, but sometimes its a hot mess to be honest.

Analyzing Workspace ONE UEM Profiles

Looking at profiles is something that is largely based on experience and understanding how profiles work and how taking actions on profiles effects things.

As my template will show you, I document a nice table of the existing profiles so I have a good canvas to work with. Here are a few of the things that I look for:

• Are profiles being grouped together properly? e.g. only put multiple profiles in one payload to share a certificate among Wi-Fi, VPN, Email, etc.
• Did you build profiles consistently cross-platform? e.g. is the passcode profile the same for iOS and Android
• Does the smart group methodology make any sense?
• Are you naming profiles in a way that a human being understands them?

There are certainly more things that you can consider if you get really crazy like are you trying to enforce supervision settings for BYOD and other common sense ideas like that. Profile analysis is mostly about documenting what they have and see what doesn’t make sense.

Mapping Workspace ONE Smart Groups to Profiles

Typically when I think about designing the entitlements around profiles, I look at a persona-based approach.

My personas are typically:

• All of One Platform, such as All iOS Devices
• All of One Platform and one ownership like All BYOD iOS Devices
• Departmental Personas e.g. Human Resources
• Title-Based Personas e.g. Directors
• Title-Based Department Personas e.g. Directors in Human Resources
• IAG-Based Smart Groups like Cisco AnyConnect Users

By designing smart groups around that concept you can ensure that people get exactly what they should be getting and provide the best user experience. It’s good to point out that you leverage user groups and LDAP queries to deliver attribute-based personas like titles and departments. I cover that in an article last year about elevating your Workspace ONE deployment. It looks like this below:

Another thing that I like to look at is the ratio of user groups to smart groups. I tend to see a lot of people over-using user groups and the ridiculous creation of user groups at sub-Org groups. Regardless of what anyone tells you, there is only one right way to do it, smart groups at the top period. No matter how perfect you think you are, you are still human and not autonomous machines.

Reviewing On-Premises Infrastructure

The last area is reviewing the On-Prem stuff. It can be relatively complex and only improves with experience. Let’s cover a small punch list:

• Is the software up-to-date?
• Are they on a reasonable Java version?
• Review config files and see if anything jumps out at you
• How are they deploying their UAGs?

Most of what you should be looking at can be found in my template, but it comes with experience and understanding the underlying OS. You should have a good understanding of Windows Server and Photon OS. Cloud Connectors are pretty simple nowadays. For the most part, it’s about keeping it up-to-date and tweaking the config file to suite your performance requirements.

UAGs come down to building a strong deployment strategy. UAGDeploy is crucial to understand like I wrote about before. You can get a strong understanding about the UAG from some of my documentation. The biggest challenge is building that right INI file, but once you do its just rinse and repeat. I also recommend reading my deep dive into the UAG.

Final Thoughts

So that was fun! Many companies pay $10-$20k for a health check, which is sort of amusing. The economics of it are great, but basically you are paying someone to tell you what is wrong with something you already paid someone to build for you. It’s a bit tedious to think about, but Professional Services can be a real crapshoot. You can get someone amazing, someone medicore, or even someone just downright awful. That is why you will see in Customer Service Organizations that when you find someone special you cling to them.

Hopefully giving everyone a peak behind the curtain into my process gives some insight. There is a right way and a wrong way to build every technology. It’s mostly about evolving, modernizing, and understanding the problem you are trying to solve. Evolution is never easy, but it is attainable.