Hi Ive read through the other posts and MS KB articles related to the setting
of the driver signing policy. I cant determine if there is any way of
setting this
policy as we require.

We have a large number of PCs (with no KB and no monitor) in remote,
often non-networked environments. All installations at the sites must be
unattended (bar insertion of a CD and pressing a proprietry interface
button). These machines have a large range of periphial devices attached.
Some of the devices are proprietary (and have signed drivers), others
are from 3rd parties (and are both signed and unsigned). Historically we
have installed all the SW on these machines from scratch each time we
need to install anything (even a single msi). We have been able to do this
by setting the driver signing policy in either unattend.txt (for standard
installs) or sysprep.inf (for sysprep'd drive images).

We are now in an XP Pro SP2 environment and have a need to (occasionally)
install unsigned drivers after an initial installation has been completed.
This
can occur days or months after the initial deployment. For example, a new
device is plugged into the unit and we need to install the SW / drivers for
just that device.

We were previously able to set the driver signing policy using the regsitry
or rather we used SECEDIT and GPUPATE. As the machines are often not on
a domain (or even networked) setting the domain policy is not an option; we
need to set it locally. The customers who own the units are not prepared to
have driver signing permanently switched off.

If SECEDIT or GPUPDATE are used now (to either set the policy to "ignore"
or to "block", then we get the error logged in setupapi.log (as described in
298503).

"Permachine codesigning policy settings appear to have been tampered with.
Error 13. The Data is invalid"
Default of 1 restored to policy.

This appears to indicate that we cant set the policy to "block" or "ignore"
it will always go to "warn" if you try to programatically set it.

Whilst I understand the reasons for tightening up on this setting we have a
definite need to bypass this standard security for our business. For new
devices and our own devices we now insist on signed drivers. We are still left
(for now) with many legacy devices with unsigned drivers. The only solution I
have just now is to spy for the warning windows and fire keypresses at the
dialogs. Obviously this is less than ideal.

Any help or comments appreciated.

Re: Setting Driver Signing policy programatically by Mark

Mark
Thu Jun 02 06:24:00 CDT 2005

Gordy wrote:
> Hi Ive read through the other posts and MS KB articles related to the setting
> of the driver signing policy. I cant determine if there is any way of
> setting this
> policy as we require.
>
> We have a large number of PCs (with no KB and no monitor) in remote,
> often non-networked environments. All installations at the sites must be
> unattended (bar insertion of a CD and pressing a proprietry interface
> button). These machines have a large range of periphial devices attached.
> Some of the devices are proprietary (and have signed drivers), others
> are from 3rd parties (and are both signed and unsigned). Historically we
> have installed all the SW on these machines from scratch each time we
> need to install anything (even a single msi). We have been able to do this
> by setting the driver signing policy in either unattend.txt (for standard
> installs) or sysprep.inf (for sysprep'd drive images).
>
> We are now in an XP Pro SP2 environment and have a need to (occasionally)
> install unsigned drivers after an initial installation has been completed.
> This
> can occur days or months after the initial deployment. For example, a new
> device is plugged into the unit and we need to install the SW / drivers for
> just that device.
>
> We were previously able to set the driver signing policy using the regsitry
> or rather we used SECEDIT and GPUPATE. As the machines are often not on
> a domain (or even networked) setting the domain policy is not an option; we
> need to set it locally. The customers who own the units are not prepared to
> have driver signing permanently switched off.
>
> If SECEDIT or GPUPDATE are used now (to either set the policy to "ignore"
> or to "block", then we get the error logged in setupapi.log (as described in
> 298503).
>
> "Permachine codesigning policy settings appear to have been tampered with.
> Error 13. The Data is invalid"
> Default of 1 restored to policy.
>
> This appears to indicate that we cant set the policy to "block" or "ignore"
> it will always go to "warn" if you try to programatically set it.
>
> Whilst I understand the reasons for tightening up on this setting we have a
> definite need to bypass this standard security for our business. For new
> devices and our own devices we now insist on signed drivers. We are still left
> (for now) with many legacy devices with unsigned drivers. The only solution I
> have just now is to spy for the warning windows and fire keypresses at the
> dialogs. Obviously this is less than ideal.
>
> Any help or comments appreciated.
>
>
>
I could be wrong but I think that driver signing policy can be preset on
install if you build your own install package.

--

=====================
Mark Roddy DDK MVP
Windows 2003/XP/2000 Consulting
Hollis Technology Solutions 603-321-1032
www.hollistech.com

RE: Setting Driver Signing policy programatically by bburgin

bburgin
Thu Jun 02 18:40:28 CDT 2005

------=_NextPart_0001_D9D82562
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

Sorry, but this is working as designed.

Bryan S. Burgin
bburgin@online.microsoft.com

This posting is provided "AS IS" with no warranties, and confers no rights.
------=_NextPart_0001_D9D82562
Content-Type: text/x-rtf
Content-Transfer-Encoding: 7bit

{\rtf1\ansi\ansicpg1252\deff0\deflang1033{\fonttbl{\f0\fnil\fprq2\fcharset0 MS Sans Serif;}}
\viewkind4\uc1\pard\f0\fs20 Sorry, but this is working as designed.
\par
\par Bryan S. Burgin
\par bburgin@online.microsoft.com
\par
\par This posting is provided "AS IS" with no warranties, and confers no rights.
\par
\par }
------=_NextPart_0001_D9D82562--