The Community

Dear support, There is a problem with my devices, they won't load my app. Does this look familiar? How about: A customer reports their remote control connection is unstable, and performance is unreliable. It has been like this for some weeks. Unfortunately these two examples are inspired by some of the many support requests I've observed in the last few weeks alone, with many more examples like this over the years I've been supporting customers and internal teams. Why are these examples of weak support requests? The information provided is just enough to suggest there's a problem, but doesn't offer near enough of what is needed to debug the issue and instead requires the assigned support person, or team, to reach out to gather more information in order to be able to start troubleshooting. In the first example, the support team will know: There's an app More than one device is affected, potentially. It's not confirmed but can be assumed based on the wording and still needs validating. They will not however know: How long it's been happening The app in question (package name, version, recent changes) What policies may be in scope to check for misconfigurations (in case of an EMM-enrolled device) How the app is distributed The devices in question (make/model/OS version) .. and much more contextual information, all of which the support team will be forced to reach out to attain, adding unnecessary back-and-forth before the issue can even be addressed. In the second example, support will know: The customer is using a remote control product It's not a one-time occurrence But won't know: What unreliable means; does the connection fail? Is it slow? Does it drop frequently? Device(s) info (make, model, OS version) Number of devices affected Who the customer(s) is If there are errors shown Steps to replicate the issue locally Environmental information, such as how devices are connecting to the internet .. and more again. Why does this matter? # By choosing to raise tickets similar to the examples above, it is guaranteeing the time to resolution for a problem will be considerably longer, more drawn-out, and require more effort on both ends. For internal teams communicating issues in this way it additionally demonstrates a lack of care and/or respect towards your colleagues' time and workload. The aim of raising a support request is to resolve an issue, whether that's a problem in production, a resource request, or anything else related to a block associated with a product or service at a personal or company level. Likewise, the aim of the support team is to resolve requests as quickly and efficiently as possible; they're supporting many customers and/or end users in most circumstances and having requests sitting unresolved negatively impact SLAs, KPIs, and often reflect poorly on the assigned support team or team member. The goal then for both sides of the request is the same, and one of the most effective ways to ensure a request is resolved with minimal friction is to reduce back-and-forth with support; that doesn't mean pre-empting any possible question a support team member could possibly have, rather it's about putting in more than the minimum effort when raising a request that offers greater insight into the request at hand for a faster resolution, and a win-win for both sides. So in contrast to the above, let's look at suggestions that can improve support requests. The following has a lean on mobility platforms and systems, but can naturally be adapted to other products and solutions Provide information upfront # Here's your basic checklist when raising an issue with support that will substantially reduce the delay to debugging: A concise description of the issue How long it has been happening How many devices are affected Any specific tenant/platform/policy details to identify you How many customers are known to be affected, and customer names (for MSP/internal support) Device identifiers (serial number, IMEI) of affected device(s) support can opt to focus on Device information, make, model, OS version, OS build number. Provide more than one if details aren't consistent across affected devices Affected app information, package name(s), app versions (for app related issues) Replication steps Any scoped policies or configurations applied Logs, pictures, video of issues respectively An example of a support request offering some of the above information - taking the above first example of a submitted issue - could look like this: Dear support, I have this week deployed a new app via MDM, however it is not showing up on my devices. The policy I am using is App deploy 1 and my tenant is Customer tenant 3. The devices targeted are a mixture of Android 11 & 12, I have checked and so far the app is not present on more than 10 devices, including the following IMEIs I have with me: 12345678901234 12345678901235 The application in question is my Package, a private application uploaded to the iFrame. I haven't had this issue with other applications from the Play Store so I'm unsure of why this one is failing. The policy saved fine and the app is showing pending install status. When considering the above, the contrast between the first and second version of this support request is stark. From the revised ticket the support team will know: This is a new issue It's affecting multiple devices, two of which are provided for review The customer environment, policy, and application names are provided for immediate troubleshooting The application is a private app, and is an exception to the norm of public apps being used The EMM is showing the app is assigned, but devices are not installing With the addition of a few sentences and additional contextual information, the support team will have all of the information needed to start immediately troubleshooting, negating the need to ask additional questions, or set up a call for more info. The only thing that would improve the above would be the addition of a bug report, since replication steps and video/image aren't relevant in this instance, though understandably fetching logs from devices may require assistance over a call, or at a minimum a detailed walkthrough. Naturally depending on the type of issue there may be a need for more, or different, information. The remote control issue referenced in the above second example for instance would typically additionally require environmental information, such as: Type of connection used (Wi-Fi, cellular) Connection quality Distance from router for Wi-Fi Inside a building or outside for cellular, signal strength (bars shown, or dBm) Can it be replicated on another network? Can it be replicated with another device? Average session lengths, if successful Replication steps to any reliable session end Are there firewalls in place, or network QoS policies active? Load the device is under normally, as a lower-spec device may struggle casting its screen while performing other activities Are prompts being received? In Kiosk deployments, apps may not be able to display over the locktasked kiosk environment, or the notification bar may be disabled All of this information isn't expected in an opening issue request, but considering any of this for inclusion will significantly help in reducing the back-and-forth required, so as the requestor of a support ticket, the more information you provide upfront, the sooner an issue can be resolved. Be reasonable with urgency # Is your request urgent? But is it really? It's both tempting and commonplace to see relatively minor requests raised as urgent or critical. The saying goes if everything is urgent, nothing is. If all requests carry an urgent or critical priority status, the efficacy of self-set priority will fade fast, and will potentially impact the speed at which your requests are addressed. Is the issue local to just yourself, or not replicable on multiple devices? It's likely not urgent, as it doesn't impact overall business function or productivity. Has a system update taken a store, or region, offline? That'll be urgent, or critical, depending on the defined SLAs in place with the support team. Keep in mind, the priority is not a substitute for poor time management, always aim to raise requests in due time when taking into consideration the SLAs offered by the support team. You probably don't need a call # One of the most common occurrences I've seen in recent years is the requirement from the support requestor to have a call to discuss the requests for further information needed by the support team. Further information being that which aims to obtain the missing information from the request that hasn't been provided upfront. What typically follows is support setting up a call with the requestor wherein the support team simply asks the questions once again through a different medium, and notes down the answers themselves. Obviously there are situations where calls are legitimately seeking assistance in obtaining the requested information (such as how do I find the OS version for the device or how do I collect device logs?) and these are wholly justifiable. But if your intention is to defer the questions asked until they're asked again over a call, this is once more going to significantly delay how quickly your issues can be resolved. Take the time to read the request for information, and offer best-effort answers based on your understanding for each question; even if only half of the questions are answered and a call is needed to cover off the remaining with additional context or explanation, you may have already provided enough information for the issue to be identified and again saved all sides time and effort where it doesn't need to be expended. Timely responses help everyone # If you're raising a support request, be prepared to engage with the support team in a timely manner. From the perspective of the support team, requests raised with little information and extremely slow responses are the worst. Not only can the request not be solved, but the support team is then burdened with adhering to SLAs and non-response processes that mandate multiple follow-ups for information, and this may be triggered multiple times through the lifecycle of a request. By raising a request and then treating it as your lowest priority, everyone suffers. Use the appropriate channels # Support teams may have a process in place for receiving requests through a multitude of channels, however often sending Teams/Slack/GChat messages directly to individual support personnel isn't one of them. It's certainly one of the easiest methods to get the attention of a support team member, but it has the potential to cause issues later. At best, it'll be a distraction, at worst the issue won't be properly logged and tracked, meaning there will be no formal request logged for the issue; this can present as a problem later if the issue requires retrospective review or similar issues exist and the team goes looking to reference. Do both sides a favour, log the request through the company-approved channels, and keep communication there. Go forth and raise better requests # Armed with the above advice, and a little insight from the other side, I trust you'll be able to create support requests both you and the support team you're raising to will benefit from. Just a few small changes to the approach of asking for help will make a world of difference. Good luck!

