Creating symbolic links with PowerShell DSC


Background

In an Azure Windows VM you automatically get a temporary disk drive mapped to D: (on Linux it’s mapped to /dev/sdb1). It is temporary because the storage is assigned from the local storage on the physical host. So if your VM is re-deployed (due to host updates, host failures, resizing, etc.), the VM is recreated on a new host and the VM will be assigned a new temporary drive on the new host. The data on the temporary drive is not migrated, but the OS disk is obviously preserved from the vhd in your storage account or managed-disk.

The problem

In this specific scenario, the customer had a 3rd party legacy application that reads and writes from two directories in the D:\ drive. The directories paths were hard-coded in the application and were a couple of gigabytes in size, so copying them to the temporary drive each time the VMs were deployed would be time and resource consuming.

Choosing a solution

After thorough testing of course, we decided to create two symbolic links from the D:\ drive to the real directories in the OS disk (where the directories were already present as part of the image). The symbolic-links creation would be accomplished with either the mklink command, or with the New-Item cmdlet in PowerShell 5.x.

Of course there are other methods overcoming this challenge, such as switching the drive letters with a data-disk and moving the PageFile to the other drive letter. But we decided that the symbolic-links approach would be faster and wouldn’t require an additional data-disk, and with it, additional costs.

The implementation

Since the creation of the symbolic-links would need to happen every time the VM is created (and redeployed), we ended up adding a PowerShell DSC extension to the VM in the ARM template and since there were no built-in DSC Resources in the OS, nor in the DSC Resource Kit in the PowerShell gallery that configures symbolic-links, we wrote a (quick-and-dirty) PowerShell module and the resource to create them.

Creating the module structure and the psm1 and schema.mof files is pretty easy when you’re using the cmdlets from the xDSCResourceDesigner module:

Install-Module -Name xDSCResourceDesigner

$ModuleName = 'myModule'
$ResourceName = 'SymbolicLink'
$ModuleFolder = "C:\Program Files\WindowsPowerShell\Modules\$ModuleName"

New-xDscResource -Name $ResourceName -Property @(
    New-xDscResourceProperty -Name Path -Type String -Attribute Key
    New-xDscResourceProperty -Name TargetPath -Type String -Attribute Write
) -Path $ModuleFolder

cd $ModuleFolder
New-ModuleManifest -Path ".\$ModuleName.psd1"

The contents of the .psm1 resource file C:\Program Files\WindowsPowerShell\Modules\myModule\DSCResources\SymbolicLink\SymbolicLink.psm1 should contain the three *-TargetResource functions (Get, Set and Test):

function Get-TargetResource {
    [CmdletBinding()]
    [OutputType([System.Collections.Hashtable])]
    param (
        [parameter(Mandatory = $true)]
        [System.String]
        $Path
    )

    Write-Verbose "Getting SymbolicLink for $Path"

    $Root = Split-Path -Path $Path -Parent
    $LinkName = Split-Path -Path $Path -Leaf
    $TargetPath = $null

    $link = Get-Item -Path (Join-Path -Path $Root -ChildPath $LinkName) -ErrorAction SilentlyContinue
    if($link -and  $link.LinkType -eq 'SymbolicLink') { $TargetPath = $link.Target[0] }
    
    @{Path = $Path; TargetPath = $TargetPath}
}


function Set-TargetResource {
    [CmdletBinding()]
    param
    (
        [parameter(Mandatory = $true)]
        [System.String]
        $Path,

        [System.String]
        $TargetPath
    )

    Write-Verbose "Creating a SymbolicLink from $Path to $TargetPath"

    $Root = Split-Path -Path $Path -Parent
    $LinkName = Split-Path -Path $Path -Leaf
    Set-Location -Path $Root
    New-Item -ItemType SymbolicLink -Name $LinkName -Target $TargetPath | Out-Null
}


function Test-TargetResource {
    [CmdletBinding()]
    [OutputType([System.Boolean])]
    param (
        [parameter(Mandatory = $true)]
        [System.String]
        $Path,

        [System.String]
        $TargetPath
    )

    Write-Verbose "Testing SymbolicLink for $Path"

    $current = Get-TargetResource -Path $Path
    return (($current.Path -eq $Path) -and ($current.TargetPath -eq $TargetPath))
}

Export-ModuleMember -Function *-TargetResource

And in the configuration document, remember to import the DSC resources from the module:

configuration Main {

    Import-DscResource -ModuleName PSDesiredStateConfiguration
    Import-DscResource -ModuleName myModule

    node localhost {

        SymbolicLink 'INPUT_DIR' {
            Path       = 'D:\INPUT_DIR'
            TargetPath = 'C:\PathTo\myLegacyApp\INPUT_DIR'
        }
        
        SymbolicLink 'OUTPUT_DIR' {
            Path       = 'D:\OUTPUT_DIR'
            TargetPath = 'C:\PathTo\myLegacyApp\OUTPUT_DIR'
        }
    }
}

