Normal Snapin deploy .reg file

[rmmadden]

@Joe-Schmitt Thanks for touching base! These registry edits were actually all in HKLM, so local computer policy for all users. Coincidentally, I did confirm that the permissions on that exact registry path in regedit did grant SYSTEM full control, so I can’t fully understand why those changes aren’t being applied, even with my new understanding.

[Quazz]

@rmmadden Try

REG IMPORT yourfile.reg

regedit is a bad tool for commandline, imo. REG is the way to go for command line registry stuff.

Regedit on commandline won’t notify of any possible errors, whereas REG might.

[rmmadden]

@Quazz Hi there! I actually did run through several different ways to import the .reg file yesterday (including reg import, as well as the full path the actual .exe file for regedit), all report success with a 0, but never actually make any registry changes. I have since moved on to applying these registry updates through group policy, which may be a better way to do this anyway. Thanks for the suggestion!

[Quazz]

@rmmadden If you run the command manually, does that work?

EDIT: Just realized, the problem might be the path of the registry file not being specified. (I doubt cd will work for this, by the way)

[rmmadden]

@Quazz Yes - it applies the updates successfully when I run as a local user (member of the Administrators group) manually through a cmd prompt (or when I execute the changes by just double clicking on the .reg file).

[rmmadden]

@Quazz Yeah - I thought that too, and in testing, created a powershell script to apply the same registry edits, as well as to do some other things, such as create a file on the root of the C:/ drive. The snapin does run, since I can then see the files being created, but the registry remains unchanged. The fog log reports success on this too, and even when I try to capture a transcript of the PS script - it doesn’t report any errors (the transcript does report it starting and stopping though, so I know that is working properly). In both the .reg and .ps1 examples, it isn’t specifying the full path to the /tmp file that the snapin uses (in terms of the snapin settings on the FOG server backend), but I am guessing it has to be doing this somewhere on execution.

[Joe Schmitt]

@rmmadden said in Normal Snapin deploy .reg file:

I am guessing it has to be doing this somewhere on execution.

Correct. Would you mind posting the .reg file? I know you switched to GPO, but I’m curios as to why its not applying when running as SYSTEM.

[rmmadden]

@Joe-Schmitt 0_1493138004730_STUDENT-AUTOLOGON.reg Sure thing! I have changed some of the details in there, but this contains all of the keys I was using. Let me know if this helps!

I will be interested to hear if you have the same trouble!

[tomtom]

I have exactly the same problem.
I always did registry-update-snapins successfully with snapin-packs in this way:

file fix.bat (example)

pushd %~dp0
REG IMPORT AutoAdminLogonDisable.reg

file AutoAdminLogonDisable.reg (example)

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon]
"AutoAdminLogon"="0"

The snapins are successfully sent to the client and run. But the registry doesn’t change…

Version of Fog Server: 1.4.0-RC-9.2
Version of Fog Client: 0.11.12

[Joe Schmitt]

@tomtom what os is the client on? When did reg edit snapin a stop working?

[tomtom]

The OS is Win 10 with Creators Update.
I had successfully deployed registry-snapins on Win-10-Creators-Update.

I’m not sure, but I think the only change was the Version of FOG Server / Client.
I think the last time I did a registry-snapin was with or before 1.4.0-RC-5.

[AndrewG78]

I had the same issue and after some amount of trials I found the solution.
You have to use external PsExec program from Sysinternals.
You have to create snapin pack and include 2 files- a batch file and psexec.exe one.
PsExec.exe -i -s -u %COMPUTERNAME%\<username> -p <user_password> -nobanner -accepteula REG DELETE “HKLM\SOFTWARE…” /v <some_key> /f
PsExec.exe -i -s -u %COMPUTERNAME%\<username> -p <user_password> -nobanner -accepteula REG ADD “HKLM\SOFTWARE…” /v <some_key> /d <some_value> /f

[fogjam]

@Joe-Schmitt, I encountered the same issue after recently upgrading from FOG Server 0.32 and the old FOG Client to 1.4.4 and 0.11.12, respectively. Deploying the same snapin that previously modified the AutoAdminLogon key on Windows 7 64, no longer seemed to affect the registry (still deploying to the same OS).

After some testing, I found that Windows File System redirection was the culprit. FOGService runs the snapin with the 32-bit executable (cmd.exe, cscript.exe, reg.exe, etc.) because Windows redirects %windir%\system32 to %windir%\SysWOW64. This caused my registry update to modify

• HKLM\Software\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Winlogon

instead of

• HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon

Don’t know why my old FOG ecosystem was unaffected, but here are some workarounds I’m exploring on the snapin side (links document the ideas—YMMV):

1. Prefix the command with %windir%\sysnative (only works on Windows 64 bit in a 32-bit shell), which can be done in directly in Snapin Run With or coded into the script
   File System Redirector mentions using %windir%\sysnative

2. Create a symbolic link to call a 64-bit version of the executable
   Open 64bit command prompt in 32 bit command prompt

3. Force REG.exe to write to 64-bit registry location with /reg:64
   https://ss64.com/nt/reg.html

4. Example VB Script that sets Autologin - untested