Networked Office

[Sarah Tanembaum]

Perhaps you can answer my question and test it on your server and
workstations(make sure that there are at least 2 workstation and use it
simultaneously). Then, you can see where the problem are.

 

[Sarah Tanembaum]

Perhaps you can answer my question and test it on your server and
workstations(make sure that there are at least 2 workstation and use it
simultaneously). Then, you can see where the problem are.

 

[Sarah Tanembaum]

Perhaps you can answer my question and test it on your server and
workstations(make sure that there are at least 2 workstation and use it
simultaneously). Then, you can see where the problem are.

 

[Sarah Tanembaum]

Perhaps you can answer my question and test it on your server and
workstations(make sure that there are at least 2 workstation and use it
simultaneously). Then, you can see where the problem are.

 

[Sarah Tanembaum]

Perhaps you can answer my question and test it on your server and
workstations(make sure that there are at least 2 workstation and use it
simultaneously). Then, you can see where the problem are.

 

[Sarah Tanembaum]

Perhaps you can answer my question and test it on your server and
workstations(make sure that there are at least 2 workstation and use it
simultaneously). Then, you can see where the problem are.

 

[Sarah Tanembaum]

Perhaps you can answer my question and test it on your server and
workstations(make sure that there are at least 2 workstation and use it
simultaneously). Then, you can see where the problem are.

 

[Sarah Tanembaum]

Perhaps you can answer my question and test it on your server and
workstations(make sure that there are at least 2 workstation and use it
simultaneously). Then, you can see where the problem are.

 

[AndyC]

Forgive me if I was mistaken.

Let me rephrase my understanding of your(MS) solution:

1- I put all the executable file as well as dll on the server to share with
other workstation without
copying any exec and/or dll file on the workstation.

Almost correct. You create an Administrative Install on the server with:

msiexec /a office.msi

This creates the correct folder structure for the server. No files are
copied to the workstation.

You then use the Office Custom Installation Wizard to configure the way you
want the Office installation done. In your case this would involve selecting
"Run from the Network" for all options. However it's perfectly valid to mix
and match if, for example, you wanted Powerpoint installed locally or
Outlook to install locally on first use etc.

You then save the .mst file in your server's shared office folder (referred
to from here on in as \\server\office)

2- I just create a shortcut and registry setting and voila I can ran the
office apps?
PS: I'd like to see the scripts that create those shortcut(don't need
the shortcut, I'd like to just
execute it directly from the network-attached directory) and
registry setting(what setting do
I need?)

Depending on your environment you can do this one of two ways:

1) If you have Active Directory, just create a GPO containing the Office
package with the .mst transform you created earlier and assign it to the
relevant Organisational Unit.

2) Alternatively, run the msiexec utility from a startup script or similar
method, again applying the relevant transform. Something like this should do
the trick:

msiexec /i \\server\Office\office.msi
TRANSFORM=\\server\Office\my_office_transform.mst /qb

This will create the appropriate registry information and Windows Installer
shortcuts for the setup you decided upon in your Custom Installation. If you
don't want the shortcuts you can always opt to omit them in your .mst file,
although I don't really see and advantage in that.

3- Just to be sure! NO INSTALLATION PROCESS ON THE WORKSTATION AND NO
EXEC and DLL files COPIED TO WORKSTATION?

Are those correct! If they are, please forgive me, but I can bet that was
not the case!

Yes that is correct. EXE or DLL files are only copied to the local
workstation if you request it in your installation. One possible caveat to
this is that Office 2003 has a few .NET optional extras (programmer support
IIRC) which have to be installed locally if you want them (because of the
way .NET Code Access Security works), although 99% of people probably don't.

AndyC

 

[AndyC]

Forgive me if I was mistaken.

Let me rephrase my understanding of your(MS) solution:

1- I put all the executable file as well as dll on the server to share with
other workstation without
copying any exec and/or dll file on the workstation.

Almost correct. You create an Administrative Install on the server with:

msiexec /a office.msi

This creates the correct folder structure for the server. No files are
copied to the workstation.

You then use the Office Custom Installation Wizard to configure the way you
want the Office installation done. In your case this would involve selecting
"Run from the Network" for all options. However it's perfectly valid to mix
and match if, for example, you wanted Powerpoint installed locally or
Outlook to install locally on first use etc.

