After I completed a recent upgrade of Windows 10 to 1803, I noticed that my English (United Kingdom) language had been joined by English (United States) and that I couldn’t remove this from the system.

After a bit of research I came across the following article that demonstrated how the additional language can be removed using PowerShell –

Nice and cleanly I no longer have the “ENG” menu in my task bar to switch to a language I don’t need.

A lot of my work recently has been working with Microsoft Intune to utilise Microsoft Modern Management constructs and principles to deliver a cloud first approach to provisioning new Windows 10 endpoints for an organisation.

Since Microsoft has migrated Intune management from the classic interface to the Azure Portal, the ability to execute installers for legacy line of business applications has been reduced. The idea is that the modern workplace is consuming data via apps from an app store and this is evident in Microsoft’s support for the Microsoft Store for Business and Universal Windows Platform .appx package support in Intune however this is not always feasible in most workplaces. There are still legacy line of business applications that require an MSI or EXE based installer and whilst Intune will support Line of Business installers that are MSI based there is again a limitation that the MSI must contain all the code required to install the application. There is currently no support for EXE based installers in the Azure Portal for Intune.

Back at Microsoft Ignite 2017, Microsoft announced the availability of the Intune Management Extension and the support to execute PowerShell scripts on Windows 10 Endpoints via Microsoft Intune (Read More). This got me thinking about how to extend the functionality of Microsoft Intune to deliver a more traditional (MDT / SCCM) provisioning process for legacy applications on modern managed Windows 10 devices.

If you could store your legacy line of business applications in a web accessible location (with appropriate security controls to prevent unauthorised access) you could then utilise the Intune Management Extension and PowerShell scripts to download the application install payload to a temporary location and then execute the payload to overcome the limitation of the Intune portal.

Looking around the Internet I came across this blog post by MVP Peter van der Woude which integrates the Chocolatey package manager and Intune. With a bit of reworking I amended the PowerShell code to download and install the AEM agent onto a target machine.

Save the PowerShell script and then add to Intune as outlined in Peter’s blog post and wait for the code to execute on your endpoint. The process can be extended to run any executable based installer.

Whilst this is a fairly simplistic example, the concept could be extended to download a compressed archive, extract and then execute the installer as required.

In the second quick article following my reporting requirement this time is to report on the enabled user accounts that have not logged in in the past X days. Again a quick Google came across the following article on WindowsITPro (Use Get-ADUser to Find Inactive AD Users)

I took the Search-ADAccount cmdlet and created some filters to exclude disabled accounts as well as enable a parameter to be passed with the script to specify the maximum age, in days, of a user account (default is 90 days)

Save the below script as Get-InactiveAccounts.ps1

To execute the script run .\Get-InactiveAccounts.ps1 to report on accounts older than 90 days or use the InactiveDays parameter to specify the age of accounts to report (eg .\Get-InactiveAccounts.ps1 -InactiveDays 180)

As part of some recent work to assist a client with reporting on their active users and the dates those users last changed their passwords I evolved a script written by Carl Gray here (PowerShell: Get-ADUser to retrieve password last set and expiry information) to generate a short PowerShell script that will report the enabled Active Directory users and the date that they last set their password.

Copy the code below and save on your server as Get-PasswordLastChange.ps1 and then run from the command line. Script will produce a CSV file and save it in the same directory as the script