Deployment Solution

I have a bat file that is running an application's install silently. The app's install is using InstallShield.

When I manually run that bat file on some PCs the install run fines and the application is installed.

When I use Deployment Server > Job > Task

I get this error,
Error 1603 during script execution

So, I remove the silent install switches and deploy the task again,

And during the install this is shown,
Error 1327 Invalid Drive H:

But why? When I manually run the bat file, the install proceeds fine.

Side note: My "My Documents" is pointing to H:\ but this shouldn't matter, cause running the bat file manually, the install proceeds fine.

What's different about the Deployment Server task/environment?

Can I just skip this error code?

Okay, I edited the task so that it Continues on error 1603.
Indeed, the DS task continues, but the install is still failinng on 1327.

This is what's confusing. There's something different about the DS environment versus when I just run the bat file manually.

On the test client PC, I changed "My Dcouments" back to its default C:\Documents and Settings\<user>\My Documents and the install ran fine via DS task.

Unfortunately, most of our client PCs have "My Documents" targeted to their personal share (H:\) on the network. So, getting that to change back won't be practical.

When you are executing this task, are you logged into the target computer? You might adjust your script to map a drive prior to executing the install. You can then set it to disconnect the drive. See example below.

net use z: \\server\share /user:username password
z:\setup.exe (insert all of the switches and transforms here)
net use z: /delete

I wouldn't normally place software to be installed by DS in someone's "My Documents" folder. I would think it should be in a central location.

quote:

---

Originally posted by: bhawver
When you are executing this task, are you logged into the target computer? You might adjust your script to map a drive prior to executing the install. You can then set it to disconnect the drive. See example below.

net use z: \\server\share /user:username password
z:\setup.exe (insert all of the switches and transforms here)
net use z: /delete

---

Yes, in my tests when I manually run the bat file on the client PC I'm logged in. When I execute the same bat file via the DS task on the same client PC, it's executing as me. I have local admin rights on all our client PCs.

quote:

---

Originally posted by: bhawver
I wouldn't normally place software to be installed by DS in someone's "My Documents" folder. I would think it should be in a central location.

---

The bat file and install executable IS on a central location (network share).

If it is in a central area, you may try what I posted above about mapping a drive directly to that area, calling the batch file and then disconnecting the drive when it is done to see if that helps.

Thanks for the workaround. I'll test that if we decide to use DS task to deploy the app.

For now, I'm going to email a link of the bat file to users, so they can run the install.

1327 Logon failure: user account restriction. Possible reasons are blank passwords not allowed, logon hour restrictions, or a policy restriction has been enforced. ERROR_ACCOUNT_RESTRICTION

Perhaps you need to configure the job to run as an account that has rights to everyone's H: drive?

In reply to your other post that was locked --

You can't run tasks with the credentials as the current logged-on user.

If possible, I'd use a login script if I had to hit specific users' profiles.

Reason I ask about the run as whoever's logged in, is cause in Notification Server, Software Deployment, you can run a task as whoever is logged into the computer (or it'll wait till a user is logged in and then run the task). Thus, that will solve the 1603 error, if the DS task can run as whoever is logged in.

Ehh, I'm starting to hate DS software deployment. What I do like is that it let's me deploy right away versus with NS software deployment the client has to pull (check in) for it, it can't push out the deployment right away.

I'm running the task and having it run with my account. Guess what? The apps icons are under my Documents and Settings profiles instead of All Users. Arggh!!! Now, this might be the way the app's install behaves though, and has nothing to do with DS.

Edit: Further testing confirms it has nothing to do with DS. It's the way the app's silent install is installing. It's installing per user instead of for all users on the PC, and thus it's putting the icons under my account (since I'm running the DS task as me).

You can just run a script after the install to move the icons to the All Users profile.

Actually, IIRC, you can schedule an NS job to run as the logged-on user.

quote:

---

Originally posted by: Kai Mallea
Actually, IIRC, you can schedule an NS job to run as the logged-on user.

---

In DS? For NS, I know it can do that. I'm trying/testing with DS cause I want to utilize the deploy right away.

quote:

---

Originally posted by: Anthony Russo
You can just run a script after the install to move the icons to the All Users profile.

---

That will work.

I will have to revisit the app's silent install however; didn't realize it was installing per user by default instead of for anyone. Manually installing, clicking through it's wizard, it selects for anyone by default.

Or depending on the type of installer it is, ALLUSERS=1 should do a machine install if it is an msi.

More information on the 1603 error... This one is a real pain in my butt.

What happens when you install an application is that it tries to enumerate all the shell folder paths in the registry (HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders). If you (like me) change the My Documents mapping on the default user's profile, you are in for a headache.

The reason it works when you manually run it is because you generally have that drive mapped. The DS job fails because the specified user account doesn't run the login script to map those drives.

To get through this headache, I created a GPO that changes the My Documents path back to default when I log in with my Altiris service account. Granted, I have to log into each machine for the GPO to take effect, but once takes care of it forever. Over the course of time, I have logged into each machine on my network (>500 workstations and laptops) with this Altiris service account. It is part of our deployment instructions.

The moral of the story? There should have been better planning when implementing W2K and higher deployments. When we migrate off XP, I will carefully consider my options.