How To Populate Shutdown Executable field in IIS App Pool through Powershell - powershell

In Internet Information Services Manager, for each app pool, there is an option to set path to a Shutdown Executable, and any parameters under Rapid-Fail Protection in advanced settings.
I have several app pools (a couple hundred) and would like to use a PowerShell script to automate setting
the shutdown field of each one to a program I created.
Does such a PowerShell command exist? I have pored through the appropriate documentation but with no results.

Short answer? I cant figure it out in Powershell specifically, However.. using "appcmd.exe" I was able to make this happen. I wrote a script that tried to restart the app pool and emails me the result. This script gets kicked off by the rapid fail protection. I can share this script too if you like...
However, I really didnt want to manually set every app pool as you mention, so I came up with the following.. Its not as pretty or elegant as some, but, it works:
$poolList = (Get-ItemProperty -Path "IIS:\AppPools\*").name
ForEach($pool in $poolList) {
C:\Windows\System32\inetsrv\appcmd.exe set apppool "$pool" /Failure.autoshutdownParams:"D:\_Scripts\CheckPools.ps1 -PoolName $pool"
C:\Windows\System32\inetsrv\appcmd.exe set apppool "$pool" /Failure.autoshutdownexe:"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe"
Get-ItemProperty -Path "IIS:\AppPools\$pool" -name Failure.autoshutdownexe|select *
}
I can confirm for me, with Windows 2016, this script sets the Shutdown Executable, and the Shutdown Executable Parameter. The Executable is set to launch powershell, and the parameters calls a powershell script and passes it the app pool name.

Related

Allow Win 10 user to reset network adaptor via PS script without UAC

Firstly: I have found a number of questions answered that do everything but allow me to bypass UAC. I am IT for a small business, but it is not my primary responsibility.
I have two machines in my domain that on startup often fail to correctly connect to the domain network. Restarting the network adapter fixes the issue until the machine restarts. Unfortunately, one of the machines is used by a non-admin, and a technically illiterate one at that.
I hoped to use a powershell script to do this. Using this website, I created script and batch files to solve the issue. Since the computer only has one network adaptor, I went simple:
internet.ps1
Get-NetAdapter | Restart-NetAdapter
internet.cmd
#ECHO OFF
SET ThisScriptsDirectory=%~dp0
SET PowerShellScriptPath=%ThisScriptsDirectory%internet.ps1
PowerShell -NoProfile -ExecutionPolicy Bypass -Command "& {Start-Process PowerShell -ArgumentList '-NoProfile -ExecutionPolicy Bypass -File ""%PowerShellScriptPath%""' -Verb RunAs}";
Unfortunately, I don't fully understand the last command in the batch file. As such I struggle to research the command to pass some form of user credential. This environment is not very secure. But I don't want to give this user domain admin permissions generally, or provide them with some admin credentials which would end up on a sticky note. Either option is just inviting trouble from my older, technically illiterate colleagues. And going over to punch in credentials every day is time consuming.
I am looking for a script that cycles the network adaptor and provides the necessary credentials to make that change so a non-admin user can fix their domain and internet access without having admin credentials on a post-it note.
You could schedule a task using the Task Scheduler in Windows. When scheduling a task, you can specify credentials for the task to use when it runs. You can add a trigger for this task to have it run when the computer starts, or you can simply allow the user to manually start it.
If you decide to go this route, there is a check box you can check that runs the program with the highest possible privileges. The entire point of that last line is to start a new PowerShell window that runs as administrator so it actually has permission to restart the adapter. This means that you can get rid of almost your entire script, and just keep the part that actually restarts the adapter.
For example, when you go to create a new task in Task Scheduler, under the Actions tab, you can create a new action and enter the following:
Program/script:
PowerShell
Add arguments:
-Command "Get-NetAdapter | Restart-NetAdapter"
Note: I'm not sure if this is still the case, but in my past experience, sometimes it will try to run before Windows is fully loaded. If it doesn't seem to be doing anything on startup, you may need to add a delay to it. You can do this by running the Start-Sleep command. You can add it to the arguments field by doing the following:
-Command "Start-Sleep 5; Get-NetAdapter | Restart-NetAdapter"
Replace the number 5 with how many seconds you would like it to wait.

Powershell takes minutes to load script / show prompt [duplicate]

