Office 2010 Deployment

(imported topic written by bendernet91)

I am planning to distribute the Office 2010 package to my enterprise using the Software Distribution Wizard in (BigFix)tem.

So far I failed in every attempt. I have copied the entire directory to a share on a server and created the .msp and placed this in the updates directory. My command line is such: setup \adminfile //server/share/office2010/updates/admin.msp

I choose this option:

Folder - Select a package folder (a compressed archive will be created). Also, Include subfolders is checked.

I noticed that on the client test workstation that only half the directories are copied. setup.exe , updates dir…etc and are copied but much of the directories are not copied. Bigfix console stated that it is still in a pending download state.

Looks as if its stuck with the copy job. Please help!

(imported comment written by SystemAdmin)

You’re in luck because I’ve been doing this lately too. You shouldn’t need to include the /adminfile switch I’ve found. The setup command will automatically use any MSP in the Updates folder.

As to the copy issue I don’t know what to do to resolve that. I created my installer using the Software Distribution site and not the typical Wizard. I haven’t had any issues with that side yet.

(imported comment written by bendernet91)

I requested the Tivoli Software Distribution site for evaluation. Still waiting (two weeks now) for the key to try this out from IBM.

I have the copy part working but executing it is not working in my task:

waithidden “C:\Temp\Setup.exe” /adminfile

It seems to launch Setup.exe but does nothing. I can run this manually from the command line and it installs fine.

(imported comment written by SystemAdmin)

Just have it do waithidden “c:\temp\setup.exe” and don’t include the /adminfile.

(imported comment written by bendernet91)

Cool! That worked just fine. Does it still read the admin file?

(imported comment written by cstoneba)

when I was working on deploying Office 2007, I found that there is a 2GB file size limit within the bigfix infrastructure. Not sure if that has been resolved in 8.x or not.

what I had to do was break up the install folder into smaller chunks, then extract those into a common folder and run the setup. It worked, but took a while to figure out.

(imported comment written by SystemAdmin)

Yes, if you include the admin file inside the Updates folder it automatically runs it as part of the install.

And my installer is only 693 Mb so I don’t have the size limit issue.

(imported comment written by SystemAdmin)

I am also in the process of setting up and testing an Office 2010 deployment package. However I’m trying, for the first time to use the Software Distribution Packages to house and maintain my source packages. I have created a package for the core install files and added my .msp config file as a second file. I have then created a task using the “Manage Tasks”. Rather than copy the .msp to the udpates folder to used setup.exe /adminfile file.msp. I did a test tinstall and everything seemed to install OK however the task seemed get stuck in a continous ‘Running’ state and never showed as complete. To help trouble shoot this I tried changed the “waithidden run.bat” to “run run.bat”. (I would also like to show the basic Office 2010 install interface to the users) However what I’ve noticed is that when using run.bat the task shows as “Fixed” as soon as the install kicks off rather than when it’s complete. Is there a way I can show/interact with the user but still have the task “wait” until the install is complete so I will actually know if the install completed successfully? Basically I need a “wait run.bat” rather than a “waithidden run.bat” Is that possible?

(imported comment written by SystemAdmin)

Follow-up question.

How does the run.bat file handle multiple installs?

Example, I have 3 msi files that I’ve uploaded under one package in the Software Distribution Package Library. I need to install the first .msi file, wait until that’s completed, install the second, wait until that’s completed then install the third.

However since the package library tasks seem to use this run.bat (I’m still not really sure why, isn’t the default path the __Download already???) how do I schedule these installs so that they happen one after the other and not all at the same time??

Can I simply skip the run.bat method and just revert to using the wait "{pathname of client folder of current site} & “__Download\file.msi” for each of the .msi files?

I don’t understand why you’re adding another whole layer of complexity by creating files to kick of installs etc rather than just using straight action script. It’s just asking for trouble and removes so much of the control!! Ahh the joys of IBM influence. Take something that is nice, simple, works well and over complicate it!!!

(imported comment written by SystemAdmin)

j2johnson - I brought up the .bat file issue when the Software Dist site went live. I do not like wrapping installs in .bat files as I agree with you that it just adds complexity and causes more problems. I love the concept of the Software Dist site and the recent update yesterday adds even more usefulness, but until they get rid of the .bat wrappers, I don’t think we will ever move to it.

(imported comment written by BenKus)

Hey guys,

The problem is that the default folder is NOT the __Download folder… and this can break some custom installers… So we had a choice to make:

  1. Add a new agent feature to run an action in a different working directory

  2. Use a bat script wrapper to change the folder before running the action

The problem with #1 is that it wouldn’t be reverse compatible so people would have to upgrade to the latest version to use SWDist… and we didn’t want to do that so we chose option #2

It seemed like the batch script adds minimal complexity… are you seeing something not work because of the batch script? (you can always edit the script manually if you want…)

Ben

(imported comment written by SystemAdmin)

Follow-up issue/question. How is relevance language handled in the .bat file processing?

In my case I like to output the a log of the .msi install to a network location and I use {hostname} as part of the log file name so that there is one log for each computer. Example:

\server1\installlogs$\ProductName{hostname}_Product_inst.log

Will this still work in the .bat file?

(imported comment written by SystemAdmin)

Network drive access is limited by the job being run as the system account. So you need to set up a Null Session share from memory or have BigFix save the file locally and you can bring the logs back via an analysis.

Is anyone having issues with the AutoActivate setting? My deployments aren’t autoactivating and ServiceDesk want me to have something run to apply this. I’ve added the key in the Customisation but its obviously not working.

(imported comment written by SystemAdmin)

Another issue with the .bat file. It seems that when running the .bat file as the current user

(run “{pathname of download folder}\RunAsCurrentUser.exe” run.bat)

Once the .bat file kicks off the install it then believes the task is complete and begins clearing out the files copied to the _Download directory!

In my case I have a big install (office 2010) and I need to setup a taks that installs Office as the user and presents the basic display. (for machines in which the default silent install fails) However once the .bat gets executed, and the MS office install window pops up, the BigFix status window says the task is complete and begins clearing out the _download folder causing the install to fail!!

(imported comment written by SystemAdmin)

Ouch, I very rarely call my installs using the .bat file. I usually just change it to call my installer directly.