Resiliency and reinstall features not working properly

[glhs]

Hi there,

We are working on a Office 2003 rollout using a the MSI package with MST assigned to computers and controlling it by OU.

The problem I am having is unpredictable behavior when it comes to bringing an unmanaged (manual) Office 2003 installation into a managed state. Sometimes it will completely uninstall Office 2003 and install the new package, yet most other times it shows in the application log that "The reinstall of application Microsoft Office Professional Edition 2003 was successful." yet features of our MST are not applied such as attached files, registry keys, settings.

The other problem I have seen is that the application is not resilient like advertised. If the user removes the GP-installed program application through the control panel it does not come back on reboot (does not even attempt an install per the app evt log) and there is no obvious way to get the package installed for a user without manually running a MSIEXEC command line, which puts the package in an unmanaged state. It should be noted that all users at our company do have administrative rights.

Does anyone have any ideas on this? I have enabled usermode, MSI and appmgmt logging before but never really seem to find any information to go on from that. Does anyone think there should be some answers in those logs, and if so can you recommend any good sources for information regarding evaluating those logs.

[AdamV]

I've never really thought that resilience should imply that it will get put back if it is properly removed via control panel - I simply take it to mean that if you just delete or change an exe or dll for example, that it gets repaired. That said, it would make sense your way.

I guess this app has been assigned to a set of users (by OU)?
Could you run a logon script to remove the manual version (via MSIExec) so it is already gone when the managed one installs? You would need to use a flag file or reg key to indicate this had been done so the script only runs once and does not keep uninstalling, or include this as part of your custom MST so the script says "if this reg key exists, this is my managed install, so don't run"

I think the failure to update the installation is an MSI/MST issue, not strictly GP, since you say the event log reports that it tried (and thinks it succeeded) to update the install so the GP is clearly doing something. Have you tried running your new installation straight over an existing installation? How does the behaviour compare to the GP method (event log, actual settings that take effect etc.)

One thing to try if the new network install point is in the same place as where you installed the unmanaged one from (this is probably a bit of a PITA but worth it even if just to eliminate something) - copy the installation point to a different path and apply a new GP pointing at that one, link to a test OU with a machine that has the old unmanaged suite on and see what it does.

(an aside - what is stopping you from getting users to run without being local admins?)

[glhs]

Thanks for the reply, I will try manually installing the MSI in the system instance to see if this happens as well with just my MSI. I would be you are correct though that this is a MSI problem and not a GP problem.

As for the resiliency, I got my feeling from this Microsoft page:
http://office.microsoft.com/en-us/assistance/HA011402011033.aspx

Which reads:
"Assigning Office to computers
Assigning Office to computers is the simplest way to use Group Policy to manage a package as large and complex as Office 2003. With this method, Office is installed on the computer the next time the computer starts and is available to all users of the computer.

Assigned applications are resilient. If a user removes an Office application from the computer, Windows automatically reinstalls it the next time the computer starts. Users can repair Office applications on the computer, but only an administrator can remove applications."

I would think that this function would be very dependent on group policy, but don't even see it trying to reinstall itself. If "only an administrator can remove applications" how is one ever supposed to get a GP installed Office back if it's removed by a local user with admin rights?

Thanks again for the advice though..

I've never really thought that resilience should imply that it will get put back if it is properly removed via control panel - I simply take it to mean that if you just delete or change an exe or dll for example, that it gets repaired. That said, it would make sense your way.

I guess this app has been assigned to a set of users (by OU)?
Could you run a logon script to remove the manual version (via MSIExec) so it is already gone when the managed one installs? You would need to use a flag file or reg key to indicate this had been done so the script only runs once and does not keep uninstalling, or include this as part of your custom MST so the script says "if this reg key exists, this is my managed install, so don't run"

I think the failure to update the installation is an MSI/MST issue, not strictly GP, since you say the event log reports that it tried (and thinks it succeeded) to update the install so the GP is clearly doing something. Have you tried running your new installation straight over an existing installation? How does the behaviour compare to the GP method (event log, actual settings that take effect etc.)

One thing to try if the new network install point is in the same place as where you installed the unmanaged one from (this is probably a bit of a PITA but worth it even if just to eliminate something) - copy the installation point to a different path and apply a new GP pointing at that one, link to a test OU with a machine that has the old unmanaged suite on and see what it does.

(an aside - what is stopping you from getting users to run without being local admins?)

[glhs]

(an aside - what is stopping you from getting users to run without being local admins?)

Lol. Been there, done that, had terrible results and had to bail out in a hurry. We had an exception list which was created because some departments had custom applications which wouldn't function properly unless the user was a local admin. Pretty soon our exception list became a vast majority of the users.

[AdamV]

...but only an administrator can remove applications."

If "only an administrator can remove applications" how is one ever supposed to get a GP installed Office back if it's removed by a local user with admin rights?

problem is, there is no difference between what you call an administrator and a user with admin rights. These are exactly the same as far as MS and OS are concerned.

I understand your frustration with apps that don't work unless users have admin rights - been there! Usually this is caused by badly written apps trying to store user-specific data in the registry under HKLM or in ini files (contrary to guidlines since about 1985!). So you can often get roudn these problems by identifying exactly where the problem lies and then applying specific permissions to fix the problem.

Two very useful tools to try and work out what is going on are filemon and regmon - you install them and run, then (try and) do something - they will show what files and registry entries are accessed (or attempted). This may be all you need to give suitable permissions to the "authenticated users" group (ideally not "everyone") so that things work.

If you still can't fix them all, then you should at least try to make the systems as secure (especially against malware) as possible by making sure that users only have admin rights on their own local system and not across to other systems. To do this, add the NT\Interactive user to the local admins group rather than a domain-level group such as Auth Users. So they only have rights on the machine they log in to and no other. Damage limitation!

Post back when you have a chance to test the MSI, and if that does not work as it should we can try to work out what else to try!

[glhs]

[Post back when you have a chance to test the MSI, and if that does not work as it should we can try to work out what else to try!

Thanks for the advice, yes, I tried again running the msiexec in an /interactive cmd.exe window (system context) and I do get the same behavior, no changes made. I used verbose MSI logging and can't seem to pointpoint anything particular, but I am noticing (possibly a red herring) a "SMARTSOURCEDIR" value that is a non-existant share. Looking through the CIW I can't imagine where this path is coming from, but at least this takes GP out of the picture for my unmanaged-to-managed installations.

Thanks again, cheers.