Non-Administrator Patch restrictions

In order to ask my questions, I need to present our scenario:

Clients receive our product through either a major upgrade interactive
install or a Group Policy Push install. Our product has a mix of COM and .Net
2.0 components. We now have converted enough of our application to .Net to be
able to patch by just replacing some .Net assemblies (upgrades involving the
old COM components would require a full upgrade). We want our application to
update itself when a patch is available: the user logs into our app and our
app checks a file somewhere on the domain for whether it’s up-to-date and if
not, kicks off the patch upgrade, shuts down the app, runs the upgrade and
re-starts the app. We don’t want our client IT departments to have to push
out patches through group policy; we only want to require that for major
upgrades. Also, users are not administrators on their own machines. The
predominant operating system is Windows XP, although there are some sites
that still use Windows 2000 Pro and there will probably be some using Vista
when our release goes out, which is soon. All the client’s workstations have
Windows Installer 3.1 or higher on them. The type of patch upgrade would be a
“small upgrade”. That is, the Product Code will remain the same and the first
three numbers of the product’s version will remain the same; we’ll increment
the fourth number to help identify the patch. Our major upgrade install is
set not to enable repairs. It can only be installed or removed.

The problem is there are significant restrictions to being able to apply
patches to machine-based installs for users who are not administrators if we
assume that our clients will not want to set group policy to allow all users
to run installs with Elevated privileges. There is also GP setting for just
allowing patches to run as elevated, but that too is a security risk.

I understand that Windows Installer 3.0 and higher supports the patch
upgrade scenario I’m talking about, but a couple of the restrictions I’m
reading about I need clarification on because they look like they will spoil
the plan. The restrictions are as follows:

1) The platform must be Microsoft Windows XP or later.

2) The application was installed from a removable media such as CD-ROM or DVD.

For the first restriction: some of our clients have Windows 2000 Pro. Does
that mean you can’t use this method even though those machines are running
Windows Installer 3.1? (I just want to be absolutely sure.)

The second restriction I don’t understand. How could it be a requirement
that the install must run off a CD or DVD and not, for instance, from a
network share? I don’t see how that can make the install more secure. Anyway,
that’s an impossible requirement for organizations like the ones using our
product; they must be able to run the upgrade from a network share.

If I’m reading these restrictions correctly, it looks like the only options
are as follows, assuming we don’t switch to a per-user install and don’t want
to require a GP push for every patch: We have are either to ask the IT
departments who use our product to relax the GP settings on elevated
privileges (for installs or patches) or just find a way to copy the .Net
assemblies without using the Windows Installer (because that’s literally all
we need to do to patch). Are there any other options?

If we do have to resort to copying .Net assemblies in some way inside our
own product, will that have any negative impact on future Major Upgrades?
(Our intention would be to keep the first 3 version numbers the same and
increment the fourth, matching the numbering on the product’s version
numbering).

Thanks,
John

Hi Adrian,

Thanks for your reply; very interesting and much appreciated! That sounds
like it should do the trick. There are two issues that now stem from this
possible solution, though.

1) The Microsoft documentation (a link to which you included in your
response) is not clear on how this scenario is supposed to be implemented.
That is, you want to place the signed patch on a network share where all
users' systems can access it. But under what authority is the patch file
signed so that the Windows Installer on each workstation recognizes that the
authority that signed the patch file is authorized to run the patch as
elevated on each workstation? Is the security in the fact that the patch file
is impregnated as having been signed to run elevated and on a specific share?
That doesn't seem secure enough as a local administrator on any given
machine. I would have thought that the user who signed it would be a domain
administrator who is in the administrators group on every workstation in the
domain that's going to be applying the patch. I need this information to
understand what we need to do to prepare the patch file for each client's
site.

2) I can't find any documentation on the Patch property (or method) of the
patch object. The sample code shows the following 2 lines of code:

Set installer = CreateObject("WindowsInstaller.Installer")

Set patch = installer.Patch(PatchCode, "", UserSid,
msiInstallContextUserManaged)

So there is an Installer object that supposedly has a Patch method (or
property), but I can't find documentation of this in on-line Windows MSDN,
under the Windows Installer Automation Reference. The documentation on the
Patch object says where the Patch object comes from in the second paragraph
and it says that “Patch” is a property, so I should be able to find more
about this property in the documentation, presumably under the properties for
the Installer object.

Thanks,
John


