In automating Windows (2012R2 and 2016) builds, I found that even though I set a system-wide proxy via netsh, I still had to set the HKCU values for IE because some commands would not work without those values set. I would have to open IE and visit a site, any site, to initialize those settings, which was annoying.
I was able to find some PowerShell code that could "initialize" the IE proxy settings so I did not have to open IE and visit a site, shown below:
$Source=#"
[DllImport("wininet.dll")]
public static extern bool InternetSetOption(int hInternet, int dwOption, int lpBuffer, int dwBufferLength);
"#
$wininet = Add-Type -memberDefinition $Source -passthru -name InternetSettings
$wininet::InternetSetOption([IntPtr]::Zero, 95, [IntPtr]::Zero, 0)|out-null
$wininet::InternetSetOption([IntPtr]::Zero, 37, [IntPtr]::Zero, 0)|out-null
The above code is from https://vanderpaal.com.au/2016/09/30/live-proxy-setting-change/ (thanks!)
The above code works great when executed manually via RDP session. I set the IE proxy values correctly, I run the above code, and I can then do whatever I want - it all works. The commands that require the IE settings work fine.
I have been trying to run more code via remote WinRM using things like Ansible and SSM (in AWS). When I do, weird things happen.
Specifically, the IE proxy registry entries get deleted and reset back to defaults. So, the order of doing things via script is:
Write IE proxy values to the registry via script called by Ansible or SSM.
Run the initialize proxy code listed above.
IE values from #1 are gone...
I am at a loss as to why the registry values get deleted. I am 100% sure they get deleted - I can script a reg query before and after the initialize proxy commands - before the commands they exist, and after the commands they do not. This does not happen when I run the same scripts manually on the server in an RDP session - that is, the proxy command does NOT delete the entries.
I have replicated this in both Ansible and SSM, both of which use PowerShell and WinRM to run commands. The scripts reside on the actual server, and Ansible/SSM tell the system to execute the scripts.
I have verified that HKCU actually exists during Ansible execution of the scripts.
Because the IE values get deleted, the initialize command does me no good when the following commands that require the IE values execute. Those commands fail with errors like so:
PackageManagement\Install-Package : No match was found for the specified
search criteria and module name ''
The commands I am running (which fail) are just install module commands, like so:
Install-Module -Name PSWindowsUpdate -Proxy http://proxy.foo.com:80 -Confirm:$false -Force
Install-Module -Name PowerShellGet -Proxy http://proxy.foo.com:80 -Confirm:$false -Force
Anyone know why the IE proxy registry values get deleted when I run the code above via Ansible or SSM? The proxy values in question are:
"HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyEnable" - this gets reset to 0
"HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyServer" - this gets deleted
"HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyOverride" - this gets deleted
had the same problem. and found out that the damned ie wizard was the root cause.
u have to add following key to registry before u can access ie components...:
desc: "Remove IE 11 first run Wizard"
path: "HKLM:\\Software\\Policies\\Microsoft\\Internet Explorer\\Main"
name: "DisableFirstRunCustomize"
data: "1"
type: "dword"
I am having an issue getting AutoAdminLogon working with my Windows Server 2008 R2 Image. It is an Amazon Windows Server 2008 R2 CIS Level 2 Benchmark AMI from the Amazon Marketplace.
The issue I am having is when I set the AutoAdminLogin to 1 and do a gpupdate or reboot it reverts back to 0.
I am using Packer to provision my AMI so the steps I am going through are Remove PowerShell 3.0 then reboot. The AutoAdminLogon is set before the reboot but gpupdate runs when the system restarts gpupdate reverts the setting back to 0.
The AutoAdminLogon is needed because the server needs to reboot several times during the provisioning.
Steps are
1. Remove PowerShell 3.0
2. Reboot
3. AutoAdminLogon
4. Install .Net 4.5.2
5. Install Windows Management Framework 5.1
6. Reboot.
At this point, Packer will try to connect using WINRM to finish provisioning the instance to capture as an AMI.
I know it has something to do with the MSS-Legacy settings applied to the AMI. But how do I un-apply them? Or just the AutoAdminLogin set to Disabled?
I have tried using secedit:
secedit /export /cfg c:\temp\secpol.cfg
(gc C:\temp\secpol.cfg).replace('AutoAdminLogon=1,"0"','AutoAdminLogon=1,"1"') | Out-File C:\temp\secpol.cfg
secedit /configure /db c:\windows\security\secedit.sdb /cfg c:\temp\secpol.cfg
Reference: Modify Local Security Policy using Powershell
I have tried the steps listed here: https://docs.bmc.com/docs/tssa89/rollback-of-cis-and-pciv2-templates-after-remediation-does-not-work-808908846.html
Here is also a link to the Script I have modified to do the PowerShell Upgrade:
https://github.com/jborean93/ansible-windows/blob/master/scripts/Upgrade-PowerShell.ps1
Now if I download the MSS-Legacy GPO templates and use the GUI to set the MSS: (AutoAdminLogon) Enable Automatic Logon (not recommended) to Enabled,
It will work and the setting will stick after reboots or gpudpate. But I need a way to do this in a scripted manner because there is no interaction with the Instance during the Bakery process.
I cannot do the steps using a GUI as this is part of our AMI bakery process.
Thanks so much I look forward to seeing peoples thoughts.
I've just come across this "fun"!
I used the PolicyFileEditor PowerShell module and a lot of trial and error, coupled with the information in your question (thanks for that!) to get this working.
My OS is Windows Server 2016, so hopefully it also works for Windows Server 2008 R2 (not that anyone should be using that anymore).
Here's the PowerShell code that I'm using in my Packer build:
Install-Module PolicyFileEditor
Import-Module PolicyFileEditor
# Change the Autologon GPO setting
Set-PolicyFileEntry -Path "$env:windir\system32\GroupPolicy\Machine\registry.pol" -Key "Software\Microsoft\Windows NT\CurrentVersion\Winlogon" -ValueName "AutoAdminLogon" -Data "1"
# Force the policy update to occur
gpupdate /force
# Configure the auto login user and password so that the next restart has autologin
$loginPath = "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon"
Set-ItemProperty -Path $loginPath -Name "DefaultUserName " -Value "<your_admin_user>" -Type String
Set-ItemProperty -Path $loginPath -Name "DefaultPassword" -Value "<your_admin_password>" -Type String
There's also another registry value that you need to specify which is the AutoLogonCount. AutoAdminLogon is directly correlated to the logon count for how many times the system will automatically logon after a reboot.
If your logon count is not set, this may be the reason why it's resetting to 0.
If you want this to be set infinitely, just set it 999999 or something ridiculously high.
You can refer to this MSDN for more information:
MSGina.dll
Note that the Type for AutoLogonCount should be REG_DWORD
Instead of having to restart the computer, you can try the following command:
# Force the policy update to occur w/o restart
echo N | gpupdate.exe /target:Computer /force
I am attempting to install PostgreSQL 9 (postgresql-9.0.3-1-windows.exe) on my WinXP machine and get the following error at the start:
Some googling around yielded some advice that suggested Windows Scripting Host might be disabled. I've checked and WSH is definitely enabled, so it must be something else. Question is, what?
I can see a file called prerun_checks.vbs is created in %TEMP% and when I try to run this manually, I get the following:
Which looks like a permissions error. However, I am an Admin, and I've given myself full control of the temp folder and it's still not working.
Any help appreciated.
In my case the solution was related to NotePad++ being the default application for opening .vbs files. If you have the same situation, here's an elaborate solution:
http://igordcard.blogspot.co.il/2012/03/unable-to-write-inside-temp-environment.html
In a nutshell, in the registry, you need to go to HKEY_CLASSES_ROOT\.vbs, and set the (Default) entry back to the string VBSFile.
This is a an old thread, but I just had the same problem on windows 10:
Unable to write inside TEMP environment path
Solve by the following steps
Check that the problem is related to Windows Script Host.
From cmd run wscript.exe
If you get an error Windows Script Host is not enabled then you can solved it by running the following from cmd
Fix for Current User
REG DELETE "HKCU\SOFTWARE\Microsoft\Windows Script Host\Settings" /v Enabled /f
Fix for Local Machine
REG DELETE "HKLM\SOFTWARE\Microsoft\Windows Script Host\Settings" /v Enabled /f
Now you can install psql
As I was finishing off my question above, our IT chap turned up and knew what the problem was immediately: it's McAfee. It prevents anything from running in a TEMP folder, including Windows Scripting Host scripts. Disabling McAfee for the duration of the installation fixed the problem for me.
So if you see this problem, try disabling your anti-virus.
The answer in the following page helpped me.
http://forums.enterprisedb.com/posts/list/3040.page
run-> regedit and take backup of registry using export
HKEY_LOCAL_MACHINE->SOFTWARE->Classes->CLSID->B54F3741-5B07-11cf-A4B0-00AA004A55E8} -> InprocServer32
Modify registry entry with new value as C:\Windows\System32\vbscript.dll
In fact, I found there are 3 entries of HKEY_LOCAL_MACHINE->SOFTWARE->Classes->CLSID->B54F3741-5B07-11cf-A4B0-00AA004A55E8}, and set the first one as above, it works.
If anyone else is searching for information on this and doesn't have any luck here, you might want to look at:
http://wiki.postgresql.org/wiki/Troubleshooting_Installation
For follow-ups to the mailing list please read:
http://wiki.postgresql.org/wiki/Guide_to_reporting_problems
Well, in my case nothing worked, and disabling McAffee needed a special ticket with my company's security team to actually do... so I installed using the binaries, by following this guide Helpful Guide.
In summary, download the binary from here, unzip it, go inside the pgsql folder, create log and data directories in there, and then open a command prompt, navigate to where the pgsql\bin folder is, and run initdb -U postgres -A password -E utf8 -W -D POSTGRESQL_ROOT\data
You can start and stop the server by running
"POSTGRESQL_ROOT/bin/pg_ctl" -D "POSTGRESQL_ROOT/data" -l "POSTGRESQL_ROOT/log/pgsql.log" start
and
"POSTGRESQL_ROOT/bin/pg_ctl" -D "POSTGRESQL_ROOT/data" -l "POSTGRESQL_ROOT/log/pgsql.log" stop
where POSTGRESQL_ROOT is the full path to the pgsql folder.
All the above did not work for me. I was getting an error like:
Script output:
CScript Error: Windows Script Host access is disabled on this machine. Contact your administrator for details.
so after a couple of googling i found the solution:
Navigate to the following key:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows Script Host\Settings
In the right panel, you will see Enabled. If you see the entry 0, it means that the Windows Script Host access is disabled on your Windows machine.
Double Click on it and give it Value Data 1 to enable it.
A value of 1 will enable Windows Script Host
A value of 0 will disable Windows Script Host.
for windows 10 navigate to
HKEY_CURRENT_USER\Software\Microsoft\Windows Script Host\Settings
To prevent further problems you should also exclude the data directory (where Postgres puts its data) from being scanned by your virus-scanner
In my case it was another application that caused the problem. Not Notepad++. To others who encounter this problem, you can diagnose it by first deleting all files in C:\Documents and Settings\UserName\Local Settings\Temp so that you'll be able to find the bitrock_installer.log easily when you try installing postgresql again and view the instructions in it. Changing the (Default) key in the HKEY_CLASSES_ROOT, .vbs section of the registry to VBSFile solved it.
I had this issue when trying to install the 32 bit version on Windows 7 64 bit.
Trying the install kit for 64 bit presented no errors, but the solutions presented by others are also valid.
In my case I've downloded McAfee removal tool
MCPR (McAfee Consumer Product Removal)
which cleaned up some tailings after McAfee uninstallation.
Some registry entries which previously had InprocServer32 values like 'c:\program files\common files\mcafee\systemcore\...' changed back to its original values:
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{B54F3741-5B07-11cf-A4B0-00AA004A55E8}\InprocServer32\(default) = vbscript.dll
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Wow6432Node\CLSID\{B54F3741-5B07-11cf-A4B0-00AA004A55E8}\InprocServer32\(default) = C:\Windows\SysWow64\vbscript.dll
After that I successfully installed PostgreSQL 9.3
it happens when Notepad++ associates .vbs file types.
you can open notepad++ -> Preferences -> fileAssociation
Remove the .vbs from the registered exts.
Close the notepad++. Try installing Postgres again.
In my case Changing the (Default) key in the HKEY_CLASSES_ROOT, .vbs section of the registry to VBSFile solved it. BlueFish is grab .vbs file association.
In the temp directory, my bitrock_installer.log file had the following:
Executing cscript //NoLogo "C:\Users\MyUser\Local
Settings\postgresql_installer_1b4eec8be6\prerun_checks.vbs"
Script exit code: 1
Script output:
Input Error: Can not find script file "C:\Users\MyUser\Local
Settings\postgresql_installer_1b4eec8be6\prerun_checks.vbs".
Turns out that Windows has a symlink between the following directories:
C:\Users\cpetrie\Local Settings\Temp
C:\Users\cpetrie\AppData\Local\Temp
For some reason my "TMP" and "TEMP" user variables were referencing the "Local Settings" path instead of the "AppData" path. Changing this fixed my install issue.
My problem was Smad-Av which disables Windows Scripts from running,
Only after going through this thread i remembered.
I just right clicked the Smad-Av icon and selected Allow Windows-Script & Office-Macro (Permanent).
I had the same problem with installing PostgreSQL (Unable to write in TEMP environment variable path), the problem was in Windows Script Host which was disabled (check the log file to see if this is your problem). enable it with register editor (run-->regedit) at this location Computer\HKEY_CURRENT_USER\Software\Microsoft\Windows Script Host\Settings by setting its value at 1
For more details check this web link: http://1stopit.blogspot.com/2011/01/postgresql-83-and-84-fails-to-install.html
I had the same problem in Windows 10 and the culprit was the OS's permission, or rather the lack thereof, on allowing the executable to write on the User dedicated Temp folder.
Solved it by following my gut and changing the User Temp folder to the same with the system's : Win + Pause/Break to have the Computer Properties window appear (you can do that manually by right-click on Computer icon on Desktop -> Properties) -> click on Advanced System Settings on the panel on the left -> click on Environment Variables and
under "System variables" - Variables, find the TEMP and TMP ones and copy their paths. Then, under "User variables for Administrator" - Variables, find the TEMP and TMP ones and paste the paths. It's most always "C:\Windows\TEMP" anyways ;)
There's this site I read : https://www.askvg.com/where-does-windows-store-temporary-files-and-how-to-change-temp-folder-location/
search for "Registery Editor" and run it.
choose HKEY_CURRENT_USER => SOFTWARE => Microsoft => Windows script host => Setting (Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows Script Host\Settings)
open "Enabled" and change value data to "1".(you will find it with a vlaue of 0).
Happy coding!
Check the log in the system's TEMP directory (provided the installer is able to write into it).
There's lot of information about the errors.
My issue was that VBS files were associated with a text editor (probably the anti virus software is the culprit) .
Here you can find some reg edit scripts to revert to the default behaviour:
http://www.nilpo.com/2009/07/windows-xp/restoring-vbs-vbscript-script-file-file-associations/#more-107
Cheers
My solution is similiar to #5, with an Explantion of how and why McAfee ruins your vbscript registration.
Apparently, when I had McAfee antivirus software on my computer, it bashed the vbscript.dll registration that Windows Scripting Host needs to run .VBS files.
In the exported .REG file:
[HKEY_CLASSES_ROOT\CLSID{B54F3741-5B07-11cf-A4B0-00AA004A55E8}\InprocServer32]
#="C:\Program Files\Common Files\McAfee\SystemCore\ScriptSn.20120327211246.dll"
That SHOULD be changed back to "C:\Windows\System32\vbscript.dll" now.
McAfee apparently installs a DLL that hijacks the vbscript.dll in order to try to protect bad scripts from running. When I uninstalled McAfee in favor of Microsoft
Security Essentials, McAfee did not restore the registry paths ("not
my problem"), and the McAfee DLL, of course, was removed from the location during uninstall, so the vbscript.dll registration in fact pointed to NOWHERE and NOTHING.
There has to be a better way to write Antivirus software so that it doesn't disable the user's operating system when it is uninstalled, or when features
are turned off, or replace registration. See the following:
https://kc.mcafee.com/corporate/index?page=content&id=KB71660
I have a 64-bit OS. The registry path was changed in a number of locations.
The regular class ID should point to the "C:\Windows\System32\vbscript.dll" 64-bit file.
The "Wow6432Node" registry paths should point to the "C:\Windows\SysWOW64\vbscript.dll" 32-bit file.
Yes, the 64-bits are in the "32" folder and the 32-bits are in the "SysWOW64" folder. Microsoft didn't want to change the name of the main "System32" execution folder when it migrated to 64-bits.
HKEY_CLASSES_ROOT\CLSID{B54F3741-5B07-11cf-A4B0-00AA004A55E8}
C:\Windows\System32\vbscript.dll
HKEY_CLASSES_ROOT\Wow6432Node\CLSID{B54F3741-5B07-11cf-A4B0-00AA004A55E8}
C:\Windows\SysWOW64\vbscript.dll
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID{B54F3741-5B07-11cf-A4B0-00AA004A55E8}
C:\Windows\System32\vbscript.dll
HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Wow6432Node\CLSID{B54F3741-5B07-11cf-A4B0-00AA004A55E8}
C:\Windows\SysWOW64\vbscript.dll
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Classes\CLSID{B54F3741-5B07-11cf-A4B0-00AA004A55E8}
C:\Windows\SysWOW64\vbscript.dll
Before you start messing with the registry, check if WSH is actually disabled or not. To do that run wscript.exe in the DOS box.
If you see a dialog box called "Windows Script Host Settings", WSH is enabled, and your problem with PostgreSQL installation must be related to something else.
If you get an error box that says "Windows Script Host access is disabled on this machine. Contact your administrator for details", WSH is disabled, and your problem with PostgreSQL installation may be related to it (or may be not).
For me, my problem was related to Windows script. I resolved this by right-clicking on smadav icon in the hidden icons in the task bar and checked "Allow Windows-script and Office-Macro (Permanent)". Then double click on the PostgreSQL setup again.
First go to registry Editor then choose HKEY_CURRENT_USER > software > Microsoft > Windows script host > setting > default > add value data to 1 and click Ok. done!
After disabling Smad Av, it still did not work. So, I right clicked on the Smad Av tray icon and I selected 'Allow Windows-Script & Office-Macro (Permanent)' and it worked.
I am writing a windows service which takes an uploaded file, runs signtool.exe on it to do the signing and timestamping and then serves the signed file back.
The code for this works when run as a standalone server using twisted however if I try and run it as a service it fails with the error "Signing succeeded, but an error occurred while attempting to timestamp".
If I replace the signcode subprocess call with a curl.exe call which explicitly uses the proxy then this succeeds.
I have set the proxy in internet explorer and running the command manually works. Is there another way of setting an http proxy for signtool/signcode or another way of doing this (I am keen for it to be a service for ease of integration in to some other monitoring systems)?
I have the same issue but running signtool via cygwin ssh (using a password). The timestamping only works via the proxy and over ssh if I login at least once through the gui (e.g. via rdesktop). I don't even have to be logged in to the gui after that for it to work via ssh, I just have to make sure I login at least once via the gui. Whatever it's doing upon graphical login survives a reboot too. One difference however is that I'm setting the proxy settings dynamically using the same powershell that I'm launching via ssh :
$reg_key = "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings"
Set-ItemProperty -path $reg_key ProxyServer -value 192.168.0.3:8888
Set-ItemProperty -path $reg_key ProxyOverride -value "<local>"
Set-ItemProperty -path $reg_key ProxyEnable -value 1
I tried launching explorer.exe &, notepad &, and iexplorer.exe & from ssh but it didn't help. I'll see about hard coding the proxy settings and also if its possible to have the signing user be logged into the gui after boot. Also will check to make sure ssh is launched with cygrunsrv -i or that it's allowed to interact with the desktop is checked in services.
The system reverts its image if it's halted (vmware delta image) (that's how I'm able to duplicate the problem), but I can always change it, which it looks like I might have to do to figure out this problem.
Finally figured it out with some help from the comment here :
http://blogs.msdn.com/b/askie/archive/2013/05/09/user-proxy-settings-showing-up-in-local-system-account-correct-way-to-apply-proxy-settings.aspx#10606266
Looks like the setting actually has to be set in the binary file :
HKEY_Current_User\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections\DefaultConnectionSettings
This binary file doesn't get created in the registry until after graphical login even with the powershell settings I made above. Easiest way is to login (assuming you have the registry settings I made with powershell above, or set it manually through the internet options ui in the gui), export the HKEY_Current_User\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections path, and the import it with :
regedit /s path_to_proxy_settings.reg
If you want it to apply for all users you need to apply the same file under:
HKEY_LOCAL_MACHINE\\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Connections
as mentioned in the post. There may be other ways as mentioned here https://serverfault.com/questions/34940/how-do-i-configure-proxy-settings-for-local-system , but the above was the easiest for me.