You then save the .mst file in your server's shared office folder (referred
to from here on in as \\server\office)

2- I just create a shortcut and registry setting and voila I can ran the
office apps?
PS: I'd like to see the scripts that create those shortcut(don't need
the shortcut, I'd like to just
execute it directly from the network-attached directory) and
registry setting(what setting do
I need?)

Depending on your environment you can do this one of two ways:

1) If you have Active Directory, just create a GPO containing the Office
package with the .mst transform you created earlier and assign it to the
relevant Organisational Unit.

2) Alternatively, run the msiexec utility from a startup script or similar
method, again applying the relevant transform. Something like this should do
the trick:

msiexec /i \\server\Office\office.msi
TRANSFORM=\\server\Office\my_office_transform.mst /qb

This will create the appropriate registry information and Windows Installer
shortcuts for the setup you decided upon in your Custom Installation. If you
don't want the shortcuts you can always opt to omit them in your .mst file,
although I don't really see and advantage in that.

3- Just to be sure! NO INSTALLATION PROCESS ON THE WORKSTATION AND NO
EXEC and DLL files COPIED TO WORKSTATION?

Are those correct! If they are, please forgive me, but I can bet that was
not the case!

Yes that is correct. EXE or DLL files are only copied to the local
workstation if you request it in your installation. One possible caveat to
this is that Office 2003 has a few .NET optional extras (programmer support
IIRC) which have to be installed locally if you want them (because of the
way .NET Code Access Security works), although 99% of people probably don't.

AndyC

 

[AndyC]

Forgive me if I was mistaken.

Let me rephrase my understanding of your(MS) solution:

1- I put all the executable file as well as dll on the server to share with
other workstation without
copying any exec and/or dll file on the workstation.

Almost correct. You create an Administrative Install on the server with:

msiexec /a office.msi

This creates the correct folder structure for the server. No files are
copied to the workstation.

You then use the Office Custom Installation Wizard to configure the way you
want the Office installation done. In your case this would involve selecting
"Run from the Network" for all options. However it's perfectly valid to mix
and match if, for example, you wanted Powerpoint installed locally or
Outlook to install locally on first use etc.

You then save the .mst file in your server's shared office folder (referred
to from here on in as \\server\office)

2- I just create a shortcut and registry setting and voila I can ran the
office apps?
PS: I'd like to see the scripts that create those shortcut(don't need
the shortcut, I'd like to just
execute it directly from the network-attached directory) and
registry setting(what setting do
I need?)

Depending on your environment you can do this one of two ways:

1) If you have Active Directory, just create a GPO containing the Office
package with the .mst transform you created earlier and assign it to the
relevant Organisational Unit.

2) Alternatively, run the msiexec utility from a startup script or similar
method, again applying the relevant transform. Something like this should do
the trick:

msiexec /i \\server\Office\office.msi
TRANSFORM=\\server\Office\my_office_transform.mst /qb

This will create the appropriate registry information and Windows Installer
shortcuts for the setup you decided upon in your Custom Installation. If you
don't want the shortcuts you can always opt to omit them in your .mst file,
although I don't really see and advantage in that.

3- Just to be sure! NO INSTALLATION PROCESS ON THE WORKSTATION AND NO
EXEC and DLL files COPIED TO WORKSTATION?

Are those correct! If they are, please forgive me, but I can bet that was
not the case!

Yes that is correct. EXE or DLL files are only copied to the local
workstation if you request it in your installation. One possible caveat to
this is that Office 2003 has a few .NET optional extras (programmer support
IIRC) which have to be installed locally if you want them (because of the
way .NET Code Access Security works), although 99% of people probably don't.

AndyC

 

[AndyC]

Forgive me if I was mistaken.

Let me rephrase my understanding of your(MS) solution:

1- I put all the executable file as well as dll on the server to share with
other workstation without
copying any exec and/or dll file on the workstation.

Almost correct. You create an Administrative Install on the server with:

msiexec /a office.msi

This creates the correct folder structure for the server. No files are
copied to the workstation.

You then use the Office Custom Installation Wizard to configure the way you
want the Office installation done. In your case this would involve selecting
"Run from the Network" for all options. However it's perfectly valid to mix
and match if, for example, you wanted Powerpoint installed locally or
Outlook to install locally on first use etc.

