/build/static/layout/Breadcrumb_cap_w.png

"Not enough storage is available..."

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

Answers (11)

Posted by: Kungfus0n 16 years ago
Senior Yellow Belt
0
Just to get this rolling, does double clicking the file on said machine work? How about the temp directories, maybe clean them out?
Posted by: aogilmor 16 years ago
9th Degree Black Belt
0
the costfinalize section of the log should give some clues.
Posted by: JdotQ 16 years ago
Senior Purple Belt
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.
Posted by: anonymous_9363 16 years ago
Red Belt
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?
Posted by: JdotQ 16 years ago
Senior Purple Belt
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. [:)]
Posted by: anonymous_9363 16 years ago
Red Belt
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?
Posted by: JdotQ 16 years ago
Senior Purple Belt
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??
Posted by: anonymous_9363 16 years ago
Red Belt
0
What is there to lose? Export the key to a .REG beforehand, just in case.
Posted by: JdotQ 16 years ago
Senior Purple Belt
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?
Posted by: JdotQ 16 years ago
Senior Purple Belt
0
Just wanted to bump this to see if anyone else had any ideas or suggestions?
Posted by: jmcfadyen 16 years ago
5th Degree Black Belt
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.
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