When you’re using Windows Analytics you’ve probably noticed that from Windows 10 1803 device names are not visible anymore within Log Analytics. For Windows 10 1709 and earlier the device name was part of the telemetry data which is uploaded to Windows Analytics. From Windows 10 1803 devices names are not part of the telemetry data by default. The result is that the device name will be cleared as soon as the device is upgraded to Windows 10 1803. If you have queries based on device names this could lead to failing queries. In this blogpost I want to share a solution for this issue.
The last couple of months it was a bit quiet on my blog. This had to do with some new project assignments and I had some presentations to prepare for WMUG and ExpertsLive. Now those events are done I’ve some time to write blogposts. Last week I was involved in a question to enable Windows Hello for Business for a group of users instead of all users. Within Intune you can configure Windows Hello for Business for all users and to configure it for a group of users an additional policy is needed. In this blogpost I want to explain what is needed to configure this scenario.
On the 1st of July I received an awesome email. Microsoft presented me my third MVP award in the category: Enterprise Mobility. I’m really proud and honored that my contributions are rewarded with a MVP Award. I will continue sharing my knowledge by presenting on events and blogging on this blog. The focus will remain the same: Intune, System Center Configuration Manager and Windows 10.
Many thanks to Microsoft and you as a reader of my blog!
The last couple of months I worked together with Microsoft on protecting the Windows 10 AlwaysOn VPN connection with AzureAD Conditional Access. As I’ve explained in this blogpost I found a strange issue where a user was able to connect without having being compliant to the Conditional Access request. I described that in this blogpost. After publishing that blogpost Microsoft came back to me that even that configuration is not the ‘total’ solution. The reason is that the VPN backend (RAS or NPS) should enforce the use of the AzureAD Conditional Access certificate. In this blogpost I will explain the steps needed to get this configured.
Next week I will be speaking on the Microsoft Tech Summit which takes place in the Amsterdam RAI. On Wednesday the 28th I will be speaking about ‘Protect your Windows 10 VPN solution with AzureAD Conditional Access’. Beside my own session I will also take part in the Microsoft 365 Keynote where we will share our KPN Microsoft 365 Migration experiences. At the end of the day I will also be present on the ‘Ask-the-Experts’ session. On Thursday I will also be at the Tech Summit but just as an attendee . I hope to see you at my session in the The Hub Theater.
In this demo-rich session I will discuss the Windows 10 AlwaysOn VPN solution. Beside the solution I will also show how we can publish the VPN through Microsoft Intune to our Windows 10 workstations and how we can protect the AlwaysOn VPN with AzureAD Conditional Access. Come to this session if you want to learn more about the AlwaysOn VPN and how to protect it with AzureAD Conditional Access.
This blogpost describes the current Bitlocker experience on Windows 10 1709 and the experience with the Windows 10 1803 Insider Build release (Build number: 17101 and 17107). In this blogpost I’m using Microsoft Intune to configure the Bitlocker settings on the client. Within Microsoft Intune a setting is added to improve the Bitlocker experience. Since this setting only has a different behavior on Windows 10 1803 Insider builds don’t expect any improvements on Windows 10 1709. To be complete in this post I will also describe the experience with Windows 10 1709.
This blog post uses the AllowWarningForOtherDiskEncryption setting of the Bitlocker configuration service provider (CSP), to silently enable Bitlocker on Windows 10 1803 devices. Windows 10 1803 is currently available as Insider Preview build.
This weeks blogpost is about collecting ‘custom’ data which is not inventoried by Intune or Windows Analytics in a Windows 10 Modern Management scenario. In a modern management scenario data about the device like Device Model, Installed Applications, Windows Updates Compliance are collected by either Microsoft Intune or Windows Analytics. But at this moment there are some ‘gaps’ when looking to which data is collected and which not, examples are BIOS information and Office365 Pro-Plus deployment information. In this blogpost I’m describing a solution which you can use to collect additional data and create reports based on the collected data.
With Microsoft Intune we can control the Windows 10 Update rings by using the Software Updates policies. For the Office365 Pro-Plus installations this is a different story, at this moment we are not able to configure this through a GUI policy within Intune. In my current project it’s one of the requirements to control and enforce the update channels of the Office365 Pro-Plus installations. I was discussing this requirement with my colleague Peter van der Woude and he challenged me to check if this was possible through ingesting a Office ADMX policy file. My answer was: Challenge Accepted!
This blogpost is about assigning Intune policies/apps to a limited group of users or devices. I want to look into the different sections like Configuration Policies, Compliance Policies and Apps and explain what options you have regarding assigning them to a limited set of users/devices. For the policies (Configuration and Compliance) you can use the include and exclude assignment to exclude users/devices from a policy. For App assignments the include/exclude assignment is not available but you will have some other options! Continue reading
Last year I wrote a couple of blogposts about the Windows 10 AlwaysOn VPN solution with AzureAD Conditional Access. You can find the blogposts here:
After testing this solution more and more I had a strange issue where the user was able to set-up a AlwaysOn VPN connection even when the conditional access conditions were not met. So if my conditional access policy was requiring a compliant device I was able to connect with a non compliant device. I could do this by clicking on the X (Close) icon when I was in the Conditional Access flow. Together with Microsoft I’ve investigated this and a solution has been found.