Believe me, I hear you. I went through all this when I was on the
install team at Medium Sized Corporation. MSC initially had a
philosophy of trying to cram everything into the install.
Eventually, they learned that the tools used in "post install
configuration" were useful in maintenance operations that their
customers were already doing. Initially the install team argued for
making the install as simple as possible, but were forced to
implement requirements similar to those you describe ("all in the
install"). This created problems because the added complexity in the
install which caused more points of failure in the install,
particularly in upgrade, patching and repair scenarios. Eventually,
configuration operations were moved to a utility program -- generally
this was a matter of database operations, but it could be anything.
I would still create a local user/group that your code uses and add
that local user/group to the appropriate domain group that they use
to grant you domain priveleges. In other words don't run *as* their
domain user/group; run as your own user/group and have them add that
user/group to the appropriate domain group that has the priveleges
you need. This decouples you from their setup and makes your
security environment more granular and amenable to control/policy.
--
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
<http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>
Legalize Adulthood! <http://legalizeadulthood.wordpress.com>
------------------------------------------------------------------------------
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
