WishList – New Action – Browse C:

[ggcisssca]

I send this request for next version as a wish list 😉

BatchBatch is a remote command tool. Sometime when something goes wrong we need to access the remote machines to diagnose. Almost of time we need to do this action in background like BatchPatch… Then not necessary a RDP or remote console, just access files to take a look.

Yes, we could just use Windows Explorer and type \\machine\C$, but having this action in shortcut in BatchPatch list of machine it could be very easier and faster when when have a lot of machines.

[doug]

Try this:

1. Go to Actions > Execute local process/command > Create/modify local commands

2. Create a new command with the following syntax:

explorer \\$computer\c$

3. Save that command. It will appear under Actions > Execute local process/command > Execute saved local commands

4. Execute the command for a row. When you execute the above command for a given row in the grid, BatchPatch will automatically substitute $computer for the actual/real computer name from the Host column.

[ggcisssca]

Sorry this method is not possible for our context because we need to run BatchPatch “As another User” due to security context the “primary user” is less privileges. The BatchPatch user is another account that have network privileges to reach another computer over network…
And Microsoft have also created a limitation that can’t run Explorer from another session in the primary session. An error tell: “Windows can’t access to peripheral, path or file spcified. May be you d’ont have appropriate permissions to acces this element.”

I can call every other Windows GUI tools like Notepad, iexplore, etc… But not explorer.exe.

[doug]

In that case probably the best option for you would be to launch a second instance of BP in the other user account, which you can use for the sole purpose of launching the Explorer C$ windows.

Or another option might be to NOT run a second instance but instead just modify the command so that it launches as the correct user. Something like this:

runas /noprofile /user:mymachine\administrator explorer \\$computer\c$

or

runas /user:mymachine\administrator explorer \\$computer\c$

[ggcisssca]

This tweak is not working to run EXPLORER.EXE. It just return “Local Command: Exit Code: 1”. I couldunderstand it’s a Microsoft limitation for security purpose… I guess. Like I said, all other EXE are working fine but the file explorer of Windows seem to be limited to current session. Try it !

In fact, we already facing this EXPLORER limitation in other context since many years. Then we already found a “tweak” where it’s to use another file explorer !!! Since many years we are using Explorer++ where we can RunAs correctly ! It could be Commander, Explorer++ or any third party file explorer.

But, it seem BatchPatch have a coding error into “filename” support. Because we use Explorer++ where the default path is: “C:\Program Files\Explorer++\explorer++.exe”. BatchPatch tell “File not found” when we call it. But, the file really exist. To confirm this issue, I tried to rename and move the explorer++.exe file trough “C:\test\explorerplusplus.exe” and it work fine !! But it’s not a final solution. Moving and renaming a installed application can cause another issue (maintaining app up-to-date, detect properly the file, antivirus bad detection, etc.)

It seem BatchPatch doesn’t like “+” sign in filename wher it should be a supported character. If this filename support could be fixed, it will be appreciated ! May be this issue could affect some other file that could use the “+” sign inside his name.

[doug]

First, I would note that we do not encounter the same issue here. I can log on to the computer as userA, and then I can run BatchPatch with run-as under userB logon account, and inside of BatchPatch I can call the following local command successfully without any issues to launch Explorer

explorer \\$computer\c$

For me it returns exit code 1 but still launches Explorer to the proper location. I believe the reason you cannot do this even though I can do this is likely because the user that you have running BatchPatch does not have local administrator permissions on the BatchPatch computer.

================

With regard to the ++ issue… BatchPatch does not have an issue with ++. The bug you are encountering is BP failing to parse the space properly in ‘Program Files’. Thank you for highlighting this issue. We will have it fixed in the next release.

================

For the time being until the next version of BP is released, it seems like your easiest workaround is to just launch a separate instance of BP in the correct user account to be able to launch Explorer without issues without needing to run-as a different user. Alternatively, put your Explorer++ in a location that does not contain a space in the filepath.

[ggcisssca]

Are you working in Active Directory (domain) environment where optimal security with Kerberos authentication is in use ?

How we need to use it:

1- The Windows tech machine is running Windows 10/11 Enterprise
2- The Windows session is open with a standard user, no admin prviliges on the local and remote machines. This user is a domain user that have no special privileges.
3- The BatchPatch application need to run as another user (Run As another user Or Run As Administrator (not really necessary… but just allow to select a user that have admin privileges on the local machine… and with in admin context). This other is a domain user have admins privileges on remote machines to access them.
4- At this step, the BatchPatch is running fine to access all remote machines.

We cannot use the “Administrator” local account because each machine use different admin account passord (LAPS) and/or local admin is also disable.

———————–

Outside BatchPatch, runnig Windows Explorer As another account is also following the same way… But this is not working. We are facing that since Windows 7/2008R2.

If I try to basically do manually what you explain, I run a CMD console as another user or as an administrator, I type “Explorer.exe”. The explorer will open… But if I try to browse with this explorer is not really running as this another user, It will revert to my standard session. An easy try to reach \\server\C$ will prompt me to type credentials (The explore should run in a context of a user that have the good permissions if this user was this one who run the CMD, but it’s not the case). Using a third party explorer is working fine.

Anyway, my request was:

If BatchPatch could have a builtin “Explore C$” to access remote machines in the context of the user who run it.

You propose to do this using “Create a local command” where it’s acceptable solution ! No need to developp your own file browser. But using native explorer.exe is cause issue do to Windows Security limitation.

Using a third-party file explorer (call it from BatchPatch) is an acceptable solution also ! But I’m facing another issue where it seem a problem inside BatchPatch that not support “+” sign in the filename. It’s an issue I found during this expreimentation and it’s not an issue about my initial request but I think it’s a bug that should be fixed. For the moment, I can work if I rename explorer++.exe through another name like explorerplusplus.exe because it’s a portable application but it’s a mitigation. I could use another third party file explorer but we are just selected this one in our enterprise as our internal tool.

NOTE: The “+” sign inside filename could affect some other situation. I can understand it’s a rare character in filename… But it’s should be supported.
https://learn.microsoft.com/en-us/windows/win32/fileio/naming-a-file

Regards

[doug]

Regarding Explorer… Yes, we are experiencing the same prompt for user credentials. This is expected behavior. We will consider a custom file explorer/browser, but to your point, there already exist custom file explorer apps on the market, and you already have such an app.

Regarding ++… As described in my previous posting, BP does *not* have an issue with + symbols. The issue that you are encountering is from the *space* character in your filepath, not from the + symbol. As mentioned in the previous posting, we will have that issue/bug fixed for the next release. However, for the time being until the next version is released, a workaround would be to install your explorer++.exe into a filepath that does not have any space characters. e.g. Instead of C:\Program Files\Explorer++\explorer++.exe, install it to something like C:\ProgramFiles\Explorer++\explorer++.exe

[Author]

Posts