enter image description here
Recently we want to update security and critical patches using command for customer's windows domain servers, and the PSWindowsUpdate Module seems is very suitable.
However, we tried to install it via "Install-Module -Name PSWindowsUpdate -Force" and also allow those servers can access Internet URL(.microsoft.com/.powershellgallery.com etc), but it still failed as screenshot
We google some links and use TLS1.2, however it still can't work and that very confused us that "WARNING: Source Location 'https://www.powershellgallery.com/api/v2/package/PSWindowsUpdate/2.2.0.3' is not valid."
I also tried to do that on my laptop with same method, it can work perfectly and there is no any error on powershell.
Customer windows server is Win2019 Datacenter and Standard
Customer powershell version is 5.1.17763.2931
We have no idea on the difference and how to install, any suggestion?
You may try the following command before installing PSWindowsupdate
Install-PackageProvider -name NuGet -MinimumVersion 2.8.5.201 -Force
Related
I just wanted to share this with you all. If I knew what to ask for, I would have created a ticket up front. But what I found online was partly misleading.
It was a combination of searching and trying, until I finally found the solution.
This issues was related to running PowerShell Core on a corporate machine, initially setup for Proxy use.
Problem description
After fresh installation of PowerShell Core, Install-Module where unable to resolve package source and Invoke-WebRequest "any-external-url" reported "No such host". This is all under Windows 10.
Solution to my issue
I had to do all of this to bypass the proxy.
First was to unset the Environment Variable for the proxy. (Maybe you also need to do this for HTTP_PROXY environment variable)
Set-Item -Path Env:HTTPS_PROXY -Value ""
Reset proxy for HttpClient
[System.Net.Http.HttpClient]::DefaultProxy = New-Object System.Net.WebProxy($null)
Reset proxy for HttpWebRequest
[System.Net.HttpWebRequest]::DefaultWebProxy = New-Object System.Net.WebProxy($null)
I ended up adding them to the PowerShell 7 profile.
Hope it save some time for at least one more soul. :)
I ran the following commands as per some other posts:
Install-Module -Name AzureAD
Import-Module AzureAD -UseWindowsPowerShell
When I try to execute Connect-AzureAD, the standard error comes up:
Connect-AzureAd: The term 'Connect-AzureAd' is not recognized as a name of a cmdlet, function, script file, or executable program.
Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
Any ideas on how to get Connect-AzureAD to work on powershell for Mac?
"AzureAD" and "AzureADPReview" modules are only supported with Windows PowerShell 5.1 (https://learn.microsoft.com/en-us/powershell/azure/active-directory/install-adv2?view=azureadps-2.0).
if you want to access Azure AD using PowerShell 7 (e.g. from MacOS), you need to use different modules:
"Az" modules
"Microsoft.Graph.*" modules (e.g. "Microsoft.Graph.Users", "Microsoft.Graph.Groups")
ref:
https://learn.microsoft.com/powershell/azure/install-az-ps
https://learn.microsoft.com/graph/powershell/installation
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 was able to install Powershell Core on MacOSX and now I'm trying to administer an Azure AD instance from the same.
When I install the AzureAD module, I get the following error
PS /Users/c> Install-Module -name AzureAD
Untrusted repository
You are installing the modules from an untrusted repository. If you trust this
repository, change its InstallationPolicy value by running the Set-PSRepository
cmdlet. Are you sure you want to install the modules from 'PSGallery'?
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help
(default is "N"):y
PackageManagement\Install-Package : Unable to load DLL 'api-ms-win-core-sysinfo-l1-1-0.dll': The specified module or one of its dependencies could not be found. (Exception from HRESULT: 0x8007007E) At /usr/local/microsoft/powershell/6.0.2/Modules/PowerShellGet/1.6.0/PSModule.psm1:2057 char:21 + ... $null = PackageManagement\Install-Package #PSBoundParameters
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (Microsoft.Power....InstallPackage:InstallPackage) [Install-Package], Exception
+ FullyQualifiedErrorId : System.DllNotFoundException,Microsoft.PowerShell.Commands.TestModuleManifestCommand,Microsoft.PowerShell.PackageManagement.Cmdlets.InstallPackage
I looked around for ways to get api-ms-win-core-sysinfo installed on Mac, but being it's a different OS, I didn't see any straightforward resolutions.
This module is not yet ported to dotnet core, so you cant use it on Linux\Mac.
You can take a look here:
https://www.powershellgallery.com/packages/AzureAD/2.0.1.6
also, you can use this search to confirm my statement:
https://www.powershellgallery.com/items?q=Tags%3A%22PSEdition_Core%22++azuread&x=0&y=0
As #4c74356b41 rightly says, the Azure AD module is not ported to PowerShell core yet.
Besides installing a VM with windows, and depending exactly what you wish to do, you could try the Azure CLI for OS X
If a browser experience is okay for you, the Azure Cloud Shell also offers CLI and even some Powershell commands (though this also runs on Core in the background):
If you look at the error message it is clear, that the error is not about the AzureAD module not being available on your platform, but more about the "PackageManagement"-Package not being supported. So you can try downloading the module directly from powershellgallery and unzipping it into your module path.
I've hit the same problem - it's frustrating that the AzureAD module isn't open-sourced on GitHub. While the Az module is, it lacks most of the functionality of the AzureAd module.
One option is to "copy" the version of AzureAD from cloud shell, as outlined here:
https://www.michev.info/Blog/Post/2339/azure-ad-powershell-module-with-support-for-powershell-core
Another option is to write your own Powershell core module that calls the Graph REST APIs directly.
Current discussion thread:
http://devnet.jetbrains.com/message/5519081#5519081
Bug Report: http://youtrack.jetbrains.com/issue/TW-37148
Error: Cannot prompt for input in non-interactive mode.
One thing to note is that the credentials prompt is triggering on each package download instead of at the beginning. I think this may be a bug in the way Team City is calling NuGet, but I'm not sure.
I have the "NuGet Feed Credentials" build feature configured, basic auth configured, and I've run the feed in Firefox and got the list of packages to show up on the agent machine (with credentials required).
My build log: https://gist.github.com/tonyeung/517597ca2312dad85f62
The following is a workaround which may help you, although I was of the impression the NuGet Feed Credentials build feature was meant to fix the problem. I was having a similar issue with the internal TeamCity NuGet feed without guest access (called Local in this example).
Initial build step (command line - custom script)
del /F %env.APPDATA%\NuGet\NuGet.Config
%teamcity.agent.tools.dir%\NuGet.CommandLine.DEFAULT.nupkg\tools\nuget.exe sources add -name Local -source %env.NuGetFeed%
%teamcity.agent.tools.dir%\NuGet.CommandLine.DEFAULT.nupkg\tools\nuget.exe sources update -Name Local -User %env.BuildServiceUser% -pass %env.BuildServicePassword%
As I say, it's a workaround, but not too much to maintain if using templates. Hopefully it gets you up and running.
I know this is an old question, but I recently came across this issue in TeamCity 9.1.7.
In my case, the issue was that I had a trailing slash on the Server URL, found in Administration > Global Settings. Removing that slash made the authentication work correctly.
For the TeamCity 8.1.2 (build 29993), I solved this issue by installing the Nuget v. 2.8.0 at the TeamCity Administration panel (I had v.2.8.2). Then I've added "Nuget Install" build step and set up the NuGet Feed Credentials build feature.
Probably, if you'll update the TeamCity it would also fix this issue.
To solve
http://localhost:80/httpAuth/app/nuget/v1/FeedService.svc: The V2 feed at 'http://localhost/httpAuth/app/nuget/v1/FeedService.svc/Packages(Id='***',Version='1.0.0')' returned an unexpected status code '401 Unauthorized'.
issue I have done:
create local administrator account
net user tcbagent password123 /add
net localgroup administrators tcbagent /add
attach "Logon as service" permissions (using Carbon PS helpers)
Grant-CAPrivilege -Identity tcbagent "SeServiceLogonRight"
create account within TeamCity
run cmd using destination environment
runas /user:tcbagent cmd
add nuget source with credentials
nuget sources add -name local -source http://localhost/httpAuth/app/nuget/v1/FeedService.svc -UserName tcbagent -Password password123
localhost of whatever you need
check your teamcity-build.log file to get something like this:
Starting NuGet.exe 3.5.0.1284 from C:\TeamCity\buildAgent\tools\NuGet.CommandLine.DEFAULT\tools\NuGet.exe
...
Restoring NuGet package xxxx.
...
Using credentials from config. UserName: tcbagent
TeamCity v9.1.7, NuGet v3.5.0-beta
I've spend 2 days to resolve it because I'm quite new with TeamCity and CI.
Hope it was helpful.
seem like a similar issue to https://nuget.codeplex.com/workitem/4172.
Can you try the workaround at the bottom of the issue description?