Tuesday, March 27, 2012
Cluster setup question
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/howtosql/ht
_clustering_51rm.asp
But it doesnt say where to install SQL. It seems to me that if I wanted to
have an Active/ Passive Cluster I would need to intsall it on both boxes? Is
this correct? Are there better links I should be using?
--
SQL2K SP3
TIA, ChrisRYou begin the installation from the node that currently owns the disk
resource you want SQL data files installed to. You can add additional disk
resources after the installation. The SQL installer adds code automagically
to the nodes you specify, provided they actually exist and are running at
install time. You can add or remove nodes from the SQL installation later
if you need to. Once SQL is installed, there is no difference between
installed nodes except for which one is actually running SQL at a given
moment.
--
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"ChrisR" <bla@.noemail.com> wrote in message
news:ugjtmqZ$EHA.2136@.TK2MSFTNGP10.phx.gbl...
> Im viewing the Cluster setup instructions at:
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/howtosql/ht
> _clustering_51rm.asp
> But it doesnt say where to install SQL. It seems to me that if I wanted to
> have an Active/ Passive Cluster I would need to intsall it on both boxes?
Is
> this correct? Are there better links I should be using?
> --
> SQL2K SP3
> TIA, ChrisR
>|||Well, that is close, but not quite accurate.
Even on a stand-alone installation, when you run the setup dialogue in
interactive mode, all that really happens is that a custom .iss file is
generated from your responses to the questions. Once all of the information
is gathered, setup then executes the setupsql with the newly created
setup.iss file as a parameter.
A cluster install is similar, except the setup.iss is deployed to both
nodes. During the installation, the cluster fails the disk over to each
node so that the individual setup.iss files can be ran against two
independently executed setupsql commands. This creates registry keys.
However, since the first install already created the directory structure,
deployed the binaries, installed the .sql scripts to master, model, and
msdb, this part of the process does not run again a second time. Just the
registry keys, performance counters, and client side tools. And, of course,
the MDAC, which is client side and IS NOT cluster aware.
Also, there is such a thing as the "Primary Node." This is nothing more
than the node from which you started the installation. It does not matter
which node you begin the installation on, as long as it is the node that
currently owns the disk resource you plan on installing SQL Server to.
However, it is important that you keep in mind which node this was.
This node will be the only one that maintains a record of the setup logs.
There is also special CLSIDs that only this node will contain that will not
propagate to the other. The nodes are close to the same configuration, BUT
NOT EXACT. This will be important in the future when you try to add
additional disk resources or swap out old disks for new, if you ever need to
modify or add an additional IP resource, or change the domain the cluster
belongs to. Keeping in mind which node was PRIMARY will only be to your
benefit.
Sincerely,
Anthony Thomas
"Geoff N. Hiten" <SRDBA@.Careerbuilder.com> wrote in message
news:%23e8GA4Z$EHA.2196@.TK2MSFTNGP14.phx.gbl...
You begin the installation from the node that currently owns the disk
resource you want SQL data files installed to. You can add additional disk
resources after the installation. The SQL installer adds code automagically
to the nodes you specify, provided they actually exist and are running at
install time. You can add or remove nodes from the SQL installation later
if you need to. Once SQL is installed, there is no difference between
installed nodes except for which one is actually running SQL at a given
moment.
--
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"ChrisR" <bla@.noemail.com> wrote in message
news:ugjtmqZ$EHA.2136@.TK2MSFTNGP10.phx.gbl...
> Im viewing the Cluster setup instructions at:
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/howtosql/ht
> _clustering_51rm.asp
> But it doesnt say where to install SQL. It seems to me that if I wanted to
> have an Active/ Passive Cluster I would need to intsall it on both boxes?
Is
> this correct? Are there better links I should be using?
> --
> SQL2K SP3
> TIA, ChrisR
>|||I have had to change accounts and add/remove disk resources. As long as I
use the current owner node, everything works fine.
Yes, there are some subtle differences such as log files between nodes but
that is only relevant during installation failure troubleshooting. Once
everythign is running, there is no practical difference between nodes,
unlike SQL 7.0 clustering.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"Anthony Thomas" <ALThomas@.kc.rr.com> wrote in message
news:OfrkU8e$EHA.1084@.tk2msftngp13.phx.gbl...
> Well, that is close, but not quite accurate.
> Even on a stand-alone installation, when you run the setup dialogue in
> interactive mode, all that really happens is that a custom .iss file is
> generated from your responses to the questions. Once all of the
information
> is gathered, setup then executes the setupsql with the newly created
> setup.iss file as a parameter.
> A cluster install is similar, except the setup.iss is deployed to both
> nodes. During the installation, the cluster fails the disk over to each
> node so that the individual setup.iss files can be ran against two
> independently executed setupsql commands. This creates registry keys.
> However, since the first install already created the directory structure,
> deployed the binaries, installed the .sql scripts to master, model, and
> msdb, this part of the process does not run again a second time. Just the
> registry keys, performance counters, and client side tools. And, of
course,
> the MDAC, which is client side and IS NOT cluster aware.
> Also, there is such a thing as the "Primary Node." This is nothing more
> than the node from which you started the installation. It does not matter
> which node you begin the installation on, as long as it is the node that
> currently owns the disk resource you plan on installing SQL Server to.
> However, it is important that you keep in mind which node this was.
> This node will be the only one that maintains a record of the setup logs.
> There is also special CLSIDs that only this node will contain that will
not
> propagate to the other. The nodes are close to the same configuration,
BUT
> NOT EXACT. This will be important in the future when you try to add
> additional disk resources or swap out old disks for new, if you ever need
to
> modify or add an additional IP resource, or change the domain the cluster
> belongs to. Keeping in mind which node was PRIMARY will only be to your
> benefit.
> Sincerely,
>
> Anthony Thomas
>
> --
> "Geoff N. Hiten" <SRDBA@.Careerbuilder.com> wrote in message
> news:%23e8GA4Z$EHA.2196@.TK2MSFTNGP14.phx.gbl...
> You begin the installation from the node that currently owns the disk
> resource you want SQL data files installed to. You can add additional
disk
> resources after the installation. The SQL installer adds code
automagically
> to the nodes you specify, provided they actually exist and are running at
> install time. You can add or remove nodes from the SQL installation later
> if you need to. Once SQL is installed, there is no difference between
> installed nodes except for which one is actually running SQL at a given
> moment.
> --
> Geoff N. Hiten
> Microsoft SQL Server MVP
> Senior Database Administrator
> Careerbuilder.com
> I support the Professional Association for SQL Server
> www.sqlpass.org
> "ChrisR" <bla@.noemail.com> wrote in message
> news:ugjtmqZ$EHA.2136@.TK2MSFTNGP10.phx.gbl...
> > Im viewing the Cluster setup instructions at:
> >
> >
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/howtosql/ht
> > _clustering_51rm.asp
> >
> > But it doesnt say where to install SQL. It seems to me that if I wanted
to
> > have an Active/ Passive Cluster I would need to intsall it on both
boxes?
> Is
> > this correct? Are there better links I should be using?
> >
> > --
> > SQL2K SP3
> >
> > TIA, ChrisR
> >
> >
>sqlsql
Cluster setup question
http://msdn.microsoft.com/library/de...us/howtosql/ht
_clustering_51rm.asp
But it doesnt say where to install SQL. It seems to me that if I wanted to
have an Active/ Passive Cluster I would need to intsall it on both boxes? Is
this correct? Are there better links I should be using?
SQL2K SP3
TIA, ChrisR
You begin the installation from the node that currently owns the disk
resource you want SQL data files installed to. You can add additional disk
resources after the installation. The SQL installer adds code automagically
to the nodes you specify, provided they actually exist and are running at
install time. You can add or remove nodes from the SQL installation later
if you need to. Once SQL is installed, there is no difference between
installed nodes except for which one is actually running SQL at a given
moment.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"ChrisR" <bla@.noemail.com> wrote in message
news:ugjtmqZ$EHA.2136@.TK2MSFTNGP10.phx.gbl...
> Im viewing the Cluster setup instructions at:
>
http://msdn.microsoft.com/library/de...us/howtosql/ht
> _clustering_51rm.asp
> But it doesnt say where to install SQL. It seems to me that if I wanted to
> have an Active/ Passive Cluster I would need to intsall it on both boxes?
Is
> this correct? Are there better links I should be using?
> --
> SQL2K SP3
> TIA, ChrisR
>
|||Well, that is close, but not quite accurate.
Even on a stand-alone installation, when you run the setup dialogue in
interactive mode, all that really happens is that a custom .iss file is
generated from your responses to the questions. Once all of the information
is gathered, setup then executes the setupsql with the newly created
setup.iss file as a parameter.
A cluster install is similar, except the setup.iss is deployed to both
nodes. During the installation, the cluster fails the disk over to each
node so that the individual setup.iss files can be ran against two
independently executed setupsql commands. This creates registry keys.
However, since the first install already created the directory structure,
deployed the binaries, installed the .sql scripts to master, model, and
msdb, this part of the process does not run again a second time. Just the
registry keys, performance counters, and client side tools. And, of course,
the MDAC, which is client side and IS NOT cluster aware.
Also, there is such a thing as the "Primary Node." This is nothing more
than the node from which you started the installation. It does not matter
which node you begin the installation on, as long as it is the node that
currently owns the disk resource you plan on installing SQL Server to.
However, it is important that you keep in mind which node this was.
This node will be the only one that maintains a record of the setup logs.
There is also special CLSIDs that only this node will contain that will not
propagate to the other. The nodes are close to the same configuration, BUT
NOT EXACT. This will be important in the future when you try to add
additional disk resources or swap out old disks for new, if you ever need to
modify or add an additional IP resource, or change the domain the cluster
belongs to. Keeping in mind which node was PRIMARY will only be to your
benefit.
Sincerely,
Anthony Thomas
"Geoff N. Hiten" <SRDBA@.Careerbuilder.com> wrote in message
news:%23e8GA4Z$EHA.2196@.TK2MSFTNGP14.phx.gbl...
You begin the installation from the node that currently owns the disk
resource you want SQL data files installed to. You can add additional disk
resources after the installation. The SQL installer adds code automagically
to the nodes you specify, provided they actually exist and are running at
install time. You can add or remove nodes from the SQL installation later
if you need to. Once SQL is installed, there is no difference between
installed nodes except for which one is actually running SQL at a given
moment.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"ChrisR" <bla@.noemail.com> wrote in message
news:ugjtmqZ$EHA.2136@.TK2MSFTNGP10.phx.gbl...
> Im viewing the Cluster setup instructions at:
>
http://msdn.microsoft.com/library/de...us/howtosql/ht
> _clustering_51rm.asp
> But it doesnt say where to install SQL. It seems to me that if I wanted to
> have an Active/ Passive Cluster I would need to intsall it on both boxes?
Is
> this correct? Are there better links I should be using?
> --
> SQL2K SP3
> TIA, ChrisR
>
|||I have had to change accounts and add/remove disk resources. As long as I
use the current owner node, everything works fine.
Yes, there are some subtle differences such as log files between nodes but
that is only relevant during installation failure troubleshooting. Once
everythign is running, there is no practical difference between nodes,
unlike SQL 7.0 clustering.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"Anthony Thomas" <ALThomas@.kc.rr.com> wrote in message
news:OfrkU8e$EHA.1084@.tk2msftngp13.phx.gbl...
> Well, that is close, but not quite accurate.
> Even on a stand-alone installation, when you run the setup dialogue in
> interactive mode, all that really happens is that a custom .iss file is
> generated from your responses to the questions. Once all of the
information
> is gathered, setup then executes the setupsql with the newly created
> setup.iss file as a parameter.
> A cluster install is similar, except the setup.iss is deployed to both
> nodes. During the installation, the cluster fails the disk over to each
> node so that the individual setup.iss files can be ran against two
> independently executed setupsql commands. This creates registry keys.
> However, since the first install already created the directory structure,
> deployed the binaries, installed the .sql scripts to master, model, and
> msdb, this part of the process does not run again a second time. Just the
> registry keys, performance counters, and client side tools. And, of
course,
> the MDAC, which is client side and IS NOT cluster aware.
> Also, there is such a thing as the "Primary Node." This is nothing more
> than the node from which you started the installation. It does not matter
> which node you begin the installation on, as long as it is the node that
> currently owns the disk resource you plan on installing SQL Server to.
> However, it is important that you keep in mind which node this was.
> This node will be the only one that maintains a record of the setup logs.
> There is also special CLSIDs that only this node will contain that will
not
> propagate to the other. The nodes are close to the same configuration,
BUT
> NOT EXACT. This will be important in the future when you try to add
> additional disk resources or swap out old disks for new, if you ever need
to
> modify or add an additional IP resource, or change the domain the cluster
> belongs to. Keeping in mind which node was PRIMARY will only be to your
> benefit.
> Sincerely,
>
> Anthony Thomas
>
> --
> "Geoff N. Hiten" <SRDBA@.Careerbuilder.com> wrote in message
> news:%23e8GA4Z$EHA.2196@.TK2MSFTNGP14.phx.gbl...
> You begin the installation from the node that currently owns the disk
> resource you want SQL data files installed to. You can add additional
disk
> resources after the installation. The SQL installer adds code
automagically
> to the nodes you specify, provided they actually exist and are running at
> install time. You can add or remove nodes from the SQL installation later
> if you need to. Once SQL is installed, there is no difference between
> installed nodes except for which one is actually running SQL at a given
> moment.
> --
> Geoff N. Hiten
> Microsoft SQL Server MVP
> Senior Database Administrator
> Careerbuilder.com
> I support the Professional Association for SQL Server
> www.sqlpass.org
> "ChrisR" <bla@.noemail.com> wrote in message
> news:ugjtmqZ$EHA.2136@.TK2MSFTNGP10.phx.gbl...
>
http://msdn.microsoft.com/library/de...us/howtosql/ht[vbcol=seagreen]
to[vbcol=seagreen]
boxes?
> Is
>
Cluster setup question
http://msdn.microsoft.com/library/d...-us/howtosql/ht
_clustering_51rm.asp
But it doesnt say where to install SQL. It seems to me that if I wanted to
have an Active/ Passive Cluster I would need to intsall it on both boxes? Is
this correct? Are there better links I should be using?
SQL2K SP3
TIA, ChrisRYou begin the installation from the node that currently owns the disk
resource you want SQL data files installed to. You can add additional disk
resources after the installation. The SQL installer adds code automagically
to the nodes you specify, provided they actually exist and are running at
install time. You can add or remove nodes from the SQL installation later
if you need to. Once SQL is installed, there is no difference between
installed nodes except for which one is actually running SQL at a given
moment.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"ChrisR" <bla@.noemail.com> wrote in message
news:ugjtmqZ$EHA.2136@.TK2MSFTNGP10.phx.gbl...
> Im viewing the Cluster setup instructions at:
>
http://msdn.microsoft.com/library/d...-us/howtosql/ht
> _clustering_51rm.asp
> But it doesnt say where to install SQL. It seems to me that if I wanted to
> have an Active/ Passive Cluster I would need to intsall it on both boxes?
Is
> this correct? Are there better links I should be using?
> --
> SQL2K SP3
> TIA, ChrisR
>|||Well, that is close, but not quite accurate.
Even on a stand-alone installation, when you run the setup dialogue in
interactive mode, all that really happens is that a custom .iss file is
generated from your responses to the questions. Once all of the information
is gathered, setup then executes the setupsql with the newly created
setup.iss file as a parameter.
A cluster install is similar, except the setup.iss is deployed to both
nodes. During the installation, the cluster fails the disk over to each
node so that the individual setup.iss files can be ran against two
independently executed setupsql commands. This creates registry keys.
However, since the first install already created the directory structure,
deployed the binaries, installed the .sql scripts to master, model, and
msdb, this part of the process does not run again a second time. Just the
registry keys, performance counters, and client side tools. And, of course,
the MDAC, which is client side and IS NOT cluster aware.
Also, there is such a thing as the "Primary Node." This is nothing more
than the node from which you started the installation. It does not matter
which node you begin the installation on, as long as it is the node that
currently owns the disk resource you plan on installing SQL Server to.
However, it is important that you keep in mind which node this was.
This node will be the only one that maintains a record of the setup logs.
There is also special CLSIDs that only this node will contain that will not
propagate to the other. The nodes are close to the same configuration, BUT
NOT EXACT. This will be important in the future when you try to add
additional disk resources or swap out old disks for new, if you ever need to
modify or add an additional IP resource, or change the domain the cluster
belongs to. Keeping in mind which node was PRIMARY will only be to your
benefit.
Sincerely,
Anthony Thomas
"Geoff N. Hiten" <SRDBA@.Careerbuilder.com> wrote in message
news:%23e8GA4Z$EHA.2196@.TK2MSFTNGP14.phx.gbl...
You begin the installation from the node that currently owns the disk
resource you want SQL data files installed to. You can add additional disk
resources after the installation. The SQL installer adds code automagically
to the nodes you specify, provided they actually exist and are running at
install time. You can add or remove nodes from the SQL installation later
if you need to. Once SQL is installed, there is no difference between
installed nodes except for which one is actually running SQL at a given
moment.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"ChrisR" <bla@.noemail.com> wrote in message
news:ugjtmqZ$EHA.2136@.TK2MSFTNGP10.phx.gbl...
> Im viewing the Cluster setup instructions at:
>
http://msdn.microsoft.com/library/d...-us/howtosql/ht
> _clustering_51rm.asp
> But it doesnt say where to install SQL. It seems to me that if I wanted to
> have an Active/ Passive Cluster I would need to intsall it on both boxes?
Is
> this correct? Are there better links I should be using?
> --
> SQL2K SP3
> TIA, ChrisR
>|||I have had to change accounts and add/remove disk resources. As long as I
use the current owner node, everything works fine.
Yes, there are some subtle differences such as log files between nodes but
that is only relevant during installation failure troubleshooting. Once
everythign is running, there is no practical difference between nodes,
unlike SQL 7.0 clustering.
Geoff N. Hiten
Microsoft SQL Server MVP
Senior Database Administrator
Careerbuilder.com
I support the Professional Association for SQL Server
www.sqlpass.org
"Anthony Thomas" <ALThomas@.kc.rr.com> wrote in message
news:OfrkU8e$EHA.1084@.tk2msftngp13.phx.gbl...
> Well, that is close, but not quite accurate.
> Even on a stand-alone installation, when you run the setup dialogue in
> interactive mode, all that really happens is that a custom .iss file is
> generated from your responses to the questions. Once all of the
information
> is gathered, setup then executes the setupsql with the newly created
> setup.iss file as a parameter.
> A cluster install is similar, except the setup.iss is deployed to both
> nodes. During the installation, the cluster fails the disk over to each
> node so that the individual setup.iss files can be ran against two
> independently executed setupsql commands. This creates registry keys.
> However, since the first install already created the directory structure,
> deployed the binaries, installed the .sql scripts to master, model, and
> msdb, this part of the process does not run again a second time. Just the
> registry keys, performance counters, and client side tools. And, of
course,
> the MDAC, which is client side and IS NOT cluster aware.
> Also, there is such a thing as the "Primary Node." This is nothing more
> than the node from which you started the installation. It does not matter
> which node you begin the installation on, as long as it is the node that
> currently owns the disk resource you plan on installing SQL Server to.
> However, it is important that you keep in mind which node this was.
> This node will be the only one that maintains a record of the setup logs.
> There is also special CLSIDs that only this node will contain that will
not
> propagate to the other. The nodes are close to the same configuration,
BUT
> NOT EXACT. This will be important in the future when you try to add
> additional disk resources or swap out old disks for new, if you ever need
to
> modify or add an additional IP resource, or change the domain the cluster
> belongs to. Keeping in mind which node was PRIMARY will only be to your
> benefit.
> Sincerely,
>
> Anthony Thomas
>
> --
> "Geoff N. Hiten" <SRDBA@.Careerbuilder.com> wrote in message
> news:%23e8GA4Z$EHA.2196@.TK2MSFTNGP14.phx.gbl...
> You begin the installation from the node that currently owns the disk
> resource you want SQL data files installed to. You can add additional
disk
> resources after the installation. The SQL installer adds code
automagically
> to the nodes you specify, provided they actually exist and are running at
> install time. You can add or remove nodes from the SQL installation later
> if you need to. Once SQL is installed, there is no difference between
> installed nodes except for which one is actually running SQL at a given
> moment.
> --
> Geoff N. Hiten
> Microsoft SQL Server MVP
> Senior Database Administrator
> Careerbuilder.com
> I support the Professional Association for SQL Server
> www.sqlpass.org
> "ChrisR" <bla@.noemail.com> wrote in message
> news:ugjtmqZ$EHA.2136@.TK2MSFTNGP10.phx.gbl...
>
http://msdn.microsoft.com/library/d...-us/howtosql/ht
to[vbcol=seagreen]
boxes?[vbcol=seagreen]
> Is
>
Sunday, February 12, 2012
ClickOnce private installation issue
I'm working on a VB.Net 2005 application that uses SQLCE as a backend database.
Following the instructions on how to do a private installation (http://msdn2.microsoft.com/en-us/librar
"Unable to install or run the application. Application requires that assembly System.Data.SQLServerCe version 9.0.42 .... must be installed in the Global Assembly Cache."
Basically it's saying the user isn't an admin so they can't install. This is the problem I went to great lengths to try to avoid, and is the reason we are using SQL CE in the first place: admin rights are not required to install our application's database. To our knowledge, SQL CE is the only Microsoft product that fits this scenario.
Now, I haven't changed anything in the publishing of the application to my knowledge, and when I check the project prerequisites, the SQLCE engine still isn't in there (as summarized at the above URL). Again following the instructions at the URL above for private installation, the required assemblies are still part of the project's files.
It must be something I did to cause this, but I have no memory of changing anything in regards to this part of the application. Our deadline is in 4 days and I cannot continue development until I get past this issue.
Where do I look to fix this problem? A little help would be greatly appreciated.
It is currently unknown as to what caused this problem and the fix may be a kludge. However, we have made some changes after much agonizing, and the application now installs with a newly-created standard user account on Windows XP. After seeing what we did to fix this issue below, any further comments are still appreciated, since we're working with a db system that's only a few months old, and which is not documented with the same rigor as most Microsoft products.
Upon checking the Prerequisites for our application (at Project Properties | Publish | Prerequisites), we saw that not only was SQL CE not selected as a prerequisite, it was not even listed as something we could deselect. Yet, it was still being configured to be installed into the GAC by the ClickOnce engine. Earlier in the development process, perhaps three weeks ago, it did appear in the prerequisites list, and was explicitly deselected. But now it had... disappeared.
However, upon checking what would be installed at Project Properties | Publish | Application Files, we saw that indeed, System.Data.SQLServerCE.dll was being included in the install, and its Publish Status was set as Prerequisite(Auto). Certainly we did not explicitly make this setting, and we are still unable to explain how it happened. Add to this that it could not be deselected on the Prerequisites tab, and you begin to understand the confusion surrounding this issue. (NOTE: we found this same problem with the Microsoft Visual Studio Report Viewer.)
Our first cut at a fix did not work: we changed the Publish status on each item listed as Prerequisite(Auto) to Exclude. The deployment completed without error, but after installation the application could not find required code to execute correctly, and threw unhandled errors at runtime.
Our second try at a fix is where we are now: we changed all items (except Framework 2.0) formerly listed as Prerequisite(Auto) to Include. Interestingly, those items that would not install as prerequisites without Administrator permissions, would now install without error. The last error to be cleared concerned the data file itself.
During our application deployment, we wanted to copy the .sdf database to the program folder. We reference it in code without a fully qualified path, due to the expectation that the database file will be in the same directory as the application executable. However, after clearing the errors described above, we had one last problem to fix: the database file was not found after installation. Checking, we saw that the ClickOnce engine automatically copies the database file to a different folder than the rest of the application files. So, we returned yet again to the Application Files list at Project Properties | Publish, and found that something Auto was happening with our database as well: its Publish Status was listed as Data File(Auto). Taking yet another wild guess, we changed it to Include. Lo, behold and voila, everything now works.
The very unfortunate issues here are 1) that we don't know why it didn't work in the first place, 2) we don't know what happened to change what we thought were correct settings for publication, and 3) we don't know whay what we did to fix the problems worked. To wit, nothing makes logical sense at this point.
We don't know whether any of the things we went through should be classed as bugs in either ClickOnce, Visual Studio, or anything else. Admittedly we are rather over our heads using several technologies for the first time. However, it needs to be said: at best, the documentation for this deployment scenario is sadly lacking (or just plain wrong). At worst, this deployment scenario is not supported by default, and it takes several arcane spells and a lot of wing of bat and eye of newt due to bugs in the system.
At any rate, I hope this tale of woe may help others who may be doing this for the first time.