Normal Snapin deploy .reg file



  • 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!



  • 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



  • 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.


  • Senior Developer

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



  • 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 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!


  • Senior Developer

    @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.



  • @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.



  • @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).


  • Moderator

    @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)



  • @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!


  • Moderator

    @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.



  • @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.


  • Senior Developer

    @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).



  • @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!


  • Moderator

    @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.



  • 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!


Log in to reply
 

361
Online

39.3k
Users

11.0k
Topics

104.4k
Posts

Looks like your connection to FOG Project was lost, please wait while we try to reconnect.