Windows 10 Subscription Activation via Powershell
We recently purchased E3 Subscription licenses for Windows 10. Microsoft's documentation states for exisiting enterprise deployments, the following script should be ran via a command line: @echo off FOR /F "skip=1" %%A IN ('wmic path SoftwareLicensingService get OA3xOriginalProductKey') DO ( SET "ProductKey=%%A" goto InstallKey ) :InstallKey IF [%ProductKey%]==[] ( echo No key present ) ELSE ( echo Installing %ProductKey% changepk.exe /ProductKey %ProductKey% ) I'm attempting to re-write this in powershell so we can use it as a remediation step in a configuration baseline in SCCM. Below is the powershell script I wrote: $ProductKey = (Get-CimInstance -ClassName SoftwareLicensingService).OA3xOriginalProductKey if ($ProductKey){ start-process c:\Windows\System32\changePK.exe -ArgumentList "/ProductKey $ProductKey" } The script runs without error, but it's not actually completing the intended task (activating the embedded windows 10 pro key). I'm not sure where I'm going wrong. I'm pretty new to powershell so any assistance would be greatly appreciated.Check if user already exists
Hi there, I'm trying to create a script which basically requires the user's input, so they'll need to enter their first name & last name and AD will check if that AD account already exists for the user or not, if it does then it would say '_____ already exists' and stops the script going any further as it's currently doing for any users whether or not they exist - below. What's the correct commands I should be using as below so it will search AD for that user and if they don't exist it would say 'User doesn't exist' and continue with the rest of the script which then asks for the user's dept and phone number etc, as currently it's just saying all the user's already exist and stops the script, I've tried various recommended commands from other forums. Thank you in advanceNew-SMBMapping not showing in Explorer until Explorer process is closed/restarted
I'm writing a script to remap drives to new paths (file server migration), and I had everything working. I'm using Remove-SMBMapping and New-SMBMapping. While it was working there was a strange bug where it would only work if I pasted the code directly into powershell. But if I called the .ps1 script file, the drive mappings would change (as verified by NET USE from the command line), Explorer continued to show and use the old drive mappings. If I end process for Explorer.exe and re-run it, then it would show and use the new mappings. I just ignored this at the time. Well now I'm doing some more testing, now no matter what I do, when using New-SMBMapping in any way, Explorer refuses to see the drive (even new mappings) while the system does see the correct drives via cmdline. I'm at a complete loss as to why this is an issue. It occurs in both Powershell 7 as well as Windows Powershell 5.1. Does anyone have a clue as to what is happening here? FWIW I know that drives mapped in the standard UAC user context are not visible to admin contexts and vice versa. That is not the issue here. This is all under the same user context. No elevated admin sessions are at play. In fact, if it were this, restarting Explorer would have no affect. Also this is an issue whether -persistent $true is used or not. Finally, if I just simply use native Windows cmd prompt command "Net Use" to map the drive, even within the Powershell console, everything works as expected. This is only an issue using the powershell specific cmdlet to map the drive.
A simple example of Windows PowerShell Just Enough Administration (JEA)!
Dear Microsoft and PowerShell Friends, Using PowerShell to establish a remote connection and then manage, for example, a domain controller or any other server that is a member of the domain, is really fun. But what about security? When I as a domain administrator establish a remote connection, I have a huge number of cmdlets at my disposal. #We start a "normal" remote connection and check how many cmdlets are available Enter-PSSession -ComputerName dc01 (Get-Command).count Maybe you (the administrator) do not always want to establish the remote connection to a specific server to process an existing task, but you would like to delegate this step to another person. But only in a way that this person cannot work with too many cmdlets. That's where PowerShell Just Enough Administration (JEA) comes in. With this technique you can, for example, provide a specific Active Directory group with exactly the number of cmdlets to perform the necessary work on the desired server. JEA is best suited for tasks that are clearly defined. JEA is not suitable for troubleshooting or research. The best place to start is in Active Directory: 1. Create a security group with the name Helpdesk in AD. 2. Add a user (or users) to the group After that we switch to the PowerShell ISE (on the server where you want to make the cmdlets available) or the one you trust (maybe VSCode ;-). #Are comments! #We navigate in to the following path Set-Location 'C:\Program Files\WindowsPowerShell\Modules' #Create a new directory New-Item -ItemType Directory Helpdesk #Navigate to the directory Set-Location Helpdesk #Create a new directory New-Item -ItemType Directory RoleCapabilities #Navigate to the directory Set-Location RoleCapabilities #Creates a file that defines a set of capabilities to be exposed through a session configuration New-PSRoleCapabilityFile -Path .\Helpdesk.psrc #Now we edit this file ISE .\Helpdesk.psrc In this file you can specify among others cmdlets, functions and also commands that can be used. In this example I provide "Get-Service" and "whoami". In a practical example, you would provide all the necessary commands/cmdlets needed for the specific task (just as the case may be). #Creates a file that defines a session configuration New-PSSessionConfigurationFile .\Helpdesk.pssc #Now we edit this file ISE .\Helpdesk.pssc In this file, you can specify the session configuration, a virtual administrator account, and user roles, among other things. #Let us check the settings Test-PSSessionConfigurationFile .\Helpdesk.pssc #Creates and registers a new session configuration Register-PSSessionConfiguration -Name Helpdesk -Path .\Helpdesk.pssc #We need to restart the WinRM Service Restart-Service WinRM #Gets the registered session configurations on the computer Get-PSSessionConfiguration Now switch to the system from which you want to establish a remote session. #We establish a connection Enter-PSSession -ComputerName dc01 -ConfigurationName Helpdesk -Credential grid\james.west #And check the number of cmdlets and the account created for the connection Get-Command We now have exactly the cmdlet and the command we specified. We also see that the session was established with a virtual account. This means that these credentials are not saved after the session ends. #Close the Session Exit-PSSession Back to the server. #(Optional) Deletes registered session configurations from the computer Unregister-PSSessionConfiguration -Name Helpdesk Clearly, that was not super spectacular or fancy. But I still wanted to share my experience with you. Thank you for taking the time to read this article. Kind regards, Tom Wechsler P.S. All scripts (#PowerShell, Azure CLI, #Terraform, #ARM) that I use can be found on github! https://github.com/tomwechsler
