Using profile on PowerShell not on ISE - powershell

I am basically trying to customize my PowerShell a bit using a profile. I'm following some instructions from Internet, but the configuration works on the ISE but not on PowerShell itself. I'm using the profiles $PROFILE.AllUsersAllHosts.
Here are some sceenshots:
Works on ISE:
but not on PowerShell

This is in my ISE profile (I use my ISE as my master).
cp -Force "C:\Users\USERNAME\Documents\WindowsPowerShell\Microsoft.PowerShellISE_profile.ps1" "C:\Users\USERNAME\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1"
Basically it writes whatever is in my ISE profile to my normal powershell profile everytime I start up ISE.
Depending on whether you are using ISE or plain Powershell $profile is a different value
Plain PowerShell
$profile = C:\Users\USERNAME\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1
ISE
$profile = C:\Users\USERNAME\Documents\WindowsPowerShell\Microsoft.PowerShellISE_profile.ps1
You could theoretically change the value of $profile in one so that it uses the other :)

Related

How to determine if my PowerShell script is being executed by Windows Terminal?

I want to do something special when my PowerShell script is being executed by Windows Terminal and not the normal PowerShell command line or ISE. How to determine that? I checked some built-in variables like $Host and can't find related information.
Disclaimer: Windows Terminal is still in development at this time of writing and this information could change for the stable release.
Look for the $env:WT_SESSION environment variable - this looks to be set to a GUID in a Windows Terminal session, but not when running powershell.exe or running powershell.exe through ConEmu, both of which I also tested.

Local Powershell script to trigger VBS script inside Citrix instance

