VB6 Application on Windows 7 Cannot Access Mapped Drives - windows-7

I have a VB6 application which links to several POS terminals from a Windows 7 32-bit machine. The POS terminals are mapped to the Windows 7 machine and I can access the POS terminals from the Windows 7 machine from Explorer or via the cmdline/shell.
The application has been updated to ADO 2.8 and all other controls and components I no longer had source code for have been re-written. After a few annoying hiccups, I got the application to recompile on the Windows 7 computer without errors.
Now come the problems. The VB6 application cannot see or navigate to any mapped drives! I have tried twiddling UAC settings; I have set the app to run in Windows XP SP3 mode; I have tried running as Administrator. None of these things (and many permutations of these) work.
Any suggestions on how to make this work?

Adding this registry setting solved the problem for me: http://technet.microsoft.com/en-us/library/ee844140%28v=ws.10%29.aspx.
To work around this problem, configure the EnableLinkedConnections
registry value. This value enables Windows Vista and Windows 7 to
share network connections between the filtered access token and the
full administrator access token for a member of the Administrators
group. After you configure this registry value, LSA checks whether
there is another access token that is associated with the current user
session if a network resource is mapped to an access token. If LSA
determines that there is a linked access token, it adds the network
share to the linked location. To configure the EnableLinkedConnections
registry value
Click Start, type regedit in the Start programs and files box, and
then press ENTER.
Locate and then right-click the registry subkey HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System.
Point to New, and then click DWORD Value.
Type EnableLinkedConnections, and then press ENTER.
Right-click EnableLinkedConnections, and then click Modify.
In the Value data box, type 1, and then click OK.
Exit Registry Editor, and then restart the computer.

I believe you are having trouble because casual drive mapping is per-user, and on a UAC system Administrators group users have two separate contexts (one for each token: SU & elevated).
There is such a thing as a system level drive mapping, which is one done under the System user (NT Authority\System). When you map a drive under this account, and map it persistently, all users can see and use the mapping (subject to the usual access rights for files there).
The normal way you do this is via Domain-level GPOs (Group Policy Objects), which means bribing your local box jockeys if in a corporate managed LAN environment.
One way to do this in a Workgroup machine is to map the letter as System via the AT command, from an elevated command prompt:
at 8:53 am "net use m: \\MediaShare\MyLibrary
ThePW /user:MediaShare\TheUser /persistent:yes > nul"
There the remote server is MediaShare, user TheUser, password ThePW, and 8:53 AM is a minute or two in the future to avoid accidentally scheduling this for tomorrow.
But this fails on Vista and later due to Session 0 Isolation!
So... use the 3rd alternative at Run CMD.exe as Local System Account which is the same thing mentioned by ForcePush's reply to How to map a network drive to be used by a service.
I believe that's what you are after here.

don't know if you ever figured this one out but for me it was the ChDir command (even with the registry fix above).
I had in my code
ChDir "P:\Temp\VidCap\Cam1\" 'I almost never use ChDir
Open "list.txt" For Output As #1
and all the VB6 inbuilt file commands looked straight though any operations, no errors, no nothing. I solved it by explicitly having the path, (in my code it was in a string but you could have it explicitly):
dd = "P:\Temp\VidCap\Cam1\"
Open dd & "list.txt" For Output As #1
works as expected.
hope this helps
H

Try this:
Open command prompt as administrator, and type this in:
net use Z: \\IP Address\share /user:you passwd /persistent:Yes
Change "IP Address", the "share" name, and your username and password as needed.
The author of this is howtogeek (source).

I had same problem. VB6 kept crashing when trying to access USB and mapped drives using the Commondialog method, even though the drives and files were all accessible OK via Explorer. Problem is the drives were not set as shared.
Solved by selecting the connected USB drive in explorer and then right click to
select Properties.
Select Sharing Tab
Select Advanced Sharing
Set the sharing and user rights as needed. May need to have local admin rights.

Related

Changing Local Policy "Prevent installation of removable devices "in CMD

