rterakedis's Posts

maziboss​ - that is a good way to do it.   Also, i did just become aware of a bug in UEM 2004 that may cause this behavior also (specific to the hub automatically not deploying).   You are correct - Internal Apps and Products require the Intelligent hub in order for the installation to happen.

VinceHWebb​ -- Glad to hear you found the resources useful!  I'm definitely happy to add anything you'd like to send me.  We're also happy to accept pull requests to the repo if you'd like to add anything from your own GitHub profile (you'll need to agree to the DCO the first time you send a pull request).   As you can see (looking at the guidance for Adobe), i'm happy to give attribution, so let me know how you'd like me to attribute you in the author page (github handle, twitter handle, etc). Rob

chengtmskcc​ -- With regards to Jamf Setup, we've had similar functionality with our concept of "Staging" (multi-user or single user).   Basically you can use the Hub to provide a login screen where a successful login assigns the device to a specific user and then they get specific home screen layout, show/hide apps, etc.   Honestly, when we release our support for Shared iPad for Apple Business Manager, I almost don't see a need for the Jamf Setup app and/or our staging functionality. We're exploring the need for this type of an app.   If you have specific use cases that it would address, please submit feedback here:   https://wsone-uem.ideas.aha.io/ideas​  We've specifically addressed this use case in the Healthcare environment via our integration with Epic ( Enabling Patient Device Wipe with Epic & Workspace ONE UEM Integration | VMware  ), which actually doesn't require any interaction on the device as the wipe gets triggered when the patient is discharged.

maziboss​ -- We generally recommend that you do not deploy BOTH a bootstrap package and the automatic Hub install at enrollment.   If you enable both, Workspace ONE sends two InstallEnterpriseApplication commands during enrollment.   Theoretically, this shouldn't be a problem.  However, in real life it seems that depending on the version of macOS installed, macOS may fail to act on the 2nd command.   We've brought this to Apple's attention multiple times, and it seems to go through this regular process where it's fixed in one version of the OS and then a few months go by and a minor upgrade breaks it again.   If you're sure that the Bootstrap Package is assigned correctly and the Automatic Hub Install is enabled correctly (at Settings > Devices & Users > Apple > MacOS > Intelligent Hub Settings, I would suggest opening a Support Ticket with both Apple Support and VMware Support -- they can coordinate troubleshooting together.    Step 1 is to make sure both commands are getting there, Step 2 look at unified logging to see if macOS is generating an error message.

VinceHWebb​ JoeBeaty -- Some examples are here:   https://github.com/vmware-samples/euc-samples/blob/master/macOS-Samples/Privacy%20Preferences%20Policy%20Control/README.md. (be sure to scroll the table left and right).   For anyone else newly joining, Fusion was specifically covered here: Privacy Preference profile example for VMware Fusion

TommyThomassen​ -- I think part of the problem you're running into is that the GlobalProtect app has a funky build version in the Info.plist (such as 5.0.2-13).    Hub (using internal apps) uses 3 main methods to determine if an app needs to be installed:   install check script (in the UI), the Installs Array (in the plist), or the receipts array (in the plist). Since the Workspace ONE Admin Assistant can't pull out the version number (and the receipts left by the installer process always show a version of "0", you'll need to make some modifications to make this work. 1).  Rename the plist/pkg files before you upload them: GlobalProtect-5.0.2.13.pkg GlobalProtect-5.0.2.13.plist 2).  Change the plist file as such: Modify the value for the "name" key to something your users will recognize. Modify the "installer_item_location" to match the name of the file:   GlobalProtect-5.0.2.13.pkg change the "version" to 5.0.2.13 (or whatever version) as this is what will be reflected in the console. 3).  When creating the app assignment in the Workspace ONE console, use an install check script (this is basic, but you get the point): #!/bin/zsh if [ -f /Applications/GlobalProtect.app/Contents/Info.plist ]   then VERSION=$(/usr/bin/defaults read /Applications/GlobalProtect.app/Contents/Info.plist CFBundleShortVersionString) ;     if [ $VERSION = "5.0.2-13" ]       then     echo $VERSION     echo "Correct Version Installed - No Install Needed"     exit 1 ;     else     echo $VERSION     echo "Wrong Version - ReInstall"     exit 0 ;     fi   else     echo "Install Required"     echo "Info.plist Not Found"     exit 0 ; fi With the script written this way, you can run tail -F -n 60 /Library/Application\ Support/AirWatch/Data/Munki/Managed\ Installs/Logs/ManagedSoftwareUpdate.log and see the output of the script on your test machine so you can see how the installcheck script logic is working.   Again, this is a very basic Install Check script, so you may want to explore something more robust and/or set it up to not downgrade the client if it automatically updates? With regards to your second scenario, one option is you could use the post-install script to echo the entire contents of the XML to a file in the correct place.  This basically embeds the XML into the catalog entry for that app install and can lay it down when the install runs.   Short of that, you have 2 options: Repackage the installer to also embed the XML and lay it down where it needs to go. Package the pkg installer and XML into a DMG file, and then use a process similar to this:    euc-samples/macOS-Samples/3rd-Party_Software_Guidance/Carbon-Black-Defense at master · vmware-samples/euc-samples · GitH…

lawrencechow​ -- Happy to help! With regards to the deployment being queued, there could be a couple of things at play: Internal App deployment on macOS requires the Workspace ONE intelligent hub. Immediate deployment requires connectivity between the Intelligent Hub and AWCM.   Since the Hub is not an App Store app, we leverage AWCM to do notifications directly to the hub (similar to how APNS notifies the mdmclient process in macOS).   Basically, with AWCM we can tell the hub to check-in and get application installs immediately, otherwise you'll default to the "fallback" interval where the hub checks in (8 hours by default I believe). Hope that helps! Rob

lawrencechow​ - You're on the right path to deploying apps for macOS!  You're probably running into some unexpected behavior with the way the Pkginfo Plist (the *.plist) file is created after parsing the Google Chrome installer package.   A few thoughts (for anyone new to the conversation):  There's a walkthough I created a while back that talks about deploying software:   Deploying a Third-Party macOS App: VMware Workspace ONE Operational Tutorial | VMware With regards to Internal Apps, you do not need to populate the scripts tab in order for an install to run -- these are all optional but not required. The way an app installs closely mirrors the munki documentation:   How Munki Decides What Needs To Be Installed · munki/munki Wiki · GitHub Can you share the content of the plist you uploaded to Workspace ONE (as it was generated by the Workspace ONE Admin Assistant App)?   If it's looking for receipts, you may need to change the "Receipts" array to an "Installs" array such as this (replacing versions with the appropriate details): <key>installs</key>   <array>        <dict>             <key>CFBundleIdentifier</key>             <string>com.google.Chrome</string>             <key>CFBundleName</key>             <string>Chrome</string>             <key>CFBundleShortVersionString</key>             <string>71.0.3578.98</string>             <key>CFBundleVersion</key>             <string>3578.98</string>             <key>minosversion</key>             <string>10.10.0</string>             <key>path</key>             <string>/Applications/Google Chrome.app</string>             <key>type</key>             <string>application</string>             <key>version_comparison_key</key>             <string>CFBundleShortVersionString</string>        </dict>   </array>

Are the licenses specifically assigned to the Location Token in Apple Business Manager that you've got uploaded into Workspace ONE UEM?   It is possible to have licenses for an app purchased in ABM but assigned to no token (or a different token).

Be on the Lookout for an Operational Tutorial specific to deploying Tunnel for all platforms (Android, iOS, macOS, Windows 10) on https://techzone.vmware.com. The content is complete and is simply making its way through our review process.

khnaveed​ - There's a few options here: By default, iOS supports a number of restrictions (iOS and iPadOS restrictions - Apple Support ). Two specific restrictions control how apps interact with each other:  Documents from managed sources appear in unmanaged destinations Documents from unmanaged sources appear in managed destinations Note - there's also restrictions that mirror this behavior specifically for Contacts. App developers can also further constrain the capabilities of an app by implementing controls at an application level which can be controlled by MDM: App developers can integrate the Workspace ONE SDK which allows setting a PIN for the app, copy/paste controls, etc.   App developers can create their own internal set of app-level policies and allow control of those app policies via App Config policies.  As you can see, for the most part the app-level policies are defined by the app developer.  Additionally, the app developer must expose control of those policies to MDM. Hopefully that helps. Rob

robsanlop​, hopefully this can shed some light.   There are a few places you can look: Workspace ONE UEM Console Release and End of General Support Matrix​ VMware Workspace ONE UEM Release Notes You can then also plan those upgrades using the VMware Product Interoperability Matrices.   There, you can find the Workspace ONE UEM Console Matrix. As mentioned above, 1909 is the current latest on-prem offering, although 2001 is due to release relatively soon.   In general, if a release is tagged for on-prem release, the actual on-prem install bits seem to be released approximately 30 days after we release to SaaS.   I haven't seen that actually documented anywhere, so it's mostly just a rough guess. Hope that helps!

jahuu​, You should be able to set device traffic rules (under Groups & Settings > Configurations > Tunnel) where you can specify the macOS Application, Action and Destination.  In your use-case, you should be able to set 2 separate rules: Mailclient —> Tunnel —> corp.email.com Mailclient —> Bypass —> personal.email.com You can also leverage the default rule and simply set it to Bypass in order to force everything that isn’t specifically tunneled to bypass the Tunnel and go straight to the Internet.