You then save the .mst file in your server's shared office folder (referred
to from here on in as \\server\office)

2- I just create a shortcut and registry setting and voila I can ran the
office apps?
PS: I'd like to see the scripts that create those shortcut(don't need
the shortcut, I'd like to just
execute it directly from the network-attached directory) and
registry setting(what setting do
I need?)

Depending on your environment you can do this one of two ways:

1) If you have Active Directory, just create a GPO containing the Office
package with the .mst transform you created earlier and assign it to the
relevant Organisational Unit.

2) Alternatively, run the msiexec utility from a startup script or similar
method, again applying the relevant transform. Something like this should do
the trick:

msiexec /i \\server\Office\office.msi
TRANSFORM=\\server\Office\my_office_transform.mst /qb

This will create the appropriate registry information and Windows Installer
shortcuts for the setup you decided upon in your Custom Installation. If you
don't want the shortcuts you can always opt to omit them in your .mst file,
although I don't really see and advantage in that.

3- Just to be sure! NO INSTALLATION PROCESS ON THE WORKSTATION AND NO
EXEC and DLL files COPIED TO WORKSTATION?

Are those correct! If they are, please forgive me, but I can bet that was
not the case!

Yes that is correct. EXE or DLL files are only copied to the local
workstation if you request it in your installation. One possible caveat to
this is that Office 2003 has a few .NET optional extras (programmer support
IIRC) which have to be installed locally if you want them (because of the
way .NET Code Access Security works), although 99% of people probably don't.

AndyC

 

[AndyC]

Forgive me if I was mistaken.

Let me rephrase my understanding of your(MS) solution:

1- I put all the executable file as well as dll on the server to share with
other workstation without
copying any exec and/or dll file on the workstation.

Almost correct. You create an Administrative Install on the server with:

msiexec /a office.msi

This creates the correct folder structure for the server. No files are
copied to the workstation.

You then use the Office Custom Installation Wizard to configure the way you
want the Office installation done. In your case this would involve selecting
"Run from the Network" for all options. However it's perfectly valid to mix
and match if, for example, you wanted Powerpoint installed locally or
Outlook to install locally on first use etc.

You then save the .mst file in your server's shared office folder (referred
to from here on in as \\server\office)

2- I just create a shortcut and registry setting and voila I can ran the
office apps?
PS: I'd like to see the scripts that create those shortcut(don't need
the shortcut, I'd like to just
execute it directly from the network-attached directory) and
registry setting(what setting do
I need?)

Depending on your environment you can do this one of two ways:

1) If you have Active Directory, just create a GPO containing the Office
package with the .mst transform you created earlier and assign it to the
relevant Organisational Unit.

2) Alternatively, run the msiexec utility from a startup script or similar
method, again applying the relevant transform. Something like this should do
the trick:

msiexec /i \\server\Office\office.msi
TRANSFORM=\\server\Office\my_office_transform.mst /qb

This will create the appropriate registry information and Windows Installer
shortcuts for the setup you decided upon in your Custom Installation. If you
don't want the shortcuts you can always opt to omit them in your .mst file,
although I don't really see and advantage in that.

3- Just to be sure! NO INSTALLATION PROCESS ON THE WORKSTATION AND NO
EXEC and DLL files COPIED TO WORKSTATION?

Are those correct! If they are, please forgive me, but I can bet that was
not the case!

Yes that is correct. EXE or DLL files are only copied to the local
workstation if you request it in your installation. One possible caveat to
this is that Office 2003 has a few .NET optional extras (programmer support
IIRC) which have to be installed locally if you want them (because of the
way .NET Code Access Security works), although 99% of people probably don't.

AndyC

 

[AndyC]

Forgive me if I was mistaken.

Let me rephrase my understanding of your(MS) solution:

1- I put all the executable file as well as dll on the server to share with
other workstation without
copying any exec and/or dll file on the workstation.

Almost correct. You create an Administrative Install on the server with:

msiexec /a office.msi

This creates the correct folder structure for the server. No files are
copied to the workstation.

You then use the Office Custom Installation Wizard to configure the way you
want the Office installation done. In your case this would involve selecting
"Run from the Network" for all options. However it's perfectly valid to mix
and match if, for example, you wanted Powerpoint installed locally or
Outlook to install locally on first use etc.

