Posts

Why want you to create desktop shortcuts with Intune? Business specific apps may require special shortcuts in order to launch the application with the right parameters. Or you need to create a shortcut for an application which is stored on your on premises fileserver. For this purpose I created a little solution which closes the gap between the modern cloud and on premises world. In comparison with other solutions this one works if you have redirected the users desktop with OneDrive Known Folder Move and automatically remediates missing shortcuts if they got deleted. Direct link to the GitHub repository. Browser links: Instead of placing shortcuts to websites on the desktop I would recommend you to use managed bookmarks which can be directly provisioned within the web browser. I documented this for the new Microsoft Edge based on chromium here. {: .notice} Features # This solution works when the desktop is redirected with OneDrive Known Folder Move Everything is user based (local userprofile) If the shortcut is missing or deleted it gets automatically (re)created Possibility to remove shortcut via Intune Win32 app uninstall Shortcut can point to: URL, File (UNC) or Folder (UNC) Ability to pass shortcut arguments Ability to specify shortcut icon (UNC/URL) Ability to deploy shortcut together with an app using Intune Win32 app dependencies Architecture # A simple PowerShell script which does all the shortcut stuff is wrapped as Intune Win32 App. This adds possibility to detect the presence of the shortcut and if required to uninstall it with Intune. In order to work with the redirected desktop to OneDrive with Known Folder Move we can take advantage of the [Environment]::GetFolderPath("Desktop") method to resolve the desktop location. Based on the Win32 app configuration the shortut get’s either created on the users personal desktop or on the allusers desktop.

Recently I read a great article from the Microsoft IAM Director Sue Bohn concerning a Conditional Access Q&A. One question was about the device platform feature - which let’s you apply a policy only to a specific device platform like iOS, Android or Windows 10. The detection of the device platform relies on the user agent string sent by the application or web browser. Because this one can be spoofed easily better configure your Conditional Access policies wisely. The problem # As soon as you enable the device platform selection there’s the chance that a user doesn’t catch any Conditional Access policy. As a result, you should not rely on the User Agent String to be present or to be accurate. Most browsers have a function to set an arbitrary User Agent String for testing purposes. (Microsoft) Bypass example # To give you an example, here’s a little walk-through: Conditional Access Policy configured for all cloud apps Windows 10 selected as device platform Access control: Block If we now try to access the azure portal with a Windows 10 app or browser we get the following result:

A colleague recently asked me how to access the Microsoft Graph API using PowerShell without specifying his user account or credentials. So here’s a little post about the required configuration to authenticate against the OAuth 2.0 endpoint of Azure AD with an app registration. This is especially useful for automation services like Azure automation. At the end of this post you’ll find a PowerShell template. Gather application information # Create a new client secret for your app and note down the following values: Client Secret Application ID (client ID) Directory ID (tenant ID) Azure AD App registration ## PowerShell code Request authentication token # In order to use the Graph API we need an authentication token. The information we gathered before is now sent to the Azure AD OAuth 2.0 endpoint. https://login.microsoftonline.com/{TenantID}/oauth2/v2.0/token In the request supply a body with the following content: $body=@{ client_id="8f9f420d-606c-4e13-889e-837072dbfb42" client_secret="BlaBlaExampleSecret" #Generated secret scope="https://graph.microsoft.com/.default" grant_type="client_credentials" } The scope and grant_type are required attributes. A full example looks like: $body=@{ client_id="8f9f420d-606c-4e13-889e-837072dbfb42" client_secret="BlaBlaExampleSecret" scope="https://graph.microsoft.com/.default" grant_type="client_credentials" } $tenantId="7955e1b3-cbad-49eb-9a84-e14aed7f3400" Invoke-WebRequest -Uri "https://login.microsoftonline.com/$tenantId/oauth2/v2.0/token" -ContentType "application/x-www-form-urlencoded" -Body $body -Method Post If everything works we receive an access token object as HTML 200/ok response:

I had the honor to deploy Windows Hello for Business several times for customers transitioning to a modern workplace using Azure AD and Microsoft Intune to manage their Windows 10 devices - combined with hybrid user identities. Now I want to share the most common hurdles and my experiences with you. Just to make sure that you have the modern mindset - here’s a little quote to reconsider your hybrid strategy (if not already done): You don’t need a Hybrid Azure AD join for your Windows 10 devices. Be brave and don’t be afraid and switch to an Azure AD join. It will simplify your device management and significantly reduce the complexity. Why additional configuration is required # To access on premise resources who rely on Active Directory (file shares, applications) kerberos is used as authentication protocol. If you have Azure AD connect in place and a user sign’s in with his hybrid Identity using a password to a Windows 10 device which is Azure AD joined he automatically receives the required kerberos tickets if he wants to access resources. But if the sign-in happens with Windows Hello for Business credentials (pin, biometrics) the authentication flow get’s interrupted because whether the domain controller (if it’s not a Windows Server 2016 DC) or the client can verify the integrity of each other.