Dear support, There is a problem with my devices, they won't load my app. Does this look familiar? How about: A customer reports their remote control connection is unstable, and performance is unreliable. It has been like this for some weeks. Unfortunately these two examples are inspired by some of the many support requests I've observed in the last few weeks alone, with many more examples like this over the years I've been supporting customers and internal teams. Why are these examples of weak support requests? The information provided is just enough to suggest there's a problem, but doesn't offer near enough of what is needed to debug the issue and instead requires the assigned support person, or team, to reach out to gather more information in order to be able to start troubleshooting. In the first example, the support team will know: There's an app More than one device is affected, potentially. It's not confirmed but can be assumed based on the wording and still needs validating. They will not however know: How long it's been happening The app in question (package name, version, recent changes) What policies may be in scope to check for misconfigurations (in case of an EMM-enrolled device) How the app is distributed The devices in question (make/model/OS version) .. and much more contextual information, all of which the support team will be forced to reach out to attain, adding unnecessary back-and-forth before the issue can even be addressed. In the second example, support will know: The customer is using a remote control product It's not a one-time occurrence But won't know: What unreliable means; does the connection fail? Is it slow? Does it drop frequently? Device(s) info (make, model, OS version) Number of devices affected Who the customer(s) is If there are errors shown Steps to replicate the issue locally Environmental information, such as how devices are connecting to the internet .. and more again. Why does this matter? # By choosing to raise tickets similar to the examples above, it is guaranteeing the time to resolution for a problem will be considerably longer, more drawn-out, and require more effort on both ends. For internal teams communicating issues in this way it additionally demonstrates a lack of care and/or respect towards your colleagues' time and workload. The aim of raising a support request is to resolve an issue, whether that's a problem in production, a resource request, or anything else related to a block associated with a product or service at a personal or company level. Likewise, the aim of the support team is to resolve requests as quickly and efficiently as possible; they're supporting many customers and/or end users in most circumstances and having requests sitting unresolved negatively impact SLAs, KPIs, and often reflect poorly on the assigned support team or team member. The goal then for both sides of the request is the same, and one of the most effective ways to ensure a request is resolved with minimal friction is to reduce back-and-forth with support; that doesn't mean pre-empting any possible question a support team member could possibly have, rather it's about putting in more than the minimum effort when raising a request that offers greater insight into the request at hand for a faster resolution, and a win-win for both sides. So in contrast to the above, let's look at suggestions that can improve support requests. The following has a lean on mobility platforms and systems, but can naturally be adapted to other products and solutions Provide information upfront # Here's your basic checklist when raising an issue with support that will substantially reduce the delay to debugging: A concise description of the issue How long it has been happening How many devices are affected Any specific tenant/platform/policy details to identify you How many customers are known to be affected, and customer names (for MSP/internal support) Device identifiers (serial number, IMEI) of affected device(s) support can opt to focus on Device information, make, model, OS version, OS build number. Provide more than one if details aren't consistent across affected devices Affected app information, package name(s), app versions (for app related issues) Replication steps Any scoped policies or configurations applied Logs, pictures, video of issues respectively An example of a support request offering some of the above information - taking the above first example of a submitted issue - could look like this: Dear support, I have this week deployed a new app via MDM, however it is not showing up on my devices. The policy I am using is App deploy 1 and my tenant is Customer tenant 3. The devices targeted are a mixture of Android 11 & 12, I have checked and so far the app is not present on more than 10 devices, including the following IMEIs I have with me: 12345678901234 12345678901235 The application in question is my Package, a private application uploaded to the iFrame. I haven't had this issue with other applications from the Play Store so I'm unsure of why this one is failing. The policy saved fine and the app is showing pending install status. When considering the above, the contrast between the first and second version of this support request is stark. From the revised ticket the support team will know: This is a new issue It's affecting multiple devices, two of which are provided for review The customer environment, policy, and application names are provided for immediate troubleshooting The application is a private app, and is an exception to the norm of public apps being used The EMM is showing the app is assigned, but devices are not installing With the addition of a few sentences and additional contextual information, the support team will have all of the information needed to start immediately troubleshooting, negating the need to ask additional questions, or set up a call for more info. The only thing that would improve the above would be the addition of a bug report, since replication steps and video/image aren't relevant in this instance, though understandably fetching logs from devices may require assistance over a call, or at a minimum a detailed walkthrough. Naturally depending on the type of issue there may be a need for more, or different, information. The remote control issue referenced in the above second example for instance would typically additionally require environmental information, such as: Type of connection used (Wi-Fi, cellular) Connection quality Distance from router for Wi-Fi Inside a building or outside for cellular, signal strength (bars shown, or dBm) Can it be replicated on another network? Can it be replicated with another device? Average session lengths, if successful Replication steps to any reliable session end Are there firewalls in place, or network QoS policies active? Load the device is under normally, as a lower-spec device may struggle casting its screen while performing other activities Are prompts being received? In Kiosk deployments, apps may not be able to display over the locktasked kiosk environment, or the notification bar may be disabled All of this information isn't expected in an opening issue request, but considering any of this for inclusion will significantly help in reducing the back-and-forth required, so as the requestor of a support ticket, the more information you provide upfront, the sooner an issue can be resolved. Be reasonable with urgency # Is your request urgent? But is it really? It's both tempting and commonplace to see relatively minor requests raised as urgent or critical. The saying goes if everything is urgent, nothing is. If all requests carry an urgent or critical priority status, the efficacy of self-set priority will fade fast, and will potentially impact the speed at which your requests are addressed. Is the issue local to just yourself, or not replicable on multiple devices? It's likely not urgent, as it doesn't impact overall business function or productivity. Has a system update taken a store, or region, offline? That'll be urgent, or critical, depending on the defined SLAs in place with the support team. Keep in mind, the priority is not a substitute for poor time management, always aim to raise requests in due time when taking into consideration the SLAs offered by the support team. You probably don't need a call # One of the most common occurrences I've seen in recent years is the requirement from the support requestor to have a call to discuss the requests for further information needed by the support team. Further information being that which aims to obtain the missing information from the request that hasn't been provided upfront. What typically follows is support setting up a call with the requestor wherein the support team simply asks the questions once again through a different medium, and notes down the answers themselves. Obviously there are situations where calls are legitimately seeking assistance in obtaining the requested information (such as how do I find the OS version for the device or how do I collect device logs?) and these are wholly justifiable. But if your intention is to defer the questions asked until they're asked again over a call, this is once more going to significantly delay how quickly your issues can be resolved. Take the time to read the request for information, and offer best-effort answers based on your understanding for each question; even if only half of the questions are answered and a call is needed to cover off the remaining with additional context or explanation, you may have already provided enough information for the issue to be identified and again saved all sides time and effort where it doesn't need to be expended. Timely responses help everyone # If you're raising a support request, be prepared to engage with the support team in a timely manner. From the perspective of the support team, requests raised with little information and extremely slow responses are the worst. Not only can the request not be solved, but the support team is then burdened with adhering to SLAs and non-response processes that mandate multiple follow-ups for information, and this may be triggered multiple times through the lifecycle of a request. By raising a request and then treating it as your lowest priority, everyone suffers. Use the appropriate channels # Support teams may have a process in place for receiving requests through a multitude of channels, however often sending Teams/Slack/GChat messages directly to individual support personnel isn't one of them. It's certainly one of the easiest methods to get the attention of a support team member, but it has the potential to cause issues later. At best, it'll be a distraction, at worst the issue won't be properly logged and tracked, meaning there will be no formal request logged for the issue; this can present as a problem later if the issue requires retrospective review or similar issues exist and the team goes looking to reference. Do both sides a favour, log the request through the company-approved channels, and keep communication there. Go forth and raise better requests # Armed with the above advice, and a little insight from the other side, I trust you'll be able to create support requests both you and the support team you're raising to will benefit from. Just a few small changes to the approach of asking for help will make a world of difference. Good luck!

