Windows service environment - what am I doing wrong? - powershell

I'm installing my own Windows service. It requires it's own Environment. No tool that I know handles it, so I manually edit registry.
I have service installation script written in PowerShell, so my first idea was to do this:
New-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\services\MyService" -Name Environment -Value "EnvVar=value" -PropertyType MultiString
The problem is, while the key appears int the registry, it is not used by my service, even after powercycle.
Experimenting, I found out that if I edit it in regedit, it works and the key is used by my service. So, I hanged it to this:
Invoke-Expression "reg.exe add ""HKLM\SYSTEM\CurrentControlSet\services\$name"" /v ""Environment"" /d ""EnvVar=value"" /t REG_MULTI_SZ /f"
and now it works :D
Whats wrong with my usage of New-ItemProperty? I'm doing everything as admin, and I'm avare of 64/32bit issues (and I don't think they apply here - my software is 64bit, windows is 64bit, everything is 64bit :))
It adds the key to the registry but it is not used, while adding the same key using regedit.exe or reg.exe works fine. Maybe I'm hitting some bug? (OS: Windows Server 2012, 64bit)

Related

Removing regedit key via powershell

I have been removing powershell and/or command line like below. My question is : Is there any equivalent inside powershell for /reg:64 parameter ?
CMD version:
reg delete HKEY_LOCAL_MACHINE\SOFTWARE\TEST /v PropertyToRemove /f /reg:64
powershell version:
Remove-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\SMS\Mobile Client" -Name "PropertyToRemove"
thanks,
It looks like it's not implemented.
Reading this question: Querying via powershell both 32bit and 64bit registry
it seems you should just be checking whether the os is x32 or x64 first
or run a check if the 64bit registry keys exists
Different topic, same question.. here's stated it's not implemented:
How to access the 64-bit registry from a 32-bit Powershell instance?
look at whenrybruce's reply on the marked answer

Disable UAC on apps that installed from network drive

So I need to uninstall some program and clean all the leftovers (folders + registry)
and then install the new app with all it dependencies - all this on 150 workstation
I've created a Powershell script and it's doing all the mention above without any issues,
the issue begins when I need to run the installation, it's located on a network share, here is the syntax:
Set-Location "\\imapps\FileSiteClientInstall\Setup Imanage\DRIVE -iManage Drive for Windows 10.2.6.48"
Start-Process iManageDrive.exe /s
The issue is that i have 6 lines like this one (each installation file is in a different folder),
and when I run this from the network I'am getting this UAC
is there a way to disable it, and make my script to run fully automatically?
Thanks alot for your help :)
So, not really UAC for what most people think of UAC. This is warning about running an executable from an untrusted location (not on a local drive). You'd get the same thing with a script that you download from the internet. What you can do is use the Unblock-File cmdlet to get past that warning like this:
Set-Location "\\imapps\FileSiteClientInstall\Setup Imanage\DRIVE -iManage Drive for Windows 10.2.6.48"
Unblock-File .\iManageDrive.exe
Start-Process iManageDrive.exe /s
This should mark the file as safe, and avoid the prompt you've been getting.

Royal TS PowerShell remote session does not work

I need to set up a PowerShell entry which connects with the PowerShell of the given server.
I haven't found anything helpful except of this instruction.
Instead of getting a PowerShell connection with the desired server I get a PowerShell connection of my local PC.
I also tried the same for cmd.exe and for Git Bash with no success.
I also tried to create tasks, but also with no success.
In all the cases I get the connection with my local PC.
My host system is: Windows 8.1 Enterprise 64 Bit
Royal TS: 3.2.9 (Build #60630)
What am I doing wrong?
Mostly solved :-)
By External Application Settings for PowerShell:
Command: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Arguments: -NoExit Enter-PSSession -computername my-remote-server
Working Directory: C:\Windows
-computername my-remote-server was missing, thatwhy it has not worked.
Unfortunatelly Working Directory does not work, I still land in C:\Users\j.sinitson\Documents.
Does someone know how to solve that?

Error trying to pass in variables when calling MSI file

I am very new to using Powershell but keen to learn.
I am attempting to install a MSI package, using PowerShell and passing in some variables. The end result is for this to be an unattended installation deployed via Jenkins using PowerShell. Please keep in mind I have changed the port numbers for this example:
msiexec /i /quiet $SYSTEMID ="PC01" $PORT1 =0000 $PORT2 =0001 $TARGETDIR ="C:\Application\" "C:\MSIPackage64bit.msi"
When trying to run the above I get presented with a Windows ® Installer. pop up which lists a load of MSIExec variable options.
I have been looking on the web for quite some time and now believe I'm having issues due to my lack of understanding when it comes to PowerShell.
/I needs to be followed by the path to the MSI to be installed. Also get rid of the $ in front of the property names. Finally TARGETDIR isn't always TARGETDIR. Some MSIs are authored as INSTALLDIR, INSTALLLOCATION and other possible directory table entry names. Adding logging ( /l*v path_to_log ) is usually a good choice also.
PS- Please note that since you are doing a silent installation you need to either be installer per-user without need for elevation or you need to already be elevated.

How to change default install path for Notepad++ in Powershell

I cant figure out the parameter(s) to change the default install path C:\Program Files\ of Notepad++ to the drive I want it to install to when I run my Powershell script. I am trying to do a silent install and can't change it manually. Does anyone know what parameters I can add to install the program to the E:\ drive? Below is my code and what I am trying in powershell. I have been messing around a lot with the -ArgumentList parameters to figure out if I can point it to the E:\ drive but no luck so far.
function install-Notepadpp()
{
$install="*PATH*\npp.6.6.2.Installer.exe"
Start-Process -FilePath $install -ArgumentList '/InstallDirectoryPath:"E:\"','/S' -Wait -Verb RunAs
Write-Host “Notepad++ has been installed.” -ForegroundColor Green}
##### This is Windows calling the function to install the script
install-Notepadpp
Do you really require an installation? You have the standalone package out there on dev site, you can copy it wherever you want. As for the 'cool' context menu addons, they are simple enough to add manually.
Below is the brief description of steps you need to take to get this done:
Have your Powershell copy the content of standalone package to the
desired folder.
Generate a new GUID using Powershell
[guid]::NewGUID()
Write down the GUID to variable (so you can reference it later).
Under HKEY_CLASSES_ROOT\CLSID\ add GUID entry in the same way the
rest of GUIDs are added.
Create a subcontainers InprocServer32 and Settings
In the InprocServer32 set the (Default) value to desired
Notepad++ installation path pointing directly to NppShell_06.dll (ex.
C:\Program Files\Notepad++\NppShell_06.dll)
Add ThreadingModel REG_SZ entry and set its' value to Apartment
In the Settings subcontainer, set the values accordingly - for a
list of valid values, please reference a machine with Notepad++
installed. The most "interesting" ones are "Path" and "Title"
Add the GUID entry you generated earlier to subcontainer "ANotepad++"
in HKEY_CLASSES_ROOT*\shellex\ContextMenuHandlers\ under (Default)
value
This should do it. Although I did not test the above on my machine, I am pretty confident that this will sort out the "manual" installation issue. As a sidenote, it could be worth as a suggestion to developer (or, as a best way, write it on your own!) to add some silent installation configuration switches so that we don't have to bother with the above 'workarounds'. Should you run into some issues setting this up, let me know.