How do I edit Group Policy Object "Prevent installation of removable devices" (https://technet.microsoft.com/en-us/library/cc753539(v=ws.10).aspx) in CMD?
I have a server (Windows Server 2008 R2) that is locked out as I am unable to use keyboard or mouse to as input devices when the windows login requires me to press ctrl+alt+delete. This Policy is the one causing this locked out situation as the old keyboard and mouse which I am trying to solve.
Current situation only allows me to use CMD to make changes to the system when I boot up with a bootable CD.
My server doesn't have PS2 port for the old type keyboard. Any other solution that can help me solve this locked out situation is also welcome :)
"Prevent installation of removable devices" is part of "Administrative Templates" and therefore corresponds to a Registry key.
To find out that registry key, I searched for "Prevent installation of removable devices" within C:\Windows\PolicyDefinitions\en-US\, found <string id="DeviceInstall_Removable_Deny">Prevent installation of removable devices</string> in C:\Windows\PolicyDefinitions\en-US\DeviceInstallation.adml. Then I searched for DeviceInstall_Removable_Deny in C:\Windows\PolicyDefinitions\ and found it in C:\Windows\PolicyDefinitions\DeviceInstallation.admx. The registry key is:
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\DeviceInstall\Restrictions
valueName: DenyRemovableDevices
enabled Value: decimal 1
disabled Value: decimal 0
If you change that value, it will be overridden when the group policy is applied the next time -- most likely at boot time.
According to http://learnthat.com/prevent-group-policy-from-applying-to-your-computer/ you can avoid this by denying write permissions to that specific registry key. (Note, I did not test this!)
To change the registry offline, you can boot from a windows install CD, press Shift+F10 simultaneously to open cmd, type regedit, select HKEY_LOCAL_MACHINE key, click Menu File -> Load Hive..., navigate to your installations \Windows\System32\Config\ folder and select the file named SOFTWARE.
Chose any key name, that doesn't already exist (e.g. Offline_Software) and then change the registry under that key. (e.g. HKEY_LOCAL_MACHINE\Offline_Software\Policies\Microsoft\Windows\DeviceInstall\Restrictions)
When you're done, select your loaded Hive (e.g. HKEY_LOCAL_MACHINE\Offline_Software) and click File -> Unload Hive...
To shutdown properly, just close all windows, including the setup window.

Admin elevation from program that runs over network

Small parts of my application require admin rights (activation of the software needs to go to HKLM). For this, I draw shield icons on the buttons whose action require admin rights and when clicking, I restart the application with an appropriate parameter again using "runas" verb.
This works very good! However, now it happens that users execute the application from a network share. If they click on the "admin rights button" now, they get an error message because the network drive is not mapped for the administrator, therefore the executeable can't be found :-(
What's the best way around this?
Mapped drives are stored with each logon session, so you don't have them after elevation.
You can extract the admin interface to another executable and mark it as requireAdministrator in the manifested. Then launch the admin executable via ShellExecute. Windows Explorer will copy the drive mapping in this case (undocumented behavior, though).

open file dialog not working in vista and 2008 envir

i am using Vista . I designed MSi file through Visual Studio 2008 Setup and deployment project in which I added one custom action. In the custom action, I am opening OpenFile dialog. This Open File dialog is not showing mapped drive or network locations. so how can i make the open file dialog to mapthe network drives.
This is a known problem with Vista User Account Control. When your installation program is started, the non-admin session of the user is elevated to an admin session. The problem is: Network drives mapped in the non-admin session of the user do not automatically carry over to the admin session.
Unfortunately, there is not much you can do about it. (You can start an elevated command prompt prior to starting your setup project and manually net use the drive letters there, but I guess that's not something you can expect your customers to do.)
Related question: Preserve mapped drive letter information during UAC elevation

Find out who is locking a file on a network share

I want to known who is locking a file on a network share.
Here is the problem : the network share is on a NAS, so I can't log on. I need a tool to find out remotely who is locking the file. It is not practical to reboot the NAS every time, because there are several users.
Handle.exe, Process Explorer and PsFile seems to be limited to files on the local machine, so they don't work for me.
Just in case someone looking for a solution to this for a Windows based system or NAS:
There is a built-in function in Windows that shows you what files on the local computer are open/locked by remote computer (which has the file open through a file share):
Select "Manage Computer" (Open "Computer Management")
click "Shared Folders"
choose "Open Files"
There you can even close the file forcefully.
On Windows 2008 R2 servers you have two means of viewing what files are open and closing those connections.
Via Share and Storage Management
Server Manager > Roles > File Services > Share and Storage Management > right-click on SaSM > Manage Open File
Via OpenFiles
CMD > Openfiles.exe /query /s SERVERNAME
See http://technet.microsoft.com/en-us/library/bb490961.aspx.
PsFile does work on remote machines. If my login account already has access to the remote share, I can just enter:
psfile \\remote-share
(replace "remote-share" with the name of your file server) and it will list every opened document on that share, along with who has it open, and the file ID if I want to force the file closed. For me, this is a really long list, but it can be narrowed down by entering part of a path:
psfile \\remote-share I:\\Human_Resources
This is kind of tricky, since in my case this remote share is mounted as Z: on my local machine, but psfile identifies paths as they are defined on the remote file server, which in my case is I: (yours will be different). I just had to comb through the results of my first psfile run to see some of the paths it returned and then run it again with a partial path to narrow down the results.
Optionally, PsFile will let you specify credentials for the remote share if you need to supply them for access.
Lastly, a little known tip: if someone clicks on a file in Windows Explorer and cuts or copies the file with the intent to paste it somewhere else, that act also places a lock on the file.
If its simply a case of knowing/seeing who is in a file at any particular time (and if you're using windows) just select the file 'view' as 'details', i.e. rather than Thumbnails, tiles or icons etc. Once in 'details' view, by default you will be shown;
- File name
- Size
- Type, and
- Date modified
All you you need to do now is right click anywhere along said toolbar (file name, size, type etc...) and you will be given a list of other options that the toolbar can display.
Select 'Owner' and a new column will show the username of the person using the file or who originally created it if nobody else is using it.
This can be particularly useful when using a shared MS Access database.
The sessions are handled by the NAS device. What you are asking is dependant on the NAS device and nothing to do with windows. You would have to have a look into your NAS firmware to see to what it support. The only other way is sniff the packets and work it out yourself.
Partial answer: With Process Explorer, you can view handles on a network share opened from your machine.
Use the Menu "Find Handle" and then you can type a path like this
\Device\LanmanRedirector\server\share\
sounds like you have the same problem i tried to solve here. in my case, it's a Linux fileserver (running samba, of course), so i can log in and see what process is locking the file; unfortunately, i haven't found how to close it without killing the responsible session. AFAICT, the windows client 'thinks' it's closed; but didn't bother telling the fileserver.
Close the file e:\gestion\yourfile.dat, open by any user (/a *)
openfiles /disconnect /a * /op "e:\gestion\yourfile.dat"
more in:
http://dosprompt.info/commands/openfiles.asp

Restrict access to a single application when logging in from the console without replacing GINA

Does anybody know if there is a feasible way on Windows XP to programmatically create and configure a user account so that after logging in from the console (no terminal services) a specific app is launched and the user is "locked" to that app ?
The user should be prevented from doing anything else with the system (e.g.: no ctrl+alt+canc, no ctrl+shift+esc, no win+e, no nothing).
As an added optional bonus the user should be logged off when the launched app is closed and/or crashes.
Any existing free tool, language or any mixture of them that gets the job done would be fine (batch, VB-script, C, C++, whatever)
SOFTWARE\Microsoft\Windows NT\CurrentVersion\WinLogon has two values
UserInit points to the application that is executed upon successful logon. The default app there, userinit.exe processes domain logon scripts (if any) and then launches the specified Shell= application.
By creating or replacing those entries in HKEY_CURRENT_USER or in a HKEY_USERS hive you can replace the shell for a specific user.
Once you ahve your own shell in place, you have very little to worry about, unless the "kiosk user" has access to a keyboard and can press ctrl-alt-del. This seems to be hardcoded to launch taskmgr.exe - rather than replacing the exe, you can set the following registry key
[SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\taskmgr.exe]
Debugger="A path to an exe file that will be run instead of taskmgr.exe"
I guess you're building a windows kiosk?
Here's some background in replacing the windows login shell - http://blogs.msdn.com/embedded/archive/2005/03/30/403999.aspx
The above link talks about using IE as the replacement, but any program can be used.
Also check out Windows Steady State - http://www.microsoft.com/windows/products/winfamily/sharedaccess/default.mspx

Resources