Software install failing

  • Thread starter Thread starter Rob Oldfield
  • Start date Start date
R

Rob Oldfield

I use GPOs to roll out software in msi files. Generally works very well but
I currently have one user who it's not working for. No real error message
in his event log when it fails... just 'it failed'.

The particular machine (Win 2K) that he uses was originally mistakenly
formatted as FAT and I think the failures have started since I converted it
to NTFS. I've switched auditing on the machine for file access permissions
being denied and that shows a failure to read c:\winnt\4RTFTG6GHTYU653 type
folders. He has read permissions on c:\winnt and if I create a new folder
in there then he also inherits the read rights. If I push him up to be a
domain admin then the installations succeed.

Any ideas?
 
Rob-
I suspect it is a permissions issue, where that folder under winnt is trying
get created during install but the user has insufficient privileges to
create and write to that folder. I take it you are using user-based software
installation rather than machine-based? Can you compare permissions on this
machine vs. one that is working and just set them equivalent?
 
The permissions seem to be the same. machine\users have Read & Execute,
Read and List Folder Contents rights. And yes, the installation is user
based.
 
I wonder why the install is trying to write a folder under c:\winnt then?
One thing you might want to try is to enable verbose Windows Installer
logging and see what errors are getting thrown. You can enable it using the
policy User Configuration|Administrative Templates|Windows
Components|Windows Installer|Logging. It will write a log file called
msi*.log to the user's %temp% folder for each install that is run. In there,
you should get a detailed picture of which file create is failing.

--
Darren Mar-Elia
MS-MVP-Windows Server--Group Policy
Check out http://www.gpoguy.com -- The Windows Group Policy Information Hub:
FAQs, Whitepapers and Utilities for all things Group Policy-related
 
......aaaah. Now that looks good. I'd seen verbose logging mentioned
before but never figured out where it was enabled. I'll report back with
the results....
 
There again.... maybe that's why I've never been able to find it. Under
Windows Installer I just have 'Always install with elevated privileges',
'Search order', 'Disable rollback' and 'Disable media source for any
install'. No 'Logging'. Am I missing an adm?
 
OK. Managed to figure out how to turn the logging on from here
http://support.microsoft.com/?kbid=246509

appmgmt.log is showing nothing useful....

"The following 4 managed applications are currently applied to this user.
UTMSetup (2) from policy Cut with state 511 and assign count 1.
trafficSetup from policy traffic with state 511 and assign count 1.
ADMOutputSetup from policy ADMOutput with state 511 and assign count 1.
FeeShape from policy FeeShapes with state 511 and assign count 1.
Found 0 applications locally that are not included in the set of
applications from the Active Directory.
Failed to apply changes to software installation settings. Software changes
could not be applied. A previous log entry with details should exist. The
error was %5.

Software installation extension returning with final error code 5."

but userenv.log is more interesting....multiple repeats of the following
lines....

"USERENV(5d0.5d8) 09:18:37:340 LoadUserProfile: Failed to impersonate user
with 5.
USERENV(a8.cc) 09:20:14:392 ProcessGPOs: Extension Application Management
ProcessGroupPolicy failed, status 0x5."

I have of course tried searching for these errors but haven't found anything
useful.
 
Rob-
Going back to your previous response--rats! Sorry, I meant Computer
Configuration|Admin Templates|Windows Components|Windows Installer|Logging.
That logging will likely be much more verbose than appmgmt.log. Error 5 is
an Access Denied error. It could mean that the permissions on the share
where the MSI is are inaccessible to the user.
--
Darren Mar-Elia
MS-MVP-Windows Server--Group Policy
Check out http://www.gpoguy.com -- The Windows Group Policy Information Hub:
FAQs, Whitepapers and Utilities for all things Group Policy-related
 
Nooooooooo!!!!!! I hate computers sometimes.

So.... I switched on the verbose logging as per your suggestion.... got the
user to log out and back in and no log file was generated. Went back and
removed the earlier registry change I'd made to generate the appmgmt.log
file and granted users write access to c:\winnt\temp.... got the user to log
in again.... and the bleeding software installed correctly!!!!

So maybe it was just that the user needed write access to the temp
folder.... but when it was failing the auditing wasn't showing any failures
related to that folder... so it makes no sense to me.

Anyway.... I'll keep an eye on it and post again as and when it falls over
again.

Many thanks for your help.
 
Back
Top