"Adrian Accinelli" wrote:

> "John_s" <Johns@discussions.microsoft.com> wrote in message
> news:36B63C5A-A5FA-4785-BF48-51A240A97552@microsoft.com...
> > In order to ask my questions, I need to present our scenario:
> > Clients receive our product through either a major upgrade interactive
> > install or a Group Policy Push install. Our product has a mix of COM and
> > .Net 2.0 components. We now have converted enough of our application to
> > .Net to be able to patch by just replacing some .Net assemblies
> > (upgrades involving the old COM components would require a full
> > upgrade). We want our application to update itself when a patch is
> > available: the user logs into our app and our app checks a file
> > somewhere on the domain for whether it's up-to-date and if not, kicks
> > off the patch upgrade, shuts down the app, runs the upgrade and
> > re-starts the app. We don't want our client IT departments to have to
> > push out patches through group policy; we only want to require that for
> > major upgrades. Also, users are not administrators on their own
> > machines. The predominant operating system is Windows XP, although
> > there are some sites that still use Windows 2000 Pro and there will
> > probably be some using Vista when our release goes out, which is soon.
> > All the client's workstations have Windows Installer 3.1 or higher on
> > them. The type of patch upgrade would be a "small upgrade". That is,
> > the Product Code will remain the same and the first three numbers of
> > the product's version will remain the same; we'll increment the fourth
> > number to help identify the patch. Our major upgrade install is set not
> > to enable repairs. It can only be installed or removed.
> > The problem is there are significant restrictions to being able to apply
> > patches to machine-based installs for users who are not administrators
> > if we assume that our clients will not want to set group policy to
> > allow all users to run installs with Elevated privileges. There is also
> > GP setting for just allowing patches to run as elevated, but that too
> > is a security risk.
> > I understand that Windows Installer 3.0 and higher supports the patch
> > upgrade scenario I'm talking about, but a couple of the restrictions I'm
> > reading about I need clarification on because they look like they will
> > spoil the plan. The restrictions are as follows:
> > 1) The platform must be Microsoft Windows XP or later.
> > 2) The application was installed from a removable media such as CD-ROM
> > or DVD.
> > For the first restriction: some of our clients have Windows 2000 Pro.
> > Does that mean you can't use this method even though those machines are
> > running Windows Installer 3.1? (I just want to be absolutely sure.)
> > The second restriction I don't understand. How could it be a requirement
> > that the install must run off a CD or DVD and not, for instance, from a
> > network share? I don't see how that can make the install more secure.
> > Anyway, that's an impossible requirement for organizations like the
> > ones using our product; they must be able to run the upgrade from a
> > network share.
> > If I'm reading these restrictions correctly, it looks like the only
> > options are as follows, assuming we don't switch to a per-user install
> > and don't want to require a GP push for every patch: We have are either
> > to ask the IT departments who use our product to relax the GP settings
> > on elevated privileges (for installs or patches) or just find a way to
> > copy the .Net assemblies without using the Windows Installer (because
> > that's literally all we need to do to patch). Are there any other
> > options?
> > If we do have to resort to copying .Net assemblies in some way inside our
> > own product, will that have any negative impact on future Major Upgrades?
> > (Our intention would be to keep the first 3 version numbers the same and
> > increment the fourth, matching the numbering on the product's version
> > numbering).
> > Thanks,
> > John
>
>
> Hi John,
>
> If you can ensure that you can run code in an elevated context then you can
> register your patches as "elevated". Once registered you can apply the
> patch as a normal user. The information on this is located here:
> http://msdn.microsoft.com/en-us/libr...82(VS.85).aspx
>
> There's a small line of note: "You can also use this method to enable a
> non-administrator to patch a per-machine application".
>
> This should work on 2000, XP or the other client platforms anyways. I don't
> think it will work on server plaforms (well if it does I think you'd have to
> be on the console anyways).
>
> What you are describing above is the User Account Control patching mechanism
> and wouldn't require any elevated code to function. In that case there's no
> support for 2000 or any server platforms and Windows XP has the removable
> source as a requirement. End of story there unfortunately.
>
> I believe the removable source requirement was a compromise because game
> developers wanted to patch without their users being an admin and yet
> Microsoft didn't want corporate users applying patches without
> administrator's consent. So the idea was if a user installed from physical
> media it was likely a laptop/home user and in this case you'd want to be
> able to patch as non-admin. If the product was installed from network then
> likely the admin would update the network source and repair the product
> instead of allowing user to install the patch directly (and thus be out of
> sync with everyone else).
>
> Sincerely,
> Adrian Accinelli
>
>
> .
>

"John_s" <Johns@discussions.microsoft.com> wrote in message
news:36B63C5A-A5FA-4785-BF48-51A240A97552@microsoft.com...
> In order to ask my questions, I need to present our scenario:
> Clients receive our product through either a major upgrade interactive
> install or a Group Policy Push install. Our product has a mix of COM and
> .Net 2.0 components. We now have converted enough of our application to
> .Net to be able to patch by just replacing some .Net assemblies
> (upgrades involving the old COM components would require a full
> upgrade). We want our application to update itself when a patch is
> available: the user logs into our app and our app checks a file
> somewhere on the domain for whether it's up-to-date and if not, kicks
> off the patch upgrade, shuts down the app, runs the upgrade and
> re-starts the app. We don't want our client IT departments to have to
> push out patches through group policy; we only want to require that for
> major upgrades. Also, users are not administrators on their own
> machines. The predominant operating system is Windows XP, although
> there are some sites that still use Windows 2000 Pro and there will
> probably be some using Vista when our release goes out, which is soon.
> All the client's workstations have Windows Installer 3.1 or higher on
> them. The type of patch upgrade would be a "small upgrade". That is,
> the Product Code will remain the same and the first three numbers of
> the product's version will remain the same; we'll increment the fourth
> number to help identify the patch. Our major upgrade install is set not
> to enable repairs. It can only be installed or removed.
> The problem is there are significant restrictions to being able to apply
> patches to machine-based installs for users who are not administrators
> if we assume that our clients will not want to set group policy to
> allow all users to run installs with Elevated privileges. There is also
> GP setting for just allowing patches to run as elevated, but that too
> is a security risk.
> I understand that Windows Installer 3.0 and higher supports the patch
> upgrade scenario I'm talking about, but a couple of the restrictions I'm
> reading about I need clarification on because they look like they will
> spoil the plan. The restrictions are as follows:
> 1) The platform must be Microsoft Windows XP or later.
> 2) The application was installed from a removable media such as CD-ROM
> or DVD.
> For the first restriction: some of our clients have Windows 2000 Pro.
> Does that mean you can't use this method even though those machines are
> running Windows Installer 3.1? (I just want to be absolutely sure.)
> The second restriction I don't understand. How could it be a requirement
> that the install must run off a CD or DVD and not, for instance, from a
> network share? I don't see how that can make the install more secure.
> Anyway, that's an impossible requirement for organizations like the
> ones using our product; they must be able to run the upgrade from a
> network share.
> If I'm reading these restrictions correctly, it looks like the only
> options are as follows, assuming we don't switch to a per-user install
> and don't want to require a GP push for every patch: We have are either
> to ask the IT departments who use our product to relax the GP settings
> on elevated privileges (for installs or patches) or just find a way to
> copy the .Net assemblies without using the Windows Installer (because
> that's literally all we need to do to patch). Are there any other
> options?
> If we do have to resort to copying .Net assemblies in some way inside our
> own product, will that have any negative impact on future Major Upgrades?
> (Our intention would be to keep the first 3 version numbers the same and
> increment the fourth, matching the numbering on the product's version
> numbering).
> Thanks,
> John


Hi John,

If you can ensure that you can run code in an elevated context then you can
register your patches as "elevated". Once registered you can apply the
patch as a normal user. The information on this is located here:
http://msdn.microsoft.com/en-us/libr...82(VS.85).aspx

There's a small line of note: "You can also use this method to enable a
non-administrator to patch a per-machine application".

This should work on 2000, XP or the other client platforms anyways. I don't
think it will work on server plaforms (well if it does I think you'd have to
be on the console anyways).

What you are describing above is the User Account Control patching mechanism
and wouldn't require any elevated code to function. In that case there's no
support for 2000 or any server platforms and Windows XP has the removable
source as a requirement. End of story there unfortunately.

I believe the removable source requirement was a compromise because game
developers wanted to patch without their users being an admin and yet
Microsoft didn't want corporate users applying patches without
administrator's consent. So the idea was if a user installed from physical
media it was likely a laptop/home user and in this case you'd want to be
able to patch as non-admin. If the product was installed from network then
likely the admin would update the network source and repair the product
instead of allowing user to install the patch directly (and thus be out of
sync with everyone else).

Sincerely,
Adrian Accinelli

Replies inline.

"John_s" <Johns@discussions.microsoft.com> wrote in message
news:BEAB2DD5-8A99-4363-89BF-63EB51E587AB@microsoft.com...
> Hi Adrian,
> Thanks for your reply; very interesting and much appreciated! That sounds
> like it should do the trick. There are two issues that now stem from this
> possible solution, though.
> 1) The Microsoft documentation (a link to which you included in your
> response) is not clear on how this scenario is supposed to be
> implemented. That is, you want to place the signed patch on a network
> share where all users' systems can access it. But under what authority
> is the patch file signed so that the Windows Installer on each
> workstation recognizes that the authority that signed the patch file is
> authorized to run the patch as elevated on each workstation? Is the
> security in the fact that the patch file is impregnated as having been
> signed to run elevated and on a specific share? That doesn't seem
> secure enough as a local administrator on any given machine. I would
> have thought that the user who signed it would be a domain
> administrator who is in the administrators group on every workstation in
> the domain that's going to be applying the patch. I need this
> information to understand what we need to do to prepare the patch file
> for each client's site.

