Microsoft Endpoint Manager is great however, if you want to encrypt Windows 10 device silently with a normal standard user logged in then you might find it difficult to do so via the MEM Portal settings. So this is where this blog post will come in handy 🙂
In order to encrypt the device silent you need to create a Custom Configuration Policy. Browse to your Microsoft Endpoint Manager Portal or Intune Portal –> Go to Device Configurations Profile –> Create New Profile
Enter a Name for the Profile
Select Windows 10 and later from Platform
Select Custom from Profile type
Select Configure from Settings
We will now need to enter the following information to configure encryption.
Once you have created the policy, assign it to your required devices and BitLocker will now encrypt the devices.
Oh but wait!!!
In my experience in performing this procedure have ran into an issue where Intune recognises the device has compliant against “Require BitLocker” but non-compliant against “Encryption of data storage on the device”.
This is due to the device not being able to backup the BitLocker Encryption Key to Azure Active Directory. The workaround for this was to deploy a PowerShell script using Intune that forces the key to be backup up.
So lets add a script to Intune which will execute the required steps; First go to Device Configuration –> Scripts –> Add
Provide a Name which will easily identify the script in the Intune Portal.
Browse to the script location on your local machine or network drive Tick Yes to Run script in 64 bit PowerShell host.
And save then assign to the required AAD Group to execute on the client macine.
I cannot take any credit for the script but it resolves the issue I encountered and my compliant policy was once again “Compliant” for all devices. I have made this script available via my GitHub account.
Office 365 ProPlus has adopted a servicing model for client updates, allowing new features, non-security updates, and security updates to be released on a regular basis, ensuring your users are always up to date with the latest functionality and improvements.
The client servicing model for Office 365 ProPlus provides options that allow organizations to manage the frequency at which features and updates are deployed using multiple release channels which can be configured for all users or a specific set of users within the organization allowing IT to manage update deployment.
The Monthly Channel is made available every month and is targetted to users that want the latest features and updates as soon as they are available.
The Semi-Annual Channel
The Semi-Annual Channel is made available every 6 months, in January/July and is best for organizations that don’t want to deploy the latest features of Office right away or that have a significant number of LOB applications, add-ins, or macros that need to be tested prior to broad deployment. This approach helps to avoid compatibility issues that can potentially stall deployments.
This channel has 18 months of support before the version will need to upgrade to the latest release of ProPlus.
The Semi-Annual Channel (Targeted)
The Semi-Annual Channel (Targeted) enables a group of early adopters who get the latest and greatest features four months in advance of a Semi-Annual release, allowing time for organizations to test the new features and updates. This is available every 6 months, in March and September.
This channel has 14 months of support before the version will need to upgrade to the latest release of ProPlus.
Below is a diagram about how the “Update Model” works.
Check out my Office Pro Plus Tool Kit script designed to assist with testing and deployments.
One of my pet hates when receiving a new laptop or device is reinstalling all the common modules that I use to complete my work. So in good old Blogabout.Cloud fashion I have created a script that installs the following
This script will also check if the module installed and if a newer version is available within the PSGallery. I have made this script available on GitHub for your downloading pleasure;
Delivering your corporate applications can be a nightmare if you dont have a enterprise delivery solution like System Center or 3rd party mechanism.
So let’s see how Azure Blob Storage and Microsoft Intune can address this issue by using a storage location and PowerShell script.
Azure Storage Account
One of the requirements for this solution is an Azure Storage Account within your Azure subscription, this account will be used for storing the applications which you would like to roll out to your Windows 10 desktops that are managed using Microsoft Intune.
Specify the required settings within the Basic tab for creating a Storage Account.
Using the default settings as shown below
Click Review and Create Click Create
Configuring Storage Account with required Applications
Click Container Specify the Name Select Conditioner (anonymous read access for containers and blobs) under Public Access Level
Select your container Select Upload Select the files you want to upload Modify the block size if it’s less than the size of the files you are uploading Select Upload
Once the files are upload they all have a unique url which is used to identify the file as shown below.
The PowerShell Script!!!
I have created a PowerShell script that is available on GitHub and should be self-explanatory.
Step 1 – Download all the required files into C:\_Build Step 2 – Run installer files Step 3 – Run additional Powershell scripts (Optional) Step 4 – Remove C:\_Build Step 5 – Create RegKeys (Optional)
Recently, I was trying to use Install-Module cmdlet to install a required module for some testing on a client machine however I ran into the following error
Install-Module: The term ‘Install-Module’ is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again. At line:1 char:1Install-Module MSOnline. CategoryInfo : ObjectNotFound: (Install-Module:String) , CommandNotFoundException FullyQualifiedErrorId : CommandNotFoundException
The error looks like below:
Install-Module : The term ‘Install-Module’ is not recognized as the name of a cmdlet, function, script file, or operable program
The error usually comes, if your PowerShell is not upto date. The major version of PowerShell should be equal or greater than 5. You can run the below cmdlets to check the PowerShell version.
My PowerShell major version was 4.
To solve the error the following steps was taken to resolve the issue.
In this post, I will look at how to modify the required Registry Keys for Windows Server 2012R2 / 2016 Update settings using PowerShell. PowerShell is one of the gems within Microsoft and enables us to work with systems without the help of a GUI.
Windows always looks at registry keys located in the following hive: HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU
Typically there is a key named ‘NoAutoUpdate’ with a value in the range 2-5, and have the following meaning:
– 1 = Disable Updates – Only supported on Windows 2012 R2. – 2 = Notify before download. – 3 = Automatically download and notify of installation. – 4 = Automatically download and schedule installation. Only valid if values exist for ScheduledInstallDay and ScheduledInstallTime. – 5 = Automatic Updates is required and users can configure it.
But if there is a ‘NoAutoUpdate’ key with the value of ‘1’, no updates will be processed by Windows.
You can change the registry key with the help of Powershell directly: