Endpoint Manager/Intune Filters is a new feature which is currently (at time of writing) in public preview. This gives you advanced targeting for things like compliance policies, configuration profiles and app assignment by adding filters.
At a basic level, you apply a filter over the top of an included device or user group, with two modes to either include or exclude devices from the assignment. For this kind of thing I currently use dynamic device groups, and set assignments to these groups. Going forward I can change this to using filters, and assigning to larger (perhaps assigned membership) groups. The benefit to doing this is that you no longer have to wait for dynamic group membership to update, which can take a while – especially on larger environments.
I’ve been looking at ways to get performance data for all our devices, currently 99% in Config Manager but in the future we’re expecting to have quite a large deployment which is only managed by Intune. I’ve already set up Desktop Analytics but this just covers things like Windows 10 feature updates, which is good but not really what I was after.
Introducing Endpoint Analytics.
This is part of Intune and, if you set up tenant attach or device co-management, you can pull data for ConfigMgr managed devices into the console. Endpoint Analytics will show you a score, based off various factors such as startup performance, recommended software and application reliability, and there’s various screens you can look at with more detailed information such as startup performance and application reliability. Most report lists can be exported for offline analysis in Excel. I think it’s a key tool for identifying devices which need attention – whether it’s a device that has missed its upgrade from HDD to SSD sitting at the top of the “slowest boot up time” list, or a device which frequently suffers from bugchecks/BSODs potentially being a hardware issue, it brings to light troublesome devices which the end user may not have ever reported.
I’ll cover setting it up and then look at each section in turn, with lots of screenshots.
I often refer to DEP as “Autopilot for iPads”, and Autopilot as “DEP for Windows”. The Device Enrolment Program allows you to register your devices with Apple so that when they are reset and go through activation, any DEP-assigned configuration is enforced onto the device.
DEP (and Volume Purchasing Program) have since been rebranded into Apple School Manager (or Apple Business Manager), which I think is a good move by Apple as I find it a lot easier than having to remember the special VPP store URL whenever I want to get some new apps, and having to remember the DEP URL to alter any device assignments.
Assigning devices to DEP is something that traditionally the reseller/supplier needed to do – you’d give them your DEP ID when placing the order and put their reseller ID into your DEP portal, and the devices would appear – however you can now add other devices yourself using Apple Configurator 2. This is particularly useful for older devices that you didn’t get set up on DEP, or if someone else in the organisation has randomly purchased some devices without speaking to you first from a supplier you don’t have an existing relationship with. You’ll need a Mac computer to run this – I use a Mac Mini – and it’ll need to be a fairly recent version. In this post I’ll go through how to set up AC2 to add devices to DEP, and then get them in to Intune for management. I’ll be referring to Apple School Manager in this post but the steps for Apple Business Manager are the same.
Back in 2015 I was looking for a cheap way to monitor the temperature in our server racks and also for a project with my new Raspberry Pi Model B. I’ve recently had a photo from this pop up in my Facebook memories so decided I’d dig out the write-up I did and post it on my blog.
The main aims of this project are:
Use a Pi to monitor temperature but reduce the number of Pis needed to a minimum – so if we have 3 racks in one room, try and monitor these off a single Pi
Python script on the Pi reads the temperatures on a schedule and uploads this data to a web server
PHP script on the web server to receive the data and log in a MySQL database and also to display the current temperature and humidity at each sensor.
Mechanism to send SMS messages if the temperature rises above a defined limit.
Windows Hello is Windows 10’s biometric authentication system which allows users to sign into their device using facial recognition (if the device has an IR camera), fingerprint (if the device has a fingerprint reader) and PIN. The data for these is stored on the device itself rather than transmitted to the authentication provider (i.e. Azure AD) so is more secure than a password as an attacker would need the device as well as the face/finger/PIN of the person they are trying to impersonate. In this case a PIN is more like a password, as we can define the minimum and maximum length, and allow/forbid/require lower case, upper case and special characters. The default setting permits numbers, lower and upper case letters but does not allow special characters.
At a basic level it works by using a public/private key pair or certificate based authentication. The private key and other biometric data is stored in the device, either in the TPM chip (if present) or in the file system. Windows Hello for Business is the enterprise version of Windows Hello and can be configured using Group Policy or a modern MDM such as Intune.
If configured correctly it can also be used to authenticate to on-premise resources such as from a domain-joined or hybrid-joined device. My preferred method of working here is to move things to use modern authentication and as such the devices I use to test this are just Azure AD joined (and provisioned using Autopilot), so I won’t be setting up the certificate for on-premise authentication. If you want to read more about configuring Windows Hello for Business SSO to on-premise resources, I have posted recently about this.
Multi-factor authentication is a must in this day and age, with phishing techniques becoming more and more sophisticated and more difficult to detect/block. Azure MFA can be used to secure your Office 365 workload (and, if you’re using it as the authentication method for other services, they can be secured too).
MFA is available in all of the levels of Azure AD licensing however it’s most powerful when combined with Conditional Access, which requires Azure AD Premium P1 or P2. In this post I’m going to run through a few of the different rules I’ve set up on various tenancies. Continue reading “Azure: Conditional Access and MFA”
Six years ago we started a migration to cloud services at work. In this post I’m going to go through the steps we took and what our network looked like back then, now, and the future steps.
We ran a traditional network – three node VMWare cluster with shared storage (fibre channel SAN), desktop PCs in most areas with a small laptop deployment, Exchange Server on-premises, and home and shared drive maps to a local file server. Remote access to documents was via a Remote Desktop Services cluster, and this was the only remaining use for RDS as we have previously migrated to a cloud based MIS.
We initially wanted to shift the Exchange workload to Exchange Online and take advantage of the fact that – for education customers – it was free. We followed this up, once Office 365 had matured a bit, with migrating home drives to OneDrive, and then shared drives to a mixture of SharePoint and Teams. Finally we started piloting Teams in 2019 and were thrown into a full roll-out in March 2020 with the surprise of Coronavirus. Continue reading “Shift to the Cloud: Moving a school to OneDrive and Teams”
Whilst Endpoint Protection can be suitably managed for traditional Active Directory-joined devices using Group Policies, you’ll need an alternative to protect your Azure AD joined devices. Luckily Intune can do this for us by way of a device configuration profile.
Azure AD Password Protection is part of Azure Active Directory and helps prevent users from picking poor/easily guessable/compromised passwords. Microsoft maintain a “global banned passwords” list which stores passwords which are “deemed too common”. Obviously this list is not published, but by using Azure AD Password Protection you can have password changes run against it for both cloud and on-premises users. You can also create a custom banned password list, of up to 1000 entries, containing easily guessable things about your organisation, e.g. product names.
When a password change is processed, the service will “normalise” the password (which in essence would be taking it to lower case, swapping out any common substitutions, e.g. Pa$$w0rd -> password), and then checking the resulting string against the banned password lists. If it matches the user will get an error telling them to pick something more difficult to guess.
The only thing I don’t like about this at the moment – and hopefully is something that will be worked on in a future update – is that it’s all or nothing. At work we give staff a much more strict password policy than pupils, so it would be nice to be able to do the same here.
I’ve looked at using Azure to back up on-premise workloads in a couple of posts now (Azure Backup for smaller loads, and Azure Backup Server for things like a Hyper-V cluster), so I think it’s time I looked at backing up workloads that are already running from Azure. I’m going to look at backing up Virtual Machines and storage accounts – there’s not much more I store in Azure that would need backing up.
I’m going to take a quick look at the options for storage accounts, virtual machines and databases.
The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.