I have 30+ Windows 2012 r2 servers, each with 30+ Zebra printers installed.
I want to be able to use PowerShell import (and export) the human readable .DRS files that can be generated with the print management UI in both the Preferences and Default locations.
I have seen lots of mentions of this: RUNDLL32.EXE PRINTUI.DLL,PrintUIEntry for import/export settings, but the file is not particularly readable, does not conform with requirements to store .DRS files, and I can't seem to get it to import the settings anyway.
I have admin on these servers, I am open to using the reg. but my understanding is that Zebras do custom things in the Devmode key - so it is not just a simple reg dump and conversion
I can use Get-PrintConfiguration and Get-CimInstance but not seeing Darkness, Speed, etc. in these outputs
$printerName = "Zebra_1"
$compNameSource = $env:COMPUTERNAME
$Printer = Get-CimInstance -ClassName Win32_Printer -Filter "Name='$PrinterName'"
$somePrinterConfig = Get-PrintConfiguration -ComputerName $compNameSource -PrinterName $printerName
$Printer.PSObject.Properties | ForEach-Object {
$_.Name, $_.Value
}
$somePrinterConfig.PSObject.Properties | ForEach-Object {
$_.Name, $_.Value
}
output:
Name : Caption
Value : Zebra_1
CimType : String
Flags : Property, ReadOnly, NotModified
IsValueModified : False
Name : Description
Value :
CimType : String
Flags : Property, ReadOnly, NotModified, NullValue
....
.DRS file:
[FileInfo]
Type=Driver Configuration File
Printer Type=201
[Barcodes]
BarcodeNum=6
[BARFONT0]
Name=EAN 13
UseHeight=1
JoinMode=2
StripTrailingSpaces=1
Kind=0
ID=1
Height=160
Expansion=1
Ratio=16908546
Flags=6164
…
[Parameters]
PaperSize=256
FormName=U
PageWidth=508
PageHeight=254
HDPI=300
VDPI=300
Orientation=3
Quantity=1
Cutter=0
BatchCut=0
Darkness=26
Speed=2
…
Related
Right now I'm running
Get-CimInstance -ComputerName $i.DNSHostName -Class CIM_Processor | Select-Object "Name", "NumberOfCores" | Export-Csv -Path .\test.csv -NoTypeInformation -Append`
This will put the CPU name and core count in a CSV fine but how can I add in the hostname as another column?
This is a good case for using a PsCustomObject, which allows you to dynamically create an object with arbitrary properties/values.
$cimProcessor = Get-CimInstance -ComputerName $hostName -Class CIM_Processor
$row = [PSCustomObject]#{
ComputerName = $hostName
Name = $cimProcessor.Name
NumberOfCores = $cimProcessor.NumberOfCores
}
$row | Export-Csv -Path test.csv -NoTypeInformation -Append
In the case where you want to retrieve information from a remote machine first, then you can skip the calculated property and simply select the PSComputerName property instead:
Note: The ellipses ... indicate the code before or after from your original sample.
... | Select-Object PSComputerName, Name, NumberOfCores | ...
Any cmdlet which connects to remote systems via WinRM should have this property automatically set when data is returned over a remote session.
If you are running this from a local session, you could use Select-Object to create a calculated property, then call the hostname command to populate its value:
... | Select-Object "Name", "NumberOfCores", #{
Name = 'ComputerName';
Expression = { hostname };
} | ...
This solution is often suitable for cross platform scripts since a hostname binary is available out of the box on Windows, MacOS, and most major distributions of Linux.
Explaining Calculated Properties
Calculated properties work by defining a hashtable in a specific format and providing the hashtable as a property to be computed just as you would use a string for a real property on the object:
$property = #{
Name = 'PropertyName';
Expression = { 'ScriptBlock' };
}
# Note that the hashtable can be specified inline as shown above
# or as a variable like shown here
[PSCustomObject]#{ Name = 'Bender'; Loves = 'Bending' } |
Select-Object Name, Loves, $property
Keep in mind that within the Expression ScriptBlock, $PSItem/$_ is set to the current object in the pipeline. Use this to reference static or instance properties from the current object you are selecting information from.
Question
Should the script block of Invoke-Command, when run with a PSSession, always run on the remote computer?
Context
I ran the below powershell against a list of servers:
Clear-Host
$cred = get-credential 'myDomain\myUsername'
$psSessions = New-PSSession -ComputerName #(1..10 | %{'myServer{0:00}' -f $_}) -Credential $cred
Invoke-Command -Session $psSessions -ScriptBlock {
Get-Item -Path 'HKLM:\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters'
} | Sort-Object PSComputerName
# $psSessions | Remove-PSSession
This returned:
Hive: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos
Name Property PSComputerName
---- -------- --------------
Parameters MaxPacketSize : 1 myServer01
MaxTokenSize : 65535
Parameters MaxPacketSize : 1 myServer02
MaxTokenSize : 65535
Parameters MaxPacketSize : 1 myServer03
MaxTokenSize : 65535
Parameters MaxPacketSize : 1 myServer04
MaxTokenSize : 65535
Parameters MaxPacketSize : 1 myServer05
MaxTokenSize : 65535
Parameters MaxPacketSize : 1 myServer06
MaxTokenSize : 65535
Parameters MaxPacketSize : 1 myServer07
MaxTokenSize : 65535
Parameters MaxPacketSize : 1 myServer08
MaxTokenSize : 65535
Parameters MaxPacketSize : 1 myServer09
MaxTokenSize : 65535
Parameters MaxPacketSize : 1 myServer10
MaxTokenSize : 65535
All looks good; onlyl I'd not expected to see these values / I was running this as a quick sense check before setting the values on these servers to ensure I didn't overwrite anything.
I had a quick look at one of the servers using regedit; and found that MaxTokenSize and MaxPacketSize did not exist.
I then amended the command to use Get-ItemProperty instead of Get-Item:
Invoke-Command -Session $psSessions -ScriptBlock {
Get-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters' -Name 'MaxTokenSize'
} | Sort-Object PSComputerName
This time I got 10 errors:
Property MaxTokenSize does not exist at path HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters.
+ CategoryInfo : InvalidArgument: (MaxTokenSize:String) [Get-ItemProperty], PSArgumentException
+ FullyQualifiedErrorId : System.Management.Automation.PSArgumentException,Microsoft.PowerShell.Commands.GetItemPropertyCommand
+ PSComputerName : myServer01
# ... (and the same for the other 9 servers, with only PSComputerName changing)
Regarding where the values that were returned came from... they're from my local machine. Amending my local registry entries and rerunning the original command showed all "servers" as having the new value.
I'm guessing this is a bug; but because I've not played with PSSessions much so far wanted to check here in case it's an issue with my understanding / usage of these commands, or if there are known gotchas to watch out for when using PSSessions.
tl;dr:
The root cause is a bug in the formatting instructions for registry keys (as of Windows PowerShell 5.1.18362.125 and PowerShell Core 7.0.0-preview.2) leading to the unexpected mix of remote and local information - see GitHub issue #10341.
As an aside: Similarly, PowerShell's ETS (extended type system) can introduce problems too, as shown in Mathias' answer here.
The best workaround is to simply use Get-ItemProperty (without a -Name argument) instead of Get-Item.
Mathias R. Jessen has provided the crucial pointer in a comment on the question, and js2010's answer provides a limited workaround and a pointer to the root cause, but it's worth providing more background information:
PowerShell comes with formatting instructions for type Microsoft.Win32.RegistryKey, as output by Get-Item with a registry path.
These formatting instructions define a calculated column named Property for the default (tabular) view, which helpfully shows a summary of the output registry key's values, which involves accessing the registry again, using Get-ItemProperty as shown in js2010's answer.
However, that behind-the-scenes Get-ItemProperty call always accesses the local registry - even when the keys were retrieved from a different machine, via PowerShell remoting, so you'll end up with a spurious mix of remote and local information.
Note that, technically, when Get-Item is run remotely, what you receive locally is an approximation of the original Microsoft.Win32.RegistryKey object, due to the serialization and deserialization involved in remoting. This approximation is a custom object with static copies of the original object's property values, and its (simulated) type name is Deserialized.Microsoft.Win32.RegistryKey - note the prefix.
PowerShell applies formatting instructions based on the full type name of output objects, but in the absence of a specific instructions or a given Deserialized.<originalTypeName> type, PowerShell applies the instructions for <originalTypeName>, which is what causes the problems here.
A - cumbersome, but edition-agnostic[1] - way to see the problematic formatting instruction is to run the following command:
(Get-FormatData Microsoft.Win32.RegistryKey -PowerShellVersion $PSVersionTable.PSVersion).FormatViewDefinition.Control | % {
$colNames = $_.Headers.Label
$colValues = $_.Rows.Columns.DisplayEntry.Value
foreach ($i in 0..($colNames.Count-1)) {
[pscustomobject] #{
ColumnName = $colNames[$i]
ColumnValue = $colValues[$i]
}
}
} | Format-Table -Wrap
This yields the column names and definitions for the table view:
ColumnName ColumnValue
---------- -----------
Name PSChildName
Property
$result = (Get-ItemProperty -LiteralPath $_.PSPath |
Select * -Exclude PSPath,PSParentPath,PSChildName,PSDrive,PsProvider |
Format-List | Out-String | Sort).Trim()
$result = $result.Substring(0, [Math]::Min($result.Length, 5000) )
if($result.Length -eq 5000) { $result += "..." }
$result
The workaround suggested in js2010's answer - piping to Format-Table * or Format-List * is effective in the sense that it prevents the inapplicable local information from being displayed: by specifying properties explicitly (even by wildcard pattern *), only those properties are displayed on output - not also the flawed calculated column.
However, while the true Property property of the output objects provides access to the value names in the registry key at hand, it doesn't provide the actual data, the way that the calculated Property column does.
By contrast, using Get-ItemProperty without a -Name argument in lieu of Get-Item as a workaround returns both value names and data (correctly even when remoting) and even does so without restrictions (whereas Get-Item limits output to 5000 chars.)
The output format will be slightly different, but all the information is there.
[1] That is, the command works also in PowerShell Core, where the built-in formatting instructions are no longer maintained as external *.format.ps1xl files and are instead compiled into the executable.
Pipe it to fl * or ft * so it doesn't use the format file to display the registry keys. The format file runs get-itemproperty locally to try to display the properties.
From the bottom of $PSHOME\Registry.format.ps1xml for type Microsoft.Win32.RegistryKey:
<ScriptBlock>
$result = (Get-ItemProperty -LiteralPath $_.PSPath |
Select * -Exclude PSPath,PSParentPath,PSChildName,PSDrive,PsProvider |
Format-List | Out-String | Sort).Trim()
$result = $result.Substring(0, [Math]::Min($result.Length, 5000) )
if($result.Length -eq 5000) { $result += "..." }
$result
</ScriptBlock>
The following powershell gets an object of Computer System information:
> $o = Get-WmiObject -Class Win32_ComputerSystem -ComputerName .
> $o
# output
# Domain : somedomain.com
# Manufacturer : VMware, Inc.
# Model : VMware Virtual Platform
# Name : MYSERVER
# PrimaryOwnerName : Windows User
# TotalPhysicalMemory : 17179332608
I add a new member TotalPhysicalMemoryGB to the object $o, as follows:
> $o = Add-Member -Input $o #{TotalPhysicalMemoryGB=([math]::round($t.TotalPhysicalMemory / 1GB))} -PassThru
This appears to work as I can access the member:
> $o.TotalPhysicalMemoryGB
# output
# 16
However, when I print the whole object again, the member TotalPhysicalMemoryGB does not appear in the member list:
> $o
# output
# Domain : somedomain.com
# Manufacturer : VMware, Inc.
# Model : VMware Virtual Platform
# Name : MYSERVER
# PrimaryOwnerName : Windows User
# TotalPhysicalMemory : 17179332608
What am I doing wrong? How can I get the new member included when I print $o?
You don't print the whole object by just output it to the console. There is a predefined view that specifies which properties of a System.Management.ManagementObject#root\cimv2\Win32_ComputerSystem is printed.
You can get a full list of all properties by using the Format-List cmdlet:
$o | Format-List *
Now you will find your previously added property.
As a workaround, you could also manually select the properties you want to output by using the Select-Object cmdlet:
$o | Select-Object Domain, Manufacturer, Model, Name, PrimaryOwnerName, TotalPhysicalMemory, TotalPhysicalMemoryGB
I need to get the latest backups version identifier in a powershell script. If I run wbadmin get versions, I get a list of backups and the last one is the one I need.
Is there a way to do a kind of select top 1 version identifier from backups order by date or parsing the wbadmin output and getting this.
edit
It may be the windows.serverbackup module and versionId of Get-WBBackupSet I'm looking for but still need help parsing this.
VersionId : 04/17/2013-21:00
BackupTime : 17/04/2013 22:00:55
BackupTarget : U:
RecoverableItems : Volumes, SystemState, Applications, Files, BareMetalRecovery
Volume : {System Reserved, Local disk (C:), Local disk (I:), Local disk (O:)...}
Application : {"Cluster", "Registry", "Microsoft Hyper-V VSS Writer"}
VssBackupOption : VssFullBackup
SnapshotId : 58999c7d-dfbf-4272-a5b9-21361d171486
Give this a try, Use -Last instead of -First to get the last item:
Get-WBBackupSet |
Sort-Object BackupTime |
Select-Object -First 1 -ExpandProperty VersionId
You can also play with the order of sorting with the -Ascending switch
Edit: revised version
For use with mixed environments (Windows Server 2008, 2008R2, 2012, 2012R2 as of this writing):
function Get-MyWBSummary
{
<#
.SYNOPSIS
Retrieves the history of backup operations on the local or any number of remote computers.
.DESCRIPTION
The Get-MyWBSummary cmdlet retrieves the history of backup operations on the local or any number of remote computers with remoting enabled. This information includes backuptime, backuplocation, bersion identifier and recovery information.
To use this cmdlet, you must be a member of the Administrators group or Backup Operators group on the local or remote computer, or supply credentials that are.
.PARAMETER ComputerName
Retrives backup results on the specified computers. The default is the local computer.
Type the NetBIOS name, an IP address, or a fully qualified domain name of one or more computers. To specify the local computer ignore the ComputerName parameter.
This parameter rely on Windows PowerShell remoting, so your computer has to be configured to run remote commands.
.PARAMETER Credential
Specifies a user account that has permission to perform this action. The default is the current user. Type a user name, such as "User01", "Domain01\User01", or User#Contoso.com. Or, enter a PSCredential object, such as an object that is returned by the Get-Credential cmdlet. When you type a user name, you are prompted for a password.
.PARAMETER Last
Specifies the last (newest/latest) backup versions.
.EXAMPLE
Get-MyWBSummary
Retrieves all Windows Server backupversions from the local computer
.EXAMPLE
Get-MyWBSummary | Where BackupTime -gt (Get-Date).AddDays(-7)
Retrieves all Windows Server backupversions from the local computer within the last week
.EXAMPLE
Get-MyWBSummary -ComputerName $server1, $server2 -Last 1 -Credential $credential -ErrorAction SilentlyContinue -ErrorVariable sessionErrors
Retrieves the last (newest) Windows Server Backup backupversion from remote servers $server1 and $server2
.NOTES
Written by Anders Præstegaard (#aPowershell).
Version 1.0 (20-01-2016)
#>
[CmdletBinding()]
[OutputType([PSCustomObject])]
param
(
[string[]]$ComputerName = $env:COMPUTERNAME,
[System.Management.Automation.PSCredential]$Credential,
[int]$Last
)
begin
{
if ($Credential)
{
$PSDefaultParameterValues['New-PSSession:Credential'] = $Credential
}
$psSession = New-PSSession -ComputerName $ComputerName
}
Process
{
$scriptBlock = {
if (-not (Test-Path -Path 'C:\Windows\System32\wbadmin.exe'))
{
## Windows Server Backup not installed
continue
}
$content = WBAdmin.exe GET VERSIONS
if (-not $content)
{
## no versions found
continue
}
## Get linenumbers for each entity
$newJobLines = #($content | Select-String -Pattern 'Backup time: ')
if ($Using:Last -and $using:Last -lt $newJobLines.Count)
{
$newJobLines = $newJobLines[- $using:Last.. -1]
}
$newJobLines |
ForEach-Object{
## Location
$lineNumberLocation = $_.LineNumber
$backupLocation = $content[$lineNumberLocation] -replace 'Backup location: '
## Version Identifier
$lineNumberVersionIdentifier = $_.LineNumber + 1
$backupVersionIdentifier = $content[$lineNumberVersionIdentifier] -replace 'Version identifier: '
## Backuptime UTC
# Version identifier string in WBAdmin output represents the UTC datetime formated in 'MM/dd/yyyy-HH:mm'
$wbAdminDateStringFormat = 'MM\/dd\/yyyy-HH:mm'
$backupDateTimeFromVersionIdentifier = [DateTime]::ParseExact($backupVersionIdentifier, $wbAdminDateStringFormat, $null)
$backupDateTimeUtcSpecified = [DateTime]::SpecifyKind($backupDateTimeFromVersionIdentifier, [System.DateTimeKind]::Utc)
# NB WBAdmin calculates the time statically compared to your timezone (ie +1 hour)
# If your timezone support "Daylight Saving Time" then WBAdmin calculation is wrong
# ~ half of the year (as far as I can perceive)
$backupDateTimeLocalTime = $backupDateTimeUtcSpecified.ToLocalTime()
## Can recover
$lineNumberCanRecover = $_.LineNumber + 2
$backupVersionCanRecover = $content[$lineNumberCanRecover] -replace 'Can recover: '
[PSCustomObject]#{
BackupTime = $backupDateTimeLocalTime
BackupTimeUtc = $backupDateTimeUtcSpecified
BackupLocation = $backupLocation
VersionIdentifier = $backupVersionIdentifier
CanRecover = $backupVersionCanRecover
}
}
} # Scriptblock
Invoke-Command -Session $psSession -ScriptBlock $scriptBlock |
Select-Object -Property * -ExcludeProperty RunspaceId
}
end
{
if ($psSession)
{
Remove-PSSession -Session $psSession
}
}
}
How can I get the NetBIOS (aka 'short') domain name of the current computer from PowerShell?
$ENV:USERDOMAIN displays the domain of the current user, but I want the domain that the current machine is a member of.
I've discovered you can do it pretty easily in VBScript, but apparently ADSystemInfo isn't very nice to use in PowerShell.
Update
Here's my final solution incorporating the suggestion of using Win32_NTDomain, but filtering to the current machine's domain
$wmiDomain = Get-WmiObject Win32_NTDomain -Filter "DnsForestName = '$( (Get-WmiObject Win32_ComputerSystem).Domain)'"
$domain = $wmiDomain.DomainName
In most cases, the default NetBIOS domain name is the leftmost label in the DNS domain name up to the first 15 bytes (NetBIOS names have a limit of 15 bytes).
The NetBIOS domain name may be changed during the installation of the Active Directory, but it cannot be changed.
The WIN32_ComputerSystem WMI object gives informations on a Windows computer
PS C:\> Get-WmiObject Win32_ComputerSystem
Domain : WORKGROUP
Manufacturer : Hewlett-Packard
Model : HP EliteBook 8530w (XXXXXXXXX)
Name : ABCHPP2
PrimaryOwnerName : ABC
TotalPhysicalMemory : 4190388224
So the domain Name is given by :
PS C:\> (gwmi WIN32_ComputerSystem).Domain
But in domain installation, the DNS name is given. In this case, you can use nbtstat -n command to find the NetBIOS domain name which is displayed like this <DOMAIN><1B>.
The PowerShell Command may be :
nbtstat -n | Select-String -Pattern "^ *(.*) *<1B>.*$" | % {$_ -replace '^ *(.*) *<1B>.*$','$1'}
Here is another way using WMI
PS C:\> (gwmi Win32_NTDomain).DomainName
Use env: to get environment settings through PowerShell
NetBIOS: $env:userdomain
FQDN: $env:userdnsdomain
To see all the values:
dir env: (no $)
import-module activedirectory
(Get-ADDomain -Identity (Get-WmiObject Win32_ComputerSystem).Domain).NetBIOSName
From Here
# Retrieve Distinguished Name of current domain.
$Domain = [System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain()
$Root = $Domain.GetDirectoryEntry()
$Base = ($Root.distinguishedName)
# Use the NameTranslate object.
$objTrans = New-Object -comObject "NameTranslate"
$objNT = $objTrans.GetType()
# Invoke the Init method to Initialize NameTranslate by locating
# the Global Catalog. Note the constant 3 is ADS_NAME_INITTYPE_GC.
$objNT.InvokeMember("Init", "InvokeMethod", $Null, $objTrans, (3, $Null))
# Use the Set method to specify the Distinguished Name of the current domain.
# Note the constant 1 is ADS_NAME_TYPE_1779.
$objNT.InvokeMember("Set", "InvokeMethod", $Null, $objTrans, (1, "$Base"))
# Use the Get method to retrieve the NetBIOS name of the current domain.
# Note the constant 3 is ADS_NAME_TYPE_NT4.
# The value retrieved includes a trailing backslash.
$strDomain = $objNT.InvokeMember("Get", "InvokeMethod", $Null, $objTrans, 3)
OP is after "computer domain" so the answer would be $GetComputerDomain (below) but I will add the $GetUserDomain also for reference.
$GetComputerDomain = ([System.DirectoryServices.ActiveDirectory.Domain]::GetComputerDomain()).Name
$GetUserDomain = ([System.DirectoryServices.ActiveDirectory.Domain]::GetCurrentDomain()).Name
I find the wmi (gwmi) option to be extremely slow, especially, when you are querying the Win32_NTDomain class. I have a multi-trusted domain environment and it takes forever when I just need that simple info quick.
Use the Active Directory Cmdlet Get-ADDomain:
(Get-ADDomain -Current LocalComputer).NetBIOSName
The below powershell command works great! I tested after trying various solutions.
If you use the following .Net command:
[System.Net.Dns]::GetHostByAddress('192.168.1.101').hostname
It works too, but it is using DNS to resolve, in my case, we have WINS setup to support an application that requires it, so can't use it. Below is what I ended up using as part of a script I use to check for WINS registration for each client:
$IPAddress = "<enterIPAddress>" (remove brackets, just enter IP address)
(nbtstat -A $IPAddress | ?{$_ -match '\<00\> UNIQUE'}).Split()[4]
http://social.technet.microsoft.com/Forums/en-US/f52eb2c7-d55d-4d31-ab4e-09d65d366771/how-to-process-cmd-nbtstat-a-ipaddress-output-and-display-the-computer-name-in-powershell?forum=ITCG
The above link has the thread and conversation.
Using NetGetJoinInformation and P/Invoke:
Add-Type -MemberDefinition #"
[DllImport("netapi32.dll", CharSet = CharSet.Unicode, SetLastError = true)]
public static extern uint NetApiBufferFree(IntPtr Buffer);
[DllImport("netapi32.dll", CharSet = CharSet.Unicode, SetLastError = true)]
public static extern int NetGetJoinInformation(
string server,
out IntPtr NameBuffer,
out int BufferType);
"# -Namespace Win32Api -Name NetApi32
function GetDomainName {
$pNameBuffer = [IntPtr]::Zero
$joinStatus = 0
$apiResult = [Win32Api.NetApi32]::NetGetJoinInformation(
$null, # lpServer
[Ref] $pNameBuffer, # lpNameBuffer
[Ref] $joinStatus # BufferType
)
if ( $apiResult -eq 0 ) {
[Runtime.InteropServices.Marshal]::PtrToStringAuto($pNameBuffer)
[Void] [Win32Api.NetApi32]::NetApiBufferFree($pNameBuffer)
}
}
This can also be done by using .NET framework (which is much faster than WMI)
PS > [System.Net.NetworkInformation.IPGlobalProperties]::GetIPGlobalProperties()
Will return
HostName : SurfaceBook
DomainName : mydomain.com
NodeType : Hybrid
DhcpScopeName :
IsWinsProxy : False
Using the ADSystemInfo COM object should work, with no delay from Win32_NTDomain lookup:
$ADSystemInfo = New-Object -ComObject "ADSystemInfo"
$ADSystemInfo.GetType().InvokeMember("DomainShortName", "GetProperty", $null, $ADSystemInfo, $null)
There are other AD-related properties available from this COM object too:
https://learn.microsoft.com/en-us/windows/win32/adsi/iadsadsysteminfo-property-methods
[EDITED - Originally included code for the WinNTSystemInfo COM object instead but a commenter pointed out this only returns the user's short domain - but ADSystemInfo does return the computer's short domain]
Here is another faster method than Win32_NTDomain, for getting the NetBIOS domain of the computer.
# Get the computer system CIM/WMI
$computersystem = Get-CimInstance Win32_ComputerSystem
# Create a Windows Identity Principal object based on the name and domain in Win32_ComputerSystem
$ComputerPrincipal = [System.Security.Principal.WindowsIdentity]::new("$($computersystem.name)#$($computersystem.domain)")
# Split the NetBIOS name on \ and get the first value which should be the domain
($ComputerPrincipal.Name -split "\\")[0]
# Bonus point, the WindowsIdentity Principal has a bunch of other useful information.
# Like quick enumeration of the groups it's in (but needs to be translated from SID to NTAccount format).
$ComputerPrincipal.Groups.Translate([System.Security.Principal.NTAccount]).value