New policy implementation and web enrollment for Android personally owned work profile
We’re happy to announce two improvements for the management of Android personally owned work profile devices with Microsoft Intune. A new implementation for how Intune delivers policies to devices Web based enrollment These updates modernize how Microsoft Intune manages devices and improves the enrollment flow. Action may be required by you as we move to the new implementation. Keep reading to understand what’s changing, actions, and timelines you need to know. What’s changing New implementation We’re finalizing our work on moving the Android personally owned work profile implementation to the latest and greatest available – Google’s Android Management API (AMAPI). It has been almost a decade since Intune released support for Android personally owned work profile management. At that time, we accomplished this by building a custom device policy controller (DPC), in the form of the Intune Company Portal app. A lot has changed since then. Google released AMAPI and its companion app, Android Device Policy, which enforces AMAPI policy on devices. This is now Google’s recommended implementation, which we used to deliver the three corporate Android Enterprise management methods: corporate owned work profile, fully managed, and dedicated. Google no longer recommends use of custom DPCs and they’re deprecating associated functionality. The benefits of moving personally owned work profile management to AMAPI include: Faster release of new features across all four Android Enterprise management options. Consistent behaviors across all four Android Enterprise management options. The Microsoft Intune app will replace the Company Portal app as the user app (to manage devices, contact their IT department, collect logs, and more), providing an updated user experience and aligning it with the corporate Android Enterprise management options. Enables Intune to support the latest Android platform management capabilities, which are unavailable with custom DPC implementations. Web based enrollment The move to AMAPI also enables us to build a web-based enrollment flow for personally owned work profile devices, similar to web based device enrollment for iOS. The benefits of this include: Users don’t need to manually install an app to start Intune enrollment since they can start enrollment from a webpage instead. Users can access enrollment from any of the three different entry points which all launch the same webpage: A URL (new!) Productivity apps (when admin has configured conditional access so that the user is required to enroll before accessing corporate resources) The Company Portal app This gives you more options for how to guide your users to get set up. 3. Android enrollment is more consistent with the iOS web-based enrollment flow. How to configure and monitor Web based enrollment We will release a new setting that will allow you to switch your tenant to the new web-based enrollment for all personally owned work profile enrollments going forward. We recommend that you configure this in a test tenant first, try out and document the user flow, and prepare your helpdesks accordingly before opting in on your main tenant. Once you opt in, there isn’t an option to opt out. Later on, we’ll automatically configure all personally owned work profile enrollments across all tenants to be web enrollments. New implementation We’ll release a new configuration policy that allows you to migrate device groups to the new implementation. As a best practice, we encourage admins to evaluate migrating a smaller device set before migrating all devices. Before moving devices to the new implementation, you may want to email users or configure custom notifications to inform them of what to expect. Later on, Intune will automatically migrate all remaining devices using the custom DPC implementation over to the new AMAPI implementation. Monitoring There’ll be a new report that will show how many personally owned work profile devices are in each of the following states: On AMAPI Not targeted to move to AMAPI Targeted to move and pending completion (since it may roll out over some time) Attempted to move and hit an error (and why) How this will affect your users Web based enrollment After you opt in to web based enrollment or later after it’s changed to the default, all devices (on all Android OS versions) will enroll with the web based flow. These devices will be managed with AMAPI. After enrollment, Intune will install a few apps automatically to ensure streamlined management. Microsoft Intune: User-facing app to manage devices, contact the IT department, collect diagnostic logs, and more. Company Portal: For mobile app management (MAM). Android Device Policy: To enforce AMAPI policies. This app is installed in a “hidden” state, so users won't see it in their app list. Microsoft Authenticator: To provide single sign on for users’ work account. Below is an example of the web based enrollment flow that a user would see if they needed to set a PIN on their device to meet admin requirements. New implementation When a device is moved to the new implementation (either through admin configuration or the later automatic move), devices won’t unenroll and users won’t lose access to corporate resources. Moving enrolled devices to the new implementation will be supported on any device running supported Android OS versions for user-based management methods at that time. The changes on the device will be: The Microsoft Intune app will install, and it will be the app for users to interact with instead the Company Portal. Users will not see a notification about this app installing. The Android Device Policy app will install to enforce policies. Users will not see a notification about this app installing and it will be in a “hidden” state on their device. If a device connected to corporate Wi-Fi with username and password authentication, when they move to AMAPI, they will lose access to corporate Wi-Fi until they sign in to the corporate Wi-Fi again. To avoid any potential disruption, we encourage you to move to certificate Wi-Fi authentication instead (as mentioned below). Timeline We'll update these timelines to provide more specific timeframes in the coming months. 2025: Use this time to revise any relevant policy configurations, update your internal documentation, and prepare your helpdesk teams, as advised below. First quarter of calendar year 2026: Enrollment: You’ll be able to opt in for all enrollments of personally owned work profile devices to be web based enrollments on AMAPI. New implementation: You’ll be able to set a configuration policy to migrate groups of previously enrolled devices over to AMAPI. Later on: Enrollment: All enrollments (regardless of past configuration) will be web enrollments for devices running all Android OS versions. New implementation: All devices still on the custom DPC implementation and running supported Android OS versions for user-based management methods at that time will be automatically moved over to AM API. You will receive advanced notice of when these changes will be applying to your tenant. How to prepare We recommend you make these changes to prepare for the upcoming release and provide the most streamlined experience for users. Replace custom policies: Intune ended support for custom configuration polices for personally owned work profile devices in April 2025. Custom policies are not supported in the new implementation. Replace all custom policies with equivalent policies using this setting mapping. Certificate authentication for Wi-Fi: If you’re using username and password authentication for Wi-Fi policies, we strongly encourage you to move to certificate authentication instead. Devices that are connected to corporate Wi-Fi with username and password authentication will lose access to corporate Wi-Fi when they are moved to AMAPI until the user signs into the corporate Wi-Fi network again. Devices using certificate authentication for Wi-Fi won’t lose access, and it’s also a more secure authentication method. Evaluate biometric configuration: Devices on the new implementation won’t apply polices that prevent users from using face, fingerprint, iris, or trust agent to unlock their device. However, policies that prevent this at the work profile level are still supported. If you have this configured at the device level, consider blocking face, fingerprint, iris, and trust agents at the work profile level to protect work resources in an equivalent way. Review enrollment restrictions: In enrollment restrictions (also referred to as device platform restrictions) the “Android Enterprise (work profile)” restriction for personally owned work profile devices has a setting to Allow or Block “Personally owned” devices. This configuration will not apply to devices on AMAPI and the setting will be removed from the Intune admin center when all devices are moved to AMAPI. As communicated in the Intune Android 12 blog, this setting does not work reliably on devices running Android 12 and later. Conceptually, personally owned work profile management is meant for personal devices, so blocking personal devices from enrolling and only allowing corporate devices isn’t recommended. If you currently have the “Personally owned” setting set to Block for personal work profile devices, you should plan an alternate way for blocking these devices. Options include using a corporate management method instead (such as corporate owned work profile) or configuring the personal work profile enrollment restriction to block enrollments for all users except for users in a specified group. Update Android OS: Intune currently supports Android 10 and later on personally owned work profile devices. We recommend you guide users to update to their device’s latest supported Android version for the best experience. Helpdesk preparation: Inform your helpdesk teams of these coming changes so they know what to expect. For devices on the new implementation, diagnostic logs will be collected using the Microsoft Intune app (instead of the Company Portal app). Plan to update any user instructions you have after you try out the web based enrollment flow. iOS web based enrollment: We recommend you consider setting up web based device enrollment for iOS now or when we release Android web based enrollment for a more consistent and improved user experience. Changes to be aware of A few defaults will change as part of the move to the new implementation. Required app installation behavior: In the custom DPC implementation, users can uninstall required apps, and then they are reinstalled automatically within a few hours. In the new implementation, users won’t be able to uninstall required apps from their device, which is the same experience as on corporate Android Enterprise devices. Caller ID and contact search: In the custom DPC implementation, the settings to “Display work contact caller-id in personal profile” and “Search work contacts from personal profile” are two independent settings. In AMAPI, they are controlled with a single setting. If you have blocked either, Intune will automatically block both for devices on the new implementation. Intune will update the policy user interface to have a single setting once all devices are on the new implementation. Screen timeout: In the custom DPC implementation, you can configure screen timeouts either for the full device or for the work profile under “Maximum minutes of inactivity until work profile locks.” In AMAPI, you can only configure this at the work profile level. Intune will set this to the lesser of the two when devices move to the new implementation. We will remove the device level setting from policies when all devices are on AMAPI. Password: There will be some minor changes to how some configurations of password requirements apply on some devices. We will update to provide more information and guidance. Stay tuned to this blog for updates! If you have any questions or feedback on this change, leave a comment on this post or reach out on X @IntuneSuppTeam. Post updates 02/19/25: Updated the Timeline and How this will affect your users + New Implementations sections. 04/08/25: Updated these sections: How to configure and monitor, How this will affect your users, Timeline, How to prepare, and Changes to be aware of. 04/09/25: Updated the Changes to be aware of section to include details about TeamViewer supportability. 08/22/25: Added images and updated all sections with the latest information, including an updated Timeline section and removing the information about the delay to TeamViewer support.
Microsoft Intune Company Portal for Linux and Conditional Access Issue
Greetings everyone, I have the following scenario implemented regarding conditional access: Rule#1: For pilotuser1, for all cloud apps, for all platforms --> require MFA Rule#2: For pilotuser1, for all cloud apps except Microsoft Intune Enrollment and Microsoft Intune, for all platforms --> Require Device marked as compliant This should allow me to enroll to Intune successfully a non-enrolled device and require the device compliance for the other workloads. For Windows it works just fine. The problem lies with Linux. Following the instructions on Enroll a Linux device in Intune | Microsoft Learn & Get the Microsoft Intune app for Linux | Microsoft Learn I installed Intune App and Edge (Version 109.0.1518.52 (Official build) (64-bit)) on a VM with Ubuntu 22.04. I open the Intune App and try to sign in: First step is to Register the Device on Azure AD, it goes without a problem --> On the next stage I get the following and press continue: At this stage Microsoft Edge opens and I sign in successfully but the Intune App throws an error: The sign in logs on Azure AD show that even though I excluded Intune Enrollment from the CA policy, it is not enough. Sign-in error code: 530003 Failure reason: Your device is required to be managed to access this resource. Additional Details: The requested resource can only be accessed using a compliant device. The user is either using a device not managed by a Mobile-Device-Management (MDM) agent like Intune, or it's using an application that doesn't support device authentication. The user could enroll their devices with an approved MDM provider, or use a different app to sign in, or find the app vendor and ask them to update their app. More details available at https://docs.microsoft.com/azure/active-directory/active-directory-conditional-access-device-remediation Application: Microsoft Intune Company Portal for Linux Application ID: b743a22d-6705-4147-8670-d92fa515ee2b Resource : Microsoft Graph Resource ID: 00000003-0000-0000-c000-000000000000 Client app: Mobile Apps and Desktop clients Client credential type: None Resource service principal ID: 01989347-a263-48ef-a8d7-583ee83db9a2 Token issuer type: Azure AD Apparently something is different in the enrollment process of Linux because I had no issues with Windows 10 enrollment . Any thoughts on the subject would be appreciated. Kind Regards, PanosUnderstanding Apple enrollment methods in Microsoft Intune
By: Rishita Sarin – Product Manager | Microsoft Intune Microsoft Intune, together with Microsoft Entra ID, facilitates a secure, streamlined process for registering and enrolling devices to access your organization’s resources. Once users and devices are registered within your Microsoft Entra ID (also called a tenant), then you can utilize Intune for its endpoint management capabilities. The process that enables device management for a device is called device enrollment. During enrollment, Intune installs a mobile device management (MDM) certificate on the enrolling device. The MDM certificate communicates with the Intune service, and enables Intune to start enforcing your organization's policies, like: Enrollment policies that limit the number or type of devices someone can enroll. Compliance policies that help users and devices meet your organization’s requirements. Configuration profiles that configure work-appropriate features and settings on devices. This blog aims to provide an overview of Microsoft Intune’s enrollment methods for Apple devices to help you make informed decisions about device management. Enrollment methods Personal owned devices (BYOD) To get started with enrolling personally owned devices navigate to the Intune admin center, Devices > Enrollment > Apple > Enrollment types > Create. Apple’s name since 2019 Intune’s name When to use it Profile-based Device Enrollment (Previously known as User Enrollment) Device enrollment with Company Portal Secures entire personal device. Supports app takeover. Web enrollment Secures entire personal device. Supports app takeover. We recommend enabling web-based enrollment for devices running iOS/iPadOS 15 and later because it doesn't require employees and students to install the Company Portal app. Post-enrollment functionality remains the same as with app-based enrollment. Profile-based User Enrollment (Support ended in 2024) User enrollment with Company Portal (Support ended in 2024) Do not use this (Support ended in 2024) Account-driven User Enrollment Account-driven user enrollment Secures only work-related apps on a personal device. No support for app takeover. Account-driven Device Enrollment Not supported Not supported N/A Determine based on user choice Gives users the option to select if they want to secure their entire device or only work-related apps. Corporate owned devices Devices > Enrollment > Apple > Enrollment program tokens > select a token > Enrollment policies > Create Apple’s name since 2019 Intune’s name When to use it Automated Device Enrollment (ADE) (Previously known as Device Enrollment Program (DEP)) Automated Device Enrollment (ADE) for iOS/iPadOS Automated Device Enrollment (ADE) for macOS Secures entire corporate device. Enroll with User Affinity: Select this option for devices that belong to users who want to use the Company Portal for services like installing apps. Enroll without User Affinity: Select this option for devices that aren't affiliated with a single user. Use this option for devices that don't access local user data. This option is typically used for kiosk, point of sale (POS), or shared-utility devices. Enroll with Microsoft Entra ID shared mode (only iOS/iPadOS): Select this option to enroll devices that will be in shared mode. 💡 Tip: If you’re enrolling Apple devices for frontline worker scenarios, make sure to check out this detailed guide: Get started with iOS/iPadOS frontline worker devices. Improvements Based on customer feedback, Intune introduced a faster and more intuitive version of device enrollment with the Intune Company Portal called web enrollment in 2023. Web enrollment retains all the benefits of device enrollment with added benefits of reduced latency and without requiring installation of the Company Portal app. We strongly encourage you to take advantage of web enrollment for a faster and more efficient enrollment process for your users. Additionally, turning on just-in-time (JIT) registration and compliance remediation (automatically set up as part of JIT registration setup) for all iOS/iPadOS enrollments can significantly improve the registration and compliance remediation experience. By bringing the enrollment experience to where the user is, we help them get productive faster and ensure a smoother transition. This applies to both iOS/iPadOS bring-your-own-device (BYOD) web enrollment and corporate Automated Device Enrollment (ADE), specifically for Setup Assistant with modern authentication within ADE. For more information on JIT registration and compliance remediation, check out this blog post: Use JIT registration and JIT compliance remediation for all your iOS/iPadOS enrollments. As a result of recent enhancements to our enrollment workflows, the Company Portal app is no longer required for some enrollment methods. However, we recognize the use cases for the Company Portal go beyond enrollment, and we’ll continue to support and invest in improvements for the app. One example of upcoming improvements to the Company Portal is the addition of the user-less app catalog. This enhancement opens the doors for future frontline worker (FLW) scenarios, allowing for more flexible and efficient device management without the need for user-specific configurations. Stay tuned to What’s new in Intune for the release and more! If you have any questions or want to share how you’re using Apple enrollment across your organization in Intune, leave a comment below or reach out to us on X @IntuneSuppTeam or @MSIntune. You can also connect with us on LinkedIn: aka.ms/IntuneLinked.
Android Devices Not Evaluating
Hi All! I seem to encounter this kind of error several times a year for no apparent reason. It mainly happens on the Android side of things on newly created setups, and then corrects itself over time, which sometimes can be weeks. I recently created two Android dedicated device environments. Dynamic group linked to the enrolment profile name, etc etc I scan the device and follow the normal process, device get all the way to the end but doesn't receive its assigned apps. When I check in the Intune Admin Portal, the device is showing as not evaluated. There is no default compliance policy showing and its custom policy. When I click on Managed Apps, the list of apps the device is going to receive are showing as pending install. The Group Membership tab shows the correct dynamic group. So for me, the setup looks good. I have left the device for 24 & 48 hours in case its a sync issue. Enrolled the device via a different WiFi. Wiped the device and left it 24 hours before enrolling it. Checked spelling of groups etc. Anyone else experienced this issue, and found a solution? I have a Teams Meeting with our external support tomorrow, Have a good oneAutoPilot Profile ???
Hi All I hope you are well. Anyway, it has came to my attention that some of inexperienced Intune admins are using the AutoPilot Hardware Scripts at the OOBE screen. No issue there. However, they are NOT checking that the devices actually sync to Intune > Devices > Enrollment > Devices Furthermore, they then proceed with the OOBE enrollment WITHOUT waiting for an AutoPilot to be assigned. The result is that devices never appear in: Intune > Devices > Enrollment > Devices No AutoPilot profile is assigned Is there any way to avoid this? Info appreciated SK
macOS enrollment - prompt to change the Mac login password
Cheers everyone! We are in the pilot phase of our macOS Intune enrollment and I've created the compliance policy which blocks simple passwords and applied this to a few test machines. After the 1st reboot I got a prompt to change the Admin password to meet the requirements. All worked fine until I've changed the "Maximum minutes of inactivity before password is required". After the first reboot, both local admin accounts (one, the IT admin, the 2nd of the actual user) get again a prompt that in order to login the password needs to be changed. Did the changes again and the story repeats itself after changing some other parameter (not something related to the actual password complexity) and ended up in the same loop. It looks like everytime I edit something in the Compliance profile, the user will be prompted to change his password, which doesn't make sense to me. Does anyone know why this is happening and how this behaviour can be changed? I don't want to enable "simple passwords" as just a workaround. Thank you in advance! 🙂Cloud-native Windows endpoints: Begin by beginning
By: Jason Sandys – Principal Product Manager | Microsoft Intune Cloud-native is Microsoft’s goal for all commercial Windows endpoints. By definition, a cloud-native Windows endpoint is joined to Microsoft Entra ID and enrolled in Microsoft Intune. It represents and involves a clean break from on-premises related systems, limitations, and dependencies for device identity and management. This clean break from on-premises dependencies might align with larger organizational goals to reduce or eliminate on-premises infrastructure but doesn’t prevent users from accessing or using existing on-premises resources like file shares, printers, or applications. Cloud-native for Windows endpoints is a large change in thinking for most organizations and thus poses an initial challenge of how to even begin on this journey. This article provides you with guidance on how to begin and how to embrace this new model. For additional guidance that includes a higher-level discussion of what to do with existing endpoints, see: Best practices in moving to cloud native endpoint management | Microsoft 365 Blog to learn more. Proof of concept The first step is to begin with a proof of concept (POC). For any new technology, methodology, or solution, POCs offer numerous advantages. Specifically, they enable you to evaluate the new “thing” with minimal risk while building your skills and gaining stakeholder buy-in. Because the exact end state of Windows endpoints is highly variable among organizations and even within an organization, a POC for cloud-native Windows enables you to take an iterative approach for defining and deploying these endpoints. This iterative approach involves smaller waves of users and endpoints within your organization. It’s ultimately up to you to define which endpoints or users should be in each wave, but you should align this to your endpoint lifecycle and refresh plan. Aligning to your endpoint lifecycle allows you to minimize impact to your users by consolidating the delivery of new endpoints with the changeover from hybrid join to Microsoft Entra join, which requires a Windows reset or fresh Windows instance. Additional significant criteria to consider for which users and endpoints to include in each wave are the organizational user personas and endpoint roles. An iterative POC enables you to break work effort and challenges into more manageable pieces and address them individually or sequentially. This is important since some (often many) challenges related to adopting cloud-native Windows endpoints are isolated or not applicable to all endpoints or users in the organization. Some challenges may even remain unknown until they arise, and the only way to learn about them is by conducting actual production testing and evaluation. You don’t need to address or solve every challenge to successfully begin your journey to cloud-native Windows endpoints. An easy example for this is users that exclusively use SaaS applications: these users’ endpoints already have limited (if any) true on-premises service or application dependencies, and they likely face few, if any, challenges in moving to cloud-native Windows endpoints. Initial cloud-native Windows configuration There are some common activities that need to occur before you deploy your first cloud-native Windows endpoints. Keep in mind that this list is simply the steps to begin the iterative process, it’s not all-inclusive or representative of the final state. For a detailed walkthrough on configuring these items (and more), see the following detailed tutorial: Get started with cloud-native Windows endpoints. Identify the user personas and endpoint types within your organization. These typically vary among organizations, so there’s no standard template to follow. However, you should align your POC to these personas and endpoint types to limit each wave’s impact and scope of necessary change. Configure your baseline policies. Implement a minimum viable set of policies within Intune to deploy to all endpoints. Base these policies on your organizational requirements rather than what has been previously implemented in group policy (or elsewhere). We strongly suggest starting as cleanly as possible with this activity and initially including only what is necessary to meet the security requirements of your organization. Configure Windows Autopatch. Keeping Windows up to date is critical, and Windows Autopatch offers the best path to doing this (whether a Windows endpoint is cloud-native or not). Configure Windows applications. As with policies, this should be a minimal set of applications to deploy to your POC endpoints and can include Win32 based and Microsoft Store based applications. Configure Windows Autopilot. Windows Autopilot enables quick and seamless Windows provisioning without the overhead of classic on-premises OS deployment methods. With Windows Autopilot, the provisioning process for cloud-native Windows endpoints is quick and easy. Configure Delivery Optimization. Windows uses Delivery Optimization for downloading most items from the cloud. By default, Delivery Optimization leverages peers to cache and download content locally. Edit the default configuration to define which managed endpoints are peers or to disable peer content sharing. Enable Windows Hello for Business and enforce multi-factor authentication (MFA) using Conditional Access. Enable Cloud Kerberos Trust for Windows Hello for Business to enable seamless access to on-premises resources. These items significantly increase your organization’s security posture and place your organization well on the Zero Trust path. As the iterative POC process evolves to include more user personas and endpoint roles, you can add more functional policy requirements and applications. This will involve some discovery as you learn about the actual needs of these various personas and roles. Since you aren’t targeting everything from day one, you don’t need to have all requirements defined up front or solutions for every potential issue. Additional suggestions, tips, and guidance Don’t assume something does or doesn’t work on cloud-native Windows endpoints. The POC process enables you to iteratively test and evaluate applications, services, resources, and everything else in your environment – most of which isn’t typically documented. It might simply be part of the tacit or tribal knowledge within your organization. In general, you’ll find that nearly everything works just as it did before Windows cloud-native. Document everything. As you implement, document the “what” as well as the “why” for everything you configure. This allows you and your colleagues to come back at any time and understand or refresh your memory for your cloud-native Windows implementation, as well as many other things in the environment. Microsoft doesn’t expect organizations to rapidly convert their entire estate of Windows endpoints to cloud-native. Instead, we recommend taking it slow, being deliberate, and using the iterative approach outlined above by aligning to your hardware refresh cycle to minimize impact on users. This also provides you with time to prove the solution, address gaps, and overcome challenges as you discover them without disrupting productivity. Use the built-in Conditional Access policy templates to quickly get started with MFA and other Conditional Access capabilities. The templates enable you to implement Conditional Access policies that align with our recommendations without experimentation. Accessing on-premises resources including file shares from a cloud-native Windows endpoint works with little to no configuration. Refer to the documentation for more details: How SSO to on-premises resources works on Microsoft Entra joined devices. Call to action Begin exploring your cloud-native Windows POC today. Taking this first step now will allow your organization to start reaping the benefits of enhanced security, streamlined management, and improved user experience sooner. Every organization is unique, so there’s no blueprint for comprehensively implementing cloud-native Windows. However, you don’t need a comprehensive blueprint to be successful, you just need to begin and slowly expand adoption throughout your organization when and where it makes sense. The guidance provided above along with the getting started tutorial should give you the information, tools, and confidence to move forward with decoupling your endpoints and users from your on-premises anchors and fully embrace cloud-native Windows. For a more detailed and in-depth discussion on adopting cloud-native Windows, including planning and execution, see Learn more about cloud-native endpoints. If you have any questions, leave a comment below or reach out to us on X @IntuneSuppTeam. Additional Blogs 3 benefits of going cloud native | Microsoft 365 Blog How to achieve cloud-native endpoint management with Microsoft Intune | Microsoft 365 Blog Myths and misconceptions: Windows 11 and cloud native | Windows IT Pro Blog (microsoft.com)
Partner enrollment issue - Duplicate Legal Entity
Greetings, I'm trying to enroll to the Microsoft Partner Program (CSP) and I've previously worked with the partner center. Because of this, some time long ago my company was registered with Microsoft. When I'm trying to register again now, I recieve an error message "Exception while creating legal entity : Duplicate Legal Entity" in the company information part of the enrollment process. Now I thought I could just contact Microsoft, verify myself as the owner of the company and have this sorted. That would be IF Microsoft had made it possible for themselves to be contacted. "Just raise a ticket via the partner center". Cant create a workspace, dont have a workspace, therefore cant create ticket with support. Has anyone else had issues with the same? Kind of in a dead lock here and Microsoft doesn't have any contact point unless you're already a partner, it seems...How to resync deleted Intune device by Clean-Up Rules?
Hi Guys, I set up the Clean-Up Rules on Intune to delete devices after 60 days. Now, I have a notebook that has been off for over 4 months and I no longer see it on Intune but it is on Entra and Autopilot. How can I bring it back as Intune managed? I read some articles that talk about clean Enrollments regedit keys and run some powershell commands but what is the correct procedure? Thank you so much. Luca
There is light at the end of the tunnel - be persistent in securing your verification
Good morning everyone, If you read my previous post and the unfortunate response I received from Jill, you might thing that my situation was hopeless. Her response was basically telling me it was never going to happen. For some reason, the post was then immediately locked and no further discussion was allowed. I I did not let that deter me. I opened yet another support ticket. This time providing them with all the same information and a plea to please contact me for anything that they needed to verify that I was who I said I was. While waiting over a week for support to provide any assistance, I can across a similar situation with HPE and their partner program. They were more open about the issues than Microsoft had been. It would seem that the verification with them failed as well. The reason for this is that I had not secured a DUNS number for the business. This is a free number you can get simply by applying. US or Canada. I was left wondering if that is what Microsoft was also using for business verification. I may never know the answer, but my persistence paid off. As of an hour ago, I am now a verified Microsoft Partner. 3 weeks, 2 support tickets, unlimited frustration, and a dash of perseverance was the correct recipe for my success. Good luck everyone!
