Deployment and Imaging Group

Hi,

I have a weird problem which i'n mote sure if its a ghost 3.0 problem or a DeepFreeze issue. This didn't happen with Ghost2.5.

Some machines are automatically booting into the ghost automation partition and sit there , but when you exit the automation they correctly boot into windows 7. I cant pin down whats cauing it. it seems to happen daily. Some of the machines are state that cannot communicate with the server but when you quit dagent and run it again they then communicate with the server and reboot to windows.

Does the automation partition boot automatically boot daily looking for jobs find none and boot into windows.. or what is the boot procedure for a ghost 3.0 with automation partition and agent? Any hints would be grateful ans its causing a daily nuisance. i do note that even with deep freeze machines infrozen, this still happens! 

Hello,

I too am having the same issue, so thank god you are posting your expereinces as well. I have been back and forth with Faronics and Symantec on this for a few months now. I will say Symantec and Faronics seem willing to work on the issue, so perhaps with our help and experiences we can get some changes effected. What seems to be happening from how I understand it, is that the server will maintain contact with the agent, and when the agent either receives a change (causing it to reboot into the automation partition) or the PC encounters a boot error, then the PC will boot into the automation partition. I beleive the change that is received is the command to unhide and make active the boot partition. If the change to the MBR is discarded, then the automation partition will boot, then the PC will reboot to the installed OS, and every other time you will see the automation partition.

One difference from what you have experienced is that when the PC's are not frozen, we do not encounter this issue.We of course can not leave them unfrozen.

Anyone from Symantec care to weigh in?

Eric G.

I cannot currently confirm the frozen vs unfrozen bit as i'm not in a position to test it (medical reasons) .. I'm relaying that bit from my colleagues. I'm afraid I'll nto be of much use overthe coming few weeks. Like yourself we cannot afford to leave machines unfrozen as we allow local admin rights to the teaching lab machines as some software for development requires it. I must check if I made deepfreeze go into maintenace mode every night instead of every wednesday would it make a difference.

During an initial deployment of GSS in a 80 station lab we started experiencing this issue.  As a result we removed the Automation Partition post imaging.

Since then I have been able to replicate it using VMs.  The problem stems from a "feature" of pevious versions of GSS/Altiris.  The details of this feature are outlined in this thread and I'm going to expand on them here for completeness and how they relate to Deep Freeze: PC booting into Automation if I power it off after hang or crash

Eric, you're correct in that this issue only occurs when the workstation is frozen.  With the information in the article linked above, here is what I believe is causing the issue.  Would love to hear from a Symantec Official about this and if this may be corrected/changed in future builds.

As mentioned in the linked article, when you install an Automation Partition, the bootloader is replaced with an Altiris/GSS bootloader.  During the boot process the bootloader sets the Automation Partition as the default boot option, but continues to perform a standard Windows boot.  The user uses the OS normally and when they shut down the AClient changes the bootloader to boot Windows as default.

Throwing Deep Freeze into the mix complicates things.  Here is what I think is the chronological process of what causes this problem.  We'll begin with the problem workstation being in a "Frozen" state.

1. Workstation starts, BIOS/EFI posts, performs hand off to GSS Bootloader.
2. GSS Bootloader, as per the feature linked above, sets the Automation Partition as the default and continues to load Windows.
3. Windows loads, user uses the machine normally and initiates a "graceful" shut down.
4. AClient updates the GSS Bootloader to set Windows as the default and continues the shut down.
5. Deep Freeze detects the GSS Bootloader modification and reverts the change (as it should), thus setting the Automation Partition back to the default.  This happens before Deep Freeze is unloaded and the workstation restarted.
6. Workstation restarts, BIOS/EFI posts, performs hand off to GSS Bootloader.
7. GSS Bootloader determines that the Automation Partition is the default and loads into Automation.
8. Automation determines there are no tasks scheduled for this workstation, updates the GSS Bootloader to set Windows to the default, and restarts.  At this point Deep Freeze was never loaded and therefore doesn't undo the GSS Bootloader modification.
9. Workstation starts, BIOS/EFI posts, performs hand off to GSS Bootloader.  We return to Step 2 above and continue to loop indefinitely or until we set the machine to "Thaw".

Depending on your "Frozen"/"Thawed" state and the transition between them will effect the behavior.  So picking up DURING Step 3 above with the same machine, but before the shut down:

4. From the Deep Freeze Console, Faronics Core Console, or Deep Freeze Client inform Deep Freeze to reboot the workstation "Thawed".
5. Deep Freeze initiates a "graceful" shutdown.
6. AClient updates the GSS Bootloader to set Windows as the default and continues the shut down.
7. Deep Freeze, again, detects the GSS Bootloader modification and reverts the change (again as it should), thus setting the Automation Partition back to the default.
8. Workstation starts, BIOS/EFI posts, performs hand off to GSS Bootloader.
9. GSS Bootloader still has the Automation Partition as the default.  Workstation boots to Automation and exits as there are no jobs assigned to the specific workstation.
10. Windows loads fully and you make whatever changes necessary to the machine.
11. You perform a simple restart, not "Freezing" the workstation.
12. AClient updates the GSS Bootloader to set Windows as the deafult and continues the restart.  This time Deep Freeze doesn't undo the change to the GSS Bootloader and Windows restarts normally without entering Automation.

Also spotted this behavior during a Windows Update window which had nothing to do with Deep Freeze.

1. Windows is running normally, Windows Updates are installed, and a reboot is required.
2. Workstation starts, BIOS/EFI posts, performs hand off to GSS Bootloader.
3. GSS Bootloader sets the Automation Partition as the default and continues to load Windows.
4. As a part of the Windows Update installation, Windows only performs a partial boot while "Configuring Updates".  Windows Update requests another restart.  The Client, having never being loaded, fails to restore Windows as the default in the GSS Bootloader.
5. Workstation starts, BIOS/EFI posts, performs hand off to GSS Bootloader.
6. GSS Bootloader determines that the Automation Partition is the default and loads into Automation.
7. Automation determines there are no tasks scheduled for this workstation, updates the GSS Bootloader to set Windows to the default, and restarts.
8. Workstation starts, BIOS/EFI posts, performs hand off to GSS Bootloader.
9. GSS Bootloader sets the Automation Partition as the default and continues to load Windows.
10. Windows starts normally and Windows Update completes normally.

Would love the option to enable/disable this option in the Automation Partion.  Would help eliminate problems like those described above.

Should also note that I modified the local workstation's Deep Freeze configuration to NOT protect the MBR and that failed to make any change in the behavior described above.

Hope this information helps anyone else who has come across this issue.