/build/static/layout/Breadcrumb_cap_w.png

Vbscript doesn't work within the MSI

Below is my script. It works fine when executed outside the MSI, but when run as a custom action it messes with me.

I have tried from embedded code, vbscript from installation and installed files and even execute program from destination

I get error 1721 when executing from destination and error 1720 when calling vbscript. Error 1720 says cant find path and points to the line - Set f = fso1.CreateFolder("P:\Folder")

The script copies folder3 from a network share to the users home drive (p:) but does nothing if that folder already exists in p:

I have also tried to execute the script from SSCM. But no. Doesnt work. It only works when I manually execute it, for example clicking it locally on my computer or at a share using unc path from "run".

Whats up with my newbie script?


Set objFSO = CreateObject("Scripting.FileSystemObject")
If objFSO.FolderExists("P:\Folder") Then

else
Dim fso1, fso2, fso3, f
Set fso1 = CreateObject("Scripting.FileSystemObject")
Set fso2 = CreateObject("Scripting.FileSystemObject")
Set fso3 = CreateObject("Scripting.FileSystemObject")
Set f = fso1.CreateFolder("P:\Folder")
CreateFolderDemo = f.Path
fso2.CopyFolder "\\networkShare\folder1\folder2\folder3", "P:\Folder"
End If


0 Comments   [ + ] Show comments

Answers (8)

Posted by: ptierney 14 years ago
Senior Yellow Belt
0
On the second line there should it not read


If Not objFSO.FolderExists("P:\Folder") Then


At the moment you are saying if a folder exists, create it again. Which there isn't really any point on doing [;)]
Posted by: polkagris 14 years ago
Orange Belt
0
He, well I just wasnt sure how to do the "if not". It should do nothing when the folder exists, but does it execute the else-part too?
Posted by: pjgeutjens 14 years ago
Red Belt
0
Polka,

when distributing your package using SCCM, the installations are probably done under LocalSystem credentials.
Since the LocalSystem account has no network access by default, let alone a mapped P: drive, herein lies your problem.

you can try using the WshNetwork.MapNetworkDrive method in your script to do the mapping before the createfolder. I'm not sure if it will work in an MSI though.

Rgds,

PJ
Posted by: WSPPackager 14 years ago
Senior Purple Belt
0
you can also pass the overwrite parameter to the copyfolder method.

fso2.CopyFolder "\\networkShare\folder1\folder2\folder3", "P:\Folder",True

This will make sure to copy all the files and subfolders.
Posted by: polkagris 14 years ago
Orange Belt
0
ORIGINAL: pjgeutjens

Polka,

when distributing your package using SCCM, the installations are probably done under LocalSystem credentials.
Since the LocalSystem account has no network access by default, let alone a mapped P: drive, herein lies your problem.

you can try using the WshNetwork.MapNetworkDrive method in your script to do the mapping before the createfolder. I'm not sure if it will work in an MSI though.

Rgds,

PJ


Well, that sucks. Guess thats why i get the same errors when trying to insert username into a path to a file (profile path).


Set objNetwork = CreateObject("WScript.Network")
strUserName = objNetwork.UserName

So, the above doesn't get me the username of the logged on user when executing within an msi but the account that runs the msi itself? Once again it works like a clock outside a msi.
Posted by: anonymous_9363 14 years ago
Red Belt
0
- If objFSO.FolderExists/If Not objFSO.FolderExists
The test would be better expressed with 'If Not objFSO.FolderExists' but then you also need to remove the 'Else' branch:If Not objFSO.FolderExists("P:\Folder") Then
Dim fso1, fso2, fso3, f
<etc, etc>
- You don't need multiple instances of the FileSystemObject object.
- You should use sensible names for variables, not nonsense like 'f'. You had the right idea with 'objFSO': by using what's called Hungarian notation, you know immediately that 'objFSO' is an object.
- Like most newcomers, you have ZERO error-trapping. Always, always, ALWAYS assume nothing is going to work, even basic stuff like object creation for well-known objects. For example:Set objFSO = CreateObject("Scripting.FileSystemObject")
If Not IsObject(objFSO) Then
'// Show a suitable error message here, then
'// quit script, passing the 'False' parameter, so that
'// any calling script/program knows that it failed.
'// Note, however, that you cannot use the 'WScript' directive in an embedded Custom Action,
'// since Windows Installer doesn't use Windows Scrioting Host as the, er, scripting host.
WScript.Quit(False)
End If

'// Carry on with your procedure
Pieter is correct in what he says about the System account: it has no network access, much less to a user's P: drive (I'm assuming you're using P: as a Personal drive?). As such, you should probably call this script via Active Setup or, since it's clearly connected with a user's log-in/personal folder set-up, have it added to your users' log-in script.
Posted by: polkagris 14 years ago
Orange Belt
0
Yeah, P is a personal drive and active setup is sort of the last resort here. Preferably it should work without logging out and in for users already logged in when getting the installation.

But thanks for clarifying why I get the errors. Was driving me nuts for a while.


If you have some tips for how to fix it through a script via msi or SCCM i would be extremely happy.
Posted by: anonymous_9363 14 years ago
Red Belt
0
Tips? Get the script fragment added to the log-in script; that's where it belongs! :) If there's some political reason why you can't do that, set the script up as a separate program/package (etc) and set it up so that it runs in user context and only when a user is logged in.
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