So, I’ve surpassed roughly a year since I started down the path of Windows Management. Going back a year or so ago when VMWare made their huge Dell Provisioning Announcement, then speaking at Dell Tech World, and starting a major transformation at my company…things have been “interesting”

I’m going to take you down the path of what I’ve learned, what mistakes I made, and what you can do to ensure things are successful. It’s not easy and it’s MUCH harder to manage than iOS, but it’s definitely possible and a major difference maker from SCCM. Sorry SCCM Administrators. Your product is old and antiquated despite your thoughts to the contrary.

How I got it in the Door

Trying to persuade your SCCM team can be so challenging. This is something that I discussed when I presented at Foxboro. Infrastructure Teams are heavily on defensive today. They’re moving infrastructure to the cloud, getting hit with staff reduction because of it, and they’re often on the defensive. You often are sitting there trying to figure out: “How do I convince these people to listen to me?”

Contrary to popular belief, Jon Towles is not a magician. I sold this with one simple yet annoying blue screen that we know and love:

The fact that I could use Workspace ONE to do TPM-based authentication and eliminate this evil blue screen was the most brilliant yet simplistic thing ever. I knew that doing this would get me in the door and it did just that! But were there other things that got me there? YES THERE WAS!

The other item that I wanted to bring up was the ability to schedule firmware updates via Dell Command Update leveraging their automation (which admittedly is still a work in progress and should be fixed in DCU 3.1).

I’m not going to be talking about Dell Provisioning during this blog but feel free to read my previous post on Dell Provisioning. It’s a very powerful technology that is still in 1.0, but once they make a few more enhancements over the next 6 months even more people will learn how special it is. So let’s talk about what I have learned about managing PCs.

Perfecting App Deployments in Workspace ONE

Deploying Apps in Workspace ONE can be challenging. The most important rule is, “Try to get a MSI” as MSIs are so crucial to the simplicity of things. Using a MSI, is great because they auto-populate most of the application for you, which certainly makes life easier. If they didn’t, let’s talk about building that application. Additionally, you should deploy all apps in their offline version because as you start talking about Dell Provisioning, it becomes a requirement and you don’t want to have to reinvent the wheel.

Files Tab

The Files Tab has a few key areas that I like to focus on: Dependencies and Uninstall Commands

Working with Dependent Applications

The biggest key when building any application for Windows is that you need to be very careful and deliberate because if you get into version hell and start getting inundated with toast messages (pop-ups about failed to install, successfully installed, etc.) you will hurt your credibility and people will think its garbage. So…

The way dependencies work is you can set apps as dependencies for other apps, which is very crucial. Let’s think about the use case. Let’s say you have an application that requires Java be installed before its installed. You have two options: (1) THE WRONG ONE and (2) use dependencies.

You can set dependent applications so that apps are installed in the right order and helps ensure you have a smooth and consistent application deployment. This is a huge help and really saves you some time. There’s only two requirements, (1) Set the app as a dependency app when you originally deploy it and (2) set the other app with the first app as an dependency. A good rule of thumb is to take any “utility-like” app and set it as a dependency originally like Java. You can’t really walk it back afterwards, so make the right decisions initially so you don’t need to impact your users.

Uninstall Commands

Engineers tend to be bad at following through. Simply, you should think about what happens when people need to upgrade an application or you want to remove that application. If you don’t handle uninstall commands appropriately, it will be an issue.

I strongly suggest using a test machine to test the command line installs and uninstalls of your application. MSI’s are easy as you just do msiexec /X {Product Code} and presto-chango good bye application!

Sometimes applications can be a bit more challenging when you’re working with EXE’s and other stuff. Office 365 for example requires that you build an uninstall XML file that looks like this:

The morale of the story is KNOW YOUR APPLICATIONS, or follow-up with the vendors directly to see what scripting is possible for this. One of the reasons why people hate SCCM or application deployments in general is that there are a lot of manual steps. The best way to be successful and effective is to eliminate all of the manual processes. This means that if you cannot do it all, then consider product provisioning to deploy the entire application, run some powershell, copy files, etc.

We can definitely do better and I have some good examples of how I have gone this route in the past, which can be very effective. There’s no right-size fits all situation, but remember that product provisioning cannot happen during Dell Provisioning so Apps are the ideal if the situation presents itself.

Deployment Options

When To Install

I have seen this area trip some people us. You can very easily make a mistake like require the battery to be at 75% which can make some initial installs stagger and make your IT compatriots cry.

As a general rule, I believe in leaving everything at 0, but you could realistically set them if you REALLY want to, but just don’t. Data contingencies can be a little bit interesting, because you can set things like “if this registry entry exists then install” or “if this app exists”

The biggest failure in IT is how people feel like they need to build these overly elegant and convoluted solutions to prove how smart they are. When it comes to user-facing technology, simpler is always better.

How to Install

This is another area people tend to make mistakes, but proper testing will help. I always leave install context at the device level. I think that’s the best way to do it, but mostly preference. You need to make sure you test your install command via CMD and “ideally” you can install the application without admin. Also, keep in mind if you zipped the application and it unzips a folder app to specify that like install files\setup.exe. If you require admin privileges to install an application, non-admin users will be prompted with a pop-up they need to accept for it to install the application. Again, USER EXPERIENCE MATTERS!

For almost every application, you exit code is 1641 and the success code is 0. That should suffice and just leave the rest of the stuff at their default settings. That usually gets it done. AGAIN, let’s remember to do stuff right the first time and test apps before you try to deploy via Workspace ONE.

App Install Verification

This is by far the toughest part of application deployments. Currently, you cannot change the validation criteria you set unless you deploy another version of the application which again puts you into toast message hell (it is NOT a fun place to be TRUST me)

