Cannot run executable on a network share from Server 2008
We have a MS Server 2008 that is used as a terminal server (TS). We have two database applications on other servers that are accessed from the TS sessions. We have been running in this configuration with no problems for over a year. On the weekend of November 13, 2010 suddenly both database applications were no longer accessable from the MS Server 2008. One of the db applications starts by launching an executable (.exe) from a network share located on a MS Server 2003. I have logged onto the MS Server 2008 server locally as a user in the Local Adminstrators Group, and navigated to the network share on the MS Server 2003 using the 'run' command, and then tried to launch the .exe from the window, but I still get a security related error from the database application (not a micrsoft error message). I can access the same network share from my XP SP3 workstation and run the .exe with no problems (I can do this from our other MS Server 2003 servers as well logged in as the same user with local administrator secruity). Our other database application runs on a SQL 2005 Server on another (different from the 1st server mentioned above) MS Server 2003. In this case we run a Client Database Configuration program on the MS Server 2008 where the Database Client is located to create the connection to the Database on the MS Server 2003 running the SQL 2005 Server. When we try to run this client configuration it appears to take the path to the share where the client configuration connection is made, but when we try to save the configuration we get a secruity related error from the database client (not a microsoft error message). Again I can use the 'run' command to access the share from the MS Server 2008 with no problems, I just can not run the files to create the connection to the db; the files have the correct security to allow them to be run. Again from our XP SP3 workstations and other MS Server 2003 servers I can make this db connection with no problems. In attempts to debug on the MS Server 2008 I have turned off the built-in Microsoft: Domain, Public, and Private firewalls (even though the Public and Private were set to ON and did not cause any problems two+ weeks ago), I have turned off our McAfee AntiVirus application by stopping the services, but I still get the same problems even logged in as a user in the Local Administrator's group. I can not find any errors or other related events in the Application, System, or Security events that coincide (or not) with my attempts to connect to these database applications located on shares on other MS 2003 servers. It's as if some how the database is trying to make the connection and is getting blocked somehow, like the ports are closed or something. The File Share, Directory and File security all appear to be correct (unchanged from what was working before). The strange part about this is that only our MS Server 2008 has this problem all other MS Server 2003, XP SP3 clinets etc. are all working correctly when they try to connect to the databasees on these shares. Does anyone have any idea what the problem could be with the MS Server 2008 security or other? Bill Tomlinson
November 29th, 2010 5:59pm

Hi, I notice that you always used "Local Administrators" when you described the issue. Do you mean it is a workgroup (non-domain) environment? Meanwhile, please perform a simple test to launch notepad.exe and save the .txt file on the Windows Server 2003 machines from the Windows Server 2008 computer. Do you encounter the same issue? Thanks. I look forward to your response.This posting is provided "AS IS" with no warranties, and confers no rights. Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
Free Windows Admin Tool Kit Click here and download it now
November 30th, 2010 1:39am

Joson, We are in a Domain. I use a domain user account that have been added to the Local Administrator's Group to avoid any security related problems for purposes of deducing the problem that has appeared. I have also tested with a domain user account that is in the normal security groups that any user trying to access the database applications would be in for a 'real' test. On one of the MS 2003 Servers the Directory Share only has 'READ' permissions, and therefore naturally we could not save the .txt file in our test. This 'READ' only share works correctly on all other MS 2003 servers trying to make the database connection to this share, and all of our XP Client machines. The Directory/File level permssions are: Read & Execute, List Folder Contents, and Read. On the other MS 2003 Server where the .exe file is launched to start the Database Connection the share is set to 'FULL', and naturally we were able to save the .txt file as a test there. The Directory/File level permissions are: Modify, Read & Execute, List Folder Contents, Read, and Write. Again as with the other database application I can run the .exe and get the database connection from any or our other MS 2003 Servers, or XP Workstations. Just the MS 2008 Server is having this issue with making the connection right now.Bill Tomlinson
November 30th, 2010 4:07pm

Hi, If I understand correctly, you are using a user account which is member of the local Administrators group on the Windows Server 2003 computers. Now, you find that you cannot save the .txt file on the Windows Server 2003 computers. Process Monitor should be able to help you identify the cause. http://technet.microsoft.com/en-us/sysinternals/bb896645.aspxThis posting is provided "AS IS" with no warranties, and confers no rights. Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
Free Windows Admin Tool Kit Click here and download it now
December 1st, 2010 2:07am