You then save the .mst file in your server's shared office folder (referred
to from here on in as \\server\office)

2- I just create a shortcut and registry setting and voila I can ran the
office apps?
PS: I'd like to see the scripts that create those shortcut(don't need
the shortcut, I'd like to just
execute it directly from the network-attached directory) and
registry setting(what setting do
I need?)

Depending on your environment you can do this one of two ways:

1) If you have Active Directory, just create a GPO containing the Office
package with the .mst transform you created earlier and assign it to the
relevant Organisational Unit.

2) Alternatively, run the msiexec utility from a startup script or similar
method, again applying the relevant transform. Something like this should do
the trick:

msiexec /i \\server\Office\office.msi
TRANSFORM=\\server\Office\my_office_transform.mst /qb

This will create the appropriate registry information and Windows Installer
shortcuts for the setup you decided upon in your Custom Installation. If you
don't want the shortcuts you can always opt to omit them in your .mst file,
although I don't really see and advantage in that.

3- Just to be sure! NO INSTALLATION PROCESS ON THE WORKSTATION AND NO
EXEC and DLL files COPIED TO WORKSTATION?

Are those correct! If they are, please forgive me, but I can bet that was
not the case!

Yes that is correct. EXE or DLL files are only copied to the local
workstation if you request it in your installation. One possible caveat to
this is that Office 2003 has a few .NET optional extras (programmer support
IIRC) which have to be installed locally if you want them (because of the
way .NET Code Access Security works), although 99% of people probably don't.

AndyC

 

[AndyC]

Forgive me if I was mistaken.

Let me rephrase my understanding of your(MS) solution:

1- I put all the executable file as well as dll on the server to share with
other workstation without
copying any exec and/or dll file on the workstation.

Almost correct. You create an Administrative Install on the server with:

msiexec /a office.msi

This creates the correct folder structure for the server. No files are
copied to the workstation.

You then use the Office Custom Installation Wizard to configure the way you
want the Office installation done. In your case this would involve selecting
"Run from the Network" for all options. However it's perfectly valid to mix
and match if, for example, you wanted Powerpoint installed locally or
Outlook to install locally on first use etc.

You then save the .mst file in your server's shared office folder (referred
to from here on in as \\server\office)

2- I just create a shortcut and registry setting and voila I can ran the
office apps?
PS: I'd like to see the scripts that create those shortcut(don't need
the shortcut, I'd like to just
execute it directly from the network-attached directory) and
registry setting(what setting do
I need?)

Depending on your environment you can do this one of two ways:

1) If you have Active Directory, just create a GPO containing the Office
package with the .mst transform you created earlier and assign it to the
relevant Organisational Unit.

2) Alternatively, run the msiexec utility from a startup script or similar
method, again applying the relevant transform. Something like this should do
the trick:

msiexec /i \\server\Office\office.msi
TRANSFORM=\\server\Office\my_office_transform.mst /qb

This will create the appropriate registry information and Windows Installer
shortcuts for the setup you decided upon in your Custom Installation. If you
don't want the shortcuts you can always opt to omit them in your .mst file,
although I don't really see and advantage in that.

3- Just to be sure! NO INSTALLATION PROCESS ON THE WORKSTATION AND NO
EXEC and DLL files COPIED TO WORKSTATION?

Are those correct! If they are, please forgive me, but I can bet that was
not the case!

Yes that is correct. EXE or DLL files are only copied to the local
workstation if you request it in your installation. One possible caveat to
this is that Office 2003 has a few .NET optional extras (programmer support
IIRC) which have to be installed locally if you want them (because of the
way .NET Code Access Security works), although 99% of people probably don't.

AndyC

 

[AndyC]

Forgive me if I was mistaken.

Let me rephrase my understanding of your(MS) solution:

1- I put all the executable file as well as dll on the server to share with
other workstation without
copying any exec and/or dll file on the workstation.

Almost correct. You create an Administrative Install on the server with:

msiexec /a office.msi

This creates the correct folder structure for the server. No files are
copied to the workstation.

You then use the Office Custom Installation Wizard to configure the way you
want the Office installation done. In your case this would involve selecting
"Run from the Network" for all options. However it's perfectly valid to mix
and match if, for example, you wanted Powerpoint installed locally or
Outlook to install locally on first use etc.

