I have a functions app written in Powershell that worked up until a month or so ago.
The function uses a module (https://www.powershellgallery.com/packages/NTware.Ufo.PowerShell.ObjectManagement/2022.2.0.1) that is only compatible with "Widows Powershell".
The module is loaded as follows:
Import-Module $PSScriptRoot\Modules\NTware.Ufo.PowerShell.ObjectManagement.dll -UseWindowsPowerShell
The module allows connection to an external Azure environment that hosts an application.
The error returned is:
2022-09-02T13:38:31Z [Warning] WARNING: Module NTware.Ufo.PowerShell.ObjectManagement is loaded in Windows PowerShell using WinPSCompatSession remoting session; please note that all input and output of commands from this module will be deserialized objects. If you want to load this module into PowerShell Core please use 'Import-Module -SkipEditionCheck' syntax.
2022-09-02T13:38:34Z [Error] ERROR: Failed to authenticate.
OriginInfo : localhost
Exception :
Type : System.Management.Automation.RemoteException
SerializedRemoteException : System.ArgumentException: Failed to authenticate. ---> Microsoft.Identity.Client.MsalServiceException: AADSTS1002016: You are using TLS version 1.0, 1.1 and/or 3DES cipher which are deprecated to improve the security posture of Azure AD
I have tried the following without success:
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
Import-Module $PSScriptRoot\Modules\NTware.Ufo.PowerShell.ObjectManagement.dll -UseWindowsPowerShell
I suspect the issue is that the remote Azure environment has started enforcing TLS 1.2. I have set my Azure Function App to also use TLS 1.2.
Any ideas on where the issue might be?
Modules imported with the -UseWindowsPowerShell are in fact loaded to a separate Windows PowerShell session in a separate process (see about Windows PowerShell Compatibility). Changing the [Net.ServicePointManager]::SecurityProtocol variable in the local process does not affect other processes. You need to update this variable in the remote process, here is how:
$session = Get-PSSession -Name WinPSCompatSession
Invoke-Command -Session $session -Command {
[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12
}
Related
I'm trying to create a pool of applications with specific parameters using this code:
$currentAppPool = New-WebAppPool -Name myNeyAppPool
# Set pool specifications
$currentAppPool.AutoStart = "true"
$currentAppPool.ManagedRuntimeVersion = "No Managed Code"
$currentAppPool | Set-Item
I have several errors because setitem asks me for a path variable that it doesn't recognize. Set-Item: The input object cannot be bound because it did not contain the information required to bind all mandatory parameters: Path
I tried to give it the parameter -path IIS:\AppPools\myNeyAppPool but I get the message
Set-Item: Cannot find drive. A drive with the name 'IIS' does not exist
There are quite a few changes concerning the management of IIS in w10 via powershell 7, but little documentation seems to exist on the subject.
Is there anything help ?
Thks,
The provider "IIS:" is loaded when importing the webadministration module.
Providers before and after to load webadministration module
Do you have IIS role enabled in windows 10?
You can check the following link:
https://community.lansweeper.com/t5/installation/how-to-install-iis-internet-information-services/ta-p/64422
Which providers appear if you run the "Get-PSProvider" command?
First try running PowerShell as an administrator, and then the drive is provided by the WebAdministration module, so you need make sure install that module, you can install the module with the following PowerShell commands:
Import-Module ServerManager
Add-WindowsFeature Web-Scripting-Tools
Disclaimer: I am not a DevOps guy so please forgive any ignorance. I'm learning this stuff to expand my understanding.
I've enabled remote Powershell on a Windows Server 2019 instance in order to stop/start scheduled tasks during deployment of files from my build server (also Windows Server 2019).
I followed the below steps in an Administrator Powershell as the Adminstrator user on the remote server:
1. Enable RSRemoting.
2. Remove existing listener.
3. Create self-signed certificate and export to crt file.
$Cert = New-SelfSignedCertificate -CertstoreLocation Cert:\LocalMachine\My -DnsName "<subdomain.domain.com>"
Create listener.
Create firewall rules to allow secure PSRemoting and disable unsecure connections.
Copy certificate to build server.
Import certificate on build server.
From the build server, I've tested the configuration using the following commands in Powershell:
$username = 'Administrator'
$pass = ConvertTo-SecureString -string '<password here>' -AsPlainText -Force
$cred = New-Object -typename System.Management.Automation.PSCredential -argumentlist $username, $pass
Invoke-Command -ComputerName <subdomain.domain.com> -UseSSL -ScriptBlock {whoami} -Credential $cred
Which responds nicely with win-<some stuff>\administrator. However, when I execute a remote Powersehll command from within a TeamCity build step, I get a big ugly Connecting to remote server <subdomain.domain.com> failed with the following error message : Access is denied..
The weird part is, this worked two days ago and I have several builds that were able to complete all remote operations. From this morning, it's just stopped working - poof!
If I fudge the credentials, I do get an incorrect username/password error so it is definitely reaching the server.
Another interesting find is that if I run
[bool](Test-WSMan)
on the remote server, I get True returned, but if I run the same command with -ComputerName <subdomain.domain.com> on the build server, I get
WinRM cannot complete the operation. Verify that the specified computer name is
valid, that the computer is accessible over the network, and that a firewall exception for the WinRM service is enabled and allows access from this computer. By default, the WinRM firewall exception for public profiles limits
access to remote computers within the same local subnet. returned.
Both the remote host and build server are logged on as the default Administrator.
Any ideas?
After more research and calling in a few favours, I was advised to tweak the TeamCity Build Agent and TeamCity Server services. These need to Log On As a User and not Local System. I can't explain how my previous settings worked. The Access is denied error I experienced has nothing to do with the Remote Powershell configuration mentioned above.
With the release of powershell 7, seems like it is time to move past ps 5.1 so I have installed in on a couple of servers to give it a go.
However I when I create a session to these servers from my pc with ps7 I am always running ps5.1 on the remote machine.
Invoke-Command -ComputerName name -ScriptBlock {
Write-Host $env:COMPUTERNAME
$PSVersionTable.PsVersion
}
Which outputs 5.1.17763.316. Any ideas how to get the remote session to use version 7.0.0 preferably by default?
Update
making some progress with this, so though I would share.
On the remote machine in powershell 7 run the following command
Enable-PSRemoting
This will create some PsSessionConfigurations which you can see with the following command..
Get-PSSessionConfiguration
Now you can do the following to create sessions from powershell 7
Invoke-Command -ComputerName ServerName -ScriptBlock { $PsVersionTable.PSVersion } -ConfigurationName Powershell.7
$session = New-PSSession ServerName -ConfigurationName Powershell.7
Invoke-Command -Session $session -ScriptBlock { $PsVersionTable.PSVersion }
This now uses ps 7 on the remote session, happy days. Now how to make this happen by default...? From this github issue :
set the default microsoft.powershell endpoint to any PowerShell they
choose
Which I think is what I want to do so switched back to ps 5.1 and tried this command:
Get-PSSessionConfiguration -Name microsoft.powershell | Set-PSSessionConfiguration -PSVersion 7.0
Only to get the following output:
Set-PSSessionConfiguration : Cannot bind parameter 'PSVersion' to the
target. Exception setting "PSVersion": "The value 7.0 is not valid for
the PSVersion parameter. The available values are 2.0, 3.0, 4.0, 5.0,
5.1."
though I would try this in ps7 so switched back by running pwsh and ran the same command again to get he following...
Write-Error: No session configuration matches criteria
"microsoft.powershell".
So still not quite sure how to make ps7 the default... :(
Note:
It is the remoting client that determines what remoting endpoint (session configuration) to connect to on the server machine - see below.
Therefore, your own attempt,
# WRONG
Get-PSSessionConfiguration -Name microsoft.powershell |
Set-PSSessionConfiguration -PSVersion 7.0
is ineffective, because Set-PSSessionConfiguration modifies endpoint configurations on the server machine, it doesn't control the client's behavior.
Note that the fundamental prerequisite is that PowerShell remoting must be enabled on the server machine, which can be achieved either by opting to do so during installation via the MSI GUI installer, or by running Enable-PSRemoting - with admin privileges - later.Tip of the hat to Lars Fosdal.
Doing so from PowerShell (Core) creates the standard session configuration(s) named PowerShell.<version> that clients can opt to connect to - see below.
To list all configurations defined on a server, run Get-PSSessionConfiguration with admin privileges.
On a client machine, you can set a default for what session configuration defined on the server (remote machine) to connect to, via the $PSSessionConfigurationName preference variable.
E.g., to target PowerShell 7 by default:
# When remoting, default to running PowerShell Core v7.x on the
# the target machines:
$PSSessionConfigurationName = 'PowerShell.7'
If you add the above to your $PROFILE file, future sessions will target PowerShell 7 by default.
See this answer for more information, which also shows how to target a given server configuration in the context of individual commands.
Note: Changing what endpoint PowerShell [Core] targets by default - which as of 7.2 is still Window PowerShell - is being considered: see GitHub issue #11616.
I'm having a problem getting a PowerShell script which queries objects in a cloud-based Exchange resource to work in an Orchestrator runbook.
The PowerShell script (which works correctly from my desktop computer's command line and when stepping through it in ISE) sets up a remote management session to the cloud and looks like this:
try
{
$user = "username#domain.com"
$pword = convert-toSecureString -string "password" -asplaintext -force
$creds = new-object -typename system.management.automation.pscredential -argumentlist $user, $pword
$o365 = new-pssession -configurationname Microsoft.Exchange -connectionuri https://ps.outlook.com -credential $creds -authentication basic - allowredirection
import-pssession $o365 -allowclobber -prefix o365
get-o365Mailbox 'Doe, John'
}
catch
{
throw $_.exception
}
As I mentioned, it runs fine when I step through it in the editor on my desktop but when executed inside the Orchestrator runbook it fails on the "import-pssession" command (because the $o365 is never set).
I've taken the PowerShell script and run it manually on the actual runbook server and it works there as well as it does on my own desktop -- it's only when run inside of an Orchestrator runbook that it won't function. I only have a few weeks experience with Orchestrator and didn't know I'd run into a problem like this so quickly -- I am trying to run the script in a "Run .Net Script" activity with the language set to "Powershell," which I believe is the recommended method.
I've tried saving the script as a file on the runbook server and then used the "Run Program" activity to run PowerShell with this file (recommended by someone during my searching) and that doesn't work either.
Is the Orchestrator service account that's running the script a member of the Exchange RBAC role groups? If not, it won't be allowed to connect to those Exchange management sessions.
The problem turned out to be related to the client's firewall and proxy settings for the service account they set up to be used by Orchestrator. They (the clients) would not grant the service account Internet access as a matter of policy.
A couple of different solutions came up: One was installing the PowerShell integration pack from CodePlex and using that -- the CodePlex PowerShell activity allowed me to explicitly set the security context of the activity, which let me get around their firewall issue by running the activity under an account which did have Internet access.
The second solution was installing the Exchange Admin integration pack and configuring a connection to the cloud host. Using the "Run Exchange PowerShell Command" activity rather than the more generic "Run .NET script" activity also allowed the code to work as expected.
Orchestrator is still x86 and the commands in your script will only run in x64.
Test this in your x86 ISE and see the same failure.
My workaround is to call the script using the "Run Program" activity within the System activities list.:
Program execution
Computer = I always start with initialize activity and then subscribe to the computer here
Program path: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Parameters: full path to the .ps1 of your script
Working folder: c:\temp
I have a WiX MSI installer for an ASP.NET website that runs on my_server. The package is installed via a very simple Powershell script install.ps1 that just calls msiexec with some parameters.
The problem
When I run install.ps1 directly on my_server, everything is fine. But when I want to run install.ps1 on my_server from a remote machine (e.g. build_server), the installation fails with error code 1603 and the MSI install log reveals the the following error:
Action start 14:22:30: ConfigureUsers.
ConfigureUsers: Error 0x80070005: failed to add/remove User actions
CustomAction ConfigureUsers returned actual error code 1603
Any suggestions?
Extra information
I run install.ps1 remotely with the following command:
Invoke-Command -ComputerName my_server -ScriptBlock { path\to\install.ps1 } -Authentication Negotiate
I use the same user credentials on both my_server and build_server.
In the WiX definition, the website is set up with a specific user account for the app pool, like this:
<Component Id="AppPoolCmp"
Guid="a-fine-looking-guid"
KeyPath="yes">
<util:User Id="AppPoolUser"
CreateUser="no"
RemoveOnUninstall="no"
Name="[APP_POOL_IDENTITY_NAME]"
Password="[APP_POOL_IDENTITY_PWD]"
Domain="[APP_POOL_IDENTITY_DOMAIN]">
</util:User>
<iis:WebAppPool Id="AppPool"
Name="[APP_POOL_NAME]"
ManagedPipelineMode="Classic"
ManagedRuntimeVersion="v4.0"
Identity="other"
User="AppPoolUser">
<iis:RecycleTime Value="5:00" />
</iis:WebAppPool>
</Component>
This is likely to be the double hop issue, your credentials are not valid beyond the scope of the first server.
Can you do the command with the option:
-Authentication CredSSP
Rather than Negotiate.
You will also need to specify credentials manually using the -Credentials flag as well as set up the client and server for CredSSP:
Enable-WSManCredSSP -Role Client -DelegateComputer HOSTNAME -Force
Enable-WSManCredSSP -Role Server -Force
The steps are explained in more detail here.