by Contributed | Nov 18, 2020 | Azure, Microsoft, Technology
This article is contributed. See the original author and article here.
This week, Tiberiu Radu (Azure Stack Hub PM @rctibi) and I, had the chance to speak to Azure Stack Hub Partner Cloud Assert. Cloud Assert is an Azure Stack Hub partner that helps provide value to both Enterprises and Service Providers. Their solutions cover aspects from billing and approvals all the way to multi-Azure Stack Hub stamp management. Join the Cloud Assert team as we explore the many ways their solutions provide value and help Service Providers and Enterprises in their journey with Azure Stack Hub.
They have several solutions for customers and partners like Azure Stack Hub Multi-Stamp management. Azure Stack Hub Multi-Stamp management enables you to manage and take actions across multiple stamp instances from a single Azure Stack Hub portal with one-pane of glass experience. It provides a holistic way for operators and administrators to perform many of their scenarios from a single portal without switching between various stamp portals. This is a comprehensive solution from Cloud Assert leveraging Cloud Assert VConnect and Usage and billing resource providers for Azure Stack Hub.
We created this new Azure Stack Hub Partner solution video series to show how our customers and partners use Azure Stack Hub in their Hybrid Cloud environment. In this series, as we will meet customers that are deploying Azure Stack Hub for their own internal departments, partners that run managed services on behalf of their customers, and a wide range of in-between as we look at how our various partners are using Azure Stack Hub to bring the power of the cloud on-premises.
Links mentioned through the video:
I hope this video was helpful and you enjoyed watching it. If you have any questions, feel free to leave a comment below. If you want to learn more about the Microsoft Azure Stack portfolio, check out my blog post.
by Contributed | Nov 17, 2020 | Azure, Microsoft, Technology
This article is contributed. See the original author and article here.
Final Update: Wednesday, 18 November 2020 01:36 UTC
We’ve confirmed that all systems are back to normal with no customer impact as of 11/18, 01:15 UTC. Our logs show the incident started on 11/18, 00:20 UTC and that during the 55 minutes that it took to resolve the issue some customers might have experienced issues with missed or delayed Log Search Alerts or experienced difficulties accessing data for resources hosted in West US2 and North Europe.
- Root Cause: The failure was due to an issue in one of our backend services.
- Incident Timeline: 55 minutes – 11/18, 00:20 UTC through 11/18, 01:15 UTC
We understand that customers rely on Azure Log Analytics as a critical service and apologize for any impact this incident caused.
-Saika
by Contributed | Nov 17, 2020 | Azure, Microsoft, Technology
This article is contributed. See the original author and article here.
As customers progress and mature in managing Azure Policy definitions and assignments, we have found it important to ease the management of these artifacts at scale. Azure Policy as code embodies this idea and focuses on managing the lifecycle of definitions and assignments in a repeatable and controlled manner. New integrations between GitHub and Azure Policy allow customers to better manage policy definitions and assignments using an “as code” approach.
More information on Azure Policy as Code workflows here.
Export Azure Policy Definitions and Assignments to GitHub directly from the Azure Portal
Screenshot of Azure Policy definition view blade from the Azure Portal with a red box highlighting the Export definitions button
The Azure Policy as Code and GitHub integration begins with the export function; the ability to export policy definitions and assignments from the Azure Portal to GitHub repositories. Now available in the definitions view, the export definition button will allow you to select your GitHub repository, branch, directory then instruct you to select the policy definitions and assignments you wish to export. After exporting, the selected artifacts will be exported to the GitHub. The files will be exported in the following recommended format:
|- <root level folder>/ ________________ # Root level folder set by Directory property
| |- policies/ ________________________ # Subfolder for policy objects
| |- <displayName>_<name>____________ # Subfolder based on policy displayName and name properties
| |- policy.json _________________ # Policy definition
| |- assign.<displayName>_<name>__ # Each assignment (if selected) based on displayName and name properties
Naturally, GitHub keeps tracks of changes committed in files which will help in versioning of policy definitions and assignments as conditions and business requirements change. GitHub will also help organizing all Azure Policy artifacts in a central source control for easy management and scalability.
Leverage GitHub workflows to sync changes from GitHub to Azure
Screenshot of the Manage Azure Policy action within GitHub
An added feature of exporting is the creation of a GitHub workflow file in the repository. This workflow leverages the Manage Azure Policy action to aid in syncing changes from your source control repository to Azure. The workflow makes it quick and easy for customers to iterate on their policies and to deploy them to Azure. Since workflows are customizable, this workflow can be modified to control the deployment of those policies following safe deployment best practices.
Furthermore, the workflow will add in traceability URLs into the definition metadata for easy tracking of the GitHub workflow run that updated the policy.
More information on Manage Azure Policy GitHub Action here.
Trigger Azure Policy Compliance Scans in a GitHub workflow
Screenshot of the Azure Policy compliance scan on GitHub Actions
We also rolled out the Azure Policy Compliance Scan that triggers an on-demand compliance evaluation scan. This can be triggered from a GitHub workflow to test and verify policy compliance during deployments. The workflow also allows for the compliance scan to be targeted at specific scopes and resources by leveraging the scopes and scopes-ignore inputs. Furthermore, the workflow is able to upload a CSV file with list of resources that are non-compliant after the scan is complete. This is great for rolling out new policies at scale and verifying the compliance of your environment is as expected.
More information on the Azure Policy Compliance Scan here.
These three integration points between GitHub and Azure Policy create a great foundation for leveraging policies in ‘as code’ approach. As always, we look forward to your valuable feedback and adding more capabilities.
by Contributed | Nov 17, 2020 | Technology
This article is contributed. See the original author and article here.
By: Adrian Moore | Sr. PM – Microsoft Endpoint Manager – Intune
The following article helps IT Pros and mobile device administrators understand some of the finer details regarding iOS device migration from an existing MDM platform to Intune when using Apple’s Automated Device Enrolment program (ADE), formally known as the Device Enrolment Program (DEP). We receive a lot of questions on how best to approach the issue of factory resets and how to handle the Apple Business Manager (ABM) side of things. We hope this article helps with some of the decisions you will face when deciding the best path forward for your organization.
As you migrate your mobile device management to Microsoft Intune, arguably one of the most important parts of the transition will be the impact to your users. Before considering how you will migrate your devices to Intune, it is important to understand your device landscape and how your employees are using their devices. This information will largely drive your migration path.
Based on our experience working with customers, the following are the most common points that will help you decide how you will migrate, and what the user experience will be during the migration:
- You currently have iOS Apple Business Manager devices enrolled in another MDM platform.
In this scenario, the devices will need to be moved to a new (Intune) MDM server in Apple Business Manager to be able to pick up an Intune ADE profile.
Devices must be factory reset to properly enrol in Intune and remain in a fully supported state with Microsoft and Apple.
- Users store personal data on these devices.
Devices with personal data on them will need to be backed up by the user to their iCloud account if they wish to retain it, however this does require you to backup corporate data to a consumer cloud service that is not controlled by your organization.
Devices must be unenrolled from the current MDM platform before the final backup is taken.
If users decide to use the restore option in the Apple Setup Assistant, once the restore is complete they will have to visit the App Store to install the Intune Company Portal.
- Users backup the device to personal iCloud.
- Backing up a device while it is still enrolled in your current MDM will mean the management profile will also be backed up, and, subsequently, re-applied to the device at the point of restore.
- You are/are not willing to factory reset the devices.
- The only supported way to enrol an ADE device is from the out-of-box experience, which requires a factory reset of the device. While it is technically possible to unenroll from one MDM platform and enrol into Intune manually via the App Store version of Company Portal, this is not recommended for several reasons:
It is not possible to “lock” a management profile to a device enrolled in this manner (however, the device does retain its “supervised” state).
The device will not show as being enrolled against an ADE profile in Intune, which means any configuration applied based on that logic will not be applied to the device.
- Devices will not get automatically marked as “Corporate”.
NOTE: If you ever need to re-enrol your ADE device, you must first add the IMEI number of that device as a corporate identifier. You might need to re-enrol your ADE device if you are troubleshooting an issue, like the device not receiving policy. In this case, you would:
- Retire the device from the Intune console.
- Add the device’s serial number as a corporate device identifier.
- Re-enrol the device by downloading the Company Portal and going through device enrolment.
Failing to do this will mean the device will be marked as “Personal” and not “Corporate”.
Now let us look at an example scenario that we commonly see when working with our customers.
Example iOS scenario
Contoso has iOS ADE devices currently enrolled in an MDM platform. They allow their staff to use their personal Apple IDs on their devices and store personal data on them. Most of their users do this, and back-up their content to iCloud. Staff understand that devices may, from time to time, need to be factory reset and may be wiped if lost or stolen. Contoso IT wants the migration to Intune to be done as quickly as possible, so they are only managing two MDM platforms for a short time. They want minimal IT interaction when it comes to users enrolling their devices. Contoso has users in regions where ADE is not supported by Apple.
In this example, the migration flow for ADE devices could look like this:
- IT Pro Action: In Apple Business Manager, move the user’s device to the new Intune MDM Server and sync devices in Intune.
- IT Pro Action: Unenroll the device from the current MDM.
- User Action: Backup the device to iCloud.
- User Action: Factory reset the device.
- User Action: Enrol device through ADE flow (do not select restore option as this will break the enrolment flow).
- User Action: Once enrolled, add Apple ID and restore any required data.
This procedure ensures that the data on the device is backed up without the old management profile and the device has been enrolled correctly with the new Intune-based ADE profile. Many of our customers add the user to a Conditional Access group after step #3, which blocks access to corporate resources until the user enrols and their device is compliant.
In the same example, the migration flow for non-ADE devices would look like this:
IT Pro Action: Unenroll the device from the current MDM.
User Action: Backup the device to iCloud.
User Action: Download Company Portal from the App Store.
User Action: Enrol device through Company Portal app.
User Action: Once enrolled, add Apple ID and restore any required data.
NOTE: The Intune service synchronizes with Apple at the following frequencies*:
- ADE: Once every 12 hours
- VPP: Once every 15 hours
*It is possible to run a manual synchronization, or use a synchronization script to increase the frequency, which can be found here (ADE) and here (VPP).
Conclusion
As you can see from the examples, the migration path will largely be determined by the way the devices are being used by your employees, so it is important to do some analysis before deciding the best path forward for your organization.
More info and feedback
For further resources on this subject, please see the links below.
Supported operating systems and browsers in Intune
Automatically enroll iOS/iPadOS devices with Apple’s Automated Device Enrolment
Enroll iOS/iPadOS devices in Intune
Backup and restore scenarios for iOS/iPadOS
Troubleshoot iOS/iPadOS device enrolment problems in Microsoft Intune
As always, we want to hear from you! If you have any suggestions, questions, or comments, please visit us on our Tech Community Page, or leave a comment below.
Follow @MSIntune and @IntuneSuppTeam on Twitter.
by Contributed | Nov 17, 2020 | Technology
This article is contributed. See the original author and article here.
This blog was published today on the M365 Developer Blog, but given its relevance and importance to our readers we wanted to publish it here too.
Microsoft Graph is the modern API for the Microsoft 365 platform. We make continuous, significant investments in its security, performance, and features to ensure it meets the needs of our own product teams as well as the global ecosystem of developers who build applications using its capabilities.
While we’re investing in Microsoft Graph, we’re also examining our legacy surface areas. Some of our existing legacy services become obsolete based on the new functionality and they no longer provide the best way to access M365 data. When this happens, we start the two-year process defined in our service deprecation policy to shut down the service in question.
Today we are announcing the deprecation of Outlook REST API v2.0 and that it will be decommissioned on November 30, 2022. Once past this date, the service will be retired, and developers may no longer access it. As part of the deprecation, we will soon disable creation of new Outlook REST API v2.0 applications.
Going forward, we will not be making any further investments in the capabilities or capacity of the Outlook REST API v2.0. In line with this announcement, we will also be retiring the OAuth Sandbox by December 31, 2020.
If you are using the Outlook REST API v2.0 in your app, you should plan on transitioning to Microsoft Graph.
Please refer to: https://docs.microsoft.com/en-us/outlook/rest/compare-graph#moving-from-outlook-endpoint-to-microsoft-graph as a starting point.
We understand that for some applications this change, even if anticipated, will require some amount of work to accommodate, but we are confident it will ensure better security, reliability, and performance for our customers. The Microsoft Support Community is here to support you through this transition.
Thanks for continuing with us on our journey as we continue to improve productivity for everyone on the planet, and please let us know if you have any additional questions or concerns by reaching out to our Q&A Mail forum.
The Microsoft 365 Team
Recent Comments