You then save the .mst file in your server's shared office folder (referred
to from here on in as \\server\office)

2- I just create a shortcut and registry setting and voila I can ran the
office apps?
PS: I'd like to see the scripts that create those shortcut(don't need
the shortcut, I'd like to just
execute it directly from the network-attached directory) and
registry setting(what setting do
I need?)

Depending on your environment you can do this one of two ways:

1) If you have Active Directory, just create a GPO containing the Office
package with the .mst transform you created earlier and assign it to the
relevant Organisational Unit.

2) Alternatively, run the msiexec utility from a startup script or similar
method, again applying the relevant transform. Something like this should do
the trick:

msiexec /i \\server\Office\office.msi
TRANSFORM=\\server\Office\my_office_transform.mst /qb

This will create the appropriate registry information and Windows Installer
shortcuts for the setup you decided upon in your Custom Installation. If you
don't want the shortcuts you can always opt to omit them in your .mst file,
although I don't really see and advantage in that.

3- Just to be sure! NO INSTALLATION PROCESS ON THE WORKSTATION AND NO
EXEC and DLL files COPIED TO WORKSTATION?

Are those correct! If they are, please forgive me, but I can bet that was
not the case!

Yes that is correct. EXE or DLL files are only copied to the local
workstation if you request it in your installation. One possible caveat to
this is that Office 2003 has a few .NET optional extras (programmer support
IIRC) which have to be installed locally if you want them (because of the
way .NET Code Access Security works), although 99% of people probably don't.

AndyC

 

[AndyC]

Forgive me if I was mistaken.

Let me rephrase my understanding of your(MS) solution:

1- I put all the executable file as well as dll on the server to share with
other workstation without
copying any exec and/or dll file on the workstation.

Almost correct. You create an Administrative Install on the server with:

msiexec /a office.msi

This creates the correct folder structure for the server. No files are
copied to the workstation.

You then use the Office Custom Installation Wizard to configure the way you
want the Office installation done. In your case this would involve selecting
"Run from the Network" for all options. However it's perfectly valid to mix
and match if, for example, you wanted Powerpoint installed locally or
Outlook to install locally on first use etc.

You then save the .mst file in your server's shared office folder (referred
to from here on in as \\server\office)

2- I just create a shortcut and registry setting and voila I can ran the
office apps?
PS: I'd like to see the scripts that create those shortcut(don't need
the shortcut, I'd like to just
execute it directly from the network-attached directory) and
registry setting(what setting do
I need?)

Depending on your environment you can do this one of two ways:

1) If you have Active Directory, just create a GPO containing the Office
package with the .mst transform you created earlier and assign it to the
relevant Organisational Unit.

2) Alternatively, run the msiexec utility from a startup script or similar
method, again applying the relevant transform. Something like this should do
the trick:

msiexec /i \\server\Office\office.msi
TRANSFORM=\\server\Office\my_office_transform.mst /qb

This will create the appropriate registry information and Windows Installer
shortcuts for the setup you decided upon in your Custom Installation. If you
don't want the shortcuts you can always opt to omit them in your .mst file,
although I don't really see and advantage in that.

3- Just to be sure! NO INSTALLATION PROCESS ON THE WORKSTATION AND NO
EXEC and DLL files COPIED TO WORKSTATION?

Are those correct! If they are, please forgive me, but I can bet that was
not the case!

Yes that is correct. EXE or DLL files are only copied to the local
workstation if you request it in your installation. One possible caveat to
this is that Office 2003 has a few .NET optional extras (programmer support
IIRC) which have to be installed locally if you want them (because of the
way .NET Code Access Security works), although 99% of people probably don't.

AndyC

 

[Sarah Tanembaum]

Almost correct. You create an Administrative Install on the server with:

msiexec /a office.msi

This creates the correct folder structure for the server. No files are
copied to the workstation.

Sure, but you have to do this for all the workstation, is that correct?
Imagine if you have to do this install 1000+ times.
Why can I just install all the file in the server and executed in the
workstation.

Another thing is that it needs administrator installation, why? Again,
you are simulating workstation installation but using the network drive.
That's not the same thing.

You then use the Office Custom Installation Wizard to configure the way you
want the Office installation done. In your case this would involve selecting
"Run from the Network" for all options. However it's perfectly valid to mix
and match if, for example, you wanted Powerpoint installed locally or
Outlook to install locally on first use etc.

