Normal Snapin deploy .reg file

[rmmadden]

Server

• FOG Version: 1.4.0 RC6
• OS: CentOS 6

Client

• Service Version: 0.11.12
• OS: Windows 7 64

Description

I have recently upgraded our FOG server from 1.2.0 to 1.4.0 RC6 (by way of 1.3.5, which needed to be upgraded for a bug that 1.4.0 RC6 solved). I have tested almost everything functionaly except for some of our snapins, which we use to deploy registry updates (for some autologon stuff). Everything seems find on the server end, as well as on the client end, but when the snapins deploy, none of the registry changes are affected. The fog.log on the client shows successful text, with regedit returning a 0 which means success. The same .reg file, run locally, applies fine - it just seems like it isn’t able to run as a snapin through FOG anymore.

In terms of snapin configuration, I have been using the the Run With “regedit.exe” with the argument “/S”
example: “regedit.exe /S autologon.reg”

We don’t use snapins for anything else, so I am not sure if this is an issue with snapins in general, or just these .reg ones.

Has anyone gotten .reg files to deploy successfully on these current builds? If so, how are you doing it? Thanks all!

[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

[rmmadden]

As an update. I have upgraded to 1.4.0 RC8 (just to be working from the current). In testing, I created a powershell script that alters the registry items I needed (same entries as in the .reg), and when I run, I get the same results - snapin runs, returns success, but no changes are applied to the registry.

I then altered the powershell script to create a test file on the client machine. This works! But, as I left the registry stuff in there, that still doesn’t work. So, this proves that the snapin is running, and doing what is it able to do, create a file in my case, but still doesn’t affect the registry. I then added the lines to create a transcript of the script, and that doesn’t return anything about why the registry portion is failing… So, stuck on the evidence that this is just the registry stuff not working, using the .reg and the .ps1 methods…

I am hoping someone else is seeing this too! Thanks for any advice!

[Wayne Workman]

@rmmadden said in Normal Snapin deploy .reg file:

he fog.log on the client shows successful text, with regedit returning a 0 which means success. The same .reg file, run locally, applies fine - it just seems like it isn’t able to run as a snapin through FOG anymore.

Running it locally runs it in the context of the currently logged in user. Snapins run as SYSTEM. This is likely the thing you need to overcome, you’ll need to adapt your code/command so that it can work when ran as SYSTEM.

[rmmadden]

@Wayne-Workman Thanks for the reply! I ended up applying these registry changes through group policy. This is probably the better way to do this, so if anything this exercise put me on the correct path here, and I understand much more about snapins than before!

As a followup question/clarification - does the new client (0.11.12) operate differently in terms of operating user on snapin installs (than the old version did [.10 I think])?

Thank you for the quick advice - we continue to love using FOG in our environment!

[Joe Schmitt]

@rmmadden said in Normal Snapin deploy .reg file:

As a followup question/clarification - does the new client (0.11.12) operate differently in terms of operating user on snapin installs (than the old version did [.10 I think])?

@rmmadden it’s likely the registry keys that were being edited, and their path (e.g. were they under HKEY_CURRENT_USER ?). As for the service executing snapins, it is fairly similar to how the legacy client operated (minus the security changes and optimizations of course).

[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