Author: jonathan

Categories
Intune / MEM Powershell SCCM / MECM

PSADT + ServiceUI + 0x8007FFFF

During application deployments, it is often necessary to inform active users of an ongoing installation. Many endpoint admins accomplish this by using PSADT with ServiceUI.

The combination facilitates a user interface if an explorer.exe process is running.

However, ServiceUI’s functionality relying on an active user session can lead to failures if no user is logged-in.

The script below solves this by:

1. Checking for an active user session.
2. If a user is present, running Deploy-Application.exe via ServiceUI.
3. If no user is present, running Deploy-Application.exe directly.”

Add the script to root of your PSADT toolkit and use the following install command in Intune:
Powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\DeployServiceUIOptional.ps1

Categories
Uncategorized

AppLocker policy, where are you?

Without prior experience with AppLocker policies, one may assume launching gpedit.msc would show the AppLocker policies pushed out via Intune. That is not the case. To find the policy files take a look in C:\Windows\System32\AppLocker. Notice files with AppLocker file extension and the folder named “MDM”. Digging through the folder will reveal the policies pushed from Intune. The “Policy” files contains the configuration from the CSP.

blank

blank

blank

Categories
Uncategorized

SID 500 LAPS

This isn’t a rant, but more so me explaining why I’ve chosen this route in basic English. Before we began assigning random passwords to our Administrator accounts using solutions like Local Administrator Password Solution (LAPS), it was encouraged to disable the built-in Administrator account. Now that we have such solutions that are easy to use and more secure, should we still disable the built-in Administrator account?

The latest [Windows] LAPS has been a hit. It’s been easy to use since it’s baked into the latest versions of the Windows operating systems and able to work with Entra and Active Directory joined devices. The hardest decision most have is whether to use the built-in Administrator account or create another account. This has been the debate, because we’ve been told to not use the built-in Administrator account forever. Should we still be doing this?

What’s really the functional benefit now? I can’t really argue why we should continue with this practice. With Windows LAPS you are able use secure passwords that are unique to each machine. One feature of Windows LAPS is the ability to have the password change automatically after its used.

When using a custom Administrator account, it is tracked by the name. If the account is renamed Windows LAPS can no longer manage it. One of the security risks with using the built-in Administrator account was it’s well known SID. But this SID is also how Windows LAPS tracks the account meaning if the account was renamed LAPS is able to continue managing it. If you are using Windows LAPS you are not concerned

Windows LAPS should be thought of as a disaster recovery solution. Technicians should have another account they use for day-to-day administration. Renaming the built-in Administrator account has no effect on Windows LAPS ability to manage the password. The built-in Administrator account also can’t be locked out. Windows LAPS can also manage the account even if it’s disabled, so if you want LAPS to manage the password but leave it disabled until you need it, that is an option.

So…

Is it insecure? Should we be updating these security baselines? Does this topic require reevaluating?

Categories
SCCM / MECM

ADK 25398, Bitlocker failure

The release of Sept 2023 ADK was met with some backlash regarding the removal of VB script support. Although powershell has taken over, VB scripts are still used by many during OS deployment. In my environment, the ADK broke my hta configs for Lenovo BIOS configurations, MDT integrated gather step (I’ve been planning to move to powershell for this anyway), and bitlocker. Yes Bitlocker..?

Failed to run command line ‘X: \windows\system32\manage-bde. exe -on C: -used’ with exit code 2147942402

(Install Operating System) has failed and the execution has been aborted. An action failed. Error 0x80004004

 

With SCCM 2211 and ADK 25398 I ran into the bitlocker pre-provision step failing. Giving me an exit code 0x80004004.

The workaround Microsoft has posted on the MS Learn page dif not correct the issue. This seems to be a different bitlocker issue. In my case Bitlocker doesn’t seem to have issue taking ownership of the TPM.

This workaround however is working:

1. Disable your current Bitlocker Pre-provision step.

2. Create a new group

3. Add 3 new run command steps.

4. The first new run command step should delete the registry key. reg delete HKLM\SYSTEM\ CurrentControlSet\Control\MiniNT /f

blank

5. The second new run command step should pre-provision Bitlocker. Customize the command to match your encryption requirement.

blank

6. The third run command step will recreate the registry key we deleted in the previous step. reg.exe add HKLM\SYSTEM\CurrentControlSet\Control\MiniNT /f

blank

The MiniNT key is interesting. When present it basically kicks Windows into WinPE mode. What we’re doing is taking the OS out of WinPE mode temporarily, running the expected Bitlocker command, and throwing the machine back into WinPE mode. You may ask, “why not use the built-in pre-provision step in-between the registry edits?” When the pre-provision step is executed it will determine it’s not in WinPE mode, and will execute a different command which will fail.

Categories
Uncategorized

No Toggling Teams

The new, highly optimized Microsoft Teams is available. Want to test it out? Just toggle the “Try the new Teams” switch at the top of Teams. Is it missing?

