Scripting

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 [;)]

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?

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

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.

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.

- 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 procedurePieter 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.

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.

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.