new-object -comobject "CAPICOM.Signed" failing on Win2k3?

Hi all,

I have written a script which uses CAPICOM and a PFX cert to silently
sign executables. This works very well on my XP dev-box. However,
when I deployed it to our Windows Server 2003 build-box, it doesn't
work.

The new-object call succeeds (well, as near as I can tell). However,
when it gets to "$signedcode.FileName =", PowerShell complains that
there is no FileName member!

Piping the frieshly-created object into get-member yields the
following, different results on each system:

XP:
--------------------------------------------------------------------------------
TypeName: System.__ComObject#{84fbcb95-5600-404c-9187-ac25b4cd6e94}

Name MemberType Definition
---- ---------- ----------
Sign Method void Sign (ISigner2)
Timestamp Method void Timestamp (string)
Verify Method void Verify (bool)
Certificates Property ICertificates2 Certificates () {get}
Description Property string Description () {get} {set}
DescriptionURL Property string DescriptionURL () {get} {set}
FileName Property string FileName () {get} {set}
Signer Property ISigner2 Signer () {get}
TimeStamper Property ISigner2 TimeStamper () {get}
--------------------------------------------------------------------------------

Windows Server 2003:
--------------------------------------------------------------------------------
TypeName: System.__ComObject

Name MemberType Definition
---- ---------- ----------
CreateObjRef Method System.Runtime.Remoting.ObjRef
CreateOb...
Equals Method System.Boolean Equals(Object obj)
GetHashCode Method System.Int32 GetHashCode()
GetLifetimeService Method System.Object
GetLifetimeService()
GetType Method System.Type GetType()
InitializeLifetimeService Method System.Object
InitializeLifetimeService()
ToString Method System.String ToString()
--------------------------------------------------------------------------------

Under Win2k3, the typename is missing the GUID, and none of the
correct members are in the object! CAPICOM 2.1.0.2 is installed on
each system and the DLL is registered.

Can anyone shed any light on why I can't instantiate
CAPICOM.SignedCode on Win2k3?

After tearing my (non-existent) hair out about this, I finally found
the problem.

On the system there were *three* different CAPICOM DLLs:
1) C:\Program Files\Microsoft CAPICOM 2.1.0.2\Lib\X86\capicom.dll
(2.1.0.2)
2) C:\Windows\System32\capicom.dll (1.0.0.2)
3) C:\Program Files\Common Files\Microsoft Shared\CAPICOM\CapiCom.dll
(2.1.0.1)

#3 was registered when what I wanted was #1. The tipoff was the
default value of the key:
HKEY_CLASSES_ROOT\CLSID\{03ACC284-
B757-4B8F-9951-86E600D2CD06}\InprocServer32

which was erroneously pointing toward the Common Files\Microsoft
Shared version.

Once I *unregistered* the other DLLs and re-registered the correct
one, CAPICOM began working from PowerShell with no further problem.

google@xxxxxx wrote: I share your pain. I ran into this the other month when there was a CAPICOM
patch released from Microsoft. In my job I have to test patch deployments and
produce vulnerable and non-vulnerable states of a given security vulnerability
and CAPICOM was being very elusive.

Glad you figured it out!


--

Hal Rottenberg
blog: http://halr9000.com
powershell category:
http://halr9000.com/article/category...ng/powershell/