DS 6.9 SP3 Deployment Error 1603 with Windows 7

[Migration User]

I have read far too many articles regarding Error 1603 when deploying tasks to Windows 7 machines. We have global package servers where applications for distributions reside and we have always been successful in Windows XP. Now in Windows 7 most work but a large number of them fail with Error 1603.

I've read:

Disable UAC
Disable Firewall
Disable IPv6
Run without command line switches (/qb, etc)
Enable verbose mode
Run them manually (which really defeats the whole purpose of having a DC)
Use the System Account (which has no rights to a server share)
Run in Console User Session (which works, but is not a solution)

and on and on.................

If I deploy a job through the console as follows:

\\%SITE%\<Server Share Path>\Programs\Adobe\Adobe Flash Player 10.0.42.34\install_flash_player_10_plugin.msi

(with "Run in Quiet Mode checked" and "Run Directly from Source" with the appropriate credentials specified) the job works fine in Windows XP but Errors with 1603 in Windows 7

If I run the exact command line as follows:

logged in as myself using Start > Run and entering "\\%SITE%\<Server Share Path>\Programs\Adobe\Adobe Flash Player 10.0.42.34\install_flash_player_10_plugin.msi" /qb

It runs without prompts or errors.

Could this be a Dagent problem or something else I've not considered? All I know is some jobs using the same manner and command lines work through DS and some don't and Error with 1603.

There has to be a common element because I see enough articles regarding this problem with no ONE solution.

[Migration User]

In addtition:

Windows 7 -

If I am logged on "using any user credentials" and then launching the DS task (with appropriate credentials) the job works!

If I log off the machine and launch the exact same job it fails. So there must be something with being logged out when the error 1603 occurs.

[Migration User]

I've found some stuff on the Internet that says some people get this error because of the location of the My Documents or even if you are using an account that has never logged in before (i.e. the profile has not been created) (which sounds closer to your problem).

The batch file probably runs fine because you are logged in at the time and the profile was already created.  Have you tried making the job run as a specific user that has logged into the machine before (i.e. the local administrator account)?

Error 1603 is a very generic MSI installer error with common problems being that the program is already installed, a file that it needs to overwrite is in use, etc.

[Migration User]

I have tried creating a profile for the "altiris" account on the local machine first (yes, thank you for the suggestion). To my knowledge there is no direct connectivity between the My Documents folder and "Adobe Flash" (I could be wrong though) and I've narrowed it down to being logged off and the error occuring.

[Migration User]

Since I was slightly convinced this may have to do with the Agent I tried this. I removed Dagent and re-installed Aclient and guess what all those jobs that errored with the 1603 errors now work fine.

[Migration User]

Do you have the DAgent installed in your image, then sysprep and capture. Then recieving the 1603 errors after the image is deployed to new hardware when trying to install new software? I only ask because I too am plagued with 1603 errors and I am trying to figure out the cause.

[Migration User]

No we do not have agents in the sysprepped image capture. They are installed post imaging. I've disabled firewall and the Error 1603 does not prompt for one application, but fails with 1603 on a different one. I've altered UAC settings, Firewall settings, Local Software Roles in GPeditor, etc and so on and so on. No one solutions appears to work.

I do know that one way that appears to work consistantly. Create a deployment job and set the parameters to "Run in Console User Session" while the computer is logged on with a domain account that has privileges to wherever you are remotely installing from. Now it works. I've narrowed most of my 1603 errors down to The job works when a user is logged on but fails if the deployment is to a machine logged off. 

[Migration User]

Working with Symantec support there is now a resolve to this problem. I believe this will appear in DS 6.9 SP4 but for now we have tested the following KB article and it resolved our problem. We no longer have to run jobs as "Run in logged in Console User Session".

kb.altiris.com Article ID: 49390 KNOWN ISSUE: Cannot run tasks against Vista systems when the task credentials differ from the logged-on user.