The docs basically mention two methods. Signing is only critical in one --
that being UAC patching one. The idea in this case is that you use the
MsiDigitalCertificate and MsiPatchCertificate tables in the ORIGINAL MSI
file to store the hash from the certificate you will use to sign your
patches (MSP files). The Installer will examine the MSP when it opens it
for the first time and will either consider it trusted or untrusted. If it's
trusted well then it's _trusted_ and based on policy can be applied without
being an admin/prompt required.

re: certificates used and who signs. Typically the original vendor of the
MSI does all this. But if you are dealing with administrative images then
the domain admin can sign the MSI using enterprise certificate and add that
certificate into the MSI's tables for patching purposes. Then when they
want to approve patches they can resign the MSP with the certificate and now
they have control over trused certificates.. no need to worry about 3rd
party ones. The file can be placed in central location where typical users
have access and applied via script/program/user interaction.

In the second method you don't need signature typically (except if group
policy requires signed MSI/MSPs). You just need some elevated code to
register the MSP (as per question 2). After the MSP is registered the MSP
is considered trusted and any repair operations launched by non-admins will
have the MSP be incorporated into the installation. Note that for now
anyways the sourcelists are stored in HKLM\Software\Classes\Installer so
that's why you need elevated code to change it.


> 2) I can't find any documentation on the Patch property (or method) of
> the patch object. The sample code shows the following 2 lines of code:
> Set installer = CreateObject("WindowsInstaller.Installer")
> Set patch = installer.Patch(PatchCode, "", UserSid,
> msiInstallContextUserManaged)
> So there is an Installer object that supposedly has a Patch method (or
> property), but I can't find documentation of this in on-line Windows
> MSDN, under the Windows Installer Automation Reference. The
> documentation on the Patch object says where the Patch object comes
> from in the second paragraph and it says that "Patch" is a property, so
> I should be able to find more about this property in the documentation,
> presumably under the properties for the Installer object.

