Notes from the field: The one that Android said no more local

On one of my projects, we’ve encountered a strange issue regarding domain name resolving.

A little background on the canvas painted it’s about a VMware Workspace ONE setup with working web URL’s and UEM enrollments, you name it. We have a nice setup regarding managed devices and these use a per-app VMware tunnel connection to achieve secure application access. All working dandy fine. The devices are based on a Ascom Myco 3 setup with Android 10 and are dedicated used for specific applications.

Then we moved on to the managed devices in a COPE / Work managed format for the normal usage of applications work and personal usage. We also implemented VMware tunnel in a per-app situation and we got some mixed scenario’s as in working, not working or not resolving at all the URL’s with a .local suffix (I know what you are thinking .local isn’t best practice to use etc. etc. well we don’t live in a perfect world and there are a LOT of companies with .local suffixes over here) on Android 11/12, it more of less pointed to Android 12 that changed DNS resolving with mDNS support as in the way how it always should have been, see Android adds mDNS support so .local hostnames finally work ( for the details.

We had some interaction with VMware support as we first thought that it would be a combination issue with VMware Tunnel because the behavior in a Workspace ONE Web with the built-in tunnel SDK would work just fine. But as soon as we changed the URL’s to a not .local suffix but .net or something else it would instantly work.

On a closing note, I think more and more customers will see this change now that Android 13 is on its way. It’s good to prepare in advance.

Special thanks to my partner in crime on this case, Sidney Laan.

See the following reference articles and blogs for some fun reading and a hint to a new DNS setup:

Local DNS resolution suddenly stopped working… – Google Pixel Community

Why do Android 12, 12L, 13 Preview devices don’t resolve local DNS anymore? – Stack Overflow

Active Directory: Best Practices for Internal Domain and Network Names – TechNet Articles – United States (English) – TechNet Wiki (

Hope it helps!

Notes from the lab: VMware UAG content gateway and an A+ rating

In addition to Jesper Alberts his blog a follow up with another custom UAG edge service which has it quirks called the content gateway. For the SEG article see – Secure Email Gateway

Now diving in, when you configure the edge service you have the following options to configure Custom Values for Content Gateway and bare in mind that you’ll find this article after your first check on SSL Labs because an disappointing rating is what you get out of the box. See below screenshots for an A+ rating on SSL Labs:

After configuring these options you need to re-save/update the configuration in the UAG as well otherwise the service will not get these changes. And voila an A+

Hope it helps!

Notes from the field: VMware Workspace ONE UEM and Android Zero Touch

On a recent project we were implementing Android Zero Touch for out of the box enrollment through WS1 UEM. For a detailed explanation what Android Zero Touch is take a look at the following URL: Zero-touch enrollment for IT admins – Android Enterprise Help

When the Zero Touch Portal is enabled through the reseller and you have your access the DPC part of UEM or any other supported EMM vendor can be added and assigned. For WS1 UEM we have the following options for configuration: Enroll Android Device Using Zero Touch Portal

Now comes the part that was the “issue” or better said somewhat misinterpreted throughout the documentation. When you configured the setup through above steps you will always get a prompt after the DPC part through VMware Access that you need to login, but the whole purpose is that there is an auto-enrollment throughout Android Zero Touch and it’s DPC values through WS1 UEM and Access. Well the latter is the blocking part.

If the authentication of WS1 UEM / WS1 Access is configured to use the source of authentication from HUB services as WS1 Access you will break the staging user part from Androids perspective. Apple for example does not have this issue when using DEP/VPP because the staging works different through that program integration with WS1 UEM.

Flipping the authentication over to UEM as primarily source and everything is working nicely. But we don’t want this because Access should be the source of authentication regarding every nicely integration for web applications throughout SAML, other IDP providers etc. etc.

Logged a support case for this but didn’t get any satisfying results regarding the enrollment process. I’ll get back to this because support did help me after we got that one fixed with something else.

Just by luck an internal colleague has a nifty RSS feed active for useful blogs and this one popped up and immediate had my interest: Automated no credential enrollment when using Workspace ONE Access for source of Authentication

OK! That explains a lot after reading and there is another VMware URL regarding extra DPC values for UEM specific items: Additional Supported Enrollment Flags for Android Enrollment and the simple addition of “useUEMAuthentication” did the trick. This effectively disables Access for the enrollment part and allows the use of a staging user again.

Well staging works and… bummer the HUB screen keeps refreshing and we can’t sign in as the owner of the device. And here we come back to VMware support, after some testing I flipped over the staging user account in UEM from “Standard – Users are asked to log in after staging” to “Advanced – Enroll on behalf of another user” and the latter gives the experience that you assign the user after staging and then login and presto no more spinning HUB screen and it works.

After discussing this with support it’s the way that how Zero Touch enrollment works the staging user account needs to be set to advanced, the standard mode isn’t supported in this way of enrolling. And after that case closed!

Hope it helps!