Software Deployment

Never heard that a package is locked during install from remote and don't think that is the problem.
Why do you think it is locking?

During initial install the package is cached down to the client and run locally.

Well I can view what machine has the file open while its installing. When its installing I can try to access it from a different machine, but I get "access is denied, make sure the source exists, and you have access to it". Once the machine finishes installing though it works fine. Only durring the install does it lock like this. I can watch for it to finish, and once it removes the file access it will work for the next machine.

So I am pretty sure its locking the file. Would REINSTALLMODE=AMUS create the type of behavior?

The REINSTALLMODE property value shouldn't be the bad guy in this scenario.
Could you enable verbose logging on the client that gets the package installed and see if you find anything that may hint you of the issue.
Also ProcMon could provide you more information why this happens.

Would it be possible for you to upload the verbose log file + the procmon log for us to have a look?
Please do not post the whole log if you decide to do so.

Not sure how to get those. I tried to enable Verbose logging for xp http://support.microsoft.com/kb/906485, but not sure if this is what your looking for. I never found a procmon log either.

How to enable Windows Installer logging
http://support.microsoft.com/kb/223300

I was looking in the temp folder and I found this.

The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2356. The arguments are: FSP222_2.cab, ,
=== Logging stopped: 5/1/2008 14:27:07 ===

I just enabled the Installer logging though so I will try to run it again, and see if it will give me anything else.

Here is the verbose logging for the MSI.

