I am looking to use a powershell script to WMI query the computer during post-install of the imaging sequence via MDT/SCCM. Actively there are multiple VB scripts to accomplish parts of the System Properties area (Manufacturer, Model, InstallDate, SerialNumber, etc.), and would like to consolidate this into a single script that does it all.
Running Powershell ISE as Administrator, so that wouldn't be causing for any permissions issues; the model information returns Macbook as I am testing on Windows 10 through Bootcamp.
Clear-Host
$Model = (Get-WmiObject -Class:Win32_ComputerSystem).Model
$RegKey = “HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\OEMInformation”
New-Item -Path $RegKey -Name Model -Type String -Value $Model –Force
After I ran the script, these were the results (shown below).
Name Property
----- --------
Model (default) : MacBookPro11,1
However the value is not written to the registry. How could I go about the writing of the informaiton to the registry, while also allowing for multiple variables to be aligned in addition? All the values (subkeys) would need to be created and be placed at the same Registry Path of "OEMInformation".
Aim to include for Manufacturer, Model, Name, InstallDate, SystemType as well.
If I understand you correctly, you're able to write to the registry, but you're unsure how to write multiple items to the same "path".
The Windows registry is contstructed by "Keys" and one or multiple values. Your "new-item" line above actually sets a value but you don't specify one so it looks like the "magic" default value is used.
In order to set multiple ones in the same path, you'd use the Cmdlet
Set-ItemProperty, for example using:
Set-ItemProperty -Path $RegKey -Name "Model" -value $Model
You can then have multiple "properties" in that path using the same technique (just use a different value for the "Name" parameter.
I was able to get this resolved, thank you #Trondh for the assistance.
$Model = (Get-WmiObject -Class:Win32_ComputerSystem).Model
$RegPath = 'Registry::HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\OEMInformation'
New-Item $RegPath -Force | New-ItemProperty -Name Model -Value $Model -Force | Out-Null
Related
So, I'm using Desktop Central to run some scripts on a bunch of machines. The script is supposed to open a zip file in the c:\users%USERNAME%\ folder, and decompress it to a folder of my choosing. The idea is to use a single script for many machines, that can leverage the c:\users\LOGGEDONUSER\downloads folder (Default TEAMS download dir). The idea is that each user will download the archive from teams, and a script will decompress and install from each users DOWNLOADS folder.
The issue is that I don't seem to know how to write a script uses a variable representing the username of the logged in user for the -path in my argument.
For instance;
Extract file
Expand-archive -path $home\Downloads\SWANDPDM_SP5.1.zip -DestinationPath C:\temp\swpdminstaller\extracted\ -Force
#Define registry values to modify to allow for no UAC
$RegistryPath = 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System'
$Name = 'ConsentPromptBehaviorAdmin'
$Value = '0'
#Run reg change
New-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType DWORD -Force
#Run installer
Invoke-Item C:\temp\swpdminstaller\extracted\SOLIDWORKS_AND_PDM_2021_SP5.1\startswinstall.exe
#Define reg values to change back to default
$RegistryPath = 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System'
$Name = 'ConsentPromptBehaviorAdmin'
$Value = '5'
#Run reg change
New-ItemProperty -Path $RegistryPath -Name $Name -Value $Value -PropertyType DWORD -Force
This works great if I copy the script to the machine manually, and launch the script as a user. It looks at $home and figures out the correct directory based on whomever is logged in.
However, when it runs as Desktop Central, $home doesn't mean the same location. It comes back with this;
Expand-archive : The path 'C:\Windows\system32\config\systemprofile\Downloads\SWANDPDM_SP5.1.zip' either does not
exist or is not a valid file system path.
At C:\Program Files (x86)\DesktopCentral_Agent\Computer\startup\76507\SWandPDMdecomInstall.ps1:2 char:1
+ Expand-archive -path $home\Downloads\SWANDPDM_SP5.1.zip -DestinationP ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (C:\Windows\syst...NDPDM_SP5.1.zip:String) [Expand-Archive], InvalidOpe
rationException
+ FullyQualifiedErrorId : ArchiveCmdletPathNotFound,Expand-Archive
I tried using various env variables with no luck. It seems like because it's a "Desktop central" account that's running the script remotely, I can't get it to point to the correct folder in c:\users\NAMEOFLOGGEDINUSER\
So, it thinks $home = 'C:\Windows\system32\config\systemprofile\ instead of c:\users\NAMEOFLOGGEDINUSER\
Is there a way that I can get the username of the current logged on user, assign it to a variable, and then use that variable instead of $home? Keep in mind, it needs to find the logged in user while running the script as the Desktop Central service account. I've tried running the script as various domain admins\system accounts with no luck.
I thought about doing a whoami, writing to a text file, then omitting the domain portion of the output and assigning it to a variable, but there's got to be a better way.
Any help is greatly appreciated!
EDIT: Thought I was on to something, but it didn't work. I tried;
Expand-archive -path $env:HOMEPATH\Downloads\SWANDPDM_SP5.1.zip -DestinationPath C:\temp\swpdminstaller\extracted\ -Force
I see from the comments that you found a workaround. But to answer your original question, you can't get the logged in username from the usual Powershell techniques ($env:USERNAME, whoami, etc.) when you're running the script under a different security context.
But you can check who owns the Explorer.exe process:
$User = (Get-CimInstance Win32_Process -Filter "name = 'explorer.exe'" |
Invoke-CimMethod -MethodName GetOwner).User
The "Desktop central" user will probably not have Explorer running. However, if there are multiple users logged in via RDP sessions this will return an array.
I want a powershell script to run each time a user login to Windows by placed in: Shell:common startup.
This script must add about 50 Regkey's in HKCU, which is setting/path for Presetfolders for a application.
I want to use Powershell and have tried this command adding the RegKey (This command needs to be repeated for each 50 regkeys!):
New-ItemProperty -Path 'HKCU:\Software\AppName' -Name 'PresetFolder' -PropertyType String -Value '$env:userprofile\Documents\AppName\Presets1' -Force
New-ItemProperty -Path 'HKCU:\Software\AppName' -Name 'PresetFolder' -PropertyType String -Value '$env:userprofile\Documents\AppName\Presets2' -Force .......
When using "$env:userprofile" instead of c:\Users\MyUserProfile\Documents\.... the -value in the RegKey will be: "$env:userprofile\Documents\NewFolder\Presets" and not as wanted: "c:\Users\MyUserProfile\Documents\NewFolder\Presets".
I need a Variable for each userprofile!
Alternatively I can after Program installation by using admin-account, I can exported all RegKey's as a .reg-file. Before using the powershell-script to merge the RegKeys everytime a user is logging in Windows, I now need to search and replace the value of the path (-Value) from AdminUserProfil-path into a variable for each user running the script.
Part of the Reg-file:
[HKEY_CURRENT_USER\Software\AppName\Version]
"HelpDocPath"="C:\Users\\AdminUserprofiles\\Documents\\AppName\\Version\\HTML Help\\en"
"ExciterCacheInstallPath"="C:\\Program Files\\AppName\\Version\\Exciter Cache"
"DSPResourceFilesInstallPath"="C:\\Program Files\\AppName\\Version/Resources"
"InstallPath"="C:\\Program Files\\AppName\\InstallFolder"
"PresetFolder"="C:\\Users\\AdminUserprofiles\\Documents\\AppName\\Version\\Presets\\Global Presets"\
Hope anyone can help?
What do I need to type for the right path, so each user will have there own path? Do I need a variable fo rusers or..?
Thank you.
Define $env:USERPROFILE as a variable so you can call it, otherwise PS will just output what you have typed, which is what is happening in this case.
$path = "$env:USERPROFILE"
New-ItemProperty -Path 'HKCU:\Software\AppName' -Name 'PresetFolder' -PropertyType String -Value '$path\Documents\AppName\Presets1' -Force
To harden windows I want to disable netbios on all computers. With the following powershell script I can easily read all Network Adapters Netbios setting.
$RegKeys = Get-ChildItem 'HKLM:\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces'
$RegKeys | ForEach-Object {
$_.GetValue("NetbiosOptions")
}
This works great so I thought analog to this I can change the settings like this:
$RegKeys = Get-ChildItem 'HKLM:\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces'
$RegKeys | ForEach-Object {
$_.SetValue("NetbiosOptions", 2)
}
But it says it can't be written into the registry key. So why is the reading working and not the writting? Of course I run both with admin rights.
If I do it this way it is possible:
Set-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\NetBT\Parameters\Interfaces\Tcpip_{Example}" -Name NetbiosOptions -Value 2
I am trying to use Powershell's Copy-Item commandlet with the -Recurse and -Force parameters to copy settings from one registry key and overwrite the same settings (if they exist) in another key. If I were using this same command on a file system, then any folders that exist in source and target would be overwritten in the target.
When using this command on the registry, however, if there are keys in the target that exist, the source key is copied as a subkey. Example:
Starting state:
HKCU:Software\OldVendor\Program
HKCU:Software\OldVendor\Program\Setting1
HKCU:Software\OldVendor\Program\Setting2
HKCU:Software\NewVendor\Program
HKCU:Software\NewVendor\Program\Setting1
HKCU:Software\NewVendor\Program\Setting2
Now if I run this command:
Copy-Item -Path "HKCU:Software\OldVendor\Program" -Destination "HKCU:Software\NewVendor" -Recuse -Force
I expect the same structure to be maintained. In fact, the structure under NewVendor looks like this:
HKCU:Software\NewVendor\Program
HKCU:Software\NewVendor\Program\Setting1
HKCU:Software\NewVendor\Program\Setting1\Setting1
HKCU:Software\NewVendor\Program\Setting2
HKCU:Software\NewVendor\Program\Setting2\Setting2
Can anyone tell me how to get Powershell to overwrite existing registry keys, instead of copying to subkeys?
It seems to me you want to copy items and their values, those are properties, not keys. You can list them as follows:
get-itemproperty "HKCU:Software\NewVendor\Program"
or u can use alias and omit quotes:
gp HKCU:Software\NewVendor\Program
Another, better way, which doesn't view powershell specific properties:
Get-Item HKLM:\SOFTWARE\NewVendor\Program | select -ExpandProperty Property
So, if u want to copy all the properties from one key to another:
Get-Item HKLM:\SOFTWARE\Program | select -ExpandProperty Property | % {Copy-ItemProperty -Path HKLM:\SOFTWARE\Program -Destination HKLM:\SOFTWARE\AnotherProgram -Name $_ -Verbose}
You have to use foreach loop, beacuse Copy-ItemProperty cmdlet can copy only one property been specified.
I'm interested in adding a property to my files under a certain scope that contains their current locations in my file system, in order to track file movement. I would think that this could be done with New-ItemProperty, with a command similar to the following:
Get-ChildItem -recurse | foreach { New-ItemProperty -Path $.FullName -Name "OriginalLocation" -PropertyType string -Value $.FullName }
However, when I try this, I'm spammed with the following error:
New-ItemProperty : Cannot use interface. The IDynamicPropertyCmdletProvider interface is not implemented by this provider.
After some searching, it appears that New-ItemProperty is all but useless except for working with the registry. Fine. Windows has myriad other file properties I should be able to hijack in order to get this done. "Label" and "Tags" come to mind. So let's try setting those via Set-ItemProperty instead.
Set-ItemProperty : Property System.String Label=D:\test\file.txt does not exist.
It appears I need to create these properties after all. Is this a shortcoming of New-ItemProperty? Maybe setting properties such as this on arbitrary items is some WMI thing I don't know about?
Here is my solution using the redirections ('<' & '>') that allow to manipulate alternate data stream in CMD.EXE. It works in Powershell without any extentions
# AlternateDataStream.ps1
$scriptBlockSetStream = {cmd /C `"echo $($Args[0])`>$($Args[1]):$($Args[2])`"}
$scriptBlockGetStream = {cmd /C `"more `<$($Args[0]):$($Args[1])`"}
$streamName = "NativeFilePath"
$File = "C:\Temp\ADSTest\toto.txt"
$streamContent = Split-Path -Path $File -Parent
# Set the data stream
Invoke-Command -ScriptBlock $scriptBlockSetStream -ArgumentList $streamContent,$File,$streamName
# Get the Data Stream
$res = Invoke-Command -ScriptBlock $scriptBlockGetStream -ArgumentList $File,$streamName
$res
Another option might be to use alternate data streams to store your path. If you are running PowerShell 3.0, you can manipulate them quite easily. Based on the first article, you would have something resembling:
"echo test" | out-file c:\powershell\test.ps1
$fs = new NTFS.FileStreams('c:\powershell\test.ps1')
$fs.add('OriginalPath')
$stream = $fs.Item('OriginalPath').open()
$sw = [System.IO.streamwriter]$stream
$sw.writeline('<path>')
$sw.close()
$stream.close()