imdisk remote install

Hello,

I'm needing help with installing imdisk remotely.  What I'm looking for is to create a login script that will install imdisk headless if needed, and then create a small ramdisk that the user can use while logged in.  Then, when they log out, it dismounts the drive and deletes it.  

I've been trying to create a script that uses the following;

Replace your first command with:
 
rundll32.exe setupapi,InstallHinfSection DefaultInstall 132 C:\ImDiskTk\driver\imdisk.inf
 
(remove ".Nt")

I attempted that, and it didn't change anything.

Thanks,

James

There are several problems with running setupapi.dll functions under system account. In general, most of setupapi functions need to run under a user account with an interactive session that can display dialog boxes and similar.

I would recommend that you instead let your script copy necessary files and install driver manually, pretty much what the .inf file usually do.

Copy:
amd64\imdisk.sys to C:\Windows\system32\drivers
amd64\awealloc.sys to C:\Windows\system32\drivers
amd64\imdisk.cpl to C:\Windows\system32
amd64\imdisk.exe to C:\Windows\system32
i386\imdisk.cpl to C:\Windows\syswow64
i386\imdisk.exe to C:\Windows\syswow64

Then:

sc create imdisk type= kernel start= auto error= ignore binPath= system32\drivers\imdisk.sys
net start imdisk
sc create awealloc type= kernel start= auto error= ignore binPath= system32\drivers\awealloc.sys
net start awealloc

(I assume 64 bit architecture here. I also skipped the helper service, imdsksvc because it is usually not needed for using RAM disks.)

There are also ways to "push" setup across network by copying files to UNC path, use sc command with a remote computer name etc if you want to try that method instead of using scripts directly on each remote machine.

 

This worked perfectly.  Thanks!

There are several problems with running setupapi.dll functions under system account. In general, most of setupapi functions need to run under a user account with an interactive session that can display dialog boxes and similar.

I would recommend that you instead let your script copy necessary files and install driver manually, pretty much what the .inf file usually do.

Copy:
amd64\imdisk.sys to C:\Windows\system32\drivers
amd64\awealloc.sys to C:\Windows\system32\drivers
amd64\imdisk.cpl to C:\Windows\system32
amd64\imdisk.exe to C:\Windows\system32
i386\imdisk.cpl to C:\Windows\syswow64
i386\imdisk.exe to C:\Windows\syswow64

Then:

sc create imdisk type= kernel start= auto error= ignore binPath= system32\drivers\imdisk.sys
net start imdisk
sc create awealloc type= kernel start= auto error= ignore binPath= system32\drivers\awealloc.sys
net start awealloc

(I assume 64 bit architecture here. I also skipped the helper service, imdsksvc because it is usually not needed for using RAM disks.)

There are also ways to "push" setup across network by copying files to UNC path, use sc command with a remote computer name etc if you want to try that method instead of using scripts directly on each remote machine.

 

One issue I have noticed now is that my standard users can't format the disk.  Administrators removable disks format correctly when they log in, but standard users just have the drive showing up.  When they click on the drive, it asks them to format it.  When they attempt to format it, they get an error stating they don't have permission to do that.  

Would this be due to the helper not being installed?  if we install imdisk like normal, the login script works fine for our normal users. 

Thanks again for all the help!

James

Here is the output;

Normal users don't have permission to format fixed disk media in Windows, so that's expected. It has nothing to do with the way you installed ImDisk. You could either:
* Use an image file that is already formatted (which ImDisk will then copy to the RAM disk when the RAM disk is created).
* Create the RAM disk with -o rem option to create it with removable media properties. This allows non-administrators to format and dismount without problems. I think I would recommend this in your case.
* Change security policy for your domain to allow non-administrators to format fixed disk media. I would not recommend that though, because it affects all fixed disk media in all machines.

Normal users don't have permission to format fixed disk media in Windows, so that's expected. It has nothing to do with the way you installed ImDisk. You could either:
* Use an image file that is already formatted (which ImDisk will then copy to the RAM disk when the RAM disk is created).
* Create the RAM disk with -o rem option to create it with removable media properties. This allows non-administrators to format and dismount without problems. I think I would recommend this in your case.
* Change security policy for your domain to allow non-administrators to format fixed disk media. I would not recommend that though, because it affects all fixed disk media in all machines.

That's where I'm getting confused. I'm already using the -o rem switch.

James

Could you check your domain security policy? Maybe the setting "Devices: Allow removable media to be formatted and ejected" is set to something other than the default? The default setting is to allow "Administrators" and "Interactive users".

Could you check your domain security policy? Maybe the setting "Devices: Allow removable media to be formatted and ejected" is set to something other than the default? The default setting is to allow "Administrators" and "Interactive users".

I checked that and it is set correctly.  I'm wondering if it has something to do with PowerShell script.  

Below is a copy of the script.  I changed the source directory of the first copy for security reasons.

I have not looked at your script in detail. But anyway, the way ImDisk is installed does not affect whether a virtual disk can be formatted by a particular user or not. There is definitely some other reason behind this problem.

You actually know that ImDisk setup was successful because there are no errors when creating the virtual disk. The error happens when Windows format.com tool is about to format the virtual disk, either because of some permission issue, policy or something similar.

I have not looked at your script in detail. But anyway, the way ImDisk is installed does not affect whether a virtual disk can be formatted by a particular user or not. There is definitely some other reason behind this problem.

 

You actually know that ImDisk setup was successful because there are no errors when creating the virtual disk. The error happens when Windows format.com tool is about to format the virtual disk, either because of some permission issue, policy or something similar.

 I'll continue looking into the permission/policy side of things.

Thanks,

James

-- FIXED! --

I was having the same issues that you were and found that it was an argument to the rundll32,setupapi  that was the real issue, the argument (132) was telling the system to ask the user to reboot if necessary (not very silent).

This argument puts in action a requirement for an interactive GUI which is obviously not the case from a remote install much less one from the system user account. This causes the entire command to fail silently.

The fix was to read up on the rundll32.exe options then determine what mode I wanted.

128 is required. So adding to that whether I wanted to reboot or not is the question. I gave it a +3 which is to reboot if necessary which brings the number to 131 (128 + 3).

In the end the rundll32 line now looks like this..

The installer now works for me.

Now repackaging the sfx is another issue entirely. I opted for making my pre-install script bigger (a salt state) and just used a plain zip archive with the modified install.cmd.

Edited by breshead, 22 March 2017 - 08:38 PM.