Damien asked, through the Mobile Pros Slack community: We have approx 5000 COPE devices with just over 4000 of them Samsung all managed using WS1 UEM. Should we use e-FOTA? If not what? What about BYOD devices? Our security team is advising us to cut access to those who don’t have a patch of 2 months old. Our minimum version is OS 12 but this would mean cutting the access to quite a few devices whose manufacturer is no longer rolling out patches! I can do this via compliance policies on WS1 but I find this a bit extreme. [..] Jason, not sure if you can weigh in here? 😉 This is such a common question, and rightly so because it's one of those subjects that tends to involve more than one part of the business, with various understandings, opinions, and perceptions on what's secure across the whole mobility estate, not Android alone. Jason says # For your question it's a little varied by use case but most popularly day to day for updates I tend to use the windowed update policy to push app and system updates overnight (or off the clock), and occasionally check in to see if anything is struggling. Not being a Samsung house for the last few years I've not leaned on e-FOTA [recently] but I absolutely would for major update management (or rather, postponement) for testing, since the 90 days AE offers comes with caveats. It has many more features than typical OTA management as well I'm sure you could get used to 🙂 For cutting off, 2 months doesn't even permit the normal 90 day update cycle many OEMs offer. Perhaps over 6 months isn't unreasonable, but a non-supported device should be considered in the context of its supported counterparts. What was patched in 6 months after EOL? Probably nothing critical, possibly nothing overtly vulnerable. OEMs can technically get away with 12 months of SMR from new, and then only patch critical, which may be 10 a year, or none in 3. An arbitrary period of time doesn't make the best sense in that regard particularly for BYOD where your biggest concern is breaching the work personal divide, and any vuln capable of that would be talked about. You'd be ruling out almost brand new devices after just a year - in an extreme example. Instead, I would (and do) monitor CVEs for impacting vulnerabilities and make a call to cut off devices that don't have the associated SMR once available. It's a monthly check but honestly compared to the support burden of arbitrary blocking of devices based on a number plucked from the sky it's my preference. Fully managed estates without the additional protection of profile isolation I err to the side of replacement at EOL. Exceptions exist for this too though, kiosk devices fully locked down with no user access will be inherently less vulnerable than knowledge worker devices; there's a sliding scale of risk to consider based on use case as I mentioned, and that comes down to the risk appetite of the organisation.