If this is a SMART and TRUE Network Apps, I will be able to execute the
apps as regular user where then I can customized whatever I want e.g.
location
of my personal template, my document directory, etc.etc.

And, it should not need an administrative priviledge! Again, if it does not
need
to copy or put something in the workstation, why administrative installation
has to be performed?

You then save the .mst file in your server's shared office folder (referred
to from here on in as \\server\office)

What happen if you have many users access it? How's the application manage
to
keep each user to its own space?

Depending on your environment you can do this one of two ways:

1) If you have Active Directory, just create a GPO containing the Office
package with the .mst transform you created earlier and assign it to the
relevant Organisational Unit.

Why do I have to go this trouble? I thought that all I need is install the
apps
in the file server, attach the drive to the workstation, and all users on
all
workstations can just execute the apps. No fuss.

What's so hard to do that? The point is that it is not necessary to even
need AD to control it, or GPO to control it. If you need to change
permission
on the file, change it on the server and all those 10000+ workstation can
see
it right away.

Again, you are avoiding the issues.

2) Alternatively, run the msiexec utility from a startup script or similar
method, again applying the relevant transform. Something like this should do
the trick:

msiexec /i \\server\Office\office.msi
TRANSFORM=\\server\Office\my_office_transform.mst /qb

This will create the appropriate registry information and Windows Installer
shortcuts for the setup you decided upon in your Custom Installation. If you
don't want the shortcuts you can always opt to omit them in your .mst file,
although I don't really see and advantage in that.

Oh my! How many more step that you have to do in the workstation?
I thought that you want to show me that nothing has to be done on the
workstation,
period.

This process is just as time consuming and prone to error as installing from
a pre-packaged
CD's 1000 times(all workstations).

Yes that is correct. EXE or DLL files are only copied to the local
workstation if you request it in your installation. One possible caveat to
this is that Office 2003 has a few .NET optional extras (programmer support
IIRC) which have to be installed locally if you want them (because of the
way .NET Code Access Security works), although 99% of people probably

don't.

AndyC, you got to admit there are room for major overhaul of how those
office apps
run and installed.

My point is, why can I just install the application in the file server and
execute that apps
in the workstation network drive! Its just as easy as that.

No administration headache.
Centralize apps administration
Patch and upgrade will be done only on the file server(instant upgrade for
ALL workstation)
And many other ....

 

[Sarah Tanembaum]

Almost correct. You create an Administrative Install on the server with:

msiexec /a office.msi

This creates the correct folder structure for the server. No files are
copied to the workstation.

Sure, but you have to do this for all the workstation, is that correct?
Imagine if you have to do this install 1000+ times.
Why can I just install all the file in the server and executed in the
workstation.

Another thing is that it needs administrator installation, why? Again,
you are simulating workstation installation but using the network drive.
That's not the same thing.

You then use the Office Custom Installation Wizard to configure the way you
want the Office installation done. In your case this would involve selecting
"Run from the Network" for all options. However it's perfectly valid to mix
and match if, for example, you wanted Powerpoint installed locally or
Outlook to install locally on first use etc.

If this is a SMART and TRUE Network Apps, I will be able to execute the
apps as regular user where then I can customized whatever I want e.g.
location
of my personal template, my document directory, etc.etc.

And, it should not need an administrative priviledge! Again, if it does not
need
to copy or put something in the workstation, why administrative installation
has to be performed?

You then save the .mst file in your server's shared office folder (referred
to from here on in as \\server\office)

What happen if you have many users access it? How's the application manage
to
keep each user to its own space?

Depending on your environment you can do this one of two ways:

1) If you have Active Directory, just create a GPO containing the Office
package with the .mst transform you created earlier and assign it to the
relevant Organisational Unit.

Why do I have to go this trouble? I thought that all I need is install the
apps
in the file server, attach the drive to the workstation, and all users on
all
workstations can just execute the apps. No fuss.

What's so hard to do that? The point is that it is not necessary to even
need AD to control it, or GPO to control it. If you need to change
permission
on the file, change it on the server and all those 10000+ workstation can
see
it right away.

Again, you are avoiding the issues.

2) Alternatively, run the msiexec utility from a startup script or similar
method, again applying the relevant transform. Something like this should do
the trick:

