by Scott Muniz | Jul 28, 2020 | Uncategorized
This article is contributed. See the original author and article here.
By Priya Ravichandran | Sr. PM – Microsoft Endpoint Manager – Intune
The Android OS is ubiquitous and a popular choice for purpose-built device manufacturers. However, not all purpose-built devices will ship with Google Mobile Services (GMS). These purpose-built devices enable organizations to accomplish critical tasks in a more streamlined manner and provide the ability to connect remotely while remaining productive. Purpose-built devices have become even more essential with the current shift to remote work during COVID-19. An example of this includes the Teams integrated RealWear devices which deliver purpose-built experiences for field service in safety-critical environments. OEMs such as Lenovo, Facebook, and Vuzix have also shipped Android (non-GMS) purpose-built devices for enterprises.
Most purpose-built devices are based on the Android platform, without integration with GMS. Microsoft Endpoint Manager’s Android Enterprise management options are dependent on GMS, which introduces challenges for managing these types of devices today. However, these devices are critical assets an organization will expect to manage alongside the rest of their device estate.
In this blog, we will review the current options for managing these Android (non-GMS) devices via Microsoft Endpoint Manager – Intune.
Leveraging device administrator to manage non-GMS Android devices
Today Intune supports two options to manage Android devices – Android Enterprise or device administrator.
Android Enterprise is the industry standard that Google is driving to enable a consistent management experience across Android devices, independent of device OEM. However, Android Enterprise requires the devices be integrated with GMS – something many purpose-built specialty devices do not ship with.
Device administrator is the other management mode that Intune currently supports. While Google is decreasing support for device administrator from Android 10, device administrator is still a viable and supported option to manage devices on earlier versions of Android and will be able to address the management needs for these purpose-built devices.
Managing your non-GMS purpose-built devices with Intune
Prerequisites
Before starting enrollment, ensure that the following pre-requisites are met:
- The device has met all the necessary requirements – as defined by the OEM – to be successfully managed.
- The Intune tenant is provisioned, and device administrator management is enabled.
- The Microsoft Intune Company Portal app .apk is downloaded. The Company Portal app .apk can be downloaded here.
Onboarding non-GMS devices
Management of your devices starts with the enrollment workflow. For device administrator, the enrollment workflow requires the Microsoft Intune Company Portal app to be installed onto the device. Once the Intune Company Portal app has been installed, the enrollment workflow begins when the user launches the app and completes the steps presented.
Once enrolled, all the applicable device administrator policies would be available for the management of these devices. The only exceptions are policies that are dependent on GMS.
Key things to note
- Device administrator enrollment must be permitted on your tenant for these device enrollments to succeed. If device administrator enrollments are blocked via the enrollment restrictions, the enrollments on these devices will fail.
- If multi-factor authentication (MFA) is enabled for the organization, a user will be expected to complete the MFA challenge when enrolling the device.
- App protection policies (APP) that have been deployed in the organization will also be equally enforced for apps provisioned on these devices as they will be considered part of the applicable Android device landscape. An example of this would be requiring a PIN to access Teams on a RealWear device.
Looking ahead
We are aware that support for management using Device Administration mode is moving out of support within the Android platform starting with Android 10. Microsoft Endpoint Manager has been guiding customers to migrate the management of their Android devices to Android Enterprise.
These purpose-built devices are an exception to this guidance because they do not have GMS support. Additionally, most of the major OEMs building these purpose-built devices are using Android versions below Android 10. Thus, device administrator management capabilities are available and supported for these devices.
Looking ahead, the Microsoft Endpoint Manager team is investigating long term options to provide an alternative to device administrator to ensure continuity of management on these devices as their platforms also progress to later Android versions.
Customer support
Managing purpose-built specialty devices without GMS with device administrator mode in Intune is considered a fully supported scenario. As such, this scenario will be supported through our usual Intune support channels.
Additional resources
by Scott Muniz | Jul 28, 2020 | Uncategorized
This article is contributed. See the original author and article here.
Today we are pleased to announce some new changes to Modern Authentication controls in the Microsoft 365 Admin Center, exposing simpler options for customers to manage both Modern and Basic Authentication requirements within their organizations. Available from within the Admin Center under Settings > Org Settings > Modern Authentication (alternatively, search for “Modern Authentication” in portal Home page Search field), customers may now quickly designate the protocols in their tenant that no longer require Basic Authentication to be enabled.
While additional granularity is available through PowerShell, once Modern Authentication is enabled these new UI options will provide Administrators simpler controls to manage Basic Authentication access to common protocol combinations. These new changes, rolling out to all tenants, align with our entry from the M365 Roadmap.
Behind the scenes, these new Modern Auth UI options utilize Authentication Policies. For customers that have not created their own Authentication Policies in the past, modifying any of these selections in the new UI (POP3 in the example below) will automatically create the first new Authentication Policy. This policy is visible only through PowerShell. For advanced customers that may already be utilizing Authentication Policies, changes within the UI will modify their existing default policy. You’ll want to look through your Azure AD Sign-in logs to get a good idea of which protocols clients are using before making any changes.
Additional Information
We realize there may be some confusion around different efforts Microsoft is making to provide more secure environments for our customers. The easiest answer for customers who aren’t using Basic Authentication, and don’t have a complicated auth story, is to enable Security Defaults. Otherwise, while the below isn’t an exhaustive list, we thought it would be a good idea to try to cover a few additional details here.
Modern vs. Basic Authentication: Hopefully by now we don’t need to expand upon the virtues of Modern Authentication. Enabled by default for all new tenants since August 1, 2017, Modern Auth is the superior alternative for all users and applications connecting to Office 365. If you haven’t turned Modern Authentication on yet we certainly recommend it. Just be aware this switch affects all the Outlook for Windows clients in your entire tenant, so make sure you are clear on how it may affect your users.
Security Defaults: If your tenant was created on or after October 22, 2019, it is possible that Security Defaults are already enabled in your tenant. In an effort to provide basic level of security, Security Defaults are being rolled out to all newly created tenants. Security Defaults block all Legacy/Basic Authentication and enable Modern/Multi-Factor Authentication for all users. We should clarify that Security Defaults are typically tailored for new customers or those who are new to managing their own security story. While the end results are similar, Security Defaults do not utilize Exchange Authentication Policies under the hood. Thus, to prevent overlap and confusion, we restrict the combination of these controls in the new Modern Auth UI. If Security Defaults are enabled in the organization, administrators attempting to use new Modern Auth UI will be presented with the following text. (You should disable Security Defaults only if you understand the risks of using Basic Authentication.)
Authentication Policies: As announced last year, the Exchange Team is planning to disable Basic Authentication for the EAS, EWS, POP, IMAP, and RPS protocols in the second half of 2021. As a point of clarity, Security Defaults and Authentication Policies are separate, but provide complementary features. We recommend that customers use Authentication Policies to turn off Basic Authentication for a subset of Exchange Online protocols or to gradually turn off Basic Authentication across a large organization. While more details will come in future announcements, as mentioned in April, we plan to begin disabling Basic Authentication in existing tenants with no recorded usage as early as October 2020. We will provide notifications via Message Center posts before we disable Basic Authentication for any tenant.
Client SMTP Submission (SMTP AUTH): While SMTP AUTH Basic Authentication will not be deprecated, the use of Basic Authentication within SMTP AUTH is still considered insecure. There are multiple initiatives for SMTP AUTH that are worth calling out, and administrators should have familiarity with each of these:
- As announced in April, we have additionally disabled SMTP AUTH for all new Office 365 tenants by utilizing the SmtpClientAuthenticationDisabled parameter, and we’ll be expanding this effort over the next several months. If your tenant doesn’t need to use SMTP AUTH at all, this option allows the granularity to disable SMTP Auth for individual users via Set-CASMailbox or Set-TranportConfig for tenants. Read more here.
- For customers that still require SMTP AUTH, we’ve got you covered, with new options for implementing OAuth 2.0 for client applications. After updating your SMTP AUTH clients, please make sure you block legacy authentication methods via one of the following:
- Security Defaults (which as mentioned covers all protocols including SMTP AUTH) if enabled will block Basic Authentication access to SMTP AUTH for all end users within a tenant. Security Defaults is being rolled out as default for all new tenants and is the recommended action if it works for your organization.
- Authentication Policies, either via PowerShell or the new UI announced here today, can also block Basic Authentication access to SMTP AUTH for all or groups of users.
Exchange Online PowerShell: As we announced recently, Exchange Online PowerShell V2 module is now fully released and this is what you should use to connect using Modern Authentication. We have also recently announced the preview program which will allow you to run PowerShell scripts with Modern Authentication (using certificates).
If you have any feedback, please let us know in the comments below.
The Exchange Team
by Scott Muniz | Jul 28, 2020 | Uncategorized
This article is contributed. See the original author and article here.
Announcing the release of BizTalk Server 2020 CU1. The download went live just moments ago.
Here are the details
https://support.microsoft.com/help/4538666 (master)
https://support.microsoft.com/help/2555976 (index)
As you may recall from 2020 setup experience, for BizTalk Developer Tools, in addition to installing CU package, also update/install new version of BizTalk Server Visual Studio extension (3.13.2.0). The extension can be installed from https://marketplace.visualstudio.com/items?itemName=ms-biztalk.BizTalk or within Visual Studio – Manage Extensions.
As a standard practice, EN download is made available by default. All other language packages will be made available on need basis. If a download is not available for the supported BizTalk language that you need, please contact me for the same.
by Scott Muniz | Jul 28, 2020 | Alerts, Microsoft, Technology, Uncategorized
This article is contributed. See the original author and article here.
This article is the 5th part of the Zero to Hero with App Service series. This article assumes you have completed the first article.
If you would like to customize your web app and have a domain name other than “azurewebsites.net”, you can add a custom domain to your web app. Moreover, you can secure your custom domain with a free certificate with App Service Managed Certificates, which will give your customers peace of mind when browsing your website.
Prerequisite
Before you can add a custom domain to your web app, you need to have purchased a custom domain already. If you don’t have a custom domain, you can buy one through App Service Domains, which you can get started with the App Service Domains section of the article . If you already have your own custom domain, proceed to the adding a custom domain to your web app section of the article.
App Service Domains
App Service Domains lets you create and manage domains hosted on Azure DNS through the Azure portal. The domain can be used for services such as Web Apps, Traffic Manager, and etc.. Purchasing an App Service Domain also provides the added benefit of privacy protection: your personal data will be protected from the WHOIS public database for free. This is often costs extra with other domain registrars. This product can auto-renew your domains and it integrates easily with your web apps.
To create your App Service Domain, you can click on this link here or you can head to the Azure portal and search for “App Service Domain”.
In the domain search bar, type the domain name you would like to purchase. If you don’t see the name in the list of available domains, then the domain isn’t available for purchase. However, you can choose from the suggested list of available domains or enter a new domain you would like to purchase. In the “Contact information” tab, enter your personal information. Then in the “Advanced” tab, choose whether you want to set up auto-renew for the domain. Domain auto-renew prevents accidental loss of domain ownership after expiration. Lastly, decide whether you would like to add privacy protection at no extra charge. Go to “Review + create” to review the legal terms, verify the domain information, and click “Create”. Once your domain has successfully been created, proceed to the adding a custom domain to your web app section of the article.
Adding a custom domain to your web app
To add a custom domain to your web app, you will need to update your domain’s DNS records. If you purchased an App Service Domain, the DNS records will be updated for you automatically and you can proceed to verifying and adding a custom domain section. Otherwise, you will need to work on updating DNS records .
Updating DNS records
You will need to get the custom domain verification ID of your web app. This token will be used to verify the domain ownership. You can get this value in the “Custom domains” tab of your web app.
Once you have the ID, go to the domain provider of your domain. In the DNS records, create a CNAME and a TXT Record. As an example, if you want to map your ‘www’ subdomain, refer to the chart below:
| Record Type |
Host |
Value |
| CNAME |
www |
.azurewebsites.net |
| TXT |
asuid.www |
Custom Domain Verification ID |
Your DNS records page should look something like the following example:
Verifying and adding custom domain
After updating your DNS records (if not using App Service Domain):
- Go to your App Service and navigate to the “Custom domain” section under “Settings”.
- Click on the “Add custom domain” button
- Enter the domain that you would like to use
- Click “Validate”
- If you correctly updated your DNS records and the DNS changes have propagated, you will see the option to “add custom domain”. Otherwise, return to the previous updating DNS records section to make sure you have correctly updated your DNS records. Click “add custom domain”.
Once the custom domain has successfully been added to your web app, you will see it under the list of “Assigned Custom Domains”. You can navigate to your web app using these domain names.
If you are interested in securing your custom domain, proceed to the following section on Creating an App Service Managed Certificate .
Creating an App Service Managed Certificate
If you would like to secure your custom domain at no cost, you can create an App Service Managed Certificate and bind it to your domain. With Managed Certificates, you don’t have to worry about renewals, as the certificate is automatically renewed for you!
Go to your web app resource and navigate to the “TLS/SSL settings” section under “Settings”. Click on the “Private Key Certificates” blade and look for the “Create App Service Managed Certificate” button.
Select the domain from the dropdown menu that you would like to create a certificate for and click “Create”.
Once the certificate has been created, you will see that it in the list of your private certificates on the “TLS/SSL Settings” blade. In order to use this certificate to secure your domain, you will need to bind this certificate to your domain, which will be explained in the next section of binding your certificate to your web app .
Binding Your Certificate to Your Web App
The final step to securing your domain is to bind your certificate to the domain. In the Portal, go to your web app and navigate to the “Custom domain” section under “Settings”. Look for the domain you want to secure from the list of “Assigned Custom Domains” and click “Add binding”.
In the following blade…
- Select the correct custom domain
- Select the App Service Managed Certificate you’ve just created from the dropdown menu
- Select “SNI SLL” for the TLS/SSL Type
- Click “Add Binding”
Once the binding has successfully been created, you will see a green checkmark and the word “Secure” beside your custom domain under the “Assigned Custom Domains” list.
Summary
Congratulations! In this article, you have successfully added and secured a custom domain for your App Service! Your users can now reach your web site at the new domain, and their browser will let them know that the site is secured.
Helpful Resources
by Scott Muniz | Jul 28, 2020 | Alerts, Microsoft, Technology, Uncategorized
This article is contributed. See the original author and article here.
We are excited to share several new Azure Migration-related assets to help you navigate cloud migration, learn about best practices, and understand tooling options available from Microsoft.
- Cloud Migration Simplified E-Book Learn about the cloud migration journey, with our tried and true framework for a successful migration and migration best practices, along with guidance on how to navigate all of the tools and resources provided by Microsoft and partners.
- Azure Migrate E-Book Learn how to discover, assess, and migrate infrastructure, applications, and data to the cloud with Microsoft’s first-party migration service, Azure Migrate.
- Virtual Machine Migration Learning Path Get step-by-step instructions along with video demos on how to migrate virtual machines and apps to Azure using Azure Migrate, including guided set up, assessment, and migration.
Recent Comments