=== Verbose logging started: 5/7/2008 10:24:33 Build type: SHIP UNICODE 3.01.4000.4039 Calling process: \??\C:\WINDOWS\system32\winlogon.exe ===
MSI (c) (98:10) [10:24:33:909]: Resetting cached policy values
MSI (c) (98:10) [10:24:33:909]: Machine policy value 'Debug' is 0
MSI (c) (98:10) [10:24:33:909]: ******* RunEngine:
******* Product: {695cdc6b-5d7c-409f-8a09-a713f5bc24ff}
******* Action:
******* CommandLine: **********
MSI (c) (98:10) [10:24:33:924]: Client-side and UI is none or basic: Running entire install on the server.
MSI (c) (98:10) [10:24:33:924]: Grabbed execution mutex.
MSI (c) (98:10) [10:24:33:924]: Cloaking enabled.
MSI (c) (98:10) [10:24:33:924]: Attempting to enable all disabled priveleges before calling Install on Server
MSI (c) (98:10) [10:24:33:940]: Incrementing counter to disable shutdown. Counter after increment: 0
MSI (s) (C4:F8) [10:24:34:236]: Grabbed execution mutex.
MSI (s) (C4:18) [10:24:34:236]: Resetting cached policy values
MSI (s) (C4:18) [10:24:34:236]: Machine policy value 'Debug' is 0
MSI (s) (C4:18) [10:24:34:236]: ******* RunEngine:
******* Product: {695cdc6b-5d7c-409f-8a09-a713f5bc24ff}
******* Action:
******* CommandLine: **********
MSI (s) (C4:18) [10:24:34:236]: Machine policy value 'DisableUserInstalls' is 0
MSI (s) (C4:18) [10:24:34:236]: Setting cached product context: machine assigned for product: b6cdc596c7d5f904a8907a315fcb42ff
MSI (s) (C4:18) [10:24:34:236]: Using cached product context: machine assigned for product: b6cdc596c7d5f904a8907a315fcb42ff
MSI (s) (C4:18) [10:24:34:236]: Using cached product context: machine assigned for product: b6cdc596c7d5f904a8907a315fcb42ff
MSI (s) (C4:18) [10:24:34:236]: Using cached product context: machine assigned for product: b6cdc596c7d5f904a8907a315fcb42ff
MSI (s) (C4:18) [10:24:34:236]: Using cached product context: machine assigned for product: b6cdc596c7d5f904a8907a315fcb42ff
MSI (s) (C4:18) [10:24:34:236]: Using cached product context: machine assigned for product: b6cdc596c7d5f904a8907a315fcb42ff
MSI (s) (C4:18) [10:24:34:236]: Using cached product context: machine assigned for product: b6cdc596c7d5f904a8907a315fcb42ff
MSI (s) (C4:18) [10:24:34:252]: User policy value 'SearchOrder' is 'nmu'
MSI (s) (C4:18) [10:24:34:252]: User policy value 'DisableMedia' is 0
MSI (s) (C4:18) [10:24:34:252]: Machine policy value 'AllowLockdownMedia' is 0
MSI (s) (C4:18) [10:24:34:252]: SOURCEMGMT: Media enabled only if package is safe.
MSI (s) (C4:18) [10:24:34:252]: SOURCEMGMT: Looking for sourcelist for product {695cdc6b-5d7c-409f-8a09-a713f5bc24ff}
MSI (s) (C4:18) [10:24:34:252]: Using cached product context: machine assigned for product: b6cdc596c7d5f904a8907a315fcb42ff
MSI (s) (C4:18) [10:24:34:252]: SOURCEMGMT: Adding {695cdc6b-5d7c-409f-8a09-a713f5bc24ff}; to potential sourcelist list (pcode;disk;relpath).
MSI (s) (C4:18) [10:24:34:252]: Using cached product context: machine assigned for product: b6cdc596c7d5f904a8907a315fcb42ff
MSI (s) (C4:18) [10:24:34:252]: SOURCEMGMT: Now checking product {695cdc6b-5d7c-409f-8a09-a713f5bc24ff}
MSI (s) (C4:18) [10:24:34:252]: SOURCEMGMT: Media is enabled for product.
MSI (s) (C4:18) [10:24:34:252]: SOURCEMGMT: Attempting to use LastUsedSource from source list.
MSI (s) (C4:18) [10:24:34:252]: SOURCEMGMT: Processing net source list.
MSI (s) (C4:18) [10:24:34:252]: SOURCEMGMT: Trying source \\domain.com\SysVol\domain.com\Policies\{488E6781-6E21-48E5-BBEE-5C5924FE9A97}\Machine\Applications\.
MSI (s) (C4:18) [10:24:34:408]: Note: 1: 2203 2: \\domain.com\SysVol\domain.com\Policies\{488E6781-6E21-48E5-BBEE-5C5924FE9A97}\Machine\Applications\app.msi 3: -2147287035
MSI (s) (C4:18) [10:24:34:408]: Note: 1: 1706 2: -2147483646 3: app.msi
MSI (s) (C4:18) [10:24:34:408]: SOURCEMGMT: Processing media source list.
MSI (s) (C4:18) [10:24:34:424]: SOURCEMGMT: Trying media source D:\.
MSI (s) (C4:18) [10:24:34:424]: Note: 1: 2203 2: D:\app.msi 3: -2147287038
MSI (s) (C4:18) [10:24:34:424]: SOURCEMGMT: Source is invalid due to missing/inaccessible package.
MSI (s) (C4:18) [10:24:34:424]: Note: 1: 1706 2: -2147483647 3: app.msi
MSI (s) (C4:18) [10:24:34:424]: SOURCEMGMT: Processing URL source list.
MSI (s) (C4:18) [10:24:34:424]: Note: 1: 1402 2: UNKNOWN\URL 3: 2
MSI (s) (C4:18) [10:24:34:424]: Note: 1: 1706 2: -2147483647 3: app.msi
MSI (s) (C4:18) [10:24:34:424]: Note: 1: 1706 2: 3: app.msi
MSI (s) (C4:18) [10:24:34:424]: SOURCEMGMT: Failed to resolve source
MSI (s) (C4:18) [10:24:34:424]: MainEngineThread is returning 1612
MSI (c) (98:10) [10:24:34:455]: Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied. Counter after decrement: -1
MSI (c) (98:10) [10:24:34:455]: MainEngineThread is returning 1612
=== Verbose logging stopped: 5/7/2008 10:24:34 ===

I found this interesting.
http://kb.acresso.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=Q107140&sliceId=

From what I got out of it is that when you choose reinstall mode, and the package does not have a source it bombs with a similar error to the one I am getting. Now I am forcing the MSI to run in repair mode by setting REINSTALLMODE=AMUS. So maybe I need(have) to figure another way to force the MSI to overwrite files.

Am I reading that wrong? Iv been working on this for a week, and I would really like to get it figured out.
.

Actually there is a source, but while its being read by another system it cannot be accessed. Is this a problem with the compressed MSI, or the Windows Installer, or just a property that needs set on the MSI?

Ding! Ding! I think we have a winner!

http://support.microsoft.com/kb/889710

AD prevents exclusive locks on the the file. So why does this MSI require an exclusive lock when all the other MSI packages we have in the sysvol folder seem to work without issue?

I found some posts while searching for your error:
Is the ResolveSource action sequence?
Does the system account have access do the MSI?

Where are you storing the package (ex. \\server\share\folder\packge.msi) which you deploy through GPO?

"authenticated users" have access to the share. I have also tried adding "domain computers" just to make sure, but it didnt change anything.

The share is \\domain.com\SysVol\domain.com\Policies\{488E6781-6E21-48E5-BBEE-5C5924FE9A97}\Machine\Applications\

