Jump to content











Photo
- - - - -

imdisk remote install


Best Answer Olof Lagerkvist , 02 March 2017 - 08:38 PM

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. Go to the full post


  • Please log in to reply
14 replies to this topic

#1 jimmy1990

jimmy1990
  • Members
  • 8 posts
  •  
    United States

Posted 02 March 2017 - 02:19 PM

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;

 

rundll32.exe setupapi,InstallHinfSection DefaultInstall.Nt 132 C:\ImDiskTk\driver\imdisk.inf
net start imdsksvc
net start awealloc
net start imdisk
 
I'm having issues with rundll32.exe executing correctly even when I run it as the local system account.  My end users don't have local admin rights on the computers, so I tried running the script as a startup script, but it didn't work either.
 
Do you have any ideas on how this could be done?
 
I need to create a virtual removable disk for my users that deletes when they log off.
 
Thanks,
James

  • ZEE likes this

#2 v77

v77

    Silver Member

  • Team Reboot
  • 521 posts
  •  
    France

Posted 02 March 2017 - 02:58 PM

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


  • ZEE likes this

#3 jimmy1990

jimmy1990
  • Members
  • 8 posts
  •  
    United States

Posted 02 March 2017 - 03:35 PM

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

 

Thanks,

James



#4 Olof Lagerkvist

Olof Lagerkvist

    Gold Member

  • Developer
  • 1339 posts
  • Location:Borås, Sweden
  •  
    Sweden

Posted 02 March 2017 - 08:38 PM   Best Answer

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.
  • ZEE likes this

#5 jimmy1990

jimmy1990
  • Members
  • 8 posts
  •  
    United States

Posted 03 March 2017 - 03:18 PM

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!


  • Olof Lagerkvist likes this

#6 jimmy1990

jimmy1990
  • Members
  • 8 posts
  •  
    United States

Posted 03 March 2017 - 04:13 PM

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



#7 jimmy1990

jimmy1990
  • Members
  • 8 posts
  •  
    United States

Posted 03 March 2017 - 04:35 PM

Here is the output;

 

C:\ImDiskTk\driver\cli\i386\imdisk.exe  -a -s 64M -m K: -
o rem -p "/fs:fat /q /y"
Creating device...
Created device 4: K: -> Image in memory
Drive letter K: points to '\Device\ImDisk3' instead of expected
'\Device\ImDisk4'. Will attempt to redefine drive letter.
Formatting disk K:...
Access Denied as you do not have sufficient privileges.
You have to invoke this utility running in elevated mode.
Notifying applications...
Done.
 
Thanks,
James


#8 Olof Lagerkvist

Olof Lagerkvist

    Gold Member

  • Developer
  • 1339 posts
  • Location:Borås, Sweden
  •  
    Sweden

Posted 03 March 2017 - 06:35 PM

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.


  • jimmy1990 likes this

#9 jimmy1990

jimmy1990
  • Members
  • 8 posts
  •  
    United States

Posted 03 March 2017 - 07:47 PM

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



#10 Olof Lagerkvist

Olof Lagerkvist

    Gold Member

  • Developer
  • 1339 posts
  • Location:Borås, Sweden
  •  
    Sweden

Posted 03 March 2017 - 09:25 PM

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



#11 Wonko the Sane

Wonko the Sane

    The Finder

  • Advanced user
  • 13647 posts
  • Location:The Outside of the Asylum (gate is closed)
  •  
    Italy

Posted 04 March 2017 - 08:51 AM

