If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#51
|
|||
|
|||
Networked Office
"Sarah Tanembaum" wrote in message ... 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 |
#52
|
|||
|
|||
Networked Office
"AndyC" wrote in message
... "Sarah Tanembaum" wrote in message ... 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. 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? 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. 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). 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, 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 .... AndyC |
#53
|
|||
|
|||
Networked Office
"Sarah Tanembaum" wrote in message ... "AndyC" wrote in message 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. No. You do this on the server to unpack the installation structure from the compressed CD image. You only need to do it once. 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 want ordinary users to be able to install applications on the server? 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. Per-user settings can be configured by a user as usual. *Unless* an Administrator specifically restricts them to do otherwise. What happen if you have many users access it? How's the application manage to keep each user to its own space? Users files/settings are kept in their profile folder as usual. Have you ever actually used Windows? 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. It's hardly trouble, it takes approximately two minutes, regardless of whether you have 1, 10 or 10,000,000 workstations. The advantage of Active Directory is that you do not need to ever touch the actual workstation machines at all. They don't even need to be in the same country. Heck, they don't even need to exist yet, they'll pick up the settings when they are added to the Domain. 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. I haven't avoided any issues. You're either misreading what I said or really haven't got a clue how networked applications work on any OS. 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. What! That's one step. A single command. And only necessary if you aren't using Active Directory. How much less do you expect to do? Even a *nix based OS needs one command to mount a networked application drive for crying out loud. 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. That's what I just explained (several times) how to do. Why not try reading the posts instead of assuming you know better. 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 .... On the contrary. It's probably the one thing that Windows simply does better than any other operating system. If you really feel the need to slag it off, there are plenty of areas where Unix/Linux/Mac actually have a genuine advantage. If you'd ever run a large scale network, you'd know this already. I'm an administrator in a mixed Solaris/Linux/Mac environment, I do know what I'm talking about. AndyC |
#54
|
|||
|
|||
Networked Office
Andy,
I am quite confident that Sarah is not going to listen / accept anything that we suggest to her. I wonder what NOS / Application(s) she means. I am a big fan of Active Directory and really like what you can do with GPOs, whether making a couple - or lot - of configuration settings or deploying applications to either the user- or computer-side of things. I have never worked in an environment of more than 300+ users but can tell you that GPOs are a really big Administrative 'Extra Strength Tylenol'! Cary "AndyC" wrote in message ... "Sarah Tanembaum" wrote in message ... "AndyC" wrote in message 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. No. You do this on the server to unpack the installation structure from the compressed CD image. You only need to do it once. 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 want ordinary users to be able to install applications on the server? 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. Per-user settings can be configured by a user as usual. *Unless* an Administrator specifically restricts them to do otherwise. What happen if you have many users access it? How's the application manage to keep each user to its own space? Users files/settings are kept in their profile folder as usual. Have you ever actually used Windows? 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. It's hardly trouble, it takes approximately two minutes, regardless of whether you have 1, 10 or 10,000,000 workstations. The advantage of Active Directory is that you do not need to ever touch the actual workstation machines at all. They don't even need to be in the same country. Heck, they don't even need to exist yet, they'll pick up the settings when they are added to the Domain. 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. I haven't avoided any issues. You're either misreading what I said or really haven't got a clue how networked applications work on any OS. 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. What! That's one step. A single command. And only necessary if you aren't using Active Directory. How much less do you expect to do? Even a *nix based OS needs one command to mount a networked application drive for crying out loud. 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. That's what I just explained (several times) how to do. Why not try reading the posts instead of assuming you know better. 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 .... On the contrary. It's probably the one thing that Windows simply does better than any other operating system. If you really feel the need to slag it off, there are plenty of areas where Unix/Linux/Mac actually have a genuine advantage. If you'd ever run a large scale network, you'd know this already. I'm an administrator in a mixed Solaris/Linux/Mac environment, I do know what I'm talking about. AndyC |
#55
|
|||
|
|||
Networked Office
"AndyC" wrote in message ... "Sarah Tanembaum" wrote in message ... "AndyC" wrote in message 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. No. You do this on the server to unpack the installation structure from the compressed CD image. You only need to do it once. Okay, you unpack and and put them in the file server. 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 want ordinary users to be able to install applications on the server? I'm talking in the workstation. As you stated earlier, Administrator priviledge (on workstation) is needed to enable users in the workstation able to run the network apps, correct? As you can see, you can push the file or ask the workstation to run a script from AD, understood, but it overkill. All you need to do is a login script to set up a search patch for that apps executable and dlls. So, we do not have to spend on hardware(AD Server) and software(anoter Windows 2003 Server OS) to just push that apps -- I think this would simplify many things. 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. Per-user settings can be configured by a user as usual. *Unless* an Administrator specifically restricts them to do otherwise. Okay, understood. What happen if you have many users access it? How's the application manage to keep each user to its own space? Users files/settings are kept in their profile folder as usual. Have you ever actually used Windows? Yes, I have. 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. It's hardly trouble, it takes approximately two minutes, regardless of whether you have 1, 10 or 10,000,000 workstations. The advantage of Active Directory is that you do not need to ever touch the actual workstation machines at all. They don't even need to be in the same country. Heck, they don't even need to exist yet, they'll pick up the settings when they are added to the Domain. If you are talking WUS(Windows Update Services), it is not yet available (Information Week this week). 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. I haven't avoided any issues. You're either misreading what I said or really haven't got a clue how networked applications work on any OS. Let me rephrase it again: 1. There is an Apps called: AppsA 2. Install apps A in the server --- e.g: \\servername\appsdir\AppsA\ 3. UserXX in WorkstationY want to access AppsA 4. UserXX in WorkstationY type: \\servername\appsdir\AppsA\A.exe 5. Voila, UserXX is running AppsA in his/her WorkstationYY. In short, install appsA in the servername, and then 1000 users can access those apps in a blink by just typing \\servername\appsdir\AppsA\A.exe (he/she can create a shortcut anytime) When there are updates, all we need to do is update those AppsA in servername\appsdir\AppsA directory, and VOILA, all users/workstation see the update. 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. What! That's one step. A single command. And only necessary if you aren't using Active Directory. How much less do you expect to do? Even a *nix based OS needs one command to mount a networked application drive for crying out loud. In *nix, install apps in /usr/local/AppsA, automount /usr/local/AppsA in user workstation, then execute the /usr/local/AppsA/A.exe ... NOW user run the apps. When patch comes in, update the file(s) in /usr/local/AppsA. As soon as the patch finishes in the server, all the user can see the update right away. Nothing has to be run on the workstation! All the user has to do is to type in the command line: /usr/local/AppsA/A.exe (okay, they do not use .exe for executable extension). 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. That's what I just explained (several times) how to do. Why not try reading the posts instead of assuming you know better. Not exactly! And by the way, I do read all your comments. 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 .... On the contrary. It's probably the one thing that Windows simply does better than any other operating system. Sure! I think you know that is not true! So, I would not go there. If you really feel the need to slag it off, there are plenty of areas where Unix/Linux/Mac actually have a genuine advantage. If you'd ever run a large scale network, you'd know this already. Yes, I have. I'm an administrator in a mixed Solaris/Linux/Mac environment, I do know what I'm talking about. Same here. AndyC |
#56
|
|||
|
|||
Networked Office
Cary, I'm not that hard to convince if the solution is not a
patch-up/ducktape solution. There are many things that Windows need to learn from its brothers that has been running for large enterprises, doesn't it? May be not! Perhaps Windows is much more superior Sarah "Cary Shultz [A.D. MVP]" wrote in message ... Andy, I am quite confident that Sarah is not going to listen / accept anything that we suggest to her. I wonder what NOS / Application(s) she means. I am a big fan of Active Directory and really like what you can do with GPOs, whether making a couple - or lot - of configuration settings or deploying applications to either the user- or computer-side of things. I have never worked in an environment of more than 300+ users but can tell you that GPOs are a really big Administrative 'Extra Strength Tylenol'! Cary "AndyC" wrote in message ... "Sarah Tanembaum" wrote in message ... "AndyC" wrote in message 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. No. You do this on the server to unpack the installation structure from the compressed CD image. You only need to do it once. 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 want ordinary users to be able to install applications on the server? 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. Per-user settings can be configured by a user as usual. *Unless* an Administrator specifically restricts them to do otherwise. What happen if you have many users access it? How's the application manage to keep each user to its own space? Users files/settings are kept in their profile folder as usual. Have you ever actually used Windows? 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. It's hardly trouble, it takes approximately two minutes, regardless of whether you have 1, 10 or 10,000,000 workstations. The advantage of Active Directory is that you do not need to ever touch the actual workstation machines at all. They don't even need to be in the same country. Heck, they don't even need to exist yet, they'll pick up the settings when they are added to the Domain. 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. I haven't avoided any issues. You're either misreading what I said or really haven't got a clue how networked applications work on any OS. 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. What! That's one step. A single command. And only necessary if you aren't using Active Directory. How much less do you expect to do? Even a *nix based OS needs one command to mount a networked application drive for crying out loud. 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. That's what I just explained (several times) how to do. Why not try reading the posts instead of assuming you know better. 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 .... On the contrary. It's probably the one thing that Windows simply does better than any other operating system. If you really feel the need to slag it off, there are plenty of areas where Unix/Linux/Mac actually have a genuine advantage. If you'd ever run a large scale network, you'd know this already. I'm an administrator in a mixed Solaris/Linux/Mac environment, I do know what I'm talking about. AndyC |
#57
|
|||
|
|||
Networked Office
"Sarah Tanembaum" wrote in message ... If you are talking WUS(Windows Update Services), it is not yet available (Information Week this week). I never mentioned WUS. I was talking about Active Directory. Please don't put words in my mouth. Let me rephrase it again: 1. There is an Apps called: AppsA 2. Install apps A in the server --- e.g: \\servername\appsdir\AppsA\ 3. UserXX in WorkstationY want to access AppsA 4. UserXX in WorkstationY type: \\servername\appsdir\AppsA\A.exe 5. Voila, UserXX is running AppsA in his/her WorkstationYY. In short, install appsA in the servername, and then 1000 users can access those apps in a blink by just typing \\servername\appsdir\AppsA\A.exe (he/she can create a shortcut anytime) When there are updates, all we need to do is update those AppsA in servername\appsdir\AppsA directory, and VOILA, all users/workstation see the update. Which is precisely the scenario I've outlined. As Cary says though, you seem to completely refuse to either believe or understand a fairly trivial explanation. Contrary to your comments, Windows simply is more flexible than *nix based operating systems in this regard and all three of the scenarios suggested are officially supported configurations. Clearly you don't want to know that because you're happier living in your little bubble. I'd suggest you stick to *nix, put on your tin-foil hat and go back to reading /. You best leave us poor Windows admins to run round installing everything from floppy disk as that's the only way we can do it right? *plonk* AndyC |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Office 2003 / Office XP Shortcut Bar | Marc Bressman | Setup, Installing & Configuration | 6 | June 26th, 2004 08:42 AM |
Office 2003 / Office XP Shortcut Bar | Marc Bressman | General Discussions | 6 | June 26th, 2004 08:42 AM |
Productkey problem when installing office 2003 on network | Stefan Schreurs | Setup, Installing & Configuration | 1 | June 1st, 2004 11:16 PM |
Two versions again-language issue | Otto | Setup, Installing & Configuration | 3 | May 28th, 2004 04:57 AM |
Office 2003 and Office 2000/97 coexist on same PC? | John | General Discussions | 3 | May 6th, 2004 12:36 PM |