@george1421 Thank you for the quick reply! As a follow up, I managed to update to 1.4.0 RC6 and was then able to deploy an older image without trouble (single disk - resizeable). It completed, and resized successfully. Take care!

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!

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

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

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

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

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

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!

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!

@george1421 Thank you for the quick reply! As a follow up, I managed to update to 1.4.0 RC6 and was then able to deploy an older image without trouble (single disk - resizeable). It completed, and resized successfully. Take care!

Hi All,

Just upgraded from 1.2.0 to 1.3.5 and am seeing the same symptoms as the OP. It looks like we may be waiting to see if this is solved in 1.4 at the moment. Let me know if there is anything I can provide to help troubleshoot this.

Server: Centos 6
Fog: 1.3.5