msiexec /i \\server\Office\office.msi
TRANSFORM=\\server\Office\my_office_transform.mst /qb

This will create the appropriate registry information and Windows Installer
shortcuts for the setup you decided upon in your Custom Installation. If you
don't want the shortcuts you can always opt to omit them in your .mst file,
although I don't really see and advantage in that.

Oh my! How many more step that you have to do in the workstation?
I thought that you want to show me that nothing has to be done on the
workstation,
period.

This process is just as time consuming and prone to error as installing from
a pre-packaged
CD's 1000 times(all workstations).

Yes that is correct. EXE or DLL files are only copied to the local
workstation if you request it in your installation. One possible caveat to
this is that Office 2003 has a few .NET optional extras (programmer support
IIRC) which have to be installed locally if you want them (because of the
way .NET Code Access Security works), although 99% of people probably

don't.

AndyC, you got to admit there are room for major overhaul of how those
office apps
run and installed.

My point is, why can I just install the application in the file server and
execute that apps
in the workstation network drive! Its just as easy as that.

No administration headache.
Centralize apps administration
Patch and upgrade will be done only on the file server(instant upgrade for
ALL workstation)
And many other ....

 

[Sarah Tanembaum]

Almost correct. You create an Administrative Install on the server with:

msiexec /a office.msi

This creates the correct folder structure for the server. No files are
copied to the workstation.

Sure, but you have to do this for all the workstation, is that correct?
Imagine if you have to do this install 1000+ times.
Why can I just install all the file in the server and executed in the
workstation.

Another thing is that it needs administrator installation, why? Again,
you are simulating workstation installation but using the network drive.
That's not the same thing.

You then use the Office Custom Installation Wizard to configure the way you
want the Office installation done. In your case this would involve selecting
"Run from the Network" for all options. However it's perfectly valid to mix
and match if, for example, you wanted Powerpoint installed locally or
Outlook to install locally on first use etc.

If this is a SMART and TRUE Network Apps, I will be able to execute the
apps as regular user where then I can customized whatever I want e.g.
location
of my personal template, my document directory, etc.etc.

And, it should not need an administrative priviledge! Again, if it does not
need
to copy or put something in the workstation, why administrative installation
has to be performed?

You then save the .mst file in your server's shared office folder (referred
to from here on in as \\server\office)

What happen if you have many users access it? How's the application manage
to
keep each user to its own space?

Depending on your environment you can do this one of two ways:

1) If you have Active Directory, just create a GPO containing the Office
package with the .mst transform you created earlier and assign it to the
relevant Organisational Unit.

Why do I have to go this trouble? I thought that all I need is install the
apps
in the file server, attach the drive to the workstation, and all users on
all
workstations can just execute the apps. No fuss.

What's so hard to do that? The point is that it is not necessary to even
need AD to control it, or GPO to control it. If you need to change
permission
on the file, change it on the server and all those 10000+ workstation can
see
it right away.

Again, you are avoiding the issues.

2) Alternatively, run the msiexec utility from a startup script or similar
method, again applying the relevant transform. Something like this should do
the trick:

msiexec /i \\server\Office\office.msi
TRANSFORM=\\server\Office\my_office_transform.mst /qb

This will create the appropriate registry information and Windows Installer
shortcuts for the setup you decided upon in your Custom Installation. If you
don't want the shortcuts you can always opt to omit them in your .mst file,
although I don't really see and advantage in that.

Oh my! How many more step that you have to do in the workstation?
I thought that you want to show me that nothing has to be done on the
workstation,
period.

This process is just as time consuming and prone to error as installing from
a pre-packaged
CD's 1000 times(all workstations).

Yes that is correct. EXE or DLL files are only copied to the local
workstation if you request it in your installation. One possible caveat to
this is that Office 2003 has a few .NET optional extras (programmer support
IIRC) which have to be installed locally if you want them (because of the
way .NET Code Access Security works), although 99% of people probably

don't.

AndyC, you got to admit there are room for major overhaul of how those
office apps
run and installed.

My point is, why can I just install the application in the file server and
execute that apps
in the workstation network drive! Its just as easy as that.

No administration headache.
Centralize apps administration
Patch and upgrade will be done only on the file server(instant upgrade for
ALL workstation)
And many other ....