Microsoft Defender ATP (MDATP) for macOS hit finally the public preview status. We can now protect our macOS endpoints with cloud based power. I created a little guide about the onboarding process with Microsoft Intune and the user experience. Prerequisites # From a macOS endpoint perspective: macOS version 10.12 (Sierra) or newer No third party endpoint protection installed At least 1GB of free disk space macOS client enrolled in your Intune tenant If you want to enable macOS enrollment for your Intune tenant - I’ve written a post about the enrollment process. From a Microsoft 365 perspective: Microsoft Defender ATP license (Windows 10 Enterprise E5) Intune tenant wit macOS enrollment enabled Access to the Microsoft Defender Security Center Appropriate user rights to create and assign an Intune device configuration, LOB App This post assumes that you perform the tasks and file preparation on a macOS machine. Preparing the onboarding package and files # Access the Microsoft Defender Security Center and gather the installation and onboarding package: To deploy the installation package with Microsoft Intune we need the Intune app wrapping tool for macOS which is available here.

As Microsoft starts to empower the integration for non Windows devices and also the available apps for macOS devices you might want to profit from your existing MDM solution of choice (Microsoft Intune) and enable features like conditional access or Windows Defender ATP on your macOS devices. This post covers the enrollment with the company portal app. If you want to enroll your devices with DEP (device enrollment program) you can find a great guide here. Mind the enrollment restrictions # Let’s start and check the configured enrollment restrictions to make sure that the macOS enrollment is not blocked for your tenant. You’ll find them on your Intune dashboard under: Microsoft Intune > Device enrollment - Enrollment restrictions Intune enrollment restrictions Get an Apple MDM push certificate # Without loosing into details - you need an Apple MDM push certificate (also called APNs) to manage apple devices with MDM. The push certificate allows your MDM solution to send notifications about device actions to your end devices (e.g. wipe, app installation, new policy). To request a push certificate you need a valid Apple ID.

When using your notebooks and portable devices together with a docking station your users might like to close the lid. The Windows 10 1903 release introduces additional power CSP settings. One of them allows you to configure the lid close action while on ac power - so the device doesn’t switch to hibernate mode as by default. Policy CSP configuration # To configure this policy with Microsoft Intune use the following OMA-URI configuration within a new custom device configuration: | Name | SelectLidCloseActionPluggedIn | | Description | Action that Windows takes when a user closes the lid on a mobile PC. | | OMA-URI | ./Device/Vendor/MSFT/Policy/Config/Power/SelectLidCloseActionPluggedIn | | Data type | Integer | | Value | 0 | Other possible values are: 0 - Take no action 1 - Sleep 2 - System hibernate sleep state 3 - System shutdown End user experience # After the next MDM policy refresh the configured policy takes effect and is visible under the power options in control panel:

Reviewing the latest OneDrive features I wanted to try the new AutoMountTeamSites setting which lets you preconfigure SharePoint online sites to sync automatically for defined users and devices. Updated on 12.07.2019: Included the Intune administrative template configuration The setting is officially described as follow: This setting lets you specify SharePoint team site libraries to sync automatically the next time users sign in to the OneDrive sync client. (Microsoft) If you enable this setting, the OneDrive sync client will automatically download the contents of the libraries you specified as online-only files the next time the user signs in. The user won’t be able to stop syncing the libraries. (Microsoft) Prerequisites # In order to get things up an running we need at least: OneDrive sync client version 19.012.0121.0011 or newer Windows 10 Version 1709 or newer OneDrive Files On-Demand enabled (described below) Be aware that this feature is not supported with on-premises SharePoint sites and not recommended to enable this setting for more than 1'000 devices. The device limit is related to the Windows Push Notification Service which tells the OneDrive clients when a file change occurs on a server side. When you exceed that limit clients will find themselves in a polling mode. Hans Brender explains this behavior well on his blog.

Recently a customer needed a drive mapping solution to access his on premise file shares during his transition phase to a cloud-only workplace. I wanted to share the solution with you because it’s a frequently asked question around a modern workplace migration. The following solution can also be extended or modified for a printer mapping or other PowerShell scripts which need to run on each user logon. Updated 04.08.2019: I’ve developed an automated solution to generate network drive mapping configurations with an online tool which also migrates group policy network drive mappings. See: next-level-network-drive-mapping-with-intune. Direct link to the final scripts Lets assume we have the following scenario: - Customer with hybrid user-identities (Azure AD Connect) - On premise ressources with legacy file shares - Devices are Azure AD joined  ( **not** hybrid joined) - MDM managed with Intune - [Optional] Always on VPN for external on-premise resource access - [Optional] Windows Hello for Business deployment as described [here](https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso) Architecture # With my colleague Alain Schneiter I designed the following solution: Main PowerShell script stored on Azure blob storage which handles the drive mapping - driveletters, UNC paths and descriptions can be configured within the script Client side script deployed with Intune which triggers the main script during logon. The main script is not stored locally which makes it easy to customize (no updates oder changes needed on client side) Deployment is user targeted via Azure AD group and Intune Azure blob storage configuration # We wanted to store the script within Azure because the customer was already using Azure blob storage. It’s also possible to store the PowerShell script on GitHub if you don’t want to use Azure.

If you are using Azure AD and the time passes you’ll have a lot of old device entries. If you enable the automatic device cleanup rule in Microsoft Intune the device is only removed within MDM and the Azure AD entry still exists. Intune device cleanup rule For this reason I created a tiny PowerShell snippet to create a report with all devices which didn’t contact your Azure AD tenant since the treshold date specified. If you confirm the operation you can also delete all affected devices. Please be careful when running the script because when removing a device from Azure AD the stored Bitlocker recovery keys are also removed. I can recommend Roger Zander’s Azure table-based Bitlocker recovery key solution.