My clients have installed Adobe Reader X and then enabled the Protected Mode on Startup and then after that caused the Reader to then NOT to open it with the Protected Mode enabled. So we left it disabled for now and all is OK.
Next we conducted some testing and the culprit of this problem was due to the STIG Security Templates settings on my XP box. Somehow Adobe Reader X with Protected Mode enabled “did not like” these restrictive settings.
So then we did a “roll-back” to the defaults and that solved the issue.
In any case, our decision was to reimage the PC and keeping those STIG Security Templates in place.
However, can someone please tell me which of these settings in the template that may have caused an issue using Adobe Reader X with Protected Mode enabled?
Also, I am stuck with the decision of just leaving the Protection Mode DISABLED while keeping the Templates in place, or, to stick with the default OS settings and then leaving the Adobe X Protected Mode enabled???
Please help me on whats the best: Option to keep the STIGs in place, or just do a ROLL-BACK to the defaults and leaving the Protected Mode ENABLED?
Sorry to repeat a lot of what you’ve said, I just want to make sure I understand what happened –
You installed Adobe Reader X on some XP systems and then enabled protected mode (mentioned in the KB article). Then you used BigFix to apply the secedit INF files found in the “Templates - XP” subdirectory of this zip file:
When you did that, Adobe Reader X no longer worked until you turned off protected mode, which is what you’ve done after reimaging the XP machines and applying the DISA secedit INF files again. So now you’re wondering which lines in one of the secedit INF files are conflicting with Adobe Reader X under protected mode.
I just want to find out which STIG template is causing the issue.
If enable to find that out, can I just disable the Protected Mode option and use the security template policies?
My guess is this. Maybe Adobe knows that my operating system is locked-down tight enough with these security policies, and maybe thats why its doing this…Who knows.
But is there a way to find out which line in the INF would be causing this issue?
I haven’t encountered this problem before and don’t know offhand what might be causing the issue.
Two approaches to getting at the root of the problem that seem promising to me are to search Google for strings that appear in that error dialog in connection with Adobe Reader, as well as to do a binary search on the secedit templates. On a VM, try the first half of an INF file and see if the problem arises; if it does, revert the VM and try the first fourth of the file. If the problem arises in the first fourth of the file, revert the VM and try the first eighth of the file, and so on. Hopefully it would become clear early on what part of which of the INF files is causing the problem.