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/



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





Poweshell under the security context of another user (RunAs)

Recently i needed to run some powershell scripts under multiple security context’s – the main reason for this was my client’s strict delegation model.

We ended up with multiple service account with rights only to the needed systems (Its not such a bad thing!)

The result was this powershell script to change security context

$SPAccountName = “<username>”;
$AccountPassword = “<password>”;
$AccountPasswordAsSecureString = $AccountPassword | ConvertTo-SecureString -Force -AsPlainText
$credential = New-Object System.Management.Automation.PsCredential(“$env:userdomain\$SPAccountName”,$AccountPasswordAsSecureString)
$SvcAccSession = New-PSSession -Credential $credential;
Invoke-Command -Session $SvcAccSession -Script { Import-Module ActiveDirectory }
Invoke-Command -Session $SvcAccSession -Script { Get-AdGroupMember “Some-group”}

In the above example we just get the member of some application group – but really, you can do whatever you like.

If you need it to query a specific server you can use -Computername <servername> right after New-PSSession.

This method also came in rather handy when running service-side powershell execution invoked by a webservice.. but more on that later

 

Unable to use Power Shell AD cmdlets on Remote Server

I came across this error when building a web service executing powershell cmdlets

When executing the commands directly on the server worked without problems

but when using New-PSSession to invoke the scripts I ended up with the following error:

WARNING: Error initializing default drive: ‘Unable to contact the server. This
may be because this server does not exist, it is currently down, or it does not
have the Active Directory Web Services running.’.
Unable to contact the server. This may be because this server does not exist,
it is currently down, or it does not have the Active Directory Web Services
running.
+ CategoryInfo : ResourceUnavailable: (:) [Get-ADObject], ADServe
rDownException
+ FullyQualifiedErrorId : ActiveDirectoryServer:0,Microsoft.ActiveDirector
y.Management.Commands.GetADObject
+ PSComputerName : localhost

Note that PSComputerName was not defined in my script – default is localhost.

To resolve the problem i did the following:

  1. Added “-Computername <Server1>” to my script file (Server1 is a domain controller, that had Active Directory Web Services running (default on Domain controllers running Windows Server 2012 R2) (Check Link for running on Windows Server 2003 and Windows Server 2008)
  2. Executed “Winrm QuickConfig” on Server1

I was searching for groups with a specific like description with the following command: get-adobject -Filter {description -like “ps1*”}

and the result with the problem solved:

PSComputerName : Server1
RunspaceId : b83f4390-36b7-4cfa-8539-279b12fce09f
DistinguishedName : CN=Application Group
1,OU=Applications,DC=ThomasMarcussen,DC=com
Name : Application Group 1
ObjectClass : group
ObjectGUID : 4c57f3b5-726b-4de7-882b-2c80b3f0fdb8

PSComputerName : Server1
RunspaceId : b83f4390-36b7-4cfa-8539-279b12fce09f
DistinguishedName : CN=Application Group
2,OU=Applications,DC=ThomasMarcussen,DC=com
Name : Application Group 2
ObjectClass : group
ObjectGUID : 70289cdd-0277-457e-bc2d-162703342f74

 

 

Change the size of a virtual machine by using a Azure PowerShell script

Finally i got around to moving my demo environment to Azure

I don’t need my environment to perform 100% while not using it, so came a cross this nice way to scale my environment on-demand.

This is possbile with a simple powershell script:

Function HowTo-SetAzureVMSize{
[CmdletBinding()]
param(
[parameter(Mandatory=$true)]
[string]$ServiceName,
[parameter(Mandatory=$false)]
[ValidateNotNullOrEmpty()]
[string]$Name=$ServiceName,
[parameter(Mandatory=$true)]
[string]$VMSize
)
PROCESS{
Get-AzureVM –ServiceName $ServiceName –Name $Name |
Set-AzureVMSize $VMSize |
Update-AzureVM
}
}
HowTo-SetAzureVMSize -ServiceName {your-cloud-service-name} -Name {your-vm} –VMSize “{your-desired-vm-size}”

Example:

Function HowTo-SetAzureVMSize{
[CmdletBinding()]
param(
[parameter(Mandatory=$true)]
[string]$ServiceName,
[parameter(Mandatory=$false)]
[ValidateNotNullOrEmpty()]
[string]$Name=$ServiceName,
[parameter(Mandatory=$true)]
[string]$VMSize
)
PROCESS{
Get-AzureVM –ServiceName $ServiceName –Name $Name |
Set-AzureVMSize $VMSize |
Update-AzureVM
}
}
HowTo-SetAzureVMSize -ServiceName ThomasMarcussen -Name TMSRV001 –VMSize “Standard_D2”

Currently not all hardware configurations are available in all locations – I tested in Western Europe.

Virtual Machine Sizes:

A0 (Shared core, 768 MB Memory)
A1 (1 core, 1.75 GB Memory)
A2 (2 cores, 3.5 GB Memory)
A3 (4 cores, 7 GB Memory)
A4 (8 cores, 14 GB Memory)
A5 (2 cores, 14 GB Memory
A6 (4 cores, 28 GB Memory)
A7 (8 cores, 56 GB Memory)

D1 (1 core, 1.75 GB Memory)
D2 (2 cores, 7 GB Memory)
D3 (4 cores, 14 GB Memory)
D4 (8 cores, 28 GB Memory)
D11 (2 cores, 14 GB Memory)
D12 (4 cores, 28 GB Memory)
D13 (8 cores, 56 GB Memory)
D13 (16 cores, 112 GB Memory)

Allowed values are:

ExtraSmall
Small
Medium
Large
ExtraLarge
A5
A6
A7
A8
A9

Basic_A0
Basic_A1
Basic_A2
Basic_A3
Basic_A4

Standard_D1
Standard_D2
Standard_D3
Standard_D4
Standard_D11
Standard_D12
Standard_D13
Standard_D14

File cannot be loaded because the execution of scripts is disabled on this system

Error when trying to execute powershell script

cannot be loaded because the execution of scripts is disabled on this system

The machine was a x64 bit Windows Server 2012 so had to set the Powershell policy for BOTH x86 and x64 to solve my problem

command: Set-ExecutionPolicy Unrestricted
The x86 version can be found here: %windir%SysWOW64WindowsPowerShellv1.0

About Execution Policies: http://technet.microsoft.com/da-DK/library/hh847748.aspx
Using the Set-ExecutionPolicy Cmdlet: http://technet.microsoft.com/en-us/library/ee176961.aspx