The sample is correct - you just need to instantiate a patch object using
several parameters based on how the patch is/will be installed. Because the
patch is not applied yet the Installer.Patches property won't have it
listed.

The parameters you pass of course have to be correct based on what the
product the patch will be applicable to is installed. If it's per-user
managed then you need to make sure UserSid matches and Context is
MSIINSTALLCONTEXT_USERMANAGED (1). Per-machine would be UserSid empty and
Context MSIINSTALLCONTEXT_MACHINE (4).

Once you have the patch object you should be able to call
SourceListAddSource with source type, path to MSP and index.


Sincerely,
Adrian Accinelli

Hi Adiran,

The long gap in response is because I was pulled off this project and now
back on.

The only method that seems plausible is the "Patching per User-Managed
Applications" where you register the patch using a Windows Installer script,
but the problem with that is that the script has to be run by an
administrator on every workstation for every patch issued. If so, I presume
the easiest approach would be to push the script out to all the client
machines (maybe through AD) every time a patch is to be installed. Are my
assumptions correct? That can lead to problems, too, such as the script not
running on all the machines that nee to be patched and in that case, the
patch won't install. Seems more difficult and prone to error than it has to
be.

Thanks,
John

"John_s" <Johns@discussions.microsoft.com> wrote in message
news:3461A47B-F66E-4DFF-A1EA-965FE1F8C7BE@microsoft.com...
> Hi Adiran,
> The long gap in response is because I was pulled off this project and now
> back on.
> The only method that seems plausible is the "Patching per User-Managed
> Applications" where you register the patch using a Windows Installer
> script, but the problem with that is that the script has to be run by an
> administrator on every workstation for every patch issued. If so, I
> presume the easiest approach would be to push the script out to all the
> client machines (maybe through AD) every time a patch is to be
> installed. Are my assumptions correct? That can lead to problems, too,
> such as the script not running on all the machines that nee to be
> patched and in that case, the patch won't install. Seems more difficult
> and prone to error than it has to be.
> Thanks,
> John

