As businesses increasingly operate in hybrid environments spanning both on-premises and cloud infrastructure, the need for seamless authentication across multiple environments becomes paramount. To address this challenge, organizations are turning to automated processes for implementing and managing Cloud Kerberos Trust. This automated approach streamlines the integration of Kerberos-based authentication in diverse environments, ensuring efficient and secure access to cloud resources.
The PowerShell script Enable-CloudKerberosTrust.ps1 simplifies and automates the process of Configuring Azure AD Cloud Kerberos Trust.
To get a deeper understanding and a great story, You should also read to following article series by Ben Whitemore and Michael Mardahl who inspired the script.
1. Install Azure AD Kerberos PowerShell module
2. Prompt the user for domain admin credentials (if it detects it is not running as domain admin)
3. Create a Kerberos Server object
4. Verify a Kerberos Server object has been created successfully
5. Create "CKT-Policy" Intune configuration profile
6. Create OMA-URI for Cloud Kerberos Trust enablement
7. Assign the configuration profile
1. Azure Active Directory global administrator.
2. Active Directory domain administrator.
3. Approve admin consent for the following permissions in Microsoft Graph application in Azure AD apps:
CloudPC.ReadWrite.All, DeviceManagementConfiguration.ReadWrite.All, DeviceManagementManagedDevices.ReadWrite.All, Directory.Read.All
.PARAMETER Domain
Specifies the on-premises Active Directory domain. A new Azure AD Kerberos Server object will be created in this Active Directory domain.
.PARAMETER UserName
Specifies the UPN of an Azure Active Directory global administrator.
.PARAMETER TenantID
Specifies the Azure AD tenant ID for the new Intune configuration policy.
.PARAMETER Group
Specifies the device group to assign the new Intune configuration policy.
.PARAMETER LogPath
Specifies path to save script output to.
.EXAMPLE
.\Enable-CloudKerberosTrust.ps1 -Domain xyz.com -UserName admin@tenant.onmicrosoft.com -TenantID 0570e92c-8fb4-4775-9eb8-61f20dd2ce72 -Group Group1 -LogPath .\
NOTE: THIS SCRIPT IS CONTINUALLY BEING IMPROVED – If you would like to suggest additional checks or improvements, feel free to reach out with your input.
Autopilot is an essential tool for managing and deploying Windows devices in the enterprise. However, before deploying Autopilot, it’s important to ensure that your environment meets the necessary prerequisites. This can be a time-consuming and error-prone process, which is why we’re excited to introduce a new script that automates the prerequisite checking process.
The new script, called Autopilot Prerequisite Checker, is a PowerShell script that checks whether your environment meets the prerequisites for deploying Autopilot. The script checks for the following prerequisites:
Tenant checks:
Check license requirements
Automatic Windows enrollment (MDM authority is set)
DNS records
Check user can join device to Azure AD
Check Enrollment Status Page
Check Windows Autopilot Deployment Profile
Check company branding
Device checks:
Windows OS version
Hardware hash uploaded to Intune
Check Windows Autopilot Deployment Profile assignment status
User checks:
User is licensed correctly
Network checks:
Required communication for Intune Autopilot is allowed
The script is easy to use and can be run on any machine with PowerShell installed. Simply download the script, run it, and wait for the results. The script will output indicating whether your environment meets the necessary prerequisites for Autopilot.
The benefits of using the script are numerous. First and foremost, it saves time by automating the prerequisite checking process, allowing you to focus on more important tasks. Second, it reduces the risk of errors, ensuring that your Autopilot deployment is successful the first time. Finally, it provides peace of mind by giving you the confidence that your environment meets the necessary requirements for deploying Autopilot.
In conclusion, Autopilot Prerequisite Checker is a powerful new script that simplifies the process of checking the prerequisites for deploying Autopilot. Whether you’re an IT administrator or a consultant, Autopilot Prerequisite Checker is an essential tool for ensuring the success of your Autopilot deployment.
NOTE: THIS IS A WORK IN PROGRESS – If would like me to add a check, just ping me the info 🙂
Powershell script to download a users OneDrive content.
New and improved: Download-OD4BAccount.ps1
.Example
.\Download-OD4BAccount.ps1 -Username User@SampleTenantName.onmicrosoft.com -Destination "D:\OD4B" -ThreadCount 3 -Verbose
Script prerequisites:
1. Microsoft Graph PowerShell Module installed on local machine. The script automatically checks for and installs module if needed.
2. An Azure AD user that has an admin consent to approve the following permissions in Microsoft Graph application in Azure AD apps:
Organization.Read.All, User.Read.All, Directory.Read.All
This was inspired by Adnan's script, which i have used on multiple occasions.
But when downloading very large OneDrive data structures, Multi-Threads seems to work faster and smoother.
Microsoft Intune is one of those brilliant products that has helped to optimize IT infrastructure for many businesses. It’s a platform that can transform your business into a modern workplace. And its capabilities are almost without limit. If you want to upload PowerShell scripts in Intune, there is the Microsoft Intune management extension (IME) that you can use for that. This management extension can enhance Mobile Device Management (MDM) resulting in a simpler move to modern management. With all this done, you can then run these scripts on Windows 10 devices. PowerShell scripts are important in a lot of different use cases and this blog is going to take a look at what this technology can do.
What is PowerShell?
PowerShell is a scripting and automation platform belonging to Microsoft. It’s an amazing product that is both a scripting language as well as an interactive command environment that is built on the .NET framework. Released back in 2006, PowerShell was basically a replacement for Command Prompt as the default method for automation of batch processes and creation of customized system management tools. PowerShell can easily automate laborious admin tasks by combining commands known as cmdlets and creating scripts. Available in all Windows OS starting with Windows 2008R2, PowerShell plays a huge role in helping IT professionals configure systems.
Adopting modern management
Modern workplaces now have plenty of user and business-owned platforms allowing users to work from anywhere. With MDM services like Microsoft Intune, you can manage devices that are running Windows 10. The Windows 10 management client will communicate with Intune to run enterprise management tasks. Windows 10 MDM features will be supplemented by IME. With this in place, you can create PowerShell scripts to run on Windows 10 devices e.g, creating a PowerShell script that does advanced device configurations. Having done this, you can upload the script to Intune and assign the script to an Azure AD group. Then run the script. Moreover, you can monitor the run status of the script from start to finish.
Latest updates from Microsoft
In November 2020, Microsoft announced the general availability of PowerShell 7.1 which is built on the foundation of PowerShell 7.0. The goal was to bring about improvements and fixes to the existing technology. Some of these features, updates, and breaking changes include:
PSReadLine 2.1.0, including Predictive IntelliSense
PowerShell 7.1 has been published to the Microsoft Store
Installer packages have been updated for new operating system versions with support for ARM64
4 new experimental features and 2 experimental features promoted to mainstream
A number of breaking changes that improve usability
Using scripts in Intune
Before IME can automatically install, when a PowerShell script or a Win32 app is assigned to the device or user, a few prerequisites should be met:
Windows 10 version 1607 or later, Windows 10 version 1709 or later for devices enrolled using bulk auto-enrollment.
Devices joined to Azure AD including Hybrid Azure AD-joined which consists of devices that are joined to Azure AD, and are also joined to on-premises Active Directory (AD).
Devices enrolled in Intune namely devices enrolled in a group policy, devices that are manually enrolled in Intune, and co-managed devices that use both Configuration Manager and Intune.
Script policy creation
Start by signing in to the Microsoft Endpoint Manager admin center. From there you’ll select Devices then PowerShell scripts then add. Under Basics, you will then have to provide a name and a description for the PowerShell script. Next, you go to Script settings and you’ll have to enter the required properties. After that, you select Scope tags, however, these are optional. And then select Assignments > Select groups to include and an existing list of Azure AD groups will be shown. Lastly, in Review + add, you’ll see a summary of the settings you configured. Select Add to save the script. When you have done so, the policy is deployed to the groups you chose.
Important considerations
If you have scripts that are set to user context with the end-user having admin rights, by default, the PowerShell script runs under the administrator privilege. Also, end-users don’t need to sign in to the device to execute PowerShell scripts. The IME agent checks with Intune once per hour and after every reboot for any new scripts or changes. In the event of a script failing, the agent attempts to retry the script three times for the next 3 consecutive IME agent check-ins. And as far as shared devices are concerned, the PowerShell script runs for every new user that signs in.
PowerShell scripts limitations
Although with Microsoft Intune you can deploy PowerShell scripts to Windows 10 devices, there are a few limitations worth noting. These include:
You won’t get support for running PowerShell scripts on a scheduled basis.
Although you can see whether the PowerShell script execution succeeded or failed, the output generated is only available on the endpoint that executes it and is not returned to the MEM Admin Portal.
Since executed PowerShell scripts are visible in the Intune Management Extension log file as plain text, credentials can’t be passed securely.
The Intune Management Extension agent responsible for executing PowerShell scripts on the endpoints only checks once an hour for new scripts so there is a delay with execution.
Wrap up about Microsoft Intune
Maximizing the time we have is increasingly a massive concern for most organizations. Technological innovation has made it such that we can have more productive time on our hands. PowerShell is a product that is very useful to IT professionals for overall system management. By being able to automate the administration of Windows OS and other applications, organizations can operate more efficiently. The evolution of this platform since its release fourteen years ago has seen it grow from strength to strength. Undoubtedly, this is a product that can easily boost your productivity.
After last weeks post with the script sample to list Packages that run in user context, there where some good feedback from people still using packages, and requiring a list of packages that install within the user context (Run with user’s rights / Execution mode as user)
It seemed that many was still using Packages, either as a result of legacy migration or to avoid some application re-packaging.
So here is the followup post, with a new script to list all packages and package with programs that run in user context.
From my point of view, its still the same; Using PSADT pretty much any package can be converted to be installed as system, and the needed stuff (registry keys, files etc) in the user context can be added in a structured and controlled way.
I do still come across some applications that i would prefer to have in MSI with all settings etc added, at least for simplicity, for those packages I still prefer to use Advanced Installer. When talking Advanced Installer, they also have a great support for MSIX, that makes to process so much easier and cost efficient.
This script will list all packages with programs, that is configured to install as user (within the user context)
All you need to do is configure the path to your import module and set the site code.
A file will be created in “C:\TEMP\Packages_and_Programs_Run_Mode_List.csv” with the following format:
“Package Name”,”Package ID”,”Program Name”,”Run with USER’s right” “My Application”,”BB10001D”,”execute”,”TRUE
With the example above we have a package ‘My Application’ that has a run mode configured: Run with user’s rights
Properties on the program, where the program run enviroment is configured to Run with Users’s rights
When deploying applications sometimes they are created to install within the active users context. This means that the actual installation requires the users to have the needed permissions to the filesystem, registry and etc. In some cases local administrative rights are needed to perform the application installation, this is not a good practice.
As applications mature for the modern design of the Windows Operating System or we choose to remove the users administrative rights due to security reasons, we may need to list and change the behavior of existing Applications.
This script was created to list applications that is configured to run with Installation behavior: Install for User
The actual output will end up in the export csv file
Script Download [download id=”893″]
Today with the modern management tools and applications, the users should not have local administrative rights on a permanent basis. Most, if not all applications can be repackaged to deploy without the need for administrative rights.
The host was installed with Windows Server 2016.
This means Hyper-V is a feature that we just need to enable – yay!
Open a elevated PowerShell prompt
Run the command: Install-WindowsFeature -Name Hyper-v -IncludeManagementTools -Restart
The command will automatically reboot once installed
NOTE: In some cases you will have to enable Intel-VT in BIOS.
You can read more about the system requirements here: Systems Requirements for Hyper-V on Windows Server 2016
For the actual setup of guests machines, I will be running mostly Windows Server 2016, Windows 10 and maybe a Linux guest or two.
Don’t forget to review: Supported Windows guest operating systems
Now to the Hyper-V Switch configuration:
I am going to add an external switch, as my client is already connected to the network on the correct vlan.
Keep in mind I got a seperat USB NIC with 2 Ports (USB 3.0 to Dual Port Gigabit Ethernet Adapter NIC w/ USB Port)
This means i will be able to have my on-board primary NIC only for management and use one of the other free ports only for VMs.
Open Hyper-V Manger
Mark your server
Click Virtual Switch Manager in the actions pane
Mark External
Click Create Virtual Switch
Name your switch – Example: External – 254 (254 indicating the vlan)
Remove the checkbox in Allow management operating system to share this network adapter
Click Ok
You might get a warning that pending network configuration will prevent remote access to this computer – If your connected to the server using another NIC, you will not be disconnected.
This concludes the basic configuration of the Hyper-V host.
We installed Hyper-V and configured a switch with external access.
The next post will be more detailed with the actual Hyper-V guest installations
The reason for having the OS on a separate volume: Deduplication is not supported on system or boot volumes. Read more about Deduplication here: About Data Deduplication
Now we installed data Deduplication and it’s ready for configuration.
My Raid 0 volume is D:
The volume will primarily hold Virtual Machines (Hyper-V)
I’m going to execute the following command: Enable-DedupVolume D: -UsageType HyperV
You can start the optimization job and limited (if needed) the amount of consumed memory for the process: Start-DedupJob -Volume “D:” -Type Optimization -Memory 50
You can get the deduplication status with the command: Get-DedupStatus
The currently saved space on my volume is 46.17 GB
That is for a 2 ISO files and a reference machine for Windows Server 2016 and the reference disks copied to separate folder.
I do love deduplication especially for virtual machines, hence most of the basic data is the same.
The disks are also rather expensive so getting the most out of them is preferred.
