DavidFainshtein
Members-
Posts
11 -
Joined
-
Last visited
-
Days Won
1
DavidFainshtein last won the day on June 28 2021
DavidFainshtein had the most liked content!
About DavidFainshtein
-
Rank
Newbie
Profile Information
-
Location
Israel
Recent Profile Visitors
The recent visitors block is disabled and is not being shown to other users.
-
I hope you are right and it's a bug, but according to the documentation I linked to in my post, it's not a bug, it's a feature 😁. Google want 3rd party MDM/EMM providers to relay on Google's in-house DPC (Device Policy Controller). For this reason they no longer accepting new DPC registration requests, and want's you to use Android Managed API.
-
Hi. I want to raise an issue that for some reason didn't get the attention it most needed. I want to talk about the changes Google made in Android 12 that makes impossible to enroll Android 12 devices to ESET PROTECT, using Device Owner mode. from now on we can only enroll new devices as Device Admin, not Device Owner. That means that ESET can no longer provide enterprise-owned devices with such protections as USB file transfer blocking and much, much more! In Android 12, google moved from the "Google Play EMM API" to newer "Android Managed API" https://developers.google.com/android/work/play/emm-api/register In the new version, a key elements were deprecated, such as ACTION_PROVISION_MANAGED_DEVICE. https://source.android.com/devices/tech/admin/provision DPC developers that want to support QR code or other provisioning methods must implement handlers for the DevicePolicyManager#ACTION_GET_PROVISIONING_MODE and DevicePolicyManager#ACTION_ADMIN_POLICY_COMPLIANCE intent actions. If the DPC doesn't implement these handlers, provisioning will fail. https://developer.android.com/work/dpc/build-dpc That means that if ESET wont take action ASAP and move to the newer DPC model, we'll have to look elsewhere for fully functional MDM/EMM solution. I hope to hear from ESET about this matter.
-
Hi. Here is a problem: I have an ESET PROTECT server on physical hardware running Windows Server 2012 R2. The time had came to upgrade the server. I've made an P2V conversion of the server and put it on Hyper-V. Then I've made an inpalce upgrade of the Windows Server 2012 R2 to Windows Server 2019. After that I've shut down the old physical server, and brought online the new VM. after dealing with some minor problems, such as Apache Tomcat service had to be re-registered, the ESET PROTECT server appears to function normally, the endpoint communicating with the server and so on. The only issue is mobile devices. Although I can push a wakeup requests to the devices, can lock/unlock them, request for configurations, location etc., and it's all works fine. But the "Last Connected" timestamp stuck on the date before the server replacement and not changing. If I'm shutting down the new server and starting up the old one - the devices communicating with him instantly. Obviously I've checked the communication part (IP address, external and internal remains the same, of course), Firewall rules etc. Any ideas?
-
Hi. Here is a problem: I have an ESET PROTECT server on physical hardware running Windows Server 2012 R2. The time had came to upgrade the server. I've made an P2V conversion of the server and put it on Hyper-V. Then I've made an inpalce upgrade of the Windows Server 2012 R2 to Windows Server 2019. After that I've shut down the old physical server, and brought online the new VM. after dealing with some minor problems, such as Apache Tomcat service had to be re-registered, the ESET PROTECT server appears to function normally, the endpoint communicating with the server and so on. The only issue is mobile devices. Although I can push a wakeup requests to the devices, can lock/unlock them, request for configurations, location etc., and it's all works fine. But the "Last Connected" timestamp stuck on the date before the server replacement and not changing. If I'm shutting down the new server and starting up the old one - the devices communicating with him instantly. Obviously I've checked the communication part (IP address, external and internal remains the same, of course), Firewall rules etc. Any ideas?
-
Upgrade after upgrade after upgrade
DavidFainshtein replied to DavidFainshtein's topic in ESET Endpoint Products
Following -
Upgrade after upgrade after upgrade
DavidFainshtein replied to DavidFainshtein's topic in ESET Endpoint Products
EXACTLY!!! -
karlisi reacted to a post in a topic: Upgrade after upgrade after upgrade
-
Dusan reacted to a post in a topic: Upgrade after upgrade after upgrade
-
Tell me, Eset - are you insane? A few days ago you released version 8.0.2039 . We started a rollout for a few thousand endpoints and now you releasing 8.1.2031??