Kenneth Skogstrand
asked on
SCCM SP2 r2 is locking folders under installation of deployed packages
Hi!
I got a potentially huge problem.
We recently discovered that under an installation of a deployed package to a computer, the c:\program files\<name of folder that installation creates> on the computer, is beeing locked. The installation hangs. msiexec.exe hangs. The installation will not proceed - or even fail.
Even though we have a timeout that says if an installation is not finished within 2 hour, SCCM should stop the installation, the installation still hangs. It could go on for days, if we don't manually stop it.
This recently happened for our Java and Adobe Reader packages that we deployed. This was for about 2 weeks ago.
This problem caused a lot of requests to our 1st line supportcentre.
What could cause this?
Best regards,
Kenneth Skogstrand
I got a potentially huge problem.
We recently discovered that under an installation of a deployed package to a computer, the c:\program files\<name of folder that installation creates> on the computer, is beeing locked. The installation hangs. msiexec.exe hangs. The installation will not proceed - or even fail.
Even though we have a timeout that says if an installation is not finished within 2 hour, SCCM should stop the installation, the installation still hangs. It could go on for days, if we don't manually stop it.
This recently happened for our Java and Adobe Reader packages that we deployed. This was for about 2 weeks ago.
This problem caused a lot of requests to our 1st line supportcentre.
What could cause this?
Best regards,
Kenneth Skogstrand
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Still monitoring the issue. I will post a new question about this problem later - if needed.
I have seen something similar that was caused by a captured OS that had the wrong permissions on Program Files. So when it was deployed installs to Program Files started to fail. Have you got a single basic build and if so have audited the source permissions of program files?
Our solution was to run a script that ran xcacls (via GPO I think) on effected machines to parse the folder and reset to default Microsoft permissions.
The problem is you have to find the source package that introduced the issue before you can apply the fix.
Mike