List Packages that run in user context (Run with user’s rights)

Introduction

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


Download the script from TechNet Galleryhttps://gallery.technet.microsoft.com/Generate-a-list-of-d8778d4c?redir=0



List Applications that run in user context (Install for User)

Introduction

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 Get_Application_USER_Context_List



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.



Useful links:

PowerShell Application Deployment Toolkit: https://psappdeploytoolkit.com
Advanced Installer: https://www.advancedinstaller.com/
Access Director Enterprise: https://ctglobalservices.com/access-director-enterprise/



MSiX Insider Preview Build 1.2019.402.0

Yet another release of the MSIX Packaging tool (1904) is nearing general public release.

Here is the list of features and fixes

  1. Ability to convert on a remote machine.
    1. We talked about that earlier here
  2. Improved management experience in package editor.
    1. Auto versioning recommendations when saving in package editor.
    2. Now supports existing folder addition to package in VFS.
  3. User can specify known valid exit codes for CLI conversions.
  4. Added the ability to time stamp your signed package in all of the workflows where signing is currently available.
    1. You can specify your default time stamp URL and type of time stamp server in the tool Settings page.
  5. Updated AppID generation logic, and added additional validation fro package name and app.
  6. Bug fixes and performance improvements

The detailed history for the app release can be found here


Cleaning up shortcuts

So the issue at hand;
I was replacing a Office application on Windows systems, where i noticed that shortcuts created by the users, was not upgraded/removed when the new office version was installed.

The issue seems to be related to users creating custom shortcuts, directly to exe files.
I some cases the shortcut name was clear, but in other cases the users had chosen something they found fit.

The following PowerShell script was created to remove shortcuts (lnk files) based on the executable. This means you can specific the exe or use a wildcard if there is multiple executable files releated to an application.

$ShortcutLocations = Get-ChildItem -Recurse (“C:\Users”,”C:\ProgramData\Microsoft\Windows\Start Menu”) -Include *.lnk -Force -ErrorAction SilentlyContinue

########
# This script searches for all *.lnk files to "C:\Program files (x86)\App\My Application.exe" or "C:\Program Files\App\My Application.exe"
# It searches in C:\users\* profiles paths, including Users Desktops, %AppData%\Microsoft\Internet Explorer\Quick Launch and in ProgramData...StartMenu
# The name of the link file can have many different names, therefore we must find each shortcut based on path to target exectuable and not on lnk name.
# Then the lnk file must be deleted.
#
# The script should be run with admin rights, otherwise shortcuts will only be deleted for the user running the script.
########

### Specify shortcut's target executable here.
$AppExecutable = "C:\Program files*\Microsoft Office\Office15\*.exe"
# * Due to mask it contains "Program files" and "Program files (x86)" paths both.
###

### Paths to browse and search for shortcuts.
$ShortcutLocations = Get-ChildItem -Recurse ("C:\Users","C:\ProgramData\Microsoft\Windows\Start Menu") -Include *.lnk -Force -ErrorAction SilentlyContinue
# * -Recurse = Includes all subdirectories.
###


### Get properties for shortcuts in the locations

Function Get-ShortcutsProperties {
$Shell = New-Object -ComObject WScript.Shell 
Foreach ($Shortcut in $ShortcutLocations)
{
$Properties = @{
ShortcutName = $Shortcut.Name;
ShortcutFullName = $Shortcut.FullName;
ShortcutLocation = $shortcut.DirectoryName
ShortcutTarget = $Shell.CreateShortcut($Shortcut).targetpath
}
New-Object PSObject -Property $Properties
}
[Runtime.InteropServices.Marshal]::ReleaseComObject($Shell) | Out-Null
}
###

$ShortcutsList = Get-ShortcutsProperties

### Compare shortcut's target path with $AppExecutable and delete it in case of corresponding one
Foreach ($item in $ShortcutsList) {

if ($item.ShortcutTarget -like $AppExecutable) {

Remove-Item -Path $item.ShortcutFullName -Force -ErrorAction SilentlyContinue
 }
}
######## End of the script

Download the PowersShell Script here: DeleteApplicationShortcuts

MSiX – Remote machine conversions

The MSiX Packaging Tool (1.2019.226.0) Preview now has the ability to connect to a remote machine, where you can run the conversion.
This is great news, and solves the normal issue with contamination on “non-sanitised” machines.

I have always preferred to do my packaging and re-packaging on Hyper-V Virtual Machines
This gives a total control and clean enviroment, with easy ability to get back to a controlled point of reference, using checkpoints.

Getting started with remote machine conversions? Fear not! It is quite simple to get started.

– PowerShell remoting must be enabled for secure access to the remote machine.
– You must be logged on with administrative privileges on the machine.

To enable PowersShell remoting on the machine, run the following command in an elevated PowerShell prompt: Enable-PSRemoting -Force -SkipNetworkProfileCheck

If network/firewall restrictions are in place, remember to allow inbound traffic on port 1599 (MSiX Packaging Tool default port, it can be changed with the settings tab)