Joson, I think we are having a communication problem, it appears that you have not been reading what I am writing very carefully, your answer seems to be off the mark. I am logging into a MS Server 2008 as a Domain User that is in the MS Server 2008's Local Administrators Group. This means that when I log on to the server I have Administrator Privileges on the server. Do you understand this? This same user has been successfully running a .exe file on a network share located on a DIFFERENT MS 2003 Server. This .exe starts a database connection object for an application. This .exe file has been successfully working for over a year and suddenly stopped working. From the MS 2008 server I can open the network share located on the MS 2003 Server and I can double click on the .exe file. When I do I get a security permissions error that I have never seen or been getting before 11/13/2010. This exact same user can log on to any other MS Server 2003, or XP Workstation and run the .exe located on the MS 2003 Server. This is the NORMAL condition the .exe file can be accessed and runs properly from all of my other MS 2003 Servers and or XP Workstations. ONLY THE MS 2008 SERVER IS HAVING THIS PROBLEM. In my previous post I quote: "On the other MS 2003 Server where the .exe file is launched to start the Database Connection the share is set to 'FULL', and naturally we were able to save the .txt file as a test there." Please re-read previous posts for answers to your other questions regarding copying a .txt file etc. My suspicion is that something has changed via group policy, security patch, or other that has somehow affected the security permissions on the MS 2008 SERVER. I can't figure out how, what or why this is occurring because the same exact user can successfully run the .exe from all my other MS 2003 Servers and XP Workstations. Any ideas about why the MS 2008 Server is having a problem running the .exe would be appreciated. Thanks, Bill Tomlinson
December 1st, 2010 11:41am

Hi, Please note that logging on with a user account that is member of the local administrators on Windows Server 2008 computer does not mean that you have administrative permission on the Windows Server 2003 computer as well. That's why I confirmed with you again and again. You can temporarily turn off the UAC on the Windows Server 2008 computer and check if it helps. Turn User Account Control on or off http://windows.microsoft.com/en-US/windows-vista/Turn-User-Account-Control-on-or-off Meanwhile, let’s collect the following information and perform some tests: What is the exact error message that you receive when you run the applications? Please let us know the exact error WORD BY WORD. Which database application are you using? Does the error occur before or when the application tries to connect to database? According to your description, the error is from the database application. Have you contacted the support of the database application to see what the possible cause is? I don't mean to bounce you between supports; however, the manufacturer may have more information on this. You mentioned that this problem happened recently. Did it coincide with any special events, such as the installation of some software or deploy some group polices or security settings on the Windows Server 2008, Windows Server 2003, and database server? Is it possible to copy the application from the network share to the Windows Server 2008 terminal server and run it from there? What’s the result? To isolate whether the database connection is an issue, you may use Data Sources (ODBC) to establish a ODBC connection to your SQL server database if you know the database connection server, user name and password of the application. Can you establish the connection. Thanks. This posting is provided "AS IS" with no warranties, and confers no rights. Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
Free Windows Admin Tool Kit Click here and download it now
December 2nd, 2010 9:27pm

Hi, How's everything going? Is there any update on the issue? Please do not hesitate to respond back if you need further information. Thanks.This posting is provided "AS IS" with no warranties, and confers no rights. Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
December 12th, 2010 8:35pm

Joson, I felt that we were 'chasing ghosts' so I used a Microsoft Case to get some more help. They too are unable to indentify the reason why 3rd party applications that worked well for over a year are now no longer able to run properly. We are continuing the work and I will update you if we resolve the issue. In the meanwhile we have setup simple workstations for users to remote logon to and they are able to run the applications with no problem. Only MS Server 2008 w/Terminal Services is not working proplerly. There is a mystery that you may be able to help me resolve: If we use the cmd window and enter change user /install We get an error stating that we need to be in the Administrator's group to perform the change. We are running as a domain user in the Local Administrators group. If we If we use the cmd window and enter change user /query It returns that we are in EXECUTE mode. One of my consultants recommended setting the Terminal Server to INSTALL mode to see if you could run the applications that way, and we can't even get Terminal Server into that mode. Microsoft is aware of this issue and I am asking that this be resolved for sure, and we will see if that leads to some resolutions on the 3rd party application side. Let me know you thoughts. Thanks, Bill T. Bill Tomlinson
Free Windows Admin Tool Kit Click here and download it now
December 13th, 2010 12:19pm

Bill. Do you run the cmd window AS Administrator (ie right-click cmd.exe and choose run as administrator)? Jovanovski
March 2nd, 2011 10:05am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics