Last week, we discussed the evolution of mobility over the years. We will shift in part two to discuss the ways that we had to evolve and adapt to that same evolution. The life of a mobility engineer is full of peril. Some of you didn’t survive the changes, such as BES administrators who didn’t have the skills to learn UEM and others who shifted to entirely different disciplines. Let’s discuss each step of the way and the skills that your toolbox needed.

The Skillset of BlackBerry Administrator

In the years of BlackBerry (and forgive me I will be doing this from memory), you needed to understand a few different things:

• How to navigate the GUI within the BES console
• Basic Windows Server administration
• SQL Server basics
• Some basic Cellular and Wi-Fi connectivity and OTA knowledge
• A solid understanding of how BES communicated with devices, the synchronization patterns, and the operating system
• Basic understanding of how Exchange works and some MFCMapi knowledge.

Your standard BES administrator would activate devices, validate functionality, ensure BB Messenger was functional, apply upgrades, understand how to update the OS, and a good understanding of the device sync patterns. One of the brilliant things about RIM/BlackBerry was their stellar documentation. Your job was made so much easier by great technical documentation, such as their Knowledgebase, performance benchmarking, and overall solid administration docs.

Things would get a bit more complicated when you would have to do certain stuff like building out high availability, doing database cleanups, or dealing with problematic user issues. Overall, once you had built up some familiarity with the platform you could become very strong. Don’t forget these were the days when you could do wired activations and all sorts of crazy things that would be foreign today. Things were certainly going to change rapidly.

MDM Creates Evolution in Mobility

The release of iPhone and Android to the MDM space would really create this major shift in the mobility space. Enter our friend: ActiveSync, which I wrote about quite a bit some years back.

ActiveSync would really change the way things were done as we would move to this whole sync paradigm now:

We knew a platform that delivered stuff exactly when it was there and was super efficient in BlackBerry. ActiveSync would move to this new concept where it would sync folders in intervals as seen above powered by Direct Push.

How Direct Push Completely Changed the Mobility Game

Direct Push can be seen below:

Direct Push would really change the game for many organizations. In the past, things would just work, but now you had so much more to account for. ActiveSync was very sensitive to Idle Session Timeout settings on every step of the mail flow, which created so many challenges.

The Skills We Needed Had Evolved for ActiveSync

Now, we had a number of new technologies we had to learn about at least in a basic way:

• Basics on Firewall/Load Balance technologies
• Reading XML
• Understanding HTTP/HTTPs Capabilities
• Learning how ActiveSync works
• Basic Network Flow and Capabilities
• ActiveSync Logs
• WireShark to a degree

This became a run instead of a walk toward ActiveSync or we would sink (pun intended). Investigating device issues was way harder now then it used to be in the BlackBerry world.

We would need to become familiar with ActiveSync device partnerships, troubleshooting issues, and the network team would finally learn we exist! Stuff like this would really matter to us:

It was a really difficult time, which would turn things on their heads. Some people learned how to work with it. Some companies simply accepted their people couldn’t handle it and would get them help, such as having their messaging or network team troubleshoot issues collaboratively. A few did adapt and evolve to this new challenging landscape.

I had the pleasure of spending a few weeks onsite with a large BlackBerry customer teaching them how ActiveSync works and it was a very interesting experience. We would spend a ton of time documenting the flow, teaching them how ActiveSync works, and optimizing their network technologies to work with this new world. Another area that was daunting was evaluating their Exchange setup specifically to make sure they were using “Least Connections” instead of the evil Round Robin

Enterprise Mobility Suites Enter the Fray

The next progression would be EMS (Enterprise Mobility Suite), which has gone by different names over the years, but I prefer EMS. Before now, mobility meant push profiles and maybe a few apps, but EMS would step things up. Now, you would get Mobile Content Management, Mobile Email Management, and Tunnel Technologies. Each of them meant something a little different to us.

How Mobile Content Management Changed Things

MCM would be pretty interesting. I wrote about it a bit here. MCM would introduce the initial concept of digital transformation. We would start to think about going paperless by delivering files electronically through apps like VMware Content Locker. Could we now possibly take those meetings and their handouts and move them to iPads? Yes we can!

MCM would let us deliver security capabilities, access files from internal websites, and collaborate easily. VMware’s platform was useful because it was vendor agnostic and would support anything WebDAV-compliant. Many people define digital transformation in different ways, but at its core nothing is more transformation than moving away from paper.