Now, to create the zip file containing the configuration document and all required modules:

# Create the zip package
Publish-AzureRmVMDscConfiguration .\myDSC.ps1 -OutputArchivePath .\myDSC.zip

And upload it to the blob container (used in the ARM template):

# Variables
$storageAccountName = 'statweb'
$resourceGroupName = 'rg-statweb'

# Login to Azure
Login-AzureRmAccount

# Get the Storage Account authentication key
$keys = Get-AzureRmStorageAccountKey -ResourceGroupName $resourceGroupName -Name $storageAccountName

# Create a Storage Authentication Context
$context = New-AzureStorageContext -StorageAccountName $storageAccountName -StorageAccountKey $keys.Item(0).value

# Upload the file to the blob container
Set-AzureStorageBlobContent -Context $context -Container dsc -File .\myDSC.zip -Blob myDSC.zip

Conclusion

There are usually several methods to accomplish a single task, and you should take under consideration all aspects and constrains, because one can be more effective than another.

HTH,
Martin.

Advertisements

Remove Azure Hybrid Connection objects


There is currently no cmdlet to easily remove an Azure Hybrid Connection object (from an App Service Plan).
So in a case you need to remove several connection objects, doing it from the protal is tedious.

This is why I created the following script:

HTH,
Martin.

Disabling the Scripting.FileSystemObject ComObject (When you get the 0x8002801c error)


When working with a customer to automate the hardening process (STIG: Security Technical Implementation Guide) for IIS servers, we ran into a problem (error 0x8002801c) when we tried to run the following command in order to disable (unregister) the Scripting.FileSystemObject ComObject

C:\Windows\System32\regsvr32.exe /u scrrun.dll

The 0x8002801c error translates to TYPE_E_REGISTRYACCESS. Using Sysinternal’s Process Monitor (aka procmon), we found that it was failing because of missing permissions to the following registry keys:

HKEY_CLASSES_ROOT\TypeLib\{420B2830-E718-11CF-893D-00A0C9054228}\1.0\0\win32
HKEY_CLASSES_ROOT\Scripting.FileSystemObject\CLSID

Note that adding permissions to the first key only (as suggested in Finding V-13700 @ stigviewer.com) is not enough. The command would run without errors, the validation would pass (thinking that FSO is disabled) but you could still create and use FSO objects.

So for automating the whole process, we needed to take ownership on the registry keys, add permissions to the keys, and then run the command to unregister the DLL.

This results in the following code:

HTH,
Martin.

Add permissions to a Session Configuration


Though the recommended approach would be to upgrade to PowerShell 5.1 and implement JEA (preferable with DSC and the JEA DSC module), there sometimes might be a need to programmatically add permissions to a PowerShell session configuration.

Continuing the mentioned above, and a question asked on the reddit forum, below is an example on how to add a specific permission (ACE) to the configuration session permissions (ACL):

HTH,
Martin.

Remove Profiles from a local or remote computer


A common need for a Remote Desktop Services (RDS) and/or Citrix farm admin, is to remove local profiles from a server.
Another example for this, is the question posted a few days ago in the PowerShell.org forum here.

Funny thing, about 6 years ago, I wrote a vbscript that does that. It just doesn’t filter by last used date.

Anyway, I decided to write the Remove-Profile PowerShell function:

You can use it to report all the profiles in the local computer:

Remove-Profile

To report all the profiles, except a specific profile:

Remove-Profile -Exclude Administrator

To report profiles last used in the past 90 days that would be deleted:

Remove-Profile -DaysOld 90 | Where-Object { $_.WouldBeRemoved }

To report against a remote computer:

Remove-Profile -ComputerName myRemoteServer

To report against a collection of remote computers, authenticating different credentials:

Remove-Profile -ComputerName $Computers -Credential $cred -DaysOld 90

To ignore the LastUseTime value in case the account never logged-on locally (e.g. an IIS ApplicationPool), use the IgnoreLastUseTime switch:

Remove-Profile -ComputerName WebServer01 -DaysOld 30 -IgnoreLastUseTime 

To really remove the profiles, use the -Remove switch:

Remove-Profile -DaysOld 90 -Remove

HTH,
Martin.

Embed PowerShell code in a batch file


In a certain scenario, I needed a batch file (bat or cmd extension) that runs PowerShell code, and I could have only one file, so I couldn’t go with the easy way of a batch file calling PowerShell.exe with the -File parameter specifying the path to a ps1 file.

For this, I created a special batch file with a header that reads the contents of itself, excludes the lines that have the batch code (lines stat start with @@) and then runs the rest in PowerShell.

Here is the batch template, just replace the lines below the comment that says “POWERSHELL CODE STARTS HERE” with your PowerShell code.

Though not intended, it’s another way of bypassing the ExecutionPolicy even if it’s set in Group Policy, since the code is run as commands and not a script file.

HTH,
Martin.