summaryrefslogtreecommitdiff
path: root/docs/docbook/faq/clientapp.sgml
diff options
context:
space:
mode:
Diffstat (limited to 'docs/docbook/faq/clientapp.sgml')
-rw-r--r--docs/docbook/faq/clientapp.sgml101
1 files changed, 101 insertions, 0 deletions
diff --git a/docs/docbook/faq/clientapp.sgml b/docs/docbook/faq/clientapp.sgml
new file mode 100644
index 0000000000..6d687bf772
--- /dev/null
+++ b/docs/docbook/faq/clientapp.sgml
@@ -0,0 +1,101 @@
+<chapter id="ClientApp">
+<title>Specific client application problems</title>
+
+<sect1>
+<title>MS Office Setup reports "Cannot change properties of '\MSOFFICE\SETUP.INI'"</title>
+<para>
+When installing MS Office on a Samba drive for which you have admin
+user permissions, ie. admin users = username, you will find the
+setup program unable to complete the installation.
+</para>
+
+<para>
+To get around this problem, do the installation without admin user
+permissions The problem is that MS Office Setup checks that a file is
+rdonly by trying to open it for writing.
+</para>
+
+<para>
+Admin users can always open a file for writing, as they run as root.
+You just have to install as a non-admin user and then use "chown -R"
+to fix the owner.
+</para>
+
+</sect1>
+
+<sect1>
+<title>How to use a Samba share as an administrative share for MS Office, etc.</title>
+
+<para>
+Microsoft Office products can be installed as an administrative installation
+from which the application can either be run off the administratively installed
+product that resides on a shared resource, or from which that product can be
+installed onto workstation clients.
+</para>
+
+<para>
+The general mechanism for implementing an adminstrative installation involves
+running <command>X:\setup /A</command>, where X is the drive letter of either CDROM or floppy.
+</para>
+
+<para>
+This installation process will NOT install the product for use per se, but
+rather results in unpacking of the compressed distribution files into a target
+shared folder. For this process you need write privilidge to the share and it
+is desirable to enable file locking and share mode operation during this
+process.
+</para>
+
+<para>
+Subsequent installation of MS Office from this share will FAIL unless certain
+precautions are taken. This failure will be caused by share mode operation
+which will prevent the MS Office installation process from re-opening various
+dynamic link library files and will cause sporadic file not found problems.
+</para>
+
+<itemizedlist>
+<listitem><para>
+As soon as the administrative installation (unpacking) has completed
+set the following parameters on the share containing it:
+</para>
+
+<para><programlisting>
+ [MSOP95]
+ path = /where_you_put_it
+ comment = Your comment
+ volume = "The_CD_ROM_Label"
+ read only = yes
+ available = yes
+ share modes = no
+ locking = no
+ browseable = yes
+ public = yes
+</programlisting></para>
+
+</listitem>
+
+<listitem>
+<para>Now you are ready to run the setup program from the Microsoft Windows
+workstation as follows: <command>\\"Server_Name"\MSOP95\msoffice\setup</command>
+</para>
+</listitem>
+</itemizedlist>
+
+</sect1>
+
+<sect1>
+<title>Microsoft Access database opening errors</title>
+
+<para>
+Here are some notes on running MS-Access on a Samba drive from <ulink url="stefank@esi.com.au">Stefan Kjellberg</ulink>
+</para>
+
+<para><simplelist>
+<member>Opening a database in 'exclusive' mode does NOT work. Samba ignores r/w/share modes on file open.</member>
+<member>Make sure that you open the database as 'shared' and to 'lock modified records'</member>
+<member>Of course locking must be enabled for the particular share (smb.conf)</member>
+</simplelist>
+</para>
+
+</sect1>
+</chapter>