If you are connecting using a non-domain joined machine, you must use a certificate to connect over https.
To enable PowerShell remoting and allowing WinRM over https run the following commands in an elevated PowerShell prompt

Enable-PSRemoting -Force -SkipNetworkProfileCheck

New-NetFirewallRule -Name "Allow WinRM HTTPS" -DisplayName "WinRM HTTPS" -Enabled True -Profile Any -Action Allow -Direction Inbound -LocalPort 5986 -Protocol TCP

To generate a self-signed certificate, configure WinRM secure configuration and export the certificate, you can run this script: (or download: GenerateSelfsignedWinRMHTTPS)

$thumbprint = (New-SelfSignedCertificate -DnsName $env:COMPUTERNAME -CertStoreLocation Cert:\LocalMachine\My -KeyExportPolicy NonExportable).Thumbprint
$command = "winrm create winrm/config/Listener?Address=*+Transport=HTTPS @{Hostname=""$env:computername"";CertificateThumbprint=""$thumbprint""}"
cmd.exe /C $command
Export-Certificate -Cert Cert:\LocalMachine\My\$thumbprint -FilePath <path_to_cer_file>

On your locale Machine, copy the exported certificate and install it into the Trusted Root Store.
It can be imported with the following command: Import-Certificate -FilePath <path> -CertStoreLocation Cert:\LocalMachine\Root





Configuration Manager 1810 Installation – Prerequisite Check – SQL Server Native Client Version

I came across this error while adopting the Configuration Manager 1810 (Early Update Ring)

[Completed with warning]:Verifies that the version of Microsoft SQL Server Native Client installed on the site server meets the minimum requirements to enable TLS 1.2 support. https://go.microsoft.com/fwlink/?linkid=2026746

I was apparently running an older SQL Native client version, that did not support TLS 1.2 which is required for ConfigMgr 1810.
Review your SQL versions and update to a version that supports TLS 1.2:

This link provides information about the updates that Microsoft is releasing to enable TLS 1.2 support for SQL Server 2017 on Windows, SQL Server 2016, SQL Server 2008, SQL Server 2008 R2, SQL Server 2012, and SQL Server 2014. This article also lists supported client providers.

Download and install the correct update for your existing SQL version.
Reboot and proceed with the 1810 update.

If your looking for the ConfigMgr 1810 package to enable early update ring follow this link

The package adds your hierarchy or standalone primary to the early update ring for Update 1810 for the current branch of System Center Configuration Manager. The package is signed and bundled inside a signed self-extracting executable.

Note: The 1810 update is only applicable to 1710 and higher versions of System Center Configuration Manager

Windows 10 Registry tweak to disable Microsoft Edge Icon for MDT or ConfigMgr

The icon for Microsoft Edge is now placed by default in every user profile.
It is not placed in Public Desktop, but created for each user at logon (DOH!)

Thank god there is way to stop this behavior.

You can simple add the following registry key:
Key: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Explorer
Value: DisableEdgeDesktopShortcutCreation
Data: 1
Type: REG_DWORD

If your using MDT (Microsoft Deployment Toolkit) or ConfigMgr (System Center Configuration Manager)
You can add the following oneliner task sequence step, to stop the creation of the Microsoft Edge icon.
Commandline: reg.exe add HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Explorer /v DisableEdgeDesktopShortcutCreation /t REG_DWORD /d 1

In case your wondering what i have in the steps to disable Cortana, let me share them:

Registry tweaks for Build and Capture or Windows 10 Deployment task sequences

Disable Cortana Voice:
reg.exe add HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\OOBE /v DisableVoice /t REG_DWORD /d 1

Disable Cortana Search:
reg add “HKLM\SOFTWARE\Policies\Microsoft\Windows\Windows Search” /v “AllowCortana” /t REG_DWORD /d 0 /f

Disable Cortana Search Box:
reg add “HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Search” /v “SearchboxTaskbarMode” /t REG_DWORD /d 0 /f

Using SCCM CI Baseline to check for expiring user certificates

The topic is almost self explaining.

You need to monitor specific user-based certificates, to avoid a situation where they have already expired.

You can add this to your daily security compliance checklist.

Prerequisites for running CIs can be found here: Compliance Baseline prerequisites

  1. Create Configuration Item

Go to Assets and Compliance, Compliance settings Configuration Items, right click and select Create a new configuration item:

Create Configuration Item

Provide the name CI – Script – USER CERT Expiration check, leave the configuration item type as Windows and press Next:
Configuration Item Wizard

Optionally you can provide a description that gives an overview of the configuration item and other relevant information that helps to identify it in the Configuration Manager console.

Select the OS where this configuration item assumes to be applied and click Next
client operating systems that will assess this configuration item for compliance

To create Configuration Item, click New:
Create Configuration Item Wizard

Type in the name CI – Script, from drop down of settings type select Script and data type as String.

There are two options to specify where a script would reside

– Discovery Script

– Remediation Script

