Problems running a program that resides on a server from a workstation on another domain
In our environment there are two different domains. The two domains trust one another. In domain A there is a remote desktop services server (setup as a member server) that has a database application that users in both domains access and run a program from. The users in domain B that are trying to run this program on the Remote Desktop Services server in domain A are having troubles.
When these users from domain B (XP clients) double click the icon on their desktop to run this program, sometimes it works and sometimes it doesn't. When the program doesn't open up for the user the error message is, "The item program.exe that this shortcut refers to has been changed or moved, so this shortcut will no longer work properly. Do you want to delete this shortcut? I have tried running this program using a UNC path to the executable that runs the program as well as mapping a drive.
When the process isn't working, if I right click on the icon, choose properties and then click Find target the target file is not found. If i then click Start, Run and type in the UNC path to the share on the Remote Desktop Services server I get the following message, "\\server name\share name is not accessible. You might not have permission to use this network resource. There are currently no logon servers available to service the logon request."
I can always ping the IP address of this server.
If I look at the security on the folder that I am trying to access, domain users from domain A have modify rights to the folder that contains the program that they are trying to run. If I try to add the domain users group from domain B to have the same modify rights to this directory I receive the following message, "The Active Directory Domain Controllers required to find the selected objects in the following domains are not available: domain B. Ensure the Active Directory domain controllers are available and try to select the objects again.
To try and get around this problem with assigning the users in domain B to have permission on the directory that contains the program.exe that they need to run, I have created these same users in domain B with the identical username and passwords that they have in domain A.
How do I go about making this process work so that I don't continue to have these errors. I don't want to have to change domain B to be part of domain A as this would require quite a big change in the network setup.
Thanks for any input you may have.
When these users from domain B (XP clients) double click the icon on their desktop to run this program, sometimes it works and sometimes it doesn't. When the program doesn't open up for the user the error message is, "The item program.exe that this shortcut refers to has been changed or moved, so this shortcut will no longer work properly. Do you want to delete this shortcut? I have tried running this program using a UNC path to the executable that runs the program as well as mapping a drive.
When the process isn't working, if I right click on the icon, choose properties and then click Find target the target file is not found. If i then click Start, Run and type in the UNC path to the share on the Remote Desktop Services server I get the following message, "\\server name\share name is not accessible. You might not have permission to use this network resource. There are currently no logon servers available to service the logon request."
I can always ping the IP address of this server.
If I look at the security on the folder that I am trying to access, domain users from domain A have modify rights to the folder that contains the program that they are trying to run. If I try to add the domain users group from domain B to have the same modify rights to this directory I receive the following message, "The Active Directory Domain Controllers required to find the selected objects in the following domains are not available: domain B. Ensure the Active Directory domain controllers are available and try to select the objects again.
To try and get around this problem with assigning the users in domain B to have permission on the directory that contains the program.exe that they need to run, I have created these same users in domain B with the identical username and passwords that they have in domain A.
How do I go about making this process work so that I don't continue to have these errors. I don't want to have to change domain B to be part of domain A as this would require quite a big change in the network setup.
Thanks for any input you may have.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Secondary DNS in B needs to point to A
Secondary DNS in A needs to point to B
"DCDIAG /test:DNS > dns.txt" returns what? on both domains
Secondary DNS in A needs to point to B
"DCDIAG /test:DNS > dns.txt" returns what? on both domains
ASKER
test-domain-A.txt test-domain-B.txt
Test from domain B was from a server 2008 r2 server. Test from Domain A was from a server 2003 server. Thus the different test reports.
I set the DNS settings on each server as indicated but still no luck.
When I go to each server and do a nslookup command to find the server from the other domain, the lookup fails.
Any other thoughts here?
Test from domain B was from a server 2008 r2 server. Test from Domain A was from a server 2003 server. Thus the different test reports.
I set the DNS settings on each server as indicated but still no luck.
When I go to each server and do a nslookup command to find the server from the other domain, the lookup fails.
Any other thoughts here?
its DNS related for sure your AD
dcdiag /v /c /d /e /s:dcname > c:\diag.txt
run on every domain controller and also post ipconfig /all from every DC
dcdiag /v /c /d /e /s:dcname > c:\diag.txt
run on every domain controller and also post ipconfig /all from every DC
ASKER
anne-diag.txt anne-ipconfig.txt francis-diag.txt francis-ipconfig.txt holycross-diag.txt holycross-ipconfig.txt john-diag.txt john-ipconfig.txt lucy-diag.txt lucy-ipconfig.txt michael-diag.txt michael-ipconfig.txt turgeon-diag.txt turgeon-ipconfig.txt District-ipconfig.txt mary1-diag.txt mary1-ipconfig.txt Primary-diag.txt Primary-ipconfig.txt
The Anne, Francis, Holy Cross, John, Lucy, Michael and Turgeon servers are all secondary domain controllers in domain A. The Primary server in this domain is the DNS server that these other servers point to. The District server is a member server in this domain A and it is on this server that the remote desktop application resides.
The Mary server is in Domain B and it is the users of this server that are having difficulty running the Remote Desktop Services Application that resides in Domain A on the District server.
Thanks for your continued assistance.
The Anne, Francis, Holy Cross, John, Lucy, Michael and Turgeon servers are all secondary domain controllers in domain A. The Primary server in this domain is the DNS server that these other servers point to. The District server is a member server in this domain A and it is on this server that the remote desktop application resides.
The Mary server is in Domain B and it is the users of this server that are having difficulty running the Remote Desktop Services Application that resides in Domain A on the District server.
Thanks for your continued assistance.
I am looking through the logs now.
But there may be something very simple here, the following is from the mary1-ipconfig.txt
it is showing an apipa address, these can register in DNS, so when a client does a nslookup they are told the IP of the server is the apipa, and not the static. This could also explain the erratic behavior, of clients working/not working
try disabling the unused adapter
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : IBM USB Remote NDIS Network Device
Physical Address. . . . . . . . . : 02-1A-64-B5-54-41
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
Autoconfiguration IPv4 Address. . : 169.254.227.163(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.0.0
Default Gateway . . . . . . . . . :
NetBIOS over Tcpip. . . . . . . . : Enabled
But there may be something very simple here, the following is from the mary1-ipconfig.txt
it is showing an apipa address, these can register in DNS, so when a client does a nslookup they are told the IP of the server is the apipa, and not the static. This could also explain the erratic behavior, of clients working/not working
try disabling the unused adapter
Ethernet adapter Local Area Connection:
Connection-specific DNS Suffix . :
Description . . . . . . . . . . . : IBM USB Remote NDIS Network Device
Physical Address. . . . . . . . . : 02-1A-64-B5-54-41
DHCP Enabled. . . . . . . . . . . : Yes
Autoconfiguration Enabled . . . . : Yes
Autoconfiguration IPv4 Address. . : 169.254.227.163(Preferred)
Subnet Mask . . . . . . . . . . . : 255.255.0.0
Default Gateway . . . . . . . . . :
NetBIOS over Tcpip. . . . . . . . : Enabled
ASKER
I disabled this unused adapter but still no luck yet.
you would also need to run ipconfig /flushdns and ipconfig /registerdns
ASKER
I have issued these commands as well but still hit and miss connecting.
Any other thoughts?
Any other thoughts?
Edit the host file on a non working client
Add the record "serverip. Servername"
Save and reboot and test
Add the record "serverip. Servername"
Save and reboot and test
ASKER
I have tried this but unfortunately still same result.
you said you have been able to ping the ip address of the server. When you have a problem machine acting up can you ping the server by name?
as a temporary test change the icon for the problem program to be \\ip of the server\share name
as a temporary test change the icon for the problem program to be \\ip of the server\share name
ASKER
Yes, when there is a problem machine I can still ping the server by name. When I tried to access the share via the \\ip address\share name I can't connect. The message "there are no currently no logon servers able to service the logon request" appears.
Upon further thinking I will reference the paragraph I wrote from above
"If I look at the security on the folder that I am trying to access, domain users from domain A have modify rights to the folder that contains the program that they are trying to run. If I try to add the domain users group from domain B to have the same modify rights to this directory I receive the following message, "The Active Directory Domain Controllers required to find the selected objects in the following domains are not available: domain B. Ensure the Active Directory domain controllers are available and try to select the objects again."
I am wondering if I changed this Remote Desktop Services server from just a member server to a domain controller that joins Domain A, then Active Directory will be installed on this server and I may have better luck assigning permissions on the network share. This might help me get past this problem.
Any thoughts on this?
Thanks for sticking with me on this one!
Upon further thinking I will reference the paragraph I wrote from above
"If I look at the security on the folder that I am trying to access, domain users from domain A have modify rights to the folder that contains the program that they are trying to run. If I try to add the domain users group from domain B to have the same modify rights to this directory I receive the following message, "The Active Directory Domain Controllers required to find the selected objects in the following domains are not available: domain B. Ensure the Active Directory domain controllers are available and try to select the objects again."
I am wondering if I changed this Remote Desktop Services server from just a member server to a domain controller that joins Domain A, then Active Directory will be installed on this server and I may have better luck assigning permissions on the network share. This might help me get past this problem.
Any thoughts on this?
Thanks for sticking with me on this one!
ASKER
When I try to run the program I get the same result.
I noticed that in domain B the clients are not registering their names and IP addressses into DNS on this domain controller even though the setting in TCP indicates that they should be.