Damien asked, through the Mobile Pros Slack community: We have approx 5000 COPE devices with just over 4000 of them Samsung all managed using WS1 UEM. Should we use e-FOTA? If not what? What about BYOD devices? Our security team is advising us to cut access to those who don’t have a patch of 2 months old. Our minimum version is OS 12 but this would mean cutting the access to quite a few devices whose manufacturer is no longer rolling out patches! I can do this via compliance policies on WS1 but I find this a bit extreme. [..] Jason, not sure if you can weigh in here? 😉 This is such a common question, and rightly so because it's one of those subjects that tends to involve more than one part of the business, with various understandings, opinions, and perceptions on what's secure across the whole mobility estate, not Android alone. Jason says # For your question it's a little varied by use case but most popularly day to day for updates I tend to use the windowed update policy to push app and system updates overnight (or off the clock), and occasionally check in to see if anything is struggling. Not being a Samsung house for the last few years I've not leaned on e-FOTA [recently] but I absolutely would for major update management (or rather, postponement) for testing, since the 90 days AE offers comes with caveats. It has many more features than typical OTA management as well I'm sure you could get used to 🙂 For cutting off, 2 months doesn't even permit the normal 90 day update cycle many OEMs offer. Perhaps over 6 months isn't unreasonable, but a non-supported device should be considered in the context of its supported counterparts. What was patched in 6 months after EOL? Probably nothing critical, possibly nothing overtly vulnerable. OEMs can technically get away with 12 months of SMR from new, and then only patch critical, which may be 10 a year, or none in 3. An arbitrary period of time doesn't make the best sense in that regard particularly for BYOD where your biggest concern is breaching the work personal divide, and any vuln capable of that would be talked about. You'd be ruling out almost brand new devices after just a year - in an extreme example. Instead, I would (and do) monitor CVEs for impacting vulnerabilities and make a call to cut off devices that don't have the associated SMR once available. It's a monthly check but honestly compared to the support burden of arbitrary blocking of devices based on a number plucked from the sky it's my preference. Fully managed estates without the additional protection of profile isolation I err to the side of replacement at EOL. Exceptions exist for this too though, kiosk devices fully locked down with no user access will be inherently less vulnerable than knowledge worker devices; there's a sliding scale of risk to consider based on use case as I mentioned, and that comes down to the risk appetite of the organisation.