Try this.

  1. Head over to Teams Admin ( https://admin.teams.microsoft.com )
  2. Under Teams, click Teams Update Policies.
  3. Create a new Teams update policy by clicking Add
  4. Give the policy a name, description, and select the appropriate preview feature availability. For “Use New Teams client” option, select either “Classic Teams as default” OR New Teams as default. Both of these options allow the user to switch between Classic Teams and New Teams. The Microsoft controlled option allows Microsoft to decide whether the “User New Teams client” toggle switch is displayed (based on readiness).blank
  5. After clicking Apply, add users to the policy by selecting the new policy and clicking Assign users. I previously assigned the policy to a group, but did not see the toggle. Adding my users directly to the policy did the trick.blankAfter some time, the toggle switch to try thee new Teams will be visible.blankblankblank
Categories
SCCM / MECM

2012 R2 no more

Here are tips for upgrading your Windows Server 2012 R2 boxes, specifically SCCM.

1. Snapshot/Backup your VM.

2. Apply your Windows and SQL updates.

3. According to Microsoft, Windows Server 2012 R2 can be upgraded directly to Windows Server 2019. From 2019 you can upgrade to Windows Server 2022. Some claim you can go directly from Windows Server 2012 R2 to 2022, but I’m sticking to Microsoft’s recommendation when it comes to in-place upgrades.
https://learn.microsoft.com/en-us/mem/configmgr/core/servers/manage/upgrade-on-premises-infrastructure

4. Uninstall System Center Endpoint Protection prior to upgrading. Windows Defender is included in later Windows Server releases.

5. Uninstall Windows Management Framework 5.X (KB3191565) prior to upgrading to avoid WMI repository.

6. Do not uninstall WSUS role or your Software Update Point. Instead, after the upgrade run WSUSUTIL Postinstall

“C:\Program Files\Update Services\Tools\wsusutil.exe” postinstall SQL_INSTANCE_NAME=”SQLSERVER\SQLINSTANCE” CONTENT_DIR=E:\WSUS

7. After upgrade is complete, install Windows updates.

8. Check SCCM services
9. Run a site reset


If upgrade fails because corrupted component store
Dism restorehealth from install media instead of SxS

One issue I ran into was the upgrade failing even after dism restorehealth repaired successfully. Turned out AppRepository was corrupted. This was confirmed by simply running Get-AppxPackage.

I fixed this by running command prompt as system (Psexec.exe -s -i cmd.exe) and deleting the files within %SYSTEMDRIVE%\ProgramData\Microsoft\Windows\AppRepository. Simply reboot and Windows will rebuild the AppRepository database files.

Categories
Intune / MEM

Building a working Kiosk

Intune has the ability to provision Kiosk mode on Windows devices. There are 2 available modes; single app or multi-app. This post will focus on single app mode, but the logic applies for both.

Kiosk mode was something I’ve previously done using provisioning package. Downside of using provisioning packages comes into play when something needs to be changed. With Intune, however, you can configure changes from the portal and sync them down.

Something else that is a plus with a Intune is Autopilot, more importantly for Kiosks, self-deploying Autopilot. Thats right. You can take a Windows device out the box, power it up with an network connection, and it will automatically enroll itself and apply its configuration.

To begin I will assume you are familar with Autopilot and have devices registered. These devices will require TPM 2.0 in order for Self-Deploying mode to function.

  1. Create a self-deploying Autopilot deployment profile and deploy it to your machines you want to be kiosk.blank2. In Configuration Profile, create a Kiosk profile type from Templates. This basically will set what your kiosk displays, e.g. website. If you want to display a Win32App or multiple apps, you must use Multi app kiosk mode, but mine will be displaying a webpage. Deploy this profile to your Kiosk group.blankWord to the wise: The options are pretty self-explanatory, but User Logon Type “Auto Logon” can be sensitive. This creates a user named “KioskUser0” with a blank password. The auto logon function can be broken by different policies. I’ve learned to keep the number of policies and profiles applied to Kiosk machines to a minimum. My kiosks only receive the configurations seen on this page along with; LAPS, our Root CA cert, and Wi-Fi. By all means apply what you need, but I suggest KISS (Keep it stupid simple).
  2. Create another Configuration Profile that will contain several settings from the Settings catalog. These settings will deal with power settings and such. I expected some of these to be configured by the Kiosk template, but I also understand why the separated it out. Lets start by configuring the System > Power Management settings in Administrative Templates:
  • Under Hard Disk Settings,
    • Enable “Turn off the Hard Disk” for both plugged in and battery. Set the values to 0.
  • Under Sleep Settings
    • Enable “Specify the system hibernate timeout” for both plugged in and battery. Set the values to 0.
    • Enable “Specify the system sleep timeout” for both plugged in and battery. Set the values to 0.
    • Disable “Require a password when a computer wakes” for both plugged in and battery.
  • Under Video and Display Settings
    • Enable “Turn off the display” for both plugged in and battery. Set the values to 0.
  • Lets navigate out of Administrative Templates to Power.
    • “Lid Close Action” for both plugged in and battery to Take No Action.
    • Set “Select Power Button” action to Take No Action.
    • Set “Select Sleep Button” action to Take No Action.

Extra pre-caution. Some kiosk devices may be used by end users who AAD credentials. To prevent them from logging I add an additional settings.

  • Under User Rights
    • Select Allow Local Log On. Add the follow SID: *S-1-5-113

This will only allow local accounts to log in. Use a LAPS account or create another local user if needed.

  • Under Task Manager
    • Select and Block “Allow End Task”.

Save this profile and deploy it to your Kiosk devices.

4. Create a simple powershell one-liner to disable the KioskUser0 from being able to change its password. Upload the powershell script and deploy it in system context to your Kiosk devices.

blank

5. Power up your Windows devices that you’ve assigned the self deploying profile. Make sure they have a network connection, and make sure you’ve deployed a wireless profile if the device will use a wireless connection in the field.

Categories
Intune / MEM Powershell

User context installs via Intune

There are two contexts when installing applications: User and System. The application either installs within the USER’s profile such as %LocalAppData% or to a SYSTEM directory that everyone can access like %ProgramFiles%.

Recently I was informed that we would be using CollegeBoard’s Bluebook for testing. CollegeBoard apps haven’t been my favorite to work with in the past, but that’s another story. Looking over the application’s requirement page, it must be installed in user profiles with user given full read/write permission to the directory for auto updates.

Test silent install in a VM, update AppLocker policy if being used, gather uninstall information if written to the registry, and test silent uninstall in a VM.

Create a simple install.cmd file which contains the silent install command.

blank

Create a simple uninstall.cmd file which contains the silent uninstall command. More than likely the uninstall file will be located in the user’s profile. Use environment variables like %APPDATA%.

blank

Create a detection script that will compare the file version of the application’s executable. The path will point inside of the user’s profile so of course we will use variables again. Feel free to use and modify the script below. Remember this is a powershell script, so you must environment variable use $env.

blank

Package these files up with Intune’s Win32 packager and deploy to your users.

Categories
Uncategorized

Whats your lab?

New endpoint administrators and those interested into getting there hands dirty often ask about home lab setups. Some feel the need to use what the ‘MVPs’ use; VMWare, NUCs, Hyper-V, etc. My opinion… use what you have, but remember the more equipment you use that is similar to your work environment, the more knowledge you’ll walk away with.

My lab set up is an old Lenovo ThinkServer TS140. I’ve had this thing for almost 10 years now. It has an old E3-1245v3 processor, 32GB of RAM, and a couple TB SSDs.

Most of my previous workloads have moved to a NAS over the years since docker has gotten nice, so now its primarily a lab server.

My hypervisor of choice is ProxMox VE. I’m a Linux guy and have been so since the late 2000’s. I officially stopped dual booting in the early 2010’s and stopped distro hopping around 2013. Fedora (Gnome) is where I landed if interested. The only non-Linux machines I use are the lab VMs and an iPad for reading. I consider my Pixel phone Linux :-).

