Workspace ONE and Win10 App deployment custom success criteria

For the most part on this blog I’ve avoided stuff that I think is basic, since there are many good blogs out there that take the time to explain these things. But one of the things you learn in life is something you think is easy/basic is something someone else may struggle with. Everyone struggles with something that someone else finds easy.

And while conceptually how Win10 app deployments works is “easy” applying it to custom stuff can be an exercise in thought.

So one ghetto flowchart for the visuals:

This is very much a cut down version of all the things that happen but its all we care about in this case.

So to simplify things a little, and hopefully not make a complete meal of the explanation…. Lets say our success criteria is ” Hi Bob” (Yes I’ve watched for All Mankind, no its not the “best scifi” of 2023… its a drama with some space more than scifi.. anywhoo I digress). So Workspace ONE sends it criteria, so “Hi BOB” and for the criteria to be successful, the response it should get is “Hi Bob”… I know, I know… But I’ve been using Bob as an example from before the stupid show came out, and If I don’t reference the tv show then people will comment 😛

When our app lands on our device:

1. Workspace ONE asks “HI BOB!”.
2. If it gets a “Hi Bob!” response back, so the criteria is successful, then it stops the install process as it assumes that the app is there, since the criteria is true.
3. If the criteria fails, then it moves on to the installation
4. It then “HI BOB” again, This time the expectation is it gets a response.
5. If it gets a response, then it reports success and everything is happy.
6. If it gets no response this time, then the assumption is the app install has failed, it will run the uninstall configured in the app config and exit with a fail.

So how do we use this?

Depends. This is where things get tricky.

Success criteria is literally telling Workspace ONE how to determine things worked, when adding a fresh app its often as easy as just pointing it to a filepath saying My.EXE exists.

But the thing to remember: THE SUCCESS CRITERIA NEEDS TO BE UNIQUELY IDENTIFIABLE FOR THE APPLICATION VERSION YOU ARE INSTALLING.

Yup it gets bolded and shouted….

In the My.EXE example, this works fine for V1.00, but what happens when we use the same criteria for V2?

If we have the exact same success criteria the flow becomes:

1. Start deployment
2. Run success Criteria of “Does My.exe” exist?
3. Success Criteria passes! So our app is already installed.

But why? Because V1.00 installed it. Your V2 criteria IS NOT UNIQUE

So what is the solution?

Again this depends.

You need to find a unique attribute that either falls under the standard Workspace ONE success criteria that works for you, or create a custom script

So in the case of My.EXE, good chance the internal version was also updated, so we could use something like:

But what if we are deploying a PowerShell script?

Again it depends. You want to try and make your life as simple as possible, can you use one of the built in criteria?

Your install script could create a flag file that is unique, a reg key that is unique per version and then you can use an existing built in criteria. You can also write a custom script.

There is no wrong answer on how you do this. As long as your new version success criteria is different from the previous version(s) so Workspace ONE can work through the flow to a successful install.

Just remember when writing a custom success criteria script that it MUST be able to fail as well as succeed, here is an example of one I use:

param
    (
    $TaskName
    )
Try
    {
    $proc=Get-ScheduledTask -TaskName $TaskName -ErrorAction stop
    }
catch
    {
    exit 1
    }

I have a few scheduled tasks, hence I reuse the script by feeding it the TaskName

So when we feed it the Taskname “Hi Bob v1”, and again referencing our flowchart above:

Workspace ONE will execute the script expecting it to fail, so it knows to install. In the case of my script example above, the Scheduled Task wont exist, so Get-ScheduledTask will throw a terminating error, which is caught by the catch, and exits with a exit code of 1, my app is set to 0 for success.

Workspace ONE will run the install

Workspace ONE will run my script again, this time when Get-ScheduledTask runs, it should find “Hi Bob v1” and powershell will exist gracefully with a 0 error code, which just happens to be what we configured in UEM

What about apps that update automagically?

So most modern browsers are a good example of this. If you allow auto updates then the browser on your clients will update more often then you will update Workspace ONE.

So you start of installing version 1.00, every 3 months you update the console, so by then its version 40.1.2.3.

How do we handle this, if another patch comes out, which lets face it with browsers is likely, before you get to rolling out 40.1.2.3 to all your clients, you might run in to problems if its not handled properly.

Is one way to look at it.

40.1.2.3 is the expected version we are pushing, if they are on anything LESS then install. If its anything newer, pass it as successful.

Finally

So the intent of this article was to hopefully shed some light on success criteria. Normally I don’t ask for comments, but if you are still unclear on this then please leave a comment and I’ll change things up in the article to try and make things more clear, everyone learns different and we as admins have enough headaches without a stupid app that should work not installing driving us even more insane.

This article may help with apps you want to be able to reinstall at will:

Working around Workspace ONE’s inability to reinstall an application.