Update: You can finally edit this now in 19.9!! WOOHOO!!

Most times, you want to use “App Exists” and specify the product code. After you have installed the application you have tested, you should document the product code found in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall and use that to specify as the install criteria. You can see below where it actually documents the uninstall command in the UninstallString value.

After adding it in the app wizard, you should see it look like this. Once this part is done, you can deploy your application and will be ready to deliver that special experience to your users.

Troubleshooting App Installs that have gone bad

Who would have thought that anything could ever go wrong? I know ::GASP::!!!

One of the tools that I love using for this is the VMWare Application Manager which shows you the status of products on the PC itself. You can access it at C:\Program Files (x86)\AirWatch\AgentUI\ApplicationManagerWin32.exe:

One of the things that can be challenging is Windows 10 doesn’t have a sync button from the console, so people can right-click the icon in the task bar to sync the device like this:

One last thing to point out is you have a few jobs in windows scheduler that are useful: (1) the Install Validation Task and (2) the Software Distribution Queue Task. If stuff just isn’t deploying, you can sometimes kick these off to get the party started. It’s always a good idea TRUST ME!

The Registry is…umm….useful now?!

The lifeblood of queuing and application management is handled in the registry. Before we discuss that, you should be aware that all apps are downloaded to C:\programdata\AirWatchMDM\AppDeploymentCache which SCCM admins are very familiar with the concept. Folder..stuff downloads there….agent fires install commands against it… “ta da!”

On to the registry! You will find it roughly where you would expect at HKEY_LOCAL_MACHINE\SOFTWARE\AirWatchMDM\AppDeploymentAgent

We have a few key areas to discuss so you can understand how the magic happens. So let’s get the party started!

App Manifests

The app manifest as you can see below is essentially the application information that tells the agent its modules how to install the application along with recording how the last attempt to install went (commonly found in LastErrorDesc), which is invaluable.

Sometimes when I have an issue with an application, I will delete its folder in the Deployment Cache, delete this key, and the key of something queued if applicable.

Content Manifests

This isn’t particularly important, but I think its sort of interesting to understand. I broke it out into notepad so you can see how it works. It’s basically the manifest that tells you how to download the files that go into the deployment cache. You will see the identifier for app/version, the application name, and then URLs to hit on the CDN.

Again, its not particularly interesting, but you could always test hitting that CDN URL in the manifest if you are having issues with a specific application to download. One key thing to understand is that it will download a ZIP file and ONLY unzip it if the application needs to be installed. The agent will run the validation criteria to see if it needs to install the app. If it does, it will unzip and go about its merry way.

Queue

Most times when you have issues with an application, you will want to start at the queue. When someone says, “I don’t have an application wah wah wah!!!!”, you should first see if its stuck in the queue or if it ever queued to begin with. Let’s be honest, sometimes its a network/technology fail.

If you don’t see it in the queue, do a sync from the Hub and wait a minute or so, refresh, and you should see it. Let’s explain what some of the stuff means.

Log: This is a log of the action in the queue and where it’s at.

ManifestId: That will correlate to an App Manifest so it gives you a nice idea of where the follow the rabbit.

Beyond that you will see some status codes, which I haven’t found to be too relevant.

I’ve found that when you have some issues and things aren’t going good, that its best to delete all of the stuff out of the queue and re-push the apps from the console. This is especially a good idea when you see a few erroneous messages coming from my archenemy the Workspace ONE Catalog UWP App. Hopefully once version 3.5 comes out, we will be in better shape.

General Tips and Tricks that Make Life Easier

So we covered a bunch of stuff that is going to make life really easy for you as you deploy Windows 10. I thought I’d provide a few nice tips and tricks that I’ve found are useful.

• Do whatever you can to avoid deploying apps as admin so you can avoid unnecessary prompts
• Deploy scripts as needed and deploy them as system to maximum benefit.
  • Some script examples I use are:
    • Office 365 Desktop Icons
    • VPN XML Files
    • Updating Drivers
    • Local Setting Changes
    • Installing Tools
• Co-Management with SCCM means you should be adding all new apps in Workspace ONE. The goal is to transition away from SCCM, not to make stuff MORE complicated
• Develop a remote management strategy so you can actually get off of SCCM. I recommend Bomgar as a nice cost effectively solution. I love Workspace ONE Assist but it’s a bit rich for my blood currently!
• Deploy every single Dell application for your Dell PCs because they can be very useful.
  • Dell Support Assist
  • Dell Command Update
  • Dell BIOS Verification
  • Dell Command Monitor
• Leverage Sensors to fill the gaps. VMWare has decent documentation on it here along with some sample sensors here , including ones that I wrote for printers and virtual memory settings. Sensors are really useful for understanding stuff like what printers are installed, if TPM is enabled, and much more
• Don’t get afraid to just get rid of the Workspace ONE Catalog if its more trouble than its worth. The unified hub is coming within the next few months and sometimes it can make you look bad.
• Transition Windows Update to Update Channels via MDM Profiles to modernize your software update strategy. Reach out if you need help setting those up!
• Remember that now using Dell OEM Profiles will also push the DCU App.

In Closing

Don’t be afraid of being dynamic and moving toward a Unified Endpoint Management strategy. Remember, we miss 100% of the shots we don’t take. Many companies are littered with people that are conservative and not willing to take risks to take yourself to the next level. You can do some really great things if you are willing to go outside of your comfort zone and modernize your IT strategy.

If you need help, just ask because we’re here for each other. Companies develop new technology and innovate as our companies modernize. We can be a truly united front and motivate tech companies like VMWare or Microsoft to keep up with our pace of innovation.