Remediation is not handled in this post.

To place discovery script since to evaluate compliance, click on Add Script.

Please note that this script needs to be runin the logged-on user context, therefore please check “Run scripts by using the logged on user credentials”

Create Setting

Select script language as Windows PowerShell and type in the script (see attached USER_CERT_Expiration _Discovery.ps1) in the Script field:
Edit Discovery Scripts

#

$Compliance = ‘Compliant’

$Check = get-childitem -path cert:\currentuser -recurse | where-object {$_.thumbprint -eq ‘‎‎‎‎‎‎245c97df7514e7cf2df8be72ae957b9e04741e85’}| where { $_.notafter -le (get-date).AddDays(30)}

If ($Check) {$Compliance = ‘NonCompliant’}

$Compliance

#

Script download: USER_CERT_Expiration _Discovery

and click OK

Click Next

Specify settings for this operating system

After the script is in place, you can click the “Compliance Rules” tab. Now compliance rule needs to be created. This rule will determine how the compliance is reported once the script runs on a computer (based on how the compliance a machine could be either Compliant or NonCompliant).

 

Click on New

Specify complance rules for this operating system

Type in the comSpecify rules to define compliance conditions for this settingpliance rule name and click on Browse:

Select the name of the configuration setting that just created (if not already selected and then click on Select):
Select a setting for this rule

In the Rule Type select Value and then select if the value returned is Equals to Compliant.

Click OK

Click Next
Use compliance rules to specify the condition that make a configuration item setting compliant

Next screen presents the summary of the settings, if any changes are needed then you can go back and make changes here. Click Next.

create an operating system configuration item with the following settings

Configuration Item is ready now.
The Create Configuration Item Wizard completed successfully

Next step is to create Configuration Baseline.

  1. Create Configuration Baseline

Right click Configuration baseline and create configuration baseline.
Create Configuration Baseline

Type the name of configuration baseline CB – Script – USER CERT Expiration check. Click on add and select configuration item from drop down menu.
Specify general information about this configuration baseline

Please make sure that Purpose set to Required!

Select the configuration item just created and click OK. This would finish creating configuration baseline.

Add Configuration Item

Now it is time to deploy this base line to relevant Users Collection(-s).

  1. Deploy the Configuration Baseline

    Go to configuration baseline and right click and select Deploy.
    Deploy Configuration Baseline

Select the configuration baseline CB – Script – USER CERT Expiration check.

Browse and point it to targeted Users collection (its recommended to run it for some limited collection for testing before deployment to production)

Change the evaluation schedule as per as your requirements (taking in consideration that in case of it seems to be critical for your environment, in production running this CB probably once a day is recommended)

Again, the key thing here is to be sure that you deploy this CB to users and not to your systems!

Select the configuration baseline that you want to deploy to a collection

Click OK

Note: When the configuration baseline is deployed, please allow that it can be evaluated for compliance within about two hours of the start time that you schedule.

  1. Verify that a device has evaluated the Configuration Baseline

To check it on a Windows PC client (general recommendation to do it for all targeted OS client types)

On a Device, go to Control Panel, System and Security and open the Configuration Manager applet. In the Configurations tab you’ll see what Configuration Baselines the client will evaluate at its specific schedule. Click on configurations and click on “Evaluate”, “Refresh” and then “View Report”.
As shown in the pictures below, Configuration Baseline was evaluated to be Compliant or Not
Configuration Manager Properties

Report view

Report view, non-compliant

 

Compliance baselines prerequisites for SCCM

PREREQUISITES

  1. Run Compliance Baselines on clients using SCCM

This setting is located in the Administration workspace under Overview ⇒ Client Settings ⇒ Default Client Agent Settings. Then right-click and select Properties. This will open the properties window for the client settings. By setting the “Enable compliance evaluation on clients” option to “Yes”, you enable this option in the default settings. The default schedule for evaluation is every 7 days.

You can adjust this schedule as necessary for your environment, including using a custom schedule that will allow you more control over when it runs.
The default schedule will typically be adequate for most environments.

You can also modify the default client settings, create new custom client settings, or modify existing custom client settings. You can create or modify custom client settings when you want to apply a group of client settings to specific collections.Client Settings - Default settings

 

  1. Running Powershell scripts on clients using SCCM:

    1. is to sign the script with your company trusted certificate
    2. is to set the PowerShell execution policy to “Bypass”.

    If you are not about to sign your scripts, please go to Administration->Client Settings, select the default (or create a new) Client Settings and set the PowerShell execution policy to “Bypass” in the “Computer Agent” section of the client settings. This action allows unsigned PowerShell scripts to run properly when they executed by the Computer Agent. If you don’t use the default client settings, you need to make sure the custom client settings you created are also deployed to the collection you will be checking compliance on.
    Client Settings - Powershell execution Policy

 

  1. Reporting Services Point SCCM role

    Should be installed in your environment for reporting.
    Assuming this role is already installed as reporting is a core requirement in the majority of SCCM functions.