Hello,

I've created a package which drops some MS Word template files into the templates directory (C:\Program Files\Microsoft Office\Templates\1033)

Installing this package via double-clicking the MSI works fine.

When adding the package to AD Group Policy to deploy computer side, it does not install, and adds the following to the application log;

Event Type: Error
Event Source: Application Management
Event Category: None
Event ID: 108
Date: 6/20/2007
Time: 3:58:59 PM
User: NT AUTHORITY\SYSTEM
Computer: COMPUTER1
Description:
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 : Not enough storage is available to complete this operation.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.


Followed by this in the application log;

Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1085
Date: 6/20/2007
Time: 3:58:59 PM
User: NT AUTHORITY\SYSTEM
Computer: COMPUTER1
Description:
The Group Policy client-side extension Software Installation failed to execute. Please look for any errors reported earlier by that extension.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.


This does not happen on all the computers, just a few random ones.

I'm not sure if it's an issue with the package itself or the way Group Policy is handling it? Anyone have any ideas? Searching around has not supplied any info...
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
Just to get this rolling, does double clicking the file on said machine work? How about the temp directories, maybe clean them out?
Answered 06/20/2007 by: Kungfus0n
Senior Yellow Belt

Please log in to comment
0
the costfinalize section of the log should give some clues.
Answered 06/20/2007 by: aogilmor
Ninth Degree Black Belt

Please log in to comment
0
ORIGINAL: Kungfus0n

Just to get this rolling, does double clicking the file on said machine work? How about the temp directories, maybe clean them out?

Yes, double clicking the file does work, it goes through and installs properly with no errors. I'll try to clean out the temp directory's and see what the result is, but I think it's hard to imagine that 40gb+ isn't enough space for a 2mb msi package ;)


ORIGINAL: aogilmor

the costfinalize section of the log should give some clues.

I'll rerun the install with full logging on and post any odd sections under costfinalize.

Thank you both for the suggestions.
Answered 06/20/2007 by: JdotQ
Senior Purple Belt

Please log in to comment
0
I've only encountered using GP for deployment at my current client and, on the two occasions where I've seen this behaviour here, it has been fixed by simply removing the package and adding it back again. Makes no sense, of course, but what does in this dark world we inhabit?
Answered 06/21/2007 by: VBScab
Red Belt

Please log in to comment
0
Clearing the temp files/folders does not resolve the issue.

I enabled verbose logging via GPO to capture the logging during install (since it's appointed computer side, rather than user side) and I'm unable to find the log anywhere on the system [&:] So that would tell me that the install is not even getting initialized to start installing?

ORIGINAL: VBScab

I've only encountered using GP for deployment at my current client and, on the two occasions where I've seen this behaviour here, it has been fixed by simply removing the package and adding it back again. Makes no sense, of course, but what does in this dark world we inhabit?


Good suggestion. I'll take it out and add it to a separate group policy. It's odd that the same package in the same group policy works on several other machines, but on a few others, it generates this error.

Back to testing.

Thanks again for all the suggestions. [:)]
Answered 06/21/2007 by: JdotQ
Senior Purple Belt

Please log in to comment
0
I presume you checked that the policy was being applied to the rogue users/machines? Is it profile-dependent? That is, if th euser logs on to a different machine, does the install run OK?
Answered 06/21/2007 by: VBScab
Red Belt

Please log in to comment
0
ORIGINAL: VBScab

I presume you checked that the policy was being applied to the rogue users/machines? Is it profile-dependent? That is, if th euser logs on to a different machine, does the install run OK?

Yea, I doublechecked everything -- the GPO is being applied to the computer. It's being applied computer-side, so the user logging in is irrelevant. It applies (and installs) successfully to other computers, so I'm not so sure it's a package issue -- maybe something flaky with that specific client.

I came across this from EventID.net (http://eventid.net/display.asp?eventid=108&eventno=1181&source=Application%20Management&phase=1)
ORIGINAL: EventID.net

- Error: "Not enough storage is available to complete this operation" - From a newsgroup post: "I've seen this problem reported a few times. This is caused when some of the appmgmt client's local state gets “corrupted” (for unknown reasons). You should also see a message something like this in the log: "Cannot initialize the data structure for local script <GUID>". The GUID will highlight the identifier for the app which is causing the trouble. It's failing out because a registry subkey can not be found. This was considered something that would indicate a catastrophic failure somewhere, which is why the lame out of memory error code was chosen (because we figured it would never be hit anyway). Possible way to fix this is to find the troubling key. This will be under HKLM (computer policy) or the user's HKCU key (user policy) Software\\Microsoft\\Windows\\CurrentVersion\\Group Policy\\Appmgmt\\<GUID>.
It's failing because one of these named values under that key is not present: "Deployment Name", "GPO ID", "GPO Name", and “Product ID". All of these are the bare minimum the client code needs to proceed. One remedy is to simply remove the <GUID> key. The appmgmt client will forget about the app in that case. Or you could fix up the missing value (all reg_sz) manually".

I noticed on the troubled machine, that the registry contains a GUID for an older package (no longer in use, or in any deployment GPO's) which this current package is supposed to upgrade. If I understand this correctly, if a package is not in a GPO, it should not appear in the HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Group Policy\Appmgmt\<GUID> location?? If this is true, maybe I should remove the older GUID which is no longer present in the GPO -- maybe this is causing it to snag during the install/upgrade process??
Answered 06/21/2007 by: JdotQ
Senior Purple Belt

Please log in to comment
0
What is there to lose? Export the key to a .REG beforehand, just in case.
Answered 06/21/2007 by: VBScab
Red Belt

Please log in to comment
0
So I removed the key from the registry which had the old outdated package info. But it still results in the same behavior (not installing, same two event logs as posted above, no verbose log anywhere). Hmmm...back to the drawing board.

Anyone with any ideas?
Answered 06/21/2007 by: JdotQ
Senior Purple Belt

Please log in to comment
0
Just wanted to bump this to see if anyone else had any ideas or suggestions?
Answered 06/24/2007 by: JdotQ
Senior Purple Belt

Please log in to comment
0
why not just put the templates into a shared location and set the share workgroup templates setting on your office installation.

after all thats what it was designed for.
Answered 06/24/2007 by: jmcfadyen
Fifth Degree Black Belt

Please log in to comment
Answer this question or Comment on this question for clarity