Deploying Office 2003 on Terminal Services 2003

M

Mark Wilson

I'm about to start a multiple server installation with Windows 2003 Server (Terminal services) and Office 2003, but am having trouble seeing the wood for the trees.

Of interest is using an administrative install to aid ongoing management of a 6 server thin client infrastructure. Obvious complications with the install characteristics of MSO on TS, and that is about where I get lost. Is doing an administrative install in this environment actually achiveable or practical ?

Also I anticipate using the Custom Installatin Wizard, MSI & MST files and also want to plan ahead for the best way to deal with Patch management and deploying them. So far I've studied the ORK, TechNet and numerous other white papers from Microsoft but have not found one source that really glues the whole lot into a coherent methodology.

How have you done it?, Do you have any technical reference guides ?

(e-mail address removed)
 
A

Arie Heinrich

Hi Mark,

One thing I didn't understand is whether are you trying to create your
AdminPoint(AP) on the TS ?

You don't have to and I would suggest against it. You can create an AP on
every computer you want,
even you personal one and later copy the entire AP to a new location as long
as you keep the structure the same.

After the AP is ready and you set your settings right, using the MST, logon
to the TS with Admin rights, preferably
logon locally or to Console and not via the TSClient itself and then from
the Add/Remove programs run the install.
To get best options ins case of patching, on the TS map a drive (that will
be mapped later to all users) to the
location of the AP and run the setup from there.

This is usually how I do it and have done in multiple office projects.
(I have placed at the end several sources of info for reference).

Starting point - Ref 1

Short How-to:
Create the following folder structure on any PC...use your own pc to save on
network latency as you are moving
300-500 MB over the wire.

Apps\Office\Office2003 -> the Apps will be the root for the share.

Run the setup /a command and browse to the Office2003 folder you just
created.

Run the ORK tools and create you flavor of MST, place it in the Office2003
folder.

If you are going to install any MUI packs for different languages, create a
subfolder for each one, under the Office2003
folder -> this is for security benefits, especially as this folder will be
shared so the security will be inherited down to
the folder structure. MS recommend using the LCID as the folder name, I just
name if after the language as its much
easier to remember :)

You can now create you're own flavor of MST for the MUI and place it in the
MUI folder. -> Remember that in the CIW,
you have to choose the appropriate MSI file on which you'll be creating the
MST, the MUI msi, for example, will usually
be called lpk.msi or similar.

If you wish to chain the installation of both the office and MUI, you'll
have to edit the setup.ini file in the office2003\setup folder.
Be ware, that unlike previously work, the paths in the ini are essential to
the correct install so they should reflect the
share structure and drive letter you'll be using.

You can build several MST files depending on its purpose, there are some
features that do not work or are known to cause problems
that are better shut via the MST that on a normal pc would be working very
well. Fortunately for you and me the number of failures in
TS install has dropped considerably since off2k, where you needed a special
MST for installing. Now the install mechanism is mart
enough to know what to drop out of the install if it detects a TS is
present.

Choosing which MST to use, is something you can set in multiple setup.ini -
like files accompanied by several batch files that run setup
with a different setup.ini-like file. (ref 2 and 3)

At this point copy your AP to any server you want that will or is used as
your file server for deploying or hosting other applications...this is why
I used the Apps as the folder root, as long as the MSI of office is at the
third level deep / or at least 2nd level deep from the shared drive
point of view - again security benefits.

On the TS server, map a drive letter, or if you have one that is usually
mapped to the 'Apps' folder as your general mapping schema,
and run the installation.

This should be it.

As for patching, choosing the AP method of install, means you'll have to d/l
the Admin Patches (usually bigger in size), run them on
the AP and then send a command line (login scrip is usually the best way) to
the clients to update/re-cache the existing office file with
the update bits (Ref 4 and 5).


I thinks this is enough to give you a good start, were allways here for more
of you're questions :)

Take care,

Arie H.
MS MVP



Please read the following articles for more info:

1. Deploying Office 2003 in a Windows Terminal Services Environment
http://www.microsoft.com/office/ork/2003/two/ch5/DepD06.htm

2. Customizing How Setup Runs
http://www.microsoft.com/office/ork/2003/two/ch4/DepB03.htm

3. Setup Command-line Options - look at the /Settings switch
http://www.microsoft.com/office/ork/2003/ref/RefA01.htm

4. Distributing Office 2003 Product Updates - look for the 'Distributing
full-file administrative updates'
and 'Updating clients from a patched administrative image' sections.
http://www.microsoft.com/office/ork/2003/five/ch18/MntA01.htm

5. Office 2003 Editions Administrative Updates
http://www.microsoft.com/office/ork/2003/admin/default.htm


View the following webcast for more info:
Support WebCast: Deploying Office 2003 In A Terminal Server Environment
http://support.microsoft.com/default.aspx?kbid=832752




Mark Wilson said:
I'm about to start a multiple server installation with Windows 2003 Server
(Terminal services) and Office 2003, but am having trouble seeing the wood
for the trees.
Of interest is using an administrative install to aid ongoing management
of a 6 server thin client infrastructure. Obvious complications with the
install characteristics of MSO on TS, and that is about where I get lost. Is
doing an administrative install in this environment actually achiveable or
practical ?.
Also I anticipate using the Custom Installatin Wizard, MSI & MST files and
also want to plan ahead for the best way to deal with Patch management and
deploying them. So far I've studied the ORK, TechNet and numerous other
white papers from Microsoft but have not found one source that really glues
the whole lot into a coherent methodology.
 
P

Patrick Rouse [MVP]

Mark, I've installed Office 2000, XP & 2003 this way and
it works well.

Place your Administrative Installation Point on a network
share (setup -a), create any MST you need to customize
your install (with CIW) then run the setup from the TS
Console (or mstsc /console), using "change user /install"
or "Add/Remove Programs".

DriveLetter:\AIPShare\SETUP.EXE
TRANSFORMS=DriveLetter:\LocationOfMST\TransformName.MST /qb
-

To patch the TS you'll need to apply the updates (MSP or
full SPs) to the Administrative Installation Point, then
recache the install on each of the TS.

http://www.microsoft.com/office/ork/xp/one/depb11.htm


Patrick Rouse
Microsoft MVP - Terminal Server
http://www.workthin.com

-----Original Message-----
I'm about to start a multiple server installation with
Windows 2003 Server (Terminal services) and Office 2003,
but am having trouble seeing the wood for the trees.
Of interest is using an administrative install to aid
ongoing management of a 6 server thin client
infrastructure. Obvious complications with the install
characteristics of MSO on TS, and that is about where I
get lost. Is doing an administrative install in this
environment actually achiveable or practical ?.
Also I anticipate using the Custom Installatin Wizard,
MSI & MST files and also want to plan ahead for the best
way to deal with Patch management and deploying them. So
far I've studied the ORK, TechNet and numerous other
white papers from Microsoft but have not found one source
that really glues the whole lot into a coherent
methodology.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top