The Community

Stay up to date…

VMware End-User Computing Blog Bringing you the latest VMware EUC news, trends and product innovations.

    Feed has no items.

Arsen Bandurian: Technical Blog Digital Workspace, End User Computing, Enterprise Mobility, AutoID, WLANs, OSes and other technical stuff I happen to work with

  • Quickly validate and enable manual application uninstall via Intune Company Portal using Graph API
    by apcsb on August 3, 2023 at 7:04 am

    I am back and the titles are getting longer! If you are an Intune admin, you will probably be happy to know that one of the most required features has landed: Uninstall Win32 and Microsoft store apps using the Windows Company Portal. One thing you need to be aware of, is that this feature is... Continue Reading →

  • Building a custom Windows Update Report p1: Parsing HTML via PowerShell on modern systems (no IE)
    by apcsb on July 28, 2022 at 7:30 am

    Wow, it’s been a while! A customer of mine recently wanted a detailed report that should include info such as how many weeks is the Windows on the machine behind the latest available Security Update. We’ve found to a way to combine Intune Data Warehouse and PowerBI to pull data that allows to identify the... Continue Reading →

  • A case of OneDrive Personal Vault not coming up (0x8031000a, MDM, GPO and BitLocker)
    by apcsb on March 18, 2022 at 6:23 pm

    Today I wanted to enable the Personal Vault feature on my Home PC. While following the wizard I got an error 0x8031000a “Your organization requires your device to join the domain before you can use the Personal Vault”. What does this have to do with MDM. GPO and BitLocker troubleshooting? Here’s some quick Friday entertainment!... Continue Reading →

  • Clean up references to your custom domain name from an Azure AD test tenant
    by apcsb on October 5, 2021 at 11:50 am

    Today I needed to move my custom domain name from an old (and messy) AAD test tenant to a (sparkling) new one. Problem is, you can’t simply delete the old custom name, since your user’s UPNs and Email addresses are using it (AAD actually presents a nice screen, showing all the dependencies, but I am... Continue Reading →

  • Viewing the encrypted Apple profiles in Workspace ONE UEM console
    by apcsb on May 18, 2021 at 7:30 am

    Apple has an option to encrypt the MDM profile payloads (both iOS and macOS). But then when you try to view the profile XML in the console (ex. migrating payloads between UAT and Production environments, working with custom profiles) – they are encrypted! Turns out, there is a way to view the XML w/o having... Continue Reading →

  • Product files: The DoorDash T8
    by Jason Bayton on August 14, 2023 at 12:00 am

    Welcome to Product Files, a series of articles that touch on some of the more interesting aspects of running a product organisation for the last several years. As this series grows, additional links will show up here: Building Android devices Alternative form factors and power solutions The DoorDash T8 Google recently published a blog post by the DoorDash team that covered how the T8, supported by Android Enterprise's suite of management solutions, provided some pretty respectable achievements for them: As the T8 slowly edges towards the end of its anticipated extended lifecycle and customers begin moving to newer options, I thought I'd take some time in this article to dive a little deeper into the product development of the RHINO T8 and some of the product decisions I made during the development of the tablet that ultimately made it attractive to DoorDash, becoming one of their most-deployed units today. As I delve into some finer details of T8 development, I'd like to point out this is a device that began its lifecycle in 2019. Some of the features that made it notable at the time are simply par for the course in 2023. That said, I'm still very happy with many of the decisions made that contributed to the device it become. What is the RHINO T8? # I touched on the T8 back in 2020 with my Building Android devices article. I'd recommend you take a gander at that if you haven't yet as I provided a good deal of relevant information as to where RHINO came from and the longer-term plans for the brand and ecosystem. The T8 was part of the first generation of RHINO devices we built from the ground up, something that would not happen again with the recent gen 2 devices as the company opted instead to re-tool products already available in the market through ODM partners. That said, here it is: It looks, behaves, and mounts like a standard 8" tablet available from many OEMs in the market today, and especially today in fact, as the ecosystem has filled to the brim with tablets in the last couple of years; far more so than in 2019 when the T8 project kicked off. But that was the intention. Developing the product # In strategising what RHINO should be, it was ultimately decided the RHINO brand would be used as a readily-available, widely-applicable showcase of what the company could produce; to act as a springboard into more complex and bespoke projects that could (or not, if bespoke was preferred) leverage these devices as their base. This achieved two objectives: Customers could see and feel the build quality of a device in their hands rather than relying on the word of a sales rep. It cannot be understated the difference this has when asking a customer to commit hundreds of thousands of pounds for a product they won't see for 6-9 months. For smaller projects the existing tooling and internal designs could be mostly or entirely reused, significantly reducing time to market One additional benefit for the company was having own-brand stock available for customers simply wanting to buy a device, and as a value-add we were able to pop the company logo of any customer on the tablets for larger orders, giving a bit of organisational customisation most mainstream OEMs don't offer. The T8 and it's larger sibling, the C10, were the first tablets I launched under the RHINO brand. Going in to product development for these tablets, the key focus was to develop devices suited to enterprise; this meant considering aspects of use they wouldn't be subject to if consumer owned (and respected), even if MSRP wouldn't eventually be as competitive as an equivalent competing product in the consumer space (think Lenovo, cheaper Samsung tablets, etc). This mindset drove some key requirements for the device: Ease of repair Tough and resistant to unfriendly usage Repellent to moist &/ corrosive environments Long term component support Resistant to battery ageing Again, there's nothing groundbreaking here, and OEMs at the time were well-versed in similar requirements for their own offerings (H/T Zebra, Honeywell, Panasonic, etc), but almost across the board they were rugged devices and didn't aim to target the pro-sumer hybrid of consumer device with enterprise features. But what does this mean in terms of product decisions? Ease of repair # Some of the earliest samples and reference products that came from our manufacturing partner during initial stages of development painted a stark picture of what cheap hardware looked like when the only goal is maximising profit: Glue blobs galore Soldered components Single-use clasps and anchors in the housing that would wear out after one to two disassembles of the unit, which was very easy to pull apart Loose wiring Cheap CMF (colour, materials, finish) Zero modularity .. and so on I've pulled apart Android devices (amongst others) aplenty over the years and have seen all of these in use in excess. These devices develop faults and unless you're willing to pull out a soldering iron they become paperweights. By comparison, the exposure I've had to what flagship OEMs have done for internal design - especially thanks to channels like JerryRigEverything and his passion for tearing devices apart so the rest of us don't have to - gave me more than enough inspiration to find a good balance between ease of access, modularisation, and appropriate, re-applicable adhesives. When it came to starting hardware development for the T8, the first few rounds of E/DVT (Engineering/Design Validation Testing) saw: Soldering components swapped for push-fit or lego-style-connectors High-wear items like the USB-C port and buttons either reinforced or modularised to their own sub-PCBA for ease of replacement Loose wiring replaced by ribbon cabling Mild adhesives used for holding the battery in place (with pull tabs) and display to the housing During this process, I went through more than 10 iterations improving the rigidity of the unit from the first EVT, and ensuring the back wouldn't pop off too easily since it wasn't glued on. Budgetary and time limitations prevented more development in this area; but if I was doing it again today I'd have aimed to make the back cover predominantly secured by screws rather than of clips/clasps, since the latter naturally wears out over time and particularly for customised orders, new printed back panels would have to be made to order when they did wear out, which is a 30-90 day wait. One final choice was opting not to bond the digitiser and LCD to one another; many OEMs do this with most devices today, which is in effect gluing the touch panel and the display underneath it together to make one item, the display assembly. There are arguments for doing this and it's generally a good thing, not least because the resulting picture can look much better without an air-gap within the assembly, and it also prevents dust and dirt from getting in there. That said, it also increases the cost both in terms of manufacturing cost to pay a factory to do this, but also when it comes time to repair a broken assembly; you're forced to replace the entire thing, or at least purchase the whole assembly, as even if you were to spend the appropriate time with a heat gun to try to separate them, the manufacturer will supply a bonded replacement. With all changes in place, repairing a T8 became very quick & straightforward to do. Exactly the words repair centres and in-house maintenance teams like to hear when units come in with something broken. Tough & resistant to unfriendly usage # In the process of improving repairability, the whole unit benefitted from greater protection from unfriendly usage by, for example, ensuring flex was minimised if the unit was crushed, twisted, or bent. Flex can be a major concern for a screen, since glass doesn't take to it near as well as other materials. In addition to this I spent several weeks with my team reviewing options for the outer finish of the unit, aiming to find a balance between something that looked decent, but also held up against knocks, scrapes, drops, and so on. On the first few batches of the T8 this was a rubberised finish on the housing, and it held up quite well in the target environments as it: Didn't really show marks Could be wiped off easily Offered better grip when holding it directly In later production runs with a new manufacturing partner we opted to switch to a textured paint coating instead, offering most of the same benefits but more likely to hold up against harsher cleaning agents and such, as considerable use could see the rubber eventually wear away. Then there were other design considerations, like the slightly-raised border that surrounds the screen. This is dual-purpose both to absorb shock from drops (along with the rest of the mostly-plastic frame) and keeps the screen ever-so-slightly further from an object that might otherwise impact it. Repellent to moist &/ corrosive environments # Knowing the tablet was destined - even during the product development phase with interested customers that predate DoorDash - to land in kitchen and high-humidity environments, but not wanting to fully seal the device for an IP rating (a trade-off for repairability), we dipped the internal components in a moisture-resistant coating. The tablet doesn't become impervious to moisture with this approach, as dropping it into water or using it during a heavy downpour may allow water to sit within the device and eventually cause a failure, but for humidity, and similar moisture devices may have to deal with, this worked. Corrosive, in this context, is what is corrosive to a PCBA - impurities, salts, the like. I couldn't save the unit from an acid dip and keep it within a budget! Long term component support # Early on in the company's history a partnership was formed with MediaTek, as we pivoted to enterprise MTK's AIoT division became our go-to for chipset selection that guaranteed long-term support & availability. The MT8765 in the T8 is by no means a powerhouse, in fact I think it's fair to say it wasn't the best choice of chipset in retrospect due to the performance issues I've seen over the years with it. For Android Go it would have been absolutely fine, and in truth the T8 would have made for a great Go device given the predominant use-cases for it, but we certified it for full-fat Android in the beginning and stuck it out. That said, it's taken us from 9.0 to 12, with potentially longer support possible if desired. Since The T8 is coming up on 5 years in-market, that need is simply not there. Outside the chipset all the standard multi-source component procurement was done by the team accordingly, so we rarely suffered component shortages even during some particularly tumultuous times for the global supply chain in the last few years; even now 4 years later and running another batch of 10s of thousands of units through production component supply has been pretty reliable. Resistant to battery ageing # One of the more active requirements, especially from customers coming from consumer tablets they'd had docked to a power supply for 6+months and suffered battery ballooning, was to handle power management intelligently. What I wanted to be able to facilitate from the get-go was a complete power management solution that allowed customers to: Boot & run without a battery connected (when connected to a power cable) Bypass the battery and run directly from power cable with the battery installed Configure OEMConfig APIs to control this via software, if it wasn't feasible to interface the hardware Unfortunately this quickly overshot time & budget requirements (but I did take some of this over to the M10p!), so I had to settle for a fully-software smart monitoring solution that would detect for how long the T8 had been plugged in, the voltages and cycles of the battery, and alter the charging profile accordingly. This required engineering coordination between the Android framework folks, kernel folks, and the engineers responsible for the PMIC design. From a UX perspective, it also introduced some scenarios that customers (or rather, their users who didn't read manuals) raised concerns about. When the tablet had been on charge for more than 24 hours straight for example, we allowed the battery to discharge intentionally to align with the new power profile. Unsurprisingly support tickets did get raised about devices not charging. There were also tickets raised about this solution not kicking in where customers would turn the power off to the tablet when their stores/offices/spaces closed, and back on in the morning; the solution simply wouldn't ever kick in because it wasn't permanently (or >24h) on charge. So it wasn't infallible, and accordingly we did see some genuine battery failures in the wild, but overall it's been a reasonably insignificant number compared to the number of devices shipped overall. The Android journey # This is not so related to DoorDash choosing the T8, but I think it's interesting to cover since it's relevant to the article. The RHINO promise has been bloat-free, vanilla Android since inception. Beyond Google apps and a couple of OEM-specific services (activation server, OEMConfig, chipset support), and some OEMConfig APIs, my flavour of Android is as light and clean as it comes. To achieve this was no insignificant undertaking as working with external engineering houses well-versed in the MediaTek turnkey builds (these are builds of Android the chipset makers offer with integrated support for the chosen chipset. Qualcomm, Rockchip, and others offer the same, often referred to as BSPs.) meant the only option for building Android I could get was to lean on these pre-made builds rather than building from AOSP. Again as with many things in product development there are pros and cons. The pros for a turnkey/BSP build are normally time to market and little need for configuration. The cons come in the amount of time you choose to dedicate to removing bloat the chipset vendor includes. Engineering apps, battery optimisers, sound enhancers, carrier optimisation apps.. you name it, the vendor has an app for it, and it's likely included. Then come the tweaks to UI and defaults set - Icon shapes, default radio behaviour, navigation setup, and so on. From the very beginning I built out a version-based requirements doc that combined a mixture of both best practice security and enterprise-friendly defaults, laced with some personal opinions on how Android should look, feel, and behave in line with examples set by Google and other OEMs offering vanilla builds. The turnkey builds were a fair departure from what I'd consider RHINO ready and so there was always a fair amount of work to do, even without custom development of OEMConfig and other bespoke functionalities. Still with all the reconfiguration required it remained faster than building AOSP from scratch, though given the choice I'd prefer building from AOSP. Swings and roundabouts. For the T8 we went through this process three times, the latest earlier in 2023 with Android 12. Each major OS build requiring porting of the changes made to the version before it, or setting up again based on the requirements doc from scratch. Upgrading unfortunately isn't much easier than building a version from scratch in my experience, but this could be down to the engineering partners I had available; my experience is understandably limited, and I imagine there's a good amount of investment in build management and development in larger OEMs that would offer a world of difference. The T8 launched with Android 9.0. 10 was feasible already at the time, but it was considered too new for some more risk-averse in the company and the older, more stable version of Android was chosen for the first products in the RHINO brand. It's understandable in some theory, but on reflection it wasn't a great choice, and had implications throughout the product's lifecycle. 9.0 included a version of Treble that was definitely not close to final, a fixed (as in permanently-set) partition system, and some other less-than-forgiving attributes. It was 10 that introduced the concept of dynamic partitioning, and set the groundwork for substantially more flexibility in how OEMs work with the on-device storage for resizing and repurposing disk partitioning on-the-go in later Android versions. This has been realised in the release of 12 this year for the T8, but given the device isn't planned to see 13, both due to demand and MediaTek's apparent stance on chipset support, the benefit is no longer there. Because we launched on 9.0, the same partitioning had to be used in 10 to allow an OTA (Over The Air) upgrade. Partitions can always be rewritten with a manual flash of a device, but an OTA update cannot adjust physical partition sizes. If we were launching 10 with a new device (like the M10p) we could have implemented dynamic partitioning, but as we wanted to upgrade from a fixed partition system on an existing device, we had to retain that. The trouble with fixed partitioning is unless you configure partitions to accommodate larger on-disk sizes later - something you can't scientifically calculate given changes that impact system sizing can't be predicted for the next version of Android, never mind 2 or 3 later - you'll eventually run out of space and can no longer support the upgrade to a newer version without some significant hackery, if possible. This is effectively what happened with the T8, and why we went 9.0 > 10 via OTA, then 12 with a manual flash for existing units, or a preload from factory of 12 for units manufactured in 2023. The upgrade to 11 took the /system partition to a larger minimum size than we could accommodate on the 9.0-specced partition layout, and we deferred upgrading again until necessary. Another aspect of maintaining an Android product over multiple years is GMS approval. Google sets approval windows for every Android release that state the latest possible time permitted for approving a new release of Android both as a new product, but also as an existing product that's upgrading; the latter has a bit more time since it's already an in-market device that needs to be supported. There are also expiry dates that stipulate the date after which it is not permitted to manufacture new Android devices with an older version of Android, though existing manufactured devices in the field could continue getting updates. These dates also differ based on form factor, Android flavour, and GMS licence (ie. EDLA (enterprise dedicated) devices). It's a reasonably complex, though not necessarily complicated process. For Android 10, the expiry date for GMS approval as a tablet on the MADA licence was Dec 2022, that means devices manufactured from January had to preload a newer version of Android from the factory, so 11+. 11 however passed the last date for GMS approval as a LR (launch release, an upgrade) back around August 2022, which meant when DoorDash picked up the phone and requested a brand new, freshly manufactured batch of T8s in late 2022, Android 12 development had to also be undertaken in order to have an approved Android build to put on the tablets in the factory before shipping out. But what about security patches? # Security updates are comparatively much simpler to plan and manage than major version releases, on the whole. The T8 has received quarterly security patches since 2019, and will continue to do so into 2024 based on current plans. The only implication with security updates is when Google stop backporting them. Backporting, to address the assumed question, is where Google will take the patch of a security vulnerability in the current version branch of Android (say, 13 as of August 2023) and undertake the necessary engineering to be compatible with older versions, so 12, 11, 10, before committing it to those version branches respectively. OEM engineering resources then pick up the patches for the relevant version they're working with, along with patches from component suppliers, chipset vendors, and anyone else pertinent to a specific device, and roll it out into the device tree (source code for the device). Google will not backport forever, however. There is typically a limit of 3 years per OS version before they cease backporting and instead focus on newer versions of Android. As an OEM, you then have the choice of: Continuing to support an Android version by cherry-picking patches from a newer version of Android and doing the engineering internally to apply to your device Or upgrading to a newer version of Android Manual backporting, as it's referred when the OEM does it after Google stops, can be challenging, especially for smaller OEMs or their engineering parters. I've often struggled to lock in agreements with partner resources, who would almost unanimously rather undertake the task of rolling out a new version of Android than keep the older version secure once Google moves on (either route demanding a reasonable chunk of change to achieve). This is relevant because while the T8 has received security updates on time and religiously since launch with no action from customers required across 9.0 and 10, backporting for Android 10 officially ended in Feb 2023, and as such the last security update for that version went out to the customer base a couple of months ago. Customers who want to continue to receive security updates for another year will have to manually flash tablets to the latest version. So to reiterate, launching on 9.0 was not a great decision. Thankfully all projects after the T8/C10 adhered to my mandate for leaning towards the newer versions of Android available to avoid such frustrations re-occurring, and 4 years later newer projects are faring much better. Not all that bad # Though the T8's Android journey has been somewhat more challenging, this isn't reflected across all projects I've worked on and devices I've supported. I want to stress it's been mostly enjoyable to support the platform. I enjoy debugging (and squashing!) bugs, writing the release notes, scheduling the OTAs, planning feature drops, building out the OEMConfig (and other solutions) roadmap based on customer needs, and absolutely.. ..more than anything.. ..requesting bug reports from customers 38 times a day in response to one-sentence support tickets exclaiming something is broken. :). Wrapping up # I've covered off a fair bit of my experience bringing the T8 to market from a product development point of view. I naturally haven't touched on everything that went into launching the T8, nor some of the more bespoke requests from DoorDash on customisations they've received over the years to the model, including: Hardware revisions configured to local markets/geographies we didn't initially launch into Custom hardware configurations (NFC was removed from one revision for a particular use case) All of their custom branding and packaging Their custom-manufactured accessories (cases, etc) And many other value-adds that made the T8 the DoorDash T8. But ultimately a springboard from which to jump is what had them Dash through the Door (😁) in the first place, and I'm immeasurably proud of what I and my team achieved as the first major project of a new brand.

  • Product files: The DoorDash T8
    by Jason Bayton on August 14, 2023 at 12:00 am

    Welcome to Product Files, a series of articles that touch on some of the more interesting aspects of running a product organisation for the last several years. As this series grows, additional links will show up here: Building Android devices Alternative form factors and power solutions The DoorDash T8 Google recently published a blog post by the DoorDash team that covered how the T8, supported by Android Enterprise's suite of management solutions, provided some pretty respectable achievements for them: As the T8 slowly edges towards the end of its anticipated extended lifecycle and customers begin moving to newer options, I thought I'd take some time in this article to dive a little deeper into the product development of the RHINO T8 and some of the product decisions I made during the development of the tablet that ultimately made it attractive to DoorDash, becoming one of their most-deployed units today. As I delve into some finer details of T8 development, I'd like to point out this is a device that began its lifecycle in 2019. Some of the features that made it notable at the time are simply par for the course in 2023. That said, I'm still very happy with many of the decisions made that contributed to the device it become. What is the RHINO T8? # I touched on the T8 back in 2020 with my Building Android devices article. I'd recommend you take a gander at that if you haven't yet as I provided a good deal of relevant information as to where RHINO came from and the longer-term plans for the brand and ecosystem. The T8 was part of the first generation of RHINO devices we built from the ground up, something that would not happen again with the recent gen 2 devices as the company opted instead to re-tool products already available in the market through ODM partners. That said, here it is: It looks, behaves, and mounts like a standard 8" tablet available from many OEMs in the market today, and especially today in fact, as the ecosystem has filled to the brim with tablets in the last couple of years; far more so than in 2019 when the T8 project kicked off. But that was the intention. Developing the product # In strategising what RHINO should be, it was ultimately decided the RHINO brand would be used as a readily-available, widely-applicable showcase of what the company could produce; to act as a springboard into more complex and bespoke projects that could (or not, if bespoke was preferred) leverage these devices as their base. This achieved two objectives: Customers could see and feel the build quality of a device in their hands rather than relying on the word of a sales rep. It cannot be understated the difference this has when asking a customer to commit hundreds of thousands of pounds for a product they won't see for 6-9 months. For smaller projects the existing tooling and internal designs could be mostly or entirely reused, significantly reducing time to market One additional benefit for the company was having own-brand stock available for customers simply wanting to buy a device, and as a value-add we were able to pop the company logo of any customer on the tablets for larger orders, giving a bit of organisational customisation most mainstream OEMs don't offer. The T8 and it's larger sibling, the C10, were the first tablets I launched under the RHINO brand. Going in to product development for these tablets, the key focus was to develop devices suited to enterprise; this meant considering aspects of use they wouldn't be subject to if consumer owned (and respected), even if MSRP wouldn't eventually be as competitive as an equivalent competing product in the consumer space (think Lenovo, cheaper Samsung tablets, etc). This mindset drove some key requirements for the device: Ease of repair Tough and resistant to unfriendly usage Repellent to moist &/ corrosive environments Long term component support Resistant to battery ageing Again, there's nothing groundbreaking here, and OEMs at the time were well-versed in similar requirements for their own offerings (H/T Zebra, Honeywell, Panasonic, etc), but almost across the board they were rugged devices and didn't aim to target the pro-sumer hybrid of consumer device with enterprise features. But what does this mean in terms of product decisions? Ease of repair # Some of the earliest samples and reference products that came from our manufacturing partner during initial stages of development painted a stark picture of what cheap hardware looked like when the only goal is maximising profit: Glue blobs galore Soldered components Single-use clasps and anchors in the housing that would wear out after one to two disassembles of the unit, which was very easy to pull apart Loose wiring Cheap CMF (colour, materials, finish) Zero modularity .. and so on I've pulled apart Android devices (amongst others) aplenty over the years and have seen all of these in use in excess. These devices develop faults and unless you're willing to pull out a soldering iron they become paperweights. By comparison, the exposure I've had to what flagship OEMs have done for internal design - especially thanks to channels like JerryRigEverything and his passion for tearing devices apart so the rest of us don't have to - gave me more than enough inspiration to find a good balance between ease of access, modularisation, and appropriate, re-applicable adhesives. When it came to starting hardware development for the T8, the first few rounds of E/DVT (Engineering/Design Validation Testing) saw: Soldering components swapped for push-fit or lego-style-connectors High-wear items like the USB-C port and buttons either reinforced or modularised to their own sub-PCBA for ease of replacement Loose wiring replaced by ribbon cabling Mild adhesives used for holding the battery in place (with pull tabs) and display to the housing During this process, I went through more than 10 iterations improving the rigidity of the unit from the first EVT, and ensuring the back wouldn't pop off too easily since it wasn't glued on. Budgetary and time limitations prevented more development in this area; but if I was doing it again today I'd have aimed to make the back cover predominantly secured by screws rather than of clips/clasps, since the latter naturally wears out over time and particularly for customised orders, new printed back panels would have to be made to order when they did wear out, which is a 30-90 day wait. One final choice was opting not to bond the digitiser and LCD to one another; many OEMs do this with most devices today, which is in effect gluing the touch panel and the display underneath it together to make one item, the display assembly. There are arguments for doing this and it's generally a good thing, not least because the resulting picture can look much better without an air-gap within the assembly, and it also prevents dust and dirt from getting in there. That said, it also increases the cost both in terms of manufacturing cost to pay a factory to do this, but also when it comes time to repair a broken assembly; you're forced to replace the entire thing, or at least purchase the whole assembly, as even if you were to spend the appropriate time with a heat gun to try to separate them, the manufacturer will supply a bonded replacement. With all changes in place, repairing a T8 became very quick & straightforward to do. Exactly the words repair centres and in-house maintenance teams like to hear when units come in with something broken. Tough & resistant to unfriendly usage # In the process of improving repairability, the whole unit benefitted from greater protection from unfriendly usage by, for example, ensuring flex was minimised if the unit was crushed, twisted, or bent. Flex can be a major concern for a screen, since glass doesn't take to it near as well as other materials. In addition to this I spent several weeks with my team reviewing options for the outer finish of the unit, aiming to find a balance between something that looked decent, but also held up against knocks, scrapes, drops, and so on. On the first few batches of the T8 this was a rubberised finish on the housing, and it held up quite well in the target environments as it: Didn't really show marks Could be wiped off easily Offered better grip when holding it directly In later production runs with a new manufacturing partner we opted to switch to a textured paint coating instead, offering most of the same benefits but more likely to hold up against harsher cleaning agents and such, as considerable use could see the rubber eventually wear away. Then there were other design considerations, like the slightly-raised border that surrounds the screen. This is dual-purpose both to absorb shock from drops (along with the rest of the mostly-plastic frame) and keeps the screen ever-so-slightly further from an object that might otherwise impact it. Repellent to moist &/ corrosive environments # Knowing the tablet was destined - even during the product development phase with interested customers that predate DoorDash - to land in kitchen and high-humidity environments, but not wanting to fully seal the device for an IP rating (a trade-off for repairability), we dipped the internal components in a moisture-resistant coating. The tablet doesn't become impervious to moisture with this approach, as dropping it into water or using it during a heavy downpour may allow water to sit within the device and eventually cause a failure, but for humidity, and similar moisture devices may have to deal with, this worked. Corrosive, in this context, is what is corrosive to a PCBA - impurities, salts, the like. I couldn't save the unit from an acid dip and keep it within a budget! Long term component support # Early on in the company's history a partnership was formed with MediaTek, as we pivoted to enterprise MTK's AIoT division became our go-to for chipset selection that guaranteed long-term support & availability. The MT8765 in the T8 is by no means a powerhouse, in fact I think it's fair to say it wasn't the best choice of chipset in retrospect due to the performance issues I've seen over the years with it. For Android Go it would have been absolutely fine, and in truth the T8 would have made for a great Go device given the predominant use-cases for it, but we certified it for full-fat Android in the beginning and stuck it out. That said, it's taken us from 9.0 to 12, with potentially longer support possible if desired. Since The T8 is coming up on 5 years in-market, that need is simply not there. Outside the chipset all the standard multi-source component procurement was done by the team accordingly, so we rarely suffered component shortages even during some particularly tumultuous times for the global supply chain in the last few years; even now 4 years later and running another batch of 10s of thousands of units through production component supply has been pretty reliable. Resistant to battery ageing # One of the more active requirements, especially from customers coming from consumer tablets they'd had docked to a power supply for 6+months and suffered battery ballooning, was to handle power management intelligently. What I wanted to be able to facilitate from the get-go was a complete power management solution that allowed customers to: Boot & run without a battery connected (when connected to a power cable) Bypass the battery and run directly from power cable with the battery installed Configure OEMConfig APIs to control this via software, if it wasn't feasible to interface the hardware Unfortunately this quickly overshot time & budget requirements (but I did take some of this over to the M10p!), so I had to settle for a fully-software smart monitoring solution that would detect for how long the T8 had been plugged in, the voltages and cycles of the battery, and alter the charging profile accordingly. This required engineering coordination between the Android framework folks, kernel folks, and the engineers responsible for the PMIC design. From a UX perspective, it also introduced some scenarios that customers (or rather, their users who didn't read manuals) raised concerns about. When the tablet had been on charge for more than 24 hours straight for example, we allowed the battery to discharge intentionally to align with the new power profile. Unsurprisingly support tickets did get raised about devices not charging. There were also tickets raised about this solution not kicking in where customers would turn the power off to the tablet when their stores/offices/spaces closed, and back on in the morning; the solution simply wouldn't ever kick in because it wasn't permanently (or >24h) on charge. So it wasn't infallible, and accordingly we did see some genuine battery failures in the wild, but overall it's been a reasonably insignificant number compared to the number of devices shipped overall. The Android journey # This is not so related to DoorDash choosing the T8, but I think it's interesting to cover since it's relevant to the article. The RHINO promise has been bloat-free, vanilla Android since inception. Beyond Google apps and a couple of OEM-specific services (activation server, OEMConfig, chipset support), and some OEMConfig APIs, my flavour of Android is as light and clean as it comes. To achieve this was no insignificant undertaking as working with external engineering houses well-versed in the MediaTek turnkey builds (these are builds of Android the chipset makers offer with integrated support for the chosen chipset. Qualcomm, Rockchip, and others offer the same, often referred to as BSPs.) meant the only option for building Android I could get was to lean on these pre-made builds rather than building from AOSP. Again as with many things in product development there are pros and cons. The pros for a turnkey/BSP build are normally time to market and little need for configuration. The cons come in the amount of time you choose to dedicate to removing bloat the chipset vendor includes. Engineering apps, battery optimisers, sound enhancers, carrier optimisation apps.. you name it, the vendor has an app for it, and it's likely included. Then come the tweaks to UI and defaults set - Icon shapes, default radio behaviour, navigation setup, and so on. From the very beginning I built out a version-based requirements doc that combined a mixture of both best practice security and enterprise-friendly defaults, laced with some personal opinions on how Android should look, feel, and behave in line with examples set by Google and other OEMs offering vanilla builds. The turnkey builds were a fair departure from what I'd consider RHINO ready and so there was always a fair amount of work to do, even without custom development of OEMConfig and other bespoke functionalities. Still with all the reconfiguration required it remained faster than building AOSP from scratch, though given the choice I'd prefer building from AOSP. Swings and roundabouts. For the T8 we went through this process three times, the latest earlier in 2023 with Android 12. Each major OS build requiring porting of the changes made to the version before it, or setting up again based on the requirements doc from scratch. Upgrading unfortunately isn't much easier than building a version from scratch in my experience, but this could be down to the engineering partners I had available; my experience is understandably limited, and I imagine there's a good amount of investment in build management and development in larger OEMs that would offer a world of difference. The T8 launched with Android 9.0. 10 was feasible already at the time, but it was considered too new for some more risk-averse in the company and the older, more stable version of Android was chosen for the first products in the RHINO brand. It's understandable in some theory, but on reflection it wasn't a great choice, and had implications throughout the product's lifecycle. 9.0 included a version of Treble that was definitely not close to final, a fixed (as in permanently-set) partition system, and some other less-than-forgiving attributes. It was 10 that introduced the concept of dynamic partitioning, and set the groundwork for substantially more flexibility in how OEMs work with the on-device storage for resizing and repurposing disk partitioning on-the-go in later Android versions. This has been realised in the release of 12 this year for the T8, but given the device isn't planned to see 13, both due to demand and MediaTek's apparent stance on chipset support, the benefit is no longer there. Because we launched on 9.0, the same partitioning had to be used in 10 to allow an OTA (Over The Air) upgrade. Partitions can always be rewritten with a manual flash of a device, but an OTA update cannot adjust physical partition sizes. If we were launching 10 with a new device (like the M10p) we could have implemented dynamic partitioning, but as we wanted to upgrade from a fixed partition system on an existing device, we had to retain that. The trouble with fixed partitioning is unless you configure partitions to accommodate larger on-disk sizes later - something you can't scientifically calculate given changes that impact system sizing can't be predicted for the next version of Android, never mind 2 or 3 later - you'll eventually run out of space and can no longer support the upgrade to a newer version without some significant hackery, if possible. This is effectively what happened with the T8, and why we went 9.0 > 10 via OTA, then 12 with a manual flash for existing units, or a preload from factory of 12 for units manufactured in 2023. The upgrade to 11 took the /system partition to a larger minimum size than we could accommodate on the 9.0-specced partition layout, and we deferred upgrading again until necessary. Another aspect of maintaining an Android product over multiple years is GMS approval. Google sets approval windows for every Android release that state the latest possible time permitted for approving a new release of Android both as a new product, but also as an existing product that's upgrading; the latter has a bit more time since it's already an in-market device that needs to be supported. There are also expiry dates that stipulate the date after which it is not permitted to manufacture new Android devices with an older version of Android, though existing manufactured devices in the field could continue getting updates. These dates also differ based on form factor, Android flavour, and GMS licence (ie. EDLA (enterprise dedicated) devices). It's a reasonably complex, though not necessarily complicated process. For Android 10, the expiry date for GMS approval as a tablet on the MADA licence was Dec 2022, that means devices manufactured from January had to preload a newer version of Android from the factory, so 11+. 11 however passed the last date for GMS approval as a LR (launch release, an upgrade) back around August 2022, which meant when DoorDash picked up the phone and requested a brand new, freshly manufactured batch of T8s in late 2022, Android 12 development had to also be undertaken in order to have an approved Android build to put on the tablets in the factory before shipping out. But what about security patches? # Security updates are comparatively much simpler to plan and manage than major version releases, on the whole. The T8 has received quarterly security patches since 2019, and will continue to do so into 2024 based on current plans. The only implication with security updates is when Google stop backporting them. Backporting, to address the assumed question, is where Google will take the patch of a security vulnerability in the current version branch of Android (say, 13 as of August 2023) and undertake the necessary engineering to be compatible with older versions, so 12, 11, 10, before committing it to those version branches respectively. OEM engineering resources then pick up the patches for the relevant version they're working with, along with patches from component suppliers, chipset vendors, and anyone else pertinent to a specific device, and roll it out into the device tree (source code for the device). Google will not backport forever, however. There is typically a limit of 3 years per OS version before they cease backporting and instead focus on newer versions of Android. As an OEM, you then have the choice of: Continuing to support an Android version by cherry-picking patches from a newer version of Android and doing the engineering internally to apply to your device Or upgrading to a newer version of Android Manual backporting, as it's referred when the OEM does it after Google stops, can be challenging, especially for smaller OEMs or their engineering parters. I've often struggled to lock in agreements with partner resources, who would almost unanimously rather undertake the task of rolling out a new version of Android than keep the older version secure once Google moves on (either route demanding a reasonable chunk of change to achieve). This is relevant because while the T8 has received security updates on time and religiously since launch with no action from customers required across 9.0 and 10, backporting for Android 10 officially ended in Feb 2023, and as such the last security update for that version went out to the customer base a couple of months ago. Customers who want to continue to receive security updates for another year will have to manually flash tablets to the latest version. So to reiterate, launching on 9.0 was not a great decision. Thankfully all projects after the T8/C10 adhered to my mandate for leaning towards the newer versions of Android available to avoid such frustrations re-occurring, and 4 years later newer projects are faring much better. Not all that bad # Though the T8's Android journey has been somewhat more challenging, this isn't reflected across all projects I've worked on and devices I've supported. I want to stress it's been mostly enjoyable to support the platform. I enjoy debugging (and squashing!) bugs, writing the release notes, scheduling the OTAs, planning feature drops, building out the OEMConfig (and other solutions) roadmap based on customer needs, and absolutely.. ..more than anything.. ..requesting bug reports from customers 38 times a day in response to one-sentence support tickets exclaiming something is broken. :). Wrapping up # I've covered off a fair bit of my experience bringing the T8 to market from a product development point of view. I naturally haven't touched on everything that went into launching the T8, nor some of the more bespoke requests from DoorDash on customisations they've received over the years to the model, including: Hardware revisions configured to local markets/geographies we didn't initially launch into Custom hardware configurations (NFC was removed from one revision for a particular use case) All of their custom branding and packaging Their custom-manufactured accessories (cases, etc) And many other value-adds that made the T8 the DoorDash T8. But ultimately a springboard from which to jump is what had them Dash through the Door (😁) in the first place, and I'm immeasurably proud of what I and my team achieved as the first major project of a new brand.

  • Android's work profile gets a major upgrade in 14
    by Jason Bayton on August 9, 2023 at 12:00 am

    In case you missed it, my article on what's new in Android 14 covered off a subtle but significant change to the way the work profile functions when toggling it on and off (pausing it). I've already popped together a technical overview of the change, as I like to do for many things that change on major releases. These intentionally lack any sort of opinion, bias, or objectivity as best I can in order to be simply taken at their intent - a straightforward technical change document highlighting what's changing, why, and the impact it may have. This, however, is an article and fully subject to all of my opinions, so let's dive in a little! Why is the work profile UX changing? # The reasoning for the change, officially, is pending Google's 14 marketing push likely due in the next several weeks when 14 lands. That said, tidbits of public information have popped up, and it's all about improving the experience for work profile users. When you turn off a work profile on 13 and older, the whole work profile user turns off. This obviously kills the apps as expected, but it also turns off every other aspect of work profile functionality also - the cross-profile APIs used for caller ID and such, application updates, and for OEMs like Samsung, the ability to move data between profiles. This obviously poses some challenges to providing a good user experience. When the boss calls while the profile is off, users will see a call from a phone number rather than a named contact, making it much harder to ignore out of hours 🙂. Additionally, because the profile is entirely off, app update policies don't apply and therefore devices can fall out of compliance,ending up in a situation where the work profile is automatically removed, or at least access to corporate data is prevented due to DLP policies in place by the managing organisation. One of the biggest annoyances reported with the work profile though? Notification-geddon. When the profile is turned off for a period and eventually turned back on, the device may be inundated with notifications all at once for everything that has happened while off. How is this addressed in 14? # In 14 Google has switched up what "pause" means, and have instead taken a leaf out of the Digital Wellbeing book to focus on the suspension of applications themselves, leaving the work profile itself still running. That means the management of the profile can continue unhindered, so applications continue to update, cross-profile APIs still function, and presumably OEM plugins like those from Samsung allowing cross-profile data migration (if you want to know what this means, open Gallery, select a picture, and in the menu there's a Move to work profile option) can continue to function, providing corporate policy permits it. And notifications? They simply accrue in the background in the same way they do for Do Not Disturb, Focus, and similar Digital Wellbeing modes. Balancing UX with UX # The drawback for this, understandably, is data and battery use while the profile is now paused. While the latter is going to likely be minimal during the pausing of the work profile - not easy to compare scientifically since there are many other changes between 13 and 14 that will equally contribute to differing battery use - data usage can silently climb in the activities of app updates, notifications, and everything/anything else a suspended app can still do while the work profile is off, rather than only being permitted to do so when turned on as per 13 and older (though Google confirm things like location won't be permitted when the profile is paused). While that's not going to be a problem for me, and likely many folks reading this, Android is a global platform, and devices are managed all over the world. This is why I felt it pertinent to mention it on the tech doc, because there are users with limited, capped, or expensive usage-based internet plans at home (I'm talking ISP, not cellular) - my Dad in Wales is capped to 10gig in a month out of choice because it's cheap! - and those who actively turn their work profile off to avoid usage in addition to gaining the benefits of the work-life balance the work profile provides may find themselves seeing the effects of this change quite quickly. Again, most will likely not even notice, but our ecosystem is vast and the Android user base geographically-diverse. Since the option to turn off the work profile completely is gone, I want to make sure organisations - and users in particular - know what's coming before it causes a problem. A net-positive change # Overall the changes make sense for the evolution of Android Enterprise, and it's wonderful to see Google's PMs honing in on the finer details of headline functionality. Combined with fix for work profile screenshots and several other cross or work profile features, it's a decent release, generally.

  • Android's work profile gets a major upgrade in 14
    by Jason Bayton on August 9, 2023 at 12:00 am

    In case you missed it, my article on what's new in Android 14 covered off a subtle but significant change to the way the work profile functions when toggling it on and off (pausing it). I've already popped together a technical overview of the change, as I like to do for many things that change on major releases. These intentionally lack any sort of opinion, bias, or objectivity as best I can in order to be simply taken at their intent - a straightforward technical change document highlighting what's changing, why, and the impact it may have. This, however, is an article and fully subject to all of my opinions, so let's dive in a little! Why is the work profile UX changing? # The reasoning for the change, officially, is pending Google's 14 marketing push likely due in the next several weeks when 14 lands. That said, tidbits of public information have popped up, and it's all about improving the experience for work profile users. When you turn off a work profile on 13 and older, the whole work profile user turns off. This obviously kills the apps as expected, but it also turns off every other aspect of work profile functionality also - the cross-profile APIs used for caller ID and such, application updates, and for OEMs like Samsung, the ability to move data between profiles. This obviously poses some challenges to providing a good user experience. When the boss calls while the profile is off, users will see a call from a phone number rather than a named contact, making it much harder to ignore out of hours 🙂. Additionally, because the profile is entirely off, app update policies don't apply and therefore devices can fall out of compliance,ending up in a situation where the work profile is automatically removed, or at least access to corporate data is prevented due to DLP policies in place by the managing organisation. One of the biggest annoyances reported with the work profile though? Notification-geddon. When the profile is turned off for a period and eventually turned back on, the device may be inundated with notifications all at once for everything that has happened while off. How is this addressed in 14? # In 14 Google has switched up what "pause" means, and have instead taken a leaf out of the Digital Wellbeing book to focus on the suspension of applications themselves, leaving the work profile itself still running. That means the management of the profile can continue unhindered, so applications continue to update, cross-profile APIs still function, and presumably OEM plugins like those from Samsung allowing cross-profile data migration (if you want to know what this means, open Gallery, select a picture, and in the menu there's a Move to work profile option) can continue to function, providing corporate policy permits it. And notifications? They simply accrue in the background in the same way they do for Do Not Disturb, Focus, and similar Digital Wellbeing modes. Balancing UX with UX # The drawback for this, understandably, is data and battery use while the profile is now paused. While the latter is going to likely be minimal during the pausing of the work profile - not easy to compare scientifically since there are many other changes between 13 and 14 that will equally contribute to differing battery use - data usage can silently climb in the activities of app updates, notifications, and everything/anything else a suspended app can still do while the work profile is off, rather than only being permitted to do so when turned on as per 13 and older (though Google confirm things like location won't be permitted when the profile is paused). While that's not going to be a problem for me, and likely many folks reading this, Android is a global platform, and devices are managed all over the world. This is why I felt it pertinent to mention it on the tech doc, because there are users with limited, capped, or expensive usage-based internet plans at home (I'm talking ISP, not cellular) - my Dad in Wales is capped to 10gig in a month out of choice because it's cheap! - and those who actively turn their work profile off to avoid usage in addition to gaining the benefits of the work-life balance the work profile provides may find themselves seeing the effects of this change quite quickly. Again, most will likely not even notice, but our ecosystem is vast and the Android user base geographically-diverse. Since the option to turn off the work profile completely is gone, I want to make sure organisations - and users in particular - know what's coming before it causes a problem. A net-positive change # Overall the changes make sense for the evolution of Android Enterprise, and it's wonderful to see Google's PMs honing in on the finer details of headline functionality. Combined with fix for work profile screenshots and several other cross or work profile features, it's a decent release, generally.

  • Google's inactive account policy may not impact Android Enterprise customers
    by Jason Bayton on August 3, 2023 at 12:00 am

    Back in May Google announced a change to their account inactivity policy. If you're a Google account owner you may have received an email also: If not, it was covered quite extensively by the media: ars TECHNICA tom's guide The Verge Wired and others I'd considered adding to the noise back then with an enterprise point of view, but it occurred to me there really wasn't any clarity for enterprise customers leveraging a Google account to bind Android Enterprise to their EMM at that point, and so I've been busy working in the background to understand the implications for Android Enterprise customers and if there's truly a mandate to keep the account active in order to prevent the bind from being deleted, and thusly, all enrolled devices becoming either unmanageable or wiped entirely (depending on EMM). The good news is, per my understanding, Google is working on a solution for the enterprise bind use case that will address Google accounts associated to an active bind being subject to the inactivity policy. There is no official word on this as yet (I'll update when that changes), so this is obviously, and unfortunately, subject to change. That said, since the original May announcement the list of exclusions to this policy has grown. Given it doesn't go live before December 2023, there's still time to fine-tune it, and do so I'm certain they will. Summarising the change # In short, as a holder of a Google account, if you have not logged in and performed an activity with said account within 2 years, it will be marked for deletion. Simply logging in is not good enough, unless that login is to a 3rd party solution supporting Sign in with Google, one of the following should be undertaken while logged in: Reading or sending an email Using Google Drive Watching a YouTube video Sharing a photo Downloading an app Using Google Search Using Sign in with Google to sign in to a third-party app or service The important current exceptions to this are: Your Google Account was used to make a purchase of a Google product, app, service, or subscription that is current or ongoing. Your Google Account contains a gift card with a monetary balance. Your Google Account owns a published application or game with ongoing, active subscriptions or active financial transactions associated with them. This might be a Google Account that owns an App on the Google Play Store. Your Google Account manages an active minor account with Family Link. Your Google Account has been used to purchase a digital item, for example, a book or movie. Not all of these are one-and-done. Using a subscription requires it remains active to secure the exception, for example. Create-and-forget enterprise accounts # The problem for organisations quite clearly is the unlikelihood any of the above exceptions may have occurred. Frequently organisations will create a Google account at the time of binding an enterprise to their EMM, and subsequently forget about the account until it becomes necessary to manage an uploaded application's advanced settings, or manage the bind itself. Arguably even if organisations sign in to the account, this may not be enough to trigger Google's activity monitor based on the requirements outlined above. This could lead to even more confusion for organisation admins that do go out of their way to keep an account active with infrequent intentional logins; those inactivity emails will land in the inbox associated with the account, and require the organisation to actively manually confirm the account is active. What happens if the account responsible for the Android Enterprise bind is deleted? # When a Google account is used to bind Android Enterprise to an EMM, an enterprise ID (as developers see it), or Organisation ID (as customers see it) is created. Every policy, device, application, etc, is then associated to this enterprise ID, and the EMM is granted permission to manage everything within that enterprise ID respectfully. That Google account becomes the primary account associated with the bind. Others can be added, and I'll touch on that shortly, but by default it is just the primary account used to create the bind in the first place that remains associated with it. A feature request here would be to provide a means of adding multiple accounts to the bind during the binding process. There's no visibility today of the ability to add multiple accounts to administer the bind in the current setup flow, and organisations will only come to know this is possible if they actively log in and manage the bind through admin settings at a later time. If this account is deleted, the enterprise - the bind - is deleted with it. Depending on the EMM this can result in anything from loss of management capabilities, with devices effectively stuck with the policy and state they are in at the time the bind is deleted, to an immediate wipe of the entire estate (and obviously an inability to re-enrol). These variances exist due to various custom DPCs, EMM logic, and of course AMAPI. Beyond devices however, any uploaded applications become inaccessible, policies, web apps, or any other data associated with the bind are also unrecoverably deleted. What can organisations do to safeguard against deletion? # Understandably with the devastation this can cause to an organisation - I actively oversee multiple 10s and a few 100 thousand unit deployments that would cripple company operations if they were to fall offline or completely reset - it's pertinent to undertake actions to ensure the continuity strategy doesn't entirely rely on Google making an exception to protect the bind. Here are some things you can do: Add more owners to the bind management # Simple and straightforward, follow my FAQ to add more Google accounts to be able to manage the bind. Aim for at least two Owners for redundancy, including the original account that set it up. If only one account manages a bind and the account is deleted, as above, the bind is deleted. If more than one account manages the bind, and any one of those accounts are deleted, the bind remains in place as there is still an owner associated. This obviously scales up to the number of accounts associated to the bind. Use domain-based Google accounts # Not Google Workspace. Google doesn't support Google Workspace accounts managing the bind. Rather, when you sign up for a Google account, click the small link to use an existing domain, and set an account up using the corporate email domain of your organisation. Group mailboxes are a safe bet, offering multiple admins the ability to interact with the account even in high employee churn environments. Again this won't work for organisations that lean on Google Workspace, so if it's not possible to create an account under your organisation's domain, ensure the recovery information is added, and again aim for a group/shared mailbox where multiple admins have access to avoid losing access to the Google account in future. Ensuring emails Google sends out land in a monitored inbox drastically reduces the likelihood of: Inactivity alerts being missed Account recovery being impossible Leverage an in-use account for the bind # Definitely not a personal account, but rather consider an existing group or departmental Google account that sees active use. One example may be a developer account used to publish to Google Play, as this also provides additional flexibility for managing private applications on a more granular level through the Google Play Console rather than the Google Play iFrame, avoiding bind lock-in should it be necessary to ever start afresh. An active account will not be subject to the inactivity policy, naturally, though consideration must be given to who has access to what may be very important accounts in some organisations. Bring on the solution # The above suggestions can and should be considered irrespective of the inactivity policy, but for those particularly concerned by Google's approach to this, hopefully the knowledge they're working on it will put minds at ease. This is a reality of consumer policies impacting organisations which unfortunately does happen quite often given Google's size, consumer focus, and shared infrastructure between teams. Hopefully in time they'll continue to improve how they approach enterprise in the way they have with private application approval policies, Play Store policy escalations, and so on. One day they may even be able to hash these challenges out before the consumer team(s) make their announcements 🙂 In the meantime, go forth and protect your bind(s)!

The Bearded Wonder From Down Under All things VMware Workspace ONE, Identity and everything in between.

Brooks Peppin's Blog Managing Windows in the Modern Workplace

Many Miles Away IT guy from Down Under

    Feed has no items.

    Feed has no items.

Sam Akroyd Thoughts on Tech

  • VMware Explore EU: Session Preview
    by Sam Akroyd on October 10, 2022 at 10:13 am

    Its that time again, just 6 weeks until VMware launch the new annual event in Barcelona. The session catalog has been announced and its full of great content, but with 100s of options, which sessions stand out for me? If anyone has followed my blogs for the past few years, you’ll know I was a

  • VMware Explore US – What’s New?
    by Sam Akroyd on September 5, 2022 at 8:17 am

    Last week VMware debuted their new annual event, VMware Explore. Gone was the VMworld banners of years gone by, replaced with a slick new brand, promising inclusivity for developers, security folk and others alongside the thousands of VMware followers. Aside from the clientelle though, whats new? VMware Explore made its debut last week, and as

  • vSphere+ is here! What is it and why is worth upgrading to it?
    by Sam Akroyd on July 6, 2022 at 2:36 pm

    This week VMware announced vSphere+ with a lot of fanfare, but what is it, and why should customers be looking at switching their traditional perpetual on-prem licences to it? Read on and hopefully you’ll learn a thing or two…. Having been fortunate to having sat on both the operational IT and vendor side, you get

  • Who are the next big hitters in the world of tech?
    by Sam Akroyd on June 21, 2022 at 1:30 pm

    One of the great things of being in the world of tech is not just appreciating the next product or feature coming into the products that your business is releasing. Don’t get me wrong – thats awesome cause you can see customers adopting and consuming those new features, but at heart, I’m still the kid

  • Managing Windows with SaltStack Config – Part 2: Roles & Config
    by Sam Akroyd on March 15, 2022 at 4:08 pm

    In the previous blog we got started with managing Windows using SaltStack Config, getting familiar with winrepo and installing software in line with our standard server builds. Next we are going to expand upon that and add the correct Windows roles, configuration and settings to our Windows Server builds. Anyone who has been (un)fortunate to

  • Workspace ONE UEM 2306 release
    by techhub981158167 on August 18, 2023 at 2:13 pm

    I don’t often post about software releases but given the amount of updates and new features in 2306 I though I would call it out. I won’t go into huge detail as that’s what Release Notes are for, but I did want to call out a couple of features that caught my eye. The full … Continue reading Workspace ONE UEM 2306 release →

  • Workspace ONE Intelligent Hub Notifications
    by techhub981158167 on June 20, 2023 at 1:25 pm

    A look at VMware Workspace ONE Intelligent Hub notifications. The test device was an Oppo Android device that was enrolled into Workspace ONE in Registered mode rather than full device enrollment, full enrollment also works but it just happened this device was Registered.

  • Workspace ONE Assist and Registered Mode
    by techhub981158167 on June 9, 2023 at 3:25 pm

    Is it possible to use Workspace ONE Assist when a device is Hub Registered? In short, yes. In this video I will take a look at remote Assist on an Android device when it is enrolled into VMware Workspace ONE UEM as Hub Registered rather than full device enrolment.

  • VMware Workspace ONE ITSM Connector for ServiceNow 3.0
    by techhub981158167 on April 26, 2023 at 8:22 am

    A little over a year ago, February 2022 from memory, VMware released a Connector from Workspace ONE UEM to ServiceNow which meant that some features from Workspace ONE UEM would be open to Support staff that had access to ServiceNow. This allows you to carry out common tasks such as change passcode, device wipe, enterprise … Continue reading VMware Workspace ONE ITSM Connector for ServiceNow 3.0 →

  • Workspace ONE Web app – Blocked site?
    by techhub981158167 on April 5, 2023 at 3:06 pm

    This a short post I have been meaning to write for a while but it seemed to slip down the ‘to do’ list. If you are a user of the Workspace ONE Web app then you may have seen this screen before: Basically, all this means is that the Web app has been configured to … Continue reading Workspace ONE Web app – Blocked site? →

Thomas Cheng Welcome to my digital home!

VirtuallyUnboxed Lifting the lid on everything virtual

  • End of support for vSphere 6.5.x and 6.7.x
    by virtuallyunboxed on October 20, 2022 at 4:31 pm

    In case you missed it, last week marked the end of general support for vSphere 6.5 and 6.7. This is the same regardless of whether you were using it for data centre services or EUC services like Horizon.

  • Desktop Repurposing v4
    by virtuallyunboxed on October 20, 2022 at 4:23 pm

    This year, myself and Matt Evans joined forced again, along with newcomer, Jonathan D'arcy to review some of the best desktop repurposing tools on the market. As with previous years we reviewed imaging and performance. However, this year we also took a look at the accompanying management solutions.

  • VMware SASE and Cloud Web Security
    by virtuallyunboxed on January 22, 2022 at 3:11 pm

    Let's start with the basics! SASE is a Gartner term and is an abreviation of Secure Access Service Edge. Still not much help right? Well lets start explaining this by looking at how people typically work, espeically remotely, and how their traffic is secured. Most of you that ever work remotely will most likely use a device level VPN. This uses software on your device to create a tunnel into your company data centre and allows you to remotely access internal resources. This is how most companies have done it for many years, and it really dates back to the days when all a companies resources were in their own data centre. Tunnelling all the traffic back into the data centre was the perfect way to reach everything a remote user would need.

  • Workspace ONE UEM and Workspace ONE Access Integration for Hub Services
    by virtuallyunboxed on March 2, 2021 at 4:06 pm

    I know there are a lot of SaaS customers out there who have only been using basic MDM functionality within Workspace ONE. The platform has moved on a lot in the last few years and if you haven't already seen it i strongly suggest you check out hub services. This takes the Workspace ONE agent that is used for device management and adds additional functionality to the application such as a unified app catalogue, people search and a notifications platform to name but a few!

  • Workspace ONE Access FIDO2 integration
    by virtuallyunboxed on February 19, 2021 at 2:33 pm

    As of this month (Feb 2021) All Workspace ONE Access SaaS tenants, now supports FIDO2 as an authentication method. So, I thought i'd put together a short video showing how easy it is to configure it and some different device types using the solution.

Mobile Jon's Blog My WordPress Blog

  • Workspace ONE UEM 2306: Reviewing the Biggest WS1 Platform Update in 2023
    by [email protected] on August 14, 2023 at 1:59 pm

    Workspace ONE UEM has had a bit of stagnation over the last 12 months, while they work on their new platform and architecture. With VMware Explore only a week away, their timing is impeccable as Workspace ONE UEM 2306 launches. We’re going to take a good look at 3 huge capabilities they’re introducing: (1) MacOS

  • Windows 365 Switch: Time to Switch Things Up!
    by [email protected] on August 11, 2023 at 12:19 pm

    Yesterday, Windows 365 Switch hit the public preview stage via the Beta and Dev Channels. The 2nd of the “Big 3” for Windows 365 in Windows 365 Boot, Windows 365 Switch, and Windows 365 Beachmode (Offline Mode). Another great advancement on the Cloud PC platform, which we will discuss today. I will show you how

  • Windows 365 Analytics Powering Decision-Making for Cloud PCs
    by [email protected] on July 25, 2023 at 3:40 pm

    With the excitement around Windows 365, I wanted to take a look at something that I believe is underrated. Windows 365 Analytics provides some really strong monitoring/data on the user experience and performance. This is the latest of my articles about Windows 365 as a Windows 365 MVP. Today, we’re going to talk about remote

  • Mobile Jon’s Top 5 Sessions for VMware Explore 2023
    by [email protected] on July 19, 2023 at 2:54 pm

    Well everyone, we are just about one month from VMware Explore 2023 in VEGAS BABY! With that in mind, I recently talked about one of my sessions at VMware Explore all about Neurodiversity. Today, I want to hit on 5 amazing sessions that I am legit excited about since that’s what everyone else is doing

  • Embracing my Neurodiversity at VMware Explore 2023
    by [email protected] on July 11, 2023 at 8:24 pm

    This year, for the first time in VMworld/VMware Explore history Neurodiversity will be brought to the stage featuring myself, Jon Towles and Philip Monk. To say, we need your support is an understatement. My experience has shown that many companies tout diversity in the workplace. The sad reality is that sentiment isn’t always actualized. Today,

VMware | Digital Workspace Tech Zone Go from zero to hero with the latest technical resources on the VMware Digital Workspace Tech Zone.

VMware Workspace ONE The un-official subreddit for VMware Workspace ONE. I recently started learning/managing Workspace One for the company I work for, I came to reddit to find others and saw that there wasn’t a community, so I started one. Our discord is here https://discord.gg/Zhr3TqMMf6

  • Keep a pushed app on Android but unenroll the device
    by /u/ZackyoTV on August 21, 2023 at 10:34 am

    Hello! ​ I'm creating a second post regarding keeping a pushed app on a telephone, but this time It is regarding Android OS. (Previous post: https://www.reddit.com/r/WorkspaceOne/comments/136gt8e/keep_a_pushed_app_on_ios_but_unenroll_the_device/) ​ But It seems to me that this isn't a function for Android. At all actually. I'm not able to find something intuitive regarding this matter, nor do I find previous posts on Reddit or other forums. So this might not be possible? To push out Intune Company Portal, unenroll the device from Workspace One then start the setup for Intune instead? submitted by /u/ZackyoTV [link] [comments]

  • Windows 10 device did not wipe after being given the Device Wipe command
    by /u/FloppySpiderOfTheSea on August 18, 2023 at 5:50 pm

    We had a Windows 10 device marked as lost / stolen in our tenant and the device wipe command was sent. Wipe log shows that this was processed. The device was found, and has reconnected to the network and the internet, checked in to the tenant, but never did complete the wipe. The status still says Wipe Pending but there is nothing to indicate it should have failed in the console. Any way to diagnose what went wrong? submitted by /u/FloppySpiderOfTheSea [link] [comments]

  • Launcher install is not working
    by /u/Sir_Yukii on August 18, 2023 at 9:31 am

    Hey we have this issue on several devices with different Android Versions. The Launcher is downloading which I can see on the device the profile appears as installed on MDM but the actual APK doesn't seem to get installed. Any ideas? submitted by /u/Sir_Yukii [link] [comments]

  • Integrate Okta Apps with Intelligent Hub
    by /u/Luisetto86 on August 16, 2023 at 3:24 pm

    Hello there!! I’ve read that you can show Okta apps (bookmarks) in the Workspace One Intelligent Hub app Catalog, has anyone done this? I’m stuck at some point where VMWare is asking for my tenant URL that I thought it was “my-company.okta.com” but it seems not to work.. Any ideas?? Thanks in advance A Newbie with WSO submitted by /u/Luisetto86 [link] [comments]

  • Workspace ONE UEM 2306 is their biggest update in 2023
    by /u/Electronic-Bite-8884 on August 14, 2023 at 5:18 pm

    submitted by /u/Electronic-Bite-8884 [link] [comments]

  • Where to find logs regarding "Failed to install"
    by /u/ZackyoTV on August 14, 2023 at 10:11 am

    Greetings! ​ I am trying to find the logs for why Android phones is getting "Failed to install" on Wi-Fi profiles. I tried to do a "Request Device Log" -> Wait 5 minutes -> Head into the Device -> More -> Attachments -> Documents, but I was unable to find something specific regarding why the Wi-Fi Profile always fails. ​ Any help on this one for further troubleshooting? submitted by /u/ZackyoTV [link] [comments]

  • Reminder - This subreddit is not for promoting services
    by /u/ZakeriaCollins on August 12, 2023 at 11:19 pm

    submitted by /u/ZakeriaCollins [link] [comments]

  • WS1 - Zebra devices. DataWedge profiles
    by /u/FunnySith on August 11, 2023 at 6:41 am

    Hi (sorry for bad language. Not English) Trying to push DataWedge settings to Zebra devices, but The device won't import the settings. When you export a DataWedge profile and copy this out to a PC, reset DataWedge(on device), import the file to WS1, push this out to the device and import, it doesn't work. This is what Zebra says should work. A guy that works for VMware says this will not work. .db file needs to be changed into other file format and renamed after push to device. When you export the DataWedge profile and copy this out to the PC, reset DataWedge(on device), rename from .db to .txt, import the file to WS1, push this out to the device, run the rename command from .txt to .db and import then it doesn't work. It seems that WS1 "converts" the .db file into .BIN format and I can't manage to get it to stay as a .db. WS1 - On-premise 2211 Device - Zebra TC26 submitted by /u/FunnySith [link] [comments]

  • SINST-176160 - Workspace One UEM - Unable to edit existing or create new DDUI profiles. (93911)
    by /u/Erreur_420 on August 10, 2023 at 8:18 am

    Upon deploying the patches noted in KB 93877, you may experience an error when creating or editing DDUI device profiles (iOS, macOS, Android Enterprise) in the Workspace ONE UEM Console. Version identified Workspace ONE UEM 23.02.0.17 Workspace ONE UEM 22.12.0.27 Workspace ONE UEM 22.9.0.35 Workspace ONE UEM 22.6.0.40 Workspace ONE UEM 22.3.0.50 For the resolution download and copy the impacted DLL on the servers : https://kb.vmware.com/s/article/93911?lang=en_US&queryTerm= submitted by /u/Erreur_420 [link] [comments]

  • WS1 - On Premise environment need urgent patching!
    by /u/Erreur_420 on August 9, 2023 at 10:23 am

    Hello All, Since the 7th of July 2023 VMware discovered that several thousands of DLL used in Workspace One Uem server were expiring the 8th of July. Dedicated KB: SINST-176145 - Multiple Workspace One Uem application pools and services may not start once stopped (93877) (https://kb.vmware.com/s/article/93877) The following on premise components need urgent patching: - Device Services - Web Console - Self Service Portal - DevicesGateway - WS1_API - Device Scheduler - Directory Sync Service - MEG Queue Service There is 3 different use case: A) you are between the version 2203 and 2302 , then you need to install the dedicated patch given in the KB B) you are under the version 2203 and agree to upgrade your server , then you need to install the dedicated patch given in the KB C) you are under the version 2203 and don’t want to upgrade , then you need to use the dedicated script (UEM Digital signing utility tool) given in the KB to re-sign every DLL If you need any assistance, feel free to open a Severity 1 ticket to VMWARE. Even if your version is not supported anymore, help will be provided Saas customer don’t need any manual action from customer since the SaasOps team of VMWARE is patching their tenant. If you had an upgrade of your tenant this week, she will be cancelled and postponed to the next week Thanks to u/MRNordsee for alerting everyone on this sub EDIT: do not install patch 23.2.17 we are facing issue to create / edit profile on iOS / Android / Mac post upgrade submitted by /u/Erreur_420 [link] [comments]

  • Azure AD Integration for Users and Groups
    by /u/slaguru on August 8, 2023 at 2:14 pm

    Hey yall... Quick question, its been a while since I connected WS1 to AAD. When I looked today I see that there is a Azure AD Integration and a use Azure AD for Identification services button. Would it be true that if I just use AAD integration and NOT Identity services we just get authentication at the UEM console and not Federated out.. If that makes sense :-). Any Ideas would be welcome submitted by /u/slaguru [link] [comments]

  • Can't ping, let alone reach the WS1 Access URL/IP
    by /u/Vescli87 on August 8, 2023 at 1:24 pm

    Hi! I am running an ESXi host (managed by/with vCenter) on which a Workspace ONE Access appliance and connector are running as well. Now I just found out that the URL that used to work, doesn't work anymore. I cannot ping the url or even IP address but the appliance does only tell me to use those. Is there any way to check the network configuration on the appliance via the CLI? I have zero knowledge of this CLI so I have no idea.. submitted by /u/Vescli87 [link] [comments]

  • WS1 DLL Signing expire today
    by /u/MRNordsee on August 8, 2023 at 7:04 am

    KB Title: Multiple Workspace ONE UEM application pools and services may not start once stopped Are you kidding me? If this turns out as bad as it sounds the WS1 could just stop working if you Restart. I hope VMWare is publishing a fix TODAY… Source: https://kb.vmware.com/s/article/93877?lang=en_US …„The internal CA and certificate used to sign DLLs shipped with Workspace ONE UEM, is set to expire at 1320 UTC on 8th Aug, 2023. Past expiration, app pools or services dependent on these DLLs may fail to start or function properly on/after 8th Aug, 2023.“…. submitted by /u/MRNordsee [link] [comments]

  • New macOS Update Dashboard
    by /u/Skyboard13 on August 7, 2023 at 8:01 pm

    So this video just popped up on one of VMWare's YouTube channels. They are adding macOS to Resources -> Device Updates. This is great and LONG overdue. https://www.youtube.com/watch?v=d78mRfJmb4o But I've got some questions. 1) Does this remove the requirement for devices to be enrolled in ABM/DEP? 2) Will this allow admins to install other updates other than the OS updates. Like Xcode or Safari? 3) When will this be available. I looked in my console (we're cloud and running the latest version) but it's not there. So I cannot test. submitted by /u/Skyboard13 [link] [comments]

  • iPhone DEP
    by /u/richardmartinjmp on August 7, 2023 at 3:32 am

    how to force iPhone to get DEP token/profile. Every time, When i do factory it goes back to normal setup mode. Telco, already removed the device and added back to ABM from their side. submitted by /u/richardmartinjmp [link] [comments]

  • A very dumb Scripts question (Windows).
    by /u/Skyboard13 on August 4, 2023 at 4:06 pm

    Been using scripts and sensors to great effect lately, but something's been bugging me, does WS1 UEM not have the ability to run a script right away from a device's details page? I know I can run the script from the script's assignment screen, but is that the only option? Some times I need to run a script on just one device right away and bouncing around is a PITA. EDIT: Fixed grammer. submitted by /u/Skyboard13 [link] [comments]

  • Possible Bug with VMware Workspace ONE Launcher for Android Version 23.07?
    by /u/Sad_Adhesiveness_315 on August 4, 2023 at 3:28 pm

    Just reaching out to see if anyone else has had the same issue or if maybe I'm doing something wrong. Our Workspace ONE UEM is set to always use the latest version of Launcher and before today we never had any issues with that setting. This morning I was notified about an issue with our Android tablets. Users were not able to adjust the brightness from the slide-down menu (excuse my ignorance of the technical term for that). This would normally be filed under "Trivial Annoyance" and investigated at a later time, except our users are truck drivers and need to be able to adjust the brightness of the tablet without having to go through different menus to do so. Initial assessment of the issue revealed that the slide down menu was not available at all from within the Launcher application. After some investigation and troubleshooting, I disabled the "Always use the latest version of Launcher" setting and changed the default version to the second most recent version (23.4). I reinstalled Launcher on my test tablet and found that the issue had been resolved. Has anyone else noticed this? or any I doing something wrong? submitted by /u/Sad_Adhesiveness_315 [link] [comments]

  • How to ensure the privacy of my personal device
    by /u/gtnbssn on July 28, 2023 at 2:32 am

    I use my personal laptop at work. From what i can read here, and elsewhere, it seems WS1 will pretty much have complete access to managing my device, including installing and removing any app they see fit. I understand the security concerns in a large organisation. My question isn't about "why is this required" or "justifying the use of my own device". My understanding is that WS1 is precisely a solution to allow the IT department to manage all of the company owned devices. How can I 100% ensure the privacy of my own device if I set up WS1 according to policy? Would creating a separate user account for work be enough to ensure absolute isolation between what WS1 will have access to and my private data / the general set up of my laptop? Is there any technical documentation I can refer to to make sure I understand all the implications? I am using a mac. Thanks!! submitted by /u/gtnbssn [link] [comments]

  • Expose com.apple.BarcodeScanner on home screen
    by /u/yurtbeer on July 27, 2023 at 6:40 pm

    Crazy question and I can't seem to make it work but is there anyway you can have the hidden code scanner that is on iphone be shown on the home screen? I can manual add it to control center but not been able to find any other place to show it. security reasons we need to hide camera and safari, this all works great just wanted a way to allow staff easier access to the qr scanning submitted by /u/yurtbeer [link] [comments]

  • Anyway to keep a persistent exe
    by /u/linsane24 on July 27, 2023 at 7:31 am

    On provisioning is there anyway for ws1 to keep a executable persistent until success code or a marker file is found? So for example if the executable fails WS1 will automatically try to rerun the same executable after x time and on reboot until success is noticed via either the executable exit code, or via a file that the executable can publish on finish. A nice to have would be that if ws1 has a try limit. IE tried to run this software 5 times after x time, failed every time so gave up. any ideas if we could possibly accomplish this. Basically have a provisioning application that does a bunch of stuff...just want to make sure if it fails or user accidentally closes it or restarts it resumes(it has internal logic for auto resume from where it left of just needs to be launched with appropriate permissions). submitted by /u/linsane24 [link] [comments]

The Support Insider VMware Support News, Alerts, and Announcements

  • 10 top new articles created in July 2023 for ESXi, vCenter and more!
    by Marcela Gleixner on August 18, 2023 at 5:01 pm

    July has brought a fresh wave of VMware Knowledge Base (KB) articles. From optimizing cluster management to navigating vCenter upgrades, these articles offer a treasure trove of knowledge. Join us as we unpack the highlights of these KB articles and explore how they can shape and enhance your virtualization journey.  The post 10 top new articles created in July 2023 for ESXi, vCenter and more! appeared first on VMware Support Insider.

  • Top 5 newly created KB articles in July 2023 for NSX-T and HCX.
    by Marcela Gleixner on August 17, 2023 at 5:36 pm

    Today we're covering critical issues and helpful insights related to NSX-T to HCX and beyond! This is a roundup of newly created articles in July 2023 so be sure to check them to be ahead of any arising issues! The post Top 5 newly created KB articles in July 2023 for NSX-T and HCX. appeared first on VMware Support Insider.

  • 10 new KB articles created in July 2023 for Workspace ONE, Horizon View, and more! 
    by Marcela Gleixner on August 16, 2023 at 6:32 pm

    In this blog post, we present an overview of the most recent VMware Knowledge Base (KB) articles released in July. These articles cover a diverse range of topics and products, offering valuable insights and solutions for VMware users. From vTPM-enabled Instant Clone desktop pools encountering AppVolumes issues to troubleshooting challenges with WS1 Web for iOS crashes, Mobile Threat Defense notifications, Trusted Network Detection setup on Windows 10, App Volume writables, VPP application records syncing errors, Horizon connection server challenges, and Workspace ONE Content limitations, we've got you covered. Gain a deeper understanding of these issues, their causes, resolutions, and workarounds, and stay informed about the latest developments in the VMware ecosystem. The post 10 new KB articles created in July 2023 for Workspace ONE, Horizon View, and more!  appeared first on VMware Support Insider.

  • New KB articles created in July 2023 for vSAN.
    by Marcela Gleixner on August 14, 2023 at 5:38 pm

    Stay updated with the latest VMware knowledge base articles released in July 2023. From vSAN performance challenges to storage policy issues and recovery failures, this blog post delves into essential insights that can help you navigate these topics. Whether you're a VMware enthusiast, IT professional, or curious learner, these articles offer valuable solutions and workarounds to keep your virtualized environments running smoothly.  The post New KB articles created in July 2023 for vSAN. appeared first on VMware Support Insider.

  • Top 10 VMware Knowledge Base Articles: Troubleshooting Tips for Redis, RabbitMQ, and GemFire in July, 2023
    by Jamie Gravatte on August 10, 2023 at 4:14 pm

    Tweet Explore the top 10 most popular knowledge base articles for Redis, RabbitMQ, and GemFire. These articles provide valuable insights and solutions to common challenges faced by users of these powerful data management and messaging platforms. From optimizing socket buffer sizes in GemFire to setting up Redis master-slave replication and addressing RabbitMQ queue deletion issues, … Continued The post Top 10 VMware Knowledge Base Articles: Troubleshooting Tips for Redis, RabbitMQ, and GemFire in July, 2023 appeared first on VMware Support Insider.

  • Top 10 VMware Tanzu KB Articles for DevAps for July, 2023
    by Jamie Gravatte on August 9, 2023 at 7:48 pm

    Tweet This blog post highlights the top 10 most popular knowledge articles for DevAps in July. The articles cover a range of topics. Each article provides insights, instructions, and resolutions to common challenges faced by developers and operations teams.  This article explains how to generate a self-signed SSL certificate using the Java keytool command for Apache … Continued The post Top 10 VMware Tanzu KB Articles for DevAps for July, 2023 appeared first on VMware Support Insider.

  • Top 10 KB articles for PostgreSQL, VMware Tanzu Greenplum in July, 2023 
    by Jamie Gravatte on August 9, 2023 at 2:44 pm

    Tweet In the fast-paced world of database management, encountering issues is inevitable. That’s why we’ve compiled a list of the top 10 Knowledge Base (KB) articles that gained popularity in June. These articles serve as valuable resources for database administrators and users alike, offering step-by-step instructions and resolutions for a variety of challenges. By sharing … Continued The post Top 10 KB articles for PostgreSQL, VMware Tanzu Greenplum in July, 2023  appeared first on VMware Support Insider.

  • VMware Skyline Advisor Pro: Diagnostic Findings Are Now Enabled
    by Kelcey Lemon on August 8, 2023 at 11:00 am

    We are pleased to announce new releases of VMware Skyline Collector, version 3.5, and Advisor Pro, that introduce VMware Aria Operations for Logs Diagnostic Findings and new proactive Findings. If you have Auto-Upgrade enabled, your Skyline Collector will automatically update The post VMware Skyline Advisor Pro: Diagnostic Findings Are Now Enabled appeared first on VMware Support Insider.

  • Top 10 most popular Tanzu KB articles in July 2023 for Kubernetes platform. 
    by Jamie Gravatte on August 7, 2023 at 6:09 pm

    Tweet In July, our knowledge base (KB) received significant traction as customers sought solutions to various challenges in Tanzu Kubernetes Grid (TKG). This blog post highlights the most popular KB articles from June, addressing common issues faced by TKG users.   This knowledge base article addresses a known issue with the vSphere CSI driver version … Continued The post Top 10 most popular Tanzu KB articles in July 2023 for Kubernetes platform.  appeared first on VMware Support Insider.

  • Top 10 Most Popular Knowledge Articles for Horizon, WorkspaceONE, End User Computing (EUC), Personal Desktop for July, 2023   
    by Jamie Gravatte on August 4, 2023 at 3:01 pm

    Tweet Get answers and solutions instantly by using VMware’s Knowledge Base (KB) articles to solve known issues. Whether you’re looking to improve your productivity, troubleshoot common issues, or simply learn something new, these most used and most viewed knowledge articles are a great place to start.   Here are the top 5 most viewed KB articles … Continued The post Top 10 Most Popular Knowledge Articles for Horizon, WorkspaceONE, End User Computing (EUC), Personal Desktop for July<strong>, </strong>2023    appeared first on VMware Support Insider.