As a side-side note, and possibly not particularly useful, I seem to remember early tests/setups where you had a (minimal) pre-formatted image that could be mounted as ramdisk in IMDISK and then enlarged, maybe enlarging a disk is allowed :unsure:
This was on 911CD (which is unfortunately "one in the wind".
http://web.archive.o...showtopic=20203

:duff:
Wonko
  • Olof Lagerkvist likes this

#12 jimmy1990

jimmy1990
  • Members
  • 8 posts
  •  
    United States

Posted 06 March 2017 - 08:20 PM

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.

 
 
$os_type = (Get-WmiObject -Class Win32_ComputerSystem).SystemType -match ‘(x64)’
Copy-Item "location of ImDiskTk folder" C:\ -recurse
if ($os_type -eq "True") {
    Copy-Item C:\ImDiskTk\driver\sys\amd64\imdisk.sys C:\Windows\system32\drivers
    Copy-Item C:\ImDiskTk\driver\awealloc\amd64\awealloc.sys C:\Windows\system32\drivers
    Copy-Item C:\ImDiskTk\driver\cpl\amd64\imdisk.cpl C:\Windows\system32
    Copy-Item C:\ImDiskTk\driver\cli\amd64\imdisk.exe C:\Windows\system32
    Copy-Item C:\ImDiskTk\driver\svc\amd64\imdsksvc.exe C:\Windows\system32
    Copy-Item C:\ImDiskTk\driver\cpl\i386\imdisk.cpl C:\Windows\syswow64
    Copy-Item C:\ImDiskTk\driver\cli\i386\imdisk.exe C:\Windows\syswow64
    Copy-Item C:\ImDiskTk\driver\svc\i386\imdsksvc.exe C:\Windows\syswow64
    CMD.exe /C sc.exe create imdisk type= kernel start= auto error= ignore binPath= system32\drivers\imdisk.sys
    CMD.exe /C net start imdisk
    CMD.exe /C sc.exe create awealloc type= kernel start= auto error= ignore binPath= system32\drivers\awealloc.sys
    CMD.exe /C net start awealloc
    }
else {
    $os_type = (Get-WmiObject -Class Win32_ComputerSystem).SystemType -match ‘(x86)’
 
    if ($os_type -eq "True") {
    Copy-Item C:\ImDiskTk\driver\sys\i386\imdisk.sys C:\Windows\system32\drivers
    Copy-Item C:\ImDiskTk\driver\awealloc\i386\awealloc.sys C:\Windows\system32\drivers
    Copy-Item C:\ImDiskTk\driver\cpl\i386\imdisk.cpl C:\Windows\system32
    Copy-Item C:\ImDiskTk\driver\cli\i386\imdisk.exe C:\Windows\system32
    Copy-Item C:\ImDiskTk\driver\svc\i386\imdsksvc.exe C:\Windows\system32
    Copy-Item C:\ImDiskTk\driver\cpl\i386\imdisk.cpl C:\Windows\syswow64
    Copy-Item C:\ImDiskTk\driver\cli\i386\imdisk.exe C:\Windows\syswow64
    Copy-Item C:\ImDiskTk\driver\svc\i386\imdsksvc.exe C:\Windows\syswow64
    CMD.exe /C sc.exe create imdisk type= kernel start= auto error= ignore binPath= system32\drivers\imdisk.sys
    CMD.exe /C net start imdisk
    CMD.exe /C sc.exe create awealloc type= kernel start= auto error= ignore binPath= system32\drivers\awealloc.sys
    CMD.exe /C net start awealloc
       }
}
 
 
Is there anything wrong with this type of script?  We have both x86 and x64 bit systems in production at the moment.  
 
Thanks,
James


#13 Olof Lagerkvist

Olof Lagerkvist

    Gold Member

  • Developer
  • 1339 posts
  • Location:Borås, Sweden
  •  
    Sweden

Posted 06 March 2017 - 08:59 PM

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.



#14 jimmy1990

jimmy1990
  • Members
  • 8 posts
  •  
    United States

Posted 06 March 2017 - 09:09 PM

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



#15 breshead

breshead
  • Members
  • 1 posts
  •  
    United States

Posted 22 March 2017 - 08:37 PM

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

"%SystemRoot%\system32\rundll32.exe" setupapi.dll,InstallHinfSection DefaultInstall 131 .\imdisk.inf
 

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.

  • Olof Lagerkvist and Chandra-Orbit like this




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users