Deploying Office 2K Across the WAN
Novell Cool Solutions: Trench
Digg This -
Posted: 24 Jan 2001
Current version: ZENworks for Desktops 3
In a recent Q&A we ran the following question:
Question: Paul R. wrote: This is in response to Tim Crabbs' article on Office 2000 deployment using ZEN 2.0. He's right on the money.
Everything works perfectly with one hitch. Typically I create application objects at our main site and then replicate the files to the servers at our remote sites.
All of our users across the WAN share a common drive mapping of N: which maps to a NAL directory on their respective servers. This is where I push the application files to.
Here's my problem. It appears that even though I've used the N:\Office2k\ path for the Office Custom setup wizard and %server% (a login script set environmental variable for the local server at each site)in the NAL object itself, Office is looking across the WAN for the install files instead of running from the local server.
I've tried adding the other servers in the additional servers section of the MST file, to no avail. It seems as long as the primary installation point server is available it will try to run from there, no matter how slowly.
At the home office this takes 10 minutes or less. Running across the Frame relay WAN takes at least 30 minutes. I'm still in the pilot program for this and haven't rolled it out company wide yet, but that's coming soon.
Do you have any suggestions other than running the initial admin setup on each server?
Answer: Tim Crabb is engrossed in another Novell technology right now, and is unavailable for comment. Anyone out there got some suggestions?
Here's what we got so far. If you think of anything else that might shed some light on this hot topic, please let us know.
- David W. Cooney
- Richard Harvey
- Nick Still
- Cliff Bowes
- Rik Hepworth
- Debbie Carraway
- Stan Schwartz
The reason that your application is continuing to install from the original server is because that server is hard-coded in the AOT file used to create the application object. What I did to resolve this problem was the following.
After copying all of the snAppShot files to the new server, edit the AXT file at the new location and modify the reference to the source server. Make sure that all references to the original server have been changed to the new server.
Create a new application object for the users of the new server from the AXT file. The result is the same exact installation that you originally captured with snAppShot but it will now pull the files from the new server rather than from the original.
Regarding Paul R.'s question on deploying Office 2000 across a WAN, this is something which I will shortly be undertaking myself.
My question is why do you need to set a server variable at all? If all users are using the same path on the respective servers, this should be sufficient to allow the installation on each site.
The way I had intended rolling this out was to copy my existing administrative installation of Office 2000 at our main site to the remote server, then configure separate Office application objects for that location. Office can then be installed on the workstations in exactly the same way as the main site, with the only changes necessary being those to the File Rights assigned through the application object for the installation of Office, and the associations.
If you have any questions you may contact Richard at firstname.lastname@example.org
One thing that immediately comes to mind is the SOURCE_PATH macro. If a UNC path was used when creating the application object, it may still be pointing to the server of origin. This is often an issue when duplicating application objects from one server container to another. Change the SOURCE_PATH macro to reflect your local server drive path mapping (N: in this case) instead of the UNC path format which is pointing users across the WAN to access the source files.
Although it was obvious to me, I could not tell from Paul's question that this had been addressed. I beg your pardon if you've already made this adjustment!
If you have any questions you may contact Nick at NickStill@sti.synovus.com
Hope this is of some help. I found when I installed Office 2K to a mapped drive (in my case m:\office2000 = \\server-name\Vol1:\apps\office2000) I had a similar problem. After using regedit and doing a search for the original UNC install path I found a number of the Office 2K registry keys still pointed to the UNC path of the server rather than m:\office2000.
Ref Paul R.'s question about Office 2k and installation paths, I believe what he's referring to are called Source Pointers.
A good source of information on MSI installation issues is the Desktop Engineers Junk Drawer. On this site, under the Windows Installer section you will find a VB script called msisources which lets you repoint the source paths for MSI-based installations on your workstation. Using this, he should be able to change the path for Office to be drive-based rather than UNC. I think there are tools to list MSI installed apps and find paths etc, but I'm not certain.
There is also another site, called InstallSite which has some resources and information which may be useful.
If you have any questions you may contact Rik at R.M.Hepworth@Bradford.ac.uk
One thing to check is whether the MSI script itself is using the mapped drive rather than a UNC path. There is a Microsoft Knowledgebase article Q228574 that describes this. Basically there is a setup.ini file (flagged hidden) in the source location for the Office files. You'd want to make sure that the [MSI] section of the SETUP.INI file lists N:\Office2k\ rather than the UNC path.
If you have any questions you may contact Debbie at email@example.com
I'm wondering if you might have used a UNC path, when doing the administrative install of O2k, instead of using the drive letter. If so, maybe the msi file (or whatever file Microsoft uses) has the server name in it.
Just a thought. Hope this helps.
I have also used ZEN (1.1) to deploy Office 2000 Pro using the 'dynamic duo of distribution' article. It seems I used exactly the same method you describe in you Question. If you would be so kind to send me the AXT file (not AOT), MST files, OPS files and some screen dumps of the Application object(s) you made to distribute the app, I could probably help you out.
One first possiblity is that you have forgotten to check the MACRO tab of the original application object. Although you have installed using a common drive mapping, ZEN sometimes translates this to UNC anyway. By doing so, the UNC path woud also refer to the SERVER (!), making it always go across the WAN. Another possibility is that you have used UNC paths in the MSI/MST/OPS files (or they are translated somehow to UNC) you created.
If you have any questions you may contact R.C. at firstname.lastname@example.org
Posted January 31, 2001
The information Tim posted is an excellent starting point and right on the money. However, has anyone successfully distributed using ZEN/MSI on Windows NT without Admin Privileges?
Launching and running the App works great for me. It's after the reboot that my attempts fail because it complains that an admin user has to finish the installation. I've installed MS's Windows Installer Files as per KB Article Q231611, applied the polices through a workstation and user policy package extensible policies to enable InstallElevated per Jimmy Benson's cool advice. (Jimmy Benson has information in a From the Trenches article entitled; Distributing Office 2000 for Dynamic Access.) Nothing, Notta, Zip... I cannot get past the reboot. Can anyone please help?
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com