Hi John,

I only see this as an issue for XP really and Per-User Managed patching was
not the order of the day in the time of XP. At that time the assumption was
that most people were admins of their machines and if they weren't they were
in a locked down environment where the IT department had asset management
software or know-how that would allow them to deploy patches. So it
shouldn't really be surprising that this is a "difficult and prone to error"
procedure in that environment. Compare that now to Vista/Windows 7 and
you'll see that Per-User Managed patching has come a long way since now in
Windows 7 for instance you can just double click the MSP to have it apply no
questions asked.

Meanwhile I would consider what your clients are really going to need -- are
they the types with IT departements who do this all the time or are they
going to need your hand holding throughout the entire process? If hand
holding is the norm then maybe you need to provide them a service
application that will apply your patches more easily. Sure it's harder for
you to provide but perhaps less painful in the long run. Also are these
same clients planning a migration to Windows 7?

Sincerely,
Adrian Accinelli

Hi Adrian,

Actually, just to be clear, we’re attempting to use the “Per-User Managed
Patching” facility of the Windows Installer as “Per-Machine” (which you
pointed out the documentation says you can do). Unfortunately, our clients’
IT departments do need a lot of hand holding and they have old machines, by
and large: Windows 2000 and Windows XP and are just beginning to upgrade to
Vista and Windows 7, but it will be a long time before that happens. (You
said that Windows 7 will run the upgrade no questions asked, but I assume the
application and patch have to be digitally signed.)

I wish they would get asset management software to handle upgrades, but they
can’t afford it or don’t have the expertise to use it.

Some of our clients use Group Policy to push out (per computer install) our
major upgrade installs, but that is a real hassle: it never goes smoothly.
Many machines don’t upgrade for a number of reasons and it’s not clear which
ones upgraded and which ones did not and the ones that did not need to be
upgraded manually. Some clients forgo the Group Push and just have the IT
staff (or IT person) go to every machine, log on as an administrator and run
the install from a network share, which they find is a real hassle.

Our application is a mixture of COM and .Net, so the thought was that
whenever a change involved COM (with registering and unregistering), we’d
create a major upgrade and have clients push out the install or install by
hand by an administrator, but when the change only involves .Net, since all
that really needs to happen is copy one or two .Net assemblies, the hope was
that you don’t need to be an administrator and a patch would be quick and
fast. Unfortunately, the .Net assemblies are in the Program Files directory,
so you need to be an administrator to write to it, which our client’s users
are not.

We had put code in our application to upgrade itself so that they don’t have
to push out the install or go around to all the PC’s and install manually as
often, but they have to be administrators for it to work. The upgrade
facility in our software checks a config file on a network share each time it
starts and if an upgrade is indicated, it goes to another share to get the
upgrade. It launches the upgrade and shuts itself down and a custom action in
the install starts it up again after the upgrade. It works great as long as
the users are administrators. We were hoping that patch upgrades would lessen
the rigors of administrative requirements, but not really for Windows 200 and
Windows XP computers, as I’ve found out.

So given all of this, it looks like we have the following options:

• Have the client temporarily allow users to install with elevated
privileges. This is a real security risk, though and I’m not sure whether
clients will opt for it.

• Use the “Per-User Managed Patching” technique, use the Controller object
of the Windows Scripting Host to run remotely, using WMI or ASDI to run a
Windows Installer script (the content of which you point to in the MSDN
documentation) on all machines to register the patch, so that later, when we
signal to our application that it’s time to upgrade, it will be able to do so
in the manner I described above. (Question: Do you have to run the script for
every patch, or only the first one for a given major upgrade install?)