blank

 

Categories
Azure Intune / MEM

Configure Windows LAPS in Microsoft Intune

Microsoft recently released Windows LAPS to the public for a preview. Local Administrator Password Solution is a security solution to randomize and rotate local administrator(s) passwords. This solution was widely used in the Enterprise to prevent lateral movement throughout the environment due to administrator accounts typically having the same password on all devices. LAPS was previously an additional install and AD schema extension. Microsoft has decided to build this security feature into recent releases Windows 10 and 11. The following guide you to setting up a LAPS policy in Microsoft Intune.

1. Navigate to Azure Active Directory in Entra. Under Devices, open All Devices and click Device settings. Set “Enable Azure AD Local Administrator Password Solution (LAPS) (Preview)” to Yes.

blank

2. Navigate to Endpoint Security in Intune. Select Account Protection under Manage. Create a new policy for Windows 10 and later platform and Local admin password solution (Windows LAPS) profile. Do the usual; name and description.

blank

3. Configure your LAPS settings to align with your organization’s strategy.

blank

 

Tips:

Legacy LAPS and Windows LAPS do not play well together, so chose which one your organization will use. Microsoft recommends migrating Windows LAPS using the emulation mode.

Backup Directory must be compatible with join type obviously; Azure AD Join devices can’t write to an on-prem Active Directory.

Setting the Backup Directory to Disabled will assign a password that you won’t know. Some will use this option until the need arises in which they add the device to a different policy that will assign a password thats backed up. Those feel this is more secure.

LAPS does not create the administrator account yet. This account must be created on the device before the policy is applied. For this reason, some are opting to use the **built-in Administrator account which has been viewed as bad practice for some time (this account was usually assigned a random password and disabled in Windows).

Post Authentication Actions instructs what should happens after a password is used. How secure do you want to be? (1) Reset password, (3) Reset password and terminate any of that accounts sessions, (5) Reset password and reboot the device.

Post Authentication Reset Delay is how long after the LAPS password is used will the Post Authentication Actions run.

blank

4. After your settings are configured, you are ready to select you device groups you wish the LAPS policy to apply to. Targeting devices are recommended though the capability to target users is available. If you target users you may potentially have LAPS passwords rotating frequently.

** If using the built-in Administrator account, you will need to enable it. Create a configuration profile that contains the Setting “Accounts Enable Administrator Account status” which is found under Local Policies Security Options. Set this to Enabled and deploy it to your target devices/groups.blank