How MCM Made Us Elevate Our Mobility Skills

MCM introduced some new concepts that would create challenges. We now needed to know:

• SMB/NFS File Protocols
• File/Folder Structures and their Requirements
• DLP

This for me personally was a challenge. You had to really learn how WebDav works:

You would have to learn about file and folder synchronization works. We would learn about the way SMB works, delivery methods, and caveats around them. Beyond that, you would start having to learn about DLP. We would need to make sure these files could only be opened in trusted locations, which would just complicate things further.

You could also lump in Microsoft’s App Protection Policies, which we bring into the discussion. We would need to start thinking about how to securely grant file access on mobile devices. On top of that, we would basically become ghetto pen testers trying to make sure we weren’t compromising our organization.

Mobile Email Management Stops By

Mobile Email Management (MEM) in the pre-Office 365 days was a major necessity now. People wanted email protection like they had at BlackBerry. This was a requirement for many people to move toward a UEM-centric management platform powered by consumer devices.

AirWatch had a very effective way of doing with their Secure Email Gateway. A few might argue that “Microsoft has ABQ” and I say to that simply, screw! ABQ was literally the worst idea and was not a manageable solution. Some people had no choice, but for the most part it was a major issue.

Basically, the idea around MEM is a proxy in front of your email server that will evaluate your requests and ensure only trusted devices are allowed:

We gain so many different things from MEM like attachment encryption, email compliance, and not needing to expose your email servers to external traffic. The reliance on MEM has largely subsided with most companies moving to Exchange Online. O365 users now shift the reliance to Mobile App Management, which is more achievable with less tech debt.

How MEM Made Us Better

Mobile Email Management overall was pretty easy to achieve. You built a policy, installed some software, and could get stuff done! Most of the magic behind MEM was from your network team setting up your load balancer in front of your MEM solution. We would often duplicate the setup we were using for Exchange and extend it to our MEM solution.

There were some advanced setups with Kerberos Constrained Delegation (KCD) to deliver seamless SSO (which is basically the holy grail of UEM), but at this point most people weren’t doing stuff that complicated. The challenge with MEM was needing to have a deeper understand of Exchange at this point. I spent time learning the different protocols that were available in Exchange like RPC, ActiveSync, MAPI, etc. because around this time we started to look at things that would revolve around stretching our experiences.

Tunneling Technologies: Time for Linux

VMware was one of the first to introduce the idea of using a Mobility/UEM component to deliver a pseudo-VPN for mobility. The idea was super appealing because we could never get close to the Cisco and Pulse Secure stuff, which could give us more ownership of the End User stack. AirWatch Tunnel was a good example of things:

The major issue that we had here was that we had to learn Linux. We will cover that more shortly, but let’s hit on the basics. AirWatch Tunnel and Proxy would let us do a few things:

• Use a Work Browser that could access internal sites (something we were super familiar with the idea from BlackBerry and our friend MDS-CS)
• Using a Per-App Tunnel to grant apps access to internal resources like a Jira Server, SharePoint Apps, etc.

These technologies would work with certificates seamlessly behind the scenes and device compliance to securely grant access to resources. It was a huge advancement in mobility, which would only grow with SDK-integrations and advancements on the OS side.

Tunneling Technologies Created Major Roadblocks for Mobility Engineers

We would inevitably run into major issues at this point. We had always lived in the Windows world, but now we were dealing with products using some strong open source technologies that moved to….. LINUX. It was crazy. We had companies who were struggling to find people who could support it AND mobility people who had never seen Linux or brands of Linux before. Some of the things overall we had to learn:

• How to patch Linux servers
• Navigating the Linux file system
• Working with .config files to customize and configure our applications
• Learning all of those commands that would become the lifeblood of our day-to-day lives
• How to possibly troubleshoot these systems
• Moving away from the GUI

We have never seen the level of culture shock that we did at this point. I remember quite vividly from experience how rough that learning curve was. I spent a ton of time trying to teach myself how to move around. Let’s count all the things that I couldn’t do:

• Why doesn’t DIR work?
• I can’t use IPConfig?
• Where is everything?
• I have no idea how to restart things or even restart this server!

Where did we go from here with Linux?

I really struggled trying to figure out my next steps. Eventually, I was able to figure out how to make Linux work for me and navigate the evil shell. First, I started to learn the commands that would make such a difference like:

