TimHardy's Posts

I'm guessing you will have resolved this by now, however just incase you haven't. if I had this issue I would first attempt to load console via Localhost directly on the box. If the console loads on localhost then I would start looking at DNS, if Console is not working on localhost then would check the Console and IIS Logs

Checked on two different environments and both have the same issue you describe, Registration date returned via the enrolleddevicces call is 0001/01/01 for all records. I know this doesn't really help you but at least you know its a general issue and not specific to your environment. 

Hi, i can confirm Multiple Active Active AWCMs behind a LB should work, we hosted and managed an on prem deployment with this configuration for a number of years. The only difference in our setup was the AWCM's and DS's were not hosted on the same instance. Our setup was 2 X console  2 x AWCM 5 x DS This is the KB we used for the persistence rules for AWCM specifically https://kb.vmware.com/s/article/2960904?lang=en_US Hopefully this helps

For Chrome App config format is as follows Managed Bookmarks [{"toplevel_name": "managed bookmarks folder" }, {"url": "https://example1.bookmark.com", "name": "Example2Bookmark"}, {"url": "https://Example3.com", "name": "Example3bookmark"}] Deny List [*] Allow List ["Demo.com", "example.com", "example2.com"]

It sounds like launcher is blocking a system app from running, To check this Replicate the fault, then click the drop down arrow (top right of launcher) > Select settings > select “Denylisted apps”. Within this menu it will display all the app IDs that launcher has blocked from running. hopefully you will see something in this menu, take that app ID and add it as a miscellaneous app to the launchers hidden apps section. Once complete try your NFC tags again.

After recreating the issue, open the launcher settings and go to blocked applications. Check what app ID launcher is blocking. Add that app ID to the hidden apps list in Launcher and it should resolve your issue.    

You don't need an existing DS config export to add an additional DS, it just saves you having to manually enter all the details and select the same components in the dropdown during the installer that's all. We added multiple DS servers a few years after the initial deployment without any issue 

Hi, I have had this issue with a few environments and it was due to Safetynet giving a false compromised. To identify and address this we took two actions  1, we temporarily disabled compromised Protection which stops devices getting auto wiped when marked as compromised, we then setup a compliance rule to highlight the compromised devices. This stopped devices being wiped and allowed us to identify the compromised devices to capture logs from and then worked with VMware to prove it was safteynet marking the device as compromised To do this Disabled Compromised Protection Settings > Apps > Settings and Policies > Compromised Protection > change to disabled save   Create compliance policy Devices > Compliance Policy > List view > Add Rules > Compromised status = Is compromised Action > Send email to Admin Assignment > Top OG Save   2, After collecting logs we identified that although we had disabled Safteynet in the System settings all existing devices still had Safetynet enabled on the device side (NOTE new enrolments were fine SafetyNet was disabled as per the system setting was only existing device that did not take the settings). We investigated this with VMware for some time and ended up having to deploy the following custom XML profile to the devices.   <characteristic type="CustomSettingsV2" uuid="e459fdf2-22dd-4b5b-8502-0aafe72167ec"> <parm name="packageid" value="com.airwatch.androidagent" /> <parm name="CustomSettings" value="{&#xD;&#xA;    &quot;CustomSettings&quot;: &quot;{\&quot;SafetyNetEnabled\&quot;: false}&quot;&#xD;&#xA;}" /> </characteristic>   Once deployed we confirmed from the device logs that all existing devices had correctly disabled SafetyNet and the issue was resolved   Hope this helps

You need to setup the time Schedule First, once setup you will then be able to select the schedule when you set the toggle in the profile To create the  Schedule its in Devices > Profiles > Profile Settings > TimeSchedule > Add Schedule Hope this helps  

For a device to load in to hub following a Factory reset it must be registered with either an Android Zero touch portal or a Samsung KME portal. The only way to remove this is to find the company that this device belongs to and request that they remove the IEMI from their AZT or KME portal.