Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Newbie question re: application deployment 3

Status
Not open for further replies.

andrew2000

Technical User
Oct 28, 2004
39
US
Hi All,
I am a wanderer from Microsoft land and happen to have come across a 700 computer (Win XP) enterprise that happens to have the ZEnworks client installed on all of the workstations.

My job is to remotely deploy Office 2003 to all of them (they currently have Office 2000).

I have been reading the Zenworks 6.5 Suite Admin's Handbook, which has been quite helpful.

I have created a working package based on a .MSI and a .MST. I have gotten it to the point that it puts an Office 2003 icon on the users desktop and they can double click it to install, works great.

Here is my question: I want to install it on all the PC's at night, without user intervention. Sort of a forced install. Is it possible to do this with Zenworks?

I haven't found any helpful info in the manual on this one. I have read it several times and am familiar with most of the options.

Thank you!

Andrew
 
Read what Marv posted for you, but also remember, users do not always read the email, post it notes, flyers, memos, neon signs, smoke signals telling them to leave their PC's on over night to perform this push. Be sure to read up on the wake on LAN scheduler functions, and bring lots and lots of asprin ... or a hammer to beat your self in the head. Novell's implementation of WOL scheduler is pretty poor, it works, but it is confusing. You can set the schedule to wake the PC, but you also have to set the schedule for the server to read the schedule to wake the PC's (this is were we all go.. huh?)

Be sure to enable the logging features. Test before deploy on this, logging to the NAL database does not always work out of the box. I find logging to file works best, just be sure to give users read, write, create, and file scan rights (workstation objects in this case).

The application will be workstation not user accociation, and all workstations that need it must be imported into your directory. Installing as an unsecure or secure system user is a very important option to look at.

BTW, if your ZfD server agents run on a Windoze box, let me know, there is more to it if you are.

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Brent Schmidt Certified nut case [hippy]
Senior Network Engineer
 
Thanks, I'll read this today and post back. We have Netware servers so there really isn't any Windows involvement except the workstations.

Andrew
 
We are in the process of deploying Office 2003 Standard and Professional to all of our users. I have found that you will need the MS Office 2003 Resource kit (From Microsoft) This has an option (Custom Install Wizard) to run through the Office install where you can configure all the options (which apps to install etc) and create an MST file to run with SETUP.exe (There are command line options which are also needed, but it informs you what to do at the end of the Install wizard). Then create an application object in ZEN (Simple NO MSI or MST) point it to the SETUP.exe and add the command line options.

In the resource kit there is also an option to 'grab' the settings from Office into a profile file which can be used in the install for menu options etc.

We have also found that if this is installed for one user, and another user logs into the PC the office profile settings are lost for the new user - we think it is an issue with the NTUSER.DAT fie - we are still looking into this.

Hope this helps

Simon.
 
Simon,

using the command that you get at the end of the ORK MST Wizard works fine and dandy, but you then loose the ability to make your office app self healing. Right Click - Verify is an awsome feature of ZfD that you esentially loose doing an MSI install using a simple app object creation. If you use the MSI app object creation, you can make the application self healing and get all the functionality of using the command line you get at the end of ORK. It is actualy easier IMPO to use the MSI app object, and link the MST file with in it, then link the service packs, and tie in the desired profile. I greatly enjoy telling my customers to Right Click - Verify when ever they contact me about an app issue. No silly remote console to up the app version number to force a redeploy to repair a broken app.

Your method may work for your enviroment, but it is not best practice and is prone to issues not present in the MSI app object.

On your problem with profile settings getting lost .... um, actually they arn't lost, they never exsisted in the first place. Windows makes a user profile for every user ID that logs in. If you set it up so all of your users used the same workstation user ID, then you would not run into this problem. But doing so is not best practice, you want individual user ID's on the local PC. The solution to your problem is to look into using the MSI app object and creating a self healing application. This way, when a new user logs into the PC, they can do the good old Right Click - Verify and the MSI technology will find that the app is already there. Instead of deploying the entire app it will only check the files (by defualt, you can set it up to do a full deploy on verify). In the end, you got your profile data.

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Brent Schmidt Certified nut case [hippy]
Senior Network Engineer
 
To add to what Brent said, you can essentially setup an MSI app to deploy MS OFfice 2003 in 5 minutes. Point to the MSI, add the MST,and then add the patch file for SP1 and you're all done. As big of an application that it is, it's one of the easiest to deploy. Rule of thumb, if you have an MSI file, use it. don't try to reinvent the install process.

Marvin Huffaker, MCNE
 
That does sound the best way to do it, I am going to re-look at my application setup in ZEN and see how I go.

Thanks for the tips Marvin & Brent.

Simon.
 
Hey Guys,
I read through the document and still haven't found the answer.

