Can COM information be advertised?
Vadim Rapp
If I create an MSI package with advertised file extensions, and assign it to
the user in group policy, then install-on-demand will install the package as
soon as the user tries to open a file with advertised extention.
But if MSI package has adversised COM information, and the user tries to
create such object in Windows XP, for example from vbscript, then
install-on-demand does not work.
Is it by design?
thanks,
Vadim Rapp
Sebastian Brand
Generally this should be possible, although Rob Mensching points out
very detailed why this is a bad idea:
Best regards,
Sebastian Brand
Instyler Software - http://www.instyler.com
Vadim Rapp
misunderstood. The point is not to avoid creating advertised information,
but rather not to do it in the public applications distributed on CD's,
downloaded., etc, when the installation source may easily be unavailable.
But in the network environment with managed installations advertised in
group policy, there's nothing bad in advertising.
One particular scenario, actually the one that I have, is when version 1 of
the package with COM object is already installed, and I have version 2. I
might publish version 2 with upgrade information, expecting that the next
time any application tries to create an object from the package, it would be
automatically upgraded. Until such request, it would be only advertised. Or
even without upgrading, there's nothing wrong in advertising avaiable COM
object on the network, so whenever an application requests it, it would be
installed - it's much better than installing the whole package (and with all
features, as opposed to just the feature hosting the object) for all users
just in case, when many of them will never need it.
Regardless of it being good or bad idea, I don't see it working to begin
with. I create a trivial project with COM object. Advertising information is
populated. The package is assigned to the user and appears in his add/remove
programs. However, in the registry there's no trace of the prog id of the
class, and when the user runs createobject, there's no install-on-demand,
and createobject fails.
Vadim Rapp
"Sebastian Brand" <inst...@gmail.com> wrote in message
news:4d8c3d24-eff7-4dec...@m36g2000hse.googlegroups.com...
Adrian Accinelli
news:uc3Kmv%23mIH...@TK2MSFTNGP06.phx.gbl...
> I'm familiar with that article and that logic, but I think it's somewhat
> misunderstood. The point is not to avoid creating advertised information,
> but rather not to do it in the public applications distributed on CD's,
> downloaded., etc, when the installation source may easily be unavailable.
> But in the network environment with managed installations advertised in
> group policy, there's nothing bad in advertising.
> One particular scenario, actually the one that I have, is when version 1
> of the package with COM object is already installed, and I have version
> 2. I might publish version 2 with upgrade information, expecting that
> the next time any application tries to create an object from the
> package, it would be automatically upgraded. Until such request, it
> would be only advertised. Or even without upgrading, there's nothing
> wrong in advertising avaiable COM object on the network, so whenever an
> application requests it, it would be installed - it's much better than
> installing the whole package (and with all features, as opposed to just
> the feature hosting the object) for all users just in case, when many
> of them will never need it.
> Regardless of it being good or bad idea, I don't see it working to begin
> with. I create a trivial project with COM object. Advertising
> information is populated. The package is assigned to the user and
> appears in his add/remove programs. However, in the registry there's no
> trace of the prog id of the class, and when the user runs createobject,
> there's no install-on-demand, and createobject fails.
> Vadim Rapp
This is not typical behaviour. I think your problem has to do with mapping
ProgId table entries to proper Class table entries.
Remember a ProgId is not directly related to a component. Look at the
ProgID table - there's no component field in there. Instead advertisement
of ProgIds relies entirely on the association between it an a Class table
entry or an Extension (or in case of version independent ProgId another
ProgId entry in the table itself. This means it is critical to have
correct relationship there or else advertisement will not succeed.
To find the problem closely check the ProgId you think should be registered
when the product is advertised against Class table to make sure you have a
good mapping. On top of that make sure that the matching Class table CLSID
is associated to a feature whose attribute does not include
msidbFeatureAttributesDisallowAdvertise (bit 8).
Also I recommend turnning on policy for logging and see what actually is
happening in your advertisement. Perhaps the features you thought would be
advertised are not actually installed -- this depends on feature table
values like Level and Attributes. This is why transforms for Group Policy
are important they can control default set of features you want advertised.
Last you don't need to through goup policy to test this - just use msisexec
/ju.
Sincerely,
Adrian Accinelli
Vadim Rapp
> msisexec /ju.
In that case, all works. And the log file is much longer than the one
produced when the package is assigned, that I attached in the previous post.
It looks like when the package is assigned in the GPO, Installer is called
do do something other than /ju.
Adrian Accinelli
> Checked everything. All correct. I even recreated the same package in
> Wise and in Installshield, same result.
> Log file created during assignment is attached. I have also attached the
> sample installation - if you assign it under User Configuration without
> "install this application on logon", log on, and then run vbscript
> createobject("testobject.testclass")
> hopefully, you will see the same as I do - "activex component can't
> create object", and no install-on-demand.
> regards,
> Vadim Rapp
> "Adrian Accinelli" <hclnosp...@newsgroup.nospam> wrote in message
> news:OorgJHAn...@TK2MSFTNGP04.phx.gbl...
From your log I can see that you are Publishing your product rather than
assigning which is what I think you want to achieve. Publishing just
registers the product as managed placing some key registry values but does
not act upon the MSI file at all in the way that assignment does. Assigning
is a superset of Publishing (i.e. does everything the other does plus more).
Essentially in the first case you describe you should have your "test"
product appear in add/remove programs and that's pretty much it. If you had
added a row to the Extension and Verb tables and associated them with
ProgId: testobject.testclass, component: testobject.dll, and feature:
Compete then you'd see your CLSID registered as you expected but only under
the guise of an extension. In an actual MSI assignment you'll see
ACTION=ADVERTISE in the log and many more actions that are included in the
AdvtExecuteSequence table. That's what you are seeing with msiexec /ju.
In your GP Software Install console select "Assign Users" rather than
"Publish to users". I don't recall if you get that choice by default or
have to click advanced(?) button to get there.
Some useful background info can be found here:
http://technet2.microsoft.com/windowsserver/en/library/a4a077c7-d976-48b1-a3ba-d88d21ebffad1033.mspx?mfr=true
Sincerely,
Adrian Accinelli
Vadim Rapp
I am familiar with the differences between "published" and "assigned", and
I'm 100% certain that I did assign it. As I said, after logon, "test" does
appears in add/remove programs, rather than only in "add new programs",
which means that not only it was put in the policy, but has been actually
assigned to the user. And still, the progid does not appear anywhere in the
registry.
Could you try it yourself by taking the attached file from the previous post
and assigning?
Thanks,
Vadim Rapp
"Adrian Accinelli" <hclnosp...@newsgroup.nospam> wrote in message
news:<#wO74eln...@TK2MSFTNGP02.phx.gbl>...
Vadim Rapp
include actions RegClassInfoRegister, RegisterProgIdInfo, and
RegProgIdInfoRegister.
Vadim Rapp
"Adrian Accinelli" <hclnosp...@newsgroup.nospam> wrote in message
news:%23wO74el...@TK2MSFTNGP02.phx.gbl...
Adrian Accinelli
> Adrian,
> I am familiar with the differences between "published" and "assigned",
> and I'm 100% certain that I did assign it. As I said, after logon,
> "test" does appears in add/remove programs, rather than only in "add
> new programs", which means that not only it was put in the policy, but
> has been actually assigned to the user. And still, the progid does not
> appear anywhere in the registry.
> Could you try it yourself by taking the attached file from the previous
> post and assigning?
> Thanks,
> Vadim Rapp
Actually I had a major brain fault here - the published case does not
actually generate MsiAdvertiseScript based logs so it should have been
obvious that it was not publishing (slap forehead! :). Anyways I have the
solution for you and dug pretty deep to get full understanding of what was
going on so if I go off on a tangent to get there please bear with me.
First I started using my GP "cheat" technique -- that is I use the
combination of MsiProductAdvertiseEx (to generate an actual AAS script file)
and a custom app that I launch as a service which calls MsiAdvertiseScript
to install the script itself. Unfortunately using the test MSI package you
provided actually worked as you'd expect (I'll get to why in a bit).
This success forced me to actually do what you suggested -- assigning in an
Active Directory using GPO editor. I dug up two vmware images -- one 2003
based Active Directory and the other Windows XP SP2. I created new policy
and then did the typical "choose all defaults" method to assign the test MSI
package. Result was it didn't work -- just as you said.
That was good because it forced me to dig deeper into an area I typically
ignore -- the GPO editor itself and the resulting Advertisation Flags used.
You see when you use MsiAdvertiseScript itself (as I mentioned I used in my
cheat method above) you can specify the exact flags you want (as per
http://msdn2.microsoft.com/en-us/library/aa370058(VS.85).aspx). Now in my
tests I typically use the flags:
SCRIPTFLAGS_REGDATA_APPINFO | SCRIPTFLAGS_REGDATA_CNFGINFO |
SCRIPTFLAGS_SHORTCUTS | SCRIPTFLAGS_CACHEINFO
which works out to 0x1A5 or 421. Now using these flags will cause the test
package to properly register the CLSID/ProgID and a subsequent CreateObject
by the current user on the ProgId triggers the install. So clearly the
defaults in GPO do not use these flags.
I didn't pull these out of nowhere -- they are recommened here
http://msdn2.microsoft.com/en-us/library/aa367550.aspx.
With that in mind I looked at what GPO does in the "default" assignment
scenario. Turns out it uses 0x104 -- that's SCRIPTFLAGS_SHORTCUTS |
SCRIPTFLAGS_REGDATA_EXTENSIONINFO. This is why your package behaves the way
it does because it contains neither shortcuts, nor extensions.
So to get it to work I made one change to the GP software install package.
In the "Deployment Options" group of the Deployment property sheet make sure
"Install this application at logon" is checked. This results in
AdvertiseFlags equivalent to 0x184 or 388. That's basically provides
shortcuts, extensions and class information. After login applies the group
policy changes the progid/clsid are registered and CreateObject by current
user on ProgId triggers the install.
What's bizarre (I'm sure some GP expert out there has the background on
this) is that there's an advanced option labelled "Include OLE class and
product information". If you select this during original creation of
package then you'd think you would get SCRIPTFLAGS_REGDATA_CLASSINFO added
to AdvertiseFlags. That does not seem to be the case-- in fact I saw no
difference in my test deployments (same old 0x104 flags were used).
One thing this excercise told me is that the logs provided by
MsiAdvertiseScript (both from winlogon process in GP case and in when my
using my cheat tool) do not really tell you what is happening at all. The
truth is that if you are running into deployment problems you should look at
the AdvertisedFlags dword value immediately after the login that triggers
the software install action. Find it in
HKCU\Software\Microsoft\Installer\Products\ProductCode. At least this way
you can see what really took place. If it does not include 0x80 then you
know your non-extension Clsid/ProgId will not be installed.
Sincerely,
Adrian Accinelli
Vadim Rapp
GPMC, isn't it. I'm surprised that this hasn't been discovered earlier - am
I the only one who is expecting advertised COM to work?
Regarding using "install this application at logon" - yes, sure it will
work, but that will actually install the whole package, so why advertising
anything...
I did notice that advanced "include ole and class information" does not have
any effect on anything, and already made several attempts to let Microsoft
know about it - so far, to no avail.
It looks, then, that the only way to have COM really advertised is to run
the installation with /ju - which means that this can't be done by group
policy deployment, since it does not allow command-line switches, right?
regards,
Vadim Rapp
"Adrian Accinelli" <hclnosp...@newsgroup.nospam> wrote in message
news:%23pQTfM3...@TK2MSFTNGP05.phx.gbl...
Adrian Accinelli
> Thanks for your thorough research Adrian. So it all looks like a bug in
> GPMC, isn't it. I'm surprised that this hasn't been discovered earlier -
> am I the only one who is expecting advertised COM to work?
> Regarding using "install this application at logon" - yes, sure it will
> work, but that will actually install the whole package, so why
> advertising anything...
> I did notice that advanced "include ole and class information" does not
> have any effect on anything, and already made several attempts to let
> Microsoft know about it - so far, to no avail.
Since I don't use AD on day to day basis I'm probably not the best to
dictate to others how it should work. That said it seems reasonable to me
that the real purpose of "Include ole and class information" option should
be to allow full CLSID/ProgID registration through advertisement and so I
would judge that appmgmt's handling of that flag is wrong. Regardless of
what I think about how the flag works there should be *some* way to get this
behaviour just by using GPMC.
It's also clear to me that doing this manually works - the service/app
combination I run to "cheat" works perfectly.
> It looks, then, that the only way to have COM really advertised is to run
> the installation with /ju - which means that this can't be done by group
> policy deployment, since it does not allow command-line switches, right?
I can't think of a workaround for this really. Without GP deployment the
only way to get the a "proper working" per-user managed is to use a custom
service which impersonates the logged on user and advertises the product for
that user (which is what I do in my "cheat" method). Likely some of the big
names in enterprise deployment have something that can do this but I don't
have information on that.
Also I have to revise these results I provided:
>>With that in mind I looked at what GPO does in the "default" assignment
>>scenario. Turns out it uses 0x104 -- that's SCRIPTFLAGS_SHORTCUTS |
>>SCRIPTFLAGS_REGDATA_EXTENSIONINFO. This is why your package behaves the
>>way it does because it contains neither shortcuts, nor extensions.
I came across http://support.microsoft.com/kb/249621 which tells you how to
get ensure that a verbose appmgmt.log file is created and by looking at the
log generated on my machine it clearly shows MsiAdvertiseScript called with
option 165 (that included the "include ole and class information" option
being enabled). This is in hexidecimal and SCRIPTFLAGS_REGDATA_CLASSINFO is
not part of it. After the install the registry writes out 0x104 in this
case and I jumped to the wrong conclusion when I initially saw the flags
there. If you use the install on long option it show an advertisment with
flags 0x61 but it gets followed up with an install and this results in the
registry AdvertiseFlags changing to 0x184.
Sincerely,
Adrian Accinelli