D
Duncan
Hi,
I'm trying to configure AxIS to allow an ActiveX control to install under
IE7 on Vista SP1 on a regular locked account. The problem is it's failing
and I'm looking for confirmation as to why.
**The setup**
- The site is Internet based and HTTPS.
- The ActiveX control CAB file install package is signed with a valid
trusted publishers certificate.
- The actual .dll/.ocx file contained within the signed CAB is NOT signed.
- I set a value of 1,1,1,0 for TPSSignedControl, SignedControl,
UnsignedControl, and ServerCertificatePolicy respectively under the AxIS
policy.
**Reference material**
http://technet2.microsoft.com/windo...700f3fa8-452c-4826-bdea-e76e79bee1671033.mspx
and
http://msdn.microsoft.com/en-us/library/bb250471.aspx
**The problem**
No luck, the ActiveX control fails to install and I get an EventID 4099 in
the app event log which according to the TechNet article above means the
ActiveX control does not meet the required signing setting that has been set
via Group Policy.
**My theory**
This is not failing because I'm getting the combinations of values wrong
above (I've tried all possible combos + included all HTTPS error exceptions
values too. And I know AxIS works as I can get the likes of Flash and MS
genuine authentication to work fine), but because the install CAB is signed
but the actual control contained within is not signed. My guess is AxIS will
not/cannot handle such scenarios? i.e. I could argue the ActiveX control
package in the first place is not kosher? Indeed the MSDN article tends to
suggest this:
"If your control is installed by a CAB file or another executable, you must
be sure to sign both the installation file (to enable installation) and the
..dll or ocx file containing the ActiveX control (to ensure your publisher
name shows up without the "Not verified" notice)."
Has anybody else had this problem or can confirm this is by design?
Thanks in advance.
Duncan
I'm trying to configure AxIS to allow an ActiveX control to install under
IE7 on Vista SP1 on a regular locked account. The problem is it's failing
and I'm looking for confirmation as to why.
**The setup**
- The site is Internet based and HTTPS.
- The ActiveX control CAB file install package is signed with a valid
trusted publishers certificate.
- The actual .dll/.ocx file contained within the signed CAB is NOT signed.
- I set a value of 1,1,1,0 for TPSSignedControl, SignedControl,
UnsignedControl, and ServerCertificatePolicy respectively under the AxIS
policy.
**Reference material**
http://technet2.microsoft.com/windo...700f3fa8-452c-4826-bdea-e76e79bee1671033.mspx
and
http://msdn.microsoft.com/en-us/library/bb250471.aspx
**The problem**
No luck, the ActiveX control fails to install and I get an EventID 4099 in
the app event log which according to the TechNet article above means the
ActiveX control does not meet the required signing setting that has been set
via Group Policy.
**My theory**
This is not failing because I'm getting the combinations of values wrong
above (I've tried all possible combos + included all HTTPS error exceptions
values too. And I know AxIS works as I can get the likes of Flash and MS
genuine authentication to work fine), but because the install CAB is signed
but the actual control contained within is not signed. My guess is AxIS will
not/cannot handle such scenarios? i.e. I could argue the ActiveX control
package in the first place is not kosher? Indeed the MSDN article tends to
suggest this:
"If your control is installed by a CAB file or another executable, you must
be sure to sign both the installation file (to enable installation) and the
..dll or ocx file containing the ActiveX control (to ensure your publisher
name shows up without the "Not verified" notice)."
Has anybody else had this problem or can confirm this is by design?
Thanks in advance.
Duncan