Google yesterday announced the Pixel 8 series, something I almost missed being wholly occupied with the release of Android 14 and all the new enterprise docs and features that came with it. (You can see what's new here and find my notes on articles and such shared yesterday here). There are plenty of new features exclusive to the model, but the biggest announcement as far as I'm concerned is that of software support. Second only to Fairphone's commitment just a few weeks ago of up to 10 years of support for the Fairphone 5, Google as one of the larger OEMs on the market has come very close with a commitment of 7 years, both major OS and security patch support is guaranteed here, meaning the Pixel 8 should find its way up to Android 20/21 by 2030. Today we announced our commitment to providing seven years of software support for Pixel 8 and Pixel 8 Pro, including Android OS upgrades, security updates and regular Feature Drops. That means your Pixel 8 and Pixel 8 Pro will be supported all the way into 2030. - Google The announcement post is not quite explicit enough as the above quote could be later construed to mean a mix of both OS and security patches, allowing Google to stop at Android 18 if desired given each major release benefits from CVE backporting for 3 years (as it stands in 2023, at least), however with further digging their own documentation offers a black-and-white commitment of both OS updates and security updates until 2030: Phone Guaranteed Android version updates until at least: Guaranteed security updates until at least: Pixel 8 & Pixel 8 Pro October 2030 October 2030 Pixel Fold June 26, 2026 June 25, 2028 Pixel 7a May 8, 2026 May 7, 2028 Pixel 7 & Pixel 7 Pro October 2025 October 2027 As you may notice from the above, this is a reasonable increase in support over previous devices, including the just-released Fold. This achievement looks to be linked to the new Tensor G3. Tensor, Google's in-house chip, offers them end-to-end control over the hardware they ship, and the support they provide. This is in contrast to many OEMs on the market reliant on the likes of Qualcomm and MediaTek, vendors with many chipsets available and little financial incentive to offer extended support on most of them (exceptions to this exist, see again Fairphone's use of the QCM6490).