I have slow PowerShell console startup times (always more than 5 second wait) and was hoping for advice on troubleshooting steps to find out where the bottlenecks might be?
I have read that for running scripts, -NoProfile is important to prevent Modules etc loading, but how, in general, should we approach finding out what is slowing things down? I don't have many Modules installed and I know that since PowerShell 3.0, Modules are just referenced at startup and not fully loaded (a Module is only fully loaded when a function from a given Module is invoked) so I just can't understand why it takes 5+ seconds to start a bare console (my $profile also is empty).
Any advice on various steps that I can look at to debug the console startup process would be appreciated? Also, are there maybe some Microsoft or third-party tools that exist to debug the various steps in the console startup process to look for bottlenecks?
When PowerShell starts to become slow at startup, an update of the .NET framework might be the cause.
To speed up again, use ngen.exe on PowerShell's assemblies.
It generate native images for an assembly and its dependencies and install them in the Native Images Cache.
Run this as Administrator
$env:PATH = [Runtime.InteropServices.RuntimeEnvironment]::GetRuntimeDirectory()
[AppDomain]::CurrentDomain.GetAssemblies() | ForEach-Object {
$path = $_.Location
if ($path) {
$name = Split-Path $path -Leaf
Write-Host -ForegroundColor Yellow "`r`nRunning ngen.exe on '$name'"
ngen.exe install $path /nologo
}
}
Hope that helps
Step 1: Stop using PowerShell.
Now, seriously, something that needs ~13 seconds (YMMV) on an quad-core i7 cpu to launch off an ssd drive is an abomination of software architecture.
But yes, I hear you, "no viable alternative" etc...
... but if forced, bribed or blackmailed to still use it, check if your Windows has DNS cache service enabled.
For me, with DNS cache disabled and powershell executable firewalled, the built-in 5.1.19041.906 version starts quickly, but the new pwsh 7.1.4 would take around 13 seconds to get responsive to keyboard input under the same circumstances. It's so desperate to call home that it would just synchronously wait for some network timeout while blocking all user input, as if threads were a thing for the weak.
My resolution was to stick with the olden powershell 5.
My work computer stored the main profile on a remote server. Another minor problem was that it imported duplicate modules from 4 different profile.ps1 files.
Use the following commands to see where your profiles and modules are stored. Delete the unnecessary profile.ps1 and move all your modules into one directory.
echo $env:PSModulePath
$profile | select *
My loading time was reduced from 21000ms to 1300ms.
Found this solution when I googled having the same problem, but in 2022. Unfortunately this did not fix my issue.
Our systems have a group policy security requirement to "Turn on PowerShell Transcription". The policy requires that we specify "the Transcript output directory to point to a Central Log Server or another secure location". The server name changed and no one updated the policy. As soon as I updated the GPO with the new location, PowerShell opened instantly again.
Press Windows+R
Type %temp% and hit enter
C+A & SHIFT+DEL
That should do it

Powershell run Script in ISE full window

Is there a was for a Powershell script to be launched from Scheduler and run full ISE window and close when done.
I am using ZeeDrive to map a SharePoint Drive but running the Script in Scheduler, it cannot see the Drive. Yet if I open in ISE and run, it finds it fine. What I got back from ThinkScape :
'Zee Drive needs to run in a Windows session. It is designed for end users – if it is running as a service, or “headless” i.e. no Windows session, or being accessed from a different Windows session it won’t work.
We don’t support Zee Drive running as a service or for service type workloads – it is designed for end users working with documents'.
Any help would be greatly appreciated.
Thanks
The only way I can think of, would be to add your script to the Microsoft.PowerShellISE_profile.ps1 and then start ISE with the scheduler and your file as parameter, like this:
powershell_ise .\Check-Process.ps1
In your profile you would want to make sure, that the script only runs, when you open that file:
if($psISE.PowerShellTabs.Files.FullPath -eq '\\fileserver\path$\to\my\Powershell\Check-Process.ps1')
{
& '\\fileserver\path$\to\my\Powershell\Check-Process.ps1'
}
But be carefull! The script runs now everytime you open it in ISE unless you use the switch -noprofile.
So far I did not find a way to close the ISE window with the profile script.

How to show the current pshostprocess and runspace information?

When debugging a powershell DSC resource, we have a help from the DSC resource which shows the commands needed to attach the debugger to the right Powershell Runspace. As described in https://overpoweredshell.com/Troubleshooting-DSC/:
I want to be able to output the same kind of help from my powershell script, nothing to do with DSC.
So, how do I figure out my current PSHostProcess, AppDomain and Runspace Id from my powershell script?
I do not want to debug in ISE or any other GUI (for the reasons irrelevant to the question).
The process ID of the host process is available via the $PID automatic variable.
The name of the containing AppDomain can be found via:
[AppDomain]::CurrentDomain.FriendlyName
but is usually not necessary when targeting most host applications (such as powershell.exe or powershell_ise.exe)
For the runspaces, use Get-Runspace from the host application:
Get-Runspace

Using $env:username in a logon script is not working

I have this setup with a GPO to run as a logon script, obviously to map a drive for clients.
net use H: \\server1\share\$env:username
Dead simple. If I put in a specific username in place of the variable then it works. Also, if I run this script directly on a client machine it works.
Do you get an error? Does it helps if you wrap the path in double quotes?
"\\server1\share\$env:username"
That should work with or without the quotation marks. Are the clients all Windows 7? I believe that Powershell logon/startup scripts don't work on earlier versions, even if you have Powershell installed, because it's an add-on rather than a native shell. If you're using downlevel clients, you can invoke the powershell script from a cmd batch file. But if you're going to do that, might as well skip Powershell and just run net use H:\\server1\share\%username% from your batch file.
Run this in a .bat file as a login script (use a FQDN for the server name):
net use H: \\server.example.com\share\%USERNAME%
If that not works, your GPO is just not yet applied. You can force that by running on the machine gpupdate /force.
For testing make sure that the GPO is applied to the right OU to the group "Authenticated Users" (computers are in the group too). And if that is not working, you can also "Enforce" the GPO. Don't forget to do a gpupdate /force after any change to the GPO or it settings.
You can also try a .js logon script like:
var WSH = new ActiveXObject("WScript.Shell");
// Map share
WSH.Run("net use H: \\\\server.example.com\\share");