• Systemctl to restart services
• Cat to print out files
• Cp to copy files
• Openssl to start working with certificates
• Sudo to elevate
• Tcpdump for packet captures

There are many more of course. I really like this article that shows a number of commands that are common in Linux. It was really challenging to learn how to operate in a shell so much, but I learned to adapt. When we started to move toward a less-GUI world many people would faulter, but some of us really did a great job to elevate our skillset.

As you learned in these sections, Mobility was evolving quickly and new skills were layering and being a necessity. Things were so different now and they are only going to become crazier.

Enter Unified Endpoint Management

Welcome to the start of UEM! Now, stuff was really starting to get crazy. A few new platforms were becoming a part of our lives: MacOS and Windows 10. I’ve written quite a bit about both of these platforms: MacOS and Windows 10 as most people know.

What most people don’t realize is I stumbled quite a bit through both of them. Let’s start by discussing MacOS and what its like learning about it.

Learning MacOS Management

When we try to learn MacOS, it was somewhat familiar. Many of the core concepts were the same as iOS. We were dealing with apps and profiles and all that good stuff. Sadly, we would learn there were a few major differences functionally:

• Scripting
• Domains/Authentication/Logins
• Agents and Daemons

Mobile was all about following the rules. Desktop platforms are about pushing the outer limits of the operating system to make something magical happen.

As I mention above, you just don’t follow the rules anymore. True engineering is about solving problems through creativity. Profiles are just the first layer. The second layer would be writing scripts to automate or enhance the user experience. Some of the examples that I achieved via scripting as found on my Github are:

• Configuring Remote Management
• Modifying App Settings
• Cleaning up Expired Certs
• Trusting Intermediate Certs
• Configuring the Menu Bar

Similarly, we used Launch Agents and Launch Daemons to trigger scripts when the user logins. This was similar to all of those Windows login scripts that were used to seeing for years. An example of daemons an be seen below, which are also found on my Github:

MacOS Management is about knowing that nothing is one size fits all. It’s not for the feint of heart, but you need to be open-minded. You can’t do everything with profiles despite what vendors may tell you. You need to use the right tool for the right job period.

Another valuable lesson I had to learn while perfecting MacOS management was around authentication. I always thought that there was only one way to authenticate since that is how mobile worked. At that point, Mobile SSO was the only right way to do it. On Desktop OS’, we thought you obviously should domain join it and do Kerberos. We were so wrong! I would come to learn that MacOS does not do a great job at Kerberos and I learned that you should always use the right tool for the job. By the end, I learned certificates were the right choice. Lesson learned: follow the data and don’t just assume because it only leads to failure.

Learning Windows 10 Management

Windows was relatively similar. In Windows, they introduced CSPs which were basically VERY similar concepts to a traditional MDM profile.

Windows Setup Efficiencies

We continued to learn that there is so much more to learning Windows Management. One of the areas we had to learn about was Windows Setup automation. It became important to understand how a Windows 10 PC would come to life. Whether it was autopilot, basic imaging, or VMware Dropship Provisioning a strong foundational understanding there was important.

The goal was to enroll a PC during its OOBE (Out of Box Experience) and achieve that solid near zero touch experience you needed. Some of the areas overall I had to learn was:

• Windows Provisioning Packages
• How to write Answer Files (a.k.a. Unattend.xml)
• How Reset PC worked and what it did and did not do
• PC Imaging Concepts

As I progressed through and could eventually deliver this sort of experience below, I felt that I was truly starting to understand the innerworkings of EUC:

You can obviously read more about the innerworkings of Windows Management on my blog. Today, we are focusing on talking about the skills that you need as technology develops and advances deeper.

Other Aspects to Windows 10

There is so much to learn and consider on Windows 10. I had to learn about how different app deployments are. There was extensive testing of silent app installs and learning about application validation criteria, using PowerShell or CMD to build similar automations as I did on MacOS. I also learned how to more effectively use Windows Scheduler to bring my automations further. The reality of UEM was that you could no longer follow some random playbook and expect to be great at your job.

Now, you are expected to analyze the technology, test, iterate, and deliver a strong experience. This isn’t going to slowdown as we see UEM growing to ChromeBooks, Oculus, iOT, and so many more permutations as we move further. Windows 10 offers a huge opportunity as you deliver a platform that has huge potential. Moving away from that archaic VPN-needy platform and toward a more flexible and internet-centric solution performing patching, security remediation, and more without ever touching the domain.