• You mention creating a service application. Do you mean create a Windows
service? That doesn’t seem too difficult, but it can be problematic, as the
system account, which it would run under by default) has no access to network
shares, so somehow an account would need to be entered for the service and
then there’s the issue of it expiring. Adding another component into mix
seems to increase the chance for problems, too, such as the service not
running when it’s needed to perform the upgrade.

Thanks for your efforts to provide advice!

John

Responses inline.

"John_s" <Johns@discussions.microsoft.com> wrote in message
news:BA951B3C-2BE7-4D08-A49F-950D44D6BEA5@microsoft.com...
> Hi Adrian,
> Actually, just to be clear, we're attempting to use the "Per-User Managed
> Patching" facility of the Windows Installer as "Per-Machine" (which you
> pointed out the documentation says you can do). Unfortunately, our
> clients' IT departments do need a lot of hand holding and they have old
> machines, by and large: Windows 2000 and Windows XP and are just
> beginning to upgrade to Vista and Windows 7, but it will be a long time
> before that happens. (You said that Windows 7 will run the upgrade no
> questions asked, but I assume the application and patch have to be
> digitally signed.)

The application doesn't have to be signed but the patch definitely does.


> I wish they would get asset management software to handle upgrades, but
> they can't afford it or don't have the expertise to use it.
> Some of our clients use Group Policy to push out (per computer install)
> our major upgrade installs, but that is a real hassle: it never goes
> smoothly. Many machines don't upgrade for a number of reasons and it's
> not clear which ones upgraded and which ones did not and the ones that
> did not need to be upgraded manually. Some clients forgo the Group Push
> and just have the IT staff (or IT person) go to every machine, log on
> as an administrator and run the install from a network share, which
> they find is a real hassle.
At some point the cost of the admin doing all this extra work will actually
pay for the software. But in any case some people don't have this and are
not likely will to spend $$ to buy something that will do the job.

> Our application is a mixture of COM and .Net, so the thought was that
> whenever a change involved COM (with registering and unregistering), we'd
> create a major upgrade and have clients push out the install or install
> by hand by an administrator, but when the change only involves .Net,
> since all that really needs to happen is copy one or two .Net
> assemblies, the hope was that you don't need to be an administrator and
> a patch would be quick and fast. Unfortunately, the .Net assemblies are
> in the Program Files directory, so you need to be an administrator to
> write to it, which our client's users are not.
> We had put code in our application to upgrade itself so that they don't
> have to push out the install or go around to all the PC's and install
> manually as often, but they have to be administrators for it to work.
> The upgrade facility in our software checks a config file on a network
> share each time it starts and if an upgrade is indicated, it goes to
> another share to get the upgrade. It launches the upgrade and shuts
> itself down and a custom action in the install starts it up again after
> the upgrade. It works great as long as the users are administrators. We
> were hoping that patch upgrades would lessen the rigors of
> administrative requirements, but not really for Windows 200 and Windows
> XP computers, as I've found out.
> So given all of this, it looks like we have the following options:
> . Have the client temporarily allow users to install with elevated
> privileges. This is a real security risk, though and I'm not sure whether
> clients will opt for it.
> . Use the "Per-User Managed Patching" technique, use the Controller
> object of the Windows Scripting Host to run remotely, using WMI or ASDI
> to run a Windows Installer script (the content of which you point to in
> the MSDN documentation) on all machines to register the patch, so that
> later, when we signal to our application that it's time to upgrade, it
> will be able to do so in the manner I described above. (Question: Do
> you have to run the script for every patch, or only the first one for a
> given major upgrade install?)

Each patch would need to be added separately since it's by PatchCode and
these change for each new patch you create.


> . You mention creating a service application. Do you mean create a
> Windows service? That doesn't seem too difficult, but it can be
> problematic, as the system account, which it would run under by
> default) has no access to network shares, so somehow an account would
> need to be entered for the service and then there's the issue of it
> expiring. Adding another component into mix seems to increase the
> chance for problems, too, such as the service not running when it's
> needed to perform the upgrade.

Yes a windows service or better a Task in Vista or later. But of course you
can have the service run in the context of a user account with appropriate
privileges and get networking support as well. From here you can control the
various account settings including password expiry.

The bottomline is that I do not think there is a single "free" solution to
allow delivery of windows installer patches across all the platforms we are
discussing. You'll either have to do work yourself, buy a solution to go
with your application or pass the buck to your customer.

Sincerely,
Adrian Accinelli