I am trying to get a local powershell script to trigger a VBS script inside a citrix instance. The events should be this:
Citrix Instance opening Windows Explorer ----> Network Path of script typed into the windows explorer session
I'm using the WfIcaLib.dll (ICOSDK) that came with the Citrix receiver install. Documentation PDF for the Citrix ICOSDK is available here
So this is the code I'm using, which works PERFECTLY in Powershell command line, but when I use the 32-bit ISE, it does nothing other than telling me the DLL has been loaded. I get no errors, but the Citrix Client never actually opens like it does when I run the same exact commands through Powershell command line.
#load Citrix ICA Client SDK
[System.Reflection.Assembly]::LoadFile("C:\Program Files (x86)\Citrix\ICA Client\WfIcaLib.dll")
$ICA = New-Object WFICALib.ICAClientClass
$ICA.Address = "***.***.***.***:****"
$ICA.Application = "Windows ExplorerFED6"
$ICA.Username = "******"
$ICA.Domain = "**"
$ICA.Launch = $true
$ICA.Outputmode = [WfIcaLib.OutputMode]::OutputModeNormal
$ICA.SetProp("Password", "*********")
$ICA.TWIMode=$true
$ICA.Connect()
Any ideas?
EDIT: SOLVED - after reopening under 32-bit ISE and getting code to work, I could not run the .ps1 file since it kept defaulting to 64-bit (even if using Open With on 32-bit powershell version). Running the script via command prompt or 32-bit powershell console both worked.
Using any method suggested by Mike Garuccio worked just fine. I will most likely end up using a Task Scheduler to run the script.
It looks like the problem is a versioning one, which you can deal with using start-job (was originally going to do this with a runspace but that's a lot more code for no real benefit). This will start a job to run your code under 32-bit powershell, it should still place any GUI elements or popups on screen but if you need to get any data out from the script later you'll need to receive the job. code would look something like below.
$SB = {
[System.Reflection.Assembly]::LoadFile("C:\Program Files (x86)\Citrix\ICA Client\WfIcaLib.dll")
$ICA = New-Object WFICALib.ICAClientClass
$ICA.Address = "***.***.***.***:****"
$ICA.Application = "Windows ExplorerFED6"
$ICA.Username = "******"
$ICA.Domain = "**"
$ICA.Launch = $true
$ICA.Outputmode = [WfIcaLib.OutputMode]::OutputModeNormal
$ICA.SetProp("Password", "*********")
$ICA.TWIMode=$true
$ICA.Connect()
}
Start-Job -ScriptBlock $SB -RunAs32
get-job | Receive-Job
Alternatively, you could also use a simple .bat file as a launcher with something like C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe -file yourscript.ps1
or if you need everything to be wrapped in powershell and the job does not work you can use the solution Here that basically does the same thing but from within powershell (drop the if statement they use tho, just use the stuff contained inside it like below, with any changes you need to make wrt the profile and interactive settings.)
&"$env:windir\syswow64\windowspowershell\v1.0\powershell.exe" -noninteractive -noprofile -file "C:\Path o\script.ps1" -executionpolicy bypass
hope one of those works for you!

Is it possible to start Powershell ISE with specified (not default) profile?

I want to have several (more than one) PowerShell profiles which will create different environments.
More specifically I need way for start separate PowerShell ISE for work with TFS and other PowerShell ISE instance for regular work. 'TFS' environment require loading some additional snappins, modules, modify prompt and so on. I do not want all this stuff will be executed for regular PowerShell ISE sessions but only when I want to.
I found that I can automatically load arbitrary script through command line parameter -File, but it does not executed automatically..
I do it by creating a shortcut for PowerShell ISE with a default directory :
In the default Directory (here called D:\TFS) I create a .PS1 file called local_profile.ps1.
In the beginning of the current profile file (C:\Windows\System32\WindowsPowerShell\v1.0\profile.ps1) I add :
# Try to load local profile
Get-ChildItem "local_profile.ps1" -ErrorAction SilentlyContinue | %{.$_}
You just have to add your initialization code to D:\TFS\local_profile.ps1.
powershell ISE has a profile too.
Probably is something like:
E:\Users\UserName\Documents\WindowsPowerShell\Microsoft.PowerShellISE_profile.ps1
Or you can open powershell ise and look at $profile variable.
After locate your profile file, write your modules import and custom scripts in it.

Load script from PowerShell ISE's command environment

Is there a way to open a script file ($profile or otherwise) from within the IDE's command environment (PS> prompt), such that it loads in the IDE itself?
# loads the current user/current host profile in Notepad (probably because .PS1 is associated w/ Notepad.exe)
PS > ii $profile
# same for any random script file
PS > ii .\Foo.ps1
Instead of Invoke-Item, just use ise. When run from the ISE, it will load the file.
PS> ise myscript.ps1
To make Invoke-Item behave like you want (as well as double-clicking from Explorer), you can associate .ps1 files with powershell_ise.exe. Here is a blog post explaining how to do this if you need it.

PowerShell script to restart a service

My mission is to press a keyboard sequence, such as Ctrl +Shift +R, to restart a Windows Service.
I have a script which works fine in the PowerShell ISE, when launched with administrative privileges.
When I try with a PowerShell script it fails due to insufficient Administrative Privileges. It’s galling that I can get it to work with an old-fashioned bat file, but not PowerShell.
The root of the problem is that shortcuts to a PowerShell script have their Administrative privileges box greyed out. So far no work-around has overcome this privilege problem.
Any ideas?
One approach is to start another elevated PowerShell session within your script like so:
Start-Process PowerShell.exe -arg '-nologo -noprofile script.ps1' -verb runas
That should prompt to elevate the new PowerShell session. I think you should be able to set the -WindowStyle parameter such that the new window doens't appear (if you need that behavior). Note that you will need to specify the full path to your existing script.
You suggest you don't like solving this problem with a batch file (e.g. net start), I think because batch files are inherently more limited than powershell scripts. What you can do is wrap your Ps script in a batch file, though, for the sake of accomplishing your stated objective -- running a powershell script with a keyboard shortcut without access permissions issues. Try this in a batch file:
powershell set-executionpolicy remotesigned
powershell myscript.ps1