With domain joined clients we’ve been able to push out registry setting changes with things like Group Policy Preferences. Unfortunately there isn’t an equivalent to this in MEM. While your best plan here would be to find the setting within the Settings Catalog or Templates in a configuration profile, or even look for an OMA-URI which can be set, there will always be some tasks which can only be achieved by directly setting a registry key.
Within MEM we can create PowerShell scripts which run once per user/device. We can specify whether we want these to run in user context or system context. The scripts are downloaded to the device by the Intune Management Extension (IME) and run once per user. If the script is running under the system context then the user does not need to be logged in for the script to execute. If you update the script, it will run again. If it is set to run in user context, and the user is a local administrator, it will run with administrative privileges.
This seems perfect for any registry keys we may wish to change once only. We can of course use Proactive Remediation instead (part of Endpoint Analytics, mentioned briefly in this post however I do plan a detailed look at Proactive Remediation soon) which would allow us to schedule the script to run frequently, as a detect/remediate script pair. Continue reading “MEM: Setting Client Registry Keys”
Updating devices to Windows 11 is fairly simple through Intune, using the Feature Updates settings. To get this working you’ll need Intune licences (…obviously) along with one of the following:
Windows Enterprise E3/E5, included in Microsoft 365 E3/E5/F3
Windows Education A3/A5 (M365 A3/A5)
Windows VDA per user
Microsoft 365 Business Premium
You’ll also need the devices to be on a supported version of Windows 10, enrolled in Intune and either Hybrid or Azure AD joined. Telemetry will need to be enabled – this can be enforced with a Device Restriction policy.
I’ve always hated having to set calendar reminders whenever an SSL certificate or Azure AD App Registration certificate expired. What if you forget to set the reminder? What if you’re off sick and miss it? In most cases missing it means disruption of service for a while, but in some cases – for example some of the Apple certificates/tokens used when managing Apple devices in Intune – missing the renewal means you need to re-enroll all your devices. If you’ve restricted profile removal then you’ll have to factory reset them all too.
I had an idea a while ago for a system to track these, and send reminders, and recently I’ve been working on a system to do just this. There’s many different ways I could have gone about this – PowerShell script, or maybe something in PowerApps/Flow, but I wanted a nice web interface, and my weapon of choice for web development is PHP.
This project will show you a list of certificates and secrets, along with their expiry date and a status indicator (Expired/Warning/Okay). It will automatically pull any Azure AD App Registrations secrets and certificates, and the Intune Apple VPP tokens, Push Notification and Enrollment Program tokens from the Microsoft Graph API. Email alerts can be configured, which will also use the Graph API to send the mail. Continue reading “Project: Certificate Expiry Notification Tool”
I’ve been putting this off for almost a year but finally thought it was time I wrote a post about managing Android devices in Microsoft Endpoint Manager (aka Intune). It’s no secret that I absolutely hate Android devices, which is probably why it’s taken so long to do this, but we have a few at work which need managing so here we are.
I’m going to go through this using a standard g-mail account to link Google to Intune, into something called “Managed Google Play”. From what I can work out, you don’t need to set up anything fancy to do this, you just need the standard g-mail account (using an account tied to G-Suite or Google Workspace does not work for this). In this post I’ll go through the various profile types – e.g. personally owned, corporate owned, fully managed, dedicated device (kiosk) and have a look on rolling out restrictions/certificates/profiles etc, along with some apps.
One of the main reasons people might choose a hybrid Azure AD joined configuration for their devices is that they still want to be able to access on-premises resources, for example a file server, or printers. In my opinion, hybrid join should be avoided and it is usually worth the extra work required on the infrastructure to support your devices being Azure AD joined and having no relationship to the AD domain.
In this post I’ll look at how SSO to on-premise resources actually works, when you are logged on to an Azure AD joined device, with a user account which is synced from your on-premise AD. I’ll also look at how you can configure this so that users logging on using Windows Hello for Business can also SSO. Continue reading “Azure AD and Windows Hello: SSO to on-premise resources”
One of the things I dislike the most about Azure AD joined devices on our enterprise wireless (using NPS on Windows Server for authentication) is that having to put my credentials in whenever I connect is poor usability compared to, say, a traditional domain joined device which can authenticate by device, or user, seamlessly. While there isn’t really a way to replicate device based authentication with Azure AD joined devices (to cut a long story short – there is no computer object in AD for NPS to look for), you can configure things so that you can use a user certificate.
There’s a few pre-requisites for this:
Wireless network using WPA2-Enterprise (or any flavour that uses 802.1x)
Active Directory domain already set up
AD Certification Authority already set up (Enterprise CA)
Windows 365 Cloud PC is Microsoft’s latest addition to the VDI scene. Announced at Inspire back in July, and then released General Availability on 2nd August 2021. On a basic level, you provision a Windows 10 (or 11) VM to a user, and it’s dedicated to that user – so effectively the same as a standard PC in that you’re not sharing resources in a multi-user environment as you may do with Azure Virtual Desktop. Licensing is made simple as it’s a fixed price per user, per month, regardless of how much usage they make. There’s a variety of different SKUs which correspond to different VM specifications.
Windows 365 comes in two versions – Business and Enterprise. Business is limited to 300 users and designed to be much simpler to set up and configure. Enterprise does not have a user limit and integrates with Endpoint Manager (Intune). The core difference here is Business could be implemented by anyone at the company, Enterprise will most likely require an IT department to manage it.
This does not replace Azure Virtual Desktop – it runs along side it. Azure Virtual Desktop requires more technical expertise to set up and manage, and can be more expensive or less expensive than Windows 365 depending on your host sizes, whether you share devices with Windows 10 multi-user, and whether you shut them down or not. Windows 365 is a fixed price with no knowledge of Azure Virtual Desktop and RDS required.
I’m going to look at the setup process for Business and Enterprise and give my thoughts.
I was recently asked about how to deploy a single application but with varying installation command line parameters, using Configuration Manager. Luckily we can do this fairly easily using the Requirements screen on your Application Deployment Type.
In this scenario we were installing a school classroom management program, and needed to provide a different string in the install command line depending upon what kind of PC it was going to – e.g. setup.exe /template=TEACHER or setup.exe /template=TECHNICIAN. The PCs were already organised by Organisational Unit in Active Directory so that was the obvious target. The other way we could have done this was to create multiple device collections in Config Manager, and then multiple applications, and deploy to each of them – but we wanted to keep all this within a single application.
The basic concept behind this is to create multiple deployment types within the single application, and optionally a fallback entry at the end if you want the software installing where none of the requirements have been met, perhaps with a generic template passed via command line.
In this example I’ve created a simple program which just drops a text file onto the C drive, with the content of the command line string, as proof of concept but this technique should work for most use cases – depending on device OU, registry setting values, or even CPU speed, RAM, Disk space. I’ve targeted device OU here, and split my VMs into two OUs – Azure and Garage (for Azure hosted VMs, and those running off a Hyper-V server in my garage).
It’s something that isn’t recommended but sometimes there’s not really much you can do otherwise – we have a set of iPad minis which are shared between multiple pupils and at the moment they are on Meraki MDM, connected to the 8021X Enterprise wireless network using a username/password which is set via the MDM profile. I really want to move these devices to Intune but you can’t create a WiFi profile with embedded credentials on Intune – presumably this was never an option for obvious reasons.
The only other option I can see is to set up SCEP and have the devices issued with certificates, and then use those to authenticate, presumably I’d also need to enable device writeback so that the NPS server can see the devices in AD. Due to the way our AD is configured (single forest with lots of domains, synced to multiple Azure AD tenancies) device writeback is unsupported, so let’s look at embedding the credentials into Intune instead. Continue reading “MEM: iOS Wireless Profile with embedded credentials”
In this part of the Intune series of posts I’m looking at getting iPads enrolled and managed, and deploying apps. In my case I’m looking to migrate some iPads from an existing MDM into Intune, so I’m assuming you already have an Apple ID set up to create the push certificates and already have Apple School Manager (or Business Manager) set up.
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.