Invalid drive when running psexec/msiexec
I am trying to install an application remotely (CA Unicenter DSM Agent + plugin) using the following command:
(This is to both XP and Server 2003 machines x86 only)
psexec \\ipaddress -c AMSD.bat
or
psexec @file.txt -c AMSD.bat
My AMSD.bat file contains the following:
@echo off
net use y: /d
net use y: \\computername\sharename /user:domain\username PASSWORD
msiexec /i Y:\AgentAM_ENU\agtsd.msi /quiet /norestart
c:
cd c:\prog*\CA\dsm\bin
REM Set Scalability server address agent needs to register with.
caf setserveraddress ipaddress
net use y: /d
:end
echo "Done"
I do not receive any errors on the cmd window, instead the remote machine has this in the event log:
Event Type: Error
Event Source: MsiInstaller
Event Category: None
Event ID: 11327
Date: 12/3/2009
Time: 10:29:45 AM
User: contoso\doe.john
Computer: Server111
Description:
Product: CA Unicenter DSM Agent + Software Delivery Plugin -- Error 1327.Invalid Drive: H:\
Our 'My documents' is redirected to a network location per AD/GPO to the H: drive but nothing else.
I checked out error 11327 on EventID's site and the suggestion to was check/modify registry settings to make sure the programs location was not pointing to H:. I confirmed that none of the program location paths were pointing to H: but as expected anything related to My Documents is pointing to H: as well as Local AppData %userprofile%\local settings\application data.
Although I have the perms to do so, it is not a viable solution for me to modify the registry on 1000+ machines. I am able to install this app if I login to a machine and run the msi locally (or from a share) but thats not ideal either.
Any help to get past this 'Invalid Drive" error is greatly appreciated.
thanks
(This is to both XP and Server 2003 machines x86 only)
psexec \\ipaddress -c AMSD.bat
or
psexec @file.txt -c AMSD.bat
My AMSD.bat file contains the following:
@echo off
net use y: /d
net use y: \\computername\sharename /user:domain\username PASSWORD
msiexec /i Y:\AgentAM_ENU\agtsd.msi /quiet /norestart
c:
cd c:\prog*\CA\dsm\bin
REM Set Scalability server address agent needs to register with.
caf setserveraddress ipaddress
net use y: /d
:end
echo "Done"
I do not receive any errors on the cmd window, instead the remote machine has this in the event log:
Event Type: Error
Event Source: MsiInstaller
Event Category: None
Event ID: 11327
Date: 12/3/2009
Time: 10:29:45 AM
User: contoso\doe.john
Computer: Server111
Description:
Product: CA Unicenter DSM Agent + Software Delivery Plugin -- Error 1327.Invalid Drive: H:\
Our 'My documents' is redirected to a network location per AD/GPO to the H: drive but nothing else.
I checked out error 11327 on EventID's site and the suggestion to was check/modify registry settings to make sure the programs location was not pointing to H:. I confirmed that none of the program location paths were pointing to H: but as expected anything related to My Documents is pointing to H: as well as Local AppData %userprofile%\local settings\application data.
Although I have the perms to do so, it is not a viable solution for me to modify the registry on 1000+ machines. I am able to install this app if I login to a machine and run the msi locally (or from a share) but thats not ideal either.
Any help to get past this 'Invalid Drive" error is greatly appreciated.
thanks
Mirfster
Instead of using PSEXEC, have you considered simply deploying the MSI with AD?
ASKER
Although I am a domain admin I am not 'allowed' to employ AD for my uses - sounds silly ye,s but its just the rules. We have others who administer AD so its not my area to tinker with - but that would be nice.
So you all have 1000+ systems and are not using any type of Deployment Solution?.... /ouch
K.. I will see what I can do to help.
K.. I will see what I can do to help.
ASKER
Yes and no, part of what I'm deploying above has a component for software delivery. The 'plug in' is called Software delivery which behaves similar to Microsofts SCCM. Technically I should be able to deploy my software deployment plugin with CA's IT Client Manager but due to a previous employees distribution of agents theres an incompatibilty with older and newer versions (long story).
My concern here is resolving the issue of invalid H drive received from psxec/msiexec.
thanks
My concern here is resolving the issue of invalid H drive received from psxec/msiexec.
thanks
ASKER
So could this be the root of my issue? Locally, when I open my cmd its default is H:\. I then cd to where psexec and my .bat file are which is f:\caf.
My thought is that the remote machine is also using h:\ to pass/run the command and for some reason it doesnt like H:\
thoughts?
SP32-20091204-145205.png
My thought is that the remote machine is also using h:\ to pass/run the command and for some reason it doesnt like H:\
thoughts?
SP32-20091204-145205.png
Quick question, in your original question you posted the error which stated:
User: contoso\doe.john
I am assuming that this is a "test" user account. But does this "doe.john" legitimately have a folder on the network where his "My Documents" is redirected? Error simply could be due to the fact that there really isn't an actual "H:" drive for this user.
User: contoso\doe.john
I am assuming that this is a "test" user account. But does this "doe.john" legitimately have a folder on the network where his "My Documents" is redirected? Error simply could be due to the fact that there really isn't an actual "H:" drive for this user.
ASKER
I replaced my username with doe.john, but my account has logged into that machine already so a profile was created.
Any thoughts on a way to make my script ignore the use of H or redirect it to C?
Any thoughts on a way to make my script ignore the use of H or redirect it to C?
Installer indeed checks the location of all user's special folders during the installation; it does not like your redirected My Documents.
Most likely you will find the answer at http://forum.sysinternals.com/forum_posts.asp?TID=3796
Most likely you will find the answer at http://forum.sysinternals.com/forum_posts.asp?TID=3796
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
vadimrapp1: Excellent link, helped me understand my issue much better.
Mirfster: I adjusted my my BAT to the following and it worked perfectly!!!
@echo off
Set HOMEDRIVE=C:
net use y: /d
net use y: \\computername\sharename /user:domain\username PASSWORD
msiexec /i Y:\AgentAM_ENU\agtsd.msi /quiet /norestart
c:
cd c:\prog*\CA\dsm\bin
REM Set Scalability server address agent needs to register with.
caf setserveraddress ipaddress
net use y: /d
:end
echo "Done"
Thanks to both of you for the help!
Mirfster: I adjusted my my BAT to the following and it worked perfectly!!!
@echo off
Set HOMEDRIVE=C:
net use y: /d
net use y: \\computername\sharename /user:domain\username PASSWORD
msiexec /i Y:\AgentAM_ENU\agtsd.msi /quiet /norestart
c:
cd c:\prog*\CA\dsm\bin
REM Set Scalability server address agent needs to register with.
caf setserveraddress ipaddress
net use y: /d
:end
echo "Done"
Thanks to both of you for the help!
Glad to hear it worked for you.
This is probably good illustration to the point that everyone would be better off not using mapped drives at all. Encourage the users to use Network Places instead.
Besides various system-related annoyances (such as, for example, tooltip "not all of your mapped drives were found", or something like that, on startup, even though in fact all were found), there's very big practical advantage in the fact that UNC's are absolute, while mapped drives can be changed by any user. This sometimes results in different users working with different copies of the same file: user A says to user B: "the report is on G: drive"; but user B has mapped his G: to different network location, so now he will be working with 6 months' old copy of the file. Worse yet, when this is eventually uncovered, embarrassed users tend to hide this fact, increasing the damage even further. As long as drive mappings are unenforceable, these incidents are inevitable.
In my network, I have created and assigned an installation package that creates commonly used "network places" for everybody, and also assigned logon script that forcefully unmaps their mapped drives if they have created any.
Besides various system-related annoyances (such as, for example, tooltip "not all of your mapped drives were found", or something like that, on startup, even though in fact all were found), there's very big practical advantage in the fact that UNC's are absolute, while mapped drives can be changed by any user. This sometimes results in different users working with different copies of the same file: user A says to user B: "the report is on G: drive"; but user B has mapped his G: to different network location, so now he will be working with 6 months' old copy of the file. Worse yet, when this is eventually uncovered, embarrassed users tend to hide this fact, increasing the damage even further. As long as drive mappings are unenforceable, these incidents are inevitable.
In my network, I have created and assigned an installation package that creates commonly used "network places" for everybody, and also assigned logon script that forcefully unmaps their mapped drives if they have created any.