The system has access to the .msi when its the only system accessing the file. Once more than one computer is accessing the file ie trying to installing the app at the same time all except one of them has this problem, and fails.

If I try to access the file directly with Orca while a computer is installing the application I get "The installation package cound not be opened. Verify that the package exists, and that you can access it, or contact the application vendor to verify that this is a valid Windows Installer package." Once the computer is finished installing the app I can access the file with Orca fine.

KB889710 says that the sysvol share prevents exclusive locks, but we have other MSI packages stored in the sysvol that dont have this problem. That would indicate that our other MSI packages dont get an exclusive lock. What would cause this MSI to lock the package?

At all my customers we have never used the sysvol share but used a regular share as \\server\share or \\server\share\folder.
When you import the MSI through GPO it will be stored in the sysvol share by default so my guessing is that it's conflicting in some how.
So what happens if you do not import the MSI directly from the sysvol share?

The you assign software via GPO it creates an .AAS file with the URL to the MSI package. I just place the MSI in the same directory where that .AAS file goes.

What I dont understand is why the other MSI packages we have (26 total) work fine, and still they are all in the SysVol folder with the .AAS file.

Ill create a new GPO with the MSI on a different server, and see what happens.

Sorry but can't tell you why or why not it does not work while storing the package in the sysvol share as I've never done it.

Well I tested this by placing the msi on a DFSR share, and it worked fine. I can edit the file with Orca while the app is being installed on a system so the file is not being locked in that case. Why the msi file is being locked on the SysVol share for this app, and not others is a mystery to me.

My only guess would be that someone/something has the file open as read before you do or the deployment thus preventing the installation with success.

ORIGINAL: AngelD
At all my customers we have never used the sysvol share but used a regular share as \\server\share or \\server\share\folder.FWIW, my thoughts exactly.

There is no way on God's earth that I would place files for deployment on SYSVOL. The rule of thumb is to have one server for one job or, at an extreme pinch, one drive/partition for one job.

Irrespective of whether or not other MSIs don't exhibit this behaviour, you're storing up trouble for yourself here. Keep the AD stuff on its own and move your deployment shares to another server/share.

ORIGINAL: AngelD
When you import the MSI through GPO it will be stored in the sysvol share by default I don't think it does, does it?. I'm pretty sure that all that gets 'stored' are the advertising files: the GPO's msiFileList attribute points to the MSI's actual location.

I don't think it does, does it?. I'm pretty sure that all that gets 'stored' are the advertising files: the GPO's msiFileList attribute points to the MSI's actual location.
You're correct Ian!
I was just thinking about when you replaced an (updated) MSI for an already imported one you had to re-create the GPO package for the updated MSI to have any affect. I guess this is due to the AAS file needs to be re-generated, right?

I was thinking about your application you wrote regarding importing package to the GPO. I'm in the process of creating a similar one for my self in C#, would it be possible to have a peek on your code and if so PM me and we'll take it from here.

Cheers!

ORIGINAL: AngelD
I guess this is due to the AAS file needs to be re-generated, right?Correct, yes.

I'll PM you a link to the script and DLL, no problem.

Hi Justin,
interesting thread.
To shed some light on your mystery:
When i look at your logfile and the KB-article,
i think, this depends on how the source files are stored.
Do you have the Cab-files in this particular MSI?
Look at the packages, which are functioning. They most likely have the files outside of the MSI.
Regards, Nick

that is interesting, being a 1612 though I would be more inclined to think its not locked but more so that it cant be found.

this happens alot with Novell deployments too. From a Novell perspective I found granting computer accounts access to the deployment share helped alot. Although I have not encountered or tested this too much with GPO deployment is it perhaps possible the machine account is being used to access the share not the user account ?

Actually storing the files in the SysVol has never been an issue. It’s never caused any problems with AD or anything like that.

This particular MSI has the cab files in the MSI. I guess that could have something to do with it. We have other MSI packages that have the files stored in the MSI, and they work without issue though.

A sample of MSI with all the files in the MSI:
Adobe Flash Player 9 install_flash_player_9_active_x.msi
Adobe Shockwave Player sw_lic_full_installer.msi
Citrix ICA Client 9.20 ica32pkg.msi

Some MSI packages that have the files outside the MSI:
Adobe Reader 7.0.8
MS Access 2000 Runtime
MS Office 2003 Pro
MS Office 2003 Std
MS Visio 2003

None of those have any problems installing on multiple systems simultaneously.

Well I decompressed the MSI, and it seems to work now. Ill do some more testing just to make sure, but its not being locked while the package is being installed so at least in my initial testing multiple systems have been successful at installing the package simultaneously.