The last area to touch on was the migration from GPOs to Security Baselines. Baselines are familiar to people on the server side, but it was a whole new world for UEM people. Trying to translate an archaic GPO that was often coming from an Active Directory environment that was in dire need of TLC is no easy feat. Therefore, leveraging Security Baselines to extend GPOs to non-domain-joined PCs is an amazing advancement that is very challenging.

Three Ways I Can Evolve

The question you should be asking yourself at this point is: “How can I evolve my skills to meet the trends?”

Below are 3 ways that you can evolve with the times and get ready to become a true technologist in not just mobility but the EUC world:

• Become more familiar with WireShark
• Start to practice using REST APIs
• Leverage great community tools to learn something new

Becoming More Familiar with Wireshark

As I wrote about in the past, a proper toolbox is so important. Tools like Wireshark, Fiddler, and other similar products can really help you build a stronger understanding of technology. People are so intimidated by products that are foreign to them. If you have proper tools at your disposal, you can be unstoppable.

I really love using Wireshark to look at stuff like LDAP where you can see how the sausage is made. We need to stop making excuses and relying on other teams to do our jobs for us. If you have passion and love for what you do, become the Sherlock Holmes of mobility and live for the puzzle.

Practice Using REST APIs

The best way to practice REST APIs is with my PowerShell Tool for Workspace ONE.

I suggest opening it up in PowerShell and trying to modify some of the code to solve a use case that would help you today. You can see in the code below what it looks like:

By looking at some of the code, you can see how it works. You could try to modify it and test something out. It’s easier than you think it is. You can use my code and the WS1 Rest API Documentation to try to design some stuff of your own. It’s a really great way of developing your skills by trying to work with REST API, which is the future.

  $SG = Read-Host -Prompt 'What Smart Group are you looking for?'
    try {
      
$profiles = Invoke-RestMethod -Method Get -Uri "https://$wsoserver/api/v2/mdm/profiles/search?status=active&searchtext=$SG" -ContentType "application/json" -Headers $header
$profiles.ProfileList | format-table -Property @{Name = 'Profile Name'; Expression = {$_.ProfileName}},@{Name='Assignment Type';Expression = {$_.AssignmentType}},@{Name = 'Smart Groups';Expression = {$_.AssignmentSmartGroups.name}}


}


    catch {
  Write-Host "An error occurred when logging on $_"
  break
  }
  }

Leverage Great Community Tools

The best community tool that I see today are VMware’s Hands on Labs.

With HOL, you can try out new technologies that your company doesn’t own today. It’s a great way to experience new technologies and grow your skill set.

Another great area I strongly recommend are VMware Flings which are open-source products that give you some capabilities you can’t achieve otherwise. By far and away, the most important tool in your toolbox is creative tinkering. It’s really a great way to grow and experience new things.

One last thing I recommend is leveraging Microsoft Trials. You can sign-up for all sorts of trials on products like PowerBi, Power Apps, and so much more in the Office 365 cloud. It really opens up a whole new world at your fingertips.

Where do we go from here in Mobility?

Our latest advancements that begrudgingly are hitting mobility are SSO and VDI. These new problems are causing significant issues for UEM engineers. It’s a two-fold problem: (1) managed service providers expect UEM people to know VDI, which is making it hard to find jobs and (2) companies are becoming more nimble and expect more.

Sure, some companies continue to be flexible and will let UEM people focus on what they are great at. However, the reality is people are going to need to level-up during COVID and start to differentiate themselves. This idea of being good at one thing isn’t really good enough anymore. In other words, you need to be flexible. Adapting to changes and understanding how to learn new technology is a MUST have now. Above all, having a strong understanding of how technology works lends well to your future.

You don’t need to know how VDI and SSO work fundamentally, but understanding their basics are a huge benefit. Everything starts with data flow. As an example, you should know how a mobile device accesses VDI and how that works to deliver SSO seamlessly. In addition, there are several SSO platforms like Azure SSO and even Workspace ONE Access to a degree that are simple to grasp. We should make a point to not shy away from those technologies as their synergy is essential.

If you want to learn, I suggest checking out SAML Tracer and looking at the traffic on a SSO attempt so you can understand what is happening. Building familiarity and figuring out some of the basics helps you speak to some of these technologies. Let’s move into the new world together and eliminate the obsolescence movement that is sweeping IT.