Is it possible to deploy it to the workstation with no user intervention at night? (so the user doesn't even have to click an icon or login so that FORCE RUN would take effect?)

I want to deploy it to all of my systems overnight and have it ready for the users when they come in the next day.

None of the docs have covered this so far, I would think with an application as powerful as Zenworks it has to be possible.

Thanks,
Andrew
 
hmm, your right, the documentation is pretty poor on scheduled deployments.

Your looking for "Scheduler". With in the app object you are given a scheduling option. You need to set this to time the deployment.

This is the best I can find in the Novell documentation that goes over what you need to do.


This book is pretty good an has better information ofr administrators.

Novell's documentation is more tailored for the intergrator.

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Brent Schmidt Certified nut case [hippy]
Senior Network Engineer
 
The concepts you need to know are covered in that documentation. As you can imagine, what you are trying to do can get rather complex. Brents post covers quite a bit.. There just isn't one setting that does it all in one fell swoop. There are several bases you must cover, and you will probably need to do some testing before you try to do it in production.

Some of the things you need..
apps associated with workstations
wake-on lan (assuming systems are off)
working import policy and workstations registered in tree
etc

I probably missed a few things..


Marvin Huffaker, MCNE
 
Wow guys, thanks for the info.

I've read that section at least 4 times and it took you guys to point out that the pre-install is what I want to do.

I guess I thought that pre-install was just going to cache the files on the system.

I'm glad that's how I setup my 3 test workstations today. I set them up to preinstall tonight, so we'll see how that goes. I was just thinking that would precache the files.

All of my workstations are registered in the tree, and I know how to associate them and all of the systems are on 24/7.

Thanks for the information, I'll report back with results.

Andrew
 
I have now changed the Office deployment to use the MSI file with the transform (MST) file, this works great! I have a couple of questions though. When the application is clicked in the application explorer window it begins to cache the application to the local workstation even though it is not set to cache. The other thing is that I am trying to install the Remove hidden data MSI file via the post install scripts tab in the application object, I set the script engine to be msiexec.exe and add the path to the msi file in the post install section (above) but all I get it the help screen for the Windows Installer?

Any ideas.

Thanks

Simon.
 
Not sure on your MSi script, never used MSI scripting in that fashion before.

I like using AutoIt for all of my scripting needs, much easier to deal with.

On the caching, do you have any of the preinstall options set?


Also, try this, you'll like it. Go into the run options and change it from install only to running an executable. Point the executable to the office app you want to run (like C:\Prograqm Files\Microsoft Office\Office\winword.exe for example). Leave the rest of the setup as it is. Just change the association to deploy a desktop icon. Now, when the user click on the icon, the app will be deployed. If the app is already deployed, it will just run it. If the app fails to load, the system will ask you if you want to redeploy it (just delete the exe to test this and see it work). Also, if the user as any issues, they just right click - verify and the app will redeploy fixing most of the app problems you will run into.

For Office 2000, you will need to create individual app object for each office app to make this work right, however, the back end will point to the same thing for all (this is because of the way MSI tech works). However in Office 2003 and XP, M$ gave you the option to create MSI files for each app, so you can have seperate installs for each app (and is much easier to understand in some cases).

Granted, you can only do this if you have an enterprise version of the office app. OEM will not allow you to create an admin install point making this whole thing a bit difficult.

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Brent Schmidt Certified nut case [hippy]
Senior Network Engineer
 
Hey Guys,
Unfortunately the preinstall route didn't work. When the user got in, he launched Outlook and it was still 2000, not 2003. He was able to double click the icon though, which launched the installer which finished the install ok.

Don't know what to do from here, any other ideas would be appreciated.

Andrew
 
Ok, I think you have a big misunderstanding about how to place the icons for these applications. It's what I consider one of the biggest misundstandings people have with ZEN.. If I understand it correctly, you have a standard Outlook shortcut on your desktop, quicklaunch, etc.. doesn't matter. It's a standard icon, not a zen icon. It's what the original Outlook install put there.

Using that is not going to do anything for you. Since it's not a ZEN icon, it's not controlled by ZEN and never will be.

The way to do it is replace the standard icons with ZEN icons. Then you can control the behavior of the launch, install, update, whatever.

As a rule of thumb, when I create an MST (transform file), I go in and remove all the entries for shortcuts. I take them off the startmenu, off the desktop, everywhere. I don't want the install program cluttering up my start menu and desktop. When I'm done, the application is installed, but you wouldn't know it just by looking at the start menu because there are no icons.

Instead, I place a ZENworks icon for the same application instead, and then I can control every aspect of it through ZEN. For example, I would create the Outlook 2003 application, associate it with my container or group of users, and place it on the desktop, startmenu, and quicklaunch bar (if you want to mimic the standard install behavior).. The only difference users see is the Red arrow instead of Black, but then when they launch it, it will do what it is supposed to. You will then find that you can get the application to behave the way you would have expected it to.

Also, speaking of placing zenworks icons on the startmenu, make sure you look up the topic of "FOLDERS" to help you organize the apps you put on the start menu.

I hope this helps and doesn't confuse you any worse.

Marvin

Marvin Huffaker, MCNE
 
Sorry, I should have been more clear. The icon they click on is in fact a Zen icon. When they click it it installs Office 2003 for them.

What I want to happen is to totally remove the user intervention, so that Office 2003 installs without any input from them.

The tricky part is that I want it to happen at night. Otherwise I could use FORCE RUN and have it install when they login.

What I think I am going to try now is a combination of FORCE RUN and PRE INSTALL. Hopefully if I use FORCE RUN it will forcibly install the software at night during it's pre install.

Thanks,
Drew
 
should be set to force run if you want the timed install to work

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Brent Schmidt Certified nut case [hippy]
Senior Network Engineer
 
Ok guys, thanks for your help. I have it sort of working.

I set it up to be available at night, with force run and run once selected, and associated it to some workstations.

One of them worked. The others did not.

Now that I have the concept down, I need to figure out why some of them aren't working. I setup reporting to dump a log file on my desktop with failures and successes in distribution, hopefully that will help.

Andrew
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top