Register a remote endpoint with DSC

• Context:

I’ve been using Desired State Configuration (DSC) recently on a Windows 10 computer to create a custom remote endpoint configuration.

• Issues:

Using the Register-PSSessionConfiguration with a -Force switch parameter breaks the push.
The error message says:
The WS-Management service cannot process the operation. The operation is being attempted on a client session that is unusable. This may be related to a recent restart of the WS-Management service. Please create a new client session and retry the operation if re-executing the operation does not have undesired behavior.
+ CategoryInfo : InvalidOperation: (root/Microsoft/…gurationManager:String) [], CimException
+ FullyQualifiedErrorId : HRESULT 0x803381fa
+ PSComputerName : localhost

If you specify a -Verbose switch parameter when you push the configuration with Start-DscConfiguration cmdlet, the verbose stream of the Register-PSSessionConfiguration cmdlet is still streamed although it’s explicitly turned off.

• Solution:

The solution consisted in:

1. turning off the verbose stream from the Register-PSSessionConfiguration cmdlet by enclosing this cmdlet in scriptblock executed by the Start-Job cmdlet.
2. removing the -Force switch parameter that restarts and breaks the push
3. using a -NoRestartService switch parameter with the Register-PSSessionConfiguration cmdlet

Advertisement

Create an ASCII encoded file with DSC

• Context:

I’ve been using Desired State Configuration (DSC) recently to create a cmd file on every users’ desktop.

• Issue:

DSC creates a UTF8 file with a BOM. The file is executed but not its first line. The File DSC resource doesn’t allow to specify an encoding

• Solution:

I’ve used a File resource to create the content and a dependent child script resource that removes the BOM.

# Remove BOM because File DSC resource creates a UTF8 file with BOM
[System.IO.File]::WriteAllLines(
  'C:\Users\Public\Desktop\myCmdFile.cmd',
  (Get-Content -Path 'C:\Users\Public\Desktop\myCmdFile.cmd'), 
  (New-Object System.Text.UTF8Encoding($False))
)

Quick tip: Testing volume licensing activation by a KMS

To test the volume licensing activation by a KMS (Key Management Server), you can actually do it either on the KMS server(s) or on the computer to be activated.

On a KMS server, you’d typically do:

$HT = @{
 LogName = 'Key Management Service' 
 Id =12290 
 Data = "$($TargetComputerNameFQDN)"
}
Get-WinEvent -FilterHashtable $HT -ErrorAction SilentlyContinue | 
ForEach-Object {
 [PSCustomObject]@{
  Result = ($_.Properties)[1].Value
  'Minimum count needed to activate' = ($_.Properties)[2].Value
  'KMS client FQDN' = ($_.Properties)[3].Value
  'Client Machine ID (CMID)' = ($_.Properties)[4].Value
  'Client TimeStamp' = ($_.Properties)[5].Value
  'is client VM?' = [bool]($_.Properties)[6].Value
  'License State' = ($_.Properties)[7].Value
  'Time State to expiration (min)' = ($_.Properties)[8].Value
  GUID = ($_.Properties)[9].Value
 }
}  | 
Out-GridView

NB1: I found the explanation of the values on this page
NB2: the license state value 1 means activated. 2 means OOB grace. 5 means there was a problem between the time of the KMSHost and the client (>4hours)

On a client KMS computer, you’d do:

Get-CimInstance -Query "Select * FROM SoftwareLicensingProduct WHERE ApplicationId = '55c92734-d682-4d71-983e-d6ec3f16059f' AND LicenseFamily = 'Enterprise' AND Description LIKE'%VOLUME_KMSCLIENT%'" |
Select Description,ApplicationId,LicenseStatus

NB1: In the above example, I’m looking for a Windows 10 Enterprise version. Notice the LicenseStatus set to 1 (which means it’s activated).