I have created a configuration item to check the status of the optional feature Internet Explorer.
The CI contains the following powershell script:
Get-WindowsOptionalFeature -FeatureName Internet-Explorer-Optional-amd64 -Online
The CI has been added to a Configuration Baseline and deployed to a test machine.
Running this powershell code manually outputs the following on a test machine
PS C:\WINDOWS\system32> Get-WindowsOptionalFeature -FeatureName Internet-Explorer-Optional-amd64 -Online
FeatureName : Internet-Explorer-Optional-amd64
DisplayName : Internet Explorer 11
Description : Finds and displays information and Web sites on the Internet.
RestartRequired : Required
State : Disabled
CustomProperties :
\SoftBlockLink : http://go.microsoft.com/fwlink/?LinkID=142507
and the related compliance rule is configured as follows:
I would assume this should result in being compliant - but actually it isn't.
I'm new to SCCM and therefor wondering if my rule is misconfigured.
Any ideas / input is highly appreciated.
Thanks in advance
Adjusted the powershell script to just output the actual state.
(Get-WindowsOptionalFeature -FeatureName Internet-Explorer-Optional-amd64 -Online).State
Related
I am facing a difficulty on installing RSAT to remote windows 10 workstations via gpo. My main goal is to use Get-ADuser command as a necessity to gain information from my Windows domain.
I created a PowerShell script using the following command:
Get-WindowsCapability -Name RSAT* -Online | Add-WindowsCapability –Online
Yet when I run it, a message appears asking for elevated privileges.
So I tried to add credentials in order to automate the installation and changed the script to :
$Username = 'domain\domain_adm'
$Password = '*******'
$pass = ConvertTo-SecureString -AsPlainText $Password -Force
$Cred = New-Object System.Management.Automation.PSCredential -ArgumentList $Username,$pass
Start-Process -FilePath powershell.exe -ArgumentList{Get-WindowsCapability -Name RSAT* -Online | Add-WindowsCapability –Online} -credential $Cred
And from a normal PowerShell window, it works. But, it doesn't when I am trying to use it from gpo.
Could you please assist me?
The goal is to install via GPO Get-ADuser (maybe RSAT) to domain workstations with OS Windows 10
For a small number of machines Powershell is not a bad option. If you have access to GPOs then you should use then. RSAT is "Windows feature". You can use WSUS. https://4sysops.com/archives/install-rsat-1809-and-other-optional-features-in-wsus-environments/ You could also use the software that you use to install software on the machine on the network . Many of software distribution packages run as root when it installs software. In this case just give that team the line below.
Get-WindowsCapability -Name RSAT* -Online | Add-WindowsCapability –Online
Why are you putting credentials in clear text in a script file? That
is just bad practice and should not be done.
Installing software is an Admin level thing, local, GPO, or
otherwise, because it's a system-wide change.
Lastly, this is not a PowerShell code/programming issue and not something PowerShell can fix relative to how you are trying to do this. It's specifically how do I use GPO to enable a Windows feature or install software, using PowerShell?
So, could be considered off-topic for Stackoverflow and more a question for SuperUser or StackExchange.
All that being said, you can still use PowerShell to do this, but doing so by using PowerShell to set a scheduled task to the targets and set that to the admin creds at run once at login.
You can write a separate script to create the scheduled task.
You can use the below script for the RSAT install effort via the task.
Use PowerShell to Create Scheduled Tasks
New-ScheduledTask
Very similar to this approach with updating PowerShell help:
PowerShell: Update-Help via Scheduled Task in Group Policy Preferences
As far as what js2010 has stated. That was true for earlier versions of Windows 10. The current state of things is as noted below.
Install RSAT for Windows 10 1809 and 1903 and 1909 automated
RSAT (Remote Server Administration Tools) in Windows 10 v1809 and
v1903 are no longer a downloadable add-on to Windows. Instead, its
included as a set of "Features on Demand" directly in Windows.
Download: Install-RSATv1809v1903v1909.ps1
Long term Scheduled Task management can be accomplished via GPO as well, as noted here:
Managing Scheduled Tasks from Group Policy
You can download RSAT as an msu file: https://www.microsoft.com/en-us/download/details.aspx?id=45520
EDIT: Ok, as for 1809 and above, my first thoughts are a gpo startup script, or using invoke-command.
I am having an issue getting AutoAdminLogon working with my Windows Server 2008 R2 Image. It is an Amazon Windows Server 2008 R2 CIS Level 2 Benchmark AMI from the Amazon Marketplace.
The issue I am having is when I set the AutoAdminLogin to 1 and do a gpupdate or reboot it reverts back to 0.
I am using Packer to provision my AMI so the steps I am going through are Remove PowerShell 3.0 then reboot. The AutoAdminLogon is set before the reboot but gpupdate runs when the system restarts gpupdate reverts the setting back to 0.
The AutoAdminLogon is needed because the server needs to reboot several times during the provisioning.
Steps are
1. Remove PowerShell 3.0
2. Reboot
3. AutoAdminLogon
4. Install .Net 4.5.2
5. Install Windows Management Framework 5.1
6. Reboot.
At this point, Packer will try to connect using WINRM to finish provisioning the instance to capture as an AMI.
I know it has something to do with the MSS-Legacy settings applied to the AMI. But how do I un-apply them? Or just the AutoAdminLogin set to Disabled?
I have tried using secedit:
secedit /export /cfg c:\temp\secpol.cfg
(gc C:\temp\secpol.cfg).replace('AutoAdminLogon=1,"0"','AutoAdminLogon=1,"1"') | Out-File C:\temp\secpol.cfg
secedit /configure /db c:\windows\security\secedit.sdb /cfg c:\temp\secpol.cfg
Reference: Modify Local Security Policy using Powershell
I have tried the steps listed here: https://docs.bmc.com/docs/tssa89/rollback-of-cis-and-pciv2-templates-after-remediation-does-not-work-808908846.html
Here is also a link to the Script I have modified to do the PowerShell Upgrade:
https://github.com/jborean93/ansible-windows/blob/master/scripts/Upgrade-PowerShell.ps1
Now if I download the MSS-Legacy GPO templates and use the GUI to set the MSS: (AutoAdminLogon) Enable Automatic Logon (not recommended) to Enabled,
It will work and the setting will stick after reboots or gpudpate. But I need a way to do this in a scripted manner because there is no interaction with the Instance during the Bakery process.
I cannot do the steps using a GUI as this is part of our AMI bakery process.
Thanks so much I look forward to seeing peoples thoughts.
I've just come across this "fun"!
I used the PolicyFileEditor PowerShell module and a lot of trial and error, coupled with the information in your question (thanks for that!) to get this working.
My OS is Windows Server 2016, so hopefully it also works for Windows Server 2008 R2 (not that anyone should be using that anymore).
Here's the PowerShell code that I'm using in my Packer build:
Install-Module PolicyFileEditor
Import-Module PolicyFileEditor
# Change the Autologon GPO setting
Set-PolicyFileEntry -Path "$env:windir\system32\GroupPolicy\Machine\registry.pol" -Key "Software\Microsoft\Windows NT\CurrentVersion\Winlogon" -ValueName "AutoAdminLogon" -Data "1"
# Force the policy update to occur
gpupdate /force
# Configure the auto login user and password so that the next restart has autologin
$loginPath = "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon"
Set-ItemProperty -Path $loginPath -Name "DefaultUserName " -Value "<your_admin_user>" -Type String
Set-ItemProperty -Path $loginPath -Name "DefaultPassword" -Value "<your_admin_password>" -Type String
There's also another registry value that you need to specify which is the AutoLogonCount. AutoAdminLogon is directly correlated to the logon count for how many times the system will automatically logon after a reboot.
If your logon count is not set, this may be the reason why it's resetting to 0.
If you want this to be set infinitely, just set it 999999 or something ridiculously high.
You can refer to this MSDN for more information:
MSGina.dll
Note that the Type for AutoLogonCount should be REG_DWORD
Instead of having to restart the computer, you can try the following command:
# Force the policy update to occur w/o restart
echo N | gpupdate.exe /target:Computer /force
I have docker 17.12.0-ce-win46 build installed on my window 10 laptop. Each time i start it I get the error below... I have followed all recommended solutions I could fine online on how to resolve this issue but the issue persist.
Docker hv-sock proxy (vsudd) is not reachable
at Docker.Backend.ContainerEngine.Linux.ConnectToVsud(TaskCompletionSource`1 vmId) in C:\gopath\src\github.com\docker\pinata\win\src\Docker.Backend\ContainerEngine\Linux.cs:line 293
at Docker.Backend.ContainerEngine.Linux.DoStart(Settings settings, String daemonOptions) in C:\gopath\src\github.com\docker\pinata\win\src\Docker.Backend\ContainerEngine\Linux.cs:line 260
at Docker.Backend.ContainerEngine.Linux.Start(Settings settings, String daemonOptions) in C:\gopath\src\github.com\docker\pinata\win\src\Docker.Backend\ContainerEngine\Linux.cs:line 130
at Docker.Core.Pipe.NamedPipeServer.<>c__DisplayClass9_0.b__0(Object[] parameters) in C:\gopath\src\github.com\docker\pinata\win\src\Docker.Core\pipe\NamedPipeServer.cs:line 47
at Docker.Core.Pipe.NamedPipeServer.RunAction(String action, Object[] parameters) in C:\gopath\src\github.com\docker\pinata\win\src\Docker.Core\pipe\NamedPipeServer.cs:line 145
For me, here is what I did to correct the error. Go to C:\Users\Public\Public Documents\Hyper-V directory, right click on Hyper-V folder, select Properties, and un-check the Read Only checkbox and Apply changes. Next, in the Windows task bar right click on the red Docker icon, or if it is located in the hidden icons, select Quit, then restart it.
You can revert to docker version 17.09.1.14687. 17.12.0-ce-win46 and 17.12.0-ce-win47 have this error.
Enable Hyper-V using PowerShell
Open a PowerShell console as Administrator.
Run the following command:
PowerShell
Copy
Enable-WindowsOptionalFeature -Online -FeatureName:Microsoft-Hyper-V -All
If the command couldn't be found, make sure you're running PowerShell as Administrator.
When the installation has completed you need to reboot the computer.
Enable Hyper-V with CMD and DISM
The Deployment Image Servicing and Management tool (DISM) helps configure Windows and Windows images. Among its many applications, DISM can enable Windows features while the operating system is running.
To enable the Hyper-V role using DISM:
Open up a PowerShell or CMD session as Administrator.
Type the following command:
PowerShell
Copy
DISM /Online /Enable-Feature /All /FeatureName:Microsoft-Hyper-V
When the installation has completed you need to reboot the computer.
Please check if your system variable(Environment variable) if DOCKER_HOST is defined then remove and restart system and run the docker.
Hyper-V UI has not any option to get info about generation of VM that was used during first setup. I do believe it should be somewhere in Settings, but can't find anything.
I'm using Hyper-V service on Windows 10 host machine.
It could be done by using Windows PowerShell as an Administrator.
The command is Get-VM, but, for getting info about Generation you have to add Format-List:
PS C:\> Get-VM | Format-List will show complex info including Generation.
I have a windows 2003 box setup with virtual box and I can't powershell to work with it.
I try this on my windows 7 machine
Get-Service –ComputerName myserver
I get back
Get-Service : Cannot open Service Control Manager on computer 'myserver'. This operation might require other privileges.
At Script1.ps1:2 char:4
+ gsv <<<< -cn myserver
+ CategoryInfo : NotSpecified: (:) [Get-Service], InvalidOperationException
+ FullyQualifiedErrorId : System.InvalidOperationException,Microsoft.PowerShell.Commands.GetServiceCommand
While searching around I found I should try and use Enable-PSRemoting.
I did this and now when I try to use it I get
WinRM already is set up to receive requests on this machine. WinRM
already is set up for remote management on this machine.
Yet I still get the same error. Is this because I am using a virtual machine? I setup the virtual OS to be on my domain and I can even use my AD account credentials to log in.
I can get other information back from it.
So it is not like I can't connect to it with powershell.
With PowerShell V2 you've got two approachs for remote commands.
Commands with built-in remoting :
A small set of commands in PowerShell v2 have a -ComputerName parameter, which allows you to specify the target machine to access.
Get-Process
Get-Service
Set-Service
Clear-EventLog
Get-Counter
Get-EventLog
Show-EventLog
Limit-EventLog
New-EventLog
Remove-EventLog
Write-EventLog
Restart-Computer
Stop-Computer
Get-HotFix
These commands do their own remoting either because the underlying infrastructure already supports remoting or they address scenarios that are of particular importance to system management. They are built on the top of DCOM and, on the access point of view, you can use them when you can establish a session with the remote machine with commands like NET.exe or PSExec.exe.
You are trying to use one of them and you've got a problem with credentials (-cred parameter), because your token credentials can't be used to establish an admin session to the remote machine.
The PowerShell remoting subsystem :
Before you can use PowerShell remoting to access a remote computer, the remoting service on that computer has to be explicitly enabled. You do so using the Enable-PSRemoting cmdlet. If you are working in workgroup you also need to enable the server to enter on your client computer with this command (on your client computer as administrator):
Set-Item WSMan:\localhost\Client\TrustedHosts *
Then, you will use New-PSSession Cmdlet (with -computername and -credentials) to create a session object. Then Invoke-Command (with -session and -scriptblock) cmdlet allows you to remotely invoke a scriptblock on another computer. This is the base element for most of the features in remoting. You can also use Enter-PSSession to establish an interactive (SSL like) PowerShell command line with the server.
Useful link : Layman’s guide to PowerShell 2.0 remoting
Test this :
$sess = New-PSSession -ComputerName myServer-Credential (Get-Credential)
Invoke-Command -Session $sess -ScriptBlock {get-service}
...
Remove-PSSession -Session $sess
If it is still important, here is my workaround:
I got an unprivileged user called 'usser' who wants powershell(v2) remoting from client A to server B.
Steps:
enable-psremoting on Targetserver B as admin
Set-PSSessionConfiguration -Name Microsoft.PowerShell -ShowSecurityDescriptorUI on Targetserver B as admin
Add "usser" with full privileges
Now comes the exciting part:
sc sdshow scmanager on Targetserver B as admin
Copy the SDDL output
sc sdset scmanager (f.e.:)"D:(A;;CC;;;AU)(A;;CCLCRPRC;;;IU)(A;;CCLCRPRC;;;SU)(A;;CCLCRPWPRC;;;SY)(A;;KA;;;BA)S:(AU;FA;KA;;;WD)(AU;OIIOFA;GA;;;WD)" , in the Output you have to fill after this part (A;;CCLCRPWPRC;;;SY) this = (A;;KA;;;SID)
SID stands of course for the SID of the unprivileged "usser"-user
when everything should be fine, it will similiar looks like this :
D:(A;;CC;;;AU)(A;;CCLCRPRC;;;IU)(A;;CCLCRPRC;;;SU)(A;;CCLCRPWPRC;;;SY)(A;;KA;;;S-1-5-21-4233383628-1788409597-1873130553-1161)(A;;KA;;;BA)S:(AU;FA;KA;;;WD)(AU;OIIOFA;GA;;;WD)
Hope you will enjoy that little but complicated workaround.
Viewing and manipulating services requires administrative privileges on the target machine.
I was able to duplicate your error message by attempting to run Get-Service -ComputerName MyServer while logged in as a user account that doesn't have administrative rights to the server in question.
You can resolve this by either granting the workstation user account administrative privileges on the target server or by creating a a local group on the server and granting invocation privileges to members of that group. If you want to do the latter, see the following article.
msgoodies: Using a PS Session without having Administrative Permissions
Building on #scusi marcus's brilliant answer here:
Let's say I have an unprivileged/limited user called 'user1' who wants powershell(v2+) remoting from client machine A to targetserver B.
Steps:
From elevated powershell prompt on targetserver B, run enable-psremoting. Accept several Y/N dialog confirmations or else run with -force switch.
In same elevated prompt as step 1, Set-PSSessionConfiguration -Name Microsoft.PowerShell -ShowSecurityDescriptorUI
In the resulting dialog, add "user1". Read privileges should be sufficient unless you are planning on remotely manipulating services, in which case you will want Full Control.
On targetserver B, from an elevated (non-powershell) prompt or as an administrator, run sc sdshow scmanager. Copy the SDDL output. May look something like this: D:(A;;CC;;;AU)(A;;CCLCRPRC;;;IU)(A;;CCLCRPRC;;;SU)(A;;CCLCRPWPRC;;;SY)(A;;KA;;;BA)S:(AU;FA;KA;;;WD)(AU;OIIOFA;GA;;;WD)
UPDATE: If we add the limited user to the target computer's Remote Management Users group, we can add (A;;LCRPWPDTLO;;;RM) to the D: portion of the above SDDL string, and skip steps 5 and 6 below.
Determine the SID of the underprivileged user account (in our case, "user1"). (Hint: try wmic useraccount where name='user1' get sid)
Insert the following text into the output we copied in step 5: (A;;KA;;;*SID*) where *SID* is the SID of the user determined in step 5. Insert it somewhere in a place before the S: part of the SDDL string retrieved in step 4. So now you should have a string looking something like this: D:(A;;CC;;;AU)(A;;CCLCRPRC;;;IU)(A;;CCLCRPRC;;;SU)(A;;CCLCRPWPRC;;;SY)(A;;KA;;;S-1-5-21-4233383628-1788409597-1873130553-1161)(A;;KA;;;BA)S:(AU;FA;KA;;;WD)(AU;OIIOFA;GA;;;WD)
On targetserver B, run sc sdset scmanager followed by our new modified SDDL string. So the entire command would look something like this:
sc sdset scmanager D:(A;;CC;;;AU)(A;;CCLCRPRC;;;IU)(A;;CCLCRPRC;;;SU)(A;;CCLCRPWPRC;;;SY)(A;;KA;;;S-1-5-21-4233383628-1788409597-1873130553-1161)(A;;KA;;;BA)S:(AU;FA;KA;;;WD)(AU;OIIOFA;GA;;;WD)
You should now be able to remotely access the Service Control Manager on the remote server while logged into client machine A as "user1".
On client machine A, you may find that when you run Get-Service –ComputerName remoteserver not all services are listed. You may need to repeat the above process (starting at step 4) for a specific service that you need remote access to, but which is not listed in your Get-Service output on client machine A. For instance, if the sqlserveragent service is not listed (but you know it is present on the targetserver), you would again log in to targetserver B and execute sc sdshow but this time not for scmanager but for the sqlserveragent service, so sc sdshow sqlserveragent. You would again receive some SDDL output that would need to be manipulated as above. At this point, it may be worth learning more about SDDL (Google it - this link was helpful for me), with the main caveat to watch for the D: and S: portions of the SDDL string and make sure you aren't messing with the S: part.
I know that this isn't the ideal answer to this question, but I was having a similar issue trying to use PowerShell to talk to a Windows 7 box. Turns out, WMI hadn't been installed with the native PSv2 that comes with Win7.
As soon as I installed v3 as part of the WMI 3.0 package, the problem solved itself. I'd suggest making sure that all the relevant WMI services are running on your server. Unless you have conflicts, I'd also recommend upgrading to WMI 3.0.